На днях Amazon выкатили что-то типа постмортема по нашумевшему сбою 19-20 октября в регионе
us-east-1 — одном из их самых важных регионов всего AWS. Напомню, тогда тысячи сервисов по всему миру, включая Reddit, The Washington Post и Perplexity, были недоступны или работали с перебоями. Масштаб был колоссальный. Нам в РФ немного "повезло", как и прошлогоднем сбое в Windows и Crowdstrike, о котором я писал раньше - у нас AWS заблокирован, поэтому бизнес там ничего не хостил.Что там было.
Часть 1: Падение DynamoDB
Коревая причина - скрытый баг в виде гонки состояний (race condition) в системе управления DNS сервиса DynamoDB (NoSQL БД). Для управления тьмой DNS записей (пишут, что записей сотни тысяч, охотно верю), у ребят был написан собственный сервис автоматизации управления. В нём два компонента:
- DNS Planner. Как я понял, это штука, которая мониторит состояние входных балансировщиков DynamoDB и менеджерит все DNS записи в регионе. Это единая точка управления, которая позволяет менять DNSы сразу по огромной инфре DynamoDB. Ребята пишут, что недавно они не без помощи этой системы смогли внедрить IPv6 эндоинты - кто забыл, для IPv6 нужны записи типа AAAA (я не ору, это тип записей так называется), запустить такую фичу на их масштабах просто невозможно без подобной системы.
- DNS Enactor. Это система типа рук DNS Planner'а. Планер планирует, а Enactor фактически выполняет сформированный план. Для отказоустойчивости (хе хе) Enactor'ов три штуки в разных зонах доступности. Они мониторят появление новых планов и транзакционно их применяют. Поэтому если один Enactor сломался, другие все равно все сделают.
Что именно пошло не так, следите за руками:
1. Медленный Enactor. Первый Enactor'ов взял план в работу и чуть завис, пытаясь применить DNS-план. Пишут, что такое обычно не случается и все работает быстро, ага. В самом начале своей работы Enactor чекает, что у него в работе ДЕЙСТВИТЕЛЬНО новейший DNS-план. Делает он это через походы в несколько эндпоинтов, и вот в этот раз он тут задержался. Скорее всего, какие-то их них отвечали дольше обычного, он делал ретраи, но в целом, в этот момент задержка была значительно дольше обычного.
2. Быстрый и везучий Enactor. Пока первый Enactor тормозил, Planner успел создал несколько новых планов, новейший из которых подхватил второй Enactor и успешно применил. Тут ему повезло, он не словил таких задержек, как словил первый.
3. Очистка прошлых планов. В конце своей работы быстрый Enactor, как и обычно, запустил очистку старых планов (они не нужны, он ведь уже применил новейший), и потер план, который был уже в работе у первого Enactor'а.
4. Неконсистентое состояние. Тут «зависший» Enactor наконец-то отмирает и идет выполнять свой очень старый план. Напомню, он уже типа успешно проверил, что у него самая актуальная версия плана. Судя по всему, за деталями плана он идет в БД, а там плана уже нет. И он выставляет пустые DNS по всем управляемым записям.
В итоге куча DNS записей DynamoDB оказались пустыми. Никто не может к ним подключиться и дальше начинается эффект домино, о котором напишу в следующей части.