Александр Демидов, директор направления облачных сервисов Битрикс24

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

2. Запуск нового продукта: как, где, какие условия?
Почему «облако»? И почему именно AWS?
Как соблюдать 242-ФЗ, раз у Амазона ДЦ в России нет?
Что из сервисов Амазона в итоге делали сами?
Как всё мониторить?
Как организовать коммуникации между разработчиками, тестировщиками,
админами?

3. как все начиналось…

4. «Битрикс24»
Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи
Минимизация расходов на эксплуатацию и снижение финансовых рисков на
старте проекта
Масштабирование при росте нагрузки и обратное масштабирование
Надежность – обеспечение SLA
Работа с разными рынками: США, Европа, Россия
Есть несколько задач на старте и в процессе работы

5. Выбор платформы для разворачивания инфраструктуры
Минусы размещения на собственном оборудовании:
«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить,
покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров –
таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы.
Оглядываясь назад, я думаю, что это было большой ошибкой»
Брет Тейлор
технический директор Facebook
Необходимы вложения в инфраструктуру на старте проекта
Сложность масштабирования
Сложность администрирования (в случае размещения в территориально удаленных
датацентрах)
Создание всех сопутствующих сервисов с нуля

6. Amazon Web Services
• Некоторый опыт работы с
Amazon
• Несколько территориально
распределенных ДЦ
• Большой выбор готовых
сервисов

7. Можно много и быстро пробовать!

8. Web – автоматическое масштабирование
CloudWatch + Auto Scaling
Web 1
Очень высокая посещаемость
Elastic Load Balancing
Web 2 Web N
…
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling

9. Web – автоматическое масштабирование
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling
Автоматически стартуют новые машины, если средняя нагрузка CPU превышает заданный верхний порог
Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка опускается ниже
заданного нижнего порога

10. Экономим – spot instances
CloudWatch + Auto Scaling (spot)
Web 1
Очень высокая посещаемость
Elastic Load Balancing
Web 2 Web N
…
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling
CloudWatch + Auto Scaling (on demand)
Web 1 Web N
…

11. Используем master-master репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от друга:
потеря связности между датацентрами может составлять часы, данные
синхронизируются после восстановления.
Пользователь и все сотрудники этой компании работают в одном датацентре.

12. Резервирование на уровне датацентра
Elastic
Load Balancing
MySQL
master
Web 1
Elastic
Load Balancing
Web 2 Web N
… S3
management,
monitoring,
MySQL backup
Датацентр 1 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
master-master
репликация
MySQL
master
Web 1 Web 2 Web N
…
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling

13. Сценарий: авария на одной или нескольких веб-нодах
MySQL
master
Elastic
Load Balancing
Web N
…Web 1 Web 2
MySQL
master
Web 1 Web 2 Web N
…
master-master
репликация
S3
management,
monitoring,
MySQL backup
Датацентр 1 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling

14. Сценарий: авария на одной или нескольких веб-нодах
Load Balancing определяет вышедшие из строя машины
Исходя из заданных параметров группы балансировки, автоматически
восстанавливается нужное количество машин

15. Сценарий: авария на одной или нескольких веб-нодах
MySQL
master
Elastic
Load Balancing
Web N
…Web 1 Web 2
MySQL
master
Web 1 Web 2 Web N
…
master-master
репликация
S3
management,
monitoring,
MySQL backup
Датацентр 1 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling

16. Сценарий: плановые работы с базой или авария всего ДЦ
MySQL
master
Elastic
Load Balancing
Web N
…Web 1 Web 2
MySQL
master
Web 1 Web 2 Web N
…
master-master
репликация
S3
management,
monitoring,
MySQL backup
Датацентр 1 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling

17. Сценарий: авария или плановые работы с базой
Весь траффик переключается в один работающий датацентр
CloudWatch определяет возросшую нагрузку на машины и добавляет их в
соответствие с правилами для AutoScaling
Приостанавливается мастер-мастер репликация
Проводятся все необходимые работы с базой, на которую не идет нагрузка
База включается в работу, восстанавливается репликация
Траффик распределяется на оба датацентра
Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения

18. Архитектура Битрикс24
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)

19. Все веб-ноды идентичны и не
зависимы друг от друга, в случае
аварии автоматически стартуют
новые.
Два датацентра синхронизированы
друг с другом и равноценно
обслуживают клиентов. В случае
аварии на уровне датацентра или
плановых работ с базой, траффик
прозрачно для клиентов
переключается на рабочий
датацентр.
Один из приоритетов –
постоянная доступность сервиса,
его отказоустойчивость.

20. Первые предпосылки к переезду: технические
Возросшие требования к скорости работы порталов:
развитие Битрикс24.Диска, скорость отклика,
мобильное приложение, real-time чаты, уведомления
и т.д. Сетевая связность стала иметь большое
значение.
Два новых ДЦ – в Ирландии
Продублировали инфраструктуру (базы, пулинг, auto-
scaling и security группы, серверы бэкапов и т.д.)
Свой API для работы с Route53
Без даунтайма для клиентов!

21. 242-ФЗ вступил в силу на территории России
1 сентября 2015 г.

22. Варианты:
1. Забить.
2. А давайте попробуем всех обмануть 
Сделаем туннель/прокси: возьмем
российский IP, сделаем прокси к западным
серверам и там оставим персональные
данные.
3. Деперсонализировать.
Разместим часть данных в России, а не перс.
данные могут остаться и не в РФ.
4. Полностью переехать.

23. Архитектура Битрикс24
Количество серверов:
• 25-40 - в США
• 35-75 - в Европе
(в зависимости от автомасштабирования)
RTT (Round Trip Time) - время между
отправкой запроса и получением ответа от
сервера:
• США - 130 миллисекунд
• Европа - 70 миллисекунд
• Россия - 5-10 миллисекунд

24. Территориальные балансировщики
Минимальный RTT
SSL – A+ (ssllabs.com)
Поддержка SPDY / HTTP/2
для клиентов
SSL keep alive на бэкенды
Раздельный кэш для общей
статики, пользовательской
статики, композитных
хитов
Работа с территориально
распределенными
бэкендами

25. 1. Первый принципиальный вопрос – это
выбор между размещением на
физическом оборудовании (неважно, это
будут наши собственные серверы или
арендованные) или же на уже развернутой
у провайдера виртуальной инфраструктуре
(по сути – IaaS).
2. Во-вторых, нам было важно, чтобы
провайдер имел как минимум 2 ДЦ для
резервирования на уровне датацентра,
чтобы мы могли строить такую же
структуру, как и раньше.
3. Выбор гипервизора. Коммерческий или
некоммерческий?
Как мы выбирали провайдера

26. • Виртуальные машины с произвольной конфигурацией дисков.
• Динамическая тарификация.
• Наличие API: стоп/старт машин, подключить/отключить диски,
назначить внешний IP и т.д.
• Снэпшоты дисков и целые образы виртуальных машин.
• Балансировщики Level 7 , DNS, Firewall, горизонтальное
масштабирование, сервисы очередей и т.д.
Выбирая провайдера, мы понимали, что в России мы не найдем
полного соответствия нашим требованиям. В любом случае,
придется самим дорабатывать-дописывать, и вот тут важно, чтобы
дорабатывать пришлось не на 70%, а на 20-30%.
Наши требования к «облаку»

27. Вопросы и сложности. 1 сентября
Резкий рост нагрузки
Сложности с быстрым
масштабированием
Производительность дисковой
системы
Тюнинг сетевого стека

28. Системными утилитами мониторим LA
Используем API VMware
Автоматически стартуют новые машины, если средняя нагрузка CPU превышает заданный верхний
порог
Автоматически останавливаются и выводятся из балансировщика, если средняя нагрузка
опускается ниже заданного нижнего порога
Вопросы и сложности. Делаем свой scaling

29. 0
5000
10000
15000
20000
25000
30000
35000
40000
45000
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Количество хитов

30. 0
0.5
1
1.5
2
2.5
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Load Average

31. 0
10
20
30
40
50
60
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Количество серверов

32. 0
50
100
150
200
250
300
350
400
0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00
Время генерации страниц (мс)

33. Как выпускать
обновления?

34. Обновления ПО на web-нодах
Web 1
Web 2
Web N
Сервер
обновлений
Новый
образ AMI
Elastic
Load
Balancing
Каждый портал работает с собственной
базой.
Все обновления ставятся на выделенный
instance, куда не приходит нагрузка.
Из этого инстанса делается новый образ
AMI.
Последовательно каждая машина
помечается «плохой», при этом новые
веб-ноды стартуют уже из нового образа.
В веб-приложении существует механизм
проверки соответствия версии ПО и базы.
Если клиентский запрос приходит на ноду
с новым ПО, а база еще старая, по
первому хиту происходит обновление.

35. Обновления ПО на web-нодах
В России все очень похоже, но чуть иначе
Новые инстансы не стартуем из образа, а просто делаем stop/start (так просто
быстрее)
API VMware vCloud
ansible
Поочередно выводим машины из балансировки нагрузки, а потом возвращаем
«Эталонный» сервер единый
Синхронизация между регионами – ansible, bash
В итоге – единый скрипт

36. Иногда слоники не взлетают…

37. Битрикс24: процедуры раскатки
Stage / production: множество НЕ выпущенные на клиентов аварий
Значительно проще экспериментировать
Ускорение цикла выпуска обновлений
Безопасность
Процедура быстрой раскатки с резервного эталона
Хотфиксы

38. Если ваш сайт выглядит как живой...
убедитесь, что он еще и здоровый.

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

40. Как при этом не взорвать мозг?
Доступность «Битрикс24» и
облачных сервисов
«1С-Битрикс» - 99.9+%
8200+ проверок в трех
регионах в системе
мониторинга

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

42. Мониторинг «железа»
Рейды
S.M.A.R.T. – диск, возможно, скоро «умрет»
Утилиты вендора – внутренние аппаратные тесты

43. Мониторинг сети
Загрузка канала
Потери пакетов
Связность узлов

44. Мониторинг сети
SpeedTest

45. Мониторинг операционной системы
Место на дисках
Очередь выполнения
Размер и использование swap

46. Тесты критичного софта
Для критичного софта: считаем число процессов, объем RSS,
%CPU, process system/user time

47. Тесты БД
Пример для MySQL

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

49. SSL сертификаты
Проэкспайрившийся SSL сертификат можно заметить не сразу,
если по HTTPS работает не весь сайт, а отдельные разделы
При этом закрыты наиболее критичные разделы (корзина,
авторизация и т.п.)
Теряем позиции в поиске

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

51. «Бизнес»-метрики
Например, количество
заказов в единицу
времени

52. Например, регистрации в «Битрикс24»

53. Уведомления
Cкрипт, опрашивающий страницу «Problems»
Шлем «дайджест» проблем, а не по одному
сообщению на каждое событие
Шлем СМС, не e-mail (не только e-mail)
Лучше – на разных операторов
Несколько уровней критичности событий
Разные списки адресатов на разные события
Повтор (через 15 минут, через 2 часа), чтобы не
«потерять» уведомление
Возможность проверки прямо из СМС
ОК – если все стало хорошо

54. Зачем наступать на одни
и те же грабли, если
вокруг полно новых?

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

56. event handler
# Segfaults on the server
define service{
use local-service
host_name ec2-54-227-28-75.compute-1.amazonaws.com
service_description Segmentaion Fault Errors
check_command check_nrpe_1arg!check_segfault!
event_handler restart_phpfpms
}
define command{
command_name restart_phpfpms
command_line /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c restart_phpfpm
}

57. «На всякий случай…»
Внешние системы:
http://host-tracker.com/
Яндекс.Метрика
И т.д.
* * * * * user /opt/manage/bin/http_sms.sh

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

59. Аналитика

60. Аналитика - MySQL
Следите за числом запросов и коннектов в БД, количеством
медленных запросов, прочими характеристиками

61. Динамика загрузки страниц
Navigation Timing API

64. Поиск узких мест и действия
Нужно быстро понять – где и как починить
Смотрим срабатывание тестов – часто единственный источник информации
Смотрим уведомления от системы мониторинга
Смотрим логи. Держим заготовленные скипты-парсеры логов на поиск ошибок.
Смотрим графики
Если получается, запускаем инструменты поиска узких мест

65. error.log
Агрегирующие скрипты (PHP, Perl, bash):
PHP Signals: 62
[…]
PHP Fatals: 94
[…]
PHP Warnings: 5
[…]

66. access.log
Apache
LogFormat "%t "%r" %>s %b child:%P time-> %D" timing
Nginx
log_format timing … '->$upstream_response_time';
PHP-FPM
access.format = … %{mili}d …

67. Поиск «узких» мест
Apache /server-status
Включенные логи медленных запросов php-fpm, nginx, apache,
MySQL
Не только «…Ops», но и «Dev…»:
Pinba
Xhprof
И т.д.

68. Инструменты поиска узких мест
Если никаких других инструментов нет, или надо срочно локализовать
проблему на «бою»
Можно просто перезапустить Apache / nginx / PHP-FPM, но вы не
найдете суть проблемы, и она повторится
Старые добрые утилиты unix: netstat, lsof, strace, gdb
И попроще: grep, awk, sort, uniq и т.д.
Для MySQL (и вот мы уже становимся DBA): понимание EXPLAIN,
SHOW PROCESSLIST, SHOW ENGINE InnoDB STATUS и т.д.
Тренируйтесь!

69. Наша команда… раньше

70. Коммуникации

71. Коммуникации

72. Дежурства

73. Автоматизация

74. Наша команда… сейчас
Обучение новых сотрудников
Документирование всех процессов
Регламенты работ
Планерки
Круглосуточное дежурство

75. Наше хозяйство
Около 300 виртуалок + прочие сервисы (SQS, DynamoDB, Kinesis, S3 и т.д.)
14 точек присутствия (ДЦ)
До 135 000 хитов в минуту в пике (100М хитов к динамике в сутки)

76. Самый главный рецепт!
Работа в команде
Любить продукт
Любить клиентов

77. Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
demidov
Demidov.Alexander