AWS este copilul drăguț din oraș. Fiecare comparație a diferiților furnizori de cloud este incompletă, cu excepția cazului în care le comparați cu AWS cel puțin o dată.

Dar S3, cea mai populară soluție pentru stocarea pe cloud și cea pe care toată lumea o iubește, nu ar trebui să fie întotdeauna alegerea ta. În acest articol, voi explica de ce.

Notă: Vă rog să nu țipați imediat la mine despre cum și de ce AWS este cel mai bun. Știu că se află în partea de sus a cloud computing – și în niciun caz nu încerc să vizez niciuna dintre practicile și serviciile lor de afaceri.

Tocmai am folosit CloudFront + S3 și eu, împreună cu DigitalOcean + Cloudflare și mi-am prezentat observațiile. Vă rog să mă gândiți constructiv și, dacă credeți că am făcut greșeli, trimiteți-mi un tweet la mehulmpt.

CloudFront + S3

CloudFront este un alt serviciu folosit adesea (și recomandat) cu S3 atunci când încercați să distribuiți fișiere digital pe tot globul. CloudFront este un CDN de la Amazon cu servere Edge din întreaga lume. Asa functioneaza:

Utilizatorul dvs., să zicem din India, încearcă să vă încarce site-ul web al cărui server este situat în SUA. Să presupunem că folosiți un SPA precum React sau Angular. Prima pagină index.html se va încărca de pe serverul dvs. de origine (de obicei este o bună practică să nu cacheți niciodată pagini HTML, mai ales dacă utilizați aplicații SSR pentru a preveni accidentele din cache).

După aceea, dacă v-ați găzduit fișierele JS / CSS pe CloudFront (S3), aceste apeluri vor fi efectuate către un nume de domeniu din CloudFront care se rezolvă la adresa IP a unei mașini cea mai apropiată de locația dvs. În acest caz, este probabil un server de la AWS care se află într-un centru de date din Mumbai, India.

Din acest moment, acel server are responsabilitatea de a livra acel fișier. Se pot întâmpla două lucruri:

  • fișierul dvs. este deja disponibil cu acel server Mumbai (în cache), iar acel server vă returnează fișierul imediat (cache a lovit),
  • sau nu are acel fișier și trebuie să efectueze o călătorie către serverul dvs. de origine (bucket S3 în acest caz) pentru a obține acel fișier.

Dar, chiar dacă există o pierdere a memoriei cache, sunt mari șanse ca acesta să fie și mai rapid pentru un utilizator în comparație cu faptul că nu are CloudFront în față.

De ce? Deoarece atunci când există o memorie cache și serverul edge încearcă să ajungă la serverul principal, acesta folosește o linie de conexiune la internet de nivel 1 operată de Amazon – o companie americană de miliarde de dolari. Probabil au o conectivitate și o latență la internet mult mai bune decât ceea ce poate oferi ISP-ul dvs.

De asemenea, deoarece se află în aceeași rețea globală Amazon, pot face câteva optimizări îngrijite pentru a economisi mai mult timp.

Bine! Până acum îmi pare grozav, deci care este problema? Ține-ți caii, vom ajunge la asta.

Compresia activelor

CloudFront vă permite să livrați materiale comprimate folosind GZIP. Dar există chiar și un copil mai rece pe piață: compresia brotli. Și este acceptat de aproape orice browser major.

Brotli vă comprimă și mai mult datele de transmisie. Acest lucru înseamnă că nu numai că este bun pentru portofel, dar este și bun pentru utilizatorul final (deoarece vor petrece mai puțin timp văzând ecranul de încărcare / alb).

Amazon CloudFront nu acceptă încă livrarea de compresie brotli. Și nici nu-i voi învinovăți pentru asta. Acest lucru se datorează faptului că compresia brotli este lentă de făcut din mers (CloudFront face gzip din mers), deci nu au implementat-o ​​încă.

Sigur, atunci să o facem singuri și să o stocăm pe S3 și să livrăm versiunea comprimată, nu? Din păcate, nu este la fel de simplu și, în curând, ne vom întoarce într-o problemă de arhitectură.

O adresă URL tipică a activului ar arăta astfel: http: //mysite/assets/javascript/file.js

Când browserul dvs. face o cerere, acesta trimite un antet: Accept-Encoding. Acest antet poate conține algoritmi de compresie pe care browserul dvs. îi poate accepta, cum ar fi gzip, deflate, brotli etc. Serverul trebuie acum să acționeze inteligent pentru a avea o eficiență maximă.

  1. Dacă clientul acceptă brotli, atunci livrați întotdeauna activul comprimat brotli.
  2. Dacă clientul acceptă gzip, atunci livrați întotdeauna gzip.
  3. În caz contrar, livrați fișierul original.
  4. De asemenea, asigurați-vă că, în tipul de răspuns, este setată codificarea corectă a conținutului, astfel încât browserul să poată recunoaște algoritmul de compresie.

Acum, în primul rând, trebuie să creați 3 variante ale fiecărui fișier de active:

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

Și trebuie condiționat livrați-le în funcție de dacă browserul acceptă sau nu. CloudFront este un CDN „prost” – acesta va mapa adresa URL a cererii dvs. la fișierul de pe server. Nu poate efectua transformări decât dacă …. optați pentru un alt serviciu AWS – funcțiile Lambda @ edge

Știm cu toții ce este Lambda pe AWS – puteți rula funcții pe cloud fără să vă faceți griji cu privire la upscaling sau downscaling al infrastructurii de bază. Prețul cererii API, limitat la timp, plăcut. Lambda @ edge este un serviciu similar, dar a fost creat pentru servere edge (centre de date CloudFront CDN)

Puteți configura din punct de vedere tehnic un server Lambda pentru a acționa ca un „om de mijloc” între solicitarea făcută de clientul dvs. și CDF CloudFront. Lambda poate deschide cererea, poate vedea anteturile de conținut acceptate, poate modifica adresa URL în consecință și o poate redirecționa către CloudFront „prost”, care va prelua fișierul URL modificat atunci.

De exemplu, dacă Lambda vede că browserul a trimis un Accept-Encoding: br, atunci lambda poate fi utilizat pentru a modifica adresa URL a cererii din /javascript/file.js în /javascript/file.js.br fără a spune de fapt părții utilizatorului. Cloudfront va prelua acum o sarcină utilă mai mică și va returna un răspuns pentru o codificare brotli. VICTORIE!

Dar asta este bine, nu-i așa? Unde este problema? Problema este … prețul.

AWS este ridicol de scump (pentru această sarcină)

Orice ai făcut până acum sună și arată foarte bine. Dar când te uiți la ce se întâmplă atunci când începi să atingi un număr semnificativ, îți vei da seama că AWS nu este minunat când vine vorba de transferul de date. Zoom tocmai a sărit AWS din același motiv.

În plus, odată cu compresia activelor, acum trebuie să plătiți și pentru apelurile Lambda @ edge. Mi-am dat seama că implementarea Lambda @ edge vă va reduce de fapt costurile, altfel veți plăti mult mai mult pentru AWS pentru trafic!

CloudFront funcționează la prețurile de transfer de date. Nu vă încarcă când preia date din bucket-ul S3, ci vă încarcă când un utilizator preia date de pe serverele marginale.

Costul superior este obligatoriu

În cea mai scumpă țară – India – CloudFront vă taxează 0,170 USD pe GB de date transferate. Acest lucru este imens!

Să presupunem că aveți un site popular (în principal) indian cu aproximativ 50.000 de utilizatori care vă vizitează site-ul zilnic. De asemenea, să presupunem că faceți câteva modificări de design în fiecare săptămână pe site-ul dvs. (destul de obișnuit pentru produsele cu iterații rapide), astfel încât trebuie să invalidați browserul și memoria cache CloudFront.

De asemenea, să presupunem, în medie, că un singur utilizator descarcă aproximativ 10 MB din activul static de pe site-ul dvs. (include CSS / JS / imagini / fonturi) găzduit pe S3 proxy prin CloudFront.

Să calculăm costul:

  1. 50.000 de utilizatori indieni
  2. 0,17 USD per GB
  3. 10 MB per utilizator
  4. Fiecare utilizator recuperează acest lucru de 4 ori pe lună (vă spălați memoria cache de 4 ori – o dată pe săptămână)

Cost = 50000 * 0,17 * (10/1024) * 4 = 332 USD. Acesta este COSTUL dvs. doar pentru transferul de date! Nu am calculat costul de stocare S3 și costul site-ului de găzduire. (De asemenea, nu am inclus prețul lambda, deoarece nu este mult => $ (0,20 * (50.000 * 4)) / 1 milion = 4 cenți.)

Cost redus

În acest caz, să presupunem un site de trafic din SUA. Parametrii acum ar fi:

  1. 50.000 de utilizatori SUA
  2. 0,085 USD per GB
  3. 3 MB per utilizator
  4. Fiecare utilizator recuperează acest lucru de 4 ori pe lună (vă spălați memoria cache de 4 ori – o dată pe săptămână)

Costul = 50000 * 0,085 * 3 * 4/1024 = 50 USD. Acesta este cel mai mic preț pe care îl veți plăti atunci când utilizați CloudFront cu traficul menționat (având în vedere că toți utilizatorii dvs. de 50K provin doar din SUA). Și amintiți-vă, acesta este costul numai pentru transferurile de date! (Nu includ costurile serverului pentru găzduirea site-ului dvs.

Alternativă

Să presupunem că acum găzduiți toate aceste active statice numai pe serverul dvs. principal – inversat proxy de NGiNX și să spunem, rulând pe o instanță DigitalOcean de 60 USD.

Transferul dvs. de date pe lună = 50000 * (10/1024) * 4 = 1952 GB aproximativ 2 TB – DigitalOcean acoperă gratuit 1 TB de transfer pe picătură. Și este de 10 USD pe 1 TB de atunci, deci vor fi 70 $ net pentru rularea serverului.

Sigur, veți obține o anumită latență acum – pentru că o găzduiți singur (chiar vom rezolva asta mai târziu). NGiNX este un server web performant și vă puteți baza pe acesta să nu fie un obstacol în livrarea activelor statice.

Așa că tocmai ați scăzut costul „transferului de active numai” de la 332 la 70 USD pentru rularea întregului server! Sfat bonus? Ne concentram pe rularea acestui lucru numai în India, deci utilizați un server DigitalOcean din India. Acest lucru ar însemna o latență mai mică.

Nu numai acest lucru, dar puteți opta și pentru Cloudflare CDN – care este GRATUIT. Cloudflare nu va respecta fișierele dvs. pentru a le păstra în CDN dacă sunt prea mari sau sunt accesate prea rar. Dar presupunem că este un site popular aici, așa că ar trebui să fim bine. Dacă nu, alegeți orice alt serviciu CDN și vă garantez că va fi mai puțin de 332 USD pe lună.

TL; DR – Dacă găzduiești un site web cu cantități medii-mari de trafic cu actualizări programate în mod regulat, este mult mai eficient din punct de vedere al costurilor să găzduiești active și să folosești CDN-uri externe (sau chiar lucruri precum DigitalOcean CDN) în loc să folosești S3 și CloudFront (unde ratele traficului de date sunt prin acoperiș).

Concluzie

Am folosit această configurare (CloudFront + AWS S3) pe codedamn.com – o platformă pentru ca dezvoltatorii să învețe și să crească. Mi-am dat seama curând că, deși pare elegant și am introdus codedamn în marile ligi – Amazon – pur și simplu nu este suficient de eficient.

Ești de acord cu mine? Ce crezi? Anunță-mă pe Twitter pe mine sau întinzându-mă spre mine Instagram.

Pace!