Архитектура и запуск SaaS решения вAmazon AWS. Как обеспечить реальные 24?                             Сергей Рыжиков     ...
Цель на 2012 годЗадача для компании в 2012 году – запустить вкоммерческую эксплуатацию «Битрикс24»• Аренда Корпоративного ...
Запускаем новый SaaS-сервис«Битрикс24» Есть несколько задач на старте и в процессе работы  • Новый SaaS сервис – как комме...
Из «бизнес-требований» появились технические  • Отказоустойчивость – умение размещаться сразу в нескольких      разных тер...
Независимые  факторы надежностиЧеловечество уже сделалоопределенный путь дляобеспечения независимыхфакторов надежности.Для...
Традиционное устройствовеб-продуктов                                  Веб-приложение                                   Кэш...
1 этап : Веб-кластер                       Балансировщик (клиентские запросы                                  по HTTP)    ...
Облачная платформа: веб-кластер• Вертикальный шардинг (вынесение модулей на отдельные серверы  MySQL)• Репликация MySQL и ...
2 этап – гео веб-кластер                     Асинхронная master-master репликация    «Веб-кластер»,   для обеспечения рабо...
Облачное хранилищефайлов    ДЦ в России                                               ДЦ в США                            ...
Платформа для разработкиоблачных веб-сервисов• В версии 10. 0 реализована поддержка веб-кластера.• В версии 11.0 – географ...
Из «бизнес-требований»появились технические• Отказоустойчивость – умение размещаться сразу в нескольких разных  территориа...
Выбор платформы дляразворачивания инфраструктуры Минусы размещения на собственном оборудовании: • Необходимы вложения в ин...
Используем все возможности масштабирования вAmazon, исходя из экономики проекта.
Архитектура «Битрикс24»                                          Elastic                                      Load Balanci...
Web – автоматическоемасштабированиеИспользуем связку Elastic Load Balancing + CloudWatch +Auto Scaling                    ...
Web – автоматическоемасштабированиеИспользуем связку Elastic Load Balancing + CloudWatch +Auto Scaling Автоматически старт...
Специфика веб-нодЕсть несколько задач, которыенеобходимо решить:• На веб-нодах нет пользовательского  контента, все ноды д...
Специфика веб-нод• Нет Apache. Есть PHP-FPM + nginx• У каждого клиента свой домен• Был разработан модуль для PHP:    • про...
Bitrix24 - cвой модуль для PHP   • Обеспечивает переопределние функции соединения     с базой данных.   • В отдельной табл...
Статический контентпользователей сервисаСтатические данные пользователейхраним в S3.Загрузка осуществляется«прозрачно» для...
Полная изоляция данных • Данные одной компании полностью изолированы от данных   другой. • Для каждого клиента данные хран...
Готов только первый  «двигатель самолета»                  Elastic                       Elastic              Load Balanci...
Используем master-masterрепликацию в MySQL• Особенности настройки MySQL:     • auto_increment_increment     • auto_increme...
Сценарий 1: авария на одной или нескольких веб-нодах                                          Elastic                     ...
Сценарий 1: авария на однойили нескольких веб-нодах  Load Balancing определяет вышедшие из строя машины.  Исходя из заданн...
Сценарий 1: авария на одной или нескольких веб-нодах                                          Elastic                     ...
Сценарий 2: потеря связности между датацентрами                  Elastic                       Elastic                    ...
Сценарий 2: потеря связностимежду датацентрами Каждый датацентр продолжает обслуживать свой сегмент клиентов. Данные синхр...
Сценарий 3: плановые работы с  базой или авария всего ДЦ                                          Elastic                 ...
Сценарий 3: плановые работы сбазой или авария всего ДЦ Весь трафик переключается в один работающий датацентр. CloudWatch о...
MySQL? Percona Server!Один из выводов в процессе эксплуатации: используемодин из fork’ов MySQL – Percona Server (обратно с...
Конфигурация машинс базами MySQL  Виртуальная машина (EC2)  - Extra Large Instance – 15  Gb RAMЭтапы масштабирования:1) Ве...
Бэкап базы данныхЕще один вывод: для разных сценариев восстановленияданных необходимо использовать разные бэкапы.  Для вос...
Обновления ПО на веб-нодахКак ставить обновления на нодах, не допустиврассинхронизации данных (веб и база)                ...
КонтроллерИспользуется для логического управления проектами, выполнениялюбых команд, SQL-запросов и PHP-кода на любой из к...
Итоговая архитектура Битрикс24                 HTTP/HTTPS                         HTTP/HTTPS                     HTTP/HTTP...
НадежностьОдин из приоритетов –постоянная доступностьсервиса, его отказоустойчивость.  Все веб-ноды идентичны и не  зависи...
www.bitrix24.ru
Спасибо за внимание!Вопросы?  @rsv_bitrix
DUMP-2012 - Только хардкор! - "Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24/7" Сергей Р...
DUMP-2012 - Только хардкор! - "Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24/7" Сергей Р...
Upcoming SlideShare
Loading in …5
×

DUMP-2012 - Только хардкор! - "Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24/7" Сергей Рыжиков (Битрикс)

1,699 views
1,628 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,699
On SlideShare
0
From Embeds
0
Number of Embeds
1,088
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DUMP-2012 - Только хардкор! - "Архитектура и запуск облачного сервиса в Amazon AWS. Как обеспечить реальные 24/7" Сергей Рыжиков (Битрикс)

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

×