Pinboard + pinba / Как организовать мониторинг сотни PHP-проектов (Devconf 2014)
Bitrix24 (DevConf)
-
Upload
alexander-demidov -
Category
Technology
-
view
736 -
download
13
description
Transcript of Bitrix24 (DevConf)
Архитектура и запуск облачного сервиса.
Как обеспечить реальные 24ч.
Александр Демидов, «1С-Битрикс»
проект Битрикс24
Цель на 2012 год
Задача для компании в 2012 году –запустить в коммерческую эксплуатациюBitrix24
Аренда Корпоративного портала как инструмента социального интранета
Развитие социального Project- и Task-менеджмента
Развитие Social CRM - готового, простого в использовании решения
Собрать и накопить опыт по эксплуатации облачных веб-сервисов, поделиться им с партнерами
Новый SaaS продукт
Есть несколько задач на старте и в процессе работы
Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи
Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта
Масштабирование при росте нагрузки и обратное масштабированиеНадежность – обеспечение SLAРабота с разными рынками: США, Европа, РоссияБыстрая отдача статического контента
Из «бизнес-требований» появились технические
Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)MultiTenancy архитектураПолное разделение логики (кода продукта) и данныхПользовательские данные – это большой объем статических файлов и база данныхУниверсальный API платформы для многолетней разработкиДинамическое масштабирование по нагрузке
Выбор технической платформы для инфраструктурыВыбор платформы разработки
Две итоговые задачи:
Масштабируемая платформа: веб-кластер
Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)Репликация MySQL и балансирование нагрузки между серверамиРаспределенный кеш данных (memcached)Непрерывность сессий между веб-серверами (хранение сессий в базе данных)Кластеризация веб-сервера:
Синхронизация файлов (это – проблема для облачного сервиса)
Балансирование нагрузки между серверами
1-ый этап реализации
Балансировщик (клиентские запросы по HTTP)
Веб-сервер 1
memcached 1
Веб-сервер 2
memcached 2
MySQLmaster
MySQLslave
2-ой этап – гео веб-кластер
«Веб-кластер», ДЦ в России
«Веб-кластер», ДЦ в России
БДБД
Веб-нодаВеб-нода
«Веб-кластер», ДЦ в Германии«Веб-кластер»,
ДЦ в Германии
«Веб-кластер», ДЦ в США
«Веб-кластер», ДЦ в США
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
БДБД
Веб-нодаВеб-нода
КэшКэш
Асинхронная master-master репликация для обеспечения работы географически распределенных веб-кластеров.
Потеря связи между ДЦ может составлять часы.
Облачное хранилище файлов
Облачное хранилище файлов (Amazon S3, Azure, Google Storage,
OpenStack Swift) + CDN
Облачное хранилище файлов (Amazon S3, Azure, Google Storage,
OpenStack Swift) + CDN
Посетители
Веб-приложениеВеб-приложение
Веб-серверВеб-сервер
ДЦ в России
Веб-сервераВеб-сервераВеб-серверыВеб-серверы
slaveslave
БД (master)БД (master)
Веб-приложениеВеб-приложение
Веб-серверВеб-сервер
ДЦ в США
Веб-сервераВеб-сервераВеб-серверыВеб-серверы
slaveslave
БД (master)БД (master)
Выбор платформы для разворачивания инфраструктуры
Минусы размещения на собственном оборудовании:
«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой»
Брет Тейлортехнический директор Facebook
Необходимы вложения в инфраструктуру на старте проектаСложность масштабированияСложность администрирования (в случае размещения в территориально удаленных датацентрах)Создание всех сопутствующих сервисов с нуля
Архитектура Bitrix24
MySQLmaster
Web 1
Web 1
ElasticLoad Balancing
ElasticLoad Balancing
Web 2
Web 2
Web N
Web N…
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
master-master
репликация
S3
management, monitoring,
MySQL backup
Датацентр 1
Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2
Мониторинг и масштабирование – CloudWatch + AutoScaling
Web – автоматическое масштабирование
CloudWatch + Auto Scaling
Web 1
Web 1
Очень высокая посещаемость
Elastic Load BalancingElastic Load Balancing
Web 2Web 2 Web N Web N…
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling
Web – автоматическое масштабирование
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling
Автоматически стартуют новые машины, если средняя нагрузка CPU превышает 40%
Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее 20%
Ставили верхний порог больше, однако начинается общая деградация системы – пользователям работать некомфортно (долго загружаются страницы)
Тест
вынесение модулей на отдельные серверы MySQL)
Специфика web-нод
Есть несколько задач, которые необходимо решить:
На веб-нодах нет пользовательского контента, все ноды должны быть абсолютно идентичны.
Read only. Никакие пользовательские данные не пишутся и не сохраняются на веб-нодах, так как в любой момент времени любая машина может быть выключена или стартует новая из «чистого» образа.
При этом необходимо обеспечить изоляцию пользователей друг от друга.
Тест
вынесение модулей на отдельные серверы MySQL)
Специфика web-нод
Нет Apache. Есть PHP-FPM + nginxУ каждого клиента свой доменБыл разработан модуль для PHP:
проверяет корректность домена, завершает хит с ошибкой, если имя некорректноустанавливает соединение с нужной базой в зависимости от доменаобеспечивает безопасность и изоляцию пользователей друг от другаслужит для шардинга данных разных пользователей по разным базам
Статический контент пользователей сервиса
Статические данные пользователей храним в S3Загрузка осуществляется «прозрачно» для пользователей – они работают с привычными интерфейсамиПравильно формируются url’ы к картинкам, документам и т.п.Для каждого созданного Корпоративного портала создается персональный аккаунт – данные каждого КП полностью изолированы друг от друга
ElasticLoad Balancing
ElasticLoad Balancing
MySQLmaster
Web 1
Web 1
ElasticLoad Balancing
ElasticLoad Balancing
Web 2
Web 2
Web N
Web N… S3
management, monitoring,
MySQL backup
Датацентр 1
Мониторинг и масштабирование – CloudWatch + AutoScaling
master-master
репликация
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
Датацентр 2
Мониторинг и масштабирование – CloudWatch + AutoScaling
Используем master-master репликацию в MySQL
Особенности настройки MySQL:auto_increment_incrementauto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.В любое время можно добавить новые датацентры.Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.Сессии храним в базе, но не реплицируем между серверами из-за большого траффика и возможных «локов»:
SET sql_log_bin = 0 … или …replicate-wild-ignore-table = %.b_sec_session%
Сценарий 1: авария на одной или нескольких веб-нодах
MySQLmaster
ElasticLoad Balancing
ElasticLoad Balancing
Web N
Web N…
Web 1
Web 1
Web 2
Web 2
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
master-master
репликация
S3
Датацентр 1
Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2
Мониторинг и масштабирование – CloudWatch + AutoScaling
Сценарий 1: авария на одной или нескольких веб-нодах
Load Balancing определяет вышедшие из строя машиныИсходя из заданных параметров группы балансировки, автоматически восстанавливается нужное количество машин
Сценарий 1: авария на одной или нескольких веб-нодах
MySQLmaster
ElasticLoad Balancing
ElasticLoad Balancing
Web N
Web N…
Web 1
Web 1
Web 2
Web 2
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
master-master
репликация
S3
Датацентр 1
Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2
Мониторинг и масштабирование – CloudWatch + AutoScaling
Сценарий 2: потеря связности между датацентрами
MySQLmaster
ElasticLoad Balancing
ElasticLoad Balancing
Web N
Web N…
Web 1
Web 1
Web 2
Web 2
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
master-master
репликация
S3
Датацентр 1
Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2
Мониторинг и масштабирование – CloudWatch + AutoScaling
ElasticLoad Balancing
ElasticLoad Balancing
ElasticLoad Balancing
ElasticLoad Balancing
Сценарий 2: потеря связности между датацентрами
Каждый датацентр продолжает обслуживать свой сегмент клиентовДанные синхронизируются после восстановления связности
Сценарий 3: плановые работы с базой или авария всего ДЦ
MySQLmaster
ElasticLoad Balancing
ElasticLoad Balancing
Web N
Web N…
Web 1
Web 1
Web 2
Web 2
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
master-master
репликация
S3
Датацентр 1
Мониторинг и масштабирование – CloudWatch + AutoScaling
Датацентр 2
Мониторинг и масштабирование – CloudWatch + AutoScaling
Сценарий 3: авария или плановые работы с базой
Весь траффик переключается в один работающий датацентрCloudWatch определяет возросшую нагрузку на машины и добавляет их в соответствие с правилами для AutoScalingПриостанавливается мастер-мастер репликацияПроводятся все необходимые работы с базой, на которую не идет нагрузкаБаза включается в работу, восстанавливается репликацияТраффик распределяется на оба датацентраГасятся лишние машины, если средняя нагрузка стала ниже порогового значения
MySQL? Percona Server!
Быстрое восстановление кэша при рестарте базы
Оптимизирован для Multitenancy приложений с тысячами таблиц
Оптимизирован для сбора статистики по отдельным пользователям
Подробная статистика по медленным запросам
XtraDB и XtraBackup
BLOB, TEXT в таблицах MEMORY (HEAP)
Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL)
Тест
вынесение модулей на отдельные серверы MySQL)
Виртуальная машина (EC2), не RDS
«Узким» местом может оказаться производительность дисковой системы. Решение – из EBS дисков Amazon можно построить software RAID.
Выбираем RAID-10, так как он и быстрый, и надежный.
Конфигурация машинс базами MySQL
Бэкап базы данных
Еще один вывод: для разных сценариев восстановления данных необходимо использовать разные бэкапы.
Для восстановления целого сервера БД в случае аварии используем образ машин со всеми дисками (AMI) – делаем целостный бэкап RAID’а, используя файловую систему, поддерживающую freeze и механизм snapshot’ов в Амазоне.Логические (mysqldump) и бинарные инкрементальные (Xtrabackup) бэкапы используются для восстановления отдельных баз или таблиц, поврежденных в случае некорректных операций в системе или ошибок пользователей.Второй тип бэкапов делается на выделенном slave, на который не распределяется общая нагрузка. Тем самым ресурсоемкие операции создания бэкапов не влияют на работу пользователей.
Обновления ПО на web-нодах
Web 1
Web 1
Web 2
Web 2
Web N
Web N
Сервер обновлений
Сервер обновлений
Новый образ AMI
Новый образ AMI
ElasticLoad
Balancing
ElasticLoad
Balancing
Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)
Немного разгрузим web-ноды
…Nginx http_sub_module nginx_substitutions_filter
location / { subs_filter '<link href="/([^ ]+).css' '<link href="http://cdn.domain.ru/$1.css' gir;}
…и client side
на один хост всего
Firefox 13 6 40
IE 8 / 9 6 35
Opera 11 6 32
Safari 5.2 6 30
Chrome 19 6 17
Максимальное количество соединений на хост
Access-Control-Allow-Origin: *
ElasticLoad Balancing
ElasticLoad Balancing
MySQLmaster
Web 1
Web 1
HTTP/HTTPS*.ru
ElasticLoad Balancing
ElasticLoad Balancing
HTTP/HTTPS*.com
Web 2
Web 2
Web N
Web N…
CloudWatch + AutoScaling
CloudWatch
MySQLmaster
Web 1
Web 1
Web 2
Web 2
Web N
Web N…
CloudWatch + AutoScaling
CloudWatch
master-master
репликация
S3
HTTP/HTTPS*.com*.ru
management, monitoring,
MySQL backup
cache cache
Все веб-ноды идентичны и не зависимы друг от друга, в случае аварии автоматически стартуют новые.Два датацентра синхронизированы друг с другом и равноценно обслуживают клиентов. В случае аварии на уровне датацентра или плановых работ с базой, траффик прозрачно для клиентов переключается на рабочий датацентр.
НадежностьОдин из приоритетов – постоянная доступность сервиса, его отказоустойчивость.
Спасибо за внимание! Вопросы?
Александр Демидов
+7 (915) 201-1500
@demidov
http://www.1c-bitrix.ru