DUMP-2012 - Только хардкор! - "Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24/7"

Сергей Рыжиковгенеральный директор

компании «1С-Битрикс»

Архитектура и запуск SaaS решения в Amazon AWS. Как обеспечить реальные 24?

Цель на 2012 год

Задача для компании в 2012 году – запустить в коммерческую эксплуатацию «Битрикс24»

• Аренда Корпоративного портала как инструмента социального интранета

• Развитие социального Project- и Task-менеджмента• Развитие Social CRM - готового, простого в использовании

решения • Собрать и накопить опыт по эксплуатации облачных веб-

сервисов, поделиться им с партнерами

• Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи

• Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта

• Масштабирование при росте нагрузки и обратное масштабирование• Надежность – обеспечение SLA• Работа с разными рынками: США, Европа, Россия• Быстрая отдача статического контента

Есть несколько задач на старте и в процессе работы

Запускаем новый SaaS-сервис «Битрикс24»

• Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)

• MultiTenancy архитектура• Полное разделение логики (кода продукта) и данных• Пользовательские данные – это большой объем статических файлов

и база данных• Универсальный API платформы для многолетней разработки• Динамическое масштабирование по нагрузке

Из «бизнес-требований» появились технические

• Выбор технической платформы для инфраструктуры• Выбор платформы разработки

Две итоговые задачи:

Независимые факторы надежности

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

Веб-приложение

Кэшированиена диск

База данных

Традиционное устройствовеб-продуктов

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

Балансировщик (клиентские запросы по HTTP)

Веб-сервер 1

memcached 1

Веб-сервер 2

memcached 2MySQLmaster

MySQLslave

1 этап : Веб-кластер

Облачная платформа: веб-кластер

Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)

Репликация MySQL и балансирование нагрузки между серверами

Распределенный кеш данных (memcached)

Непрерывность сессий между веб-серверами (хранение сессий в базе данных)

Кластеризация веб-сервера:

Синхронизация файлов (это – проблема для облачного сервиса)Балансирование нагрузки между серверами

«Веб-кластер», ДЦ в России

БД

Веб-нода

«Веб-кластер», ДЦ в Германии

«Веб-кластер», ДЦ в США

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

Асинхронная master-master репликация для обеспечения работы географически распределенных веб-кластеров.

Потеря связи между ДЦ может составлять часы.

2 этап – гео веб-кластер

Облачное хранилищефайлов

Облачное хранилище файлов (Amazon S3, Azure, Google Storage, OpenStack

Swift) + CDN

Посетители


Веб-сервер

ДЦ в России

Веб-сервераВеб-серверы

slave

БД (master)


Веб-сервер

ДЦ в США

Веб-сервераВеб-серверы

slave

БД (master)

Платформа для разработки облачных веб-сервисов

• В версии 10. 0 реализована поддержка веб-кластера.

• В версии 11.0 – географический веб-кластер master-master.

• В версии 11.0 – поддержка облачных хранилищ, тайм-зон, автомасштабирования.

• В 2011 году разработана облачная архитектура эксплуатации в Амазоне.

• Накоплен опыт работы в Амазоне , опыт эксплуатации и особенности работы в облачной инфраструктуре.

• В конце 2011 г была запущена первая опытная версия сервиса «Битрикс24».

• Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)

• Большой объем базы данных – шардинг – возможность разделить базу данных по территории и группам клиентов

• MultiTenancy архитектура

• Полное разделение логики (кода продукта) и данных

• Пользовательские данные – это большой объем статических файлов и база данных

• Универсальный API платформы для многолетней разработки

• Динамическое масштабирование по нагрузке

Из «бизнес-требований» появились технические

Минусы размещения на собственном оборудовании:

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

Брет Тейлортехнический директор Facebook

Выбор платформы для разворачивания инфраструктуры

• Необходимы вложения в инфраструктуру на старте проекта• Сложность масштабирования• Сложность администрирования (в случае размещения в

территориально удаленных датацентрах)• Создание всех сопутствующих сервисов с нуля

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

MySQLmaster

Web 1

ElasticLoad Balancing

Web 2

Web N…

MySQLmaster

Web 1

Web 2

Web N…

master-master репликация

Архитектура «Битрикс24»

S3

management, monitoring,

MySQL backup

Датацентр 1 в регионе 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 отдельное пространство для кеширования данных

• Все веб-ноды могут обслуживать любых клиентов, набор данных определяется по домену и не может быть изменен.


Готов только первый «двигатель самолета»

MySQLmaster

Web 1


Web 2

Web N… S3


MySQL backup




MySQLmaster

Web 1

Web 2

Web N…



• Особенности настройки MySQL:• auto_increment_increment• auto_increment_offset

• Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.

• В любое время можно добавить новые датацентры.

• Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.

• Сессии храним в базе, но не реплицируем между серверами из-за большого траффика:

• SET sql_log_bin = 0 … или …• replicate-wild-ignore-table = %.b_sec_session%

Используем master-master репликацию в MySQL

MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


Сценарий 1: авария на одной или нескольких веб-нодах

S3


MySQL backup





Load Balancing определяет вышедшие из строя машины.

Исходя из заданных параметров группы балансировки, автоматически восстанавливается нужное количество машин.


MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


S3


MySQL backup






MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


Сценарий 2: потеря связности между датацентрами

S3


MySQL backup







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

Сценарий 2: потеря связности между датацентрами

MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


Сценарий 3: плановые работы с базой или авария всего ДЦ

S3


MySQL backup





Весь трафик переключается в один работающий датацентр.

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

ElasticLoad

Balancing

Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)

Обновления ПО на веб-нодах

Контроллер

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

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


MySQLmaster

Web 1

HTTP/HTTPS*.ru


HTTP/HTTPS*.com

Web 2

Web N…

CloudWatch + AutoScaling

MySQL slave

CloudWatch

MySQLmaster

Web 1

Web 2

Web N…

CloudWatch + AutoScaling

MySQL slave

CloudWatch


Итоговая архитектура Битрикс24

S3

HTTP/HTTPS*.com*.ru


MySQL backup

cache cache

Все веб-ноды идентичны и не зависимы друг от друга, в случае аварии автоматически стартуют новые.

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

НадежностьОдин из приоритетов – постоянная доступность сервиса, его отказоустойчивость.

www.bitrix24.ru

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

@rsv_bitrix

Documents

DUMP-2012 - Только хардкор! - "Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24/7"