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

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

Битрикс24

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

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

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

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

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

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

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

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

Платформа для разработки облачных веб-сервисов В версии реализована поддержка веб-кластера. В версии 11.0 – географический веб-кластер master-master. В версии 11.0 – поддержка облачных хранилищ, тайм-зон, автомасштабирования. В 2011 году разработана облачная архитектура эксплуатации в Амазоне. Накоплен опыт работы в Амазоне, опыт эксплуатации и особенности работы в облачной инфраструктуре. В конце 2011 г была запущена первая опытная версия сервиса «Битрикс24».

Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах) Большой объем базы данных – шардинг – возможность разделить базу данных по территории и группам клиентов 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 репликация Архитектура «Битрикс24» 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%, однако начинается общая деградация системы – пользователям работать некомфортно (долго загружаются страницы)

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

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

Bitrix24 - cвой модуль для PHP Обеспечивает переопределние функции соединения с базой данных. В отдельной таблице хранит строки соединения с разными мастерами и «слейвами», обслуживающими БД. Позволяет выполнять горизонтальное масштабирование БД (шардинг) по любому количеству серверов вплоть до «один клиент на одном сервере». Обеспечивает запуск (fork) процессов для PHP и быструю отдачу страницы пользователю.

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

Полная изоляция данных Данные одной компании полностью изолированы от данных другой. Для каждого клиента данные хранятся раздельно: o свой логин пароль к БД o своя БД со структурой таблиц o свое облачное хранилище S3 с отдельным логином/паролем o отдельное пространство для кеширования данных Все веб-ноды могут обслуживать любых клиентов, набор данных определяется по домену и не может быть изменен.

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 репликация S3 management, monitoring, MySQL backup Датацентр 1 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Сценарий 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 репликация Сценарий 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 Этапы масштабирования: 1)Вертикальное масштабирование (дисковая система RAID-10 на EBS) 2)Веб-кластер master-slave. Запуск необходимого числа слейвов в конфигурации веб-кластера master-slave 3)Горизонтальное масштабирование, разделение мастера на несколько серверов Все этапы выполняются без остановки сервиса. Конфигурация машин с базами MySQL

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

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

Контроллер Используется для логического управления проектами, выполнения любых команд, SQL-запросов и PHP-кода на любой из копии проекта. Обеспечивает биллинг, включение тарифных планов, ограничения по пользователям, дисковому пространству и т.д.

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 репликация Итоговая архитектура Битрикс24 S3 HTTP/HTTPS *.com *.ru management, monitoring, MySQL backup cache

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

ваш

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

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