Bitrix24 (DevConf)

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

2. Цель на 2012 год
Задача для компании в 2012 году –
запустить в коммерческую эксплуатацию
Bitrix24
Аренда Корпоративного портала как инструмента социального
интранета
Развитие социального Project- и Task-менеджмента
Развитие Social CRM - готового, простого в использовании решения
Собрать и накопить опыт по эксплуатации облачных веб-сервисов,
поделиться им с партнерами

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

4. Для пользователя…
Быстро
Без сбоев

5. Из «бизнес-требований» появились технические
Отказоустойчивость – умение размещаться сразу в нескольких разных
территориально распределенных датацентрах (в разных странах)
MultiTenancy архитектура
Полное разделение логики (кода продукта) и данных
Пользовательские данные – это большой объем статических файлов и
база данных
Универсальный API платформы для многолетней разработки
Динамическое масштабирование по нагрузке
Две итоговые задачи:
Выбор технической платформы для инфраструктуры
Выбор платформы разработки

6. Традиционное устройство веб-продуктов
Веб-приложение
Кэширование
на диск
База данных

7. Масштабируемая платформа: веб-кластер
• Вертикальный шардинг (вынесение модулей на отдельные серверы
MySQL)
• Репликация MySQL и балансирование нагрузки между серверами
• Распределенный кеш данных (memcached)
• Непрерывность сессий между веб-серверами (хранение сессий в базе
данных)
• Кластеризация веб-сервера:
• Синхронизация файлов (это – проблема для облачного сервиса)
• Балансирование нагрузки между серверами

8. 1-ый этап реализации
Балансировщик (клиентские
запросы по HTTP)
Веб-сервер 1 Веб-сервер 2
MySQL MySQL
memcached memcached
1 master slave 2

9. 2-ой этап – гео веб-кластер
Асинхронная master-master
«Веб-кластер», репликация для обеспечения работы «Веб-кластер»,
ДЦ в России географически распределенных ДЦ в США
веб-кластеров.
Веб-нода Потеря связи между ДЦ может Веб-нода
Веб-нода Веб-нода
Веб-нода составлять часы. Веб-нода
Кэш Кэш
Кэш Кэш
Кэш Кэш
«Веб-кластер»,
БД ДЦ в Германии БД
БД БД
БД БД
Веб-нода
Веб-нода
Веб-нода
Кэш
Кэш
Кэш
БД
БД
БД

10. Облачное хранилище файлов
ДЦ в России ДЦ в США
Посетители
Веб-сервер
Веб-сервера Веб-сервер
Веб-сервера
Веб-серверы Веб-серверы
Веб-приложение Веб-приложение
Облачное хранилище файлов
БД (master) (Amazon S3, Azure, Google Storage,
БД (master)
OpenStack Swift) + CDN
slave slave

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

12. Используем все возможности масштабирования в Amazon – исходя из
экономики проекта.

13. Архитектура Bitrix24
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 MySQL MySQL Датацентр 2
master master- master
Мониторинг и master Мониторинг и
репликация
масштабирование масштабирование
– CloudWatch + – CloudWatch +
AutoScaling AutoScaling
management,
monitoring,
MySQL backup

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

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

16. Специфика web-нод
Тест
Есть несколько задач, которые
вынесение модулей на отдельные серверы MySQL)
необходимо решить:
На веб-нодах нет пользовательского
контента, все ноды должны быть
абсолютно идентичны.
Read only. Никакие пользовательские
данные не пишутся и не сохраняются на
веб-нодах, так как в любой момент
времени любая машина может быть
выключена или стартует новая из
«чистого» образа.
При этом необходимо обеспечить
изоляцию пользователей друг от друга.

17. Специфика web-нод
Тест
Нет Apache. Есть PHP-FPM + nginx
вынесение модулей на отдельные серверы MySQL)
У каждого клиента свой домен
Был разработан модуль для PHP:
проверяет корректность домена,
завершает хит с ошибкой, если имя
некорректно
устанавливает соединение с
нужной базой в зависимости от
домена
обеспечивает безопасность и
изоляцию пользователей друг от
друга
служит для шардинга данных
разных пользователей по разным
базам

18. Статический контент пользователей сервиса
Статические данные пользователей
храним в S3
Загрузка осуществляется
«прозрачно» для пользователей –
они работают с привычными
интерфейсами
Правильно формируются url’ы к
картинкам, документам и т.п.
Для каждого созданного
Корпоративного портала создается
персональный аккаунт – данные
каждого КП полностью изолированы
друг от друга

19. Elastic Elastic
Load Balancing Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 MySQL MySQL Датацентр 2
master master- master
master
Мониторинг и репликация Мониторинг и
масштабирование масштабирование
– CloudWatch + – CloudWatch +
AutoScaling AutoScaling
management,
monitoring,
MySQL backup

20. Используем master-master репликацию в MySQL
Особенности настройки MySQL:
• auto_increment_increment
• auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от
друга: потеря связности между датацентрами может составлять часы,
данные синхронизируются после восстановления.
В любое время можно добавить новые датацентры.
Пользователь и все сотрудники этой компании работают в одном
датацентре за счет управления балансировщиком.
Сессии храним в базе, но не реплицируем между серверами из-за
большого траффика и возможных «локов»:
SET sql_log_bin = 0 … или …
replicate-wild-ignore-table = %.b_sec_session%

21. Сценарий 1: авария на одной или нескольких
веб-нодах
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 MySQL MySQL Датацентр 2
master master- master
master
Мониторинг и репликация Мониторинг и
масштабирование масштабирование
– CloudWatch + – CloudWatch +
AutoScaling AutoScaling

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

23. Сценарий 1: авария на одной или нескольких
веб-нодах
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 MySQL MySQL Датацентр 2
master master- master
master
Мониторинг и репликация Мониторинг и
масштабирование масштабирование
– CloudWatch + – CloudWatch +
AutoScaling AutoScaling

24. Сценарий 2: потеря связности между
датацентрами
Elastic Elastic Elastic
Load Balancing Load Balancing Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 MySQL MySQL Датацентр 2
master master- master
master
Мониторинг и репликация Мониторинг и
масштабирование масштабирование
– CloudWatch + – CloudWatch +
AutoScaling AutoScaling

25. Сценарий 2: потеря связности между
датацентрами
Каждый датацентр продолжает обслуживать свой сегмент
клиентов
Данные синхронизируются после восстановления связности

26. Сценарий 3: плановые работы с базой или
авария всего ДЦ
Elastic
Load Balancing
Web 1 Web 2
… Web N S3 Web 1 Web 2
… Web N
Датацентр 1 MySQL MySQL Датацентр 2
master master- master
master
Мониторинг и репликация Мониторинг и
масштабирование масштабирование
– CloudWatch + – CloudWatch +
AutoScaling AutoScaling

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

28. MySQL? Percona Server!
Один из выводов в процессе эксплуатации:
используем один из fork’ов MySQL – Percona Server
(обратно совместим с MySQL)
Быстрое восстановление кэша при рестарте базы
Оптимизирован для Multitenancy приложений с тысячами таблиц
Оптимизирован для сбора статистики по отдельным пользователям
Подробная статистика по медленным запросам
XtraDB и XtraBackup
BLOB, TEXT в таблицах MEMORY (HEAP)

29. Конфигурация машин
Тест
с базами MySQL
вынесение модулей на отдельные серверы MySQL)
Виртуальная машина
(EC2), не RDS
«Узким» местом может
оказаться
производительность
дисковой системы.
Решение – из EBS дисков
Amazon можно построить
software RAID.
Выбираем RAID-10, так
как он и быстрый, и
надежный.

30. Бэкап базы данных
Еще один вывод: для разных сценариев
восстановления данных необходимо использовать
разные бэкапы.
Для восстановления целого сервера БД в случае аварии используем
образ машин со всеми дисками (AMI) – делаем целостный бэкап
RAID’а, используя файловую систему, поддерживающую freeze и
механизм snapshot’ов в Амазоне.
Логические (mysqldump) и бинарные инкрементальные (Xtrabackup)
бэкапы используются для восстановления отдельных баз или таблиц,
поврежденных в случае некорректных операций в системе или ошибок
пользователей.
Второй тип бэкапов делается на выделенном slave, на который не
распределяется общая нагрузка. Тем самым ресурсоемкие операции
создания бэкапов не влияют на работу пользователей.

31. Обновления ПО на web-нодах
Как ставить обновления на нодах, не допустив
рассинхронизации данных (веб и база)
Сервер Новый
обновлений образ AMI
Web 1
Elastic
Load
Web 2 Balancing
Web N

32. Немного разгрузим web-ноды
…
Nginx http_sub_module
nginx_substitutions_filter
location / {
subs_filter '<link href="/([^ ]+).css' '<link href="http://cdn.domain.ru/$1.css' gir;
}

33. …и client side
Максимальное количество соединений на хост
на один хост всего
Firefox 13 6 40
IE 8 / 9 6 35
Opera 11 6 32
Safari 5.2 6 30
Chrome 19 6 17
Access-Control-Allow-Origin: *

34. HTTP/HTTPS HTTP/HTTPS HTTP/HTTPS
*.com *.com *.ru
*.ru
Elastic Elastic
Load Balancing Load Balancing
CloudWatc CloudWatc
h+ h+
… S3
…
AutoScalin AutoScalin
g g
Web 1 Web 2 Web N Web 1 Web 2 Web N
cache MySQL MySQL cache
master-
master master
master
репликация
management,
CloudWatch monitoring, CloudWatch
MySQL backup

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

36. Мониторинг
Мониторим все, но аккуратно
Мгновенные уведомления (sms)
Автоматика

37. …и аналитика
Логи
Pinba и т.п.
Munin и т.п.

38. Bitrix24
www.bitrix24.ru

39. Спасибо за внимание!
Вопросы?
Александр Демидов
demidov@1c-bitrix.ru
+7 (915) 201-1500
@demidov
http://www.1c-bitrix.ru