Evgeniy Potapov Root Conf потапов

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

Увертюра
Опыт перехода на облачный хостинг сайта 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 , пик запросов от клиентов

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

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

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

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

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

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

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

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

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

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

Поехали?

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

Запуск, сложности
Человеческий фактор
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

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

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

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

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

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

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

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

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

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

Особенности конкретного хостинга - решения

… Мониторинг

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

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

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

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

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

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

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

http://ritconf.ru	135
http://www.ritconf.ru	16
http://new.profyclub.ru	10
http://profyclub.ontico.ru	6
http://2011.ritconf.ru	2
http://www.slideshare.net	1
http://ritconf.ontico.ru	1

Evgeniy Potapov Root Conf потапов

by rit2010 on Apr 11, 2010

Accessibility

Upload Details

Usage Rights

7 Embeds 171

Statistics

Evgeniy Potapov Root Conf потапов — Presentation Transcript