Ahoj všichni!
Na spojení Nikita — systémový inženýr z firmy SEMrush. Dnes vám povím, jak jsme čelili úkolu zajistit stabilitu našich služeb semrush.com v Číně a jaké problémy jsme při plnění tohoto úkolu zažili (vzhledem k umístění našeho datového centra na východním pobřeží USA).
Bude to velký příběh rozdělený do několika článků. Řeknu, jak to všechno probíhalo u nás: od zcela nefunkční služby v Číně až po úroveň výkonu služby na úrovni její americké verze pro Američany. Slibuji, že to bude zajímavé a užitečné. Takže, jdeme na to.
Problémy čínského internetu
I ten nejvzdálenější člověk od specifik sítové administrace aspoň jednou slyšel o Velkém čínském firewallu. Uu, zní to skvěle, že? Ale co to je, jak to vlastně funguje — to je docela složitá otázka. Na internetu je možné najít spoustu článků věnovaných tomuto tématu, ale z technického hlediska je zařízení tohoto firewallu nikde popsáno. Což není překvapující. Přiznám se hned, po roce práce nebudu moct přesně říct, jak funguje, ale mohu vyprávět o svých pozorováních a praktických závěrech. A začneme se spekulacemi o tomto firewallu.
Existuje spousta spekulací o tomto firewallu. Pojďme shromáždit ty nejzásadnější a nejzajímavější do jednoho seznamu:
- Google, Facebook, Twitter a další podobné služby jsou zablokovány a nefungují v Číně.
- Jakýkoli provoz, který jde MIMO Čínu a DO Číny, je analyzován a omezen pomocí strojového učení (v případě podezřelého provozu), což výrazně zpomaluje jeho (provoz), když prochází hranicí.
- Čínské tajné služby rozbijí jakýkoli šifrovaný provoz, který prochází jejich firewallem.
- VPN tunely, IPSEC tunely jsou nestabilní, padají a neustále se blokují.
- Čím jednodušší šifrování, tím jednodušší pass phrase používaná pro autentikaci/šifrování provozu, tím rychleji prochází čínským firewallem.
To je to, co se nám podařilo zjistit o těchto spekulacích:
- Google, Facebook, Twitter a další podobné služby jsou skutečně zablokované (váš K.O.), ale mnoho technických domén Google, například, není zakázáno a funguje (třeba gstatic.com). Odtud vyplývá závěr: není třeba bez rozmyslu likvidovat všechny Google a jiné, zdánlivě zablokované, zdroje.
- Jakýkoliv provoz, který přechází hranici, skutečně přidává k času značný delay. Podívejte se na dva výsledky. Jedna stránka, jeden web, jednoduchý GET. curlPrvní měření z Číny (krásné město Šen-čen). Druhé měření zvenčí z Hongkongu (má suverenitu a mezi ním a světem není firewall). Vzdálenost mezi městy je přímá asi 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Celkem % Přijato % Xferd Průměrná rychlost Čas Čas Čas Aktuální
Dload Upload Celkem Stráveno Zbývá Rychlost
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Celkem % Přijato % Xferd Průměrná rychlost Čas Čas Čas Aktuální
Dload Upload Celkem Stráveno Zbývá Rychlost
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sVezměte na vědomí time_connect. A celkově vidíte výsledek: firewall přidává 4 zbytečné sekundy, což je ohromně dlouho.
- VPN a IPSEC tunely skutečně často padají. O tom budu hovořit později a podrobněji. VPN servery používané uživateli jsou v průběhu času blokovány (většinou během jednoho dne po zahájení používání).
- Existuje názor, získaný od lidí žijících v Číně, že čím jednodušší je šifrování provozu, tím rychleji prochází hranici, protože je snadné pochopit, že v něm není nic nezákonného. A stejně tak „čistý“ provoz dostává více šířky pásma a rychlosti, zatímco „špinavý“ provoz, ve kterém nic není rozlišitelné, má naopak pomalejší průchod. Pro příklad uvedu curl do ifconfig.co protokolem HTTPS a HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Celkem % Přijato % Xferd Průměrná rychlost Čas Čas Čas Aktuální
Dload Upload Celkem Stráveno Zbývá Rychlost
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Celkem % Přijato % Xferd Průměrná rychlost Čas Čas Čas Aktuální
Dload Upload Celkem Stráveno Zbývá Rychlost
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sRozdíl 5 sekund v celkovém čase načítání 13 bajtů. Při opakování testu lze pozorovat, že GET na HTTP končí prakticky vždy ve stejném čase, zatímco u HTTPS stránka někdy odpovídá za 3, 5, 10 a dokonce 17 sekund. Někdy se objevují chyby SSL:
Neznámá chyba SSL protokolu v připojení k ifconfig.co:443.
Takže, co máme:
- Problémy, které způsobuje čínská firewall, popsané výše.
- Pinky do externích zdrojů a uvnitř tunelů občas ztrácejí spojení.
- Latence mezi dvěma místy se neustále mění, často je prostě nepředvídatelná. Při spojování různých měst/regionů očekáváš, že na základě geografické polohy regionů bude zpoždění menší, ale dostáváš zcela opačnou situaci.
- Internet a komunikační kanály fungují jednou rychle, jednou pomalu. Existuje zde určitá závislost na denní době a dni v týdnu, ale ne vždy.
- DNS dotazy do externího světa z Číny občas překračují povolený timeout.
Obraz se rýsuje jako "vynikající".
Datové centrum, jak jsem již zmínil, máme na východě USA, a celý SEMrush se skládá z desítek vzájemně propojených produktů, backendů, frontendů, databází, a to vše v datovém centru a cloudech. Před námi, jako týmem systémových administrátorů, byla stanovena úloha s malými nároky rychle začít pracovat v Číně.
Museli jsme odpovědět na důležitou otázku: Je možné obejít se s malými nároky a vyřešit všechny problémy spojené s čínským internetem a firewallem na úrovni sítě/cloud/serverů?
Začali jsme získáním .
ICP-licence
Abychom mohli umístit naši službu v rámci Číny (pevninská Čína) a provádět testy, musíme nejprve získat ICP-licenci pro doménu.
Pokud je provoz vašeho webu terminován na území Mainland China a vaše doména nemá licenci ICP, bude váš provoz na straně poskytovatele/hostingu blokován. Zajímavé je, že do ICP licence je zapsán konkrétní poskytovatel, ať už je to Cloudflare nebo Alibaba Cloud. Proto, pokud jste získali ICP licenci pro Cloudflare a hostovali svůj web u nich, později se „bezešvě“ přemístit na Alibaba Cloud vám nebude možné. Budete muset do této licence přidat další hosting.
Získáním ICP licence na doménu jsme byli schopni vymýšlet a realizovat konkrétní technické nápady a řešení.
Testování řešení
Ale než se pustíme do vytváření variant stagingů, ladění a optimalizace webu a jeho rychlosti, je třeba vybrat nástroj pro jeho testování, abychom viděli, jaké naše kroky zlepšují nebo naopak zhoršují fungování webu.
Náš nástroj pro testování by měl splňovat dvě hlavní požadavky:
- musí mít možnost spouštět testy z Číny,
- musí mít prohlížečové testy.
Tak jsme našli ! Mají skvělé pokrytí testovacími body po celém světě. V Číně lze pomocí tohoto nástroje spouštět testy také z 100500 provincií. V každé z nich je několik různých poskytovatelů + možnost provádět Backbone-testy (něco jako virtuální stroj v datacentru) a Lastmile-testy (maximálně se blížící podmínkám uživatelů, aka pracovní stanice). Poslední typ testů je dražší.
Uzavřením roční smlouvy (méně nelze) jsme se pustili do studování nástroje. Přiznám se, že jsme byli příjemně překvapeni jeho funkcionalitou. Lze spouštět:
- DNS testy,
- Web testy (prohlížečové, jednoduché GET/POST, simulace mobilního klienta atd.),
- Transakční ověření (například přihlášení),
- API testy,
- Ping, traceroute, NTP atd.
Všechno se nedá vyjmenovat. A co je nejdůležitější, každý test lze poměrně dobře přizpůsobit, přidáním balíčku hlaviček a dalších parametrů. Výsledkem je obrovské množství informací, které plně popisují váš test. Pokud jde o to, co je pro nás nejzajímavější (prohlížečové testy), výsledek zahrnuje:
- Connect, Wait, Load, SSL, DNS time,
- TTFB, TTLB, Document complete, Render time, DOM load,
- Response (něco blízkého k Time To First Byte), Webpage Response (něco blízkého k Time To Last Byte),
- Jakékoliv percentile, Average, Median time
- A tak dále.
Tyto metriky nám skvěle pomáhají vidět změny a pochopit, zda došlo ke zlepšení. V podstatě jsme se zaměřili na Response, Webpage Response, Median, 75 a 95 Percentiles.
Důležitá otázka, která visela ve vzduchu od samého začátku: můžeme věřit Catchpoint?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
To je velký problém, protože v Rusku je prakticky nemožné přesně zjistit, jak fungují webové stránky z Číny. Při použití socks-proxy na virtuálním stroji trvá načtení stránky několik minut, což je pro testování naprosto nepřijatelné, takže jedinou možností ručního testování zůstává curl a jednoduché GET z konzole s měřením času. Tento test je užitečný, protože dobré odráží rychlost síťového řešení, a pokud máme i prohlížečové testy, je to ještě lepší.
Později jsme sami cestovali do Číny a ujistili se, že Catchpoint může být důvěryhodný, poměrně přesně odráží skutečné rychlosti.
Cloudflare China Network
Jelikož pro hlavní doménu semrush.com úspěšně používáme Cloudflare, rozhodli jsme se okamžitě vyzkoušet jejich funkci zvanou . Tato možnost je aktivována pouze pro enterprise stránky na zvláštní žádost a za zvláštní poplatek. Také je dostupná pouze pro weby, které mají odpovídající ICP licenci, kde jako poskytovatel je uveden Cloudflare. Po jejím aktivaci se pro web stává dostupný "čínský CDN" od Cloudflare - provoz z čínských regionů je směrován do nejbližších PoP (Points of Presence) CF, a poté je distribuován jeho sítěmi nebo sítěmi poskytovatelů/partnerů k originu.
Schéma tohoto testovacího stánku je uvedeno níže.
Pro nás je to skvělá volba. Tímto se druhý domén bude také chráněn Cloudflare, což nezvyšuje počet řešení používaných ve firmě a téměř nekomplikuje infrastrukturní strukturu.
Spustili jsme prohlížečové testy a zde jsou výsledky:
Červené kosočtverce znamenají selhání testů. Selhání dole jsou DNS chyby (časový limit překladu). Selhání nahoře jsou časové limity.
Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s
Medián se po odstranění zatížení reCaptcha (služba od Googlu, která je v Číně zablokována), snížil z 28 na 18 sekund. Ale stále to jsou hrozné hodnoty, když vezmeme v úvahu, že stejný test pro semrush.com (ze Spojených států) měl méně než 10 sekund pro 95 % uživatelů (ze Spojených států) na tu samou stránku (statika + dynamika).
Do každého testu se lze přihlásit a prohlédnout si ho Waterfall a další podrobnější parametry. Začali jsme zkoumat příčiny chyb, a pokud je ohledně timeoutů situace víceméně jasná: internet v Číně se "to skládá, to rozkládá", kvůli čemuž je rychlost připojení a načítání zdrojů ze zahraničí nestabilní a různá, tak nás DNS chyby značně překvapily. Zjistili jsme, že PoP u Cloudflare skutečně nacházejí v Číně, adresa webu se převádí na jeden anycast IP, ale používají se americké DNS servery, což znamená, že DNS dotazy musí procházet hranicí, proto někdy selhávají.
Po upřesnění této otázky u CF se ukázalo, že nemají vlastní DNS servery v Číně, a kdy budou — zatím není známo.
Proto jsme se rozhodli testovat pouze DNS Cloudflare a změnili jsme mechanismus fungování Cloudflare pro naši stránku na režim “Pouze DNS”. To je takový režim, kdy Cloudflare neprošuje provoz přes sebe, a tedy neposkytuje DDoS ochranu, CDN a další funkce, a pracuje v režimu běžného DNS serveru.
Tento stand je schematicky znázorněn na následujícím obrázku. Na obrázku jsou zohledněny nově získané znalosti o tom, že DNS servery Cloudflare jsou za firewallem.
V Catchpoint jsme spustili jednoduché GET testy (ne prohlížečové), které ukázaly spoustu selhání. Příčinou jich byly stále ty samé DNS chyby.
Začali jsme ladit tyto chyby pomocí dig a zjistili jsme, že při prvním dotazu je adresa určena správně, ale při opakovaném dotazu dostáváme pokaždé SERVFAIL a nenalezeno. Odkud se to vzalo?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn má adresu 220.170.186.192
Host semrushchina.cn nenalezen: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn má adresu 220.170.186.192
Host semrushchina.cn nenalezen: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn má adresu 220.170.186.192
Host semrushchina.cn nenalezen: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn má adresu 220.170.186.192
Host semrushchina.cn nenalezen: 2(SERVFAIL)Při přímém dotazu na NS servery Cloudflare takové chyby nejsou:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Používám server domény:
Název: ray.ns.cloudflare.com.
Adresa: 173.245.59.138#53
Alias:
semrushchina.cn má adresu 220.170.186.192
semrushchina.cn má adresu 220.170.186.192
Používám server domény:
Název: ray.ns.cloudflare.com.
Adresa: 173.245.59.138#53
Alias:
semrushchina.cn má adresu 220.170.186.192
semrushchina.cn má adresu 220.170.186.192Takže problém je na straně "lokálního" DNS serveru nebo serveru poskytovatele.
Další vyšetřování ukázalo, že SERVFAIL na rozlišení dostáváme AAAA-záznamy.
Zjistilo se, že při dotazu u Cloudflare AAAA-záznam, který v doméně neexistuje, Cloudflare odpovídal A-záznamem, což je chyba a nesoulad s RFC. Z tohoto důvodu to místnímu resolveru (x.x.x.x) se nelíbilo a odpovídal SERVFAIL. V níže uvedeném protokolu je toto chování jasně vidět:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @x.x.x.x
;; globální možnosti: +cmd
;; Dostáváme odpověď:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; příznaky: qr rd ra; DOTAZ: 1, ODPOVĚĎ: 0, AUTORITY: 0, PŘIDANÉ: 1
;; OPT PSEUDOSECTION:
; EDNS: verze: 0, příznaky:; udp: 4096
;; OTÁZKOVÁ SEKCE:
;semrushchina.cn. IN AAAA
;; Čas dotazu: 334 ms
;; SERVER: x.x.x.x#53(x.x.x.x)
;; KDY: Út 14. srpna 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; globální možnosti: +cmd
;; Dostáváme odpověď:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; příznaky: qr aa rd; DOTAZ: 1, ODPOVĚĎ: 1, AUTORITY: 0, PŘIDANÉ: 1
;; UPOZORNĚNÍ: vyžadována rekurze, ale není dostupná
;; OPT PSEUDOSECTION:
; EDNS: verze: 0, příznaky:; udp: 512
;; OTÁZKOVÁ SEKCE:
;semrushchina.cn. IN AAAA
;; ODPOVĚĎ SEKCE:
semrushchina.cn. 300 IN A 220.170.186.192
;; Čas dotazu: 185 ms
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; KDY: Út 14. srpna 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Odeslali jsme bug report Cloudflare a oni to opravili po nějaké době. Ukázalo se, že je to zajímavé: v tuto chvíli v Číně stále není podpora IPv6, takže Cloudflare nemohl při odpovědi na požadavek poskytnout svou IPv6 adresu AAAA-záznamů. Nakonec se to vyřešilo tak, že pro Čínu začal Cloudflare odpovídat NODATA na takové požadavky.
Takže chyby DNS v testech Catchpoint se výrazně snížily, ale ne zcela. Časové limity také nezmizely:
A začali jsme hledat jiné řešení.
V další části vám povím, jak jsme testovali čínské cloudové služby Alibaba Cloud, jak pomocí malé „kouzla“ Nginx jsme mohli rychle vytvářet PoC (Proof of Concept) řešení, jak jsme vytvářeli Multi-Cloud řešení, z nichž jedno nám nakonec velmi pomohlo urychlit provoz služby z Číny.
Zůstaňte na příjmu!
Další části
Zdroj: habr.com
