В ЦЕЛОМ ОТ ЧЕТЫРЕХДНЕВНОГО сбоя Amazon Web Services, произошедшего в апреле прошлого года, пострадали около 13% узлов EBS в регионе, в результате чего 0,07% данных было безвозвратно утеряно
В ЦЕЛОМ ОТ ЧЕТЫРЕХДНЕВНОГО сбоя Amazon Web Services, произошедшего в апреле прошлого года, пострадали около 13% узлов EBS в регионе, в результате чего 0,07% данных было безвозвратно утеряно

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

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

«Некоторые справились с апрельским сбоем благодаря прикрытым тылам, но по остальным он ударил очень сильно, — утверждает Хендрик. — Конечно, из этого инцидента многие могут извлечь уроки, но вопрос в том, готовы ли заказчики в полной мере выполнить тот объем работ, который действительно позволит им защититься».

Напомним вкратце, что произошло в прошлом году. Через несколько недель после сбоя AWS компания опубликовала послеаварийный отчет, в котором описывались причина происшедшего и контрмеры, принятые оператором. По сути, цепную реакцию событий запустила ошибка человека. В предрассветные часы 21 апреля 2011 года при попытке обновить в регионе Восточного побережья сервис Elastic Block Storage — среды хранения, связанной с сервисом Elastic Compute Cloud, часть сети EBS переключилась на инфраструктуру с меньшей мощностью, которая не была готова принять на себя весь трафик сервиса. Его узлы попытались устранить проблему, но образовался сетевой затор, который вскоре передался на другой элемент AWS, Relational Database Service, применяемый для хранения журналов операций. В целом от четырехдневного сбоя пострадали около 13% узлов EBS в регионе, в результате чего 0,07% данных было безвозвратно утеряно.

Утверждается, что операторы AWS с тех пор доработали систему, но неизвестно, насколько масштабными были эти изменения. Например, в послеаварийном отчете говорится, что была проведена аудиторская проверка процесса внесения изменений и повышен уровень использования средств автоматизации при выполнении обновлений в целях исключения ошибки оператора. Аналитик Gartner Дру Ривз утверждает, что компания повысила мощность основной и вспомогательной сетей EBS, сделав сервис более отказоустойчивым: «Они приняли ряд корректирующих мер, чтобы подобное больше не происходило, однако это не значит, что теперь заказчики застрахованы».

В Amazon утверждают, что приняты меры, чтобы проблемы в одних сервисах не перекидывались на другие. Утверждается также, что заказчикам теперь стало проще создавать отказоустойчивые системы с использованием сервисов AWS. Однако, по мнению Ривза, учитывая скрытность компании по поводу архитектуры ее облачных систем, о их возможных уязвимостях судить трудно.

В AWS пообещали в будущем в случае возникновения перебоев действовать более решительно. В прошлом году только через несколько часов после начала отключения в компании объявили, что произошел «сетевой инцидент». Это вызвало гнев многих заказчиков, которые хотели знать, что именно случилось и когда сервисы вернутся в строй. Представитель AWS утверждает, что подробности о масштабе проведенных изменений содержатся в послеаварийном отчете: «Это исправления в программном обеспечении, а также новые особенности, в том числе EC2 Instance Status Monitoring и EBS Volume Status, предоставляющие заказчикам всю информацию, которая им нужна, чтобы выяснить состояние своих ресурсов, работающих в AWS».

В компании также активно пропагандируют меры, которые сами заказчики могут принять, чтобы защититься от сбоев. Главная из них — использование зон готовности. AWS предлагает заказчикам возможность хранения данных в восьми регионах мира, один из которых — Восточное побережье США — стал эпицентром прошлогодней катастрофы. Внутри каждого региона также имеются физически отделенные друг от друга зоны готовности — независимые инфраструктуры, призванные обеспечить высокую готовность данных. Как бы вежливо говоря «мы ведь вас предупреждали», AWS ясно дает понять в послеаварийном отчете, что заказчики, создавшие резервные копии данных в нескольких зонах, пострадали от сбоя меньше. Например, среди абонентов Amazon Relational Database Service, пользовавшихся только одной зоной, пострадали 45%, а среди тех, кто применял несколько зон, — всего 2,5%. За прошедший год компания также опубликовала серию технических докладов и провела ряд веб-семинаров, обучающих заказчиков планировать архитектуру систем, распределенных по нескольким зонам готовности.

Каждому заказчику нужно самостоятельно выполнить оценку рисков, чтобы определить, сколько следует вложить денег для обеспечения достаточной готовности сервисов, полагает Хендрик. По его оценкам, наличие копий данных в нескольких зонах готовности может означать увеличение расходов на пользование облаком AWS на 50%. «Не знаю, в скольких предприятиях реально оценивают свои потребности в высокой готовности, — говорит аналитик. — Эмпирическое правило: чем более критически важны приложения и данные, хранимые в облаке, тем больше заказчику следует уделять внимания архитектурным мерам повышения готовности. Для некоторых заказчиков одного только мультизонного подхода будет недостаточно».

«Мы всегда храним данные в нескольких зонах, чтобы избежать перебоев, — утверждает Джереми Эдберг, старший разработчик продуктов Reddit. — Причина отказа сервиса AWS была в том, что сбой произошел сразу в нескольких зонах».

Для дополнительной защиты от сбоев в экосистеме AWS можно также хранить данные в нескольких регионах, напоминает Ривз. Это будет немного сложнее, так как AWS предоставляет одни и те же API для работы с разными зонами в пределах одного региона, но для работы с разными регионами понадобятся различные API. Со времени прошлогоднего сбоя мультирегиональным методом пользуются в компании Quora, которая предлагает социальный сервис «вопрос-ответ». На сайте Quora указано, что в компании применяют «стратегию межрегионального тиражирования базы данных».

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

Тем не менее риски и перебои будут всегда, и в определенном смысле, по мнению Ривза, это даже хорошо, так как аварии заставляют провайдеров и конечных пользователей двигаться вперед: «Мне каждется, сбои, скорее дают толчки к развитию облаков, чем задерживают его. Если и заказчики, и провайдеры будут учиться на допущенных ошибках, делая системы более безопасными и защищенными, это принесет пользу индустрии в целом».