Amazon laat Cloudfront dynamische content serveren

Amazon Web Services heeft zijn clouddienst Cloudfront, dat bedoeld is voor contentdistributie, voorzien van de mogelijkheid om dynamische content te serveren. Tot nu toe was het alleen mogelijk om statische content aan te bieden.

Cloudfront, dat in 2008 zijn deuren opende, wordt als content delivery network ingezet door websites die grote hoeveelheden statische content willen aanbieden, zoals afbeeldingen, video's of muziekbestanden. De content wordt daarbij opgeslagen in zogenaamde buckets die via een url oproepbaar zijn. Amazon gebruikt voor het aanbieden van content via zijn Cloudfront-platform wereldwijd circa dertig datacenters.

Inmiddels laat Amazon weten dat het zijn contentdistributiedienst van de mogelijkheid heeft voorzien om voortaan ook dynamische content te serveren. Hierdoor kan voor elke bezoeker van een website bepaald worden welke content voor hem of haar beschikbaar is.

Om dynamische content via Cloudfront te serveren, zou een websitebeheerder via de AWS Management Console slechts enkele stappen hoeven te doorlopen. Doordat Cloudfront nu in een url een query string herkent, kan vervolgens dynamische content naar de eindgebruiker gestuurd worden.

Amazon claimt dat het diverse verbeteringen aan Cloudfront heeft doorgevoerd om het aanbieden van dynamische content te versnellen. Zo wordt er gebruik gemaakt van persistent tcp-verbindingen, kan content uit meerdere bronnen opgehaald worden en de time-to-live-waarde voor caching is voortaan te verlagen tot 0.

Reacties (19)

[borft]

s3 is voor de opslag van data. Je kunt er wel statische data vanuit serveren, maar dan komt het altijd vanuit het data centrum waar je de data opgeslagen hebt (s3 draait dus vanuit een vaste locatie).

CF is een CDN met heel veel nodes. Als je content opvraagt wordt het geserveerd vanuit de node die het dicht bij de requester is. Je hebt dus lagere latency. Verder kan je CF dus niet gebruiken als opslag. Het is een soort reverse proxy, met heel veel end points.

[Henrikop]

S3 kun je allemaal data opslaan in "buckets". Cloudfront kun je bijvoorbeeld gebruiken om statische sites te tonen waarbij het niet uitmaakt of je tien of een miljoen bezoekers hebt per dag. Door verschillende diensten te combineren kun je zelfs sites zoals Tweakers.net hosten (database, website, cache, content, et cetera). Tweakers heeft een vrij vast te berekenen load, het voordeel van AWS zit er o.a. in dat als je minder bezoekers hebt, je minder resources gebruikt en daardoor bijvoorbeeld ook een kostenbesparing kan realiseren.

[borft]

met cloudfront kan je helemaal geen statische websites tonen, Het is geen webserver. Cloudfront gebruik je als distributie front voor je eigen web servers met statische content. Cloudfront zorgt dan automatisch dat het via het dichtsbijzijnde endpoint uitgeserveerd wordt. Verder schaalt het automatisch mee met de vraag. Je betaalt voor het aantal afgehandelde requests, dataverkeer en invalidaties.

Het mechanisme is vrij simpel, iemand doet een http request naar CF, de desbetreffende node kijkt of de content lokaal beschikbaar is, zonee, dan wordt het aan de upstream leverancier gevraagd (je eigen web server). Daarna wordt het doorgestuurd naar de persoon die het opvraagt. Als de data wel lokaal beschikbaar is, dan wordt het direct verstuurd, zonder contact met de upstream leverancier.

Voor het invalideren van de lokale cache zijn eigenlijk 2 mogelijkheden:
- de cache headers die je eigen web server meegeeft worden gerespecteerd
- je kunt op url niveau invalidatie requests sturen. Hiervoor moet je in de regel wel betalen.

wat betreft he serveren van een site zoals tweakers zou ik niet zo snel voor een cloud oplossing kiezen. Het aantal bezoekers is redelijk voorspelbaar en constant. Fysieke servers in eigen beheer geven je een stuk meer controle (performance tuning, hardware keuze, software keuze, etc), mits je er de kennis voor hebt. Vrij grote kans dat het ook goedkoper is.

Voor sterk wisselende en/of lastig voorspelbare loads is het schalen van de cloud oplosingen van amazon natuurlijk jeen uitkomst!

[Reactie gewijzigd door borft op 23 juli 2024 20:46]

[Genoil]

aangezien nu url querystrings herkend worden, komt er een 3e manier om te invalideren bij, met een versie string:

/mijnvideo.mp4?v=1,2,3

niet heel fraai maar wel praktisch :-)

[borft]

het helpt alleen niet tegen mensen die bestaande urls verversen

[Lex_brugman]

Zelfs bij een voorspelbare load kan een schaalbare cloud oplossing zijn voordelen hebben, je kan namelijk op off-peak uren met minder servers draaien om de kosten te drukken. En bij het gebruik van eigen fysieke servers zal je ook altijd aardig wat meer overcapaciteit moeten hebben, in tegenstelling tot de andere optie waarbij je serverpark automatisch meeschaalt en je dus standaard minder overcapaciteit nodig hebt.

Beiden hebben zo hun voor- en nadelen.

[borft]

helemaal mee eens, vandaar dat ik ook aangaf dat voor sterk wisselende loads de cloud, of eigenlijk (Semi) automatisch schalende oplossingen zoals Amazon AWS die aanbiedt een prima oplossing zijn, zowel op performance- als kostentechnisch.

Het is redelijk briljant dat je met een sim[pel shellscriptje opeen 20 machines erbij kunt booten en die automatisch achter je loadbalacer kunt hangen. Waarbij de loadbalancer automatisch opschaalt naarmate het dataverkeer toeneemt! Maar alles heeft wel zijn prijs natuurlijk.

Ik vraag me bijvoorbeeld af wat de io performance is van de zwaarste instanties, zelf als je meerdere ELB's in raid opstellingen gebruikt. En fysieke machine met een stuk of 10 ssd's in raid10 haalt toch echt fokking veel iops

[jvd-nl]

Henrikop en borft hebben beide gelijk. Je kunt bij het aanmaken van een distributie kiezen of deze gebruik maakt van een http upstream (hij haalt de data van je eigen webserver) of dat deze in een S3 bucket kijkt.

Het laatste is in theorie iets sneller, maar lastiger te implementeren omdat de webapplicatie ervoor moet zorgen dat de content in S3 komt. Wanneer de website enkel statisch is, maakt dat natuurlijk niet uit. Je kunt zelfs een 'index' file specificeren, waarmee je dus wel degelijk een volledige statische website kan hosten. Of dat rendabel is, is een heel andere vraag.

Een ander groot voordeel van een CDN is dat je content krijgt geserveerd vanaf de dichtstbijzijnde edge-locatie. Wanneer je de website vanuit NL bezoekt, krijg je dus waarschijnlijk een CF server in A'dam te pakken. Wanneer je vanuit België komt wellicht een server in Brussel. Dat is dus vooral zinvol wanneer je een sterk internationaal georiënteerde website host.

[Reactie gewijzigd door jvd-nl op 23 juli 2024 20:46]

[humbug]

Een ander groot voordeel van een CDN is dat je content krijgt geserveerd vanaf de dichtstbijzijnde edge-locatie. Wanneer je de website vanuit NL bezoekt, krijg je dus waarschijnlijk een CF server in A'dam te pakken. Wanneer je vanuit België komt wellicht een server in Brussel. Dat is dus vooral zinvol wanneer je een sterk internationaal georiënteerde website host.

Of wanneer je gewoon een hele hoge uptime nodig hebt. Een aardbeving in Amsterdam waardoor je datacenter onbereikbaar is, is dan geen probleem.

[Blaise]

Is het nu mogelijk om op een makkelijkere manier dynamisch je statische bestanden te gzippen? Want dat zou wel een uitkomst zijn.

[siepeltjuh]

Waarom zou je dynamisch statische bestanden willen gzippen?

Praktisch elke webserver, bekijkt tijdens het opstarten welke statische bestanden er zijn, gzipt die in een cache en serveert die zodra er een gzip header wordt meegestuurd.

Het dynamisch gzippen, oftewel bij elke request de content gzippen veroorzaakt zinloze cpuload. Je CPU doet immers bij elke request exact dezelfde bewerkingen en genereert dezelfde output....

[MeZZiN]

De reden dat Blaise dit zegt is waarschijnlijk omdat cloudfront geen native manier heeft van het glippen van bestanden. Het zou nu iets makkelijk kunnen worden door ipv meer logica een parameter aan een filename te geven ?gzip=true of iets om het te gzippen.
(je kan via een om weg alle bestanden als GZIP uploaden en de headers goed zetten maar niet zo handig helaas.)

Maar het zou mooier zijn als AWS gewoon GZIP en non-GZIP ondersteund....

[Lex_brugman]

Het maakt voor Amazon niet uit of de data gzipped is of niet. Als je origin server de data gegzipped aanbied komt het gegzipped in de cache van CloudFront, en zal het ook zo serveren aan de clients.

[borft]

wat wel interessant is, wat gebeurt er met clients die gzip niet in de accept-headers hebben staan?

[Lex_brugman]

CloudFront kijkt naar de client HTTP headers, als die anders zijn (bijv. een andere Accept-Encoding header) zal hij hiervoor opnieuw je origin server raadplegen. Zo krijg je dus meerdere varianten van een pagina/file in de cache.

[borft]

echt waar? volgens mij gebruikt amazon gewoon de url als key voor de cache laag en is er dus geen verschil! Kan er ook in de docs niets over vinden eigenlijk (zelfs cookies worden niet doorgegeven).

[Lex_brugman]

Echt waar http://docs.amazonwebserv...#RequestCustomCompression

[Reactie gewijzigd door Lex_brugman op 23 juli 2024 20:46]

[borft]

i stand corrected weer wat geleerd

Overigens kijken ze dus niet naar alle headers die de client meestuurt, maar dus wel naar de compression headers.

[Reactie gewijzigd door borft op 23 juli 2024 20:46]

[cornedor]

Weet iemand het verschil tussen S3 en Cloudfront? S3 kun je toch ook gebruiken als content-platform?

[Reactie gewijzigd door cornedor op 23 juli 2024 20:46]