Késleltetési tesztek Budapest és AWS, Frankfurt között

Kipróbáltam néhány alternatívát a két helyszín közötti kapcsolat felépítésére

Az előző cikkemben arról írtam hogyan lehet a Direct Connect segítségével közvetlenül kapcsolódni az AWS hálózatához. Utána kíváncsi lettem vajon milyen igények esetén lehet valóban szükség a Direct Connect-re, mikor nem elég a publikus internet által adott sávszélesség és késleltetés.

A teszteléshez használt on-premise környezet a Budapesten, a BIX VH node-dal közös épületben található.

Ha egy AWS-en létrehozott VPC-hez, illetve a VPC-ben futó EC2 virtuális géphez akarunk kapcsolódni, akkor nagyjából az alábbi lehetőségeink vannak:

• közvetlenül az EC2 virtuális gép publikus IP címére (ha van neki)
• AWS Virtual Private Gateway-en keresztül IPsec kapcsolat segítségével
• saját szofveres VPN megoldással (én most a teszt kedvéért WireGuard-ot használtam)
• Global Accelerator-on keresztül közvetlenül a gép valamelyik nyitott TCP/UDP portjára
• Global Accelerator-on keresztül felépített saját VPN megoldással
• Direct Connect segítségével

A Direct Connect ezek közül a legdrágább megoldás, cserébe garantált sávszélességet és késleltetést biztosít. Az elérhető sávszélesség itt a legmagasabb, akár több száz Gbit/s is lehet.

A Global Accelerator használata azt jelenti hogy a forgalmunk nem a publikus interneten keresztül utazik Frankfurtig, hanem már a budapesti edge helyszínen felmegy az AWS Global Backbone-ra, ami elméletben alacsonyabb késleltetést biztosíthat.

Az AWS Virtual Private Gateway-nek van egy olyan korlátozása hogy egy kapcsolat maximum 1.25 Gbit/s sávszélességet tud biztosítani és egy Customer Gateway felé maximum két kapcsolat hozható létre aktív-passzív felállásban. Egy Transit Gateway közbeiktatásával ezen annyit lehet javítani hogy két linken aktív-aktív felállásban equal cost multipath routing alakítható ki. Egy-egy TCP kapcsolat még így is 1.25 Gbit/s -re korlátozódik, de több párhuzamos kapcsolat már ki tudja használni a teljes 2.5 Gbit/s sávszélességet.

Ha az on-premise környezet csak 1 Gbit/s linken kapcsolódik az internetre, akkor ez persze nem probléma, ha viszont 10 Gbit/s vagy nagyobb sebességgel szeretnénk kapcsolódni akkor ez az út nem járható.

Saját, szoftveres VPN megoldásokkal ez a limit megkerülhető, csak a végpontunkat futtató EC2 virtuális gép számára elérhető sávszélesség és annak CPU teljesítménye lehet korlátozó tényező. Én a teszteléshez a WireGuard-ot használtam, egyrészt azért mert egyszerű bekonfigurálni, másrészt azért mert kifejezetten jó a teljesítménye.

Ilyen feladatra célszerű network optimized instance típust választani. Ha a létrehozott virtuális gép legalább 32 vCPU-t kapott akkor az instance típus elvi max. sávszélességének felét (pl. egy c6in.8xlarge esetén 25 Gbit/s-et) is elérhetjük, kisebb instance típusoknál 5 Gbit/s a maximum. Fontos, hogy egy stream-en (azonos source-dest ip cím, port és protokol) csak 5 Gbit/s tud kimenni, ami egy wireguard link sávszélességét is 5 Gbit/s-re korlátozza. Ha ennél nagyobb sebesség kell akkor pl. wireguard esetén több különböző tunnel-t kell létrehozni párhuzamosan majd azok fölött equal-cost multipath routing-ot kell megvalósítani.

Mivel az on-premise környezetünk 1 Gbit/s sávszélességet használ, a teszteléshez egy kisebb, c6in.large instance típust választottam, amit a frankfurti AWS régióban hoztam létre.

A virtuális gépre telepítettem egy nginx webszervert is hogy egy egyszerű html oldal letöltését tudjam tesztelni.

Elsőként azt néztem meg mekkora a ping válaszidő Budapestről Frankfurt felé közvetlenül az EC2 virtuális gép publikus IP címét használva. Ez nagyjából 16 ms volt.

Utána megnéztem mennyi idő alatt töltődik le a statikus oldal:

$ curl -o /dev/null -s -w 'Total: %{time_total}s\n' http://18.156.2.6

Eredményül több próbálkozásból nagyjából 31-32 ms adódott.

Következő lépésként felépítettem a wireguard kapcsolatot a két gép között, majd azon keresztül futtattam a ping-et, így is 16 ms válaszidőt kaptam, a wireguard okozta késleltetés tehát elhanyagolható.

A curl letöltés a wireguard linken keresztül 32-33 ms körül volt, ebben sem volt lényeges eltérés.

Kíváncsiságból megnéztem az elérhető sávszélességet is iperf3 segítségével, kb. 650-750 Mbit/s körüli értékek adódtak az 1 Gbit/s link fölött (de ennek ne tulajdonítsatok nagy jelentőséget, az éppen elérhető sávszélesség ebben a viszonylatban elég sok tényezőtől függ).

Az iperf teszt közben ránéztem a CPU terhelésre, de az alig néhány százalék volt a 2 vCPU gépen, tehát ez a kis c6in.large instance simán ki tudná használni a rendelkezésére álló 5 Gbit/s -et, a nagyobbakkal pedig nem lehet probléma a 10-20 Gbit/s sem.

Következő lépésben bekonfiguráltam egy Global Accelerator példányt az AWS oldalán és mind a HTTP (TCP port 80) mind a WireGuard (UDP port 1820) forgalmat ezen keresztül irányítottam.

A statikus oldal letöltése curl segítségével nagyon hasonló válaszidőt adott ebben az esetben is mint a Global Acceletor nélkül: 32-34 ms körül.

A wireguard tunnel fölött a ping válaszidő ebben az esetben is 16 ms lett.

Próbaképpen futtattam egy ping-et a Global Accelerator által meghirdetett anycast IP címre is, ez 0.57 ms lett, vagyis erősen valószínű hogy a budapesti edge helyszínt használta a routing (a fény ennyi idő alatt máshova nehezen jutna el).

Tanulságok?

Általános igényekre, 1 Gbit/s sávszélességig a legegyszerűbb az AWS saját Virtual Private Gateway megoldását használni, ott nem kell bajlódni a saját VPN endpoint és router virtuális gépek menedzselésével.

Ha 1.25 - 2.5 GBit/s -nél nagyobb sávszélességre van szükség vagy olyan egyedi igények vannak amit a Virtual Private Gateway segítségével nem lehet megoldani, akkor jó opció lehet az EC2 virtuális gépen futtatott WireGuard, nagyon alacsony késleltetéssel és CPU terheléssel el tud futni.

Ha a hosting szolgáltatódnak jó nemzetközi kapcsolatai vannak, akkor a Global Accelerator használata ebben az irányban nem javít a késleltetésen. Mondjuk túl sokat nem is javíthatna. A fény terjedési ideje optikai kábelen ekkora távolságon (kb. 1000 km) úgy 4-5 ms körül van, oda-vissza 8-10 ms, ehhez képest a 16 ms ping round-trip válaszidő kifejezetten szép érték.

Ha viszont a szolgáltatódnak belföld felé megfelelő a sávszélessége, de a külföldi sávszélességgel, késleltetéssel problémák vannak, akkor megérhet egy próbát a Global Accelerator használata.

Végül visszatérve a Direct Connect-re: mikor lehet létjogosultsága? Hát, ha a hosting szolgáltatódnak jó a sávszélessége és a késleltetése, akkor csak igen speciális esetekben. A fent tapasztalt 16 ms átlagos válaszidőnél sokkal jobbat nem lehet elérni. A kulcsszó a "garantált": ha valamilyen speciális felhasználási terület miatt garantálnunk kellene egy fix, alacsony válaszidőt, azt csak úgy lehetne megbízhatóan teljesíteni ha a szolgáltatás alapját adó kapcsolat is garantált sávszélességet és késleltetést biztosít, ezt pedig csak a Direct Connect tudja. Szintén a Direct Connect mellett szólhat, ha olyan nagy sávszélességre van szükség (50-100 Gbit/s nagyságrendtől) ahol a fenti WireGuard-os EC2 instance már nem opció.