Hi!
Nikita on jälleen kanssasi, yrityksen järjestelmäinsinööri SEMrush. Ja tällä artikkelilla jatkan tarinaa siitä, kuinka keksimme kiertoratkaisun Kiinan palomuuri palveluamme semrush.com.
В Sanoin:
- mitä ongelmia syntyy päätöksenteon jälkeen "Meidän täytyy saada palvelumme toimimaan Kiinassa"
- Mitä ongelmia kiinalaisessa Internetissä on?
- miksi tarvitset ICP-lisenssin?
- miten ja miksi päätimme testata testialustojamme Catchpointilla
- mikä oli ensimmäisen Cloudflare China Networkiin perustuvan ratkaisumme tulos
- Kuinka löysimme virheen Cloudflare DNS:ssä
Tämä osa on mielestäni mielenkiintoisin, koska se keskittyy lavastuksen tiettyihin teknisiin toteutuksiin. Ja aloitamme tai pikemminkin jatkamme siitä Alibaba Cloud.
Alibaba Cloud
Alibaba Cloud on melko suuri pilvipalveluntarjoaja, jolla on kaikki palvelut, joiden avulla se voi rehellisesti kutsua itseään pilvipalveluntarjoajaksi. On hyvä, että heillä on mahdollisuus rekisteröityä ulkomaisille käyttäjille ja että suurin osa sivustosta on käännetty englanniksi (Kiinalle tämä on luksusta). Tässä pilvessä voit työskennellä monien maailman alueiden, Manner-Kiinan sekä valtameren Aasian (Hongkong, Taiwan jne.) kanssa.
IPSEC
Aloitimme maantiedosta. Koska testisivustomme sijaitsi Google Cloudissa, meidän oli "linkitettävä" Alibaba Cloud GCP:hen, joten avasimme luettelon sijainneista, joissa Google on läsnä. Tuolloin heillä ei vielä ollut omaa datakeskusta Hongkongissa.
Lähin alue osoittautui Aasia-itä1 (Taiwan). Ali osoittautui Taiwania lähimmäksi Manner-Kiinan alueeksi cn-shenzhen (Shenzhen).
Kanssa terraformi kuvasi ja nosti koko infrastruktuurin GCP:ssä ja Alissa. 100 Mbit/s tunneli pilvien välissä nousi lähes välittömästi. Shenzhenin ja Taiwanin puolella välityspalvelinten virtuaalikoneita nostettiin. Shenzhenissä käyttäjäliikenne päätetään, välitetään tunnelin kautta Taiwaniin ja sieltä se siirtyy suoraan palvelumme ulkoiseen IP-osoitteeseen. me-itä (USA:n itärannikko). Ping virtuaalikoneiden välillä tunnelin kautta 24ms, mikä ei ole niin paha.
Samalla sijoitimme testialueen Alibaba Cloud DNS. Kun vyöhyke oli delegoitu NS Alille, resoluutioaika lyheni 470 ms:sta 50 ms. Ennen tätä vyöhyke oli myös Cloudlfarella.
Samansuuntaisesti tunnelin kanssa Aasia-itä1 nosti toisen tunnelin Shenzhenistä suoraan us-itä4. Siellä he loivat lisää välityspalvelinvirtuaalikoneita ja alkoivat testata molempia ratkaisuja reitittämällä testiliikennettä evästeiden tai DNS:n avulla. Testipenkki on kuvattu kaavamaisesti seuraavassa kuvassa:
Tunnelien latenssi osoittautui seuraavaksi:
Ali cn-shenzhen <—> GCP aasia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms
Catchpoint-selaintestit raportoivat erinomaisesta parannuksesta.
Vertaa kahden ratkaisun testituloksia:
päätös
Päällä
Mediaani
75 prosenttipiste
95 prosenttipiste
CloudFlare
86.6
18s
30s
60s
IPSec
99.79
18s
21s
30s
Tämä on dataa ratkaisusta, joka käyttää IPSEC-tunnelia Aasia-itä1. us-east4:n kautta tulokset olivat huonompia ja virheitä oli enemmän, joten en anna tuloksia.
Tämän kahden tunnelin testin tulosten perusteella, joista toinen päättyy Kiinaa lähimpään alueeseen ja toinen lopulliseen määränpäähän, kävi selväksi, että on tärkeää "purkaa" Kiinan palomuurin alta mahdollisimman nopeasti. mahdollista ja käytä sitten nopeita verkkoja (CDN-palveluntarjoajat, pilvipalveluntarjoajat jne.). Sinun ei tarvitse yrittää päästä palomuurin läpi ja päästä määränpäähäsi yhdellä iskulla. Tämä ei ole nopein tapa.
Yleisesti ottaen tulokset eivät ole huonoja, mutta semrush.comin mediaani on 8.8 s ja 75 prosenttipiste 9.4 s (samassa testissä).
Ja ennen kuin jatkan, haluaisin tehdä lyhyen lyyrisen poikkeaman.
Lyyrinen poikkeama
Kun käyttäjä saapuu sivustolle www.semrushchina.cn, joka ratkaistaan "nopeiden" kiinalaisten DNS-palvelimien kautta, HTTP-pyyntö kulkee nopean ratkaisumme läpi. Vastaus palautetaan samaa polkua pitkin, mutta verkkotunnus on määritetty kaikissa JS-skripteissä, HTML-sivuilla ja muissa verkkosivun elementeissä semrush.com lisäresursseja varten, jotka on ladattava, kun sivu hahmonnetaan. Eli asiakas ratkaisee "päätietueen" A-tietueen www.semrushchina.cn ja menee nopeaan tunneliin, saa nopeasti vastauksen - HTML-sivun, joka sanoo:
- lataa sellaisia ja sellaisia js-tiedostoja osoitteesta sso.semrush.com,
- Hanki CSS-tiedostot osoitteesta cdn.semrush.com,
- ja ota myös kuvia osoitteesta dab.semrush.com
- ja niin edelleen.
Selain alkaa siirtyä "ulkoiseen" Internetiin näitä resursseja varten ja kulkee joka kerta palomuurin läpi, joka kuluttaa vasteaikaa.
Mutta edellinen testi näyttää tulokset, kun sivulla ei ole resursseja semrush.comvain semrushchina.cn, ja *.semrushchina.cn ratkaisee Shenzhenin virtuaalikoneen osoitteeseen päästäkseen tunneliin.
Vain tällä tavalla, työntämällä kaiken mahdollisen liikenteen maksimiin ratkaisusi läpi kiinalaisen palomuurin nopeaan ohitukseen, voit saada hyväksyttävät nopeudet ja verkkosivustojen saatavuusindikaattorit sekä rehelliset ratkaisutestien tulokset.
Teimme tämän ilman koodin muokkausta tiimin tuotepuolella.
Alasuodatin
Ratkaisu syntyi melkein heti tämän ongelman ilmaantumisen jälkeen. Me tarvitsimme PoC (Proof of Concept), että palomuuriratkaisumme toimivat todella hyvin. Tätä varten sinun on käärittävä kaikki sivuston liikenne tähän ratkaisuun niin paljon kuin mahdollista. Ja me haimme nginxissä.
Alasuodatin on melko yksinkertainen moduuli nginxissä, jonka avulla voit vaihtaa yhden rivin vastaustekstissä toiseksi riviksi. Joten muutimme kaikki esiintymät semrush.com päälle semrushchina.cn kaikissa vastauksissa.
Ja... se ei toiminut, koska saimme pakattua sisältöä taustajärjestelmistä, joten alisuodatin ei löytänyt vaadittua riviä. Minun piti lisätä toinen paikallinen palvelin nginxiin, joka purki vastauksen ja välitti sen seuraavalle paikalliselle palvelimelle, joka oli jo varattu vaihtamaan merkkijonoa, pakkaamaan sitä ja lähettämään sen ketjun seuraavalle välityspalvelimelle.
Tämän seurauksena, mistä asiakas saisi .semrush.com, hän vastaanotti .semrushchina.cn ja käveli kuuliaisesti päätöksemme läpi.
Pelkästään verkkotunnuksen vaihtaminen yhteen suuntaan ei kuitenkaan riitä, koska taustajärjestelmät odottavat silti semrush.com-sivustoa myöhemmissä asiakkaan pyynnöissä. Vastaavasti samalla palvelimella, jossa yksisuuntainen korvaus tehdään, saamme yksinkertaisen säännöllisen lausekkeen avulla aliverkkotunnuksen pyynnöstä ja teemme sitten proxy_pass muuttujan kanssa $ isäntä, esillä v $aliverkkotunnus.semrush.com. Se voi tuntua hämmentävältä, mutta se toimii. Ja se toimii hyvin. Yksittäisille verkkotunnuksille, jotka vaativat erilaista logiikkaa, luo omat palvelinlohkot ja tee erilliset asetukset. Alla on lyhennetyt nginx-konfiguraatiot selkeyden ja tämän järjestelmän esittelyn vuoksi.
Seuraava konfiguraatio käsittelee kaikki pyynnöt Kiinasta .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;
}
}Tämä asetus on välityspalvelin localhost porttiin 83, ja seuraava kokoonpano odottaa siellä:
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;
}
}Toistan, nämä ovat rajattuja määrityksiä.
niin. Se voi näyttää monimutkaiselta, mutta se on sanoin. Itse asiassa kaikki on yksinkertaisempaa kuin höyrytetyt nauriit :)
Poikkeaman loppu
Hetken aikaa olimme onnellisia, koska myytti putoavista IPSEC-tunneleista ei vahvistunut. Mutta sitten tunnelit alkoivat kaatua. Useita kertoja päivässä muutaman minuutin ajan. Vähän, mutta se ei sopinut meille. Koska molemmat tunnelit päätettiin Alin puolella samalla reitittimellä, päätimme, että tämä oli ehkä alueellinen ongelma ja meidän oli nostettava vara-aluetta.
He poimivat sen. Tunnelit alkoivat epäonnistua eri aikoina, mutta vikasiirtymä toimi meille hyvin ylävirran tasolla nginxissä. Mutta sitten tunnelit alkoivat pudota suunnilleen samaan aikaan 🙂 Ja 502 ja 504 alkoivat taas.. Käyttöaika alkoi heiketä, joten aloimme työstää vaihtoehtoa Alibaba CEN (Cloud Enterprise Network).
CEN
CEN - Tämä on kahden VPC:n liitettävyys eri alueilta Alibaba Cloudissa, eli voit yhdistää minkä tahansa pilven alueiden yksityisiä verkkoja toisiinsa. Ja mikä tärkeintä: tällä kanavalla on melko tiukka SLA. Se on erittäin vakaa sekä nopeuden että käyttöajan suhteen. Mutta se ei ole koskaan niin yksinkertaista:
- sitä on ERITTÄIN vaikea saada, jos et ole Kiinan kansalainen tai oikeushenkilö,
- Sinun on maksettava jokaisesta kanavakapasiteetin megabitistä.
Mahdollisuus yhdistää Manner-Kiinassa и ulkomailla, loimme CEN:n kahden Ali-alueen välille: cn-shenzhen и us-itä-1 (lähin piste meitä-itä4). Ali us-itä-1 nosti toisen virtuaalikoneen niin, että on yksi lisää humala.
Siitä tuli näin:
Selaimen testitulokset ovat alla:
päätös
Päällä
Mediaani
75 prosenttipiste
95 prosenttipiste
CloudFlare
86.6
18s
30s
60s
IPSec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
Suorituskyky on hieman parempi kuin IPSEC. Mutta IPSEC:n kautta voit mahdollisesti ladata 100 Mbit/s nopeudella ja CENin kautta vain 5 Mbit/s ja enemmän.
Kuulostaa hybridiltä, eikö? Yhdistä IPSEC-nopeus ja CEN-vakaus.
Näin teimme sallien liikenteen sekä IPSEC:n että CEN:n kautta IPSEC-tunnelin vian sattuessa. Käyttöajasta on tullut paljon korkeampi, mutta sivuston latausnopeus jättää silti paljon toivomisen varaa. Sitten piirsin kaikki piirit, joita olimme jo käyttäneet ja testannut, ja päätin yrittää lisätä tähän piiriin hieman enemmän GCP:tä, nimittäin korkki.
korkki
korkki - Onko (tai Google Cloud Load Balancer). Sillä on meille tärkeä etu: CDN:n yhteydessä sillä on Anycast IP, jonka avulla voit reitittää liikenteen asiakasta lähinnä olevaan palvelinkeskukseen, jolloin liikenne pääsee nopeasti Googlen nopeaan verkkoon ja vähemmän "tavallisen" Internetin kautta.
Ajattelematta kahdesti nosimme HTTP/HTTPS LB Asensimme virtuaalikoneemme alisuodattimella GCP:hen ja taustajärjestelmänä.
Kaavoja oli useita:
- Käytä Cloudflare China Network, mutta tällä kertaa Originin tulisi määrittää globaali IP GLB.
- Lopeta asiakkaat klo cn-shenzhen, ja sieltä välitetään liikenne suoraan kohteeseen korkki.
- Mene suoraan Kiinasta korkki.
- Lopeta asiakkaat klo cn-shenzhen, sieltä välityspalvelin osoitteeseen Aasia-itä1 IPSEC:n kautta (in us-itä4 CENin kautta), mene sieltä GLB:hen (rauhassa, alla tulee kuva ja selitys)
Testasimme kaikkia näitä vaihtoehtoja ja useita muita hybridejä:
- Cloudflare + GLB
Tämä malli ei sopinut meille käytettävyyden ja DNS-virheiden vuoksi. Mutta testi tehtiin ennen kuin vika korjattiin CF-puolella, ehkä se on nyt parempi (tämä ei kuitenkaan sulje pois HTTP-aikakatkaisuja).
- Ali + GLB
Tämä kaava ei myöskään sopinut meille käytettävyyden suhteen, koska GLB putosi usein ylävirrasta johtuen yhteyden muodostamisen mahdottomuudesta hyväksyttävässä ajassa tai aikakatkaisussa, koska Kiinan sisällä olevan palvelimen GLB-osoite pysyy ulkopuolella ja siksi palvelimen takana. kiinalainen palomuuri. Taikuutta ei tapahtunut.
- Vain GLB
Samanlainen vaihtoehto kuin edellinen, vain se ei käyttänyt palvelimia itse Kiinassa: liikenne meni suoraan GLB:hen (DNS-tietueita muutettiin). Näin ollen tulokset eivät olleet tyydyttäviä, koska tavallisilla kiinalaisilla asiakkailla, jotka käyttävät tavallisten Internet-palveluntarjoajien palveluita, on paljon huonompi tilanne palomuurin läpäisyssä kuin Ali Cloudilla.
- Shenzhen -> (CEN/IPSEC) -> Välityspalvelin -> GLB
Tässä päätimme käyttää parhaita ratkaisuja:
- vakaus ja taattu SLA CEN:ltä
- suuri nopeus IPSEC:ltä
- Googlen "nopea" verkko ja sen anycast.
Kaava näyttää suunnilleen tältä: käyttäjäliikenne lopetetaan virtuaalikoneen sisään ch-shenzhen. Siellä on määritetty Nginx-ylävirtaukset, joista osa osoittaa yksityisiin IP-palvelimiin, jotka sijaitsevat IPSEC-tunnelin toisessa päässä, ja osa ylävirtauksista CEN:n toisella puolella olevien palvelimien yksityisiin osoitteisiin. IPSEC määritetty alueelle Aasia-itä1 GCP:ssä (oli Kiinan lähin alue ratkaisun luomishetkellä. GCP on nyt läsnä myös Hongkongissa). CEN - alueelle us-itä1 Ali Cloudissa.
Sitten liikenne ohjattiin molemmista päistä Anycast IP GLB, eli lähimpään Googlen läsnäolopisteeseen, ja meni sen verkkojen kautta alueelle us-itä4 GCP:ssä, jossa oli korvaavia virtuaalikoneita (alisuodattimella nginxissä).
Tämä hybridiratkaisu hyödynsi, kuten odotimme, jokaisen tekniikan edut. Yleensä liikenne kulkee nopean IPSEC:n kautta, mutta jos ongelmat alkavat, potkimme nämä palvelimet nopeasti ja muutamaksi minuutiksi pois ylävirrasta ja lähetämme liikennettä vain CENin kautta, kunnes tunneli vakiintuu.
Toteuttamalla yllä olevan listan neljännen ratkaisun saimme sen, mitä halusimme ja mitä liiketoiminta vaati meiltä tuolloin.
Uuden ratkaisun selaimen testitulokset verrattuna aikaisempiin:
päätös
Päällä
Mediaani
75 prosenttipiste
95 prosenttipiste
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
Toteuttamassamme ratkaisussa kaikki on hyvin, mutta CDN:ää ei ole, joka voisi nopeuttaa liikennettä alueellisella ja jopa kaupunkitasolla. Teoriassa tämän pitäisi nopeuttaa sivustoa loppukäyttäjien kannalta käyttämällä CDN-palveluntarjoajan nopeita viestintäkanavia. Ja mietimme sitä koko ajan. Ja nyt on tullut aika projektin seuraavalle iteraatiolle: CDN-palveluntarjoajien etsimiseen ja testaamiseen Kiinassa.
Ja kerron tästä seuraavassa, viimeisessä osassa :)
Lähde: will.com