Всем привет! На связи Никита — системный инженер из компании SЕMrush. Сегодня я расскажу вам о том, как перед нами встала задача обеспечить стабильность работы нашего сервиса semrush.com в Китае, и с какими проблемами мы столкнулись в ходе ее выполнения (учитывая местонахождение нашего дата-центра на восточном побережье США). Это будет большая история, разбитая на несколько статей. Расскажу, как все это было у нас: от полностью неработающего сервиса из Китая, до показателей работы сервиса на уровне его американской версии для американцев. Обещаю, будет интересно и полезно. Итак, поехали. Даже самый далекий человек от специфики сетевого администрирования хотя бы раз, да слышал о Великом Китайском Фаерволе. Ууу, звучит круто, да? Но что это такое, как оно работает на самом деле — вопрос довольно сложный. В интернете можно найти много статей, посвященных этому, но с технической точки зрения устройство этого фаервола нигде не описано. Что, впрочем, неудивительно. Признаюсь сразу, по итогам года работы я не смогу сказать точно, как он работает, но смогу рассказать о своих замечаниях и практических выводах. И начнем мы со слухов об этом фаерволе. Есть много слухов об этом самом фаерволе. Давайте соберем основные и наиболее интересные из них в один список: Вот, что нам удалось выяснить об этих слухах: Обратите внимание на time_connect. И в целом, вы видите результат: фаервол добавляет 4 лишних секунды, что чудовищно долго. Разница в 5 секунд на общее время загрузки 13 байт. При том, делая такой тест несколько раз, можно заметить, что GET на HTTP завершается в целом за одинаковое время каждый раз, в то время как по HTTPS сайт отвечает иногда за 3, 5, 10 и даже 17 секунд. Иногда случаются ошибки SSL: Unknown SSL protocol error in connection to ifconfig.co:443. Итак, что мы имеем: Картина вырисовывается просто “отличная”.  Датацентр, как я уже сказал, у нас на востоке США, а весь SEMrush состоит из десятков взаимосвязанных продуктов, бэкэндов, фронтэндов, баз данных, и все это в ДЦ и облаках. Перед нами, как командой системных администраторов, была поставлена задача малыми усилиями быстро начать работать в Китае. Нам предстояло ответить на важный вопрос: можно ли обойтись малой кровью и решить все проблемы, связанные с китайским интернетом и фаерволом, на уровне сети/облаков/серверов? Мы начали с получения ICP-лицензии. Для того, чтобы иметь возможность размещать свой сервис в пределах Китая (Mainland China) и проводить тесты, нужно сначала получить ICP-лицензию на домен. Если пользовательский трафик вашего сайта терминируется в пределах Mainland China, и если у вашего домена нет лицензии ICP, ваш трафик будет блокироваться на стороне провайдера/хостинга. Интересно, что в ICP-лицензию вписывается конкретный провайдер, будь то Cloudflare или Alibaba Cloud. Поэтому, если вы получали ICP-лицензию для Cloudflare и размещали свой сайт у них, в последствии “бесшовно” переехать на Alibaba Cloud у вас не получится. Необходимо будет добавлять в эту лицензию еще один хостинг. Получив ICP-лицензию на домен, мы смогли придумывать и реализовывать конкретные технические идеи и решения. Но перед тем, как непосредственно создавать варианты стейджингов, крутить ручки, оптимизировать работу сайта и его скорость, нужно выбрать инструмент для его тестирования, чтобы видеть, какие наши действия улучшают или наоборот ухудшают работу сайта. Наш инструмент для тестирования должен был соответствовать двум главным требованиям: Так мы нашли Catchpoint! У них отличное покрытие точками тестирования по всему миру. В Китае через этот инструмент можно запускать тесты тоже из 100500 провинций. В каждой по несколько разных провайдеров + возможность делать Backbone-тесты (что-то типа виртуалки в датацентре) и Lastmile-тесты (максимально приближенные к пользовательским условиям, aka рабочая станция). Последний тип тестов стоит дороже. Заключив годовой контракт (меньше нельзя), мы приступили к изучению инструмента. Признаться, мы были приятно удивлены его функционалом. Можно запускать: Всего не перечислишь. И что самое главное, каждый тест можно довольно хорошо кастомизировать, добавив пачку заголовков и других параметров. На выходе получается огромное количество информации, полностью описывающей твой тест. Если говорить о самом интересном для нас (браузерные тесты), то результат включает в себя: Соответственно, все эти метрики отлично помогают видеть изменения и понимать, стало ли лучше. Мы, в основном, смотрели на Response, Webpage Response, Median, 75 и 95 Percentiles.  Важный вопрос, который витал в воздухе с самого начала: а можно ли верить Catchpoint? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Это большая проблема, потому что находясь в России практически невозможно достоверно узнать, как работает сайт из Китая. Делая socks-proxy через виртуалку, на выходе получаешь загрузку сайта в течение пары минут, что для тестов просто неприемлимо, поэтому единственным вариантом ручного тестирования остается curl и простые GET из консоли с замером времени. Это помогает, потому что данный тест хорошо отражает скорость работы сетевого решения, а если есть еще и браузерные тесты, то совсем хорошо. Позже мы сами съездили в Китай и убедились, что Catchpoint верить можно, он довольно точно отражает реальные показатели скорости работы. Так как для основного домена semrush.com мы успешно используем Cloudflare, решили сразу попробовать их фичу под названием China Network. Данная опция включается только для 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% пользователей (из США) на ту же самую страницу (статика + динамика). В каждый тест можно зайти и посмотреть Waterfall и другие более подробные параметры. Мы начали исследовать причины ошибок, и если для таймаутов все более менее понятно: интернет в Китае “то съезжается, то разъезжается”, из-за этого скорость коннекта и загрузки ресурсов из-за границы нестабильна и неодинакова, то DNS-ошибки нас сильно удивили. Мы обнаружили, что PoP у Cloudflare действительно находятся в Китае, адрес сайта резолвится в один anycast IP, но DNS-серверы используются американские, из-за чего DNS-запросы вынуждены проходить через границу, поэтому иногда они фейлятся. Уточнив этот вопрос у CF, выяснилось, что своих DNS-серверов в Китае у них нет, а когда будет — пока неизвестно. Поэтому мы решили потестировать только DNS Cloudflare и поменяли механизм работы Cloudflare для нашего сайта на режим “Только DNS”. Это такой режим, когда Cloudflare не проксирует трафик через себя, а значит, не предоставляет DDoS-защиты, CDN и прочие фичи, и работает в режиме обычного DNS-сервера.  Данный стенд схематично представлен на следующем рисунке. На рисунке учтены появившиеся знания о том, что DNS-сервера Cloudflare за фаерволом. В Catchpoint мы запустили простые GET-тесты (не браузерные), которые показали очень много фейлов. Причиной их были все те же DNS ошибки. Начали дебажить эти ошибки с помощью dig и обнаружили, что при первом запросе адрес определяется правильно, а при повторном запросе мы получаем каждый раз SERVFAIL и not found. Это с чего вдруг? При запросе NS-серверов Cloudflare напрямую таких ошибок нет: Значит, проблема на стороне “локального” DNS-сервера или сервера провайдера.
Дальнейшее расследование показало, что SERVFAIL мы получаем на резолве AAAA-записи.  Оказалось, что при запросе у Cloudflare АААА-записи, которой в домене нет, Cloudflare отвечал А-записью, что является ошибкой и несоответствием RFC. Из-за чего локальному резолверу (x.x.x.x) это не нравилось, и он отвечал SERVFAIL. В логе ниже это поведение отчетливо видно: Мы отправили bug-репорт Cloudflare, и они это исправили через какое-то время. Оказалось интересно: на настоящий момент в Китае до сих пор нет поддержки IPv6, поэтому Cloudflare не мог выдавать там свой IPv6 адрес в ответе на запрос АААА-записи. В итоге все решилось так, что для Китая Cloudflare стал отвечать NODATA на такие запросы. Так, ошибки DNS в тестах Catchpoint резко уменьшились, но не до конца. Таймауты тоже никуда не делись: И мы начали искать другое решение.  В следующей части я расскажу, как мы тестировали китайское облако Alibaba Cloud, как с помощью небольшой "магии" Nginx мы смогли быстро создавать PoC (Proof of Concept) решений, как мы создавали Multi-Cloud решения, одно из которых в итоге очень сильно помогло ускорить работу сервиса из Китая. Stay tuned! Часть 2
Часть 3 Linux администратор