Kuidas me murdsime Suure Hiina Tulekahju Seina (osa 2)

Tere!

Teiega on jälle Nikita — süsteemitehnik ettevõttest SEMrush. Selle artikliga jätkan lugu, kuidas me leiutasime lahenduse Hiina tulemüürile meie teenuse jaoks semrush.com.

Uues eelmises osas Rääkisin:

• millised probleemid ilmnevad pärast otsuse tegemist "Peame tagama, et meie teenus toimiks Hiinas"
• millised probleemid on Hiina internetis
• miks on vajalik ICP-litsents
• kuidas ja miks me otsustasime testida meie testkeskkondi Catchpointi abil
• milline tulemus saadi meie esimesest lahendusversioonist, mis põhines Cloudflare Hiina võrgul
• kuidas me leidsime vead Cloudflare DNS-is

See osa on minu arvates kõige huvitavam, kuna keskendub konkreetsetele tehnilistele rakendustele. Alustame, või pigem jätkame, Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud — üsna suur pilveteenuse pakkuja, millel on kõik teenused, mis võimaldavad tal õigustatult end pilveteenuse pakkujana nimetada. Hästi on see, et neil on võimalus registreeruda välismaalastel ja et enamik veebisaidist on tõlgitud inglise keelde (Hiina jaoks on see luksus). Selle pilvega saab töötada paljude maailma piirkondade, mandri-Hiina ning ka Vaikse ookeani Aasia (Hongkong, Taiwan jne) kaudu.

IPSEC

Alustasime geograafiast. Kuna meie testimine toimus Google Cloudis, oli meil vaja "ühendada" Alibaba Cloud GCP-ga, seetõttu vaatasime Google'i kohaloleku lokatsioone. Sel hetkel polnud neil veel enda andmekeskust Hongkongis.
Lähim piirkond oli asia-east1 (Taiwan). Ali kõige lähem piirkond mandri-Hiinast Taiwani oli cn-shenzhen (Shenzhen).

EL-i abil terraform K kirjeldasime ja tõstsime kogu taristut GCP-s ja Ali. 100 Mbit/s tunnel kahe pilve vahel loodi praktiliselt koheselt. Shenzhenis ja Taiwani pool tõstsime proxy virtuaalsed masinad. Shenzhenis terminaaliseeritakse kasutaja liiklus, edastatakse tunnelisse Taiwani ja sealt lähevad nad otse meie teenuse välisele IP-le us-east (USA idarannik). Pingi aeg virtuaalmasinate vahel tunnelis 24ms, mis pole üldse halb.

Samas paigaldasime testimisala Alibaba Cloud DNS. Pärast tsooni delegeerimist NS Ali, resolutsiooniaeg langes 470 ms-lt 50 ms. Enne seda oli tsoon ka Cloudflare'is.

Samaaegselt tunneliga asia-east1 loome veel ühe tunnel Shenzhenist otse us-east4. Seal loodi veel proxyd virtuaalne masina ja hakati mõõtma mõlemaid lahendusi, marsruutides testliiklust Cookieside või DNSi abil. Skeemiliselt on teststend kirjeldatud järgmises joonises:

Tunnelite latentsus oli järgmine:
Ali cn-shenzhen GCP asia-east1 — 24ms
Ali cn-shenzhen GCP us-east4 — 200ms

Brauseritestid Catchpoint teatasid suurepärasest jõudluse parandusest.

Võrdle tulemusi kahe lahenduse vahel:

Lahendus
Aeg
Mediaan
75. percentiil
95. percentiil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Need on andmed lahenduse kohta, mis kasutab IPSEC-tunnelit läbi asia-east1. Us-east4 kaudu olid tulemused halvemad ning vigu oli rohkem, seega ei too tulemusi välja.

Antud kahe tunnelitestiga, millest üks lõppeb Hiinale lähimas regioonis ja teine lõpp-punktis, sai selgeks, et on oluline võimalikult kiiresti "hiinast välja tõmmata", ning seejärel kasutada kiireid võrke (CDN-teenusepakkujad, pilveteenusete pakkujad jne). Ei ole mõistlik proovida ühel liikvel läbi tulekahjusüsteemi minna ning jõuda sihtpunkti. See pole kõige kiirem tee.

Üldiselt on tulemused head, aga semrush.com'i mediaan on 8.8s ja 75. percentiil 9.4s (samal testil).
Ja enne kui edasi liikuda, sooviksin teha väikese lühiülevaate.

Lühiühendus

Pärast seda, kui kasutaja siseneb saidile www.semrushchina.cn, mis lahendatakse "kiirete" Hiina DNS-serverite kaudu, läheb HTTP-päring meie kiire lahenduse kaudu. Vastus saadetakse tagasi sama teed, kuid kõikides JS-skriptides, HTML-lehtedes ja muudes veebilehe elementides näidatakse domeeni semrush.com täiendavate ressursside jaoks, mis peavad olema laaditud lehe renderdamise käigus. See tähendab, et klient lahendab "peamise" A-kirje www.semrushchina.cn ja läheb kiirese tunnelisse, saavad kiiresti vastuse — HTML-lehe, milles öeldakse:

• lae see javascript sso.semrush.com-ilt,
• CSS-failid too cdn.semrush.com-ilt,
• ja veel too pilte dab.semrush.com-ilt.
• ja nii edasi.

Brauser hakkab minema "välimisse" internetti nende ressursside järele, läbides iga kord aeglaselt vastuse takistav tulekahjusüsteem.

Kuid eelmises testis esitati tulemused, kus lehes ei olnud ressursse semrush.com, ainult semrushchina.cn, ja *.semrushchina.cn lahendatakse Shenzhenis asuva virtuaalmasina aadressile, et pääseda siis tunnelisse.

Ainult nii, suunates maksimaalselt kogu võimaliku liikluse läbi oma Hiina tulemüüri kiiruse lahenduse, on võimalik saavutada vastuvõetavaid kiirus- ja saidi kättesaadavuse näitajaid, samuti ausaid lahenduste teste.
Me tegime seda ilma ühegi koodimuudatuseta toote meeskondade poolelt.

Alamfilter

Lahendus sündis praktiliselt kohe pärast siinse probleemi ilmnemist. Me vajasime PoC (Proof of Concept), et näidata, et meie tulemüüri lahendused töötavad tõeliselt hästi. Selleks tuli maksimaalselt kogu saidi liiklus selle lahenduse kaudu suunata. Ja me rakendasime alamfilteri nginx'is.

Alamfilter — see on üsna lihtne moodul nginx'is, mis võimaldab muuta ühe rea vastuse kehas teiseks reaks. Nii muudeti me kõik esinemised semrush.com . Tundub, et semrushchina.cn kõikides vastustes.

Ja… see ei töötanud, sest tagasiandmistelt saime komprimeeritud sisu, seega alamfilter ei leidnud vajalikku rida.Pidime lisama veel ühe kohaliku serveri nginx'i, mis dekomprimeeris vastuse ja edastas selle järgmisele kohalikule serverile, mis tegi ridade asendamise, komprimeerimise ja edastamise järgmisele silmusele vaheserverisse.

Lõpuks, kus klient oleks saanud <subdomain>.semrush.com, sai ta <subdomain>.semrushchina.cn ja läks usinalt läbi meie lahenduse.

Kuid ei piisa lihtsalt domeeni vahetamisest ühes suunas, kuna tagaplaanid ootavad endiselt semrush.com'i järgnevate klientide päringutes. Seetõttu samas serveris, kus toimub asendamine ühes suunas, saame lihtsa regulaaravalduse abil päringust alamdomeeni ja seejärel teeme proxy_pass muutuja $host, mis on seadistatud $subdomain.semrush.com. See võib tunduda segane, kuid see töötab. Ja see töötab hästi. Erinevate domeenide jaoks, mis nõuavad teistsugust loogikat, luuakse lihtsalt omad serveriplokid ja tehakse eraldi konfiguratsioon. Allpool on näidatud lühendatud nginx konfiguratsioonid selle skeemi selgitamiseks ja demonstreerimiseks.

Järgmine konfiguratsioon käsitleb kõiki Hiinast pärinevaid päringuid aadressil .semrushchina.cn:

    kuula 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;
    }
}

See konfiguratsioon edastab localhost porti 83, kus ootab järgmine konfiguratsioon:

    kuula 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;
    }
}

Kordan, need on lühendatud konfiguratsioonid.

Nii see umbes välja näeb. See võib tunduda keeruline, aga sõnades on see niimoodi. Tegelikult on kõik lihtsam kui kõrvits 🙂

Lühiheide lõppu

Mõnda aega olime õnnelikud, sest müüt langevatest IPSEC-tunnelitest ei tõestunud. Aga siis hakkasid tunnelid langema. Paar korda päevas, paar minutit korraga. Natuke, aga meid see ei rahuldanud. Kuna mõlemad tunnelid lõpetati Ali-s ühel ruuteril, otsustasime, et võib-olla on see piirkondlik probleem ja tuleb üles tõsta varukoopia piirkond.

Me tõstsime üles. Tunnelid hakkasid langema erinevatel aegadel, kuid meie ülemineku tasemel nginxis toimis failover suurepäraselt. Kuid seejärel hakkasid tunnelid jälle langema peaaegu samaaegselt 🙂 Ja taas ilmusid 502 ja 504. Üksikasjad hakkasid halvenema, seega hakkasime uurima võimalust Alibaba CEN (Cloud Enterprise Network).

CEN

CEN on ühendus kahe VPC vahel erinevates piirkondades Alibaba Cloudis, mis tähendab, et saate ühendada privaatvõrgud mis tahes piirkondade vahel. Ja mis kõige olulisem: sellel kanalil on üsna range SLA. See on väga stabiilne nii kiiruselt kui ka tööajalt. Aga ei ole kunagi nii lihtne:

• seda ON ÜLIMALT raske saada, kui te ei ole Hiina kodanikud ega juriidilised isikud,
• tuleb maksta iga megabiti ühenduse ribalaiuse eest.

Saades võimaluse ühendada Mandri-Hiina ja Välismaal, lõime CEN kahe piirkonna Ali vahel: cn-shenzhen ja us-east-1 (kõige lähem punta us-east4-le). Ali-s us-east-1 tõstsime üles veel ühe virtuaalmasina, et oleks veel üks hop.

Tulenes järgmine tulemus:

Brauserite testide tulemused on allpool:

Lahendus
Aeg
Mediaan
75. percentiil
95. percentiil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Tulemustel on veidi paremad näitajad kui IPSEC-il. Aga IPSEC-i kaudu saab potentsiaalselt laadida kiirusel 100 Mbit/s, CEN-i kaudu ainult 5 Mbit/s kiirusel ja see on kallim.

Küsimus on segas, eks? Ühendada IPSEC-i kiirus ja CEN-i stabiilsus.

Nii me tegimegi, suunates liiklust nii IPSEC kui ka CEN kaudu, kui IPSEC-tunneli ühendus katkes. Tõsteaeg kasvas märkimisväärselt, kuid veebisaidi laadimiskiirus jäi endiselt soovitust madalamaks. Siis tõmbasin kõik skeemid, mida olime juba kasutanud ja testinud, ja otsustasin proovida lisada sellesse skeemi veel natuke GCP-d, nimelt GLB.

GLB

GLB — see on Globaalne koormuse tasakaalustaja (või Google Cloud Load Balancer). Sellel on meie jaoks oluline eelis: CDN kontekstis, sellel on anycast IP, mis võimaldab suunata liiklust lähimasse andmekeskusesse kliendile, tänu millele liiklus jõuab kiiremini Google'i kiire võrguni ja vähem liigub läbi "tavalise" interneti.

Mõtleme natuke, me tõstsime HTTP/HTTPS LB GCP-s ja tagapool setsime meie virtuaalmasinad subfilteriga.

Oli mitu skeemi:

• Kasutage Cloudflare Hiina võrk, aga seekord määrasin Origin’iks globaalse IP GLB.
• Kliendid on terminiseeritud cn-shenzhen, ja sealt suunatakse liiklus otse GLB.
• Otse Hiinast GLB.
• Kliendid on terminiseeritud cn-shenzhen, sealt suunatakse asia-east1 IPSEC kaudu (CEN kaudu), sealt edasi GLB-sse (rahune, allpool on pilt ja seletus) us-east4 Testisime kõiki neid variante ja veel mitmeid hübriide:

Cloudflare + GLB

• See skeem ei rahuldanud meid tõsteaja ja DNS- tõrgete poolest. Kuid test viidi läbi enne CF-bugi parandamist, võib-olla on nüüd parem (kuid see ei välista HTTP-aega).

Ali + GLB

• See skeem ei rahuldanud meid tõsteaja poolest, kuna GLB langes sageli allavoolu, kuna ühenduse loomine ei olnud mõistliku aja jooksul võimalik või aegumiste tõttu, sest Hiinas oleva serveri jaoks jääb GLB aadress väliseks ja seega Hiina tulemüüri taha. Midagi erilist ei juhtunud.

GLB ainult

• Variant, mis sarnaneb eelmisele, ainult et selles ei kasutatud servereid Hiinas: liiklus läks kohe GLB-sse (DNS-koodide muutmine). Seetõttu ei rahuldanud tulemused, kuna tavaliste Hiina klientide, kes kasutavad tavapäraseid internetiteenuse pakkujaid, olukord tulemüüri ületamisel on palju halvem kui Ali Cloudil.

Shenzhen -> (CEN/IPSEC) -> Proksy -> GLB

• Siin otsustasime kasutada parimat kõigist lahendustest:

stabiilsus ja garanteeritud SLA CEN-ilt

• kõrge kiirus IPSEC-ist
• "kiire" Google'i võrk ja selle anycast.
• Skeem näeb välja umbes nii: kasutajate liiklus terminiseeritakse virtuaalmasinas

ch-shenzhen ch-shenzhen. Seal on upstreams nginx, some of which refer to private IP servers located at the other end of the IPSEC tunnel, while others point to private server addresses on the other side of the CEN. IPSEC was configured for the region asia-east1 in GCP (it was the closest region to China at the time the solution was created. Now GCP also has a presence in Hong Kong). CEN is for the region us-east1 in Ali Cloud.

Then the traffic from both ends was directed to anycast IP GLB, that is, to the nearest Google point of presence, and went through its networks to the region us-east4 in GCP, where we had proxy virtual machines (with subfilter in nginx).

This hybrid solution, as we expected, allowed us to take advantage of each technology. Overall, traffic flows through a fast IPSEC, but if problems arise, we quickly and for a few minutes remove these servers from upstreams and direct traffic only through CEN until the tunnel stabilizes.

By implementing the 4th solution from the list above, we achieved what we wanted and what the business required at that time.

Results of browser tests for the new solution compared to previous ones:

Lahendus
Aeg
Mediaan
75. percentiil
95. percentiil

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

In the solution we implemented, everything is good, only there is no CDN that could accelerate traffic at the regional and even city levels. Ideally, this should speed up website performance for end users by utilizing fast communication channels from the CDN provider. And we were always thinking about this. And now, the time has come for the next iteration of the project: searching and testing CDN providers in China.

And I will tell you about this in the next, final part 🙂

Allikas: habr.com