Уроки отключения Amazon S3

28 февраля запомнится глобальным ИТ-предприятиям как грубая проверка реальностью. Причина — служба Simple Storage Service (S3) Amazon Web Service не работала почти четыре часа. Облачный аналитик Forrester Research Дэйв Бартолетти классно сравнил AWS S3 с «воздухом» в «облачном» контексте; вот какой он большой. Время простоя затронуло тысячи веб-сайтов, как в количественном, так и в неизмеримом выражении.

Как это случилось?

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

После перезапуска этим серверам потребовалось больше времени, чем предполагалось, и они не смогли обслуживать несколько регионов с расчетной мощностью. Вот так обычный день в офисе для службы поддержки S3 вскоре превратился в катастрофу года. И нет, это было не потому, что «Янки» выиграли Мировую серию, имея больше всего денег, или «Патриоты» обманули свой путь к еще одному Суперкубку, это что-то совершенно другое!

Влияние

Больше всего от этого сбоя S3 пострадали интернет-магазины. Это связано с тем, что их веб-сайты страдали от серьезных проблем с производительностью: время загрузки страниц увеличилось в 10 раз по сравнению с нормальными значениями. По оценкам, в контексте электронной коммерции более трети покупателей переключатся на веб-сайты, если загрузка веб-страницы занимает даже 10 секунд. Примерно столько времени потребуется ЛаВару Боллу, чтобы сделать еще одно нелепое заявление!

У наиболее пострадавших ритейлеров время загрузки страницы составляло 50 секунд и выше, а во многих случаях даже 80 секунд. Для электронной коммерции снижение скорости загрузки страниц эквивалентно потере потенциальных клиентов, а отключение S3 затронуло более 20 из 100 крупнейших интернет-магазинов.

Уроки для предприятий

В то время как сбой S3 означал серьезные потери в долларах для ведущих веб-сайтов электронной коммерции, он также преподнес несколько тяжелых уроков. Вот основные выводы для лиц, принимающих решения в области ИТ.

Единый облачный поставщик: плохая идея

Во время сбоя S3 несколько интернет-магазинов справились отлично, потому что они сохранили только частичные данные в облаке Amazon и, следовательно, смогли пройти шторм с минимальным ущербом или без него. Были и другие розничные продавцы, которым удалось визуализировать изображения, используя данные, хранящиеся на облачных платформах других поставщиков, что обеспечило непрерывность бизнеса, несмотря на время простоя S3.

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

Инновационные методы аварийного восстановления

Наличие надежного плана на случай непредвиденных обстоятельств на случай, если сторонний облачный провайдер потерпит неудачу, просто дальновидно. Стратегия децентрализованного облака с упором на аварийное восстановление — это путь вперед для предприятий. Резервное копирование данных в облаке на самом деле не так сложно, как кажется. Это необходимость. Что-то вроде отказа от еды в Wal-Mart McDonald's, если вы не хотите, чтобы вас ограбили холодным гамбургером, который должен быть горячим!

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

Проактивное тестирование устойчивости

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

Netflix даже использует Chaos Gorilla и Chaos Monkey (инструменты с открытым исходным кодом), чтобы автоматически отключать внутренние системы, чтобы проводить тесты устойчивости систем в реальном времени. Стоит ли удивляться, что Netflix не сообщал о каких-либо серьезных проблемах во время отключения S3?

Идентификация сбоев в режиме реального времени и автоматические ответы

Знание того, что ваше предприятие быстро справляется с отказом облачной системы, может помочь уменьшить влияние простоя. Это может быть достигнуто двухэтапным способом. Первый этап — это анализ нормального поведения систем, а второй этап — сравнение значений в реальном времени с идеальными значениями и подача сигналов тревоги на основе отклонений и допусков. В качестве ответов на эти ситуации можно настроить большое количество системных реакций.

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

Системы построения с резервированием

Избыточность помогает предприятиям быстро и с минимальным вмешательством человека преодолевать разрушительные последствия сбоя облачной платформы. Для создания избыточности в ваших корпоративных облачных системах «резервный» подход представляется надежным методом.

Благодаря резервному резервированию приложения автоматически обнаруживают отключение или нехватку ресурсов от основного сервера и в таких случаях автоматически переключаются на резервные и резервные системы. В идеале системы резервного копирования должны оставаться выключенными, если только не возникнет необходимость переключения. Альтернативная стратегия заключается в том, чтобы системы резервного копирования всегда работали в фоновом режиме, чтобы время переключения было минимальным. Конечно, последний вариант дороже.

Ограничением варианта «резервный» является время между обнаружением ошибки и переключением на резервную систему. Решением является активная избыточность, при которой приложения распределяются по нескольким резервным системам. При таком подходе рабочая нагрузка распределяется по нескольким ресурсам, и в случае сбоя одного из них другие ресурсы начинают обрабатывать увеличенные рабочие нагрузки с почти нулевым временем переключения.

Уроки выучены

Всем, кто влюблен в панику, охватившую из-за сбоя S3, и всем, кто не может не сказать, что «облако мертво», мы говорим — живите! S3 поддерживает облачную инфраструктуру уже много лет, и этот единственный случай простоя — это то, что снизит вероятность повторения события. На самом деле у вас больше шансов увидеть фантастический фильм о Росомахе, что, по-видимому, является довольно редким явлением. Но это лучше, чем «Звездные войны»!

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