Witam wszystkich!
Kontaktuje się z Nikitą – inżynierem systemowym z firmy SEMrush. Dziś opowiem Wam o tym jak stanęliśmy przed zadaniem zapewnienia stabilności naszej usługi semrush.com w Chinach i jakie problemy napotkaliśmy podczas jej wdrożenia (biorąc pod uwagę lokalizację naszego data center na wschodnim wybrzeżu Stanów Zjednoczonych).
To będzie obszerna historia, podzielona na kilka artykułów. Opowiem Wam jak to wszystko się u nas odbyło: od całkowicie niefunkcjonalnej usługi z Chin, po wskaźniki wydajności usługi na poziomie jej amerykańskiej wersji dla Amerykanów. Obiecuję, że będzie ciekawie i pożytecznie. Więc chodźmy.
Problemy chińskiego Internetu
Nawet najdalsza osoba od specyfiki administrowania siecią słyszała Wielka zapora sieciowa w Chinach. Wow, brzmi fajnie, prawda? Ale co to jest i jak faktycznie działa, to dość skomplikowane pytanie. W Internecie można znaleźć wiele artykułów na ten temat, jednak z technicznego punktu widzenia struktura tego firewalla nie jest nigdzie opisana. Co jednak nie jest zaskakujące. Przyznam od razu, że na podstawie wyników rocznej pracy nie będę w stanie dokładnie powiedzieć, jak to działa, ale mogę podzielić się swoimi uwagami i praktycznymi wnioskami. A zaczniemy od plotek na temat tej zapory ogniowej.
Krąży wiele plotek na temat tego właśnie firewalla. Zbierzmy główne i najciekawsze z nich na jednej liście:
- Google, Facebook, Twitter i inne podobne usługi są zablokowane i nie działają w Chinach.
- Jakikolwiek ruch wychodzący POZA Chiny i DO Chin jest analizowany i ograniczany przy użyciu uczenia maszynowego (w przypadku podejrzanego ruchu), co znacznie spowalnia jego (ruch) przechodzący przez granicę.
- Chińskie agencje wywiadowcze zhakują każdy zaszyfrowany ruch przechodzący przez ich zaporę ogniową.
- Tunele VPN, tunele IPSEC są niestabilne, ulegają awariom i są stale blokowane.
- Im prostsze szyfrowanie, im prostsze hasło używane do uwierzytelniania/szyfrowania ruchu, tym szybciej przechodzi on przez chińską zaporę ogniową.
Oto, czego dowiedzieliśmy się na temat tych plotek:
- Google, Facebook, Twitter i inne podobne usługi są rzeczywiście zablokowane (twoje KO), ale na przykład wiele technicznych domen Google nie jest zablokowanych i działa (ta sama gstatic.com). Wniosek z tego wynika: nie należy lekkomyślnie odcinać wszystkich zasobów Google i innych, które wydają się zablokowane.
- Jakikolwiek ruch przekraczający granicę naprawdę powoduje poważne opóźnienie. Spójrz na dwa wyniki. Jedna witryna, jedna strona, prosty GET curlom. Pierwszy pomiar pochodził z samych Chin (pięknego miasta Shenzhen). Drugi mierzony był spoza Hongkongu (ma suwerenność i nie ma żadnej zapory ogniowej pomiędzy nim a światem). Odległość między miastami w linii prostej wynosi około 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sZwróć uwagę na czas_połączenia. Ogólnie rzecz biorąc, widzisz wynik: zapora sieciowa dodaje 4 dodatkowe sekundy, co jest potwornie długie.
- Tunele VPN i IPSEC często zawodzą. Opowiem o tym nieco później i bardziej szczegółowo. Serwery VPN, z których korzystają użytkownicy, są z czasem blokowane (zwykle w ciągu jednego dnia od rozpoczęcia użytkowania).
- Wśród mieszkańców Chin panuje opinia, że im prostsze szyfrowanie ruchu, tym szybciej przechodzi on przez granicę, bo łatwo zrozumieć, że nie ma w tym nic nielegalnego. I w ten sam sposób „czysty” ruch uzyskuje większą przepustowość i prędkość przepływu, podczas gdy „brudny” ruch, w którym nic nie można zrozumieć, przeciwnie, uzyskuje wolniejszy przepływ. Na przykład użyję curl do ifconfig.co za pośrednictwem protokołu HTTPS i HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sRóżnica 5 sekund przy całkowitym czasie pobierania 13 bajtów. Co więcej, wykonując taki test kilka razy, można zauważyć, że GET na HTTP jest wykonywany generalnie za każdym razem w tym samym czasie, podczas gdy na HTTPS strona czasami odpowiada w ciągu 3, 5, 10, a nawet 17 sekund. Czasami zdarzają się błędy SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Zatem co mamy:
- Problemy stwarzane przez chińską zaporę sieciową opisano powyżej.
- Pingi do zasobów zewnętrznych i wewnętrznych tuneli okresowo znikają.
- Opóźnienie między dwoma punktami stale się zmienia i często jest po prostu nieprzewidywalne. Łącząc różne miasta/regiony, oczekujesz, że w oparciu o położenie geograficzne regionów opóźnienie będzie mniejsze, ale otrzymasz dokładnie odwrotną sytuację.
- Internet i kanały komunikacji są albo szybkie, albo wolne. Istnieje niewielka zależność od pory dnia i dnia tygodnia, ale nie zawsze.
- Żądania DNS do świata zewnętrznego z Chin czasami przekraczają dozwolony limit czasu.
Obraz, jaki się wyłania, jest po prostu „doskonały”.
Centrum danych, jak już mówiłem, znajduje się we wschodniej części Stanów Zjednoczonych, a cały SEMrush składa się z kilkudziesięciu połączonych ze sobą produktów, backendów, frontendów, baz danych, a wszystko to w DC i chmurach. My, jako zespół administratorów systemów, otrzymaliśmy zadanie szybkiego rozpoczęcia pracy w Chinach przy niewielkim wysiłku.
Musieliśmy odpowiedzieć sobie na ważne pytanie: czy da się obejść niewielkim kosztem i rozwiązać wszystkie problemy związane z chińskim Internetem i firewallem na poziomie sieci/chmury/serwera?
Zaczęliśmy od odbioru .
Licencja ICP
Aby móc hostować swoją usługę na terenie Chin (Chiny kontynentalne) i przeprowadzać testy, należy najpierw uzyskać licencję ICP na domenę.
Jeśli ruch użytkowników Twojej witryny zostanie wstrzymany w Chinach kontynentalnych, a Twoja domena nie ma licencji ICP, Twój ruch zostanie zablokowany po stronie dostawcy usług internetowych/hostingu. Co ciekawe, licencja ICP obejmuje konkretnego dostawcę, czy to Cloudflare, czy Alibaba Cloud. Dlatego jeśli otrzymałeś licencję ICP dla Cloudflare i hostowałeś na nich swoją stronę internetową, nie będziesz mógł „płynnie” przenieść się do Alibaba Cloud. Będziesz musiał dodać kolejny hosting do tej licencji.
Po otrzymaniu licencji ICP na domenę mogliśmy wymyślić i wdrożyć konkretne pomysły i rozwiązania techniczne.
Testowanie rozwiązań
Zanim jednak bezpośrednio stworzysz opcje stagingu, przekręcisz gałki, zoptymalizujesz wydajność witryny i jej szybkość, musisz wybrać narzędzie do jej przetestowania, aby zobaczyć, które z naszych działań poprawiają, a które pogarszają wydajność witryny.
Nasze narzędzie testowe musiało spełniać dwa główne wymagania:
- powinien móc uruchamiać testy z Chin,
- musi mieć testy przeglądarki.
Więc znaleźliśmy ! Mają doskonałe pokrycie lokalizacji testowych na całym świecie. W Chinach za pomocą tego narzędzia można również przeprowadzać testy w 100500 XNUMX prowincjach. Każdy ma kilku różnych dostawców + możliwość zrobienia Kręgosłup-testy (coś w rodzaju maszyny wirtualnej w centrum danych) i Ostatnia mila-testy (jak najbardziej zbliżone do warunków użytkownika, czyli stacji roboczej). Ten drugi rodzaj badań jest droższy.
Po zawarciu rocznej umowy (mniej niż to nie jest możliwe) zaczęliśmy studiować instrument. Szczerze mówiąc, byliśmy mile zaskoczeni jego funkcjonalnością. Możesz uruchomić:
- testy DNS,
- Testy webowe (testy przeglądarkowe, proste GET/POST, emulacja klienta mobilnego itp.),
- Kontrole transakcyjne (np. logowanie),
- testy API,
- Ping, traceroute, NTP itp.
Nie możesz wymienić wszystkiego. A co najważniejsze, każdy test można całkiem dobrze dostosować, dodając kilka nagłówków i innych parametrów. Dane wyjściowe to ogromna ilość informacji, które w pełni opisują Twój test. Jeśli mówimy o tym, co dla nas najciekawsze (testy przeglądarek), w wyniku otrzymujemy:
- Połącz, czekaj, załaduj, SSL, czas DNS,
- TTFB, TTLB, dokument kompletny, czas renderowania, ładowanie DOM,
- Odpowiedź (coś zbliżonego do czasu do pierwszego bajtu), Odpowiedź strony internetowej (coś w pobliżu czasu do ostatniego bajtu),
- Dowolny percentyl, średnia, mediana czasu
- Itp.
W związku z tym wszystkie te wskaźniki doskonale nadają się do obserwowania zmian i zrozumienia, czy sytuacja się poprawiła. Głównie przyglądaliśmy się Odpowiedź, Odpowiedź strony internetowej, Mediana, 75 i 95 percentyli.
Ważne pytanie, które wisiało w powietrzu od samego początku: Czy możesz zaufać Catchpointowi?? Czy to narzędzie odzwierciedla rzeczywistą prędkość ładowania strony w Chinach z różnych miast, czy też jest to tylko rodzaj testu w próżni, który nie ma nic wspólnego z rzeczywistym doświadczeniem użytkownika?
To duży problem, ponieważ będąc w Rosji prawie niemożliwe jest wiarygodne sprawdzenie, jak działa witryna z Chin. Robiąc skarpetki-proxy przez maszynę wirtualną, efektem końcowym jest to, że strona ładuje się w ciągu kilku minut, co jest po prostu nie do przyjęcia w przypadku testów, więc jedyną opcją do testowania ręcznego jest zwijanie i proste GET z konsoli za pomocą timera . Pomaga to, bo ten test dobrze oddaje szybkość rozwiązania sieciowego, a jeśli są jeszcze testy przeglądarkowe, to jest bardzo dobrze.
Później sami pojechaliśmy do Chin i byliśmy o tym przekonani Można zaufać Catchpoint; dość dokładnie odzwierciedla rzeczywiste wskaźniki wydajności.
Sieć Cloudflare w Chinach
Ponieważ z powodzeniem używamy Cloudflare dla domeny głównej semrush.com, postanowiliśmy od razu wypróbować ich funkcję o nazwie . Ta opcja jest dostępna tylko dla witryn korporacyjnych na osobne żądanie i za dodatkową opłatą. Jest również dostępny tylko dla witryn posiadających odpowiednią licencję ICP, która wymienia Cloudflare jako dostawcę. Po jej włączeniu dla witryny staje się dostępny „chiński CDN” od Cloudflare – ruch z chińskich regionów ląduje w najbliższym PoP (Points of Presence) CF, a następnie poprzez jego sieci lub sieci dostawców/partnerów jest dostarczany do miejsca pochodzenia .
Schemat tego stanowiska badawczego przedstawiono poniżej.
Jest to dla nas świetna opcja. Okazuje się, że druga domena będzie również przeznaczona dla CF, co nie zwiększa liczby rozwiązań stosowanych w firmie, a także praktycznie nie komplikuje infrastruktury.
Przeprowadziliśmy testy przeglądarki i oto co się stało:
Czerwone diamenty to niepowodzenie testu. Poniższe pliki to błędy DNS (przekroczenie limitu czasu rozwiązania). Awarie na górze to przekroczenia limitu czasu.
Czas pracy: 86.6
Mediana: 18 s
75 percentyl: 29.3 s
95 percentyl: 60 s
Medianę po załadowaniu usunięto reCaptcha (usługa Google zablokowana w Chinach) spadła z 28 do 18 sekund. Ale to i tak okropne wyniki, biorąc pod uwagę, że ten sam test dla semrush.com (z USA) dał mniej niż 10 sekund dla 95% użytkowników (z USA) na tej samej stronie (statyczny + dynamiczny).
Możesz wejść do każdego testu i popatrzeć Wodospad i inne bardziej szczegółowe parametry. Zaczęliśmy badać przyczyny błędów i jeśli w przypadku przekroczeń limitu czasu wszystko jest mniej więcej jasne: Internet w Chinach „przychodzi i wychodzi”, z tego powodu prędkość połączenia i ładowania zasobów z zagranicy jest niestabilna i nierówna, wtedy błędy DNS bardzo nas zaskoczyły. Znaleźliśmy to Muzyka pop Cloudflare faktycznie znajdują się w Chinach, adres witryny jest rozpoznawany jako jeden adres IP anycast, ale serwery DNS są amerykańskie, dlatego żądania DNS są zmuszone przekraczać granicę, co czasami kończy się niepowodzeniem.
Po wyjaśnieniu tej kwestii z CF okazało się, że Nie mają własnych serwerów DNS w Chinachi kiedy to nastąpi, wciąż nie wiadomo.
Dlatego postanowiliśmy przetestować tylko DNS Cloudflare i zmieniliśmy mechanizm operacyjny Cloudflare dla naszej witryny na „Tylko DNSy" Jest to tryb, w którym Cloudflare nie proxy sam przez siebie ruchu, co oznacza, że nie zapewnia ochrony DDoS, CDN i innych funkcji i działa w trybie zwykłego serwera DNS.
Stanowisko to pokazano schematycznie na poniższym rysunku. Rysunek uwzględnia pojawiającą się wiedzę, że serwery DNS Cloudflare znajdują się za zaporą ogniową.
W Catchpoint przeprowadziliśmy proste testy GET (nie testy przeglądarki), które wykazały wiele błędów. Były spowodowane tymi samymi błędami DNS.
Zaczęliśmy debugować te błędy za pomocą kopać i okazało się, że przy pierwszym żądaniu adres jest ustalany prawidłowo, a przy powtórnym żądaniu otrzymujemy za każdym razem AWARIA SERWISOWA и nie znaleziono. Dlaczego to się dzieje nagle?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Nie ma takich błędów podczas bezpośredniego wysyłania zapytań do serwerów Cloudflare NS:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Oznacza to, że problem leży po stronie „lokalnego” serwera DNS lub serwera dostawcy.
Dalsze dochodzenie to wykazało AWARIA SERWISOWA postanawiamy AAAA-dokumentacja.
Okazało się, że podczas żądania od Cloudflare AAAA-rekord, który nie istnieje w domenie, odpowiedział Cloudflare А-wpis będący błędem i niezgodnością z RFC. Dlaczego lokalny program rozpoznawania nazw (xxxx) Nie podobało mi się to, a on odpowiedział AWARIA SERWISOWA. To zachowanie jest wyraźnie widoczne w poniższym logu:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Przesłaliśmy raport o błędzie do Cloudflare, który po pewnym czasie naprawił go. Okazało się to ciekawe: w Chinach nadal nie ma obsługi protokołu IPv6, więc Cloudflare nie mógł wydać tam swojego adresu IPv6 w odpowiedzi na żądanie AAAA-dokumentacja. Ostatecznie wszystko zostało rozwiązane w taki sposób, że Cloudflare zaczął odpowiadać za Chiny BRAK DANYCH na takie prośby.
Zatem błędy DNS w testach Catchpoint gwałtownie spadły, ale nie całkowicie. Limity czasu nadal są tutaj:
I zaczęliśmy szukać innego rozwiązania.
W kolejnej części opowiem jak testowaliśmy chińską chmurę Alibaba Cloud, jak przy pomocy odrobiny „magii” Nginxa udało nam się szybko stworzyć rozwiązania PoC (Proof of Concept), jak stworzyliśmy rozwiązania Multi-Cloud, z których jedno ostatecznie znacząco pomogło przyspieszyć pracę usługi z Chin.
Bądźcie czujni!
Kolejne części
Źródło: www.habr.com
