CloudFront vs Global Accelerator
Cikkünk előző részében arra jutottunk, hogy ha szeretnénk hibatűrő és a felhasználóhoz közel lévő alklamazást, akkor
- vagy teljességre törekszünk, és alkalmazást, adatbázist, storage-et replikálunk a szükséges régiókba, és a Route53 latency-alapú routingját választjuk
- vagy kihasználjuk az Edge Locationök nyújtota lehetőséget, és az alkalmazást a CloudFront vagy a Global Accelerator használatával visszük közel a felhasználóinkhoz.
A cikk végén pedig föltettük a kérést: ugyan miért van két, nagyon hasonló szolgáltatása az AWS-nek? A múltkor azt ígértük, hogy a kérdést meg fogjuk válaszolni, és ebben a cikkben eljött az ideje, hogy ígéretünket beváltsuk.
Valójában nagyon is sok a különbség a két szolgáltatás között, és - mint rendesen - az ördög a részletekben rejlik.
Honnan "tudja" a felhasználó eszköze, hogy melyik Edge Locationhöz csatlakozzon?
- A CloudFront esetében a CloudFront-disztribúció domainnevére irányuló kérésekre az AWS névszerverei a felhasználóhoz, illetve a felhasználó DNS-szerveréhez eső legközelebbi Edge Location IP-címével válaszolnak. Ha a disztribúció domainneve helyett a saját domainünket szeretnénk használni, akkor vegyünk fel a disztribúcióra mutató CNAME-rekordot.
- A Global Accelerator esetén két statikus anycast IP-címet kapunk. Ezt a két címet DNS-szerverbe A-rekordként beírva a két cím anycast mivolta garantálja, hogy a felhasználó mindig a közeli Edge Locationhöz jusson.
Hol hatékonyabb a gyorsítótárazás?
- A CloudFront végez gyorsítótárazást az Edge Locaionökön,
- a Global Accelerator pedig nem, az Edge Locationök itt csak belépési pontot jelentenek az AWS hálózatába. Ha kell gyorsítótárazás is, akkor a Global Accelerator elé tehetünk CloudFrontot.
Minek az elérését tudjuk gyorsítani?
- A CloudFront-disztribúció originje lehet:
- S3-vödör
- S3-vödör statikus weboldalként
- Elastic Load Balancer (Application Load Balancer és Classic Load Balancer)
- EC2-példány
- bármilyen IP-cím, azaz akár on-premises gép is
- AWS MediaPackage vagy MediaStore
- A Global Accelerator egy acceleratorának végpontja lehet:
- Elastic Load Balancer (Application Load Balancer és Network Load Balancer)
- EC2-példány
- EIP, azaz bármilyen olyan AWS-béli szolgáltatás, amihez Elastic IP kérhető
Ezek szerint Global Accelerator használatakor lehet on-premises a DNS, de a gyorsított erőforrásoknak az AWS-ben kell lenniük.
Milyen protokoll és melyik port használható?
- A CloudFront csak HTTP-protokollon működik. Csak a 80-as és 443-as porton hallgatózik, és ezekre, valamint az 1023 fölötti portokra továbbít kéréseket.
- A Global Accelerator TCP-n és UDP-n egyaránt fogad kéréseket (és nyilván bármelyik olyan protokoll is használható, amelyik ezek fölött működik). Egy accelerator akár több listenert is kaphat, az általunk meghatározott portra vagy portokra.
Tudok-e vele több régióba irányítani forgalmat (például hibatűrés végett)?
- CloudFront esetében a beállítás nem magától értetődő, de működik: az egyik.ceg.hu név egy CloudFront-disztribúcióra oldódik fel, aminek az originje viszont lehet például egy latency-policyt alkalmazó rekord (masik.ceg.hu) a Route53-ban. A felhasználó belép az Edge Locationre, és az pedig a legközelebbi régióból olvas majd a masik.ceg.hu Route53-beállítása miatt.
- A Global Accelerator kifejezetten arra van tervezve, hogy több régióban vannak a végpontjai. A régiók közötti forgalomeloszlás alapesetben kiegyenlített, de részlegesen vagy akár teljesen át tudjuk terhelni kézzel az egyik régióba. Egy régión belül pedig végpontcsoportokat definiálhatunk, és közöttük is megadható súlyozás.
Van-e Health Check?
- A CloudFront nem ismeri ezt a fogalmat, az ellenőrzés a mögötte lévő infrastruktúra, például a terheléselosztó dolga lehet. Ennek megfelelően a mögötte lévő elemtől is elvárunk hibatűrést, különben ez lesz a Single Point of Failure.
- A Global Accelerator rendelkezik saját ellenőrző mechanizmussal.
Reagálás a változtatásokra
- Ha a CloudFront disztribúciót módosítanunk kell, akkor az még napjainkban is 7-8 perc, de év elején még háromnegyed órás időkkel kellett számolni. Az operációs rendszer vagy a böngésző a leggyorsabban elérhető Edge Location címét teszi el TTL időre, ami okozhat gondot, ha az IP-cím közben változna.
- Egy-egy accelerator állítása (például a forgalom másik régióba terhelése) gyorsan megy. A Global Accelerator anycast IP-címeit szabad eltenni, ezek nem fognak változni.
Mi a helyzet az árakkal?
- A CloudFront ára az átvitt adatmennyiségtől függ,
- ami a Global Acceleratornál is megvan, de ott fix óradíjat is fizetünk.
Mit is látunk az ábrán?
Most, hogy rengeteg aspektusát megvizsgáltuk a Global Accelerator (és a CloudFront) működésének, értelmezhetjük a szomszédos ábrát. Azt látjuk, hogy az Őrségben kiránduló (kék) felhasználó eszköze Pityerszer mellől az anycast IP alapján a budapesti Edge Locationön belépve az AWS hálójába eljut a frankfurti régióig, és ott a három adatközpont valamelyikében megtalálja azt a virtuális gépet vagy konténert, aki majd beszélget vele. A frankfurti régióban az alkalmazásunk régiós szinten hibatűrő, azaz mind a három adatközpontban jelen van. Az alkalmazásunk másik régiója a londoni, és ott csak egyetlen adatközpontban lévő egyetlen konténer fogadja a terhelést, mert eddigi tapasztalataink alapján ennyi is elég. A konténernek van lehetősége skálázódni, azaz ha elkezdene nőni a terhelés, indulnának újabb konténerek, de most még nincs erre szükség. A barcelonában lévő (piros) felhasználónk a Sagrada Familia szépségein ámulva kezdeményezi az alkalmazáshoz való hozzáférést, és ő a madridi Edge Locationben találja meg a budapestivel (és a többi Edge Locationnal) is megegyező anycast IP-címet. Itt belép az AWS-hálóba, Párizsban elkanyarodik Anglia felé és eléri a londoni alkalmazás-végpontot.