Усім прывітанне!
На сувязі Мікіта - сістэмны інжынер з кампаніі SЕMrush. Сёння я раскажу вам пра тое, як перад намі паўстала задача забяспечыць стабільнасць працы нашага сэрвісу semrush.com у Кітаі, і з якімі праблемамі мы сутыкнуліся падчас яе выканання (улічваючы месцазнаходжанне нашага дата-цэнтра на ўсходнім узбярэжжы ЗША).
Гэта будзе вялікая гісторыя, разьбітая на некалькі артыкулаў. Раскажу, як усё гэта было ў нас: ад поўнасцю непрацуючага сэрвісу з Кітая, да паказчыкаў працы сэрвісу на ўзроўні яго амерыканскай версіі для амерыканцаў. Абяцаю, будзе цікава і карысна. Такім чынам, паехалі.
Праблемы кітайскага інтэрнэту
Нават самы далёкі чалавек ад спецыфікі сеткавага адміністравання хаця б раз, ды чуў пра Вялікім Кітайскім Фаервале. Ууу, гучыць крута, так? Але што гэта такое, як яно працуе насамрэч – пытанне даволі складанае. У інтэрнэце можна знайсці шмат артыкулаў, прысвечаных гэтаму, але з тэхнічнага пункта гледжання прылада гэтага фаервала нідзе не апісана. Што, зрэшты, нядзіўна. Прызнаюся адразу, па выніках года працы я не змагу сказаць дакладна, як ён працуе, але змагу расказаць пра свае заўвагі і практычныя высновы. І пачнем мы са чутак аб гэтым фаервале.
Ёсць шмат чутак аб гэтым самым фаервале. Давайце збяром асноўныя і найбольш цікавыя з іх у адзін спіс:
- Google, Facebook, Twitter і іншыя падобныя сэрвісы заблакаваныя і не працуюць у Кітаі.
- Любы трафік, які ідзе ЗА межы Кітая і Ў Кітай, парсіцца і абмяжоўваецца з дапамогай машыннага навучання (у выпадку падазронага трафіку), што моцна запавольвае яго (трафік), які праходзіць праз мяжу.
- Кітайскія спецслужбы ўзламаюць любы зашыфраваны трафік, які ідзе праз іх фаервал.
- VPN-тунэлі, IPSEC-тунэлі нестабільныя, падаюць і ўвесь час блакуюцца.
- Чым прасцей шыфраванне, чым прасцей pass phrase, якая выкарыстоўваецца для аўтэнтыфікацыі/шыфра трафіку, тым хутчэй ён праходзіць кітайскі фаервол.
Вось, што нам удалося высветліць пра гэтыя чуткі:
- Google, Facebook, Twitter і іншыя падобныя сэрвісы сапраўды заблакаваныя (ваш ДА), але шматлікія тэхнічныя дамены Google, напрыклад, не забанены і працуюць (той жа gstatic.com). Адсюль вынікае выснова: не варта безразважна выпілоўваць усе запар гуглавыя і іншыя, якія здаюцца заблакаванымі, рэсурсы.
- Любы трафік, які праходзіць мяжу, сапраўды дадае да свайго часу неабыякі delay. Паглядзіце на два вынікі. Адзін сайт, адна старонка, просты GET завітакТым. Першы замёр з самога Кітая (выдатны горад Шэньчжэнь). Другі замёр звонку з Ганконга (мае суверэнітэт, і паміж ім і мірам няма фаервала). Адлегласць паміж гарадамі па прамой прыкладна 30-40 км.
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/sЗвярніце ўвагу на time_connect. І ў цэлым, вы бачыце вынік: фаервал дадае 4 лішнія секунды, што жахліва доўга.
- VPN і IPSEC-тунэлі сапраўды часта падаюць. Пра гэта я раскажу крыху пазней і падрабязней. VPN-серверы, якія выкарыстоўваюцца карыстальнікамі, з часам блакуюцца (звычайна на працягу сутак пасля пачатку выкарыстання).
- Ёсць меркаванне, атрыманае ад людзей, якія пражываюць у Кітаі, што чым прасцей шыфраванне трафіку, тым хутчэй ён праходзіць праз мяжу, таму што лёгка зразумець, што ў ім няма нічога супрацьзаконнага. І сапраўды таксама "чысты" трафік атрымлівае больш паласы прапускання і хуткасці праходжання, а "брудны" трафік, у якім нічога не разабраць, атрымлівае наадварот больш павольны праход. Для прыкладу я прывяду curl да ifconfig.co па пратаколе HTTPS і 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/sРозніца ў 5 секунд на агульны час загрузкі 13 байт. Пры тым, робячы такі тэст некалькі разоў, можна заўважыць, што GET на HTTP завяршаецца ў цэлым за аднолькавы час кожны раз, у той час як па HTTPS сайт адказвае часам за 3, 5, 10 і нават 17 секунд. Часам здараюцца памылкі SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Такім чынам, што мы маем:
- Праблемы, якія ствараюцца кітайскім фаервалам, апісаныя вышэй.
- Пінгі да знешніх рэсурсаў і ўнутры тунэляў перыядычна знікаюць.
- Latency паміж двума кропкамі ўвесь час змяняецца, а часцяком яна проста непрадказальная. Злучаючы розныя гарады/рэгіёны, ты чакаеш, што зыходзячы з геаграфічнага размяшчэння рэгіёнаў, затрымка будзе менш, а атрымліваеш роўна зваротную сітуацыю.
- Інтэрнет і каналы сувязі працуюць то хутка, то павольна. Тут ёсць невялікая залежнасць ад часу сутак і дня тыдня, але не заўжды.
- DNS-запыты ў знешні свет з Кітая часам перавышаюць дапушчальны таймаўт.
Карціна вымалёўваецца проста "выдатная".
Датацентр, як я ўжо сказаў, у нас на ўсходзе ЗША, а ўвесь SEMrush складаецца з дзясяткаў узаемазлучаных прадуктаў, бэкэндаў, франтэндаў, баз дадзеных, і ўсё гэта ў ДЦ і аблоках. Перад намі, як камандай сістэмных адміністратараў, была пастаўлена задача малымі намаганнямі хутка пачаць працаваць у Кітаі.
Нам трэба было адказаць на важнае пытанне: ці можна абысціся малой крывёй і вырашыць усе праблемы, звязаныя з кітайскім інтэрнэтам і фаервалам, на ўзроўні сеткі/аблокаў/сервераў?
Мы пачалі з атрымання .
ICP-ліцэнзія
Для таго, каб мець магчымасць размяшчаць свой сэрвіс у межах Кітая (Mainland China) і праводзіць тэсты, трэба спачатку атрымаць ICP-ліцэнзію на дамен.
Калі карыстацкі трафік вашага сайта тэрмінуецца ў межах Mainland China, і калі ў вашага дамена няма ліцэнзіі ICP, ваш трафік будзе блакавацца на баку правайдэра/хостынгу. Цікава, што ў ICP-ліцэнзію ўпісваецца пэўны правайдэр, няхай гэта будзе Cloudflare ці Alibaba Cloud. Таму, калі вы атрымлівалі ICP-ліцэнзію для Cloudflare і размяшчалі свой сайт у іх, пасля "бясшвоўна" пераехаць на Alibaba Cloud у вас не атрымаецца. Неабходна будзе дадаваць у гэтую ліцэнзію яшчэ адзін хостынг.
Атрымаўшы ICP-ліцэнзію на дамен, мы змаглі прыдумляць і рэалізоўваць пэўныя тэхнічныя ідэі і рашэнні.
Тэставанне рашэнняў
Але перад тым, як непасрэдна ствараць варыянты стэйджынгаў, круціць ручкі, аптымізаваць працу сайта і яго хуткасць, трэба абраць прыладу для яго тэставання, каб бачыць, якія нашы дзеянні паляпшаюць ці наадварот пагаршаюць працу сайта.
Наш інструмент для тэсціравання павінен быў адпавядаць двум галоўным патрабаванням:
- ён павінен мець магчымасць запуску тэстаў з Кітая,
- ён павінен мець браузерныя тэсты.
Так мы знайшлі ! У іх выдатнае пакрыццё кропкамі тэсціравання па ўсім свеце. У Кітаі праз гэтую прыладу можна запускаць тэсты таксама з 100500 правінцый. У кожнай па некалькі розных правайдэраў + магчымасць рабіць Пазваночнік-тэсты (нешта тыпу віртуалкі ў датацэнтры) і Апошняя міля-тэсты (максімальна набліжаныя да карыстацкіх умоў, aka працоўная станцыя). Апошні тып тэстаў каштуе даражэй.
Заключыўшы гадавы кантракт (менш нельга), мы прыступілі да вывучэння інструмента. Прызнацца, мы былі прыемна здзіўлены яго функцыяналам. Можна запускаць:
- DNS-тэсты,
- Web-тэсты (браўзэрныя, просты GET/POST, эмуляцыя мабільнага кліента і г.д.),
- Транзакцыйныя праверкі (напрыклад, лагін),
- API-тэсты,
- Пінг, traceroute, NTP і г.д.
Усяго не пералічыш. І што самае галоўнае, кожны тэст можна даволі добра кастамізаваць, дадаўшы пачак загалоўкаў і іншых параметраў. На выхадзе атрымліваецца вялікая колькасць інфармацыі, якая цалкам апісвае твой тэст. Калі казаць пра самае цікавае для нас (браўзэрныя тэсты), то вынік уключае ў сябе:
- Connect, Wait, Load, SSL, DNS time,
- TTFB, TTLB, Document complete, Render time, DOM load,
- Response (нешта блізкае да Time To First Byte), Webpage Response (нешта блізкае да Time To Last Byte),
- Любыя percentile, Average, Median time
- І да т.п.
Адпаведна, усе гэтыя метрыкі выдатна дапамагаюць бачыць змены і разумець, ці стала лепш. Мы, у асноўным, глядзелі на Response, Webpage Response, Median, 75 і 95 Percentiles.
Важнае пытанне, якое лунала ў паветры з самага пачатку: а ці можна верыць Catchpoint? Ці адлюстроўвае гэты інструмент рэальную хуткасць загрузкі сайта ў Кітаі з розных гарадоў ці гэта проста нейкі тэст у вакууме, які не мае нічога агульнага з real user experience?
Гэта вялікая праблема, таму што знаходзячыся ў Расіі практычна немагчыма дакладна даведацца, як працуе сайт з Кітая. Робячы socks-proxy праз віртуалку, на выхадзе атрымліваеш загрузку сайта на працягу пары хвілін, што для тэстаў проста непрымальна, таму адзіным варыянтам ручнога тэсціравання застаецца curl і простыя GET з кансолі з замерам часу. Гэта дапамагае, таму што дадзены тэст добра адлюстроўвае хуткасць працы сеткавага рашэння, а калі ёсць яшчэ і браузерныя тэсты, то зусім добра.
Пазней мы самі з'ездзілі ў Кітай і ўпэўніліся, што Catchpoint верыць можна, ён даволі сапраўды адлюстроўвае рэальныя паказчыкі хуткасці працы.
Cloudflare China Network
Так як для асноўнага дамена semrush.com мы паспяхова выкарыстоўваем Cloudflare, вырашылі адразу паспрабаваць іх фічу пад назовам . Дадзеная опцыя ўключаецца толькі для Enterprise-сайтаў па асобным запыце і за асобную плату. Таксама яна даступна толькі для сайтаў, якія маюць адпаведную ICP-ліцэнзію, у якой у якасці правайдэра паказаны Cloudflare. Пасля яе ўключэння, для сайта становіцца даступным "кітайскі CDN" ад Cloudflare - трафік з кітайскіх рэгіёнаў прызямляецца ў бліжэйшыя PoP (Points of Presence) CF, а далей ужо па яго сетках або сетках правайдэраў/партнёраў дастаўляецца да origin.
Схема дадзенага тэставага стэнда прадстаўлена ніжэй.
Для нас гэта цудоўны варыянт. Атрымліваецца, што другі дамен будзе таксама за CF, што не дадае колькасць рашэнняў, якія выкарыстоўваюцца ў кампаніі, а таксама практычна не ўскладняе інфраструктуру.
Мы запусцілі браузерныя тэсты, і вось што атрымалася:
Чырвоныя ромбікі - гэта фейлы тэстаў. Фейлы знізу - DNS памылкі (resolve timeout). Фейлы зверху - таймаўты.
Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s
Медыяна, пасля таго, як прыбралі загрузку reCaptcha (сэрвіс гугла, заблакаваны ў Кітаі), знізілася з 28 да 18 сек. Але ўсё роўна гэта жудасныя паказчыкі, калі ўлічыць, што такі ж тэст для semrush.com (з ЗША) даваў менш за 10 секунд для 95% карыстальнікаў (з ЗША) на тую ж самую старонку (статыка + дынаміка).
У кожны тэст можна зайсці і паглядзець вадаспад і іншыя больш падрабязныя параметры. Мы пачалі даследаваць прычыны памылак, і калі для таймаўтаў усё больш менш зразумела: інтэрнэт у Кітаі "то з'язджаецца, то раз'язджаецца", з-за гэтага хуткасць канэкту і загрузкі рэсурсаў з-за мяжы нестабільная і неаднолькавая, то DNS-памылкі нас моцна здзівілі. PoP у Cloudflare сапраўды знаходзяцца ў Кітаі, адрас сайта рэзалюе ў адзін anycast IP, але DNS-серверы выкарыстоўваюцца амерыканскія, з-за чаго DNS-запыты вымушаны праходзіць праз мяжу, таму часам яны фейлят.
Удакладніўшы гэтае пытанне ў CF, высветлілася, што сваіх DNS-сервераў у Кітаі ў іх няма, а калі будзе - пакуль невядома.
Таму мы вырашылі патэставаць толькі DNS Cloudflare і памянялі механізм працы Cloudflare для нашага сайта на рэжым.Толькі DNS”. Гэта такі рэжым, калі Cloudflare не праксіруе трафік праз сябе, а значыць, не падае DDoS-абароны, CDN і іншыя фічы, і працуе ў рэжыме звычайнага DNS-сервера.
Дадзены стэнд схематычна прадстаўлены на наступным малюнку. На малюнку ўлічаны якія з'явіліся веды аб тым, што DNS-сервера Cloudflare за фаервалам.
У Catchpoint мы запусцілі простыя GET-тэсты (не браузерныя), якія паказалі вельмі шмат фэйлаў. Прычынай іх былі ўсё тыя ж DNS памылкі.
Пачалі дэбажыць гэтыя памылкі з дапамогай капаць і выявілі, што пры першым запыце адрас вызначаецца правільна, а пры паўторным запыце мы атрымліваем кожны раз 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)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Пры запыце NS-сервераў Cloudflare напрамую такіх памылак няма:
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.192Значыць, праблема на баку "лакальнага" DNS-сервера ці сервера правайдэра.
Далейшае расследаванне паказала, што SERVFAIL мы атрымліваем на рэзалве АААА-запісы.
Аказалася, што пры запыце ў Cloudflare АААА-запісы, якой у дамене няма, Cloudflare адказваў А-запісам, што з'яўляецца памылкай і неадпаведнасцю RFC. З-за чаго лакальнаму рэзаверу (хххх) гэта не падабалася, і ён адказваў SERVFAIL. У логу ніжэй гэтыя паводзіны выразна відаць:
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
Мы адправілі bug-рэпарт Cloudflare, і яны гэта выправілі праз нейкі час. Аказалася цікава: на сапраўдны момант у Кітаі да гэтага часу няма падтрымкі IPv6, таму Cloudflare не мог выдаваць там свой IPv6 адрас у адказе на запыт. АААА-запісы. У выніку ўсё вырашылася так, што для Кітая Cloudflare пачаў адказваць. NODATA на такія запыты.
Так, памылкі DNS у тэстах Catchpoint рэзка паменшыліся, але не да канца. Таймаўты таксама нікуды не падзеліся:
І мы пачалі шукаць іншае рашэньне.
У наступнай частцы я раскажу, як мы тэставалі кітайскае воблака Alibaba Cloud, як з дапамогай невялікай "магіі" Nginx мы змаглі хутка ствараць PoC (Proof of Concept) рашэнняў, як мы стваралі Multi-Cloud рашэнні, адно з якіх у выніку вельмі моцна дапамагло паскорыць працу сэрвісу з Кітая.
Сачыце за абнаўленнямі!
Наступныя часткі
Крыніца: habr.com
