clouds nn 2012 Александр Демидов "Битрикс24 архитектура и...
TRANSCRIPT
«Битрикс24»: архитектура и опыт эксплуатации отказоустойчивого, масштабируемого, высоконагруженного веб-сервиса в облаке
Александр Демидовруководитель направления арендных решений
«1С-Битрикс»
Цель на 2012 год
Задача для компании в 2012 году – запустить в коммерческую эксплуатацию Bitrix24
Аренда Корпоративного портала как инструмента социального интранетаРазвитие социального Project- и Task-менеджментаРазвитие Social CRM - готового, простого в использовании решения Собрать и накопить опыт по эксплуатации облачных веб-сервисов, поделиться им с партнерами
Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователиМинимизация расходов на эксплуатацию и снижение финансовых рисков на старте проектаМасштабирование при росте нагрузки и обратное масштабированиеНадежность – обеспечение SLAРабота с разными рынками: США, Европа, Россия
Запускаем новый SaaS продукт Bitrix24
Есть несколько задач на старте и в процессе работы
Быстро
Без сбоев
Для пользователя
Независимые факторы надежности
Человечество уже сделало определенный путь - для обеспечения независимых факторов надежности. Для Bitrix24 нужен аналогичный подход – продолжать работу без потери данных в случае выхода из строя одного ДЦ и быть способными восстанавливать базы данных за несколько минут.
Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)MultiTenancy архитектураПолное разделение логики (кода продукта) и данныхПользовательские данные – это большой объем статических файлов и база данныхУниверсальный API платформы для многолетней разработкиДинамическое масштабирование по нагрузке
Из «бизнес-требований» появились технические
Выбор технической платформы для инфраструктурыВыбор платформы разработки
Две итоговые задачи:
Веб-приложение
Кэшированиена диск
База данных
Традиционное устройствовеб-продуктов
Обычный продут не поддерживает гео веб-кластер, облачные файлы, распределенное кэширование, multitenancy…
Облачная платформа: веб-кластер
Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)
Репликация MySQL и балансирование нагрузки между серверами
Распределенный кеш данных (memcached)
Непрерывность сессий между веб-серверами (хранение сессий в базе данных)
Кластеризация веб-сервера:
Синхронизация файлов (это – проблема для облачного сервиса)Балансирование нагрузки между серверами
Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
memcached 2MySQLmaster
MySQLslave
1-ый этап реализации
Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
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
ElasticLoad Balancing
Web 2
Web N… S3
management, monitoring,
MySQL backup
Датацентр 1 в регионе US East (Virginia)
Мониторинг и масштабирование – CloudWatch + AutoScaling
master-master репликация
MySQLmaster
Web 1
Web 2
Web N…
Датацентр 2 в регионе US East (Virginia)
Мониторинг и масштабирование – CloudWatch + AutoScaling
Особенности настройки MySQL:auto_increment_incrementauto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.
Используем master-master репликацию в MySQL
MySQLmaster
ElasticLoad Balancing
Web N…
Web 1
Web 2
MySQLmaster
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: авария на одной или нескольких веб-нодах
MySQLmaster
ElasticLoad Balancing
Web N…
Web 1
Web 2
MySQLmaster
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
MySQLmaster
ElasticLoad Balancing
Web N…
Web 1
Web 2
MySQLmaster
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
ElasticLoad Balancing
ElasticLoad Balancing
Каждый датацентр продолжает обслуживать свой сегмент клиентовДанные синхронизируются после восстановления связности
Сценарий 2: потеря связности между датацентрами
MySQLmaster
ElasticLoad Balancing
Web N…
Web 1
Web 2
MySQLmaster
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
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-нодах
ElasticLoad Balancing
MySQLmaster
Web 1
HTTP/HTTPS*.ru
ElasticLoad Balancing
HTTP/HTTPS*.com
Web 2
Web N…
CloudWatch + AutoScaling
CloudWatch
MySQLmaster
Web 1
Web 2
Web N…
CloudWatch + AutoScaling
CloudWatch
master-master репликация
Итоговая архитектура Bitrix24
S3
HTTP/HTTPS*.com*.ru
management, monitoring,
MySQL backup
cache cache
Все веб-ноды идентичны и не зависимы друг от друга, в случае аварии автоматически стартуют новые.
Два датацентра синхронизированы друг с другом и равноценно обслуживают клиентов. В случае аварии на уровне датацентра или плановых работ с базой, траффик прозрачно для клиентов переключается на рабочий датацентр.
НадежностьОдин из приоритетов – постоянная доступность сервиса, его отказоустойчивость.
Мониторинг
Мониторим все, но аккуратноМгновенные уведомления (sms)Автоматика
…и аналитика
ЛогиPinba и т.п.Munin и т.п.
Надежность «облака»
Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.
Спасибо за внимание! Вопросы?
Александр Демидов
+7 (915) 201-1500
@demidov
http://www.1c-bitrix.ru