Реальный опыт использования облачного хостинга

Евгений Потапов (Сумма АйТи)

Увертюра• Опыт перехода на облачный хостинг сайта

makemebabies.com• 50-100 тысяч уникальных посетителей в сутки

(зависит от магнитных бурь )• 300-900 тысяч хитов в сутки• Linux/nginx/PHP/MySQL – front-end/API• Windows/IIS/PHP – back-end

Disclaimer/Основные понятия• Речь идет об Amazon-подобных облачных

решениях• Речь идет не обо всех хостингах – мы пробовали

Amazon, но используем другой хостинг• Наш опыт – не истина в последней инстанции

makemebabies.com

1. Заходим на сайт

makemebabies.com

2. Загружаем фотографию

makemebabies.com

3. Получаем ребенка

Как это работало, версия 1.0

Роддом

Проблемы1. Простой ресурсов

• Dedicated-серверы арендуются помесячно• В пиковые часы число запросов на детей в 3 раза

больше, чем в остальное времяПриходится содержать парк dedicated-серверов выдерживающий максимум и платить за это

Простой ресурсов

На графике – число успешных запросов на рождение детей в минутупериод – 2 дня

Пиковая нагрузка

На графике – пятикратный рост посещаемостиdedicated-сервер не справляется

Проблемы2. Reliability

• Если посетители сайта могут «подождать», то API-клиенты требуют надежность 24/7

• Согласно SLA хостинга время восстановления работы после аппаратной ошибки – 4 часаПриходится либо признать возможность «даунтайма» в 4 часа либо держать заказанным резервное оборудование

Проблемы3. Масштабирование

• API-клиенты проводят рекламные кампании, в периоды которых нагрузка на API-процессинг может расти в 5-10 раз

• При этом dedicated-сервера арендуются минимум на месяцПриходится держать большой парк API-серверов чтобы не допустить общего падения

Облака?• Сможем купить сто тысяч инстансов днем и жить с

одним ночью?• Сможем заменять «оборудование» за 10 минут?• Сможем быстро закупить дополнительные ресурсы

для API-клиентов в период кампаний?

Вычисления, ночь

Вычисления, день

API, все спокойно

API, пик запросов от клиентов

Переход

Просто взять и перейти?

Переход

Просто взять и перейти? Не получится!

Переход, вычисления1. Отвязываемся от статических

зависимостей:– Убираем жесткие связи с Windows-серверами из

конфигурации приложения– Убираем связь через SMB-mount-ы– Изолируем весь процесс взаимодействия

Переход, вычисления1. Мониторинг

– Контролируем число запросов в течении времени– Создаем систему реагирования на изменение

нагрузок– Учитываем бизнес-логику (30 минут перегрузок для

посетителей сайта – не критично, 30 минут перегрузок для API-клиентов – море писем с недовольствами)

Переход, вычисления1. Интегрируем облачное API

– Удаляем и добавляем инстансы в течении дня, в зависимости от времени суток

– Добавляем инстансы при росте нагрузок и удаляем -при спаде

– Создаем панель управления всей системой

Переход, вычисления1. Организуем обновление кода и

конфигурации– 20 инстансов сложно обновить руками – ставим SVN/

используем rsync/пишем систему сами– Создаем шаблонный образ инстанса– Создаем панель управления обновлениями

конфигураций и кода

Переход, API1. Отвязываемся от статических

зависимостей:Round-robin балансировка направляет каждый запрос случайным образом. Один единственный инстанс не может сохранить состояние пользователя сам, пользователь может там больше не оказаться (это верно для любой front-end системы в облаках)

Переход, API1. Отвязываемся от статических

зависимостей:– «Забываем» о локальных состояниях– Выносим общие данные на отдельный,

единственный инстанс (SPOF!!!)

Переход, API1. Организуем балансировку

– Nginx/Upstream Module? IP_HASH не надежен (AOL меняет подсети)

– Внешний DNS с низким TTL (обычно – очень дорого)– Средства хостера (NetScaler, Amazon Load Balancer,

и т.д.)

Переход, API1. Организуем обновление кода и

конфигурации– 20 инстансов сложно обновить руками – ставим SVN/

используем rsync/пишем систему сами– Создаем шаблонный образ инстанса– Создаем панель управления обновлениями

конфигураций и кода

Поехали?

Запуск

Правда жизни:Чудес не бывает

Запуск, сложности1. Человеческий фактор

What are the causes of faults?– Software bugs– Out of date or incorrect configurations– Landslides– Disk failures, broken fans– Assembly problems– ...

«That Couldn't Happen To Us... Could It?», Google,http://excession.spiral-arm.org/jay/talks/Google-SRE/ThatCouldntHappenToUs.pd

f

Запуск, сложности1. Человеческий фактор - проблемы

– Ошибки приложения и конфигурации– Ошибки оценки – реальная нагрузка не

соответствует тестам, созданных инстансов не хватает

– Ошибки обновления конфигурации – конфигурация/код приложения обновляется не на всех инстансах (NB – Очень сложно отследить!)

Запуск, сложности1. Человеческий фактор - решения

– В первое время - всегда должна быть возможность быстро вернуться на старую архитектуру

– Версионирование необходимо – нужно иметь возможность «откатить» последнюю внедренную версию

– Необходимо контролировать «бизнес-логику» - основные показатели поведения пользователей, конверсию – и т.д.

Запуск, сложности1. Облака – ограниченные возможности

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

Запуск, сложности1. Облака – ограниченные возможности - проблемы

– На одном аппаратном обеспечении находится множество инстансов – проблемы аппаратного обеспечения – проблемы всех этих инстансов

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

– Из-за проблем с разделением ресурсов существуют большие скачки в производительности доступа к дискам – хостеры не рекомендуют размещать «жадные до I/O» приложения

Запуск, сложности1. Облака – ограниченные возможности - решения

– Во время разработки – замеряем возможности хостинга – CPU performance, Disk I/O performance и т.д

– …И продолжаем это делать в процессе использования– Если мы активно используем I/O и нам обязательно надо

«в облака» - ищем решение которое нам будет соответствовать (Amazon: I/O performance moderate/high)

Запуск, сложности1. Особенности конкретного хостинга

Предлагаемые хостингами облачные решения часто – не стабильны! Практически все показатели время от времени отличаются от «идеальных»

Запуск, сложности1. Особенности конкретного хостинга

– Время создания инстансов постоянно варьируетсяВ среднем оно составляет от 10 до 60 минут.Моментально среагировать на пиковую загрузку не получится никогда!

Запуск, сложности1. Особенности конкретного хостинга

– XEN-based инстансы неадекватно реагируют на пиковую дисковую нагрузкуВ случае, если приложение на протяжении долгого времени использовало hdd на пределе возможностей фатально долгий iowait будет сохранятся еще около 10 минут

Запуск, сложности1. Особенности конкретного хостинга

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

Запуск, сложности1. Особенности конкретного хостинга -

решения– Мониторинг

Запуск, сложности1. Особенности конкретного хостинга -

решения– Мониторинг– …Мониторинг

Запуск, сложности1. Особенности конкретного хостинга -

решения– Мониторинг– …Мониторинг– ……Оповещения от мониторинга (недоступность

инстанса, высокий Load Average, долгий iowait и т.д.)

Запуск, сложности1. Особенности конкретного хостинга –

частота «проблем»1. Проблемы с дисковой производительностью2. Недоступность инстансов3. Падения CPU-производительности

Запуск, сложности1. Особенности конкретного хостинга –

решенияВ случае если работоспособность 24/7 критически важна – всегда должен быть доступен человек, который может моментально среагировать на оповщения от мониторинга

Запуск, итоги• Процесс перехода – 6 месяцев• Проблемы на запуске – 2 месяца• «Стабильная» работа – 3 месяца….

… и дальше?

Запуск, итоги• Экономия на аренде? Нет (и в разы дороже!) – на запуске, да

– в стабильном режиме.• С начала стабильной работы – сокращение (отсутствие?)

жалоб на производительность и доступность API• Три резких пика посещаемости за последние два месяца

остались практически не замеченными с точки зрения проблем.

• Появилась возможность сделать «запас» ресурсов на выходные и праздники (когда реагировать быстро не хочется)

Что дальше?• Очень хочется уйти от «инстансов» к

собственно вычислениям – AppEngine/Azure• Автоматическое масштабирование ресурсов?• Стабильность!!!

Спасибо за внимание!• E-mail: eapotapov@gmail.com• Jabber: eapotapov@gmail.com• Skype: eugene.potapov.irkutsk• http://www.itsumma.ru

Вопросы?