(2 часть) 1С-Битрикс. Производительность проекта. Архитектура проекта «Битрикс24»

Сергей РыжиковДиректор

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

Производительность проекта

«1С-Битрикс: Виртуальная машина» – это «1С-Битрикс: Веб-окружение Linux» с использованием разных способов виртуализации.

Виртуальная машина эмулирует работу реального компьютера и включает в себя:

сконфигурированную операционную систему;

веб-сервер;

базу данных;

firewall;

почтовый сервер;

мастер создания кластера, мастер добавления slave-сервера, мастер переключения slave-сервера в режим master;

а также большое число настроек, от которых зависит надежность, производительность и безопасность веб-проекта.

1С-Битрикс: Виртуальная машина

Сколько стоит 1 час?

Крупный интернет-магазин с годовым оборотом 1.5 млрд. руб.

210 рабочих дней в году по 10 рабочих часов.

Час простоя крупного интернет-проекта может обойтись владельцам в 0,3 - 1 миллион рублей упущенной выручки.

Основные задачи, которые решает веб-кластер:

Обеспечение высокой доступности сервиса (так называемые HA - High Availability или Failover кластеры)

Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры)

Балансирование нагрузки, трафика, данных между несколькими серверами.

Создание целостной резервной копии данных для MySQL.

Географический веб-кластер повышает отказоустойчивость проекта и обеспечивает независимость от дата-центра.

В различных дата-центрах объединяются несколько групп веб-кластеров, находящихся в разных городах или странах.

В случае отказа одного дата-центра, в работу мгновенно включается другой, без необходимости восстановления «бэкапа».

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

БД

Веб-нода

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

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

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

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

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

Географический веб-кластер

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

Azure, Google Storage, OpenStack Swift) + CDN

Посетители

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

Веб-сервер

ДЦ в России

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

slave

БД (master)


Веб-сервер

ДЦ в США


slave

БД (master)

Географический веб-кластер

ДЦ в США

MySQLmaster

Web 1

HTTP/HTTPS*.ru


HTTP/HTTPS*.com

Web 2

Web N…

CloudWatch + AutoScaling

MySQLslave

cache cache cache

CloudWatch

MySQLmaster

Web 1

Web 2

Web N…


MySQLslave

cache cache cache

CloudWatch

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

Схема «облачного сервиса»

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

HTTP/HTTPS*.com*.ru

management, monitoring

Архитектура проекта «Битрикс24»:как сделать так, чтобы все летало и не падало

Цель на 2012 год

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

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

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

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

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

Быстро

Без сбоев

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

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

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

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

БД

Веб-нода

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

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

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

БД

Веб-нода

Кэш

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

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

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

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

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

Azure, Google Storage, OpenStack Swift) + CDN

Посетители


Веб-сервер



slave

БД (master)


Веб-сервер

ДЦ в США


slave

БД (master)

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

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

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

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

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

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

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

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

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

MySQLmaster

Web 1

ElasticLoad Balancing

Web 2

Web N…

MySQLmaster

Web 1

Web 2

Web N…


Архитектура Bitrix24

S3

management, monitoring,

MySQL backup

Датацентр 1

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

Датацентр 2


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’ы к картинкам, документам и т.п.Для каждого созданного Корпоративного портала создается персональный аккаунт – данные каждого КП полностью изолированы друг от друга

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


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

MySQLmaster

Web 1


Web 2

Web N… S3


MySQL backup

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



MySQLmaster

Web 1

Web 2

Web N…



Особенности настройки MySQL:auto_increment_incrementauto_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

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

MySQLmaster

Web 1

Web 2

Web N…


CloudWatch


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

S3

HTTP/HTTPS*.com*.ru


MySQL backup

cache cache

Мониторинг

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

…и аналитика

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

Bitrix24

www.bitrix24.ru

http://www.bitrix24.ru/

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

Сергей Рыжиков

[email protected]

+7 (926) 000-8880

@rsv_bitrix

http://www.bitrix24.ru

mailto:[email protected]

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

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

Technology

(2 часть) 1С-Битрикс. Производительность проекта. Архитектура проекта «Битрикс24»