Kiel ni trarompis la Grandan Ĉinan Fajromuron (Parto 2)

Saluton!

Nikita estas kun vi denove, sistema inĝeniero de la firmao SEMrush. Kaj kun ĉi tiu artikolo mi daŭrigas la rakonton pri kiel ni elpensis solvon Ĉina Fajromuro por nia servo semrush.com.

В antaŭa parto Mi diris:

• kiaj problemoj aperas post la decido "Ni devas funkcii nian servon en Ĉinio"
• Kiajn problemojn havas la ĉina Interreto?
• kial vi bezonas ICP-licencon?
• kiel kaj kial ni decidis testi niajn testejojn per Catchpoint
• kio estis la rezulto de nia unua solvo bazita sur Cloudflare Ĉina Reto
• Kiel ni trovis cimon en Cloudflare DNS

Ĉi tiu parto estas la plej interesa, laŭ mi, ĉar ĝi temigas specifajn teknikajn realigojn de surscenigo. Kaj ni komencos, aŭ prefere daŭrigos, per Alibaba Nubo.

Alibaba Nubo

Alibaba Nubo estas sufiĉe granda nuba provizanto, kiu havas ĉiujn servojn, kiuj permesas al ĝi honeste nomi sin nuba provizanto. Estas bone, ke ili havas la ŝancon registriĝi por eksterlandaj uzantoj, kaj ke la plej granda parto de la retejo estas tradukita en la anglan (por Ĉinio tio estas lukso). En ĉi tiu nubo, vi povas labori kun multaj regionoj de la mondo, kontinenta Ĉinio, same kiel Oceana Azio (Honkongo, Tajvano, ktp.).

IPSEC

Ni komencis per geografio. Ĉar nia prova retejo troviĝis sur Google Cloud, ni bezonis "ligi" Alibaba Cloud kun GCP, do ni malfermis liston de lokoj en kiuj ĉeestas Google. En tiu momento ili ankoraŭ ne havis propran datumcentron en Honkongo.
La plej proksima regiono montriĝis azio-oriento1 (Tajvano). Ali rezultis esti la plej proksima regiono de kontinenta Ĉinio al Tajvano cn-ŝenĵen (Ŝenĵeno).

Kun la helpo de terraform priskribis kaj altigis la tutan infrastrukturon en GCP kaj Ali. 100 Mbit/s tunelo inter la nuboj supreniris preskaŭ tuj. Flanke de Shenzhen kaj Tajvano, prokurantaj virtualaj maŝinoj estis levitaj. En Ŝenĵeno, uzanttrafiko estas ĉesigita, prokurita tra tunelo al Tajvano, kaj de tie ĝi iras rekte al la ekstera IP de nia servo en us-oriento (Usono Orienta marbordo). Pingu inter virtualaj maŝinoj per tunelo 24ms, kio ne estas tiel malbona.

Samtempe ni metis testareon enen Alibaba Cloud DNS. Post delegado de la zono al NS Ali, rezoluciotempo malpliiĝis de 470 ms al 50 m. Antaŭ tio, la zono estis ankaŭ sur Cloudlfare.

Paralele al la tunelo al azio-oriento1 levis alian tunelon de Shenzhen rekte al us-oriento4. Tie ili kreis pli da prokuraj virtualaj maŝinoj kaj komencis testi ambaŭ solvojn, direktante testan trafikon per Kuketoj aŭ DNS. La testbenko estas priskribita skeme en la sekva figuro:

Latenteco por tuneloj montriĝis kiel sekvas:
Ali cn-ŝenĵen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint-retumilo-testoj raportis bonegan plibonigon.

Komparu testrezultojn por du solvoj:

decido
Senkulpa
Meza
75 Procento
95 Procento

cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Ĉi tio estas datumoj de solvo, kiu uzas IPSEC-tunelon per azio-oriento1. Pere de ni-oriento4 la rezultoj estis pli malbonaj, kaj estis pli da eraroj, do mi ne donos la rezultojn.

Surbaze de la rezultoj de ĉi tiu provo de du tuneloj, unu el kiuj finiĝas en la plej proksima regiono al Ĉinio, kaj la alia ĉe la fina celloko, evidentiĝis, ke gravas "eliri" el sub la ĉina fajroŝirmilo tiel rapide kiel ebla, kaj poste uzu rapidajn retojn (CDN-provizantoj, nubaj provizantoj, ktp.). Ne necesas provi trairi la fajroŝirmilon kaj atingi vian celon per unu ŝovo. Ĉi tio ne estas la plej rapida maniero.

Ĝenerale, la rezultoj ne estas malbonaj, tamen, semrush.com havas medianon de 8.8s, kaj 75 Percentilo 9.4s (sur la sama testo).
Kaj antaŭ ol pluiri, mi ŝatus fari mallongan lirikan deturniĝon.

Lirika devio

Post kiam la uzanto eniras la retejon www.semrushchina.cn, kiu solvas per "rapidaj" ĉinaj DNS-serviloj, la HTTP-peto trairas nian rapidan solvon. La respondo estas resendita laŭ la sama vojo, sed la domajno estas specifita en ĉiuj JS-skriptoj, HTML-paĝoj kaj aliaj elementoj de la retpaĝo semrush.com por pliaj rimedoj, kiuj devas esti ŝargitaj kiam la paĝo estas prezentita. Tio estas, la kliento solvas la "ĉefan" A-rekordon www.semrushchina.cn kaj iras en la rapidan tunelon, rapide ricevas respondon - HTML-paĝon kiu diras:

• elŝutu tiajn js de sso.semrush.com,
• Akiru la CSS-dosierojn de cdn.semrush.com,
• kaj ankaŭ prenu kelkajn bildojn de dab.semrush.com
• kaj tiel plu.

La retumilo komencas iri al la "ekstera" Interreto por ĉi tiuj rimedoj, ĉiufoje trapasante fajroŝirmilon, kiu manĝas respondan tempon.

Sed la antaŭa testo montras la rezultojn kiam ne estas rimedoj sur la paĝo semrush.comnur semrushchina.cn, kaj *.semrushchina.cn solvas al la adreso de la virtuala maŝino en Shenzhen por tiam eniri la tunelon.

Nur tiamaniere, puŝante ĉian eblan trafikon al la maksimumo tra via solvo por rapide trapasi la ĉinan fajroŝirmilon, vi povas akiri akcepteblajn rapidojn kaj retejajn havebleco-indikilojn, same kiel honestajn rezultojn de solvotestoj.
Ni faris tion sen ununura koda redakto ĉe la produktoflanko de la teamo.

Subfiltrilo

La solvo naskiĝis preskaŭ tuj post kiam ĉi tiu problemo aperis. Ni bezonis PoC (Pruvo de Koncepto) ke niaj solvoj pri penetro de fajroŝirmiloj vere funkcias bone. Por fari tion, vi devas envolvi la tutan retejan trafikon en ĉi tiun solvon kiel eble plej multe. Kaj ni kandidatiĝis subfiltrilo en nginx.

Subfiltrilo estas sufiĉe simpla modulo en nginx, kiu ebligas al vi ŝanĝi unu linion en la respondkorpo al alia linio. Do ni ŝanĝis ĉiujn okazojn semrush.com sur semrushchina.cn en ĉiuj respondoj.

Kaj... ĝi ne funkciis ĉar ni ricevis kunpremitan enhavon de la backends, do subfiltrilo ne trovis la postulatan linion. Mi devis aldoni alian lokan servilon al nginx, kiu malkunpremis la respondon kaj transdonis ĝin al la sekva loka servilo, kiu jam estis okupata anstataŭante la ĉenon, kunpremante ĝin kaj sendi ĝin al la sekva prokura servilo en la ĉeno.

Kiel rezulto, kie ricevus la kliento .semrush.com, li ricevis .semrushchina.cn kaj obeeme trairis nian decidon.

Tamen, ne sufiĉas simple ŝanĝi la domajnon unudirekte, ĉar la backends ankoraŭ atendas semrush.com en postaj petoj de la kliento. Sekve, sur la sama servilo kie la unudirekta anstataŭigo estas farita, uzante simplan regulan esprimon ni ricevas la subdomajnon de la peto, kaj tiam ni faras prokura_paso kun variablo $gastiganto, ekspoziciita en $subdomajno.semrush.com. Ĝi povas ŝajni konfuza, sed ĝi funkcias. Kaj ĝi funkcias bone. Por individuaj domajnoj kiuj postulas malsaman logikon, simple kreu viajn proprajn servilblokojn kaj faru apartan agordon. Malsupre estas mallongigitaj nginx-agordoj por klareco kaj pruvo de ĉi tiu skemo.

La sekva agordo procesas ĉiujn petojn de Ĉinio al .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;
    }
}

Ĉi tiu agordo prokurigas al localhost al pordo 83, kaj la sekva agordo atendas tie:

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

Mi ripetas, ĉi tiuj estas tranĉitaj agordoj.

Tiel. Ĝi povas aspekti komplika, sed ĝi estas en vortoj. Fakte, ĉio estas pli simpla ol vaporitaj rapoj :)

Fino de digreso

Dum kelka tempo ni estis feliĉaj ĉar la mito pri falantaj IPSEC-tuneloj ne estis konfirmita. Sed tiam la tuneloj komencis fali. Plurfoje tage dum kelkaj minutoj. Iom, sed tio ne konvenis al ni. Ĉar ambaŭ tuneloj estis finitaj ĉe la flanko de Ali per la sama enkursigilo, ni decidis, ke eble tio estas regiona problemo kaj ni bezonas levi la rezervan regionon.

Ili prenis ĝin. La tuneloj komencis malsukcesi en malsamaj tempoj, sed la malsukceso funkciis bone por ni ĉe la kontraŭflua nivelo en nginx. Sed tiam la tuneloj komencis fali proksimume en la sama tempo 🙂 Kaj denove komenciĝis 502 kaj 504. Aktivtempo komencis plimalboniĝi, do ni komencis labori pri la opcio kun Alibaba CEN (Nuba Enterprise Network).

CEN

CEN - ĉi tio estas la konektebleco de du VPC-oj de malsamaj regionoj ene de Alibaba Cloud, tio estas, vi povas konekti privatajn retojn de iuj regionoj en la nubo inter si. Kaj plej grave: ĉi tiu kanalo havas sufiĉe striktan SLA. Ĝi estas tre stabila kaj en rapideco kaj funkciado. Sed ĝi neniam estas tiel simpla:

• ĝi estas TRE malfacile akiri se vi ne estas ĉinaj civitanoj aŭ jura ento,
• Vi devas pagi por ĉiu megabito da kanalkapacito.

Havante la ŝancon konekti Mainland Ĉinio и Eksterlande, ni kreis CEN inter du Ali-regionoj: cn-ŝenĵen и us-oriento-1 (plej proksima punkto al ni-oriento4). En Ali us-oriento-1 levis alian virtualan maŝinon por ke estu unu pli hop.

Ĝi rezultis jene:

La retumiltestrezultoj estas sube:

decido
Senkulpa
Meza
75 Procento
95 Procento

cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

La rendimento estas iomete pli bona ol IPSEC. Sed per IPSEC vi povas elŝuti kun rapido de 100 Mbit/s, kaj per CEN nur kun rapido de 5 Mbit/s kaj pli.

Sonas kiel hibrido, ĉu ne? Kombinu IPSEC-rapidecon kaj CEN-stabilecon.

Jen kion ni faris, permesante trafikon tra kaj IPSEC kaj CEN en la okazo de fiasko de la IPSEC-tunelo. Aktivtempo fariĝis multe pli alta, sed la rapideco de ŝarĝo de retejo ankoraŭ lasas multon por deziri. Poste mi desegnis ĉiujn cirkvitojn, kiujn ni jam uzis kaj provis, kaj decidis provi aldoni iom pli da GCP al ĉi tiu cirkvito, nome GLB.

GLB

GLB Estas Tutmonda Ŝarĝbalancilo (aŭ Google Cloud Load Balancer). Ĝi havas gravan avantaĝon por ni: en la kunteksto de CDN ĝi havas anycast IP, kiu ebligas al vi direkti trafikon al la datumcentro plej proksima al la kliento, tiel ke trafiko rapide eniras la rapidan reton de Guglo kaj malpli iras tra la "regula" Interreto.

Sen pripensi dufoje, ni levis HTTP/HTTPS LB Ni instalis niajn virtualajn maŝinojn kun subfiltrilo en GCP kaj kiel backend.

Ekzistis pluraj skemoj:

• Uzu Cloudflare Ĉina Reto, sed ĉi-foje Origino devus specifi tutmondan IP GLB.
• Nuligi klientojn ĉe cn-ŝenĵen, kaj de tie prokuru la trafikon rekte al GLB.
• Iru rekte el Ĉinio al GLB.
• Nuligi klientojn ĉe cn-ŝenĵen, de tie prokurilo al azio-oriento1 per IPSEC (en us-oriento4 per CEN), de tie iru al GLB (trankvile, estos bildo kaj klarigo sube)

Ni testis ĉiujn ĉi tiujn eblojn kaj plurajn pli hibridajn:

• Cloudflare + GLB

Ĉi tiu skemo ne konvenis al ni pro funkciada tempo kaj DNS-eraroj. Sed la provo estis efektivigita antaŭ ol la cimo estis riparita ĉe la CF-flanko, eble ĝi estas pli bona nun (tamen, ĉi tio ne ekskludas HTTP-tempon).

• Ali + GLB

Ĉi tiu skemo ankaŭ ne konvenis al ni rilate al tempodaŭro, ĉar GLB ofte elfalis de la kontraŭfluo pro la malebleco konekti en akceptebla tempo aŭ timeout, ĉar por servilo ene de Ĉinio, la GLB-adreso restas ekstere, kaj tial malantaŭ la Ĉina fajroŝirmilo. La magio ne okazis.

• GLB nur

Opcio simila al la antaŭa, nur ĝi ne uzis servilojn en Ĉinio mem: la trafiko iris rekte al GLB (la DNS-rekordoj estis ŝanĝitaj). Sekve, la rezultoj ne estis kontentigaj, ĉar ordinaraj ĉinaj klientoj uzantaj la servojn de ordinaraj interretaj provizantoj havas multe pli malbonan situacion kun preterpaso de la fajroŝirmilo ol Ali Cloud.

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

Ĉi tie ni decidis uzi la plej bonan el ĉiuj solvoj:

• stabileco kaj garantiita SLA de CEN
• alta rapideco de IPSEC
• La "rapida" reto de Google kaj ĝia anycast.

La skemo aspektas kiel ĉi tio: uzanttrafiko finiĝas sur virtuala maŝino en ĉ-ŝenĵen. Nginx-supren-fluoj estas agorditaj tie, kelkaj el kiuj montras al privataj IP-serviloj situantaj ĉe la alia fino de la IPSEC-tunelo, kaj iuj kontraŭfluoj montras privatajn adresojn de serviloj sur la alia flanko de la CEN. IPSEC agordita al regiono azio-oriento1 en GCP (estis la plej proksima regiono al Ĉinio en la tempo kiam la solvo estis kreita. GCP nun ankaŭ havas ĉeeston en Honkongo). CEN - al regiono us-oriento1 en Ali Nubo.

Tiam trafiko de ambaŭ finoj estis direktita al anycast IP GLB, tio estas, al la plej proksima punkto de ĉeesto de Guglo, kaj iris tra ĝiaj retoj al la regiono us-oriento4 en GCP, en kiu estis anstataŭaj virtualaj maŝinoj (kun subfiltrilo en nginx).

Ĉi tiu hibrida solvo, kiel ni atendis, utiligis la avantaĝojn de ĉiu teknologio. Ĝenerale, trafiko trairas rapidan IPSEC, sed se problemoj komenciĝas, ni rapide kaj dum kelkaj minutoj forĵetas ĉi tiujn servilojn el la kontraŭfluo kaj sendas trafikon nur tra CEN ĝis la tunelo stabiliĝas.

Realigante la 4-an solvon el la supra listo, ni atingis tion, kion ni volis kaj kion la komerco postulis de ni tiutempe.

Testrezultoj de la retumilo por la nova solvo kompare kun antaŭaj:

decido
Senkulpa
Meza
75 Procento
95 Procento

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

Ĉio estas bona en la solvo, kiun ni efektivigis, sed ne ekzistas CDN, kiu povus akceli trafikon je la regiona kaj eĉ urba nivelo. En teorio, ĉi tio devus akceli la retejon por finaj uzantoj uzante la rapidajn komunikajn kanalojn de la CDN-provizanto. Kaj ni pensis pri tio la tutan tempon. Kaj nun, venis la tempo por la sekva ripeto de la projekto: serĉado kaj testado de CDN-provizantoj en Ĉinio.

Kaj mi rakontos al vi pri tio en la sekva, fina parto :)

fonto: www.habr.com