Kuidas me läbisime Suure Hiina tulemüüri (osa 2)

Tere!

Teiega on jälle Nikita — süsteemiinsener ettevõttest SEMrush. Ja selle artikliga järgin lugu sellest, kuidas me leiutasime lahenduse Hiina tulemüürile meie teenuse jaoks semrush.com.

V eelmisel osal Ma rääkisin:

• millised probleemid tekivad pärast otsuse vastuvõtmist „Me peame tagama, et meie teenus töötaks Hiinas“
• millised probleemid on Hiina internetis
• miks on vajalik ICP-luba
• kuidas ja miks me otsustasime testida meie testimisüsteeme teoreetiliselt Catchpoint'i abil
• milline tulemus oli meie esimesel lahenduse variandil, mis põhines Cloudflare'i Hiina võrgul
• kuidas me leidsime vea Cloudflare'i DNS-is

See osa on minu arvates kõige huvitavam, kuna see keskendub konkreetsetele tehnilistele rakendustele. Ja alustame me, või õigemini jätkame, koos Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud — üsna suur pilvepakkuja, millel on kõik teenused, mis võimaldavad tal end õiglaselt pilvepakkujana nimetada. Hea, et välismaa kasutajad saavad liituda ning et suur osa saidist on tõlgitud inglise keelde (Hiina jaoks on see luksus). Selles pilves on võimalik töötada paljude maailma piirkondadega, sealhulgas Mandri-Hiinaga ja ookeanilise Aasiaga (Hongkong, Taiwan jne).

IPSEC

Alustasime geograafiast. Kuna testisait asus Google Cloud'is, pidime 'ühendama' Alibaba Cloud'i GCP-iga, seega avasime Google'i kohalolekute nimekirja. Tol hetkel ei olnud neil veel oma andmekeskust Hongkongis.
Lähim piirkond oli asia-east1 (Taiwan). Ali jaoks selgus, et kontinentalsest Hiinast lähim piirkond Taiwani suunas on cn-shenzhen (Shenzen).

Käesoleva abil terraform kirdasime ja lõime kogu infrastruktuuri GCP ja Ali vahel. 100 Mbit/s tunnel pilvede vahel loodi praktiliselt momentaalselt. Shenzenis ja Taiwanil loodi vahendavad virtuaalmasinad. Shenzenis terminaalitakse kasutajaliiklus, mis suunatakse kaudu tunnelit Taiwani, kust see juba otse suundub meie teenuse välisele IP-le us-east (USA idaosa). Virtuaalmasinate vaheline latentsus tunnelite kaudu 24ms, mis pole nii halb.

Korraga paigaldasime testimisala Alibaba Cloud DNS. Pärast tsooni delegeerimist NS Ali-le, kahanes resolvamise aeg 470 ms-lt 50 ms. Enne seda oli tsoon samuti Cloudflare'is.

Samaaegselt tunneliga asia-east1 tõstsime üles veel ühe tunneli Shenzhenist otse us-east4. Seal lõime veel proksiseerivaid virtuaalmasinaid ja alustasime mõlema lahenduse mõõtmist, suunates testimisliiklust Cookies või DNS kaudu. Testimise ala on skeemiliselt kirjeldatud järgmises joonises:

Tunnelite latentsus osutus järgnevaks:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Brauseritestid Catchpoint teatasid suurepärasest parandusmaterjalist.

Võrdle kahe lahenduse testide tulemusi:

Lahendus
Suurus
Mediaan
75. protsentiil
95. protsentiil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Need on IPSEC-tunneli kasutava lahenduse andmed asia-east1. Us-east4 kaudu olid tulemused halvemad, lisaks rohkem vigu, seega ei too tulemusi välja.

Selle tunnelitestide tulemuste põhjal, millest üks lõppeb Hiinale kõige lähemal asuvas piirkonnas ja teine lõppsihtkohas, on selge, et on oluline kiiresti „pinda hüpata” Hiina tulemüürist, seejärel kasutada kiireid võrgusid (nt CDN-teenuse pakkujad, pilveteenuste pakkujad jne). Pole mõistlik püüda korraga mööda tulemüürist minna ja otse sihtkohta jõuda. See ei ole kiireim tee.

Üldiselt on tulemused head, kuid semrush.com puhul on mediaan 8,8 s ja 75. protsentil 9,4 s (sama teste juures).
Ja enne, kui liigume edasi, tahaksin teha väikese lühiülevaate.

Lühiülevaade

Pärast seda, kui kasutaja siseneb veebisaidile www.semrushchina.cn, mis lahendatakse kaudu „kiirete” Hiina DNS-serverite, suunatakse HTTP-päring läbi meie kiire lahenduse. Vastus naaseb sama teed, kuid kõikide JS-skriptide, HTML-lehtede ja muude veebilehe elementide puhul on näidatud domeen semrush.com täiendavate ressursside jaoks, mis peavad olema laaditud lehe renderdamise käigus. See tähendab, et kliendil on reaalajas lahendatud „peamine” A-kirje www.semrushchina.cn ja ta läheb kiiresti tunnelisse, saab kiiresti vastuse — HTML-lehe, milles on öeldud:

• lae alla sellist js sso.semrush.com-ist,
• CSS-failid võta cdn.semrush.com-ist,
• ja veel too pilte dab.semrush.com-ist
• ja nii edasi.

Brauser hakkab minema "välisele" internetile, et neid ressursse leida, läbides iga kord aega sööva tulemüüriga.

Kuid eelmisel testil on esitatud tulemused, kus lehel ei ole ressursse semrush.com, ainult semrushchina.cn, ja *.semrushchina.cn resolveerub virtuaalmasina aadressiks Shenzhenis, et pääseda tunnelisse.

Ainult nii, suunates kogu võimaliku liikluse läbi oma kiire tulemüüri lahenduse, on võimalik saavutada aktsepteeritavad kiirus ja saidi kättesaadavuse näitajad ning ausad tulemused lahenduste testimisel.
Me tegime seda ilma ühtegi koodi parandamata toote poolel.

Alamfilter

Lahendus sündis praktiliselt kohe pärast seda, kui see probleem tekkis. Me vajamine ' PoC (Koncepte tõendamine), et meie tulemüüri läbimislahendused tõepoolest töötavad hästi. Selleks tuleb kogu saidi liiklus maksimaalselt suunata läbi selle lahenduse. Ja me rakendasime alamfiltrit nginx-is.

Alamfilter — see on üsna lihtne moodul nginx-is, mis võimaldab ühe rea vahetamist vastuse kehas teise vastu. Nii me vahetasime kõik esinemised semrush.com järgnevaga semrushchina.cn kõikides vastustes.

Ja... see ei töötanud, kuna tagapoolt saime me kompresseeritud sisu, seetõttu ei leidnud subfilter õiget rida. Pidi lisama veel ühe kohaliku serveri nginx-is, mis dekomprimeeris vastuse ja edastas selle järgmisele kohalikule serverile, mis juba tegi rea vahetuse, komprimeeris ja andis selle järgmisele vaheldus serverile.

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

Kuid lihtsalt domeeni vahetamine ühes suunas ei piisa, kuna tagapool ootavad ikka veel semrush.com järgmistelt klientide päringutelt. Seetõttu, samas serveris, kus toimub vahetus ühes suunas, kasutades lihtsat regulaarset väljendit, saame päringust alamdomeeni ning edasi teeme proxy_pass muutujaga $host, määratud $subdomain.semrush.com. See võib tunduda keeruline, aga see töötab. Ja töötab hästi. Erinevate loogikatega üksikute domeenide jaoks luuakse lihtsalt oma serveriplokid ja tehakse eraldi konfigureerimine. Allpool on esitatud lühendatud nginx konfiguratsioonid selguse huvides ja selle skeemi näitamiseks.

Järgmine konfiguratsioon töötleb kõik päringud Hiinast .semrushchina.cn:

    listen 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 suunab localhost port 83, kus ootab järgmist konfiguratsiooni:

    listen 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.

Ligikaudu nii. See võib tunduda keeruline, aga see on sõnades. Tegelikkuses on kõik lihtsam kui koogitükk 🙂

Looduse kõrvalejuhtimise lõpp

Mõnda aega olime õnnelikud, sest väärarusaamad IPSEC-tunnelite kokku kukkumisest ei leidnud kinnitust. Kuid siis hakkasid tunnelid kokku kukkuma. Mitu korda päevas, paar minutit. Veidi, kuid see ei rahuldanud meid. Kuna mõlemad tunnelid lõppesid Ali poolel ühes ruuteris, arvasime, et võib-olla on see piirkondlik probleem ja tuleb tõsta varunduspiirkonda.

Tõstsime üles. Tunnelid hakkasid kokku kukkuma erinevatel aegadel, kuid meil töötas upstream tasemel nginxis failover suurepäraselt. Siiski hakkasid tunnelid jälle peaaegu samaaegselt kokku kukkuma 🙂 Ja taas ilmusid 502 ja 504. Üksuse tööaeg halvenes, mistõttu hakkasime vaatama varianti koos Alibaba CEN (Cloud Enterprise Network).

CEN

CEN on kahe VPC ühendamine erinevates piirkondades Alibaba Cloudis, st saate ühendada eraklikud võrgud mis tahes piirkondades pilves omavahel. Ja mis kõige tähtsam: sellel kanali on üsna ranged SLA. See on väga stabiilne nii kiiruselt kui ka tööajalt. Kuid kunagi ei ole asjad lihtsalt lihtsad:

• seda on ÄÄRETSI keeruline saada, kui te ei ole Hiina kodanikud või juriidilised isikud,
• tuleb maksta iga megabiti kanalil läbivõime eest.

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

Tulemus oli selline:

Brauseritestide tulemused on allpool:

Lahendus
Suurus
Mediaan
75. protsentiil
95. protsentiil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Näitajad on veidi paremad kui IPSEC-il. Kuid IPSEC-i kaudu on potentsiaalselt võimalik laadida kiirusel 100 Mbit/s, samas kui CEN-i kaudu ainult 5 Mbit/s ja see maksab rohkem.

Küsimus on, kas luua hübriid, eks? Ühendades IPSEC-i kiirus ja CEN-i stabiilsus.

Ja nii me tegime, suunates liiklus nii IPSEC-i kui ka CEN-i kaudu IPSEC-i tunnelite tõrke korral. Üksikasjalikus tõusis oluliselt, kuid saidi laadimiskiirus jättis veel soovida. Siis ma joonistasin kõik skeemid, mida oleme juba kasutanud ja testinud, ja otsustasin proovida lisada sellele skeemile veel veidi GCP-d, nimelt GLB.

GLB

GLB — see on Global Load Balancer (või Google Cloud Load Balancer). Sellel on meie jaoks oluline eelis: CDN-i kontekstis on sellel anycast IP, mis võimaldab suunata liiklust lähimasse andmekeskusesse kliendile, mistõttu liiklus jõuab kiirelt Google'i võrku ja väheneb “tavalise” interneti kaudu kulgev liiklus.

Mõtlemata kaua, lõime HTTP/HTTPS LB GCP-s ja tagapindadega seadsime meie virtuaalmasinad koos subfilteriga.

Nende skeemide seas oli

• Kasutage Cloudflare Hiina võrk, kuid seekord tuleb kasutada Origin'it, et näidata globaalset IP GLB.
• Klientide lõpetamine cn-shenzhen, ja sealt edastada liiklus kohe GLB.
• Otseselt Hiinast GLB.
• Klientide lõpetamine cn-shenzhen, sealt edastada asia-east1 IPSEC-i kaudu ( us-east4 CEN-i kaudu), sealt juba GLB-sse (rahune, allpool on pilt ja selgitus)

Oleme testinud neid kõiki variante ja veel mitmeid hübriidlahendusi:

• Cloudflare + GLB

See skeem ei rahuldanud meid uptime ja DNS-veerudega. Kuid testid viidi läbi enne CF vea parandamist, võib-olla on nüüd parem (siiski ei välista see HTTP-aega).

• Ali + GLB

See skeem ei rahuldanud meid uptime osas, kuna GLB kukkus sageli välja, kuna ühenduse loomine oli ebapiisava ajaga või aegumise tõttu, kuna GLB aadress Hiina sees jääb välisse, mis tähendab, et see on Hiina tulemüüris. Maagia ei juhtunud.

• GLB ainult

Variant, mis sarnaneb eelnevale, kuid seal ei kasutatud servereid Hiinas: liiklus suundus kohe GLB-sse (vahetasime DNS-kirjeid). Seega ei rahuldanud tulemused, kuna tavaliste Hiina klientide, kes kasutavad tavaliste internetiteenuse pakkujate teenuseid, olukord tulemüüri läbimise osas on palju halvem kui Ali Cloud'il.

• Shenzhen -> (CEN/IPSEC) -> Proksi -> GLB

Siin otsustasime kasutada parimat kõigest, mis on saadaval:

• stabiilsus ja garanteeritud SLA CEN-ist
• kõrge kiirus IPSEC-i kaudu
• Google'i “kiiret” võrku ja tema anycast-id.

Schema näeb välja umbes nii: kasutajate liiklus lõpeb virtuaalmasinas ch-shenzhen. Seal on seadistatud nginx-i upstream'id, millest osa viitab privaatsete IP-serverite poole, mis asuvad IPSEC-tunneli teises otsas, ning osa upstream'e — privaatserverite aadressidele CEN-i teises otsas. IPSEC seadistati piirkonda asia-east1 GCP (oli kõige lähem piirkond Hiinale lahenduse loomise hetkel. Praegu on GCP-l ka kohalolek Hongkongis). CEN — piirkonda us-east1 Ali Cloud-is.

Edasi suunati liiklus mõlemast otsast anycast IP GLB, see tähendab lähimasse Google'i kohaloleku punkti, ja suundus tema võrkude kaudu piirkonda us-east4 GCP-s, kus asusid asendavad virtuaalmasinad (nginx-is subfilteriga).

See hübriidlahendus, nagu me ootasime, lubas kasutusele võtta iga tehnoloogia eelised. Üldiselt liigub liiklus kiiresti IPSEC-i kaudu, kuid kui tekivad probleemid, viskame need serverid kiiresti upstream'idest välja ja suuname liikluse ainult CEN-i kaudu, kuni tunnel stabiliseerub.

Rakendades eeltoodud lahendust, saavutasime selles osas, mida soovisime ja mida äri tol hetkel meilt nõudis.

Uue lahenduse brauseritestide tulemused võrreldes varasematega:

Lahendus
Suurus
Mediaan
75. protsentiil
95. protsentiil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13 s
16s
25 s

CDN

Meie rakendatud lahenduses on kõik hästi, ainult et puudub CDN, mis võiks kiirendada liiklust regionaalsel ja isegi linna tasemel. Idee on, et see peaks parandama saidi tööd lõppkasutajate jaoks, kasutades CDN-teenuse pakkuja kiireid ühendusi. Me mõtlesime selle üle pidevalt. Nüüd on käes järgmise projekti iteratsiooni aeg: CDN-teenuse pakkujate otsimine ja testimine Hiinas.

Ja sellest räägin teile järgmises, lõplikus osas 🙂

Allikas: habr.com