Кратко

  • 21 апреля 2011 года ошибочное переключение трафика EBS на менее производительную сеть репликации изолировало множество узлов в одной зоне доступности US East.
  • После восстановления связности одновременный поиск новых реплик исчерпал свободную ёмкость и вызвал «шторм повторного зеркалирования»; его последствия затронули также региональный управляющий контур.
  • AWS сообщила, что при стабилизации около 13% томов в затронутой зоне оставались заблокированными, а 0,07% томов этой же зоны не удалось вернуть в согласованное состояние. Эти показатели нельзя распространять на весь регион или всех клиентов AWS.

Что именно произошло

Согласно посмертному отчёту AWS, EBS того времени хранила реплики в кластерах внутри зоны доступности. Узлы обменивались данными по основной высокопроизводительной сети, а отдельная сеть меньшей пропускной способности служила для репликации. Региональный управляющий контур координировал операции с томами. Это описание относится к архитектуре 2011 года и не должно восприниматься как описание нынешней платформы.

В 00:47 по тихоокеанскому летнему времени 21 апреля во время изменения пропускной способности основной сети трафик был ошибочно направлен в сеть репликации. Она не была рассчитана на такую нагрузку. Многие узлы потеряли эффективную связь и с основной, и с резервной сетями. Именно это изменение было триггером. Однако триггер ещё не объясняет продолжительность и масштаб последующего восстановления.

Когда связность вернулась, большое число узлов одновременно стало искать новые реплики для томов, которые считались недостаточно защищёнными. Свободная ёмкость быстро закончилась. Недостаточно агрессивная задержка повторных попыток и редкое состояние гонки усилили поток запросов. Механизм, предназначенный для восстановления избыточности, создал самоподдерживающуюся нагрузку — шторм повторного зеркалирования.

Здесь полезно разделять причины. Неверное сетевое переключение запустило событие. Ограниченная резервная пропускная способность создала исходную изоляцию. Недостаток свободной восстановительной ёмкости, слабое замедление повторов и состояние гонки превратили локальное нарушение связности в затяжной кризис восстановления. Называть один сетевой шаг единственной коренной причиной означало бы потерять именно ту цепочку контроля, которая определила ущерб.

Почему проблема вышла за границы повреждённого кластера

Новые операции создания томов зависали надолго и занимали потоки регионального управляющего контура. Когда пул потоков оказался исчерпан, ошибки и задержки API EBS наблюдались и за пределами непосредственно затронутой зоны доступности. AWS изолировала деградировавший кластер и ограничила нагрузку, чтобы вернуть управляющему контуру работоспособность.

Это важная граница фактов. Основной отказ хранения был сосредоточен в одной зоне доступности US East. В другие части региона распространилось ограниченное по времени ухудшение API, а не одинаковый отказ всех томов. Источники не подтверждают ни глобальную аварию AWS, ни единый исход для всех клиентов региона.

Восстановление также не было одним моментом. Сначала требовалось остановить дальнейшее ухудшение, затем разгрузить управляющий контур, добавить физическую ёмкость, восстанавливать реплики небольшими партиями, обработать накопленные запросы и отдельно разбирать остаточные проблемные тома. Поэтому фразы вроде «сервис восстановлен» без указания конкретной функции могут скрывать существенную разницу между доступностью API, доступностью тома и завершением проверки согласованности.

Масштаб: два процента, два разных результата

AWS сообщила, что после стабилизации около 13% томов в затронутой зоне доступности оставались в зависшем состоянии. Компания также сообщила, что в конечном счёте 0,07% томов в той же зоне не удалось восстановить в согласованном состоянии. Первый показатель описывает промежуточный масштаб блокировки; второй — остаточный результат восстановления данных. Их нельзя смешивать.

Знаменатель в обоих случаях — тома затронутой зоны доступности, а не все тома US East, не все клиенты и тем более не вся AWS. Публичные материалы не раскрывают число затронутых клиентов, объём потерянных байтов или записей и совокупный экономический ущерб. Поэтому серьёзность следует описывать через подтверждённые эксплуатационные последствия, а не через вымышленные абсолютные величины.

Зависимости RDS и внешних платформ

Amazon RDS использовала EBS для хранения баз данных и журналов. AWS сообщила, что ранее не встречавшееся состояние помешало автоматическому переключению части экземпляров Multi-AZ, и потребовалось ручное вмешательство. Это не доказывает, что каждый экземпляр Multi-AZ отказал, и не позволяет объединять результаты однозонных и многозонных конфигураций.

Heroku непосредственно описала широкомасштабный сбой приложений на своей платформе. Современные событию публикации называли Reddit, Foursquare, Quora и другие публичные сервисы. Эти свидетельства показывают реальную цепочку зависимости между инфраструктурным поставщиком, платформой и приложениями. Но список не является полной переписью пострадавших, а названные сервисы могли иметь разные пути отказа, длительность и качество восстановления.

Контроль и ответственность

AWS располагала наибольшей информацией и полномочиями для управления внутренней сетью, ёмкостью кластеров, алгоритмами повторных попыток, изоляцией управляющего контура и последовательностью восстановления. Поэтому ответственность оператора в данном случае следует оценивать по тому, были ли заранее ограничены потребности защитного механизма, существовал ли достаточный запас и можно ли было доказать завершение восстановления по каждому ресурсу.

Клиенты, со своей стороны, контролировали архитектуру приложений, резервное копирование и выбор способов распределения нагрузки. Однако этот факт не переносит на них ответственность за внутренний сетевой триггер или поведение EBS. Многозонная либо многорегиональная схема может уменьшать некоторые риски, но источники не позволяют утверждать, что она предотвращает любое воздействие на управляющий контур или приложение.

В источниках нет оснований обвинять конкретного человека, устанавливать халатность, незаконность, нарушение регулирования или договорную ответственность. Сервисный кредит также не доказывает полного возмещения ущерба. Подотчётность здесь — не юридический вердикт, а требование связать полномочия с наблюдаемыми мерами контроля и проверяемыми результатами.

Объявленные меры и предел доказательств

После инцидента AWS объявила о более крупных резервах восстановительной ёмкости, более агрессивном замедлении повторов, исправлении состояния гонки, улучшении тайм-аутов и сброса нагрузки, усилении изоляции зон, автоматизации восстановления, развитии инструментов Multi-AZ и более частых сообщениях клиентам.

Эти меры логично соответствуют выявленной цепочке отказа: уменьшают усиление запросов, защищают управляющий контур и делают восстановление более управляемым. Но закрытый набор источников подтверждает лишь то, что AWS их объявила. Он не является независимым доказательством внедрения, эффективности или сохранения этих механизмов в современной архитектуре.

Главный вывод поэтому формулируется осторожно. Репликация защищает данные только тогда, когда её восстановительный контур имеет ограниченный максимальный спрос, отдельную ёмкость, устойчивую обратную связь и механизм изоляции. Если массовое восстановление способно поглотить все свободные ресурсы и заблокировать управляющий контур, резервирование превращается из защиты в усилитель аварии.

Источники