Nola hautsi genuen Txinako Suebaki Handia (2. zatia)

Hi!

Nikita zurekin dago berriro, konpainiako sistema ingeniaria SEMrush. Eta artikulu honekin konponbide irtenbide bat nola asmatu genuen azaltzen jarraitzen dut Txinako suebakia gure zerbitzurako semrush.com.

В aurreko zatia Esan nuen:

• zer arazo sortzen diren erabakia hartu ondoren "Gure zerbitzuak Txinan funtzionatu behar dugu"
• Zein arazo ditu Txinako Internetek?
• zergatik behar duzu ICP lizentzia?
• nola eta zergatik erabaki genuen gure proba-baseak Catchpoint-ekin probatzea
• zein izan zen Cloudflare China Network-en oinarritutako gure lehen irtenbidearen emaitza
• Nola aurkitu genuen akats bat Cloudflare DNS-n

Zati hau da interesgarriena, nire ustez, eszenaratzearen ezarpen tekniko zehatzetan zentratzen delako. Eta hasiko gara, edo hobeto esanda, jarraituko dugu Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud hodei hornitzaile nahiko handia da, eta bere burua zintzoki hodeiko hornitzaile deitzeko aukera ematen dioten zerbitzu guztiak ditu. Ona da atzerriko erabiltzaileentzat izena emateko aukera izatea, eta gune gehiena ingelesera itzulita egotea (Txinarentzat hau luxua da). Hodei honetan, munduko hainbat eskualderekin lan egin dezakezu, Txina kontinentala, baita Asia Ozeanikoarekin (Hong Kong, Taiwan, etab.).

IPSEC

Geografiarekin hasi ginen. Gure proba-gunea Google Cloud-en zegoenez, Alibaba Cloud GCP-rekin "lotu" behar genuen, beraz, Google dagoen kokapenen zerrenda ireki genuen. Momentu horretan ez zuten oraindik bere datu-zentrorik Hong Kongen.
Eskualde hurbilena izan zen asia-ekialdea1 (Taiwan). Ali Txina kontinentaletik Taiwanetik hurbilen dagoen eskualdea izan zen cn-shenzhen (Shenzhen).

With terraform GCP eta Ali-n azpiegitura osoa deskribatu eta planteatu zuen. Hodeien arteko 100 Mbit/s-ko tunela igo zen ia berehala. Shenzhen eta Taiwanen aldean, proxy makina birtualak planteatu ziren. Shenzhenen, erabiltzaileen trafikoa amaitzen da, tunel baten bidez Taiwanera bideratzen da, eta hortik zuzenean gure zerbitzuaren kanpoko IPra doa. gu-ekialde (AEBko ekialdeko kostaldea). Egin ping makina birtualen artean tunelaren bidez 24ms, hori ez da hain txarra.

Aldi berean, proba eremu bat jarri genuen Alibaba Cloud DNS. Zona NS Ali-ri delegatu ondoren, ebazpen-denbora 470 ms-ra jaitsi zen 50 ms. Horren aurretik, zona Cloudlfare-n zegoen ere.

Tunelarekiko paraleloa asia-ekialdea1 Shenzhenetik zuzenean beste tunel bat altxatu zuen gu-ekialde4. Bertan proxy makina birtual gehiago sortu zituzten eta bi irtenbideak probatzen hasi ziren, probako trafikoa Cookieak edo DNS erabiliz bideratuz. Proba-bankua eskematikoki deskribatzen da hurrengo irudian:

Tunelen latentzia hauxe izan zen:
Ali cn-shenzhen <—> GCP asia-east1 — 24 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

Catchpoint arakatzailearen probek hobekuntza bikaina eman zuten.

Konparatu probaren emaitzak bi soluziotarako:

Erabaki
Funtzionamendu
median
75 ehunekoa
95 ehunekoa

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

IPSEC tunel bat erabiltzen duen irtenbide baten datuak dira asia-ekialdea1. Gurekin-ekialdeko4 emaitzak okerragoak ziren, eta akats gehiago egon ziren, beraz, ez ditut emaitzak emango.

Bi tunelen proba honen emaitzetatik abiatuta, horietako bat Txinatik hurbilen dagoen eskualdean amaitzen dena, eta bestea azken helmugan, argi geratu zen garrantzitsua dela Txinako suebakiaren azpitik bezain laster "irtetea". posible, eta gero sare azkarrak erabili (CDN hornitzaileak, hodeiko hornitzaileak, etab.). Ez dago suebakia zeharkatzen eta kolpe bakarrean helmugara iristen saiatu beharrik. Hau ez da biderik azkarrena.

Orokorrean, emaitzak ez dira txarrak, hala ere, semrush.com-ek 8.8s-ko mediana du, eta 75 pertzentilak 9.4s (proba berean).
Eta aurrera jarraitu baino lehen, digresio liriko labur bat egin nahiko nuke.

Digresio lirikoa

Erabiltzailea gunera sartu ondoren www.semrushchina.cn, Txinako DNS zerbitzari "azkarren" bidez konpontzen dena, HTTP eskaera gure soluzio azkarretik pasatzen da. Erantzuna bide beretik itzultzen da, baina domeinua JS script guztietan, HTML orrialdeetan eta web-orriko beste elementu batzuetan zehazten da. semrush.com orria errendatzean kargatu behar diren baliabide gehigarrietarako. Hau da, bezeroak A-erregistro "nagusia" ebazten du www.semrushchina.cn eta tunel azkarrera sartzen da, azkar erantzun bat jasotzen du - dioen HTML orria:

• deskargatu halako eta halako js sso.semrush.com-etik,
• Lortu CSS fitxategiak cdn.semrush.com-etik,
• eta atera argazki batzuk dab.semrush.com-etik
• eta abar.

Nabigatzailea baliabide hauetarako “kanpoko” Internetera joaten hasten da, aldi bakoitzean erantzun denbora jaten duen suebaki batetik igaroz.

Baina aurreko probak emaitzak erakusten ditu orrialdean baliabiderik ez dagoenean semrush.combakarra semrushchina.cn, eta *.semrushchina.cn Shenzhen-ko makina birtualaren helbidea ebazten du gero tunelean sartzeko.

Horrela bakarrik, ahalik eta trafiko guztia ahalik eta gehien bultzatuz zure irtenbidearen bidez Txinako suebakia azkar pasatzeko, abiadura onargarriak eta webguneen erabilgarritasun-adierazleak lor ditzakezu, baita soluzio proben emaitza zintzoak ere.
Taldearen produktuaren aldetik kode editatu gabe egin dugu hau.

Azpiiragazkia

Konponbidea arazo hau azaleratu eta ia berehala jaio zen. Behar genuen POC (Kontzeptuaren froga) gure suebakiaren sartze-soluzioak benetan ondo funtzionatzen dutela. Horretarako, guneko trafiko guztia soluzio honetan bildu behar duzu ahalik eta gehien. Eta aplikatu genuen azpiiragazkia nginx-en.

Azpiiragazkia nginx-en nahiko modulu sinplea da, erantzunaren gorputzeko lerro bat beste lerro batera aldatzeko aukera ematen duena. Beraz, agerraldi guztiak aldatu ditugu semrush.com on semrushchina.cn erantzun guztietan.

Eta... ez zuen funtzionatu backendetatik eduki konprimitua jaso genuelako, beraz, azpiiragazkiak ez zuen beharrezko lerroa aurkitu. Beste tokiko zerbitzari bat gehitu behar izan nion nginx-i, erantzuna deskonprimitu eta hurrengo zerbitzari lokalari pasatu, jada lanpetuta zegoen katea ordezkatzen, konprimitzen eta kateko hurrengo proxy zerbitzariari bidaltzen.

Ondorioz, non jasoko luke bezeroak .semrush.com, jaso zuen .semrushchina.cn eta obeki ibili zen gure erabakia.

Hala ere, ez da nahikoa domeinua modu batean aldatzea, backendek semrush.com espero baitute bezeroaren ondorengo eskaeretan. Horren arabera, norabide bakarreko ordezkapena egiten den zerbitzari berean, adierazpen erregular soil bat erabiliz, eskaeraren azpidomeinua lortzen dugu, eta ondoren egingo dugu. proxy_pass aldagaiarekin $host, erakusketan $subdomain.semrush.com. Nahasia dirudi, baina funtzionatzen du. Eta ondo funtzionatzen du. Logika desberdinak behar dituzten domeinu indibidualetarako, besterik gabe, sortu zure zerbitzari-blokeak eta egin bereizitako konfigurazio bat. Jarraian, nginx konfigurazioak laburtzen dira eskema hau argitzeko eta erakusteko.

Ondorengo konfigurazio honek Txinako eskaera guztiak prozesatzen ditu .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;
    }
}

Konfigurazio honek proxy-a da localhost 83 atakara, eta konfigurazio hau zain dago han:

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

Berriro diot, hauek moztutako konfigurazioak dira.

Horrelako. Konplikatua dirudi, baina hitzez da. Izan ere, dena arbia lurrunetan baino sinpleagoa da :)

Digresioaren amaiera

Pixka batean pozik egon ginen, IPSEC tunelak erortzearen inguruko mitoa baieztatu gabe zegoelako. Baina orduan tunelak erortzen hasi ziren. Egunean hainbat aldiz minutu batzuetan. Pixka bat, baina hori ez zitzaigun komeni. Bi tunelak bideratzaile berean Ali aldean amaitzen zirenez, agian eskualdeko arazo bat zela erabaki genuen eta babeskopia eskualdea igo behar genuela.

Jaso zuten. Tunelak une ezberdinetan huts egiten hasi ziren, baina hutsegiteak ondo funtzionatu zuen nginx-en gorako mailan. Baina orduan tunelak gutxi gorabehera aldi berean erortzen hasi ziren 🙂 Eta 502 eta 504 berriro hasi ziren. Uptime okertzen hasi zen, beraz, aukera lantzen hasi ginen Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - Alibaba Cloud-eko eskualde ezberdinetako bi VPCren konektibitatea da, hau da, hodeiko edozein eskualdetako sare pribatuak elkarren artean konekta ditzakezu. Eta garrantzitsuena: kanal honek nahiko zorrotza du SLA. Oso egonkorra da bai abiaduran bai denboran. Baina inoiz ez da hain erraza:

• OSO zaila da lortzea Txinako herritarrak edo pertsona juridikoak ez bazara,
• Kanalaren edukiera megabit bakoitzeko ordaindu behar duzu.

Konektatzeko aukera izatea Txina kontinentala и Atzerritik, CEN bat sortu genuen Ali bi eskualderen artean: cn-shenzhen и gu-ekialde-1 (guretik hurbilen dagoen puntua-ekialde4). Alietan gu-ekialde-1 beste makina birtual bat planteatu zuen, bat gehiago egon dadin hop.

Honela atera zen:

Arakatzailearen probaren emaitzak behean daude:

Erabaki
Funtzionamendu
median
75 ehunekoa
95 ehunekoa

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Errendimendua IPSEC baino apur bat hobea da. Baina IPSEC bidez 100 Mbit/s-ko abiaduran deskarga dezakezu eta CEN bidez 5 Mbit/s eta gehiagoko abiaduran soilik.

Hibrido bat dirudi, ezta? Konbinatu IPSEC abiadura eta CEN egonkortasuna.

Hauxe egin genuen, IPSEC zein CEN bidez trafikoa ahalbidetuz IPSEC tunelaren hutsegiterik gertatuz gero. Egonkortasun-denbora askoz ere handiagoa izan da, baina gunea kargatzeko abiadurak asko uzten du oraindik. Orduan jada erabili eta probatu genituen zirkuitu guztiak marraztu nituen, eta zirkuitu honi GCP apur bat gehiago gehitzen saiatzea erabaki nuen, hots. txapela.

txapela

txapela - Is Karga-balantzatzaile globala (edo Google Cloud Load Balancer). Guretzat abantaila garrantzitsu bat du: CDN baten testuinguruan dauka anycast IP, trafikoa bezeroarengandik hurbilen dagoen datu-zentrora bideratzeko aukera ematen duena, trafikoa azkar Google-ren sare azkarrera sar dadin eta gutxiago Internet "ohiko"tik igaro dadin.

Bi aldiz pentsatu gabe, planteatu genuen HTTP/HTTPS LB Gure makina birtualak azpiiragazkia duten GCPn eta backend gisa instalatu ditugu.

Hainbat eskema zeuden:

• erabiltzea Cloudflare Txinako sarea, baina oraingoan Origin-ek globala zehaztu beharko luke IP GLB.
• Amaitu bezeroak hemen cn-shenzhen, eta hortik zuzenean proxy trafikoa txapela.
• Joan zuzenean Txinatik txapela.
• Amaitu bezeroak hemen cn-shenzhen, hortik proxy asia-ekialdea1 IPSEC bidez (in gu-ekialde4 CEN bidez), handik GLBra joan (lasai, behean argazkia eta azalpena egongo dira)

Aukera hauek guztiak eta beste hainbat hibrido probatu ditugu:

• Cloudflare + GLB

Eskema hau ez zitzaigun egokitu denboraren eta DNS akatsen ondorioz. Baina proba CF aldean akatsa konpondu aurretik egin zen, agian hobe da orain (hala ere, honek ez du HTTP denbora-mugarik baztertzen).

• Ali + GLB

Eskema hau ere ez zitzaigun ondo funtzionamendu-denborari dagokionez, izan ere GLB sarritan erortzen zen denbora onargarrian edo denbora-muga onargarrian konektatzeko ezintasunagatik, Txina barneko zerbitzari batentzat GLB helbidea kanpoan geratzen baita, eta, beraz, atzean. Txinako suebakia. Magia ez zen gertatu.

• GLB bakarrik

Aurrekoaren antzeko aukera, baina Txinan bertan ez zituen zerbitzariak erabiltzen: trafikoa zuzenean GLBra joaten zen (DNS erregistroak aldatu ziren). Horren arabera, emaitzak ez ziren onak izan, Internet hornitzaile arrunten zerbitzuak erabiltzen dituzten txinatar bezero arruntek suebakia pasatzean Ali Cloud baino egoera askoz okerragoa baita.

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

Hemen irtenbide guztien artean onena erabiltzea erabaki dugu:

• egonkortasuna eta CEN-en SLA bermatua
• IPSEC-en abiadura handia
• Google-ren sare "bizkorra" eta bere anycast.

Eskemak honelako itxura du: erabiltzaileen trafikoa makina birtual batean amaitzen da ch-shenzhen. Nginx upstream-ak hor konfiguratzen dira, eta horietako batzuk IPSEC tunelaren beste muturrean kokatutako IP zerbitzari pribatuetara seinalatzen dute, eta goranzko batzuek CEN-ren beste aldean dauden zerbitzarien helbide pribatuetara. IPSEC eskualdean konfiguratuta dago asia-ekialdea1 GCPn (konponbidea sortu zen garaian Txinatik gertuen zegoen eskualdea zen. GCPk Hong Kongen ere badu presentzia). CEN - eskualdera gu-ekialde1 Ali Hodeian.

Ondoren, bi muturretako trafikoa bideratu zen anycast IP GLB, hau da, Googleren presentzia puntu hurbilenera, eta bere sareetatik joan zen eskualdera gu-ekialde4 GCPn, bertan ordezko makina birtualak zeuden (nginx-en azpiiragazkia).

Soluzio hibrido honek, espero genuen bezala, teknologia bakoitzaren onurak aprobetxatu zituen. Orokorrean, trafikoa IPSEC azkarretik pasatzen da, baina arazoak hasten badira, azkar eta minutu batzuez zerbitzari hauek urtik kanpora bota eta CEN bidez soilik bidaltzen dugu trafikoa tunela egonkortu arte.

Goiko zerrendako 4. irtenbidea ezarriz, nahi genuena eta negozioak une horretan eskatzen ziguna lortu genuen.

Soluzio berriaren arakatzailearen probaren emaitzak aurrekoekin alderatuta:

Erabaki
Funtzionamendu
median
75 ehunekoa
95 ehunekoa

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

Inplementatu genuen soluzioan dena ona da, baina ez dago eskualde mailan eta baita hiri mailan trafikoa bizkor dezakeen CDNrik. Teorian, honek azken erabiltzaileentzako gunea bizkortu beharko luke CDN hornitzailearen komunikazio kanal azkarrak erabiliz. Eta denbora guztian pentsatzen genuen. Eta orain, proiektuaren hurrengo iteraziorako garaia iritsi da: Txinan CDN hornitzaileak bilatu eta probatzea.

Eta honen berri emango dizuet hurrengo, azken zatian :)

Iturria: www.habr.com