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.