Як мы прабівалі Вялікі Кітайскі Фаервал (ч.3)

Прывітанне!
Любыя добрыя гісторыі заканчваюцца. І нашая гісторыя пра тое, як мы прыдумвалі рашэнне хуткага праходу Кітайскага Фаервала, не выключэнне. Таму спяшаюся падзяліцца з вамі апошняй, завяршальнай часткай на гэтую тэму.

У папярэдняй частцы было расказана пра мноства тэставых стэндаў, прыдуманых намі, і якія вынікі яны далечы. І мы спыніліся на тым, што нядрэнна было б дадаць CDN! для глейкасці ў нашу схему.

Я раскажу вам, як мы тэсціравалі Alibaba Cloud CDN, Tencent Cloud CDN і Akamai, і на чым у выніку спыніліся. Ну і вядома, падвядзем вынік.

Alibaba Cloud CDN

Мы хостымcя ў Alibaba Cloud, выкарыстоўваем IPSEC і CEN ад іх жа. Лагічна будзе спачатку паспрабаваць іх рашэнні.

Alibaba Cloud мае два віды прадукту, якія могуць нам падысці: CDN и DCDN. Першы варыянт уяўляе сабой класічны CDN на пэўны дамен (паддамен). Другі варыянт расшыфроўваецца як Dynamic Route for CDN (я яго клічу дынамічны CDN), яго можна ўключаць у рэжыме Full-site (для wildcard даменаў), ён таксама кэшуе статыку і акселеруе на сабе дынамічны кантэнт, гэта значыць дынаміка старонкі таксама будзе грузіцца праз хуткія сеткі правайдэра. Гэта для нас важна, таму што ў асноўным у нас сайт дынамічны, у ім выкарыстоўваецца мноства паддаменаў, і зручней наладзіць CDN адзін раз для "зорачкі" - *.semrushchina.cn.

Мы ўжо бачылі гэты прадукт на больш ранніх этапах нашага кітайскага праекта, але тады ён яшчэ не працаваў, і распрацоўшчыкі абяцалі, што вось-вось прадукт стане даступны для ўсіх кліентаў. І ён стаў.

У DCDN можна:

• наладзіць тэрмінаванне SSL са сваім сертыфікатам,
• уключыць акселерацыю дынамічнага кантэнту,
• гнутка наладзіць кэшаванне статычных файлаў,
• рабіць кэшу purge,
• пракідваць вэб-сокеты,
• уключыць сціск і нават HTML Beautifier.

Увогуле, усё як у дарослых і вялікіх CDN-правайдэраў.

Пасля таго, як Origin (тое месца, куды пойдуць CDN edge servers) паказаны, далей застаецца стварыць CNAME для зорачкі, які спасылаецца на all.semrushchina.cn.w.kunluncan.com (дадзены CNAME быў атрыманы ў кансолі Alibaba Cloud), і CDN запрацуе.

Па выніках тэстаў, дадзены CDN нам вельмі дапамог. Статыстыка прыведзена ніжэй.

рашэнне
Uptime
медыяна
75 Percentile
95 Percentile

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

Ali CDN + CEN / IPsec + GLB
99.75
10s
12.8s
17.3s

Гэта вельмі добрыя вынікі, тым больш калі іх параўнаць з тым, якія лічбы былі спачатку. Але мы ведалі, што браузерны тэст амерыканскай версіі нашага сайта www.semrush.com адпрацоўвае са ЗША ў сярэднім за 8.3s (вельмі набліжанае значэнне). Ёсць куды імкнуцца. Тым больш, былі яшчэ CDN-правайдэры, якіх цікава было пацесціць.

Так мы плаўна пераходзім да яшчэ аднаго гіганту на кітайскім рынку. Tencent.

Воблака Tencent

Tencent сваё воблака толькі развівае - гэта відаць па невялікай колькасці прадуктаў. У ходзе яго выкарыстання, мы хацелі пратэставаць не толькі іх CDN, але і ў цэлым сеткавую інфраструктуру:

• ці ёсць у іх нешта падобнае на CEN?
• як у іх працуе IPSEC? Ці хутка, які uptime?
• ці ёсць у іх Anycast?

Разбяром гэтыя пытанні па асобнасці.

Аналаг CEN

У Tencent ёсць прадукт Cloud Connect Network (CCN), які дазваляе злучаць паміж сабой VPC з розных рэгіёнаў, у тым ліку рэгіёны ўнутры Кітая і звонку. Прадукт зараз ва ўнутранай beta, і трэба ствараць тыкет з просьбай падключыцца да яе. Ад саппорта мы даведаліся, што global-акаўнтам (гаворка не аб грамадзянах Кітая і не юрыдычных асобах) нельга ўдзельнічаць у праграме beta тэставання і ў цэлым злучыць рэгіён унутры Кітая з рэгіёнам звонку. 1-0 на карысць Ali Cloud

IPSEC

Самы паўднёвы рэгіён у Tencent Гуаньчжоў. Мы сабралі тунэль і злучылі яго з рэгіёнам Ганконг у GCP (тады гэты рэгіён ужо стаў даступны). Таксама паднялі адначасова другі тунэль у Ali Cloud з Шэньчжэня ў Ганконг. Аказалася, што праз сетку Tencent latency да Ганконга ў цэлым лепш (10ms), чым з Шэньчжэня ў Ганконг у Ali (120ms – what?). Але гэта ніяк не паскарала працу сайта, накіраванага на працу праз Tencent і гэты тунэль, што само па сабе было дзіўным фактам і яшчэ раз даказвала наступнае: latency – для Кітая гэта не паказчык, на які рэальна варта зважаць падчас распрацоўкі рашэння праходжання кітайскага. фаервала.

Anycast Internet Acceleration

Яшчэ адзін прадукт, які дазваляе працаваць праз anycast IP AIA. Але ён таксама недаступны глабальным акаўнтам, таму пра яго не раскажу, але ведаць, што такі прадукт ёсць, можа быць карысна.

А вось тэст CDN паказаў дастаткова цікавыя вынікі. CDN у Tencent нельга ўключыць на full-site, толькі на пэўныя дамены. Мы завялі дамены і пусцілі на іх трафік:

Аказалася, што дадзены CDN мае такую ​​функцыю: Cross Border Traffic Optimization. Дадзеная фіча павінна зніжаць выдаткі пры праходжанні трафіку праз кітайскі фаервал. Ў якасці Паходжанне быў паказаны IP адрас гуглавога GLB (GLB anycast). Такім чынам мы хацелі спрасціць архітэктуру праекту.

Вынікі былі вельмі добрымі - на ўзроўні Ali Cloud CDN, а месцамі нават і лепш. Гэта дзіўна, таму што ў выпадку поспеху тэстаў, можна адмовіцца ад важкай часткі інфраструктуры, тунэляў, CEN, віртуалак і тд.

Цешыліся нядоўга, бо выявілася праблема: тэсты ў Catchpoint фейліліся для інтэрнэт-правайдэра China Mobile. З любых лакацый мы атрымлівалі таймаўт праз CDN Tencent'а. Перапіска з тэхнічнай падтрымкай ні да чаго не прывяла. Каля сутак мы спрабавалі развязаць гэтую праблему, але нічога так і не выйшла.

Я знаходзіўся ў той момант у Кітаі, але не змог знайсці публічны Wi-Fi у сетцы гэтага правайдэра, каб пераканацца ў праблеме асабіста. У астатнім усё выглядала хутка і добра.
Аднак, з-за таго, што аператар China Mobile уваходзіць у тройку найбуйнейшых аператараў, мы былі вымушаныя вярнуць трафік на Ali CDN.
Але ў цэлым гэта было даволі цікавым рашэннем, якое заслугоўвае даўжэйшага тэсціравання і траблшутынгу дадзенай праблемы.

Akamai

Апошні CDN-правайдэр, які мы тэставалі – гэта Akamai. Гэта вялізны правайдэр, які мае сваю сетку ў Кітаі. Вядома, мы не змаглі прайсці міма яго.

З самага пачатку мы дамовіліся з Akamai аб тэставым перыядзе, каб мы маглі пераключыць дамен і паглядзець, як ён будзе працаваць на іх сетцы. Вынік усяго тэставання я апішу ў выглядзе "Што спадабалася" і "Што не спадабалася", а таксама прывяду вынікі тэстаў.

Што спадабалася:

• Рабяты з Akamai вельмі дапамагалі ва ўсіх пытаннях і суправаджалі нас на ўсіх этапах тэставання. Пастаянна спрабавалі палепшыць нешта на сваім баку. Давалі нядрэнныя тэхнічныя парады.
• Akamai працуе прыкладна на 10-15% павольней нашага рашэння праз Ali Cloud CDN. Уражвае тое, што ў Origin для Akamai мы паказвалі IP-адрас GLB, гэта значыць трафік ішоў не праз нашае рашэнне (патэнцыйна можна адмовіцца ад часткі інфраструктуры). Але ўсёткі вынікі тэстаў паказалі, што гэты варыянт рашэння горш нашага бягучага варыянту (параўнальныя вынікі ніжэй).
• Тэставаўся як Origin GLB, так і Origin у Кітаі. Абодва варыянты прыкладна аднолькавыя.
• Ёсць Sure Route (аўтаматычная аптымізацыя маршрутызацыі). Можна размясціць у сябе тэставы аб'ект на Origin, і Edge сервера Akamai будуць спрабаваць яго забраць (звычайны GET). Для гэтых запытаў вымяраецца хуткасць і іншыя метрыкі, на аснове чаго сетка Akamai аптымізуе маршруты, каб трафік ішоў хутчэй для нашага сайта і было бачна, што ўключэнне гэтай фічы сапраўды моцна адбівалася на хуткасці працы сайта.
• Версіянаванне канфігурацыі ў вэб-інтэрфейсе - гэта крута. Можна зрабіць Compare для вэрсіяў, паглядзець diff. Паглядзець папярэднія версіі.
• Можна выкочваць новую версію спачатку толькі на Staging сетку Akamai – такую ​​ж сетку як і production, толькі такі шлях не афектыць рэальных карыстачоў. Для гэтага тэсту трэба зрабіць спуфінг DNS-запісаў на лакальнай машыне.
• Вельмі хуткая хуткасць загрузкі праз іх сетку вялікай статыкі, ну і, мабыць, любых іншых файлаў. Файл з "халоднага" кэша залазіць у разы хутчэй, чым той жа файл з "халоднага" кэша Ali CDN. З "гарачага" кэша хуткасць ужо плюс-мінус аднолькавая.

Ali CDN test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

Akamai test:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

Мы заўважылі, што сітуацыя з прыкладу вышэйшая залежыць ад розных фактараў. На момант напісання гэтага пункта я правёў тэст яшчэ раз. Вынікі для абедзвюх платформ аказаліся прыкладна аднолькавымі. Гэта кажа нам аб тым, што інтэрнэт у Кітаі нават для буйных аператараў і хмарных правайдэраў паводзіць сябе час ад часу па-рознаму.

Да папярэдняга пункта дадам вялікі плюс Akamai: калі ў Ali бачныя падобныя паласкі высокай прадукцыйнасці і вельмі нізкай (гэта дакранаецца і Ali CDN, і Ali CEN, і Ali IPSEC), то ў Akamai кожны раз, як бы я не тэставаў іх сетку, усё працуе стабільна.
Akamai сапраўды маюць вялікае пакрыццё ў Кітаі і працуюць праз многіх правайдэраў.

Што не спадабалася:

• Не падабаецца вэб-інтэрфейс і схема працы - такія нулявыя. Але ў прынцыпе абвыкаеш (напэўна).
• Вынікі тэстаў горшыя за нашу пляцоўку.
• Памылак пры тэстах больш, чым на нашай пляцоўцы (uptime ніжэй).
• Няма сваіх DNS-сервераў у Кітаі. Адгэтуль шмат памылак у тэстах з-за DNS resolve timeout.
• Не падаюць свае IP ranges -> няма магчымасці прапісаць карэктныя set_real_ip_from на нашых сэрверах.

Метрыкі (~3626 runs; усе метрыкі, акрамя Uptime, у ms; статыстыка за адзін прамежак часу):

Правайдэр CDN
медыяна
75%
95%
Адказ
Webpage Response
Uptime
DNS
падключаць
пачакайце
Нагрузка
SSL

Ali CDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Размеркаванне па Percentile (у ms):

Працэнтны
Akamai
Ali CDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

Выснова такая: варыянт з Akamai жыццяздольны, але не дае тыя ж паказчыкі стабільнасці і хуткасці, як наша ўласнае рашэнне разам з Ali CDN.

Маленькія нататкі

Некаторыя моманты не ўвайшлі ў апавяданне, але мне хацелася б пра іх напісаць таксама.

Пекін + Токіа і Ганконг

Як я ўжо казаў вышэй, мы тэсціравалі IPSEC тунэль да Ганконга (HK). Але таксама мы тэсціравалі і CEN да HK. Ён каштуе крыху танней, і было цікава, як ён будзе працаваць паміж гарадамі з адлегласцю ~100км. Цікавым аказалася тое, што latency паміж гэтымі гарадамі на 100ms вышэй, чым у нашым першапачатковым варыянце (да Тайваня). Хуткасць, стабільнасць таксама была лепшай для Тайваня. У выніку, мы пакінулі HK як бэкапны IPSEC рэгіён.

Акрамя таго, мы спрабавалі паднімаць такую ​​інсталяцыю:

• тэрмінаванне кліентаў у Пекіне,
• IPSEC і CEN да Токіо,
• у Ali CDN паказваўся ў якасці origin сервер у Пекіне.

Гэтая схема была не такой стабільнай, хоць па хуткасці ў цэлым не саступала нашаму рашэнню. Што да тунэля, я бачыў перыядычныя падзенні нават для CEN, які павінен быў быць стабільным. Таму мы вярнуліся на старую схему і разабралі гэты стэйджынг.

Ніжэй прыведзена статыстыка па latency паміж рознымі рэгіёнамі па розных каналах. Можа, камусьці яна будзе цікавая.

IPsec
Ali cn-beijing <-> GCP asia-northeast1 - 193ms
Ali cn-shenzhen <-> GCP asia-east2 - 91ms
Ali cn-shenzhen <-> GCP us-east4 - 200ms

CEN
Ali cn-beijing <-> Ali ap-northeast-1 - 54ms (!)
Ali cn-shenzhen <-> Ali cn-hongkong - 6ms (!)
Ali cn-shenzhen <-> Ali us-east1 - 216ms

Агульная інфармацыя пра інтэрнэт у Кітаі

Як дадатак да праблем з інтэрнэтам, апісаным у самым пачатку, у першай частцы артыкула.

• Інтэрнэт у Кітаі працуе даволі хутка ўсярэдзіне.
  • Выснова зроблена на аснове тэсціравання публічных сетак Wi-Fi у розных лакацыях, дзе дадзеныя сеткі выкарыстоўваюцца вялікай колькасцю чалавек.
  • Хуткасць скокі і запампоўкі на серверы ўнутры Кітая была каля 20 мбіт/с і 5-10 мбіт/с адпаведна.
  • Хуткасць да сервераў звонку Кітая проста мізэрная, менш за 1 мбіт/c.
• Інтэрнэт у Кітаі не вельмі стабільны.
  • Часам сайты могуць адчыняцца хутка, часам павольна (у адзін і той жа час сутак у розныя дні), пры ўмове, што канфігурацыя не змяняецца. Мы гэта назіралі на прыкладзе semrushchina.cn. Гэта можна спісаць на Ali CDN, які таксама працуе то так, то сяк у залежнасці ад часу сутак, становішчы зорак і т.д.
• Мабільны інтэрнэт практычна ўсюды 4G ці 4G+. Ловіць у метро, ​​ліфтах - карацей, усюды.
• Тое, што кітайскія карыстальнікі вераць толькі даменам у зоне. Cn – міф. Мы даведваліся гэта непасрэдна ў карыстальнікаў.
  • Можна ўбачыць, як http://baidu.cn рэдырэктыт на www.baidu.com (у mainland China таксама).
• Многія рэсурсы сапраўды заблакаваныя. Прымітыўна: google.com, Facebook, Twitter. Але шматлікія гуглавыя рэсурсы працуюць (вядома, не на ўсіх Wi-Fi і VPN пры гэтым не выкарыстоўваецца (на боку роўтара таксама, гэта сапраўды).
• Многія "тэхнічныя" дамены заблакаваных карпарацый таксама працуюць. Гэта значыць, што не заўсёды варта безразважна выпілоўваць усе запар гуглавыя і іншыя ўяўныя заблакаванымі рэсурсы. Трэба пашукаць нейкі спіс забароненых даменаў.
• У іх усяго тры асноўныя інтэрнэт-аператары: China Unicom, China Telecom, China Mobile. Ёсць яшчэ мяльчэй, але іх доля на рынку неістотная

Бонус: выніковая схема рашэння

Вынік

Мінуў год з моманту старту праекту. Мы пачалі з таго, што наш сайт увогуле ў прынцыпе адмаўляўся нармальна працаваць з Кітая, а проста GET curl'ам займаў 5.5 секунд.

Потым, з такіх паказчыкаў пры першым рашэнні (Cloudflare):

рашэнне
Uptime
медыяна
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

Мы ў выніку дайшлі да такіх вынікаў (статыстыка за апошні месяц):

рашэнне
Uptime
медыяна
75 Percentile
95 Percentile

Ali CDN + CEN / IPsec + GLB
99.86
8.8s
9.5s
13.7s

Як бачна, аптайму ў 100% дамагчыся пакуль што не ўдалося, але мы што-небудзь прыдумаем, а потым раскажам вам пра вынікі ў новым артыкуле:)

Таму, хто дачытаў да канца ўсе тры часткі - рэспект. Спадзяюся, вам усё гэта было так цікава, як і мне, калі я гэта рабіў.

PS Папярэднія часткі

Частка 1
Частка 2

Крыніца: habr.com