Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Производительность проекта

Сергей Рыжиков
Директор
«1С-Битрикс»
1С-Битрикс: Виртуальная машина
«1С-Битрикс: Виртуальная машина» – это «1С-Битрикс: Вебокружение Linux» с использованием ра...
Сколько стоит 1 час?
Крупный интернет-магазин
с годовым оборотом 1.5
млрд. руб.
210 рабочих дней в году по
10 рабочих часо...
Основные задачи, которые
решает веб-кластер:
Обеспечение высокой
доступности сервиса (так
называемые HA - High Availabilit...
Географический веб-кластер
повышает отказоустойчивость
проекта и обеспечивает
независимость от дата-центра.
В различных да...
Географический веб-кластер
«Веб-кластер»,
ДЦ в России

Веб-нода
Веб-нода
Веб-нода

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

ДЦ в России

Посетители

ДЦ в США

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

Веб-сервер
Веб-сервера
...
Схема «облачного сервиса»
HTTP/HTTPS
*.com

HTTP/HTTPS
*.com
*.ru

HTTP/HTTPS
*.ru

ДЦ в России

cache

cache

Web 1

Web ...
Архитектура проекта «Битрикс24»:
как сделать так, чтобы все летало и не падало
Цель на 2012 год
Задача для компании в 2012 году – запустить в
коммерческую эксплуатацию Bitrix24
Аренда Корпоративного по...
Запускаем новый SaaS продукт
Bitrix24
Есть несколько задач на старте и
в процессе работы
Новый SaaS сервис – как коммерчес...
Для пользователя

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

Веб-нода
Веб-нода
Веб-нода

Асинхронная master-master р...
Облачное хранилище
файлов

ДЦ в России

Посетители

ДЦ в США

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

Веб-сервер
Веб-сервера
В...
Из «бизнес-требований»
появились технические
Отказоустойчивость – умение размещаться сразу в нескольких
разных территориал...
Выбор платформы для
разворачивания инфраструктуры
Минусы размещения на
собственном оборудовании:
Необходимы вложения в инф...
Используем все возможности масштабирования в
Amazon – исходя из экономики проекта.
Архитектура Bitrix24
Elastic
Load Balancing

Web 1

Web 2

Датацентр 1
Мониторинг и
масштабирование –
CloudWatch +
AutoSca...
Web – автоматическое
масштабирование
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Очень высокая по...
Web – автоматическое
масштабирование
Используем связку Elastic Load Balancing + CloudWatch +
Auto Scaling
Автоматически ст...
Специфика web-нод
Есть несколько задач, которые
необходимо решить:
На веб-нодах нет пользовательского
контента, все ноды д...
Специфика web-нод
Нет Apache. Есть PHP-FPM + nginx
У каждого клиента свой домен
Был разработан модуль для PHP:
проверяет к...
Статический контент
пользователей сервиса
Статические данные пользователей
храним в S3
Загрузка осуществляется
«прозрачно»...
Готов только первый «двигатель
самолета»
Elastic
Load Balancing

Web 1

Web 2

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

…...
Используем master-master
репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Ба...
Сценарий 1: авария на одной или
нескольких веб-нодах
Elastic
Load Balancing

Web 1

Web 2

Датацентр 1 в
регионе US East
(...
Сценарий 1: авария на одной или
нескольких веб-нодах

Load Balancing определяет вышедшие из строя машины
Исходя из заданны...
Сценарий 1: авария на одной или
нескольких веб-нодах
Elastic
Load Balancing

Web 1

Web 2

Датацентр 1 в
регионе US East
(...
Сценарий 2: потеря связности
между датацентрами
Elastic
Load Balancing

Web 1

Web 2

Датацентр 1 в
регионе US East
(Virgi...
Сценарий 2: потеря связности
между датацентрами

Каждый датацентр продолжает обслуживать свой сегмент
клиентов
Данные синх...
Сценарий 3: плановые работы с
базой или авария всего ДЦ
Elastic
Load Balancing

Web 1

Web 2

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

Весь траффик переключается в один работающий датацентр
CloudWatch определя...
MySQL? Percona Server!
Один из выводов в процессе эксплуатации: используем
один из fork’ов MySQL – Percona Server (обратно...
Конфигурация машин
с базами MySQL
Виртуальная машина (EC2)

«Узким» местом может
оказаться
производительность
дисковой сис...
Бэкап базы данных
Еще один вывод: для разных сценариев восстановления
данных необходимо использовать разные бэкапы.
Для во...
Обновления ПО на web-нодах
Как ставить обновления на нодах, не допустив
рассинхронизации данных (веб и база)
Сервер
обновл...
Итоговая архитектура Bitrix24
HTTP/HTTPS
*.com

HTTP/HTTPS
*.com
*.ru

HTTP/HTTPS
*.ru

Elastic
Load Balancing

Elastic
Lo...
Мониторинг
Мониторим все, но аккуратно
Мгновенные уведомления (sms)
Автоматика
…и аналитика
Логи
Pinba и т.п.
Munin и т.п.
Bitrix24

www.bitrix24.ru
Спасибо за внимание!
Вопросы?
Сергей Рыжиков
rsv@bitrix24.ru
+7 (926) 000-8880

@rsv_bitrix
http://www.bitrix24.ru
Upcoming SlideShare
Loading in …5
×

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

193 views

Published on

Сергей Рыжиков. Директор "1С-Битрикс". Нагруженный Форк. Производительность проекта. Архитектура проекта «Битрикс24»: как сделать так, чтобы все летало и не падало, master-master, мастер мастер

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Производительность проекта Сергей Рыжиков Директор «1С-Битрикс»
  2. 2. 1С-Битрикс: Виртуальная машина «1С-Битрикс: Виртуальная машина» – это «1С-Битрикс: Вебокружение Linux» с использованием разных способов виртуализации. Виртуальная машина эмулирует работу реального компьютера и включает в себя: сконфигурированную операционную систему; веб-сервер; базу данных; firewall; почтовый сервер; мастер создания кластера, мастер добавления slave-сервера, мастер переключения slave-сервера в режим master; а также большое число настроек, от которых зависит надежность, производительность и безопасность веб-проекта.
  3. 3. Сколько стоит 1 час? Крупный интернет-магазин с годовым оборотом 1.5 млрд. руб. 210 рабочих дней в году по 10 рабочих часов. Час простоя крупного интернет-проекта может обойтись владельцам в 0,3 - 1 миллион рублей упущенной выручки.
  4. 4. Основные задачи, которые решает веб-кластер: Обеспечение высокой доступности сервиса (так называемые HA - High Availability или Failover кластеры) Масштабирование веб-проекта в условиях возрастающей нагрузки (HP - High Performance кластеры) Балансирование нагрузки, трафика, данных между несколькими серверами. Создание целостной резервной копии данных для MySQL.
  5. 5. Географический веб-кластер повышает отказоустойчивость проекта и обеспечивает независимость от дата-центра. В различных дата-центрах объединяются несколько групп веб-кластеров, находящихся в разных городах или странах. В случае отказа одного датацентра, в работу мгновенно включается другой, без необходимости восстановления «бэкапа».
  6. 6. Географический веб-кластер «Веб-кластер», ДЦ в России Веб-нода Веб-нода Веб-нода Асинхронная master-master репликация для обеспечения работы географически распределенных веб-кластеров. Потеря связи между ДЦ может составлять часы. Кэш Кэш Кэш «Веб-кластер», ДЦ в США Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш «Веб-кластер», БД БД ДЦ в Германии БД Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш БД БД БД БД БД БД
  7. 7. Географический веб-кластер ДЦ в России Посетители ДЦ в США Веб-сервер Веб-сервера Веб-серверы Веб-сервер Веб-сервера Веб-серверы Веб-приложение Веб-приложение БД (master) slave Облачное хранилище файлов (Amazon S3, Azure, Google Storage, OpenStack Swift) + CDN БД (master) slave
  8. 8. Схема «облачного сервиса» HTTP/HTTPS *.com HTTP/HTTPS *.com *.ru HTTP/HTTPS *.ru ДЦ в России cache cache Web 1 Web 2 ДЦ в США CloudWatch + AutoScaling … cache Облачное хранилище cache Web 1 Web N cache Web 2 CloudWatch CloudWatch + AutoScaling … cache Web N CloudWatch MySQL master master-master репликация MySQL slave MySQL master MySQL slave management, monitoring
  9. 9. Архитектура проекта «Битрикс24»: как сделать так, чтобы все летало и не падало
  10. 10. Цель на 2012 год Задача для компании в 2012 году – запустить в коммерческую эксплуатацию Bitrix24 Аренда Корпоративного портала как инструмента социального интранета Развитие социального Project- и Task-менеджмента Развитие Social CRM - готового, простого в использовании решения Собрать и накопить опыт по эксплуатации облачных вебсервисов, поделиться им с партнерами
  11. 11. Запускаем новый SaaS продукт Bitrix24 Есть несколько задач на старте и в процессе работы Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта Масштабирование при росте нагрузки и обратное масштабирование Надежность – обеспечение SLA Работа с разными рынками: США, Европа, Россия Быстрая отдача статического контента
  12. 12. Для пользователя Быстро Без сбоев
  13. 13. Независимые факторы надежности Человечество уже сделало определенный путь - для обеспечения независимых факторов надежности. Для Bitrix24 нужен аналогичный подход – продолжать работу без потери данных в случае выхода из строя одного ДЦ и быть способными восстанавливать базы данных за несколько минут.
  14. 14. 2-ой этап – географический веб-кластер «Веб-кластер», ДЦ в России Веб-нода Веб-нода Веб-нода Асинхронная master-master репликация для обеспечения работы географически распределенных веб-кластеров. Потеря связи между ДЦ может составлять часы. Кэш Кэш Кэш «Веб-кластер», ДЦ в США Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш «Веб-кластер», БД БД ДЦ в Германии БД Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш БД БД БД БД БД БД
  15. 15. Облачное хранилище файлов ДЦ в России Посетители ДЦ в США Веб-сервер Веб-сервера Веб-серверы Веб-сервер Веб-сервера Веб-серверы Веб-приложение Веб-приложение БД (master) slave Облачное хранилище файлов (Amazon S3, Azure, Google Storage, OpenStack Swift) + CDN БД (master) slave
  16. 16. Из «бизнес-требований» появились технические Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах) Большой объем базы данных – шардинг – возможность разделить базу данных по территории и группам клиентов MultiTenancy архитектура Полное разделение логики (кода продукта) и данных Пользовательские данные – это большой объем статических файлов и база данных Универсальный API платформы для многолетней разработки Динамическое масштабирование по нагрузке
  17. 17. Выбор платформы для разворачивания инфраструктуры Минусы размещения на собственном оборудовании: Необходимы вложения в инфраструктуру на старте проекта Сложность масштабирования Сложность администрирования (в случае размещения в территориально удаленных датацентрах) Создание всех сопутствующих сервисов с нуля «Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой» Брет Тейлор технический директор Facebook
  18. 18. Используем все возможности масштабирования в Amazon – исходя из экономики проекта.
  19. 19. Архитектура Bitrix24 Elastic Load Balancing Web 1 Web 2 Датацентр 1 Мониторинг и масштабирование – CloudWatch + AutoScaling … Web N MySQL master S3 master-master репликация management, monitoring, MySQL backup Web 1 MySQL master Web 2 … Web N Датацентр 2 Мониторинг и масштабирование – CloudWatch + AutoScaling
  20. 20. Web – автоматическое масштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Очень высокая посещаемость Elastic Load Balancing Web 1 Web 2 … CloudWatch + Auto Scaling Web N
  21. 21. Web – автоматическое масштабирование Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Автоматически стартуют новые машины, если средняя нагрузка CPU превышает 60% Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка менее 30% Ставили верхний порог на 80%, однако начинается общая деградация системы – пользователям работать некомфортно (долго загружаются страницы)
  22. 22. Специфика web-нод Есть несколько задач, которые необходимо решить: На веб-нодах нет пользовательского контента, все ноды должны быть абсолютно идентичны. Read only. Никакие пользовательские данные не пишутся и не сохраняются на веб-нодах, так как в любой момент времени любая машина может быть выключена или стартует новая из «чистого» образа. При этом необходимо обеспечить изоляцию пользователей друг от друга.
  23. 23. Специфика web-нод Нет Apache. Есть PHP-FPM + nginx У каждого клиента свой домен Был разработан модуль для PHP: проверяет корректность домена, завершает хит с ошибкой, если имя некорректно устанавливает соединение с нужной базой в зависимости от домена обеспечивает безопасность и изоляцию пользователей друг от друга служит для шардинга данных разных пользователей по разным базам
  24. 24. Статический контент пользователей сервиса Статические данные пользователей храним в S3 Загрузка осуществляется «прозрачно» для пользователей – они работают с привычными интерфейсами Правильно формируются url’ы к картинкам, документам и т.п. Для каждого созданного Корпоративного портала создается персональный аккаунт – данные каждого КП полностью изолированы друг от друга
  25. 25. Готов только первый «двигатель самолета» Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Elastic Load Balancing Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, m onitoring, MySQL backup
  26. 26. Используем master-master репликацию в MySQL Особенности настройки MySQL: auto_increment_increment auto_increment_offset Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления. В любое время можно добавить новые датацентры. Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком. Сессии храним в базе, но не реплицируем между серверами из-за большого траффика и возможных «локов»: SET sql_log_bin = 0 … или … replicate-wild-ignore-table = %.b_sec_session%
  27. 27. Сценарий 1: авария на одной или нескольких веб-нодах Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, monitoring, MySQL backup
  28. 28. Сценарий 1: авария на одной или нескольких веб-нодах Load Balancing определяет вышедшие из строя машины Исходя из заданных параметров группы балансировки, автоматически восстанавливается нужное количество машин
  29. 29. Сценарий 1: авария на одной или нескольких веб-нодах Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, m onitoring, MySQL backup
  30. 30. Сценарий 2: потеря связности между датацентрами Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Elastic Load Balancing Web N MySQL master S3 master-master репликация Elastic Load Balancing Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, monitoring, MySQL backup
  31. 31. Сценарий 2: потеря связности между датацентрами Каждый датацентр продолжает обслуживать свой сегмент клиентов Данные синхронизируются после восстановления связности
  32. 32. Сценарий 3: плановые работы с базой или авария всего ДЦ Elastic Load Balancing Web 1 Web 2 Датацентр 1 в регионе US East (Virginia) … Web N MySQL master S3 master-master репликация Web 1 MySQL master Web 2 … Web N Датацентр 2 в регионе US East (Virginia) Мониторинг и масштабирование – CloudWatch + AutoScaling Мониторинг и масштабирование – CloudWatch + AutoScaling management, monitoring, MySQL backup
  33. 33. Сценарий 3: авария или плановые работы с базой Весь траффик переключается в один работающий датацентр CloudWatch определяет возросшую нагрузку на машины и добавляет их в соответствие с правилами для AutoScaling Приостанавливается мастер-мастер репликация Проводятся все необходимые работы с базой, на которую не идет нагрузка База включается в работу, восстанавливается репликация Траффик распределяется на оба датацентра Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения
  34. 34. MySQL? Percona Server! Один из выводов в процессе эксплуатации: используем один из fork’ов MySQL – Percona Server (обратно совместим с MySQL) Быстрое восстановление кэша при рестарте базы Оптимизирован для Multitenancy приложений с тысячами таблиц Оптимизирован для сбора статистики по отдельным пользователям Подробная статистика по медленным запросам XtraDB и XtraBackup BLOB, TEXT в таблицах MEMORY (HEAP)
  35. 35. Конфигурация машин с базами MySQL Виртуальная машина (EC2) «Узким» местом может оказаться производительность дисковой системы. Решение – из EBS дисков Amazon можно построить software RAID. Выбираем RAID-10, так как он и быстрый, и надежный.
  36. 36. Бэкап базы данных Еще один вывод: для разных сценариев восстановления данных необходимо использовать разные бэкапы. Для восстановления целого сервера БД в случае аварии используем образ машин со всеми дисками (AMI) – делаем целостный бэкап RAID’а, используя файловую систему, поддерживающую freeze и механизм snapshot’ов в Амазоне. Логические (mysqldump) и бинарные инкрементальные (Xtrabackup) бэкапы используются для восстановления отдельных баз или таблиц, поврежденных в случае некорректных операций в системе или ошибок пользователей. Второй тип бэкапов делается на выделенном slave, на который не распределяется общая нагрузка. Тем самым ресурсоемкие операции создания бэкапов не влияют на работу пользователей.
  37. 37. Обновления ПО на web-нодах Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база) Сервер обновлений Новый образ AMI Web 1 Web 2 Web N Elastic Load Balancing
  38. 38. Итоговая архитектура Bitrix24 HTTP/HTTPS *.com HTTP/HTTPS *.com *.ru HTTP/HTTPS *.ru Elastic Load Balancing Elastic Load Balancing CloudWatch + AutoScaling Web 1 Web 2 … cache S3 Web N MySQL master CloudWatch CloudWatch + AutoScaling Web 1 master-master репликация management, m onitoring, MySQL backup Web 2 … Web N cache MySQL master CloudWatch
  39. 39. Мониторинг Мониторим все, но аккуратно Мгновенные уведомления (sms) Автоматика
  40. 40. …и аналитика Логи Pinba и т.п. Munin и т.п.
  41. 41. Bitrix24 www.bitrix24.ru
  42. 42. Спасибо за внимание! Вопросы? Сергей Рыжиков rsv@bitrix24.ru +7 (926) 000-8880 @rsv_bitrix http://www.bitrix24.ru

×