«Не мог же Фейсбук упасть?» – подумали мы на какое-то мгновение.
Сегодня в 15:51 UTC мы открыли внутренний инцидент под названием "DNS-поиск для Facebook возвращает SERVFAIL", поскольку забеспокоились, что что-то не так с нашим DNS-резолвером 1.1.1.1. Мы уже собирались сделать пост на нашей публичной странице состояния, но тут стало ясно, что происходит нечто более серьезное.
Социальные сети взорвались сообщениями, которые и наши инженеры быстро подтвердили. Facebook, а также принадлежащие ему сервисы WhatsApp и Instagram, действительно упали. Их DNS-имена перестали разрешаться, а IP-адреса инфраструктуры стали недоступны. Словно кто-то разом «выдернул кабели» из их центров обработки данных и отключил их от Интернета.
Это не было проблемой DNS, однако сбой DNS стал первым симптомом более масштабного сбоя в работе Facebook.
Как такое вообще возможно?
Сообщение Facebook
Facebook опубликовал у себя в блоге сообщение с некоторыми подробностями того, что произошло внутри компании. Со стороны мы наблюдали проблемы с BGP и DNS, описанные в данном посте, но на самом деле проблема началась с изменения конфигурации, которое затронуло всю внутреннюю магистральную сеть. Это вызвало целую цепочку последствий, Facebook и другие ресурсы исчезли из сети, при этом собственные сотрудники Facebook столкнулись с трудностями, пытаясь восстановить работу сервиса.
Facebook опубликовал еще одну запись в блоге с гораздо более подробной информацией о том, что произошло. В их посте – взгляд изнутри, в нашем – взгляд со стороны.
Теперь перейдем к тому, что мы увидели со своей стороны.
Знакомьтесь с BGP
BGP расшифровывается как Border Gateway Protocol (Протокол граничного шлюза). Это механизм обмена информацией о маршрутизации между автономными системами (AS) в Интернете. Крупные маршрутизаторы, обеспечивающие работу Интернета, имеют огромные, постоянно обновляемые списки возможных маршрутов, по которым каждый сетевой пакет может быть доставлен в конечный пункт назначения. Без BGP маршрутизаторы Интернета не знали бы, что им делать, и Интернет не смог бы работать.
Интернет – это в буквальном смысле сеть сетей, и они связаны между собой при помощи BGP. BGP позволяет одной сети (скажем, Facebook) анонсировать свое присутствие другим сетям, образующим Интернет. В данный момент Facebook не анонсирует свое присутствие, интернет-провайдеры и другие сети не могут найти сеть Facebook, и поэтому она недоступна.
Каждая отдельная сеть имеет свой ASN: Autonomous System Number (Номер автономной системы). Автономная система (AS) – это отдельная сеть с единой политикой внутренней маршрутизации. AS может формировать собственные префиксы (означающие, что она контролирует группу IP-адресов), а также транзитные префиксы (означающие, что она знает путь к определенной группе IP-адресов).
Cloudflare имеет ASN AS13335. Каждый ASN должен анонсировать в Интернете маршруты к своим префиксам с помощью BGP, иначе никто не будет знать, как подключиться и где нас найти.
В нашем учебном центре имеется подробный обзор BGP и ASN и принципа их работы.
На этой упрощенной схеме изображены шесть автономных систем в Интернете и два возможных маршрута, по которым пакет может пройти от начала до конца. AS1 → AS2 → AS3 – наиболее быстрый маршрут, а AS1 → AS6 → AS5 → AS4 → AS3 – наиболее медленный, но его можно использовать, если первый не сработает.
В 15:58 UTC мы заметили, что Facebook перестал анонсировать маршруты к своим префиксам DNS. Это означало, что, как минимум, DNS-серверы Facebook недоступны. Поэтому DNS-резолвер Cloudflare 1.1.1.1 больше не мог отвечать на запросы, требующие сообщить IP-адрес домена facebook.com.
Тем временем другие IP-адреса Facebook по-прежнему маршрутизировались, но от них не было особой пользы, поскольку без DNS Facebook и связанные с ним сервисы были фактически недоступны:
Мы отслеживаем все обновления и анонсы BGP, поступающие в нашу глобальную сеть. Благодаря масштабу нашей сети собираемые данные дают нам представление о связях в Интернете и о том, откуда и куда должен направляться трафик в любой точке планеты.
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>Сообщение BGP UPDATE информирует маршрутизатор о любых изменениях в анонсе префикса или полностью отзывает префикс. Если обратиться к нашей базе данных временных рядов BGP, хорошо видно количество обновлений, полученных нами от Facebook. Обычно этот график довольно спокойный: 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>Но примерно в 15:40 UTC мы увидели резкий всплеск изменений маршрутизации со стороны Facebook. Тогда-то и начались проблемы.
Если разбить этот график на анонсы и отзывы маршрутов, станет еще яснее, что произошло. Маршруты были отозваны, DNS-серверы Facebook ушли в офлайн, и уже через минуту после возникновения проблемы инженеры Cloudflare сидели и недоумевали, почему 1.1.1.1 не выдает IP для facebook.com, и беспокоились, что это вызвано каким-то сбоем в наших системах.
В результате отзыва маршрутов Facebook и его сайты фактически отключились от Интернета.
DNS тоже пострадал
Прямым следствием произошедшего стало то, что DNS-резолверы по всему миру перестали выдавать IP-адреса этих доменных имен.
Это произошло потому, что DNS, как и многие другие системы в Интернете, также имеет свой механизм маршрутизации. Когда кто-либо набирает в браузере URL https://facebook.com, DNS-резолвер, отвечающий за преобразование доменных имен в IP-адреса, с которыми устанавливается соединение, сначала проверяет, нет ли IP-адреса у него в кэше, и если есть, использует его. Если нет, он пытается получить ответ от сервера имен соответствующего домена, расположенного, как правило, в организации, которой домен принадлежит.
Если серверы имен недоступны или не отвечают по какой-либо другой причине, возвращается ответ SERVFAIL, и браузер выдает пользователю ошибку.
➜ ~ 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.
Поскольку Facebook перестал анонсировать по BGP маршруты к своим префиксам DNS, наши и все прочие DNS-резолверы утратили возможность подключаться к его серверам имен. Соответственно, 1.1.1.1, 8.8.8.8 и другие крупные публичные DNS-резолверы начали выдавать (и кэшировать) ответы SERVFAIL.
Но это еще не все. Теперь в дело вступает человеческий фактор и логика работы приложений, вызывая еще один экспоненциальный эффект. Возникает цунами дополнительного DNS-трафика.
Это происходит отчасти потому, что приложения не принимают ошибку за ответ и начинают повторять попытки, порой очень интенсивно, а отчасти потому, что конечные пользователи также не принимают ошибку за ответ и начинают перезагружать страницы или закрывать и перезапускать приложения, иногда тоже весьма интенсивно.
Вот рост трафика (по числу запросов), который мы наблюдали на 1.1.1.1:
Таким образом, поскольку Facebook и его сайты привлекают огромный трафик, DNS-резолверы по всему миру теперь вынуждены обрабатывать в 30 раз больше запросов, чем обычно, что чревато задержками и таймаутами для других платформ.
К счастью, 1.1.1.1 — бесплатный, приватный, быстрый (что может подтвердить независимый DNS-монитор DNSPerf) и масштабируемый сервис, что позволило нам продолжать обслуживать пользователей практически в штатном режиме.
Время ответа на подавляющее большинство наших DNS-запросов составило менее 10 мс. В то же время у крайне небольшой части перцентилей p95 и p99 время отклика увеличилось — вероятно, из-за того, что истекшие TTL вынуждали обращаться к серверам имен Facebook с последующим таймаутом. 10-секундный таймаут в системе DNS хорошо известен инженерам.
Влияние на другие сервисы
Пользователи начинают искать альтернативы, хотят узнать подробности или обсудить происходящее. Когда Facebook стал недоступен, мы увидели рост числа DNS-запросов к Twitter, Signal и другим платформам обмена сообщениями и социальным сетям.
Еще один побочный эффект недоступности сказался на нашем WARP-трафике к сети Facebook (ASN 32934) и обратно. Этот график показывает, как изменился трафик в каждой стране с 15:45 UTC до 16:45 UTC по сравнению с тремя часами ранее. По всему миру WARP-трафик к сети Facebook и обратно просто исчез.
Интернет
Сегодняшние события – мягкое напоминание о том, что Интернет представляет собой очень сложную и взаимозависимую систему, состоящую из миллионов систем и протоколов, работающих вместе. Доверие, стандартизация и сотрудничество между организациями являются ключевыми факторами, обеспечивающими его работоспособность для почти пяти миллиардов активных пользователей по всему миру.
Обновление
Примерно в 21:00 UTC мы заметили возобновление активности BGP со стороны сети Facebook, она достигла пика в 21:17 UTC.
На данном графике показана доступность DNS-имени facebook.com на DNS-резолвере Cloudflare 1.1.1.1. Доступность пропала примерно в 15:50 UTC и восстановилась в 21:20 UTC.
Сервисам Facebook, WhatsApp и Instagram наверняка потребуется еще какое-то время, чтобы вернуться в строй, но по состоянию на 21:28 UTC Facebook, похоже, восстановил подключение к глобальному Интернету, и его DNS вновь работает.