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

Реальный опыт использования облачного хостинга Евгений Потапов (Сумма Ай. Ти)

Увертюра • Опыт перехода на облачный хостинг сайта makemebabies. com • 50 -100 тысяч уникальных посетителей в сутки (зависит от магнитных бурь ) • 300 -900 тысяч хитов в сутки • Linux/nginx/PHP/My. SQL – 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-ы Изолируем весь процесс взаимодействия

Переход, вычисления 2. Мониторинг – – – Контролируем число запросов в течении времени Создаем систему реагирования на изменение нагрузок Учитываем бизнес-логику (30 минут перегрузок для посетителей сайта – не критично, 30 минут перегрузок для API-клиентов – море писем с недовольствами)

Переход, вычисления 3. Интегрируем облачное API – – – Удаляем и добавляем инстансы в течении дня, в зависимости от времени суток Добавляем инстансы при росте нагрузок и удаляем при спаде Создаем панель управления всей системой

Переход, вычисления 4. Организуем обновление кода и конфигурации – – – 20 инстансов сложно обновить руками – ставим SVN/используем rsync/пишем систему сами Создаем шаблонный образ инстанса Создаем панель управления обновлениями конфигураций и кода

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

Переход, API 1. Отвязываемся от статических зависимостей: – – «Забываем» о локальных состояниях Выносим общие данные на отдельный, единственный инстанс (SPOF!!!)

Переход, API 2. Организуем балансировку – – – Nginx/Upstream Module? IP_HASH не надежен (AOL меняет подсети) Внешний DNS с низким TTL (обычно – очень дорого) Средства хостера (Net. Scaler, Amazon Load Balancer, и т. д. )

Переход, API 3. Организуем обновление кода и конфигурации – – – 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/That. Couldnt. Happen. To. Us. pdf

Запуск, сложности 1. Человеческий фактор - проблемы – – – Ошибки приложения и конфигурации Ошибки оценки – реальная нагрузка не соответствует тестам, созданных инстансов не хватает Ошибки обновления конфигурации – конфигурация/код приложения обновляется не на всех инстансах (NB – Очень сложно отследить!)

Запуск, сложности 1. Человеческий фактор - решения – – – В первое время - всегда должна быть возможность быстро вернуться на старую архитектуру Версионирование необходимо – нужно иметь возможность «откатить» последнюю внедренную версию Необходимо контролировать «бизнес-логику» - основные показатели поведения пользователей, конверсию – и т. д.

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

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

Запуск, сложности 2. Облака – ограниченные возможности - решения – – – Во время разработки – замеряем возможности хостинга – CPU performance, Disk I/O performance и т. д …И продолжаем это делать в процессе использования Если мы активно используем I/O и нам обязательно надо «в облака» - ищем решение которое нам будет соответствовать (Amazon: I/O performance moderate/high)

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

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

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

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

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

Запуск, сложности 3. Особенности конкретного хостинга решения – – Мониторинг …Мониторинг

Запуск, сложности 3. Особенности конкретного хостинга решения – – – Мониторинг ……Оповещения от мониторинга (недоступность инстанса, высокий Load Average, долгий iowait и т. д. )

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

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

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

Запуск, итоги • • Экономия на аренде? Нет (и в разы дороже!) – на запуске, да – в стабильном режиме. С начала стабильной работы – сокращение (отсутствие? ) жалоб на производительность и доступность API Три резких пика посещаемости за последние два месяца остались практически не замеченными с точки зрения проблем. Появилась возможность сделать «запас» ресурсов на выходные и праздники (когда реагировать быстро не хочется)

Что дальше? • • • Очень хочется уйти от «инстансов» к собственно вычислениям – App. Engine/Azure Автоматическое масштабирование ресурсов? Стабильность!!!

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