Miért ne használná az AWS S3 vagy a CloudFront statikus eszközök kézbesítéséhez?

AWS A menő gyerek a városban. A különböző felhőszolgáltatók minden összehasonlítása hiányos, kivéve, ha legalább egyszer összehasonlítja őket az AWS-szel.

De az S3, a felhőben történő tárolás legnépszerűbb megoldása, amelyet mindenki szeret, nem mindig az Ön választása. Ebben a cikkben elmagyarázom, miért.

Megjegyzés: Kérlek, ne kiabálj azonnal azzal, hogy az AWS hogyan és miért a legjobb. Tudom, hogy a felhőalapú számítás élén állnak - és semmiképpen sem próbálom megcélozni bármely üzleti gyakorlatukat és szolgáltatásukat.

Most használtam a CloudFront + S3-at, a DigitalOcean + Cloudflare-rel együtt, és lefektettem a megfigyeléseimet. Kérem, vegye konstruktívan gondolataimat, és ha úgy gondolja, hogy hibáztam, tweeteljen a mehulmpt-en.

CloudFront + S3

A CloudFront egy másik szolgáltatás, amelyet gyakran használnak (és ajánlanak) az S3-mal, amikor a fájlokat digitálisan terjeszteni próbálja az egész világon. A CloudFront az Amazon CDN-je, szélső szerverekkel a világ minden tájáról. Így működik:

A felhasználó, mondjuk Indiából, megpróbálja betölteni webhelyét, amelynek szervere az Egyesült Államokban található. Tegyük fel, hogy olyan SPA-t használ, mint a React vagy az Angular. Az első index.html oldal az eredeti szerverről töltődik be (általában jó gyakorlat, ha a HTML-oldalakat soha nem tároljuk gyorsítótárba, különösen akkor, ha SSR-alkalmazásokat használ a gyorsítótár-hibák elkerüléséhez).

Ezt követően, ha a JS / CSS fájlokat tárolta a CloudFront (S3) szolgáltatáson, akkor ezeket a hívásokat a CloudFront domainnevére fogják kezdeményezni, amely a tartózkodási helyéhez legközelebb eső gép IP-címére változik. Ebben az esetben valószínűleg az AWS szerverei ülnek valamilyen adatközpontban Mumbaiban, Indiában.

Ettől a ponttól kezdve a kiszolgáló felel a fájl kézbesítéséért. Két dolog történhet:

  • a fájlod már elérhető azzal a mumbai kiszolgálóval (gyorsítótárban), és az a kiszolgáló azonnal visszaadja neked a fájlt (cache hit),
  • vagy nem rendelkezik azzal a fájllal, és meg kell tennie egy utat az eredeti kiszolgálóhoz (ebben az esetben S3 vödör) a fájl megszerzéséhez.

De még ha van is egy gyorsítótár-hiány, nagy az esély arra, hogy még mindig gyorsabb lesz a felhasználó számára, ha nincs CloudFront elöl.

Miért? Mert ha van egy gyorsítótár-hiány, és az élkiszolgáló megpróbálja elérni a fő szervert, akkor az Amazon - egy billió dolláros amerikai társaság - által üzemeltetett Tier 1 internetkapcsolati vonalat használ. Valószínűleg sokkal jobb az internetkapcsolatuk és a késésük, mint amit az internetszolgáltató kínál.

Továbbá, mivel ugyanazon a globális Amazon-hálózaton vannak, néhány elegáns optimalizálással több időt takaríthatnak meg.

Rendben! Nekem eddig nagyon jól hangzik, akkor mi a probléma? Fogd a lovaidat, ráérünk.

Eszköztömörítés

A CloudFront lehetővé teszi a GZIP használatával tömörített eszközök szállítását. De van még egy menőbb gyerek is a piacon: brotli tömörítés. És szinte minden nagyobb böngésző támogatja.

A Brotli még jobban tömöríti az átviteli adatokat. Ez azt jelenti, hogy nemcsak a pénztárcáján, de a végfelhasználónak is jó (mert kevesebb időt töltenek a betöltő / fehér képernyő megtekintésével).

Az Amazon CloudFront egyelőre nem támogatja a brotli tömörítést. És én sem hibáztatom őket emiatt. Ez azért van, mert a brotli tömörítés menet közben lassú (a CloudFront menet közben is gzipez), ezért még nem hajtották végre.

Persze, akkor csináljuk mi magunk, és tároljuk az S3-on, és szállítsuk a tömörített verziót, igaz? Sajnos ez nem ilyen egyszerű, és hamarosan egy építészeti problémává válunk.

Egy tipikus eszköz URL a következőképpen néz ki: //mysite/assets/javascript/file.js

Amikor a böngésző kérést küld, fejlécet küld: Elfogadás-Kódolás. Ez a fejléc tartalmazhat tömörítési algoritmusokat, amelyeket a böngésző támogat, például a gzip, a deflate, a brotli stb. A szervernek most már okosan kell cselekednie a maximális hatékonyság érdekében.

  1. Ha az ügyfél támogatja a brotlit, akkor mindig szállítsa a brotli tömörített eszközt.
  2. Ha az ügyfél támogatja a gzip-t, akkor mindig szállítsa a gzip-t.
  3. Ellenkező esetben szállítsa be az eredeti fájlt.
  4. Győződjön meg arról is, hogy a válasz típusában a megfelelő tartalomkódolás van-e beállítva, hogy a böngésző fel tudja ismerni a tömörítési algoritmust.

Először létre kell hoznia minden egyes eszközfájl 3 változatát:

  1. file.js
  2. file.js.br - brotli
  3. file.js.gz - gzip

És feltételesen meg kell küldenie őket attól függően, hogy a böngésző támogatja-e vagy sem. A CloudFront egy "buta" CDN - csak lekérési URL-jét hozzárendeli a szerveren lévő fájlhoz. Csak akkor hajthat végre átalakításokat, ha ... Ön egy másik AWS szolgáltatást választ - a Lambda @ edge funkciókat

Valószínűleg mindannyian tudjuk, hogy mi a Lambda az AWS-en - a felhőben is futtathat funkciókat anélkül, hogy aggódnia kellene az alapul szolgáló infrastruktúra-átméretezés vagy kicsinyítés miatt. API kérés szerinti árazás, időhöz kötött, édes. A Lambda @ edge hasonló szolgáltatás, de élkiszolgálókhoz készült (CloudFront CDN adatközpontok)

Technikailag konfigurálhatja a Lambda szervert úgy, hogy "középső emberként" működjön az ügyfél kérése és a CloudFront CDN között. A Lambda megnyithatja a kérést, megnézheti a támogatott tartalom fejléceket, ennek megfelelően módosíthatja az URL-t, és továbbíthatja azt a "buta" CloudFrontnak, amely ekkor be fogja szerezni a módosított URL fájlt.

Például, ha a Lambda úgy látja, hogy a böngésző egy Accept-Encoding: br-t küldött, akkor a lambda segítségével módosíthatja a kérés URL-jét a /javascript/file.js fájlról a /javascript/file.js.br fájlra anélkül, hogy a felhasználónak valóban szólna. A Cloudfront most lekér egy kisebb hasznos terhet, és választ ad egy brotli kódolásra. GYŐZELEM!

De ez jó, nem igaz? Hol a probléma? A probléma ... az árképzés.

Az AWS nevetségesen drága (ehhez a feladathoz)

Bármi, amit eddig tettél, nagyon jól hangzik és jól néz ki. De ha megnézi, mi történik, amikor jelentős számokat kezd el találni, rájön, hogy az AWS nem nagyszerű az adatátvitel terén. A Zoom ugyanezen okból éppen az AWS-re pattant.

Ráadásul az eszköztömörítéssel most a Lambda @ edge hívásokért is fizetnie kell. Rájöttem, hogy a Lambda @ edge megvalósítása valóban csökkenti a költségeit, különben sokkal többet fizet az AWS-ért a forgalomért!

A CloudFront az adatátviteli árazásokon dolgozik. Nem akkor számít fel díjat, ha adatokat szerez az S3 vödörből, hanem akkor, ha a felhasználó adatokat szerez be az élkiszolgálókról.

Felső költség kötött

A legdrágább országban - Indiában - a CloudFront 0.170 USD-t számít fel az átvitt adatok GB-jáért. Ez hatalmas!

Tegyük fel, hogy van egy népszerű (főleg) indiai webhelye, ahol naponta körülbelül 50 000 felhasználó látogatja meg az Ön webhelyét. Tegyük fel azt is, hogy minden héten végez néhány változtatást a webhelyén (elég gyakori a gyorsan ismétlődő termékeknél), így érvénytelenítenie kell a böngészőt és a CloudFront gyorsítótárát.

Tegyük fel, hogy átlagosan egyetlen felhasználó körülbelül 10 MB statikus eszközt tölt le az Ön webhelyéről (beleértve a CSS / JS / képeket / betűtípusokat is), amelyeket az S3-on tárol a CloudFronton keresztül.

Számoljuk ki a költségeket:

  1. 50 ezer indiai felhasználó
  2. 0,17 USD / GB
  3. 10 MB felhasználónként
  4. Minden felhasználó ezt havonta négyszer kapja le (Ön négyszer öblíti ki a gyorsítótárat - hetente egyszer)

Költség = 50000 * 0,17 * (10/1024) * 4 = 332 USD. Ez a költsége az adatátvitelnek! Nem számoltam az S3 tárolási és a tárhely költségeit. (A lambda árképzést azért sem vettem fel, mert nem sok => $ (0,20 * (50 000 * 4)) / 1 millió = 4 cent.)

Alacsonyabb költség kötött

Ebben az esetben tegyük fel, hogy egy amerikai forgalmi webhely található. A paraméterek most a következők lennének:

  1. 50 000 USA-felhasználó
  2. 0,085 USD / GB
  3. 3 MB felhasználónként
  4. Minden felhasználó ezt havonta négyszer kapja le (Ön négyszer öblíti ki a gyorsítótárat - hetente egyszer)

A költség = 50000 * 0,085 * 3 * 4/1024 = 50 USD. Ez a legalacsonyabb összeg, amelyet akkor fizet, ha a CloudFront az említett forgalommal használja (mivel az összes 50 000 felhasználója csak az Egyesült Államokból származik). És ne feledje, ez csak az adatátvitel költsége! (A webhely szerverének költségeit nem számítva.)

Alternatív

Tegyük fel, hogy most ezeket a statikus eszközöket csak a fő szerveren tárolja - fordítva az NGiNX által közölve, és mondjuk egy 60 dolláros DigitalOcean példán fut.

A havi adatátvitel = 50000 * (10/1024) * 4 = 1952 GB körülbelül 2 TB - a DigitalOcean ingyenesen fedezi az 1 TB cseppenkénti átvitelt. És attól kezdve 10 USD / 1 TB, tehát nettó 70 dollár lesz a szerver futtatásához.

Persze, most kap némi késleltetést - mert maga is otthont ad neki (ezt később még kijavítjuk). Az NGiNX egy nagy teljesítményű webszerver, és bízhat benne, hogy ez nem szűk keresztmetszet a statikus eszközök kézbesítésében.

Tehát csak a teljes szerver futtatásáért csökkentette az "egyetlen eszközátadás" költségét 332 dollárról 70 dollárra! Bónusztipp? Arra összpontosítottunk, hogy ezt csak Indiában futtassuk, ezért használjon Indiából származó DigitalOcean szervert. Ez kevesebb késést jelentene.

Nem csak ez, de választhatja a Cloudflare CDN-t is - ami INGYENES. A Cloudflare nem fogja tiszteletben tartani a CDN-ben tárolt fájljait, ha túl nagyok vagy ritkán férnek hozzá. De pokolian népszerű webhelyet feltételezünk itt, ezért jól kellene lennünk. Ha nem, akkor válasszon bármely más CDN szolgáltatást, és garantálom, hogy kevesebb, mint havi 332 USD lesz.

TL; DR - Ha közepesen nagy forgalmat bonyolító webhelyet üzemeltet rendszeresen ütemezett frissítésekkel, akkor sokkal költséghatékonyabb az eszközök saját maga tárolása és külső CDN-ek (vagy akár olyan dolgok használata, mint például a DigitalOcean CDN) használata az S3 használata helyett. CloudFront (ahol az adatforgalom sebessége a tetőn van).

Következtetés

Ezt a beállítást (CloudFront + AWS S3) használtam a codedamn.com webhelyen - egy platform a fejlesztők számára a tanuláshoz és a fejlődéshez. Hamarosan rájöttem, hogy bár divatosnak tűnik, és a nagy ligákba - az Amazonba - belekódoltam, ez egyszerűen nem elég hatékony.

Egyetértesz velem? Mit gondolsz? Tájékoztasson arról, hogy tweetelt rám a Twitteremen, vagy az Instagramon kereste meg.

Béke!