1. Проектируем облачныйвеб-сервис «по-взрослому» Сергей Рыжиков генеральный директор компании «1С-Битрикс»

2. Запускаем новый SaaSпродуктBitrix24 Есть несколько задач на старте и в процессе работы Новый SaaSсервис – как коммерческие, так и «бесплатные» пользователи Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта Масштабирование при росте нагрузки и обратное масштабирование Надежность – обеспечение SLA Работа с разными рынками: США, Европа, Россия Быстрая отдача статического контента

3. Из «бизнес-требований» появились технические Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах) Большой объем базы данных –шардинг – возможность разделить базу данных по территории и группам клиентов MultiTenancyархитектура Полное разделение логики (кода продукта) и данных Пользовательские данные – это большой объем статических файлов и база данных Универсальный API платформы для многолетней разработки Динамическое масштабирование по нагрузке Две итоговые задачи: Выбор технической платформы для инфраструктуры Выбор платформы разработки

4. Традиционное устройство веб-продуктов Веб-приложение Кэширование на диск База данных Обычный продут не поддерживает гео веб-кластер, облачные файлы, распределенное кэширование, multitenancy…

5. Облачная платформа: веб-кластер Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL) Репликация MySQLи балансирование нагрузки между серверами Распределенный кешданных (memcached) Непрерывность сессий между веб-серверами (хранение сессий в базе данных) Кластеризация веб-сервера: Синхронизация файлов (это – проблема для облачного сервиса) Балансирование нагрузки между серверами

6. 1-ый этап реализации Балансировщик (клиентские запросы по HTTP) Веб-сервер 1 Веб-сервер 2 memcached 1 memcached2 MySQL master MySQL slave

7. 2-ой этап – гео веб-кластер Асинхронная master-master репликация для обеспечения работы географически распределенных веб-кластеров. Потеря связи между ДЦ может составлять часы. «Веб-кластер», ДЦ в России «Веб-кластер», ДЦ в США Веб-нода Веб-нода Веб-нода Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш Кэш Кэш Кэш «Веб-кластер», ДЦ в Германии БД БД БД БД БД БД Веб-нода Веб-нода Веб-нода Кэш Кэш Кэш БД БД БД

8. Облачное хранилище файлов ДЦ в США Посетители Веб-сервер Веб-сервера Веб-серверы ДЦ в России Веб-сервер Веб-сервера Веб-серверы Веб-приложение Облачное хранилище файлов (Amazon S3, Azure, Google Storage, OpenStack Swift) + CDN БД (master) Веб-приложение slave БД (master) slave

9. Из «бизнес-требований» появились технические Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах) Большой объем базы данных –шардинг – возможность разделить базу данных по территории и группам клиентов MultiTenancyархитектура Полное разделение логики (кода продукта) и данных Пользовательские данные – это большой объем статических файлов и база данных Универсальный API платформы для многолетней разработки Динамическое масштабирование по нагрузке

10. Выбор платформыдля разворачивания инфраструктуры Минусы размещения на собственном оборудовании: Необходимы вложения в инфраструктуру на старте проекта Сложность масштабирования Сложность администрирования (в случае размещения в территориально удаленных датацентрах) Создание всех сопутствующих сервисов с нуля «Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверыили же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой» Брет Тейлор технический директор Facebook

11. Используем AWS: Amazon Web Services У нас есть успешный опыт работы с Amazon (сайт www.1c-bitrix.ruи другие сайты компании). В Amazon много дополнительных сервисов, которые помогают решить наши задачи. Всю архитектуру строим из «кирпичиков» – сервисов AWS.

12. Используем все возможности масштабирования в Amazon – исходя из экономики проекта.

13. Статический контент пользователей сервиса Для хранения и отдачи статического контента пользователей сервиса используем Amazon S3 (Simple Storage Service) Любое количество объектов (до 5 Тб каждый) Возможность размещения в разных датацентрах (регионах) Группировка объектов Механизмы авторизации REST и SOAP интерфейсы для работы с объектами Высокая доступность Низкая цена (по сравнению с EBS)

14. Статический контент пользователей сервиса Какие задачи решаем, используя S3? Снижаем стоимость эксплуатации Можем использовать совместно с CDN для ускорения отдачи контента Снижаем нагрузку на web-узлы Используя централизованное хранилище, решаем задачу синхронизации контента между множественными web-узлами Разделяем пользовательские данные и код

15. Web Используем связку Elastic Load Balancing + CloudWatch+ Auto Scaling Очень высокая посещаемость Elastic Load Balancing CloudWatch + Auto Scaling Web 1 Web 2 … Web N

16. Web Используем связку Elastic Load Balancing + CloudWatch+ Auto Scaling Все клиентские запросы (HTTP и HTTPS) поступают на балансировщикAmazon При росте нагрузки (и обратно) используем горизонтальное (а не вертикальное) масштабирование. Для каждой отдельной веб-ноды можем использовать хоть micro instance, а управлять – их количеством. Рост и снижение нагрузки мониторим через CloudWatchдвумя путями – состояние нод (EC2) и балансировщика. Все ноды – абсолютно идентичны. Каждая новая нода поднимается из заранее созданного образа (AMI). Любая веб-нода может обслуживать любого клиента.

17. Web Используем связку Elastic Load Balancing + CloudWatch+ Auto Scaling Мы задаем в конфигурации минимально необходимое количество машин. В случае сбоев или аварий машина помечается «плохой», гасится, и поднимается новый instance. Балансировщик умеет распределять нагрузку между разными AZ. Можем держать машины в разных зонах на случай аварии уровня AZ.

18. Обновления ПО на web-нодах Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база) Сервер обновлений Новый образ AMI Web 1 Elastic Load Balancing Web 2 Web N

19. Обновления ПО на web-нодах Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база) Каждое клиентское приложение работает с собственной базой. Все обновления ставятся на выделенный instance, куда не приходит нагрузка. Из этого инстанса делается новый образ AMI. Последовательно каждая машина помечается «плохой», при этом новые веб-ноды стартуют уже из нового образа. В веб-приложении существует механизм проверки соответствия версии ПО и базы. Если клиентский запрос приходит на ноду с новым ПО, а база еще старая, по первому хиту происходит обновление.

20. Специфика web-нод На веб-нодах нет пользовательского контента, все ноды абсолютно идентичны. При этом необходимо обеспечить изоляцию пользователей У каждого клиента свой домен Был разработан модуль для PHP: проверяет корректность HTTP_HOST, завершает хит с ошибкой, если имя некорректно устанавливает соединение с нужной базой в зависимости от HTTP_HOST авторизация внутри приложения определяется непосредственно логикой самого приложения

21. Конфигурация машин с базами MySQL Виртуальная машина (EC2) - High-Memory Extra Large Instance – 17.1 Gb RAM «Узким» местом может оказаться производительность дисковой системы. Решение – из EBS дисков Amazon можно построить software RAID. Выбираем RAID-10, так как он и быстрый, и надежный.

22. Как определить конфигурацию RAID? Любое решение выбирается, исходя из конкретной поставленной задачи. Для работы MySQL используем InnoDB. Следовательно, необходимо эффективно работать с операциями random read/write на больших файлах (ibdata). Тесты sysbench Работы с одиночным файлом 16 Гб в режиме random read/write. При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет.

23. Как делать бэкапRAID-10? Для Amazon EC2 есть удобный механизм snapshot’ов. Как сделать целостный бэкапRAID-10 из нескольких дисков? А лучше – всей машины в целом Используем файловую систему, поддерживающую freeze (xfs, утилита xfs_freeze; или на новых ядрах Linux и ext3/ext4 и механизм fsfreeze). Делаем freeze файловой системы (в случае MySQL правильно предварительно сделать FLUSH TABLES WITH READ LOCK). Делаем снэпшоты всех дисков. «Размораживаем» файловую систему. Для бэкапа файлов – достаточно, но если хотим быстро и удобно переезжать между AZ (Availability Zones), используем более высокий уровень абстракции и оперируем образами целых машин – AMI (Amazon Machine Image).

24. Масштабирование базы Для масштабирования только чтения используем master-slave репликацию Приложение умеет отправлять запросы на запись на master, а запросы на чтение – на slave. После запросов, изменяющих данные, в случае «отставания» slave – некоторое время чтение идет с мастера Веб-нода Балансировка SQL MySQL master MySQL slave

25. Если требуется масштабирование мастера MySQL Для вертикального масштабирования используем slave, потом переключаем его в master Мониторим состояние master через CloudWatch Есть slave – минимальной конфигурации – работающий в режиме только бэкапа При необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование) Останавливаем master, делаем slave мастером Переключаем IP (Amazon Elastic IP) на машину с новым мастером Веб-ноды не требуют переконфигурирования и продолжают работать без даунтайма Веб-нода Балансировка SQL Elastic IP CloudWatch MySQL slave MySQL master

26. Шардинг базы данных в рамках региона Аккаунтыa-m База данных MySQL 1 База данных MySQL 1 База данных MySQL База данных MySQL База данных MySQL 2 База данных MySQL 2 Аккаунты n-z Вертикальный шардинг Горизонтальный шардинг

27. Почему не RDS? У Amazon есть сервис RDS (Relational Database Service).Можно использовать MySQL или Oracle. Почему не стали использовать его? Недостаточно гибкая система (нет полноценного root в базе) Непрозрачно Риск долгого даунтайма (пример попадания молнии в европейский ДЦ в августе) Двойная стоимость машин при использовании Multi-AZ

28. Общая схема HTTP/HTTPS *.ru HTTP/HTTPS *.com HTTP/HTTPS *.com *.ru Elastic Load Balancing Elastic Load Balancing S3 Web 1 Web 2 Web N CloudWatch + AutoScaling Web 1 Web 2 Web N CloudWatch + AutoScaling … … cache cache cache cache cache cache MySQL master MySQL master CloudWatch CloudWatch MySQL slave MySQL slave master-master репликация management, monitoring

29. Надежность Один из приоритетов – постоянная доступность сервиса Внутри региона все веб-ноды не зависимы друг от друга, поднимаются в любой AZ (резервирование на случай аварии на уровне AZ) Реплика базы (slave) поднята в другой AZ Между регионами настроена master-master репликация В случае аварии на уровне целого региона: вDNS меняется IP – на балансировщик в другой зоне веб-ноды идентичны для каждого региона требуется поменять только адрес подключения к базе

30. Следите за нами! twitter.com/1C_Bitrix facebook.com/1CBitrix www.1c-bitrix.ru

31. Спасибо за внимание! Вопросы?