Масштабирование инфраструктуры высокой доступности в облаке

Доступность — это время, в течение которого устройство фактически работает, выраженное в процентах от общего времени, которое оно должно работать. Это общее *время безотказной работы*, деленное на общее *время безотказной работы + время простоя*. «Пять девяток» или 99,999% — распространенная цель в средах, критически важных для доступности. 99,999% доступности соответствуют 5,26 минутам простоя в год или 25,9 секундам простоя в месяц.

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

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

Сохранение данных — самая сложная техническая проблема, с которой сталкивается большинство масштабируемых SaaS-бизнесов.

Недавно мы выступили с докладом на Web 2.0 Expo в Нью-Йорке, который исследует коренные причины времени простоя и архитектурные решения, которые мы приняли в Twilio для обработки компонентов с состоянием, чтобы обеспечить высокую доступность.

Ключевые моменты доклада:

— Проблемы с сохранением данных и ошибки контроля изменений — две ключевые причины времени простоя

— Сохранение данных — это сложно

— Сложно изменять схему или структуру из-за необходимости переписывать данные и индексы

— Сложно восстанавливаться после сбоев из-за сложных ситуаций «разделения мозга» и времени, необходимого для восстановления состояния с другого узла или резервной копии

— Сложно масштабироваться из-за низкой производительности ввода-вывода — медленная пропускная способность ввода-вывода и задержка в облаке по сравнению с аппаратным обеспечением,

— и сложно управлять из-за невероятной сложности современных систем управления данными.

— При создании облачных приложений с высокой доступностью следует учитывать:

— четкое разграничение компонентов с состоянием и без состояния в вашей инфраструктуре

— избегание хранения данных, когда это возможно

— использование неструктурированного хранилища вместо структурированного, когда это возможно

— агрессивное архивирование или удаление данных, которые не должны находиться в режиме онлайн

— определение четких процессов, опосредованных человеком, для контроля изменений

— и прагматичный выбор технологии хранения данных для конкретной задачи — SQL лучше всего подходит для определенных задач, в то время как хранилище типа «ключ-значение» или облачное хранилище, такое как S3, лучше для других.