Bitrix24: архитектура высоконагруженных и отказоустойчивых проектов Александр Демидов, Александр Сербул

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

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

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

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

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

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

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

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

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

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

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

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

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 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 MySQL slave CloudWatch MySQL master Web 1 Web 2 Web N … CloudWatch + AutoScaling MySQL slave CloudWatch master-master репликация Итоговая архитектура Bitrix24 S3 HTTP/HTTPS *.com *.ru management, monitoring, MySQL backup cache

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

Bitrix24

Следите за нами! facebook.com/1CBitrix twitter.com/1C_Bitrix

Спасибо за внимание! Вопросы?

Bitrix24: архитектура высоконагруженных и отказоустойчивых проектов Что вошло только в режиссерскую версию презентации…

Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Все клиентские запросы (HTTP и HTTPS) поступают на один или несколько балансировщиков Amazon (ELB) При росте нагрузки (и обратно) используем горизонтальное (а не вертикальное) масштабирование. Для каждой отдельной веб-ноды можем использовать хоть micro instance, а управлять – их количеством. Рост и снижение нагрузки мониторим через CloudWatch двумя путями – состояние нод EC2 (% CPU Utilization) и балансировщика (время latency – в секундах). Все ноды – абсолютно идентичны. Каждая новая нода поднимается из заранее созданного образа (AMI). Любая веб-нода может обслуживать любого клиента. Web – подробнее про масштабирование

Еще немного о том, как работает авто-масштабирование Мы задаем в конфигурации минимально необходимое количество машин. В случае сбоев или аварий машина помечается «плохой», гасится, и поднимается новый instance – из единого образа (AMI). Балансировщик умеет распределять нагрузку между разными датацентрами (AZ - Availability Zones). Можем держать машины в разных зонах на случай аварии уровня целого датацентра. Web

Для хранения и отдачи статического контента пользователей сервиса используем Amazon S3 (Simple Storage Service) Любое количество объектов (до 5 Тб каждый) Возможность размещения в разных датацентрах (регионах) Группировка объектов Механизмы авторизации REST и SOAP интерфейсы для работы с объектами Высокая доступность Низкая цена (по сравнению с EBS) Статический контент пользователей сервиса

Снижаем стоимость эксплуатации Можем использовать совместно с CDN для ускорения отдачи контента Снижаем нагрузку на web-узлы Используя централизованное хранилище, решаем задачу синхронизации контента между множественными web-узлами Разделяем пользовательские данные и код Статический контент пользователей сервиса Какие задачи решаем, используя S3?

Любое решение выбирается, исходя из конкретной поставленной задачи. Для работы MySQL используем InnoDB. Следовательно, необходимо эффективно работать с операциями random read/write на больших файлах (ibdata). Тесты sysbench Работы с одиночным файлом 16 Гб в режиме random read/write. При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет. Как определить конфигурацию RAID для базы?

Как делать бэкап RAID-10? Для Amazon EC2 есть удобный механизм snapshotов. Как сделать целостный бэкап RAID-10 из нескольких дисков? А лучше – всей машины в целом Используем файловую систему, поддерживающую freeze (xfs, утилита xfs_freeze; или на новых ядрах Linux и ext3/ext4 и механизм fsfreeze). Делаем freeze файловой системы (в случае MySQL правильно предварительно сделать FLUSH TABLES WITH READ LOCK). Делаем снэпшоты всех дисков. «Размораживаем» файловую систему. Для бэкапа файлов – достаточно, но если хотим быстро и удобно переезжать между AZ (Availability Zones), используем более высокий уровень абстракции и оперируем образами целых машин – AMI (Amazon Machine Image).

Для масштабирования только чтения используем master- slave репликацию MySQL master MySQL slave Веб-нода Балансировка SQL Приложение умеет отправлять запросы на запись на master, а запросы на чтение – на slave. После запросов, изменяющих данные, в случае «отставания» slave – некоторое время чтение идет с мастера Масштабирование базы

CloudWatch MySQL master MySQL slave Веб-нода Балансировка SQL Elastic IP Мониторим состояние master через CloudWatch Есть slave – минимальной конфигурации – работающий в режиме только бэкапа При необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование) Останавливаем master, делаем slave мастером Переключаем IP (Amazon Elastic IP) на машину с новым мастером Веб-ноды не требуют переконфигурирования и продолжают работать без даунтайма Если требуется масштабирование мастера MySQL Для вертикального масштабирования используем slave, потом переключаем его в master

Недостаточно гибкая система (нет полноценного root в базе) Непрозрачно Риск долгого даунтайма (пример попадания молнии в европейский ДЦ в августе) Двойная стоимость машин при использовании Multi-AZ Почему не RDS? У Amazon есть сервис RDS (Relational Database Service). Можно использовать MySQL или Oracle. Почему не стали использовать его?

Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база) Каждое клиентское приложение работает с собственной базой. Все обновления ставятся на выделенный instance, куда не приходит нагрузка. Из этого инстанса делается новый образ AMI. Последовательно каждая машина помечается «плохой», при этом новые веб-ноды стартуют уже из нового образа. В веб-приложении существует механизм проверки соответствия версии ПО и базы. Если клиентский запрос приходит на ноду с новым ПО, а база еще старая, по первому хиту происходит обновление. Как работают обновления ПО на web-нодах

Внутри региона все веб-ноды не зависимы друг от друга, поднимаются в любой AZ (резервирование на случай аварии на уровне AZ) Реплика базы (slave) поднята в другой AZ Между регионами настроена master- master репликация В случае аварии на уровне целого региона: в DNS меняется IP – на балансировщик в другой зоне веб-ноды идентичны для каждого региона требуется поменять только адрес подключения к базе Надежность Один из приоритетов – постоянная доступность сервиса