Совсем недавно из-за проблем с сервисом Amazon S3 случился настоящий «облакалипсис». Сбой в работе стал причиной падения большого количества сайтов и сервисов тех компаний, кто является клиентом Amazon. Проблемы начались вечером 28 февраля, о чем можно было узнать из социальных сетей. Затем стали массово появляться сообщения о неработающих Quora, IFTTT, рассылок Sailthru, Business Insider, Giphy, Medium, Slack, Courser и т.п.

Сбоили не только сервисы и сайты, многие IoT устройства оказалось невозможно контролировать через интернет (в частности, из-за неработающего IFTTT). Самое интересное то, что до последнего момента статус Amazon S3 показывался, как нормальный. Но многие сотни, а то и тысячи компаний, чьи ресурсы были затронуты проблемой, осознали, что рано или поздно даже очень надежное «облако» может рухнуть, накрыв всех своими обломками. Можно ли что-то сделать в такой ситуации?

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

Способы, позволяющие избежать проблем со своими серверами в том случае, если облако, в котором они работают, падает, сильно отличаются от методов, используемых дата-центрами для повышения аптайма и «стрессоустойчивости» (например, дублирование различных систем). Для защиты своих сервисов и удаленных данных можно использовать копии, размещенные на виртуальных машинах в дата-центрах из различных регионов, а также использовать базу данных, которая охватывает несколько ЦОД.

Этот способ можно использовать и в рамках работы с одним провайдером, но более надежно использовать и услуги других облачных компаний, включая Microsoft Azure или Google Cloud Platform в дополнение к тому же AWS. Понятно, что это дороже, но здесь, как и в обычном случае, стоит подумать над тем, стоит ли овчинка выделки. Если да, например, сервис или сайт должен работать постоянно, то можно предпринять такие методы предосторожности. «Мультоблачная» архитектура, вот как это можно назвать.

Во многих случаях можно обезопасить себя, воспользовавшись услугами CDN провайдера вроде Cloudflare (кстати, вскоре мы открываем собственный CDN), сохраняющего копии важных данных, которые хранятся у других компаний.

После падения Amazon S3 те клиенты AWS, кто работал с Cloudflare, почти не испытывали проблем.



Напомним, что все начиналось с S3 в 2006 году. Первый публичный сервис, который Amazon запустил — именно облачное файловое хранилище. Виртуалки (EC2) появились заметно позже.

Вот еще один скриншот клиента Амазона — Российской ИТ компании. У них не работало 45 сервисов:



Данные можно хранить в грузовиках (тоже от Amazon), но и это не всегда является выходом

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

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

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

Еще один тренд, связанный с предыдущими — это появление все большего числа инструментов контейнерной оркестровки, вроде Docker, Kubernetes, и DC/OS от Mesosphere. Их тоже стоит опробовать в работе, с ними принцип мультиоблачной инфраструктуры организовать гораздо проще, чем в обычном случае.

Человеческий фактор

Это, как всегда, основная проблема. Именно человек стал причиной падения серверов Amazon, о чем компания призналась на своем сайте. Команда инженеров работала над отладкой системы биллинга, для чего ряд серверов нужно было перевести в автономный режим. Из-за опечатки в такой режим перевели гораздо больше серверов, чем требовалось изначально.



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

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