1. Как жить в облаке без админов?
Александр Демидов
руководитель направления арендных решений
«1С-Битрикс»

2. Никак…

3. До 2012 года…
Два основных продукта:
Единственное, что
требовало того или
иного обслуживания –
наш собственный сайт.

4. В настоящее время…
CRM CDN
бэкапфайлы
сканер
безопасности
??
видеозвонки push

5. Облачные сервисы
Битрикс24 – SaaS «Корпоративный портал»
Более 7000 наиболее активных порталов
Ускорение сайта – интеграция с CDN
Около 9000 сайтов
Облачный бэкап
Более 7500 сайтов
Анонс новых сервисов осенью 2013

6. Примерно 2 стойки
42U – если без
виртуализации
Два человека – у
которых админство
не является
основной
деятельностью

7. Разные классы сайтов и веб-
сервисов:
Домашние странички, личные блоги и т.п.
«Продающие» сайты (интернет-магазины)
Имиджевые сайты (в том числе и
корпоративные)
«Business critical application» - веб-
сервисы, использующиеся в работе (CRM,
учет, таск-менеджмент, почта и т.п.)
Разные стадии проекта:
Инвестиции, развитие
Выход на операционную прибыль
Что ожидаем от проекта?

8. Облако!
Быстро, качественно (надежно), дешево!
Marketing bullshit
Выберите любые два пункта…

9. Не дешевле?
В прямом сравнении железа и аналогичного по
конфигурации облака – облако почти всегда проигрывает
Почти всегда отдельно рассчитывается стоимость траффика
Сложность расчетов при оплате «по потреблению»
При оплате «по потреблению» при резком росте нагрузки
(DDoS, «хабраэффект», ошибки в разработке) возможны
значительные расходы (в разы больше запланированных)

10. Как минимум – не надежнее…

11. Надежность?
Виртуальные машины ребутятся чаще
физического «железа».
Amazon AWS – как минимум:
апрель 2011, август 2011, июнь 2012,
декабрь 2012…
«Лежали» Foursquare, Instagram, Netflix,
Pinterest…

12. Масштабирование в облаке?
Без готовности приложения к
масштабированию – не имеет
практического смысла
Есть выделенные ресурсы – RAM,
CPU, HDD: попросил-выделил-
заплатил
Есть разделяемые ресурсы – кэш
процессора, IOPS... Почти ни у
одного облака нельзя попросить
обеспечить N IOPS в течение K
минут. Можно только
понадеяться.

13. Инфраструктура: «Железо» vs. «Облако»
- Медленные диски
- Нельзя гарантированно получить
некоторые ресурсы
- Ложное ощущение гарантий
безопасности и
отказоустойчивости
+ CPU и RAM – по требованию
+ Возможность построить
масштабируемую инфраструктуру
+ Возможность построить
отказоустойчивую
инфраструктуру

14. Инфраструктура: «Железо» vs. «Облако»
- Затраты (время) на обучение
сотрудников специфике
конкретного сервиса
- Ограничения инфраструктуры
(аппаратная часть, специфичное
ПО)
- Сложность расчетов «по
потреблению»
+ Экономия за счет возможности
планирования ресурсов
+ Экономия и отсутствие рисков,
связанные с вложениями в
инфраструктуру
+ Моментальное вертикальное и
горизонтальное
масштабирование
+ Удобство администрирования
+ Экономия времени
+ Дополнительные сервисы

15. Правильное облако

16. Правильное облако
Несколько территориально распределенных ДЦ (с
возможностью их выбора)
Гибкое управление дисками
Облачные базы данных, кэш, NoSQL, балансировщики,
DNS, мониторинг, сервисы очередей, файловые
хранилища, CDN и т.д.
API и готовые SDK для управления всеми сервисами

17. Модульность приложения

18. И его готовность к масштабированию

19. Админы пока еще не нужны…
Нужен аналитик…

20. Админы пока еще не нужны…
…и архитектор.

21. Elastic Load Balancing
Web 1
Elastic Load Balancing
Dynamic
HTTPS
*.com/*.de
Web N
…
CloudWatch
+
AutoScaling
Web 1 Web 2 Web N
…
CloudWatch
+
AutoScaling
Резервируй это!
S3
management,
monitoring,
backup
Static
HTTPS
*.com/*.de
CDN (Amazon CloudFront)
js, css
Dynamic
HTTPS
*.ru
Static
HTTPS
*.ru
CDN (CDNvideo)
js, css
images(clients)
images(clients)
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
control cache: memcached
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
master-master replication
master-master replication
master-master replication
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
control cache: memcached
control cache: memcached
control cache: memcached
control cache: memcached
Web 2
local
cache
(APC)

22. Real Time мониторинг – как
узнавать о проблемах?
Можно – так…

23. Real Time мониторинг – как
узнавать о проблемах?
Или – так…

24. Организация системы
мониторинга
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Мониторить систему мониторинга.
Автоматизация типовых реакций.

25. Автоматизация типовых
реакций
Рост / падение LA – автоматическое масштабирование
вверх / вниз
Автоматический рестарт «сбойных» сервисов
Автоматическое «удаление» проблемных машин
Автоматическое восстановление репликации
Автоматическое переключение траффика в случае аварии
на уровне целого ДЦ

26. Мониторинг веб-приложения
Лог работы скрипта (>) – обновился за N часов
Лог ошибок работы скрипта (2>) – должен быть пуст

27. Мониторинг нетипичных
характеристик
Наличие бэкапов
Срок делегирования доменов
Срок действия SSL сертификатов
Баланс у провайдера смс-уведомлений

28. Аналитика
Видим, что было
Предвидим, что будет
Улавливаем тренды
Планируем мощности железа
Сравниваем настройки софта
Веб-система перестает быть черным ящиком, видно ее
развитие с течением времени

29. Аналитика

30. Аналитика – со стороны
пользователя
Гистограммы распределения времени хитов, памяти,
кодам ответа и т.п. – из логов (awk-скрипт), pinba или
других инструментов
Мало знать «среднюю температуру по больнице» и
мониторить только главную страницу сайта

31. Поиск узких мест
Pinba, XDebug, XHProf

32. Приложение всегда работает
в условиях ограниченных ресурсов
Постоянный feedback разработчикам – в
автоматическом и полуавтоматическом режиме

33. Резюме
Систему в облаке можно поддерживать, обходясь
минимумом человеческих ресурсов
• Выбирайте правильное облако – с максимально широким
набором сервисов, API и т.п.
• Ваше приложение должно быть готово к горизонтальному
масштабированию
• Резервируйте все
• Обязательно используйте системы мониторинга
• Автоматизируйте все типовые действия
• Держите приложение в условиях ограниченных ресурсов и
всегда давайте обратную связь разработчикам.

34. Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
+7-926-521-3700
@demidov
http://www.1c-bitrix.ru