Your SlideShare is downloading. ×
(2 часть) 1С-Битрикс. Производительность проекта. Архитектура проекта «Битрикс24»
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

98

Published on

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

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
98
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×