Мини-разбор крупного сбоя AWS: как гонка потоков в DNS обрушила пол-интернета. Часть 2 В прошлой части я начал разбирать постмортем сбоя в AWS, в этом продолжу. Часть 2: Эффект домино Тут-то и началось самое интересное. Оказалось, что DynamoDB это фундамент для многих других сервисов AWS, и его отказ запустил цепную реакцию: - EC2 (виртуальные серверы): для начала, какое-то время совсем не работало создание новых ВМ. Как пишут, DynamoDB использовалось в Control Plane системе, которая управляла железными кластерами, на которых крутились ВМ. Для синхронизации состояния (например, перезагрузка, запуск новой ВМ и т.д.) использовалась логика, которая хранила данные в сервисной БД. Базы больше нет, синки не происходит и, как следствие, в Control Plane накопилась дикая очередь задач на синхронизацию. Примечательно, что очередь в какой-то момент начала расти лавинообразно: сервер не создавался за заданный таймаут, поэтому система ставила новую задачу в очередь на создание, и т.д. - EC2 (опять): когда это разглебли, то оказалось, что новые ВМки создаются, но не становятся доступными по сети. Тачку создал, а достучаться до нее никто не может. После создания ВМ на нее нужно задеплоить сетевую конфигурацию и контроллер, который отвечает за эту работу, не был готов к такой нагрузке, которая на него обрушилась после нескольких часов простоя. Инженерам AWS пришлось сильно ограничивать очередь, чтобы воркеры обрабатывали записи и не "захлебывались". Пока они этим занимались, цепная реакция продолжалась. - NLB (балансировщик нагрузки): новые ВМки попадали в конфиги балансировщиков КУЧИ разных сервисов, но мы помним, что многие из них все еще недоступны по сети. Это привело к очень интересной ситуации. Для health check'ов была своя собственная подсистема - это логично, на таких масштабах health check'и это так еще задача. Из-за того, что неадекватно много нод EC2 были недоступны и не проходили проверку на health check, система этих самых health check'ов автоматически масштабировалась под рост нагрузки. И самое прикольное, что для этого она создавала серверы из...EC2! Таким образом, уже в работе самой подсистемы health check'ов были недоступные ВМки. Это приводило к тому, что часть задач health check'ов распределялись и на них и помечались FAILED, хотя вполне возможно, что целевой сервис был жив и здоров. Ситуацию осложняло то, что из-за таких "флапающих" проверок - то сервис доступен, то недоступен, смотря какая нода будет делать health check - срабатывала другая автоматика, которая выполняла всякие failover операции. Это приводило к другим каскадным изменениям в системах🫠 - Из-за проблем на таком фундаментальном и платформенном уровне, страдать каскадно начали вообще все сервисы AWS. Из "прикольного" отмечу разве что IAM (система аутентификации и авторизации) - пока она лежала, никто не мог никуда залогиниться, а чтобы оживить сервисы надо было что-то сделать, а для этого надо залогиниться:) ​ Сбой длился примерно 15 часов. В интернетах пишут о разных выводах, которые люди сделали для себя - кто-то о важности multi-cloud, чтобы не зависеть от одного провайдера, кто-то о важности настроенных процессов инцидент-менеджмента и ранбуков в командах, кто-то о хрупкости всех этих гигантских систем и том, что ИИ нас тут спасет. Я тоже сделал некоторые выводы, о них напишу в следующей части.