Ahoj!
Opět s vámi Nikita — systémový inženýr z firmy SEMrush. A tímto článkem pokračuji v příběhu o tom, jak jsme vymýšleli řešení pro obcházení čínského firewallu pro naši službu semrush.com.
V Pověděl jsem:
- jaké problémy se objevují poté, co padne rozhodnutí 'Musíme zajistit, aby naše služba fungovala v Číně'
- jaké problémy existují v čínském internetu
- proč je potřebná ICP licence
- jak a proč jsme se rozhodli testovat naše testovací prostředí pomocí Catchpoint
- jaký výsledek nám přinesla naše první verze řešení založená na Cloudflare China Network
- jak jsme našli chybu v DNS Cloudflare
Tato část je, podle mého názoru, nejzajímavější, protože se zaměřuje na konkrétní technické realizace strojů. A začneme, vlastně pokračujeme, s Alibaba Cloud.
Alibaba Cloud
Alibaba Cloud — poměrně velký cloudový poskytovatel, který má všechny služby, což mu umožňuje právem nazývat se poskytovatelem cloudu. Je dobré, že mají možnost se zaregistrovat zahraničním uživatelům, a že většina stránek je přeložena do angličtiny (pro Čínu je to luxus). V tomto cloudu můžete pracovat z mnoha regionů světa, pevninské Číny a také Oceánské Asie (Hongkong, Tchaj-wan atd.).
IPSEC
Začali jsme s geografií. Protože naše testovací stránka byla na Google Cloud, bylo nutné 'propojit' Alibaba Cloud s GCP, takže jsme otevřeli seznam lokalit, kde Google působí. V tu chvíli ještě neměli datové centrum v Hongkongu.
Nejbližším regionem se ukázal být asia-east1 (Tchaj-wan). Nejbližším regionem Alibaba Cloud k Tchaj-wanu byl cn-shenzhen (Šen-čen).
Pomocí terraform Popisovali jsme a nastavovali celou infrastrukturu v GCP a Ali. Túnel 100 Mbit/s mezi cloudu byl téměř okamžitě spuštěn. Na straně Šen-čenu a Tchaj-wanu byly spuštěny proxy virtuální stroje. V Šen-čenu je uživatelský provoz terminován a směrován skrze túnel na Tchaj-wan, a odtud už jde přímo na externí IP naší služby v us-east (východní pobřeží USA). Ping mezi virtuálními stroji přes túnel 24 ms, což není tak špatné.
Zároveň jsme umístili testovací zónu na Alibaba Cloud DNS. Po delegování zóny na NS Ali se doba resolvování snížila z 470 ms na 50 ms. Předtím byla zóna také na Cloudflare.
Současně s túnelováním do asia-east1 jsme zprovoznili další túnel ze Šen-čenu přímo do us-east4. Vytvořili jsme další proxy virtuály a začali měřit obě řešení, směrováním testovacího trafiku pomocí Cookies nebo DNS. Schématicky je testovací stanice popsána na následujícím obrázku:
Latence pro tunely byla následující:
Ali cn-shenzhen GCP asia-east1 — 24 ms
Ali cn-shenzhen GCP us-east4 — 200ms
Prohlížečové testy Catchpoint hlásily vynikající zlepšení metrik.
Porovnejte výsledky testů pro dvě řešení:
Řešení
Uptime
Medián
75. percentile
95. percentile
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
Toto jsou data řešení používajícího IPSEC tunel přes asia-east1. Přes us-east4 byly výsledky horší a bylo více chyb, proto je nebudu uvádět.
Z výsledků tohoto testu dvou tunelů, jeden z nichž končí v nejbližším regionu k Číně, a druhý v cílovém místě, bylo jasné, že je důležité co nejrychleji "vyplavat" z pod čínskou firewall a dále používat rychlé sítě (CDN poskytovatelé, cloudoví poskytovatelé atd.). Neměli bychom se snažit překonat firewall a dostat se do cíle jedním tahem. To není nejrychlejší cesta.
Celkově jsou výsledky dobré, nicméně, u semrush.com je medián 8.8s a 75. percentil 9.4s (na stejném testu).
A než se posuneme dál, rád bych udělal malou literární odbočku.
Lyrické odbočení
Po vstupu uživatele na web www.semrushchina.cn, který je rozpoznáván přes "rychlé" čínské DNS servery, HTTP dotaz prochází naším rychlým řešením. Odpověď se vrací stejnou cestou, ale ve všech JS skriptech, HTML stránkách a dalších prvcích webové stránky je uvedena doména semrush.com pro další zdroje, které by měly být načteny při vykreslování stránky. To znamená, že klient rozpoznává "hlavní" A záznam www.semrushchina.cn a vstupuje do rychlého tunelu, rychle dostává odpověď — HTML stránku, která obsahuje:
- stáhni nějaký js z sso.semrush.com,
- CSS soubory si vezmi z cdn.semrush.com,
- a vezmi také obrázky z dab.semrush.com
- a tak dále.
Prohlížeč začíná jít do "vnější" internet za těmito zdroji, přičemž pokaždé prochází časově náročným firewallem.
Ale v předchozím testu jsou uvedeny výsledky, kdy na stránce nejsou žádné zdroje semrush.com, pouze semrushchina.cn, zatímco *.semrushchina.cn se rozpoznává na adresu virtuálního stroje v Šen-čen, aby se pak dostal do tunelu.
Pouze tak, maximalizací veškerého možného provozu prostřednictvím našeho řešení pro rychlé obcházení čínské firewallové regulace, lze dosáhnout přijatelných rychlostí a dostupnosti webu, stejně jako férových výsledků testů řešení.
Učinili jsme to bez jediné změny kódu na straně produktů týmů.
Subfilter
Řešení vzniklo prakticky okamžitě po tom, co se problém objevil. Potřebovali jsme PoC (Proof of Concept), že naše řešení obcházení firewallu skutečně fungují dobře. K tomu je potřeba maximalizovat veškerý provoz webu v tomto řešení. A použili jsme v nginx.
Subfilter — je to poměrně jednoduchý modul v nginx, který umožňuje měnit jeden řetězec v těle odpovědi na jiný. A to jsme udělali se všemi výskyty semrush.com na semrushchina.cn ve všech odpovědích.
A… nefungovalo to, protože jsme od backendů dostávali komprimovaný obsah, resp. subfilter nenašel požadovaný řetězec. Museli jsme přidat další lokální server v nginx, který dekomprimoval odpověď a předával ji dalšímu lokálnímu serveru, který se již zabýval výměnou řetězce, kompresí a dodáním jí dalšímu proxy serveru v řetězci.
Nakonec, kde klient obdržel <subdomain>.semrush.com, obdržel <subdomain>.semrushchina.cn a poslušně přešel přes naše řešení.
Nicméně, není dostatečné změnit doménu na jednu stranu, protože backendy stále očekávají semrush.com v následujících požadavcích od klienta. Tudíž, na stejném serveru, kde probíhá výměna na jednu stranu, pomocí jednoduchého regulárního výrazu získáváme subdoménu z požadavku a dále provádíme proxy_pass s proměnnou $host, nastavenou na $subdomain.semrush.com. Může se to zdát složité, ale funguje to. A funguje to dobře. Pro jednotlivé domény, které vyžadují jinou logiku, se jednoduše vytvářejí vlastní serverové bloky a provádí se zvláštní konfigurace. Níže jsou uvedeny zkrácené nginx konfigurace pro názornost a demonstraci tohoto schématu.
Následující konfigurace zpracovává všechny požadavky z Číny na .semrushchina.cn:
naslouchat 80;
server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;
sub_filter '.semrush.com' '.semrushchina.cn';
sub_filter_last_modified on;
sub_filter_once off;
sub_filter_types *;
gzip on;
gzip_proxied any;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
location / {
proxy_pass http://127.0.0.1:8083;
proxy_set_header Accept-Encoding "";
proxy_set_header Host $subdomain.semrush.com;
proxy_set_header X-Accept-Encoding $http_accept_encoding;
}
}Tento konfiguruje proxy na localhost portu 83, kde čeká další konfigurace:
naslouchat 127.0.0.1:8083;
server_name *.semrush.com;
location / {
resolver 8.8.8.8 ipv6=off;
gunzip on;
proxy_pass https://$host;
proxy_set_header Accept-Encoding gzip;
}
}Opakuji, to jsou zkrácené konfigurace.
Vypadá to asi tak. Může se to zdát složité, ale to jsou jen slova. Ve skutečnosti je to jednodušší než vařená řepa 🙂
Konec lyrického odbočení
Nějakou dobu jsme byli šťastní, protože mýtus o padání IPSEC tunelů se nepotvrdil. Ale pak začaly tunely padat. Několikrát denně po několik minut. Trochu, ale nám to nevyhovovalo. Protože oba tunely byly terminovány na straně Ali na jednom routeru, rozhodli jsme se, že to možná je regionální problém a je třeba zvednout záložní region.
Zvedli jsme ho. Tunely začaly padat v různých časech, ale failover na úrovni upstream v nginx fungoval skvěle. Ale pak začaly tunely padat zhruba současně 🙂 A znovu začaly 502 a 504. Uptime se zhoršoval, takže jsme začali vypracovávat variantu s Alibaba CEN (Cloud Enterprise Network).
CEN
CEN — je to konektivita dvou VPC z různých regionů v rámci Alibaba Cloud, tedy je možné propojit soukromé sítě jakýchkoli regionů uvnitř cloudu mezi sebou. A co je nejdůležitější: tento kanál má docela přísné SLA. Je velmi stabilní jak co do rychlosti, tak co do uptime. Ale nikdy to není tak jednoduché:
- je ho OPRAVDU obtížné získat, pokud nejste čínští občané nebo právnické osoby,
- za každý megabit šířky pásma kanálu se musí platit.
Když jsme se dostali k možnosti propojit Hlavní Čína a zámořské, vytvořili jsme CEN mezi dvěma regiony Ali: cn-shenzhen a us-east-1 (nejbližší bod k us-east4). V Ali us-east-1 jsme zvedli další virtuálku, abychom měli další hop.
Vyšlo to takto:
Výsledky prohlížečových testů níže:
Řešení
Uptime
Medián
75. percentile
95. percentile
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
Ukazatele jsou o něco lepší než u IPSEC. Ale přes IPSEC by teoreticky bylo možné stahovat rychlostí 100 Mbit/s, zatímco přes CEN pouze rychlostí 5 Mbit/s a je to dražší.
Hybrydní řešení se nabízí, že? Spojit rychlost IPSEC a stabilitu CEN.
Tak jsme to udělali, pustili jsme provoz jak přes IPSEC, tak přes CEN v případě pádu IPSEC tunelu. Uptime se značně zvýšil, ale rychlost načítání stránek zatím nebyla ideální. Tehdy jsem nakreslil všechny schémata, která jsme již používali a testovali, a rozhodl jsem se zkusit přidat do této schématu ještě trochu GCP, konkrétně GLB.
GLB
GLB — to je (nebo Google Cloud Load Balancer). Má pro nás důležité výhody: v kontextu CDN má anycast IP, což umožňuje směrovat provoz do nejbližšího datacentra k zákazníkovi, díky čemuž se provoz rychleji dostane do rychlé sítě Google a méně jde po „obyčejném“ internetu.
Nedlouho poté jsme nasadili HTTP/HTTPS LB v GCP a backendem jsme nastavili naše virtuální servery se subfilterem.
Bylo několik schémat:
- Použít Cloudflare China Network, ale tentokrát jsme jako originál uvedli globální IP GLB.
- Terminovat zákazníky v cn-shenzhen, a odtud směrovat provoz přímo do GLB.
- Jít přímo z Číny do GLB.
- Terminovat zákazníky v cn-shenzhen, odtud směrovat do asia-east1 přes IPSEC (přes us-east4 přes CEN), odtud už jít do GLB (klidně, níže bude obrázek a vysvětlení)
Otestovali jsme všechny tyto varianty a ještě několik hybridních:
- Cloudflare + GLB
Toto schéma nás neuspokojilo z hlediska uptime a DNS chyb. Ale test byl proveden před opravou chyby na straně CF, možná je nyní situace lepší (nicméně to nevy excludes HTTP time-outy).
- Ali + GLB
Toto schéma nás také neuspokojilo z hlediska uptime, protože GLB často vypadával z upstreamu kvůli nemožnosti navázat spojení v přijatelném čase nebo timeoutu, neboť pro server uvnitř Číny zůstává adresa GLB venku, což znamená, že je za čínským firewallem. Kouzlo se nekonalo.
- GLB only
Varianta podobná předchozí, jen v ní nebyly používány servery přímo v Číně: provoz šel rovnou do GLB (změnili jsme DNS záznamy). Odpovídající výsledky nás neuspokojily, protože u běžných čínských klientů, kteří využívají služby běžných internetových poskytovatelů, je situace s překonáváním firewallu mnohem horší než u Ali Cloud.
- Shenzhen -> (CEN/IPSEC) -> Proxy -> GLB
Zde jsme se rozhodli použít to nejlepší ze všech řešení:
- stabilitu a garantovaný SLA od CEN
- vysokou rychlost od IPSEC
- "rychlou" síť Googlu a jeho anycast.
Schéma vypadá zhruba takto: provoz uživatelů se terminován na virtuálním serveru v ch-shenzhen. Jsou zde nastaveny upstreamy nginx, z nichž některé odkazují na soukromé IP servery nacházející se na druhé straně IPSEC tunelu, a některé upstreamy na soukromé adresy serverů na druhé straně CEN. IPSEC byl nastaven do regionu asia-east1 v GCP (byl to nejbližší region k Číně v době vzniku řešení. Nyní má GCP také přítomnost v Hongkongu). CEN — do regionu us-east1 v Ali Cloud.
Dále byl provoz z obou konců směrován na anycast IP GLB, tedy na nejbližší bod přítomnosti Googlu, a putoval jeho sítěmi do regionu us-east4 v GCP, kde byly umístěny substituční virtuální stroje (s subfilter v nginx).
Toto hybridní řešení, jak jsme očekávali, umožnilo využít výhod každé technologie. Celkově provoz prochází rychlým IPSEC, ale pokud nastanou problémy, rychle a na několik minut vyřazujeme tyto servery z upstreamů a posíláme provoz pouze přes CEN, dokud se tunel nestabilizuje.
Implementací 4. řešení z výše uvedeného seznamu jsme dosáhli toho, co jsme chtěli, a co od nás podnik požadoval v té době.
Výsledky testů prohlížeče pro nové řešení ve srovnání s předchozími:
Řešení
Uptime
Medián
75. percentile
95. percentile
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
CEN/IPsec + GLB
99.79
13s
16s
25s
CDN
V námi implementovaném řešení je vše v pořádku, pouze chybí CDN, které by mohlo akcelerovat provoz na úrovni regionů a dokonce i měst. V ideálním případě by to mělo urychlit práci webu pro koncové uživatele díky využití rychlých komunikačních kanálů poskytovatele CDN. A o tom jsme neustále přemýšleli. A nyní nastal čas na další iteraci projektu: hledání a testování poskytovatelů CDN v Číně.
A o tom vám povím v následující, závěrečné části 🙂
Zdroj: habr.com
