CodeFest 2012. Рыжиков С. — Архитектура и запуск облачного...

Сергей Рыжиков генеральный директор компании «1С-‐Битрикс»

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

Цель на 2012 год

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

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

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

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

Битрикс24

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных

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

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

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

Веб-‐сервер 1

memcached 1

Веб-‐сервер 2

memcached 2 MySQL master

MySQL slave

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

Облачная платформа: веб-‐кластер •  Вертикальный шардинг (вынесение модулей на отдельные серверы

MySQL)

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

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

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

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

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

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

БД

Веб-‐нода

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

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

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

БД

Веб-‐нода

Кэш

Асинхронная master-‐master репликация для обеспечения работы географически распределенных веб-‐кластеров. Потеря связи между ДЦ может составлять часы.

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

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

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

Swi�) + CDN

Посетители

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

Веб-сервер

ДЦ в России

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

slave

БД (master)

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

Веб-сервер

ДЦ в США

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

slave

БД (master)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MySQL master

Web 1

ElasZc 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


CloudWatch + Auto Scaling

Web 1

Очень высокая посещаемость


Web 2

Web N …

Web – автоматическое масштабирование

Используем связку Elaswc Load Balancing + CloudWatch + Auto Scaling

Web – автоматическое масштабирование

Используем связку Elaswc 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  отдельное пространство для кеширования данных •  Все веб-‐ноды могут обслуживать любых клиентов, набор данных определяется по домену и не может быть изменен.


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

MySQL master

Web 1


Web 2

Web N … S3


MySQL backup



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


Web N …

Web 1

Web 2

MySQL master

Web 1

Web 2

Web N …


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

S3


MySQL backup



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

автоматически восстанавливается нужное количество машин.


MySQL master


Web N …

Web 1

Web 2

MySQL master

Web 1

Web 2

Web N …


S3


MySQL backup




MySQL master


Web N …

Web 1

Web 2

MySQL master

Web 1

Web 2

Web N …


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

S3


MySQL backup





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

"   Данные синхронизируются после восстановления связности.

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

MySQL master


Web N …

Web 1

Web 2

MySQL master

Web 1

Web 2

Web N …


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

S3


MySQL backup



"   Весь трафик переключается в один работающий датацентр. " CloudWatch определяет возросшую нагрузку на машины и

добавляет их в соответствие с правилами для AutoScaling.

"   Приостанавливается мастер-‐мастер репликация. "   Проводятся все необходимые работы с базой, на которую

не идет нагрузка.

"   База включается в работу, восстанавливается репликация. "   Траффик распределяется на оба датацентра. "   Гасятся лишние машины, если средняя нагрузка стала ниже

порогового значения.

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

•  Оптимизирован для работы в «облаке» (с относительно медленными дисками) •  Быстрое восстановление кэша при рестарте базы •  Оптимизирован для Mulwtenancy приложений с тысячами таблиц •  Оптимизирован для сбора статистики по отдельным пользователям •  Подробная статистика по медленным запросам •  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

ElasZc Load

Balancing

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

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

Контроллер

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


MySQL master

Web 1

HTTP/HTTPS *.ru


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


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

S3

HTTP/HTTPS *.com *.ru


MySQL backup

cache cache

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

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

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

Идет тестирование

•  Не раздавайте «инвайты», используйте только сами! •  Для тестирования ограничение по пользователям не

установлено. •  Тем, кто перейдет на использование компанией, сервис

предоставим бесплатно (50 Гб).

Ваш персональный «инвайт» на Битрикс24

XXX-‐XXX-‐XX

Следите за нами!

www.1c-‐bitrix.ru

facebook.com/1CBitrix

twi¦er.com/1C_Bitrix

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

CodeFest 2012. Рыжиков С. — Архитектура и запуск облачного...

Documents

Transcript of CodeFest 2012. Рыжиков С. — Архитектура и запуск облачного...