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

1 Архитектура проекта «Битрикс24»: как сделать так, чтобы все летало и не падало Александр Демидов руководитель направления арендных решений «1С-Битрикс»

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

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

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

5 Независимые факторы надежности Человечество уже сделало определенный путь - для обеспечения независимых факторов надежности. Для Bitrix24 нужен аналогичный подход – продолжать работу без потери данных в случае выхода из строя одного ДЦ и быть способными восстанавливать базы данных за несколько минут.

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

7 Веб-приложение Кэширование на диск База данных Традиционное устройство веб-продуктов Обычный продут не поддерживает гео веб-кластер, облачные файлы, распределенное кэширование, multitenancy…

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

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

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

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

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

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

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

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

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

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

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

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

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

21 Elastic Load Balancing Elastic Load Balancing Готов только первый «двигатель самолета» MySQL master Web 1 Elastic Load Balancing 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

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

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

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

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

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

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

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

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

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

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

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

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

34 Elastic Load Balancing Elastic Load Balancing MySQL master Web 1 HTTP/HTTPS *.ru Elastic Load Balancing Elastic Load Balancing HTTP/HTTPS *.com Web 2 Web N … CloudWatch + AutoScaling CloudWatch MySQL master Web 1 Web 2 Web N … CloudWatch + AutoScaling CloudWatch master-master репликация Итоговая архитектура Bitrix24 S3 HTTP/HTTPS *.com *.ru management, monitoring, MySQL backup cache

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

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

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

38 Bitrix24

39 Спасибо за внимание! Вопросы? Александр Демидов +7 (915)