[Перевод] Из-за чего Facebook стал глобально недоступен. Технический ликбез
Прим. перев.: в этой статье инженеры онлайн-сервиса Cloudflare весьма популярно объясняют, что именно (технически) произошло с недоступностью Facebook минувшим вечером (4-го октября 2021), а также затрагивают тему того, как этот сбой повлиял на более глобальные процессы в интернете.
«Разве Facebook может упасть?» — задумались мы на секунду…
Сегодня в 16:51 UTC (в 19:51 MSK — прим. перев.) у нас был открыт внутренний инцидент под названием «Facebook DNS lookup returning SERVFAIL» («DNS-поиск для Facebook возвращает SERVFAIL»). Мы решили, что это с нашим DNS-ресолвером 1.1.1.1 что-то не так. Однако к моменту размещения соответствующего обновления на публичной статус-странице стало ясно, что здесь что-то серьёзное.
Социальные сети уже разрывались от сообщений о том, что быстро подтвердили и наши инженеры: Facebook и связанные с ним сервисы WhatsApp и Instagram действительно упали. Их DNS-имена больше не ресолвились, а IP-адреса инфраструктуры были недоступны. Выглядело так, как будто кто-то буквально выдернул кабели разом во всех их дата-центрах, отключив от интернета.
Как такое вообще возможно?
Встречайте BGP
BGP — это «протокол граничного шлюза» (Border Gateway Protocol). Это механизм для обмена информацией о маршрутизации между автономными системами (AS) в интернете. У больших роутеров, благодаря которым работает интернет, есть постоянно обновляемые списки возможных маршрутов, используемых для доставки каждого сетевого пакета до мест их назначения. Без BGP интернет-роутеры не знают, что делать, и интернет просто не будет работать.
Интернет — это буквально сеть из сетей, связанных между собой с помощью BGP. BGP позволяет одной сети (скажем, Facebook) объявлять о своём присутствии другим сетям, которые в конечном счёте формируют весь интернет. На момент написания этой статьи Facebook не сообщал о своём присутствии, поэтому интернет-провайдеры (ISP) и другие сети не могут найти сеть Facebook — она недоступна.
У индивидуальных сетей есть свой ASN — номер автономной системы (Autonomous System Number). Автономная система (AS) — это индивидуальная сеть с унифицированной политикой внутренней маршрутизации. AS может порождать специальные префиксы (означающие, что они контролируют группу IP-адресов), а также транзитные префиксы (они знают, как добраться до определённых групп IP-адресов).
Например, ASN у Cloudflare — AS13335. Каждая ASN должна объявить интернету о своих prefix routes с помощью BGP. В ином случае никто не узнает, как к ней подключиться и где найти её.
В онлайн-центре обучения Cloudflare есть отличный обзор того, что такое BGP, ASN и как они работают.
В этой упрощённой схеме можно увидеть шесть автономных систем в интернете и два возможных маршрута, по которым один пакет может пройти от начала (Start) до конца (End). Самый быстрый маршрут — это AS1 → AS2 → AS3. Самый медленный — AS1 → AS6 → AS5 → AS4 → AS3; он используется в случаях, когда первый не срабатывает.
В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов. Это означало, что по меньшей мере DNS-серверы Facebook были недоступны. По этой причине DNS-ресолвер Cloudflare (уже упомянутый 1.1.1.1) не мог отвечать на запросы, требующие выдать IP-адрес для домена facebook.com или instagram.com.
route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>
route-views>show ip bgp 129.134.30.0/23
% Network not in table
route-views>Хотя другие IP-адресы Facebook и имели маршруты в то же самое время, в них не было особого смысла, потому что DNS-службы Facebook и связанных сервисов были недоступны:
route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
Paths: (24 available, best #14, table default)
Not advertised to any peer
Refresh Epoch 2
3303 6453 32934
217.192.89.50 from 217.192.89.50 (138.187.128.158)
Origin IGP, localpref 100, valid, external
Community: 3303:1004 3303:1006 3303:3075 6453:3000 6453:3400 6453:3402
path 7FE1408ED9C8 RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
route-views>Мы следим за всеми обновлениями и анонсами в BGP, какие появляются в глобальной сети. Собираемые таким образом данные позволяют увидеть глобальные связи в интернете и понять, откуда и куда трафик должен ходить весь трафик.
UPDATE-сообщение от BGP информирует роутер о любых изменениях, сделанных в префиксе, или о полном отзыве этого префикса. Проверяя базу данных BGP, основанную на временных рядах, мы можем точно увидеть количество обновлений, поступивших от Facebook«а. Обычно этот график довольно ровный: Facebook не будет постоянно делать большое количество изменений для своей сети.
Но около 15:40 UTC была замечен резкий всплеск изменений в маршрутах Facebook«а. Именно здесь и начались проблемы.
Ещё лучше будет видно, что же произошло, если разбить этот график на анонсы маршрутов и их отзывы. Маршруты были отозваны, DNS-серверы Facebook ушли в offline, а минутой позже возникла проблема: инженеры Cloudflare сидели и недоумевали, почему 1.1.1.1 не может получить IP для facebook.com, обеспокоенные каким-то сбоем в своих системах.
После отзыва этих маршрутов Facebook и его сайты были отключены от интернета.
DNS тоже в деле
Прямым последствием этого события стала невозможность для DNS-ресолверов со всего мира получать IP для связанных с проектами доменных имён:
➜ ~ dig @1.1.1.1 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @1.1.1.1 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN A
➜ ~ dig @8.8.8.8 facebook.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;facebook.com. IN A
➜ ~ dig @8.8.8.8 whatsapp.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31322
;whatsapp.com. IN AЭто происходит по той причине, что в DNS, как и во многих других системах в интернете, используется свой механизм маршрутизации. Когда кто-то набирает https://facebook.com в веб-браузере, DNS-ресолвер, ответственный за перевод доменного имени в реальный IP-адрес для фактического подключения, сначала проверяет, есть ли что-то в его кэше. Если кэш есть — он используется. Если кэша нет — производится попытка получит ответ от DNS-сервера, обычно расположенного где-то поблизости.
Если DNS-серверы недоступны или не могут дать ответ по какой-то другой причине, возвращается ответ SERVFAIL, а браузер показывает пользователю ошибку.
Опять же, в онлайн-центре обучения Cloudflare есть хорошее объяснение, как работает DNS.
Из-за того, что Facebook перестал анонсировать свои DNS prefix routes через BGP, наш и любой другой DNS-ресолвер не мог подключиться DNS-серверам проекта. Поэтому, 1.1.1.1, 8.8.8.8 и другие крупные публичные DNS-ресолверы начали выдавать (и кэшировать) ответы SERVFAIL.
Но это ещё не всё. Теперь в дело включается человеческий фактор и логика работы приложения, что в совокупности приводит к экспоненциальному эффекту. От пользователей обрушивается огромная волна дополнительного DNS-трафика.
Отчасти это происходит по той причине, что приложения не расценивают ошибку как подходящий пользователю ответ и начинают делать повторные запросы, причем иногда очень активно. А отчасти — потому что конечные пользователи тоже не воспрнимают ошибку за правильный для них результат и начинают обновлять страницы, убивать/перезапускать свои приложения, порой тоже весьма активно.
Всё это привело к резкому росту трафика (по количеству запросов), что мы наблюдали на 1.1.1.1:
Из-за того, что Facebook и его сайты так популярны, мы получили 30-кратную нагрузку на DNS-ресолверы по всему миру, а это может вызывать задержки и таймауты для других платформ.
К счастью, 1.1.1.1 был создан как бесплатный, приватный, быстрый (убедиться в этом можно в DNSPerf) и масштабируемый сервис, так что мы продолжали обслуживать своих пользователей с минимальными проблемами.
Скорость ответов на подавляющую часть DNS-запросов оставалась в диапазоне менее 10 мс. В то же время небольшая часть перцентилей p95 и p99 показали повышенное время ответов — вероятно, из-за истекших TTL при обращении к DNS-серверам Facebook и вызванных таймаутов. 10-секундный таймаут для DNS — значение, которое пользуется популярностью среди инженеров.
Влияние на другие сервисы
Люди ищут альтернатив, хотят знать и обсуждать, что происходит. Когда Facebook упал, мы увидели растущее число DNS-запросов к Twitter, Signal и другим социальным сетям и платформам для обмена сообщениями.
Также недоступность проявилась в статистике по WARP-трафику от и к автономной сети Facebook«а (ASN 32934). Эта карта показывает, как трафик изменился в интервале с 15:45 UTC до 16:45 UTC по сравнению с тремя часами до этого в каждой стране. По всему миру WARP-трафик от и к сети Facebook практически исчез.
Интернет
Сегодняшние события служат мягким напоминанием о том, что интернет — это очень сложная и взаимозависимая система из миллионов систем и протоколов, взаимодействующих друг с другом. Доверие, стандартизация и кооперация между задействованными в нём организациями — ключ к его работоспособности для почти пяти миллиардов активных пользователей со всего мира.
Обновление
Около 21:00 UTC (полночь в MSK — прим. перев.) мы увидели новую BGP-активность в сети Facebook, пик которой пришёлся на 21:17 UTC:
График ниже показывает доступность DNS-имени 'facebook.com' на DNS-ресолвере 1.1.1.1. Она пропала около 15:50 UTC и вернулась в строй в 21:20 UTC:
Несомненно, сервисам Facebook, WhatsApp и Instagram ещё понадобится некоторое время, чтобы полностью вернуться в строй, но по состоянию на 21:28 UTC Facebook уже доступен в глобальном интернете, а его DNS снова функционирует.
P.S. от переводчика
Читайте также в нашем блоге:
