Anycast и BGP: Как AdGuard DNS обрабатывает миллионы запросов
AdGuard DNS начинался как второстепенный некоммерческий проект в дополнение к блокировщику, но со временем дорос до статуса самостоятельного продукта и обрёл огромное количество пользователей по всему миру. Сейчас он обрабатывает больше миллиона запросов в секунду, и эта цифра растёт с каждым днем.
Изначально AdGuard DNS представлял собой всего лишь один сервер. И с ростом количества пользователей мы столкнулись с двумя проблемами:
- Один сервер уже не справлялся с нагрузкой.
- Клиенты находятся по всему миру, и для некоторых из них время доступа к серверу где-то в одном месте непозволительно велико.
Сегодняшний пост посвящён тому, как мы решали эти проблемы.
В какой бы точке мира вы ни находились, AdGuard DNS будет отвечать быстро, как будто сервер находится недалеко от вас.
Но что делать, если клиентов по всему миру много, каждый хочет подключиться к ближайшему к нему DNS-серверу, но при этом все они вбивают в роутер один и тот же IP-адрес, который указан у вас на сайте? Есть только один ответ на этот вопрос — использовать Anycast-маршрутизацию.
Попробую объяснить, что это такое, максимально просто и используя минимум непонятных слов.
Маршрутизация в интернете
Первым делом нужно рассказать о том, как вообще работает роутинг в интернете. Разбираться будем на примере: пусть Кенни из Колорадо пытается подключиться к серверу, который находится в другом городе или стране.
Кенни уже сделал всё, что от него зависит — он узнал IP-адрес сервера, к которому хочет подключиться, и передал туда пакет с данными. Для этого он отправил пакет на роутер своего интернет-провайдера.
Вот что происходит с пакетом дальше:
- Роутер провайдера Кенни передаёт пакет с данными роутеру другого провайдера, с которым он соединён физическим кабелем.
- Этот роутер передаёт пакет дальше (опять по кабелю).
- Процесс продолжается, пока пакет с данными не дойдёт до того роутера, с которым соединён целевой сервер.
Выглядит просто, но есть один вопрос. Ведь весь интернет представляет собой огромную сеть из серверов, роутеров и прочего, соединённых между собой. Эти серверы принадлежат разным компаниям-провайдерам, которые обслуживают разных пользователей. И вот провайдер Кенни соединён не с одним, а сразу с несколькими другими провайдерами — как ему узнать, кому из них передавать пакет, чтобы он достиг точки назначения?
Работает это следующим образом:
- Роутер, соединённый с целевым сервером, передаёт всем соседним роутерам (фактически, другим провайдерам) информацию о том, что он «отвечает» за все IP-адреса с определённым префиксом. Эти адреса включают и IP-адрес целевого сервера. Для передачи этой информации используется протокол BGP (англ. Border Gateway Protocol, протокол граничного шлюза).
- Они транслируют эту информацию дальше по другим роутерам, с которыми они соединены.
- В конце концов до роутера Кенни доходит информация обо всех маршрутах, по которым можно добраться до целевого сервера.
- Маршрут выбирается просто: берётся тот, на котором задействовано меньше всего роутеров.
Я делаю одно большое упрощение, чтобы сделать описание более понятным. На самом деле обмен информацией происходит между так называемыми «автономными системами» (autonomous system), которые внутри себя также могут пропускать трафик через кучу роутеров. Каждая автономная система — это совокупность IP-адресов и роутеров, обычно управляемых одной организацией (например, провайдером).
Маршрутизация Anycast
Окей, с маршрутизацией разобрались. Но как нам это помогает и что вообще такое Anycast? Давайте представим себе ситуацию, в которой много роутеров в разных точках мира говорят соседям одно и то же: «Эй, я отвечаю за все IP-адреса с этим префиксом!». Как и в предыдущем примере, эта информация в итоге доходит до роутера Кенни.
А этот роутер для пакета Кенни выбирает самый короткий маршрут из возможных.
Вот этот механизм и называется Anycast routing и именно его мы используем в AdGuard DNS для того, чтобы гарантировать, что вам ответит ближайший сервер.
Недостатки Anycast
Anycast — хорошее, но не идеальное решение. Дело в том, что длина маршрута не гарантирует, что соединение действительно будет быстрее, ведь в расчёт берётся только количество точек, а не качество соединения между ними. Даже в этом случае протокол BGP позволяет в определённых рамках влиять на маршруты. Например, мы можем «искусственно» сделать какой-то маршрут длиннее.
Возьмём для примера диаграмму выше. Кенни соединился с сервером в Майами, так как маршрут туда короче, но на самом деле его соединение работало бы гораздо быстрее, если бы его отправило в Амстердам. Можем ли мы как-то повлиять на это? Ответ на этот вопрос - "возможно", так как это зависит от того, какие возможности по кастомизации предоставлены нам автономными системами, с которыми соединены наши сервера.
Многие автономные системы позволяют использовать так называемые «BGP community» для гибкой настройки маршрутизации. По сути, BGP community — это некий «маркер», который передаётся вместе с данными о маршруте. Опираясь на этот маркер, роутер, принимающий маршрут, может искусственно удлинить маршрут или вообще избавиться от него и не передавать информацию о нем дальше по цепочке.
Давайте попробуем использовать BGP community, чтобы трафик Кенни пошёл не по более короткому, а по более быстрому пути.
В этом примере нам повезло, провайдеры на пути к Кенни позволяют использовать BGP community, которые «занулят» маршрут до провайдера Кенни — то есть его роутер вообще не узнает об этом маршруте. Так что мы просто соответствующим образом маркируем данные о маршрутах, которые анонсируются с помощью протокола BGP.
Благодаря этому, провайдер Кенни вообще не узнал о маршрутах в Майами и Сингапур. В итоге желаемая нами цель достигнута, у нас получилось исправить маршруты таким образом, чтобы трафик пошёл в Амстердам.
К сожалению, в реальной жизни всё не так просто:
- Не все провайдеры позволяют использовать BGP community для гибкой настройки.
- Иногда, чтобы выяснить наличие такой настройки, нам нужно писать напрямую провайдерам, так как эта информация не опубликована или зарыта в глубинах сайтов.
- Не всегда BGP community предоставляют достаточную гибкость в настройке.
Не существует единственно верного решения и правильная маршрутизация — это постоянная работа, которой мы занимаемся.
