Failure as a Service – cбой как услуга по-амазоновски

Недавний 7-часовой сбой в работе платформы Amazon Web Services стал причиной для новых обсуждений о надежности облачных вычислений, а также о том, кто должен нести ответственность за подобные происшествия – провайдеры услуг или их клиенты. Обсуждение возникло после двух сбоев 4 мая и вошло в новую фазу после очередного сбоя в субботу ночью, 8 мая. Все указанные происшествия стали следствием отключения электропитания. В субботу платформа стала недоступна примерно в 0:20 и продолжала находиться в таком состоянии до 7:20. В результате перебоев в электроснабжении, по данным Amazon, была обесточена «группа серверных стоек». В компании заявили, что основную массу американских пользователей в East Availability Zone данный сбой не затронул.

Автор обсуждения, на форуме AWS, пишет: «Они (Amazon) обещают избыточность. Это полная чушь». В частности Amazon утверждает следующее: «EBS-тома разработаны с учетом высокого коэффициента доступности и высокой надежности. Данные Amazon EBS реплицируются на большом количестве серверов в Availability Zone, в результате чего исключается потеря данных при возникновении сбоя в каком-либо одном компоненте. Жизнестойкость вашего тома зависит от двух вещей: его размера и процента данных, которые были изменены с момента совершения последнего снимка данных (snapshot). Например, тома, включающие 20 ГБ или меньший объем измененных данных с момента создания последнего снимка Amazon EBS, вероятнее всего будут иметь годовой уровень отказов (Annual Failure Rate – AFR) в интервале 0,1-0,5% (отказ в данном случае обозначает полную потерю тома). Таким образом, EBS является в 10 раз более надежной системой хранения данных по сравнению с привычным жестким диском, AFR которого составляет около 4%».

Как и множество новых пользователей облачных вычислений, автор заметки предположил, что он просто будет использовать сервис, а в случае возникновения сбоя та самая избыточность AWS автоматически исправит любую проблему. Полагать так вполне резонно, так как провайдер (вроде как) обещает полную сохранность данных. Фактически же Amazon вкладывает в свои слова несколько иной смысл: «Жизнестойкость вашего тома зависит от двух вещей: его размера и процента данных, которые были изменены с момента совершения последнего снимка», что возлагает ответственность за сохранность данных на пользователя. В компании утверждают, что защищают от потери данных. Они действительно это делают, но только если вы пользуетесь AWS корректно, иначе фортуна обойдет вас стороной. На деле большинство пользователей AWS должно самостоятельно учитывать возможность возникновения серьезных сбоев и для защиты от потери данных использовать функцию EBS для создания снимков. Проблема заключается в том, что большинство пользователей узнает об этой обязанности (имеется в виду применение функции EBS для создания снимков) слишком поздно. Поиск информации по планированию сбоев AWS в Интернете практически не выдает полезных результатов.

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

С развитием услуги «инфраструктура как сервис» (Infrastructure as a Service – IaaS) становится очевидно, что "помешанные" на новейших технологиях разработчики, которые взяли на вооружение облачные вычисления раньше других, отнюдь не получают те финансовые преимущества, которые могли бы получить. С целью сделать IaaS доступной для большего числа клиентов компания Amazon и другие провайдеры вынуждены создавать и развивать платформы пока для достаточно малой группы пользователей. То есть работать на этот наименьший общий знаменатель - тех, кто "достаточно умен", чтобы рискнуть.

Самый важный вопрос заключается в том, должен ли пользователь облачных вычислений беспокоиться о возможных аппаратных сбоях, или проблемы данного плана должны решаться исключительно провайдером услуг? Очевидно, что переход к облачным вычислениям должен упрощать работу, а не усложнять ее. Пользователи должны нести ответственность за политики доступа, а Amazon – за сбои, которые возникают в результате работы приложений и сопутствующих компонентов, которые они создают и внедряют, но не работой аппаратного обеспечения. В случае выхода из строя аппаратного обеспечения (что непременно произойдет) ответственным за это должен быть тот, кто его предоставил и обслуживает. Обещая максимальную надежность, высокий коэффициент доступности и избыточность, но на деле предлагая решение, надежное функционирование которого всецело зависит от технической грамотности пользователей, не совсем корректный шаг. Если EBS автоматически реплицирует данные, то возникает вопрос, почему тогда автор сообщения на форуме AWS потерял всю свою информацию? В наиболее благоприятной для работы пользователей облачной среде выход из строя одного любого сервера не должен иметь значения. Но, исходя из примера AWS, это оказывается не так...