Clouds NN 2012 Александр Демидов "Битрикс24 архитектура и опыт эксплуатации отказоустойчивого, масштабируемого,

«Битрикс24»: архитектура и опыт эксплуатации отказоустойчивого, масштабируемого, высоконагруженного веб-сервиса в облаке

Александр Демидовруководитель направления арендных решений

«1С-Битрикс»

Цель на 2012 год

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

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

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

Запускаем новый SaaS продукт Bitrix24

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

Быстро

Без сбоев

Для пользователя

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

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

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

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

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

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

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

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

База данных

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

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

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

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

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

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

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

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

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

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

Веб-сервер 1

memcached 1


memcached 2MySQLmaster

MySQLslave

1-ый этап реализации

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


memcached 1


memcached 1MySQLmaster

MySQLslave

Аварии на уровне целого датацентра

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

БД

Веб-нода

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

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

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

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

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

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

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

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

Azure, Google Storage, OpenStack Swift) + CDN

Посетители


Веб-сервер

ДЦ в России

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

slave

БД (master)


Веб-сервер

ДЦ в США

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

slave

БД (master)

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

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

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

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

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

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

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

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

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

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 превышает 50% (по метрикам CloudWatch)Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее 20%

Специфика web-нод

Есть несколько задач, которые необходимо решить:

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

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

Статический контент пользователей сервиса

ElasticLoad Balancing

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

MySQLmaster

Web 1


Web 2

Web N… S3

management, monitoring,

MySQL backup

Датацентр 1 в регионе US East (Virginia)

Мониторинг и масштабирование – CloudWatch + AutoScaling

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

MySQLmaster

Web 1

Web 2

Web N…



Особенности настройки MySQL:auto_increment_incrementauto_increment_offset

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

Используем 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

BLOB, TEXT в таблицах MEMORY (HEAP)

MySQL? Percona Server!

Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL)

Виртуальная машина (EC2)

«Узким» местом может оказаться производительность дисковой системы. Решение – из EBS дисков Amazon можно построить software RAID.

Выбираем RAID-10, так как он и быстрый, и надежный.

Конфигурация машинс базами MySQL

Бэкап базы данных

Еще один вывод: для разных сценариев восстановления данных необходимо использовать разные бэкапы.

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

Web 1

Web 2

Web N

Сервер обновлений

Новый образ AMI

ElasticLoad

Balancing

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

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


MySQLmaster

Web 1

HTTP/HTTPS*.ru


HTTP/HTTPS*.com

Web 2

Web N…

CloudWatch + AutoScaling

CloudWatch

MySQLmaster

Web 1

Web 2

Web N…

CloudWatch + AutoScaling

CloudWatch


Итоговая архитектура Bitrix24

S3

HTTP/HTTPS*.com*.ru


MySQL backup

cache cache

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

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

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

Мониторинг

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

…и аналитика

ЛогиPinba и т.п.Munin и т.п.

Надежность «облака»

Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.

Битрикс24

www.bitrix24.ru

http://www.bitrix24.ru/

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

Александр Демидов

[email protected]

+7 (915) 201-1500

@demidov

http://www.1c-bitrix.ru

mailto:[email protected]

http://www.1c-bitrix.ru/

Technology

Clouds NN 2012 Александр Демидов "Битрикс24 архитектура и опыт эксплуатации отказоустойчивого, масштабируемого,