Ahoj všetci!
Nikita je v kontakte - systémový inžinier zo spoločnosti SEMrush. Dnes vám poviem o tom, ako sme čelili úlohe zabezpečiť stabilitu našej služby semrush.com v Číne a s akými problémami sme sa stretli pri jej implementácii (vzhľadom na polohu nášho dátového centra na východnom pobreží Spojených štátov amerických).
Toto bude veľký príbeh rozdelený do niekoľkých článkov. Poviem vám, ako sa to všetko stalo pre nás: od úplne nefunkčnej služby z Číny až po ukazovatele výkonu služby na úrovni jej americkej verzie pre Američanov. Sľubujem, že to bude zaujímavé a užitočné. Tak, poďme.
Problémy čínskeho internetu
Počul o tom aj ten najvzdialenejší od špecifík správy siete Veľký čínsky firewall. Wow, znie to cool, však? Ale čo to je a ako to vlastne funguje, je pomerne komplikovaná otázka. Na internete nájdete veľa článkov, ktoré sa tomu venujú, ale z technického hľadiska nie je štruktúra tohto firewallu nikde popísaná. Čo však nie je prekvapujúce. Hneď sa priznám, že na základe výsledkov ročnej práce nebudem môcť presne povedať, ako to funguje, ale môžem vám povedať o svojich komentároch a praktických záveroch. A začneme fámami o tomto firewalle.
O tomto firewalle koluje veľa povestí. Poďme zhromaždiť hlavné a najzaujímavejšie z nich do jedného zoznamu:
- Google, Facebook, Twitter a ďalšie podobné služby sú v Číne zablokované a nefungujú.
- Akákoľvek premávka smerujúca MIMO Čínu a DO Číny je analyzovaná a obmedzená pomocou strojového učenia (v prípade podozrivej dopravy), čo výrazne spomaľuje jej (premávku) prechádzajúcu hranicou.
- Čínske spravodajské agentúry hacknú všetku šifrovanú komunikáciu prechádzajúcu cez ich firewall.
- Tunely VPN, tunely IPSEC sú nestabilné, padajú a sú neustále blokované.
- Čím jednoduchšie je šifrovanie, čím jednoduchšia je heslová fráza použitá na overenie/šifrovanie prevádzky, tým rýchlejšie prejde čínskym firewallom.
Tu je to, čo sme zistili o týchto povestiach:
- Google, Facebook, Twitter a ďalšie podobné služby sú skutočne zablokované (vaše KO), ale napríklad mnohé technické domény Google nie sú zakázané a fungujú (rovnako gstatic.com). Z toho vyplýva záver: nemali by ste bezohľadne vypínať všetky zdroje Google a ďalšie zdroje, ktoré sa zdajú byť zablokované.
- Akákoľvek premávka prechádzajúca hranicou skutočne pridáva na čas vážne zdržanie. Pozrite sa na dva výsledky. Jedna stránka, jedna stránka, jednoduchý GET curlom. Prvé meranie bolo zo samotnej Číny (krásne mesto Shenzhen). Druhý bol meraný zvonku z Hongkongu (má suverenitu a medzi ním a svetom nie je žiadna brána). Vzdialenosť medzi mestami v priamej línii je približne 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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/sVenujte pozornosť time_connect. A vo všeobecnosti vidíte výsledok: firewall pridá 4 sekundy navyše, čo je neuveriteľne dlho.
- Tunely VPN a IPSEC často zlyhávajú. Budem o tom hovoriť trochu neskôr a podrobnejšie. Servery VPN, ktoré používajú používatelia, sú časom (zvyčajne do jedného dňa od začiatku používania) blokované.
- Od ľudí žijúcich v Číne existuje názor, že čím jednoduchšie je šifrovanie dopravy, tým rýchlejšie prechádza cez hranice, pretože je ľahké pochopiť, že na tom nie je nič nezákonné. A rovnako „čistá“ prevádzka dostáva väčšiu šírku pásma a rýchlosť prechodu, zatiaľ čo „špinavá“ prevádzka, v ktorej sa ničomu nedá rozumieť, má, naopak, pomalší prechod. Napríklad použijem curl to ifconfig.co cez HTTPS a HTTP protokol.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
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/sRozdiel 5 sekúnd pri celkovom čase sťahovania 13 bajtov. Okrem toho, keď robíte takýto test niekoľkokrát, môžete si všimnúť, že GET na HTTP sa dokončí vo všeobecnosti vždy v rovnakom čase, zatiaľ čo na HTTPS stránka niekedy odpovie za 3, 5, 10 a dokonca 17 sekúnd. Niekedy sa vyskytnú chyby protokolu SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Čo teda máme:
- Problémy spôsobené čínskym firewallom sú popísané vyššie.
- Pingy na externé zdroje a vnútorné tunely pravidelne miznú.
- Latencia medzi dvoma bodmi sa neustále mení a často je jednoducho nepredvídateľná. Pri spájaní rôznych miest/regiónov očakávate, že na základe geografickej polohy regiónov bude meškanie menšie, no dostanete presne opačnú situáciu.
- Internet a komunikačné kanály sú buď rýchle alebo pomalé. Existuje mierna závislosť od dennej doby a dňa v týždni, ale nie vždy.
- Požiadavky DNS do vonkajšieho sveta z Číny niekedy prekračujú povolený časový limit.
Obraz, ktorý sa objaví, je jednoducho „výborný“.
Dátové centrum, ako som už povedal, je na východe USA a celý SEMrush pozostáva z desiatok vzájomne prepojených produktov, backendov, frontendov, databáz a to všetko v DC a cloudoch. My ako tím systémových administrátorov sme dostali za úlohu rýchlo začať pracovať v Číne s malým úsilím.
Museli sme odpovedať na dôležitú otázku: je možné zaobísť sa s malými nákladmi a vyriešiť všetky problémy spojené s čínskym internetom a firewallom na úrovni sieť/cloud/server?
Začali sme prijímaním .
licencia ICP
Aby ste mohli hostiť svoju službu v Číne (pevninská Čína) a vykonávať testy, musíte najprv získať licenciu ICP pre doménu.
Ak je návštevnosť vašich stránok ukončená v rámci pevninskej Číny a ak vaša doména nemá licenciu ICP, vaša návštevnosť bude zablokovaná na strane ISP/hostingu. Zaujímavosťou je, že licencia ICP zahŕňa konkrétneho poskytovateľa, či už je to Cloudflare alebo Alibaba Cloud. Preto, ak ste dostali licenciu ICP pre Cloudflare a hostili ste s nimi svoju webovú stránku, nebudete môcť „bezproblémovo“ prejsť na Alibaba Cloud. K tejto licencii budete musieť pridať ďalší hosting.
Po získaní ICP licencie na doménu sme boli schopní vymyslieť a zrealizovať konkrétne technické nápady a riešenia.
Testovacie riešenia
Ale predtým, ako priamo vytvoríte možnosti inscenácie, otáčate gombíkmi, optimalizujete výkon stránky a jej rýchlosť, musíte si vybrať nástroj na jej testovanie, aby ste videli, ktoré z našich akcií zlepšujú alebo naopak zhoršujú výkon stránky.
Náš testovací nástroj musel spĺňať dve hlavné požiadavky:
- mala by byť schopná vykonávať testy z Číny,
- musí mať testy prehliadača.
Tak sme našli ! Majú vynikajúce pokrytie testovacích miest po celom svete. V Číne je možné prostredníctvom tohto nástroja spustiť testy aj zo 100500 XNUMX provincií. Každý má niekoľko rôznych poskytovateľov + možnosť robiť chrbtica-testy (niečo ako virtuálny stroj v dátovom centre) a Posledná míľa-testy (čo najbližšie k užívateľským podmienkam, aka pracovná stanica). Posledný typ testov je drahší.
Po uzavretí ročnej zmluvy (menej ako to nie je možné) sme začali študovať nástroj. Úprimne povedané, boli sme príjemne prekvapení jeho funkčnosťou. Môžete spustiť:
- DNS testy,
- Webové testy (testy prehliadača, jednoduché GET/POST, emulácia mobilného klienta atď.),
- transakčné kontroly (napríklad prihlásenie),
- API testy,
- Ping, traceroute, NTP atď.
Nemôžete vymenovať všetko. A čo je najdôležitejšie, každý test sa dá celkom dobre prispôsobiť pridaním hromady hlavičiek a iných parametrov. Výstupom je obrovské množstvo informácií, ktoré plne vystihujú váš test. Ak hovoríme o pre nás najzaujímavejších veciach (testy prehliadača), výsledok zahŕňa:
- Pripojiť, čakať, načítať, SSL, čas DNS,
- TTFB, TTLB, Dokument je dokončený, Čas vykreslenia, Načítanie DOM,
- Response (niečo blízke Time To First Byte), Webpage Response (niečo blízke Time To Last Byte),
- Akýkoľvek percentil, priemer, stredný čas
- Atď.
Preto sú všetky tieto metriky skvelé na to, aby ste videli zmeny a pochopili, či sa veci zlepšili. Hlavne sme sa pozerali Odpoveď, odozva webovej stránky, medián, 75 a 95 percentilov.
Dôležitá otázka, ktorá bola vo vzduchu od samého začiatku: Môžete dôverovať Catchpointu?? Odráža tento nástroj skutočnú rýchlosť načítania stránok v Číne z rôznych miest, alebo je to len nejaký druh testu vo vzduchoprázdne, ktorý nemá nič spoločné so skutočnými používateľskými skúsenosťami?
Je to veľký problém, pretože v Rusku je takmer nemožné spoľahlivo zistiť, ako funguje stránka z Číny. Uskutočnením socks-proxy cez virtuálny stroj je konečným výsledkom, že stránka sa načíta v priebehu niekoľkých minút, čo je pre testy jednoducho neprijateľné, takže jedinou možnosťou manuálneho testovania je zvlnenie a jednoduché GET z konzoly pomocou časovača. . Pomáha to, pretože tento test dobre odráža rýchlosť sieťového riešenia a ak existujú aj testy prehliadača, je to veľmi dobré.
Neskôr sme sami išli do Číny a boli sme o tom presvedčení Catchpointu môžete dôverovať, celkom presne odráža skutočné ukazovatele výkonu.
Cloudflare China Network
Keďže Cloudflare úspešne používame pre hlavnú doménu semrush.com, rozhodli sme sa ihneď vyskúšať ich funkciu tzv . Táto možnosť je povolená len pre podnikové lokality na samostatnú žiadosť a za príplatok. Je tiež k dispozícii iba pre stránky, ktoré majú príslušnú licenciu ICP, ktorá uvádza Cloudflare ako poskytovateľa. Po jeho povolení sa pre stránku sprístupní „čínske CDN“ od Cloudflare – návštevnosť z čínskych regiónov pristane na najbližšom PoP (Points of Presence) CF a potom sa prostredníctvom svojich sietí alebo sietí poskytovateľov/partnerov doručí do pôvodu. .
Schéma tejto testovacej stolice je uvedená nižšie.
Toto je pre nás skvelá možnosť. Ukazuje sa, že druhá doména bude aj pre CF, čo nepridáva na počte riešení používaných vo firme, a tiež prakticky nekomplikuje infraštruktúru.
Spustili sme testy prehliadača a stalo sa toto:
Červené diamanty sú zlyhania testu. Nižšie uvedené súbory sú chyby DNS (časový limit riešenia). Zlyhania v hornej časti sú časové limity.
Prevádzková doba: 86.6
Medián: 18 s
75 percentil: 29.3 s
95 percentil: 60 s
Medián, po odstránení načítania reCAPTCHA (služba Google zablokovaná v Číne) sa znížila z 28 na 18 sekúnd. Ale stále sú to hrozné výsledky, ak vezmeme do úvahy, že rovnaký test pre semrush.com (z USA) dal menej ako 10 sekúnd pre 95 % používateľov (z USA) na tej istej stránke (statická + dynamická).
Môžete ísť do každého testu a pozrieť sa Vodopád a ďalšie podrobnejšie parametre. Začali sme skúmať príčiny chýb, a ak je pre časové limity všetko viac-menej jasné: internet v Číne sa „sťahuje a odchádza“, z tohto dôvodu je rýchlosť pripojenia a načítania zdrojov zo zahraničia nestabilná a nerovnomerná, potom nás chyby DNS veľmi prekvapili. Zistili sme to Po Cloudflare sa v skutočnosti nachádza v Číne, adresa stránky sa prekladá na jednu IP adresu anycast, ale servery DNS sú americké, a preto sú požiadavky DNS nútené ísť cez hranice, takže niekedy zlyhajú.
Po objasnení tejto otázky s CF sa ukázalo, že V Číne nemajú svoje vlastné servery DNS, a kedy to bude, zatiaľ nie je známe.
Preto sme sa rozhodli otestovať iba Cloudflare DNS a zmenili sme operačný mechanizmus Cloudflare pre našu stránku na „Iba DNS" Toto je režim, keď Cloudflare neprenáša cez seba proxy, čo znamená, že neposkytuje ochranu DDoS, CDN a ďalšie funkcie a funguje v režime bežného servera DNS.
Tento stojan je schematicky znázornený na nasledujúcom obrázku. Obrázok zohľadňuje nové poznatky, že servery DNS spoločnosti Cloudflare sú za bránou firewall.
V Catchpointe sme spustili jednoduché testy GET (nie testy prehliadača), ktoré ukázali veľa zlyhaní. Boli spôsobené rovnakými chybami DNS.
Tieto chyby sme začali ladiť pomocou kopať a zistili sme, že pri prvej žiadosti je adresa určená správne a pri opakovanej žiadosti zakaždým dostaneme SERVFAIL и nenájdené. Prečo sa to zrazu deje?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Pri priamom dopytovaní serverov Cloudflare NS k takýmto chybám nedochádza:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192To znamená, že problém je na strane „miestneho“ servera DNS alebo servera poskytovateľa.
Odhalilo to ďalšie vyšetrovanie SERVFAIL dohodneme sa AAAA- záznamy.
Ukázalo sa, že pri vyžiadaní od Cloudflare AAAA-záznam, ktorý v doméne neexistuje, odpovedal Cloudflare А-položka, ktorá je chybou a nie je v súlade s RFC. Prečo lokálny prekladač (xxxx) Nepáčilo sa mi to a on odpovedal SERVFAIL. Toto správanie je jasne viditeľné v nižšie uvedenom protokole:
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
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 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.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Cloudflare sme poslali hlásenie o chybe a oni to po nejakom čase opravili. Ukázalo sa to ako zaujímavé: v súčasnosti v Číne stále neexistuje podpora IPv6, takže Cloudflare tam nemohol vydať svoju IPv6 adresu ako odpoveď na žiadosť AAAA- záznamy. Nakoniec sa všetko vyriešilo tak, že Cloudflare sa začal zodpovedať za Čínu ŽIADNE DÁTA na takéto žiadosti.
Chyby DNS v testoch Catchpoint sa teda výrazne znížili, ale nie úplne. Časové limity sú stále tu:
A začali sme hľadať iné riešenie.
V ďalšej časti vám poviem, ako sme testovali čínsky cloud Alibaba Cloud, ako sme s pomocou malej „kúzla“ Nginxu dokázali rýchlo vytvoriť PoC (Proof of Concept) riešenia, ako sme vytvorili Multi-Cloud riešenia, z ktorých jedno v konečnom dôsledku výrazne pomohlo urýchliť prácu služby z Číny.
Zostaňte naladení!
Ďalšie diely
Zdroj: hab.com
