DynamoDB представляет собой распределенную документ-ориентированную БД. Она обеспечивающую мгновенный доступ к хранящейся в ней информации, имеет встроенную систему безопасности и механизмы резервного копирования и восстановления данных. 20 сентбря 2015 года система перестала работать.
Технические сведения о DynamoDB. DynamoDB хранит информацию в таблицах, разделенных на части (разделы), в каждой из которых содержится часть всей информации в БД. Эти разделы распределены по множеству серверов для обеспечения быстрого (с малой задержкой) и постоянного доступа к хранящейся информации, а также для целей репликации данных.
Принадлежность разделов к конкретному серверу называется "членством" (membership). Членство некоторого множества таблиц/разделов в рамках одного сервера управляется внутренней службой управления метаданными DynamoDB. Служба имеет внутреннюю репликацию и запускается в нескольких центра обработки данных (ЦОД). Сервера хранения данных содержат актуальные данные таблицы внутри раздела, а также периодически выполняют проверку того, что разделам определено корректное членство. Они осуществляют такую проверку, связываясь со службой управления метаданными. В ответ на запрос служба получает список разделов и всю связанную информацию из своего локального хранилища, объединяет эти данные в сообщении, передаваемом в последствии на сервер. Сервер хранения также получает сведения о собственном членстве при старте, либо после неполадок сети. После того, как сервер хранения данных закончил обработку собственных сведений о членстве, он проверяет наличие таблиц/разделов в локальном хранилище, создает новые связанные таблицы/разделы и получает данные от других серверов хранения для репликации существующих связанных разделов.
Первоначальная причина отказа. В 2:19 ночи (тихоокеанское летнее время, -10 часов от МСК) наблюдалось кратковременное падение сети, затронувшее несколько серверов DynamoDB. Обычно аналогичные падения сети обрабатываются не заметно и без изменения производительности DynamoDB, так как затронутые сервера хранения запрашивают службу управления метаданными сведения о своем членстве, применяют все необходимые обновления и сообщают, что они вновь могут обрабатывать запросы. Если сервера хранения не могут получить информацию назад в течение определенного периода времени, они отправляют повторный запрос о членстве и временно отписываются от обработки запросов.
Основная проблема. Но воскресным утром несколько ответов службы управления метаданными превысили предел времени получения и передачи данных. В следствие чего некоторые из серверов не смогли получить сведения о членстве и отписались от обработки запросов. Увеличение времени ответа было связано с недавней доработкой DynamoDB: в последние несколько месяцев пользователи часто применяли GSI (Globl Secondary Indexes). GSI позволяет обращаться к данным по альтернативным ключам (а не по первичным). Так как GSI является глобальным, он имеет свой собственный набор разделов на серверах хранения, тем самым увеличивая общий размер членских данных. Пользователи могут добавить несколько GSI для одной таблицы, поэтому таблица с большим числом разделов может быстро удвоить или утроить размер таких данных. За счет быстрого применения технологии пользователями для больших таблиц индекс "разделов-на-таблицы" значительно вырос. Из-за больших размеров членских данных время обработки некоторых запросов начало приближаться к пороговым значениям. Amazon не вел мониторинга размера данных о членстве и не имел достаточных мощностей для обработки таких тяжеловесных запросов.
Таким образом, когда в воскресенье после проблем с сетью несколько серверов одновременно запросили свои членские данные, служба управления метаданными обрабатывала тяжелые запросы. Несколько одновременных запросов для таких больших объемов данных привело к еще большему увеличению времени обработки, что привело к отказу серверов хранения от обработки входящих запросов. Из за высокой нагрузки на службу управления метаданными, она также перестала отвечать на запросы серверов, не вовлеченных в изначальную проблему деградации сети, которые запросили обновление своих членских данных. Многие из этих серверов хранения также стали недоступны. Недоступные серверы продолжали отправку запросов на обновление сведений, сохраняя тем самым высокую нагрузку на службу управления метаданными. Не смотря на то, что многие запросы обрабатывались корректно, работающие сервера, получившие успешный ответ от службы один раз, получали ошибочный ответ в следующий, становясь вновь недоступными. К 2:37 ночи количество ошибок достигло максимума за последние три года, остановившись примерно на 55%.
Предпринятые шаги. Из-за высокой нагрузки Amazon не мог добавить ресурсов к службе. После нескольких неудачных попыток увеличить мощности в 5:06 утра было решено остановить запросы к службе. Это действие уменьшило активность повторных запросов, составлявших существенную часть нагрузки на службу. После того, как служба смогла отвечать на запросы администраторов, Amazon смог значительно увеличить вычислительные ресурсы и возобновить запросы серверов хранения к службе. В 7:10 утра работа DynamoDB была восстановлена.
Количество ошибок значительно снизилось и составляло теперь 0.15%-0.25%, что считалось приемлемым показателем, хотя и более высоким, чем обычно. В понедельник Amazon начал получать сообщения от пользователей о проблемах с таблицами, застрявшими в режиме обновления или удаления. Проблема заключалась в том, что не смотря на низкий уровень ошибок, отказы был и распределены не равномерно между пользователями и у некоторых из них отказы случались существенно чаще, чем у других. Оказалось, что проблема была вызвана тем, что некоторые из разделов все еще не обрабатывали требуемое количество трафика. Команда администраторов работала осторожно и старательно чтобы восстановить собственные разделы службы управления метаданными и закрыла эту проблему в понедельник.
Для предотвращения подобных проблем в будущем Amazon значительно увеличил вычислительные мощности службы управления метаданными, реализовал более строгий мониторинг производительности служб, уменьшил частоту и увеличил предельное время получения членских данных. Кроме того служба управления метаданными разделяется на сегменты для того, чтобы каждый экземпляр службы обслуживал только свою часть серверов хранения.
Сопутствующие потери
Сбой в системе хранения затронул не только DynamoDB, но и большое число сервисов связанных с ней сервисов. Ниже приведены основные из них.
Simple Queue Service (SQS). На ранних этапах сбоя DynamoDB, SQS работал с повышенным фоном ошибок и с немного большей задержкой. Amazon SQS использует в своей работе DynamoDB для хранения очередей. Когда информация об очереди закэширована в SQS и не доступна напрямую для API непосредственной отправки/приема сообщений, кэш часто обновляется, чтобы корректно отразить операции создания, удаления и изменения, выполняющиеся в инфраструктуре Amazon. Когда DynamoDB перестал блокировать трафик в 05:45 PDT (с тем, чтобы дать возможность сервису метаданных восстановиться), SQS не мог считывать данные из БД, что привело к значительному повышению фона ошибок. Когда в 07:10 PDT трафик стал восстанавливаться, сервис очередей восстановился, данные в очередях в результате инцидента потеряны не были.
После инцидента сервийс SQS был доработан с тем, чтобы он не создавал ошибок даже в случае, когда сервис метаданных неоступен.
EC2 Auto Scaling. Между 02:15 и 07:10 API сервиса отдавала большое число ошибок. С 07:10 до 10:52 в EC2 наблюдались существенные задержки при выполнении нового подключения, либо отключении старого. Уже имевшиеся подключения продолжали работать корректно в течение всего инцидента.
Сервис хранит в DynamoDB информацию о группах и конфигурацих запуска. С момнета начала инцидента EC2 не мог обновлять внутреннюю таблицу данных при вызове его API. Когда DynamoDB было восстановлено, началось восстановление работы сервиса, которое не было закончено из-за накопившихся за время инцидента не обработанных активностей. Запуск и остановка сервиса осуществляется в фоновых процессах. В течение инцидента накопилось большое количество активностей, связанных с вышеупомянутым фоновым планировщиком. Эти процессы обрабатывались до 10:52.
Помимо мероприятий, сделанных командой DynamoDB, заключавшихся в обеспечении быстрого восстановления при образовании большого лога необработанных запросов, Amazon также изменил подход к разделению работ над серверами EC2 (чтобы большее их число можно было выполнять в параллельном режиме), внедрил механизмы удаления старых активностей и увеличил мощность серверов для обработки запоросов.
CloudWatch. Начиная с 02:35 сервис метрик Amazon - CloudWatch, - начал регистрировать задержки, отсутствие метрик EC2, а также возросшее число ошибок. CloudWatch использует внутреннее хранилище для добавления информации о членстве в группе автомасштабирования во все входящие запросы сервиса EC2. С 02:35 до 05:45 ошибки в DynamoDB обуславливали нестабильный доступу к метрикам EC2. CloudWatch также заметил ненормально низкую активность метрик других сервисов, использующих DynamoDB, усугбляя проблему доступа к метрикам.
Далее примерно с 05:51 до 07:10 CloudWatch сообщил о значительно возросшем фоне ошибок вызовов API сервиса PutMetricData, что влияло на все метрики Amazon, а также метрики, созданные пользователями. Ошибки были связаны с доступом к данным о членстве, упомянутым выше. Сервисы CloudWatch восстановились к 07:29.
Для уменьшения влияния DynamoDB на CloudWatch Amazon уменьшил размер пакета до минимально возможного. Также в разработке сервисы быстрой доставки метрик за счет сквозной записи кэшей. Этот кэш должен предоставить возможность получать метрики без их ее сохранения. Кроме того он обеспечит большую защиту данных.
Console. AWS console также работала не стабильно у некоторых пользователей между 05:45 и 07:10. Пользователи, уже зашедшие в консоль оставались подключенными к ней. Те же, кто пытался войти в систему сталкивались с высокими задержками при входе. Это связано было с высокими задержками API, полагавшегося на DynamoDB. Для успешного входа вызов к этому API не обязательно должен пройти без ошибок, но из-за большог таймаута, этот запрос, блокировал процесс входа на десятки секунд.
Таймаут запроса уже был уменьшен и отправлен на тестирование. К сожалению, до начала инцидента новая версия консоли еще не была обновлена на релизе.