Mindenkinek szia!
Csatlakozott Nikita – a cég rendszermérnöke SEMrush. Ma arról fogok mesélni, hogyan állt előttünk a feladat, hogy biztosítsuk a semrush.com szolgáltatásának stabil működését Kínában, és milyen problémákkal szembesültünk ennek végrehajtása során (figyelembe véve adatközpontunk elhelyezkedését az Egyesült Államok keleti partján).
Ez egy nagy történet lesz, több cikkre bontva. Elmondom, hogyan is volt ez nálunk: a teljesen működésképtelen szolgáltatástól kezdve Kínából, egészen a szolgáltatás amerikai verzióval egy szinten lévő teljesítményeiig az amerikai felhasználók számára. Ígérem, érdekes és hasznos lesz. Tehát, vágjunk bele.
A kínai internet problémái
Még a legkevésbé a hálózati adminisztrációval foglalkozó ember is hallott legalább egyszer a Nagy Kínai Tűzfalról. Hűha, mennyire menő, igaz? De mi is ez valójában, hogyan működik – ez egy meglehetősen bonyolult kérdés. Az interneten sok írni való található erről, de technikai szempontból ezt a tűzfalat sehol sem írják le. Ami nem meglepő. Bevallom, hogy az év végére én sem tudom pontosan, hogyan működik, de el tudom mondani a megfigyeléseimet és gyakorlati következtetéseimet. Tehát kezdjük a tűzfalkal kapcsolatos pletykákkal.
Sok pletyka kering erről a bizonyos tűzfalról. Gyűjtsük össze a legfontosabb és legérdekesebbakat egy listába:
- A Google, a Facebook, a Twitter és hasonló szolgáltatások blokkolva vannak, és nem működnek Kínában.
- Minden forgalom, amely Kínán kívülre és Kínába megy, gépi tanulással elemzésre kerül és korlátozásra kerül (gyanús forgalom esetén), ami jelentősen lelassítja azt (a forgalmat), amely áthalad a határon.
- A kínai titkosszolgálatok feltörik bármilyen titkosított forgalmat, amely áthalad a tűzfalukon.
- A VPN-alagutak, az IPSEC-alagutak instabilak, elfogynak és rendszeresen blokkolva vannak.
- Minél egyszerűbb a titkosítás, annál egyszerűbb a jelszó, amelyet a forgalom azonosítására/ titkosítására használnak, annál gyorsabban halad át a kínai tűzfalon.
Mit tudtunk meg ezekről a pletykákról:
- A Google, a Facebook, a Twitter és hasonló szolgáltatások valóban blokkolva vannak (az Ön KÖ), de sok technikai Google domain, például nem tiltott és működik (ugyanaz a gstatic.com). Így következik a következtetés: nem érdemes gondolkodás nélkül eltávolítani minden esetlegesen blokkolt Google- és egyéb erőforrást.
- Bármely forgalom, amely átlépi a határt, valóban jelentős késést okoz. Nézze meg a két eredményt. Egy weboldal, egy oldal, egyszerű GET. curlAz első mérés Kínából (gyönyörű Shenzhen városából) történt. A második mérés Hongkongból kívülről (annak szuverenitása van, és nincs tűzfal a kettő között). A városok közötti távolság egyenes vonalban körülbelül 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Teljes % Fogadott % Átvitt Átlagos Sebesség Idő Idő Idő Jelenlegi
Letölt Feltölt Összes Elöltött Hátralevő Sebesség
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
----------
letöltési méret: 390968 Byte
letöltési sebesség: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Teljes % Fogadott % Átvitt Átlagos Sebesség Idő Idő Idő Jelenlegi
Letölt Feltölt Összes Elöltött Hátralevő Sebesség
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
----------
letöltési méret: 326755 Byte
letöltési sebesség: 2616740.000B/sKérjük, vegye figyelembe time_connect. És általában a következtetés: a tűzfal 4 extra másodpercet ad hozzá, ami borzalmasan hosszú.
- A VPN- és IPSEC-alagút kapcsolatok valóban gyakran megszakadnak. Erről később részletesebben beszélek. A felhasználók által használt VPN-szerverek idővel letiltásra kerülnek (általában 24 órán belül, miután elkezdődött a használatuk).
- Van egy vélemény, amelyet Kínában élő emberektől hallottam, hogy minél egyszerűbb a forgalom titkosítása, annál gyorsabban halad át a határon, mert könnyen érthető, hogy nincs benne semmi illegális. Ugyanígy a „tiszta” forgalom nagyobb sávszélességet és sebességet kap, míg a „piszkos” forgalom, amelyet nem lehet azonosítani, éppen ellenkezőleg, lassabb átjárást kap. Példaként említeném a curl-t a ifconfig.co protokollal a HTTPS és HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Teljes % Fogadott % Xferd Átlagos Sebesség Idő Idő Idő Jelenlegi
Letöltés Feltöltés Összes Elköltött Maradék Sebesség
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/"
% Teljes % Fogadott % Xferd Átlagos Sebesség Idő Idő Idő Jelenlegi
Letöltés Feltöltés Összes Elköltött Maradék Sebesség
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/sÖt másodperces eltérés a 13 byte letöltési időben. Ha ezt a tesztet többször elvégezzük, észlelhetjük, hogy a GET kérés HTTP-n általában azonos idő alatt fejeződik be, míg HTTPS alatt a webhely válasza néha 3, 5, 10 vagy akár 17 másodpercet is igénybe vehet. Néha SSL hibák is előfordulnak:
Ismeretlen SSL protokoll hiba a kapcsolatban ifconfig.co:443.
Tehát, mit is kapunk:
- A fentebb említett kínai tűzfal által okozott problémák.
- Pingek külső forrásokhoz és a tunnelen belül időnként eltűnnek.
- A késleltetés két pont között folyamatosan változik, és gyakran egyszerűen kiszámíthatatlan. Különböző városok/régiók összekapcsolásakor várnád, hogy a régiók földrajzi elhelyezkedése alapján a késleltetés csökken, de pont ellenkező eredményt kapunk.
- Az internet és a kommunikációs csatornák néha gyorsan, néha lassan működnek. Itt van egy kis függés az időponttól és a hét napjától, de nem mindig.
- A DNS-kérések a külső világ felé Kínából néha meghaladják a megengedett időkorlátot.
A kép egyszerűen 'kitűnő'.
A központunk, ahogy már említettem, az Egyesült Államok keleti partján található, és a SEMrush több tucat kölcsönösen összekapcsolt termékből, backendből, frontendből, adatbázisból áll, mindezek a központban és felhőkben vannak. Rendszergazdaként a csapatunknak az volt a feladata, hogy minimális erőfeszítéssel gyorsan elkezdjünk dolgozni Kínában.
Meg kellett válaszolnunk egy fontos kérdést: Meg lehet-e oldani a kínai internettel és tűzfallal kapcsolatos problémákat a hálózat/felhők/szerverek szintjén minimális erőfeszítéssel?
Kezdtünk azzal, hogy .
ICP engedély
Ahhoz, hogy lehetőségünk legyen szolgáltatásunk elhelyezésére Kínában (Mainland China) és teszteket végezhessünk, először meg kell szereznünk az ICP engedélyt a domainhez.
Ha a webhelye felhasználói forgalma Kínában belül ér véget, és a domainje nem rendelkezik ICP engedéllyel, akkor a forgalma blokkolva lesz a szolgáltatónál / hosztnál. Érdekes, hogy az ICP engedélybe egy konkrét szolgáltató kerül, legyen az Cloudflare vagy Alibaba Cloud. Tehát, ha ICP engedélyt kapott a Cloudflare-től, és ott helyezte el a weboldalát, akkor a jövőben nem tud "zökkenőmentesen" átállni az Alibaba Cloudra. További hostingot kell hozzátennie ehhez az engedélyhez.
Miután megszereztük az ICP engedélyt a domainünkre, elkezdhettük kidolgozni és megvalósítani a konkrét technikai ötleteinket és megoldásainkat.
Megoldások tesztelése
De mielőtt közvetlenül létrehoznánk a staging variansokat, finomhangolnánk a weboldal működését és sebességét, ki kell választanunk az eszközt a teszteléshez, hogy láthassuk, mely lépéseink javítják, vagy éppen ellenkezőleg, rontják a weboldal teljesítményét.
A tesztelési eszközünknek megfelelt két fő követelménynek:
- lehetővé kell tennie a tesztek futtatását Kínából,
- továbbá böngészős teszteket kell biztosítania.
Így találtunk rá ! Kiváló tesztelő pontok lefedettsége van világszerte. Kínában ezen az eszközön keresztül teszteket lehet futtatni 100500 tartományból is. Mindegyik tartományban több különböző szolgáltató, valamint lehetőség van Backbone-tesztekre (valami hasonló a felhőalapú virtualizációhoz), és Lastmile-tesztekre (maximálisan a felhasználói körülményekhez közel, azaz munkaállomás). Az utolsó teszt típusa drágább.
Éves szerződést kötve (kisebbet nem lehet) elkezdtük tanulmányozni az eszközt. Be kell vallanom, kellemesen meglepődtem a funkcionalitásán. Futtathatók:
- DNS-tesztek,
- Web-tesztek (böngészők, egyszerű GET/POST, mobil kliens emuláció stb.),
- Tranzakciós ellenőrzések (például bejelentkezés),
- API-tesztek,
- Ping, traceroute, NTP stb.
Összességében nem lehet mindent felsorolni. És ami a legfontosabb, minden tesztet meglehetősen jól testreszabhatunk, akár egy csomó fejlécet és más paramétert is hozzáadva. Az eredmény hatalmas mennyiségű információ, amely teljesen lefedi a tesztünket. Ha a számunkra legérdekesebbre (böngészős tesztek) gondolunk, az eredmény tartalmazza:
- Kapcsolódási idő, Várakozási idő, Betöltési idő, SSL, DNS idő,
- TTFB, TTLB, Dokumentum kész, Renderelési idő, DOM betöltés,
- Válasz (valami hasonló a Time To First Byte-hoz), Weboldal Válasz (valami hasonló a Time To Last Byte-hoz),
- Bármely percentilis, Átlag, Medián idő
- stb.
Így minden ilyen metrikák kiválóan segítenek észlelni a változásokat és megérteni, hogy javult-e a helyzet. Főleg a következőkre figyeltünk: Válasz, Weboldal Válasz, Medián, 75 és 95 Percentilis.
Fontos kérdés, ami a kezdetektől fogva a levegőben lóg: bízni lehet a Catchpointban?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Ez komoly probléma, mert Oroszországból majdnem lehetetlen megbízhatóan megállapítani, hogyan működik egy webhely Kínából. Ha SOCKS-proxyt állítunk be egy virtuális gépen, a webhely betöltése pár percet vesz igénybe, ami teszteléshez egyszerűen elfogadhatatlan, ezért az egyetlen lehetőség a manuális tesztelésre a curl és egyszerű GET parancsok a konzolban, időméréssel. Ez segít, mert ez a teszt jól tükrözi a hálózati megoldás sebességét, és ha van még böngészős teszt is, az teljesen jó.
Később magunk is ellátogattunk Kínába, és meggyőződtünk arról, hogy a Catchpointba lehet bízni, pontosan tükrözi a valós sebességadatokat.
Cloudflare Kína Hálózat
Mivel a fő domain, a semrush.com sikeresen használja a Cloudflare-t, úgy döntöttünk, hogy azonnal kipróbáljuk a neve alatt futó funkciót . Ez az opció csak Enterprise webhelyek számára érhető el külön kérés és külön díj ellenében. Ezenkívül csak olyan webhelyek számára elérhető, amelyek rendelkeznek a megfelelő ICP-licenszel, amelyben a Cloudflare van megjelölve szolgáltatóként. A bekapcsolása után a webhely számára elérhetővé válik a Cloudflare "kínai CDN" szolgáltatása — a forgalom a kínai régiókból a legközelebbi CF PoP-okba (Presence Pontok) érkezik, majd a Cloudflare vagy a partnerei hálózatain keresztül érkezik a forráshoz.
A tesztelési környezet sémája alább található.
Ez számunkra egy kiváló lehetőség. Úgy tűnik, hogy a második domain szintén a CF alatt lesz, ami nem növeli a cég által használt megoldások számát, valamint gyakorlatilag nem bonyolítja az infrastruktúrát.
Futtattuk a böngészős teszteket, és a következő eredmények születtek:
A piros rombuszok a tesztelés hibáit jelzik. Az alul lévő hibák DNS hibák (időkorlát a névszerver feloldásakor). A felül lévő hibák időkorlátok.
Uptime: 86.6
Medián: 18s
75 Percentilis: 29.3s
95 Percentilis: 60s
A medián, miután eltávolítottuk a betöltődést reCaptcha (a Google szolgáltatása, amely Kínában blokkolva van), a 28 másodpercről 18 másodpercre csökkent. De ez még mindig borzalmas adat, figyelembe véve, hogy ugyanaz a teszt a semrush.com (az Egyesült Államokból) kevesebb mint 10 másodperces eredményeket mutatott 95% felhasználóra (az Egyesült Államokból) ugyanarra az oldalra (statika + dinamika).
Minden tesztbe beléphet és megtekintheti Vízesés és egyéb részletes paraméterek. Elkezdjük felderíteni a hibák okait, és ha a timeoutokkal kapcsolatban minden viszonylag világos: az internet Kínában "hol zsugorodik, hol tágul", ezért a külföldi kapcsolódás és az erőforrások betöltési sebessége ingadozó és egyenlőtlen, a DNS-hibák nagyon megleptek minket. Felfedeztük, hogy PoP a Cloudflarenél valóban Kínában találhatók, a weboldal címe egy anycast IP-re oldódik fel, de az DNS-szerverek amerikaiak, emiatt a DNS-kérések kénytelenek átmenni a határon, ezért néha meghibásodnak.
Miután tisztáztuk ezt a kérdést a CF-nél, kiderült, hogy nincsenek saját DNS-szervereik Kínában, és hogy mikor lesz — az továbbra is ismeretlen.
Ezért úgy döntöttünk, hogy csak a Cloudflare DNS-t teszteljük, és megváltoztattuk a Cloudflare működési mechanizmusát a weboldalunkon a "Csak DNS" módra. Ez egy olyan mód, amikor a Cloudflare nem proxyzza a forgalmat magán, ami azt jelenti, hogy nem biztosít DDoS-védelmet, CDN-t és egyéb funkciókat, és sima DNS-szerverként működik.
Ez a tesztelési környezet a következő ábrán vázolva van. Az ábrán figyelembe van véve az a tudás, hogy a Cloudflare DNS-szerverek a tűzfal mögött találhatók.
A Catchpointnél egyszerű GET-teszteket indítottunk (nem böngésző alapú), amelyek nagyon sok hibát mutattak. Ezek okai a már említett DNS hibák voltak.
Elkezdjük hibakeresni ezeket a hibákat dig és felfedezzük, hogy az első kéréskor a cím helyesen van meghatározva, de a következő kérésnél újra megkapjuk a SERVFAIL és nem található. Miért van ez hirtelen?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn rendelkezik címmel 220.170.186.192
A semrushchina.cn host nem található: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn rendelkezik címmel 220.170.186.192
A semrushchina.cn host nem található: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn rendelkezik címmel 220.170.186.192
A semrushchina.cn host nem található: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn rendelkezik címmel 220.170.186.192
A semrushchina.cn host nem található: 2(SERVFAIL)Ha a Cloudflare névszerverek közvetlenül kérjük, ilyen hibák nincsenek:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Használva a domain szervert:
Név: ray.ns.cloudflare.com.
Cím: 173.245.59.138#53
Aliasok:
semrushchina.cn rendelkezik címmel 220.170.186.192
semrushchina.cn rendelkezik címmel 220.170.186.192
Használva a domain szervert:
Név: ray.ns.cloudflare.com.
Cím: 173.245.59.138#53
Aliasok:
semrushchina.cn rendelkezik címmel 220.170.186.192
semrushchina.cn rendelkezik címmel 220.170.186.192Ezért a probléma a "helyi" DNS-szerveren vagy a szolgáltató szerverén van.
A további nyomozás során kiderült, hogy SERVFAIL az AAAA -bejegyzéseket kapunk a feloldásnál.Kiderült, hogy a Cloudflare-nál végzett kérés során
Оказалось, что при запросе у Cloudflare AAAAA-rekord, amely nem létezik a doménben, a Cloudflare így válaszolt A-rekord, ami hibát és RFC-nek való megfelelés hiányt jelent. Emiatt a helyi feloldó (x.x.x.x) ezt nem szerette, és így válaszolt SERVFAIL. Az alábbi naplóban ez a viselkedés világosan látható:
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ális opciók: +cmd
;; Megkaptuk a választ:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; zászlók: qr rd ra; KÉRDÉS: 1, VÁLASZ: 0, JOGOSULTSÁG: 0, TOVÁBBI: 1
;; OPT PSEUDOSECTION:
; EDNS: verzió: 0, zászlók:; udp: 4096
;; KÉRDÉS SZAKASZ:
;semrushchina.cn. IN AAAA
;; Kérési idő: 334 msec
;; SZERVER: x.x.x.x#53(x.x.x.x)
;; IDŐ: 2018. augusztus 14. kedd 23:38:50 CST
;; MSG MÉRET kapott: 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ális opciók: +cmd
;; Megkaptuk a választ:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; zászlók: qr aa rd; KÉRDÉS: 1, VÁLASZ: 1, JOGOSULTSÁG: 0, TOVÁBBI: 1
;; FIGYELMEZTETÉS: rekurzió kérve, de nem elérhető
;; OPT PSEUDOSECTION:
; EDNS: verzió: 0, zászlók:; udp: 512
;; KÉRDÉS SZAKASZ:
;semrushchina.cn. IN AAAA
;; VÁLASZ SZAKASZ:
semrushchina.cn. 300 IN A 220.170.186.192
;; Kérési idő: 185 msec
;; SZERVER: 173.245.58.105#53(173.245.58.105)
;; IDŐ: 2018. augusztus 14. kedd 23:43:03 CST
;; MSG MÉRET kapott: 60
Bejelentettük a hibát a Cloudflare-nek, és ők ezt egy idő után kijavították. Érdekesnek bizonyult: jelenleg Kínában még mindig nincs IPv6 támogatás, így a Cloudflare nem tudta megadni az IPv6 címét a lekérdezésekre adott válaszban AAAAA-rekordokra. Végül úgy oldódott meg, hogy Kínáért a Cloudflare így válaszolt NODATA az ilyen lekérdezésekre.
Így a Catchpoint teszteken a DNS hibák számottevően csökkentek, de nem teljesen. Az időtúllépések sem tűntek el:
És elkezdtünk más megoldásokat keresni.
A következő részben mesélek arról, hogyan teszteltük a kínai felhőt Alibaba Cloud, hogyan tudtunk egy kis „varázslat” segítségével gyorsan PoC (Proof of Concept) megoldásokat létrehozni, hogyan hoztunk létre Multi-Cloud megoldásokat, amelyek közül az egyik végül nagyon sokat segített a szolgáltatás Kínából való gyorsításában.
Maradjatok velünk!
Következő részek
Forrás: habr.com
