Tere kõigile!
Tere, mina olen Nikita - süsteemiinsener ettevõttest SEMrush. Täna räägin teile, kuidas seisis meie ees ülesanne tagada meie teenuse semrush.com stabiilne töö Hiinas ja milliseid probleeme me selle täitmise käigus kohtasime (arvestades meie andmekeskuse asukohta Ameerika Ühendriikide idaosas).
See saab olema suur lugu, jagatud mitmeks artikliks. Räägin, kuidas meil kõigil see oli: täiesti mittetoimiv teenus Hiinas, kuni teenuse töö näitajate tasemeni, mis vastab Ameerika versioonile Ameerika kasutajatele. Luban, et see on huvitav ja kasulik. Nii et läheme.
Hiina interneti probleemid
Isegi kõige kauge eemal olev inimene võrguadministratsiooni spetsiifikast on vähemalt korra kuulnud Suurest Hiina tulemüürist. Ooh, kõlab lahedalt, eks? Aga mis see on, kuidas see tegelikult töötab - see on üsna keeruline küsimus. Internetis leiab palju artikleid, mis on sellele pühendatud, kuid tehnilisest vaatenurgast pole selle tulemüüri ülesehitust kusagil detailselt kirjeldatud. Mis pole üllatav. Pean tunnistama, et pärast aasta tööd ma ei suuda täpselt öelda, kuidas see töötab, aga saan rääkida oma tähelepanekutest ja praktilistest järeldustest. Ja alustame kuulujuttudest selle tulemüüri kohta.
Selle tulemüüri kohta on palju kuulujutte. Kogume mõned peamised ja huvitavamad neist ühte nimekirja:
- Google, Facebook, Twitter ja muud sarnased teenused on blokeeritud ja ei tööta Hiinas.
- Iga liiklus, mis liigub Hiina piiridest VÄLJA ja SISEPOOLE, analüüsitakse ja piiratakse masinõppe abil (kahtlase liikluse korral), mis aeglustab seda tugevalt (liiklus), mis ületab piiri.
- Hiina eriteenistused võivad häkkida iga krüpteeritud liiklust, mis läbib nende tulemüüri.
- VPN-tunnelid, IPSEC-tunnelid on ebastabiilsed, kukuvad alla ja blokeeritakse pidevalt.
- Mida lihtsam on krüptimine, seda lihtsam on passifrase, mida kasutatakse liikluse autentimiseks/krüptimiseks, seda kiiremini see Hiina tulemüüri kaudu läbib.
Siin on, mida me nende kuulujuttude kohta teada saime:
- Google, Facebook, Twitter ja muud sarnased teenused on tõepoolest blokeeritud (teie KO), kuid paljud tehnilised domeenid Google'ilt, näiteks, ei ole blokeeritud ja töötavad (sama gstatic.com). Seega järeldus: ei tasu mõtlematult kõrvaldada kõiki Google'i ja teisi, tundlikena näivate blokeeritud ressursse.
- Iga liiklus, mis ületab piiri, tõesti lisab oma ajale märkimisväärse viivituse. Vaadake kahte tulemust. Üks sait, üks leht, lihtne GET curl’om. Esimene mõõtmine otse Hiinast (ilus linn Shenzhen). Teine mõõtmine väljastpoolt Hongkongist (millel on suveräänsus ja millel ei ole tulemüüri maailma suunas). Linnadevaheline kaugus on sirgjoones umbes 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/sPange tähele time_connect. Ja kokkuvõttes näete tulemust: tulemüür lisab 4 täiendavat sekundit, mis on kohutavalt pikk aeg.
- VPN ja IPSEC tunneliühendused tõesti tihti katkevad. Sellest räägin veidi hiljem ja põhjalikumalt. VPN-serverid, mida kasutajad kasutavad, blokeeritakse aja jooksul (tavaliselt ühe päeva jooksul pärast kasutamist).
- On arvamus, mis on saadud Hiinas elavatelt inimestelt, et mida lihtsam on liikluse krüptimine, seda kiiremini see piiri ületab, kuna on lihtne mõista, et selles pole midagi ebaseaduslikku. Samuti „puhtam“ liiklus saab rohkem ribalaiust ja kiiruset võrreldes „mustaga“ liiklusega, mille sisu on raskesti mõistetav, mis omakorda venitab läbipääsu. Näiteks toon curl-i ifconfig.co protokollide HTTPS ja HTTP kaudu.
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/s13 baiti allalaadimise üldine aja erinevus on 5 sekundit. Korduvalt selliseid teste tehes võib märkida, et GET HTTP kaudu lõpeb enamasti sama aja jooksul, samas kui HTTPS kaudu vastab sait mõnikord 3, 5, 10 ja isegi 17 sekundi pärast. Mõnikord esinevad SSL-i vead:
Tundmatu SSL-protokolli viga ühenduses ifconfig.co:443.
Nii, mida me siis omame:
- Eelnevalt kirjeldatud probleemid, mida tekitab Hiina tulemüür.
- Pingid välistele ressurssidele ja tunnelites kaovad perioodiliselt.
- Latency kahe punkti vahel muutub pidevalt ja sageli on see täiesti ettearvamatu. Erinevate linnade/regioonide ühendamisel ootad, et geograafilise asukoha põhjal on latentsus väiksem, kuid saad täpselt vastupidise tulemuse.
- Internet ja sidekanalid töötavad kas kiiresti või aeglaselt. Siin on väike sõltuvus kellaajast ja nädalapäevast, kuid mitte alati.
- DNS-päringud Hiinast välismaailma ületavad mõnikord lubatud aegumistähtaega.
Pilt kujuneb välja lihtsalt "suurepärane".
Kuna meie andmekeskus asub USA idaosas ja kogu SEMrush koosneb kümnetest omavahel seotud toodetest, taustadest, päringutest, andmebaasidest, ja kõik see asub andmekeskustes ja pilvessä. Meie, süsteemiadministraatorid, seadsime endale ülesande miinimumvaevaga kiiresti Hiinas tööle hakata.
Meil oli vaja vastata olulisele küsimusele: kas on võimalik väheste jõupingutustega lahendada kõik probleemid, mis on seotud Hiina interneti ja tulemüüriga, võrgu/pilvede/serverite tasemel?
Alustasime .
ICP-litsents
Hiina (Mandri-Hiina) piirides oma teenuse majutamiseks ja testide läbiviimiseks tuleb esmalt saada ICP-litsents domeeni jaoks.
Kui teie saidi kasutajate liiklus lõpeb Mandri-Hiinas ja teie domeenil pole ICP-litsentsi, blokeerib teie liikluse pakkuja/hostimine. Huvitav on see, et ICP-litsentsi lisatakse konkreetne pakkuja, olenemata sellest, kas see on Cloudflare või Alibaba Cloud. Seetõttu, kui olete saanud ICP-litsentsi Cloudflare'i jaoks ja majutanud oma saiti nende juures, ei saa te hiljem "sujuvalt" üle kolida Alibaba Cloudi. Peate lisama veel ühe hostimise sellele litsentsile.
Saades oma domeenile ICP-litsentsi, suutsime välja mõelda ja ellu viia konkreetsed tehnilised ideed ja lahendused.
Lahenduste testimine
Kuid enne, kui hakkame otse loomulikult looma stendiversioone, reguleerima seadistusi, optimeerima saidi tööd ja kiirus, peame valima tööriista selle testimiseks, et näha, millised meie tegevused parandavad või vastupidi halvendavad saidi tööd.
Meie testimisriist peab vastama kahtele peamisele nõudele:
- see peab olema võimeline testima Hiinast,
- see peab olema brauseritestide võimalus.
Nii leidsime ! Neil on suurepärane testimispunktide katvus kogu maailmas. Hiinas saab seda tööriista kasutades teste läbi viia ka 100500 provintsist. Igaühes on mitu erinevat pakkujat + võimalus teha Backbone-teste (midagi sarnast virtuaalmasinale andmekeskuses) ja Lastmile-teste (maksimaalselt lähedased kasutajatingimustele, aka tööjaam). Viimane testitüüp on kallim.
Aasta lepingu sõlmimisega (odavamalt ei saa) alustasime tööriista uurimist. Peame tunnistama, et olime meeldivalt üllatunud selle funktsionaalsusest. Saab käivitada:
- DNS-testid,
- Veebitestid (brauseri, lihtne GET/POST, mobiilse kliendi emulatsioon jne),
- Tehingu kontrollid (näiteks sisselogimine),
- API-testid,
- Ping, traceroute, NTP jne.
Kokku on palju rohkem. Ja mis kõige tähtsam, iga testi saab üsna hästi kohandada, lisades hulga päiseid ja muid parameetreid. Tulemuseks on tohutu hulk teavet, mis täielikult kirjeldab teie testi. Kui rääkida kõige huvitavamast meie jaoks (brauseritestid), siis tulemus sisaldab:
- Connect, Wait, Load, SSL, DNS aeg,
- TTFB, TTLB, Dokument valmis, Renderdamise aeg, DOM-i laadimine,
- Response (midagi, mis sarnaneb Time To First Byte'ile), Veebilehe vastus (midagi, mis sarnaneb Time To Last Byte'ile),
- Igasse protsenti, Keskmine, Mediaan aeg
- jne.
Seega, kõik need mõõdikud aitavad suurepäraselt jälgida muutusi ja mõista, kas olukord on paranenud. Me keskendusime peamiselt sellele, Response, Veebilehe reaktsioon, Mediaan, 75 ja 95 protsentiil.
Oluline küsimus, mis on olnud õhus alates algusest: kas Catchpoint'i usaldada? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
See on suur probleem, kuna Venemaal on praktiliselt võimatu usaldusväärselt teada, kuidas veebisait Hiinast töötab. SOCKS-proxy kasutamine virtuaalmasinas viib selleni, et veebisaidi laadimine kestab paar minutit, mis pole testide jaoks vastuvõetav, seetõttu jääb ainsaks käsitsi testimise võimaluseks curl ja lihtsad GET-käsklused terminalist ajamõõtmisega. See on kasulik, sest antud test peegeldab hästi võrgulahenduse töökiirus, ja kui on veel ka brauseritestid, on kõik veelgi parem.
Hiljem käisime hiinas ja veendusime, et Catchpoint'ile võib usaldada, see peegeldab üsna täpselt reaalseid töökiirusnäitajaid.
Cloudflare Hiina võrk
Kuna peamise domeeni semrush.com puhul kasutame Cloudflare'i edukalt, siis otsustasime kohe proovida nende funktsiooni nimega . See valik aktiveeritakse ainult Enterprise-veebisaitide jaoks eraldi taotluse alusel ja eritasu eest. Samuti on see saadaval ainult veebisaitidele, millel on vastav ICP-luba, kus teenusepakkujana on märgitud Cloudflare. Pärast aktivatsiooni on saidile saadaval Cloudflare'i "Hiina CDN" — Hiina piirkondadest tulev liiklus suunatakse lähimasse CF PoP (Presence Point) ja sealt edasi edastatakse see tema võrkude või teenusepakkujate/partnerite kaudu alguspunkti.
Antud testseina skeem on esitatud allpool.
Meie jaoks on see suurepärane variant. Tundub, et teine domeen läheb samuti CF alla, mis ei suurenda ettevõttes kasutatavate lahenduste arvu ja praktiliselt ei komplitseeri infrastruktuuri.
Käivitame brauseritestid ja siin on tulemused:
Punased rombid on testide ebaõnnestumised. Alumise punase rombi ebaõnnestumised on DNS-i vead (resolve timeout). Ülemise punase rombi ebaõnnestumised on ajastamise ületamised.
Ajaline töö: 86.6
Mediaan: 18s
75. protsentiil: 29.3s
95. protsentiil: 60s
Mediaan, pärast seda kui eemaldati laadimine reCaptcha (Google'i teenus, mis on Hiinas blokeeritud), langes 28 sekundi pealt 18 sekundi peale. Aga need on siiski kohutavad näitajad, kui arvestada, et sama test semrush.com-ile (USA-st) näitas alla 10 sekundi 95% kasutajatele (USA-st) samal lehel (staatika + dünaamiline).
Iga testisse saab sisse logida ja näha Waterfall ja teised üksikasjalikumad parameetrid. Me alustasime vigade põhjuste uurimist ja kui ajavõtud on enam-vähem arusaadavad: internet Hiinas "siis tuleb, siis läheb". Seetõttu on ühenduse kiirus ja välisressursside laadimise kiirus ebastabiilsed ja varieeruvad, siis DNS-vigade tõttu olime väga üllatunud. Me avastasime, et PoP Cloudflare'i serverid asuvad tõepoolest Hiinas, saidi aadress lahendatakse ühele anycast IP-le, kuid kasutatakse Ameerika DNS-servereid, mistõttu peavad DNS-päringud läbima piiri, seetõttu need aeg-ajalt ebaõnnestuvad.
Selle küsimuse täpsustamisel CF-ilt selgus, et neil ei ole oma DNS-servereid Hiinas,aga kuna need tulevad, pole hetkel teada.
Seetõttu otsustasime testida ainult Cloudflare'i DNS-i ja muutsime Cloudflare'i töö mehhanismi meie saidil režiimiks "Ainult DNS". See on selline režiim, kus Cloudflare ei edasta liiklust läbi enda, mis tähendab, et nad ei paku DDoS-kaitset, CDN-i ja muid funktsioone ning töötavad tavalise DNS-serverina.
Antud skeem on visuaalselt esitatud järgmises joonises. Joonisel on arvesse võetud teadmised, et Cloudflare DNS-serverid asuvad tulemüüri taga.
Catchpointis käivitasime lihtsad GET-testid (mitte brauseripõhised), mis näitasid väga palju ebaõnnestumisi. Nende põhjuseks olid kõik samad DNS vead.
Alustasime nende vigade tõrkeotsingut dig ja avastasime, et esimesel päringul määratakse aadress õigesti, kuid korduvatel päringutel saame iga kord SERVFAIL ja not found. Miks see nii on?
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)Kui pärida Cloudflare'i NS-serverit otse, siis selliseid vigu ei esine:
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.192See tähendab, et probleem on "kohaliku" DNS-serveri või teenusepakkuja serveri poolel.
Edasiuurimine näitas, et SERVFAIL me saame resolveerimisel AAAA-kirjed.
Selgus, et Cloudflare'i päringul AAAA-kirje, mida domeenis ei ole, Cloudflare vastas A-kirjega, mis on viga ja ei vasta RFC-le. Seetõttu ei meeldinud see kohalikule resolverile (x.x.x.x) ja ta vastas SERVFAIL. Allolevas logis on see käitumine selgelt nähtav:
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
;; globaalne valik: +cmd
;; Sai vastuse:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; lipud: qr rd ra; UURING: 1, VASTUS: 0, AUTORITEET: 0, LISATAV: 1
;; OPT PSEUDOSECTION:
; EDNS: versioon: 0, lipud:; udp: 4096
;; KÜSIMISE OSAS:
;semrushchina.cn. IN AAAA
;; KÜSIMISE AEG: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; AEG: Tue Aug 14 23:38:50 CST 2018
;; MSG SUURUS 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.
;; globaalne valik: +cmd
;; Sai vastuse:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; lipud: qr aa rd; UURING: 1, VASTUS: 1, AUTORITEET: 0, LISATAV: 1
;; HOIATUS: rekurssiooni küsiti, kuid see ei ole saadaval
;; OPT PSEUDOSECTION:
; EDNS: versioon: 0, lipud:; udp: 512
;; KÜSIMISE OSAS:
;semrushchina.cn. IN AAAA
;; VASTUSE OSAS:
semrushchina.cn. 300 IN A 220.170.186.192
;; KÜSIMISE AEG: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; AEG: Tue Aug 14 23:43:03 CST 2018
;; MSG SUURUS rcvd: 60
Saime Cloudflare'ile bug-aruande edasi ja nad parandasid selle mõne aja pärast. Okei, et hetkel ei ole Hiinas ikka veel IPv6 tuge, seega ei suutnud Cloudflare seal oma IPv6-aadressi päringule vastata AAAA-kirjed. Lõpuks lahendati asi nii, et Cloudflare hakkas Hiinas vastama NODATA sellistele päringutele.
Seega vähendati Catchpointi testides DNS-vigu järsult, kuid mitte täielikult. Aegumise probleeme ei olnud ka kuhugi kadunud:
Ja me hakkasime otsima muud lahendust.
Järgmises osas räägin, kuidas me testisime Hiina pilve Alibaba Cloud, kuidas Nginx'i väikese „võlu“ abil saime kiiresti luua PoC (Proof of Concept) lahendusi, kuidas me lõime Multi-Cloud lahendusi, millest üks aitas oluliselt kiirendada teenuse tööd Hiinast.
Jälgige meid!
Järgmised osad
Allikas: habr.com
