Слабое звено облаков

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

В соглашении об уровне обслуживания (SLA) устанавливается вероятная или обещанная доступность конкретного облачного сервиса, а также компенсация, причитающаяся пользователю, если поставщик эту доступность не обеспечивает. Причем для каждого облачного сервиса обычно заключается отдельное SLA.

В качестве примера на рисунке показана облачная архитектура с потоками трафика между виртуальными машинами и виртуальным балансировщиком нагрузки. Балансировщик распределяет трафик между девятью виртуальными машинами. Виртуальные машины используют модель «инфраструктура как услуга» (IaaS), причем ответственность за отказоустойчивость (resiliency) системы виртуальных машин возложена на пользователя. Балансировщик же работает по модели «платформа как услуга» (PaaS), и это означает, что за его отказоустойчивость отвечает поставщик услуг.

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

Итак, провайдер несет ответственность за отказоустойчивость балансировщика нагрузки. Но является ли балансировщик единой точкой отказа (Single Point Of Failure, SPOF), приводящей к неработоспособности всей системы? Это зависит от точки зрения пользователя. Балансировщик не может рассматриваться в качестве SPOF, если пользователь абсолютно уверен в том, что провайдер правильно обеспечил отказоустойчивость, например, путем установки избыточных серверов или через функцию автоматического аварийного переключения. Но если у пользователя есть сомнения, он может рассматривать балансировщик как единую точку отказа, поскольку он управляется провайдером, над которым у пользователя нет всеобъемлющего контроля.

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

Чтобы оценить финансовые последствия такой ситуации, предположим, что каждая виртуальная машина и балансировщик нагрузки обходятся заказчику в $3 в месяц. Например, в SLA облачного сервиса Microsoft Azure предусмотрена компенсация в размере 10% ежемесячной стоимости балансировщика, если не обеспечивается его доступность в течение от 99,9–99,99% времени в месяц. Аналогичные условия предусмотрены и для виртуальных машин.

Если балансировщик нагрузки не работает в течение, скажем, 43 мин, то Microsoft Azure обязан выплачивать 10% его ежемесячной стоимости, что в нашем случае составляет $0,30. Провайдер не обязан платить за виртуальные машины, так как они продолжают работать, несмотря на то, что приложение перестает отвечать. Общая ежемесячная стоимость приложения составляет $30, а плата за недоступность балансировщика $0,30, т.е. компенсация за его отключение составляет 1% ежемесячной платы поставщику услуг – ничтожная сумма по сравнению с вероятными последствиями такого отключения.

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

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!