Kako smo probili Veliki kineski vatrozid (2. dio)

Pozdrav!

S vama je opet Nikita, sistem inženjer iz tvrtke SEMrush. I ovim člankom nastavljam priču o tome kako smo došli do zaobilaznog rješenja Kineski vatrozid za našu uslugu semrush.com.

В prethodni dio rekao sam:

• koji problemi nastaju nakon donošenja odluke "Moramo omogućiti da naša usluga radi u Kini"
• Kakve probleme ima kineski Internet?
• zašto vam je potrebna ICP licenca?
• kako i zašto smo odlučili testirati naše testne uređaje s Catchpointom
• što je bio rezultat našeg prvog rješenja temeljenog na Cloudflare China Network
• Kako smo pronašli grešku u Cloudflare DNS-u

Ovaj dio je po mom mišljenju najzanimljiviji jer se fokusira na specifične tehničke izvedbe inscenacije. I mi ćemo započeti, odnosno nastaviti, s Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud je prilično veliki pružatelj usluga oblaka, koji ima sve usluge koje mu omogućuju da se iskreno nazove pružateljem usluga oblaka. Dobro je što imaju mogućnost registracije za strane korisnike i što je većina stranica prevedena na engleski (za Kinu je to luksuz). U ovom oblaku možete raditi s mnogim regijama svijeta, kontinentalnom Kinom, kao i oceanskom Azijom (Hong Kong, Tajvan itd.).

IPSEC

Počeli smo s geografijom. Budući da se naše testno mjesto nalazilo na Google Cloudu, morali smo “povezati” Alibaba Cloud s GCP-om, pa smo otvorili popis lokacija na kojima je Google prisutan. U tom trenutku još nisu imali svoj podatkovni centar u Hong Kongu.
Pokazalo se da je najbliža regija azija-istok1 (Tajvan). Ispostavilo se da je Ali Tajvanu najbliža regija kontinentalne Kine cn-Shenzhen (Shenzhen).

S terraform opisao i podigao cjelokupnu infrastrukturu u GCP i Ali. Tunel od 100 Mbit/s između oblaka digao se gotovo trenutno. Na strani Shenzhena i Tajvana podignuti su proxy virtualni strojevi. U Shenzhenu se korisnički promet prekida, prosljeđuje kroz tunel do Tajvana, a od tamo ide izravno na vanjski IP naše usluge u nas-istok (istočna obala SAD-a). Ping između virtualnih strojeva putem tunela 24ms, što i nije tako loše.

Istovremeno smo postavili testno područje Alibaba Cloud DNS. Nakon delegiranja zone NS Aliju, vrijeme razlučivanja smanjilo se s 470 ms na 50 ms. Prije ovoga, zona je također bila na Cloudlfareu.

Paralelno s tunelom do azija-istok1 podigao još jedan tunel iz Shenzhena izravno u nas-istok4. Tamo su stvorili više proxy virtualnih strojeva i počeli testirati oba rješenja, usmjeravajući testni promet pomoću kolačića ili DNS-a. Ispitni uređaj shematski je opisan na sljedećoj slici:

Pokazalo se da je latencija za tunele sljedeća:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

Testovi preglednika Catchpoint izvijestili su o izvrsnom poboljšanju.

Usporedite rezultate testa za dva rješenja:

odluka
Uptime
srednja
75 percentila
95 percentila

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Ovo su podaci iz rješenja koje koristi IPSEC tunel putem azija-istok1. Kroz us-east4 rezultati su bili lošiji, a grešaka je bilo više pa neću iznositi rezultate.

Na temelju rezultata ovog testa dvaju tunela, od kojih jedan završava u regiji najbližoj Kini, a drugi na krajnjem odredištu, postalo je jasno da je važno što prije “izroniti” ispod kineskog vatrozida. moguće, a zatim koristiti brze mreže (pružatelji CDN-a, pružatelji usluga u oblaku itd.). Nema potrebe pokušavati proći kroz vatrozid i jednim potezom stići na odredište. Ovo nije najbrži način.

Općenito, rezultati nisu loši, međutim semrush.com ima medijan od 8.8s, a 75 Percentila 9.4s (na istom testu).
I prije nego što nastavim, želio bih napraviti kratku lirsku digresiju.

Lirska digresija

Nakon što korisnik uđe na stranicu www.semrushchina.cn, koji rješava putem "brzih" kineskih DNS poslužitelja, HTTP zahtjev prolazi kroz naše brzo rješenje. Odgovor se vraća istim putem, ali je domena navedena u svim JS skriptama, HTML stranicama i drugim elementima web stranice semrush.com za dodatne resurse koji se moraju učitati kada se stranica prikazuje. Odnosno, klijent rješava "glavni" A-zapis www.semrushchina.cn i odlazi u brzi tunel, brzo prima odgovor - HTML stranicu koja navodi:

• preuzmite takav i takav js sa sso.semrush.com,
• Preuzmite CSS datoteke s cdn.semrush.com,
• i uzmi neke slike s dab.semrush.com
• i tako dalje.

Preglednik počinje ići na "vanjski" Internet za te resurse, svaki put prolazeći kroz vatrozid koji jede vrijeme odziva.

Ali prethodni test pokazuje rezultate kada na stranici nema resursa semrush.comsamo semruščina.cn, a *.semrushchina.cn rješava na adresu virtualnog stroja u Shenzhenu kako bi zatim ušao u tunel.

Samo na taj način, gurajući sav mogući promet do maksimuma kroz svoje rješenje za brzo prolaženje kineskog vatrozida, možete dobiti prihvatljive brzine i pokazatelje dostupnosti web stranice, kao i poštene rezultate testova rješenja.
Učinili smo to bez ikakve izmjene koda na strani proizvoda tima.

Potfilter

Rješenje se rodilo gotovo odmah nakon što je ovaj problem isplivao na površinu. Trebali smo PoC (Dokaz koncepta) da naša rješenja za prodor vatrozida stvarno dobro funkcioniraju. Da biste to učinili, morate što je više moguće umotati sav promet stranice u ovo rješenje. I prijavili smo se podfilter u nginxu.

Potfilter je prilično jednostavan modul u nginxu koji vam omogućuje promjenu jedne linije u tijelu odgovora u drugu liniju. Tako smo promijenili sve pojave semrush.com na semruščina.cn u svim odgovorima.

I... nije radilo jer smo primili komprimirani sadržaj iz pozadine, pa subfilter nije pronašao traženi redak. Morao sam dodati još jedan lokalni poslužitelj u nginx, koji je dekomprimirao odgovor i proslijedio ga sljedećem lokalnom poslužitelju, koji je već bio zauzet zamjenom niza, komprimiranjem i slanjem na sljedeći proxy poslužitelj u lancu.

Kao rezultat toga, gdje bi klijent primio .semrush.com, primio je .semrushchina.cn i poslušno prošetao kroz našu odluku.

Međutim, nije dovoljno jednostavno promijeniti domenu na jedan način, jer pozadina i dalje očekuje semrush.com u narednim zahtjevima klijenta. Sukladno tome, na istom poslužitelju gdje se vrši jednosmjerna zamjena, pomoću jednostavnog regularnog izraza dobivamo poddomenu iz zahtjeva, a zatim radimo proxy_pass s varijablom $ domaćin, izloženo u $poddomena.semrush.com. Možda se čini zbunjujuće, ali djeluje. I dobro radi. Za pojedinačne domene koje zahtijevaju različitu logiku, jednostavno kreirajte vlastite blokove poslužitelja i napravite zasebnu konfiguraciju. Ispod su skraćene nginx konfiguracije radi jasnoće i demonstracije ove sheme.

Sljedeća konfiguracija obrađuje sve zahtjeve od Kine do .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;
    }
}

Ova konfiguracija služi kao proksi localhost na port 83, a tamo čeka sljedeća konfiguracija:

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

Ponavljam, ovo su izrezane konfiguracije.

ovako. Možda izgleda komplicirano, ali tako je u riječima. Zapravo, sve je jednostavnije od repe na pari :)

Kraj digresije

Neko smo vrijeme bili sretni jer mit o padajućim IPSEC tunelima nije potvrđen. Ali onda su tuneli počeli padati. Nekoliko puta dnevno po nekoliko minuta. Malo, ali to nam nije odgovaralo. Budući da su oba tunela prekinuta na strani Ali na istom usmjerivaču, odlučili smo da je to možda regionalni problem i da moramo podići rezervnu regiju.

Pokupili su ga. Tuneli su počeli kvariti u različito vrijeme, ali failover je dobro funkcionirao za nas na uzvodnoj razini u nginxu. Ali onda su tuneli počeli padati otprilike u isto vrijeme 🙂 I opet su počeli 502 i 504. Vrijeme neprekidnog rada počelo se pogoršavati, pa smo počeli raditi na opciji s Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - ovo je povezivanje dva VPC-a iz različitih regija unutar Alibaba Clouda, odnosno možete međusobno povezati privatne mreže bilo koje regije unutar oblaka. I što je najvažnije: ovaj kanal ima prilično stroge SLA. Vrlo je stabilan i u brzini i u vremenu neprekidnog rada. Ali nikad nije tako jednostavno:

• JAKO ju je teško dobiti ako niste kineski državljanin ili pravna osoba,
• Morate platiti za svaki megabit kapaciteta kanala.

Imati priliku za povezivanje Kontinentalna Kina и preko mora, stvorili smo CEN između dvije Ali regije: cn-Shenzhen и nas-istok-1 (najbliža točka nama-istok4). U Aliju nas-istok-1 podigao još jedan virtualni stroj tako da postoji još jedan hmelj.

Ispalo je ovako:

Rezultati testa preglednika su u nastavku:

odluka
Uptime
srednja
75 percentila
95 percentila

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Performanse su nešto bolje od IPSEC-a. Ali preko IPSEC-a potencijalno možete preuzimati brzinom od 100 Mbit/s, a preko CEN-a samo brzinom od 5 Mbit/s i više.

Zvuči kao hibrid, zar ne? Kombinirajte IPSEC brzinu i CEN stabilnost.

To je ono što smo učinili, dopuštajući promet kroz IPSEC i CEN u slučaju kvara IPSEC tunela. Vrijeme neprekidnog rada postalo je mnogo veće, ali brzina učitavanja stranice još uvijek ostavlja mnogo za poželjeti. Zatim sam nacrtao sve krugove koje smo već koristili i testirali, i odlučio pokušati dodati malo više GCP-a ovom krugu, naime kapa.

kapa

kapa - Je Globalni balanser opterećenja (ili Google Cloud Load Balancer). Za nas ima važnu prednost: u kontekstu CDN-a ima anycast IP, koji vam omogućuje usmjeravanje prometa u podatkovni centar najbliži klijentu, tako da promet brzo ulazi u Googleovu brzu mrežu, a manje prolazi kroz "običan" internet.

Bez razmišljanja smo podigli HTTP/HTTPS LB Instalirali smo naše virtualne strojeve s podfilterom u GCP i kao backend.

Bilo je nekoliko shema:

• Za korištenje Cloudflare kineska mreža, ali ovaj put bi Origin trebao navesti globalno IP GLB.
• Prekinite klijente na cn-Shenzhen, a odatle proxy promet izravno na kapa.
• Idite ravno iz Kine u kapa.
• Prekinite klijente na cn-Shenzhen, od tamo proxy to azija-istok1 putem IPSEC-a (in nas-istok4 putem CEN-a), odatle idite na GLB (smireno, ispod će biti slika i objašnjenje)

Testirali smo sve te opcije i još nekoliko hibridnih:

• Cloudflare + GLB

Ova shema nam nije odgovarala zbog neprekidnog rada i grešaka u DNS-u. Ali test je proveden prije nego što je pogreška ispravljena na CF strani, možda je sada bolje (međutim, to ne isključuje HTTP timeout).

• Ali + GLB

Ova nam shema također nije odgovarala u pogledu produženja rada, budući da je GLB često ispadao iz upstreama zbog nemogućnosti povezivanja u prihvatljivom vremenu ili timeoutu, jer za poslužitelj unutar Kine GLB adresa ostaje izvan, a time i iza Kineski vatrozid. Čarolija se nije dogodila.

• Samo GLB

Opcija slična prethodnoj, samo što nije koristila poslužitelje u samoj Kini: promet je išao izravno na GLB (promijenjeni su DNS zapisi). Sukladno tome, rezultati nisu bili zadovoljavajući, budući da obični kineski klijenti koji koriste usluge običnih Internet providera imaju puno goru situaciju s prolaskom firewalla nego Ali Cloud.

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

Ovdje smo odlučili upotrijebiti najbolje od svih rješenja:

• stabilnost i zajamčeni SLA od CEN-a
• velika brzina od IPSEC-a
• Googleova "brza" mreža i njezin anycast.

Shema izgleda otprilike ovako: korisnički promet se prekida na virtualnom stroju u ch-Shenzhen. Ondje su konfigurirani Nginx uzvodi, od kojih neki upućuju na privatne IP poslužitelje koji se nalaze na drugom kraju IPSEC tunela, a neki upstreami upućuju na privatne adrese poslužitelja s druge strane CEN-a. IPSEC konfiguriran za regiju azija-istok1 u GCP-u (bila je regija najbliža Kini u vrijeme kada je rješenje stvoreno. GCP je sada također prisutan u Hong Kongu). CEN - u regiju nas-istok1 u Ali Cloudu.

Zatim je promet s oba kraja usmjeren na anycast IP GLB, odnosno do najbliže točke prisutnosti Googlea, te je kroz njegove mreže otišao u regiju nas-istok4 u GCP-u, u kojem su bili zamjenski virtualni strojevi (s podfilterom u nginxu).

Ovo hibridno rješenje, kao što smo i očekivali, iskoristilo je prednosti svake tehnologije. Općenito, promet ide kroz brzi IPSEC, ali ako počnu problemi, mi brzo i na nekoliko minuta izbacujemo te servere iz uzvodnog toka i šaljemo promet samo kroz CEN dok se tunel ne stabilizira.

Implementacijom 4. rješenja s gornje liste postigli smo ono što smo željeli i što je poslovanje od nas u tom trenutku zahtijevalo.

Rezultati testa preglednika za novo rješenje u usporedbi s prethodnima:

odluka
Uptime
srednja
75 percentila
95 percentila

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

U rješenju koje smo implementirali sve je dobro, ali nema CDN-a koji bi mogao ubrzati promet na regionalnoj, pa i gradskoj razini. U teoriji, ovo bi trebalo ubrzati stranicu za krajnje korisnike korištenjem brzih komunikacijskih kanala CDN providera. I stalno smo razmišljali o tome. A sada je došlo vrijeme za sljedeću iteraciju projekta: traženje i testiranje pružatelja CDN usluga u Kini.

A o tome ću vam pričati u sljedećem, završnom dijelu :)

Izvor: www.habr.com