Kako smo probili Veliki Kineski Vatrozid (dijel 2)

Pozdrav!

Ponovno smo s vama, Nikita — sistemski inženjer iz kompanije SEMrush. Ovim člankom nastavim priču o tome kako smo smislili rješenje zaobilaženja Kineskog Vatrozida za našu uslugu semrush.com.

U u prethodnom dijelu objasnio sam:

• koji se problemi javljaju nakon što donesemo odluku 'Trebamo učiniti da naša usluga radi u Kini'
• koji problemi postoje s kineskim internetom
• zašto je potrebna ICP licenca
• kako i zašto smo odlučili testirati naše testne platforme pomoću Catchpoint
• koji su rezultati dali naš prvi model rješenja, temeljen na Cloudflare Kina mreži
• kako smo otkrili grešku u DNS Cloudflare

Ovaj dio je, po mom mišljenju, najzanimljiviji jer se fokusira na konkretne tehničke realizacije. I započet ćemo, odnosno nastaviti s Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud — prilično veliki oblačni provajder koji nudi sve usluge koje mu omogućavaju da se pošteno naziva cloud provider. Dobra stvar je što stranci mogu otvoriti nalog, i što je velika većina sajta dostupna na engleskom jeziku (za Kinu je to luksuz). U ovom oblaku možete raditi s brojnim regijama širom sveta, kopnenom Kinom, kao i Okeanskom Azijom (Hong Kong, Tajvan itd.).

IPSEC

Počeli smo s geografijom. Budući da se naš testni sajt nalazio u Google Cloud, morali smo 'povezati' Alibaba Cloud s GCP, pa smo otvorili listu lokacija gde postoji Google. Tada nisu imali svoj data centar u Hong Kongu.
Najbliža regija bila je asia-east1 (Tajvan). Najbliža regija kontinentalne Kine prema Tajvanu bila je cn-shenzhen (Shenzhen).

Pomoću terraform opisali smo i podigli cijelu infrastrukturu u GCP i Ali. Tunnela od 100 mbit/s između oblaka postavljen je gotovo odmah. Na strani Shenzhen i Tajvan podigli smo proksirajuće virtualke. U Shenzhen-u se korisnički promet terminira, prokurira kroz tunel na Tajvan, a odatle ide direktno na vanjski IP naše usluge u us-east (Istočno obala SAD-a). Ping između virtualki preko tunela 24ms, što nije toliko loše.

Istodobno smo postavili testnu zonu u Alibaba Cloud DNS. Nakon delegiranja zone na NS Ali, vrijeme rezolviranja smanjeno je sa 470 ms na 50 ms. Prije toga zona je također bila na Cloudflare.

Paralelno s tunelom do asia-east1 podigli smo još jedan tunel iz Šenžena direktno u us-east4. Tamo su stvoreni dodatni proksirajući virtuelni serveri i počeli su da mere oba rešenja, rutirajući test saobraćaj pomoću kolačića ili DNS-a. Shematski, testna stanica je opisana na sledećem crtežu:

Latency za tunele je bila sledeća:
Ali cn-shenzhen GCP asia-east1 — 24ms
Ali cn-shenzhen GCP us-east4 — 200ms

Browser testovi Catchpoint izvestili su o odličnom poboljšanju performansi.

Uporedite rezultate testova za dva rešenja:

Rešenje
Uptime
Medijan
75. percentil
95. percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

To su podaci rešenja koje koristi IPSEC tunel kroz asia-east1. Kroz us-east4 rezultati su bili lošiji, a grešaka je bilo više, tako da neću prikazivati te rezultate.

Na osnovu rezultata ovog testa dva tunela, od kojih se jedan završava u bliskoj regiji Kini, a drugi na konačnoj destinaciji, postalo je jasno da je važno što brže “izroniti” iz kineskog vatrozida, a zatim koristiti brze mreže (CDN provajdere, cloud provajdere itd.). Ne treba pokušavati proći kroz vatrozid i doći do odredišta u jednom potezu. To nije najbrži put.

U celini, rezultati su dobri, međutim, semrush.com ima medijan 8.8s, a 75. percentil 9.4s (na istom testu).
I pre nego što nastavim, želeo bih da napravim malo lirsko odražavanje.

Lirsko odmaknuće

Nakon što korisnik uđe na sajt www.semrushchina.cn, koji se rezolvira kroz “brze” kineske DNS servere, HTTP zahtev ide kroz naše brzo rešenje. Odgovor se vraća istim putem, ali u svim JS skriptama, HTML stranicama i drugim elementima veba naveden je domen semrush.com za dodatne resurse koji treba da budu učitani prilikom renderovanja stranice. Drugim rečima, klijent rezolvira “glavnu” A-zapis www.semrushchina.cn i ide u brzi tunel, brzo dobija odgovor — HTML stranicu, u kojoj piše:

• preuzmi određeni js sa sso.semrush.com,
• CSS datoteke uzmi sa cdn.semrush.com,
• i uzmi slike sa dab.semrush.com
• i tako dalje.

Pregledač počinje da ide u “spoljni” internet po tim resursima, prolazeći svaki put kroz vatrozid koji usporava odgovor.

Ali rezultati u prethodnom testu prikazali su kada na stranici nema resursa semrush.com, samo semrushchina.cn, a *.semrushchina.cn rezolvira se u adresu virtuelnog servera u Šenženu, da bi nakon toga prešao u tunel.

Samo tako, maksimalno usmjeravajući sav mogući promet kroz naše rješenje za brzo prolaz kroz kineski vatrozid, možemo postići prihvatljive brzine i dostupnost stranice, kao i poštene rezultate testova rješenja.
Uspjeli smo to bez jedine izmjene koda na strani proizvoda timova.

Subfilter

Rješenje se pojavilo gotovo odmah nakon što se pojavio ovaj problem. Trebali smo PoC (Proof of Concept), da bi dokazali da naša rješenja za prolaz kroz vatrozid stvarno dobro rade. Za to je potrebno maksimalno usmjeriti sav promet stranice kroz ovo rješenje. Primijenili smo subfilter u nginx-u.

Subfilter — to je prilično jednostavan modul u nginx-u koji omogućuje zamjenu jedne linije u tijelu odgovora drugom linijom. Tako smo promijenili sve pojave semrush.com na semrushchina.cn u svim odgovorima.

I… to nije uspjelo jer smo od backend-a primali komprimirane sadržaje, te subfilter nije mogao pronaći potrebnu liniju. Morali smo dodati još jedan lokalni server u nginx koji je dekompresirao odgovor i predao ga sljedećem lokalnom serveru koji se već bavio zamjenom linije, kompresijom i isporukom sljedećem proxy serveru u redu.

Kao rezultat, gdje bi klijent primio <subdomain>.semrush.com, zapravo je primio <subdomain>.semrushchina.cn i po poslušnosti prolazio kroz naše rješenje.

Međutim, nije dovoljno samo promijeniti domen u jednom smjeru, jer backend-i i dalje očekuju semrush.com u sljedećim zahtjevima od klijenta. Stoga, na istom serveru gdje se vrši zamjena u jednom smjeru, pomoću jednostavnog regularnog izraza dobivamo poddomenu iz zahtjeva, a zatim radimo proxy_pass s varijablom $host, postavljenom na $subdomain.semrush.com.Može izgledati zbunjujuće, ali to radi. I radi dobro. Za posebne domene koje zahtijevaju drugu logiku, jednostavno se kreiraju vlastiti server-blokovi i izrađuje zasebna konfiguracija. Ispod su prikazane skraćene nginx konfiguracije za preglednost i demonstraciju ove sheme.

Sljedeća konfiguracija obrađuje sve zahtjeve iz Kine na .semrushchina.cn:

    slušaj 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 proksira na localhost na port 83, a tamo čeka sljedeća konfiguracija:

    slušaj 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;
    }
}

Ponovit ću, ovo su skraćene konfiguracije.

Otprilike tako. Može izgledati složeno, ali to su samo riječi. U stvarnosti je sve jednostavnije od pečenog krumpira 🙂

Kraj lirskog odustajanja

Neko vrijeme smo bili sretni jer se mit o padajućim IPSEC tunelima nije potvrdio. Ali potom su tuneli počeli padati. Nekoliko puta dnevno po nekoliko minuta. Malo, ali nam to nije odgovaralo. Budući da su oba tunela terminirana na strani Alija na jednom ruteru, odlučili smo da je možda to regionalni problem i da treba podići rezervni region.

Podigli smo. Tuneli su počeli padati u različito vrijeme, ali failover je odlično funkcionirao na razini upstream u nginx. Ali potom su tuneli počeli padati otprilike u isto vrijeme 🙂 I opet su se pojavili 502 i 504. Uptime je počeo opadati, zato smo počeli razrađivati opciju s Alibaba CEN (Cloud Enterprise Network).

CEN

CEN — to je povezanost dva VPC-a iz različitih regija unutar Alibaba Clouda, tj. možete spojiti privatne mreže iz bilo kojih regija unutar oblaka međusobno. I što je najvažnije: ovaj kanal ima prilično stroge SLA. On je vrlo stabilan po brzini kao i po uptimeu. No nikad nije sve tako jednostavno:

• vrlo je teško dobiti, ako niste kineski državljani ili pravne osobe,
• treba platiti za svaki megabit propusnosti kanala.

Dobivši mogućnost povezivanja Mainland China i Overseas, stvorili smo CEN između dva Alijeva regiona: cn-shenzhen i us-east-1 (najbliža točka us-east4). U Aliju us-east-1 podigli smo još jednu virtualku da imamo još jedan hop.

Ispalo je ovako:

Rezultati testova preglednika su u nastavku:

Rešenje
Uptime
Medijan
75. percentil
95. percentil

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Pokazatelji su malo bolji nego kod IPSEC-a. No putem IPSEC-a potencijalno možete preuzimati brzinom od 100 mbita/s, dok preko CEN-a samo brzinom od 5 mbita/s i skuplje je.

Nadam se hibridu, zar ne? Povezati brzinu IPSEC-a i stabilnost CEN-a.

Tako smo i postupili, propuštajući promet i kroz IPSEC i kroz CEN u slučaju pada IPSEC tunela. Uptime je postao znatno veći, ali brzina učitavanja stranice još uvijek nije bila zadovoljavajuća. Tada sam izradio sve sheme koje smo već koristili i testirali, te odlučio pokušati dodati malo GCP-a u ovu shemu, konkretno GLB.

GLB

GLB — to je Global Load Balancer (ili Google Cloud Load Balancer). Ima važno prednost za nas: u kontekstu CDN-a ima anycast IP, što omogućuje usmjeravanje prometa u najbliži data centar klijentu, zahvaljujući čemu promet brže ulazi u brzu Googleovu mrežu i manje ide kroz "obični" internet.

Nakon malo razmišljanja, postavili smo HTTP/HTTPS LB u GCP i backend postavili naše virtuelne mašine s subfilterom.

Postojale su nekoliko shema:

• Koristiti Cloudflare China Network, ali ovaj put kao Origin navodimo globalni IP GLB.
• Terminirati klijente u cn-shenzhen, a odatle proksirati promet odmah u GLB.
• Ići odmah iz Kine u GLB.
• Terminirati klijente u cn-shenzhen, odatle proksirati u asia-east1 putem IPSEC (u us-east4 putem CEN), a odatle već ići u GLB (smirite se, dolje će biti slika i objašnjenje)

Testirali smo sve ove opcije i još nekoliko hibridnih:

• Cloudflare + GLB

Ova shema nas nije zadovoljila zbog uptime-a i DNS grešaka. No testiranje je provedeno prije rješavanja buga sa strane CF, možda je sada bolje (međutim, to ne isključuje HTTP timeout-e).

• Ali + GLB

Ova shema nas također nije zadovoljila zbog uptime-a, jer je GLB često ispadao iz upstream-a zbog nemogućnosti povezivanja u prihvatljivom vremenu ili timeout-a, jer za server unutar Kine adresa GLB ostaje vani, a to znači iza kineskog vatrozida. Magije nije bilo.

• Samo GLB

Opcija slična prethodnoj, samo u njoj nisu korišteni serveri unutar same Kine: promet je išao direktno u GLB (promijenili smo DNS zapise). U skladu s tim, rezultati nas nisu zadovoljili, jer su obični kineski klijenti, koji koriste usluge običnih internet provajdera, imali znatno lošiju situaciju s prolazom kroz vatrozid nego s Ali Cloud.

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

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

• stabilnost i zajamčen SLA od CEN-a
• visoku brzinu od IPSEC-a
• "brzu" mrežu Google-a i njegov anycast.

Shema izgleda otprilike ovako: promet korisnika se terminira na virtuelnoj mašini u ch-shenzhen. Tamo su postavljeni upstreami nginx, od kojih se neki odnose na privatne IP servere na drugom kraju IPSEC tunela, dok se neki upstreami odnose na privatne adrese servera s druge strane CEN. IPSEC je podešen do regije asia-east1 u GCP (bio je najbliži region Kini u vreme stvaranja rešenja. Sada GCP takođe ima prisustvo u Hong Kongu). CEN - do regije us-east1 u Ali Cloud.

Nakon toga, saobraćaj s oba kraja usmeravan je na anycast IP GLB, što znači na najbližu Google-ovu tačku prisustva, i odlazio je kroz njegove mreže u regiju us-east4 u GCP, gde su se nalazile zamene virtuelne mašine (sa subfilterom u nginxu).

Ovo hibridno rešenje, kao što smo i očekivali, omogućilo je korišćenje prednosti svake tehnologije. U suštini, saobraćaj ide kroz brzi IPSEC, ali ako počnu problemi, brzo i na nekoliko minuta izbacujemo te servere iz upstreama i šaljemo saobraćaj samo kroz CEN, dok se tunel ne stabilizuje.

Implementacijom četvrtog rešenja sa spiska iznad, postigli smo ono što smo želeli i što je od nas zahtevala kompanija u to vreme.

Rezultati testova pretraživača za novo rešenje u odnosu na prethodna:

Rešenje
Uptime
Medijan
75. percentil
95. percentil

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 našem implementiranom rešenju sve je u redu, osim što nemamo CDN koji bi mogao ubrzati saobraćaj na nivou regija i čak gradova. U teoriji, to bi trebalo da ubrza rad sajta za krajnje korisnike koristeći brze kanale CDN provajdera. I stalno smo razmišljali o tome. I zato je došlo vreme za sledeću iteraciju projekta: istraživanje i testiranje CDN provajdera u Kini.

O tome ću vam pričati u sledećem, završnom delu 🙂

Izvor: habr.com