Привет!
Любые хорошие истории заканчиваются. И наша история про то, как мы придумывали решение быстрого прохода Китайского Фаервола, не исключение. Поэтому спешу поделиться с вами последней, завершающей частью на эту тему.
В предыдущей части было рассказано про множество тестовых стендов, придуманных нами, и какие результаты они дали. И мы остановились на том, что неплохо было бы добавить 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
Median
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 Cloud
Tencent свое облако только развивает — это видно по небольшому количеству продуктов. В ходе его использования, мы хотели протестировать не только их CDN, но и в целом сетевую инфраструктуру:
- есть ли у них что-то похожее на CEN?
- как у них работает IPSEC? Быстро ли, какой uptime?
- есть ли у них Anycast?
Разберем эти вопросы по отдельности.
Аналог CEN
У Tencent есть продукт Cloud Connect Network (), позволяющий соединять между собой 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 — . Но он также недоступен глобальным аккаунтам, поэтому о нем не расскажу, но знать, что такой продукт есть, может быть полезно.
А вот тест CDN показал довольно интересные результаты. CDN у Tencent нельзя включить на full-site, только на конкретные домены. Мы завели домены и пустили на них трафик:
Оказалось, что данный CDN имеет такую функцию: Cross Border Traffic Optimization. Данная фича должна снижать издержки при прохождении трафика через китайский фаервол. В качестве Origin был указан 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/sAkamai 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 Provider
Median
75%
95%
Response
Webpage Response
Uptime
DNS
Connect
Wait
Load
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):
Percentile
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 — миф. Мы узнавали это непосредственно у пользователей.
- Можно увидеть, как редиректит на www.baidu.com (в mainland China также).
- Многие ресурсы действительно заблокированы. Примитивно: google.com, Facebook, Twitter. Но многие гугловые ресурсы работают (конечно, не на всех Wi-Fi и VPN при этом не используется (на стороне роутера тоже, это точно).
- Многие “технические” домены заблокированных корпораций также работают. Это значит, что не всегда следует безрассудно выпиливать все подряд гугловые и прочие кажущиеся заблокированными ресурсы. Нужно поискать какой-то список запрещенных доменов.
- У них всего три основных интернет-оператора: China Unicom, China Telecom, China Mobile. Есть еще помельче, но их доля на рынке несущественна
Бонус: итоговая схема решения
Итог
Прошел год с момента старта проекта. Мы начали с того, что наш сайт вообще в принципе отказывался нормально работать из Китая, а просто GET curl’ом занимал 5.5 секунд.
Потом, с таких показателей при первом решении (Cloudflare):
Решение
Uptime
Median
75 Percentile
95 Percentile
Cloudflare
86.6
18s
30s
60s
Мы в итоге дошли до таких результатов (статистика за последний месяц):
Решение
Uptime
Median
75 Percentile
95 Percentile
Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s
Как видно, аптайма в 100% добиться пока что не удалось, но мы что-нибудь придумаем, а потом расскажем вам о результатах в новой статье:)
Тому, кто дочитал до конца все три части — респект. Надеюсь, вам все это было так же интересно, как и мне, когда я это делал.
P.S. Предыдущие части
Источник: habr.com