Проектируем облачный веб-сервис "по-взрослому" (Сергей Рыжиков)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как делать бэкап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).

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

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

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

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

Общая схемаHTTP/HTTPS*.ruHTTP/HTTPS*.comHTTP/HTTPS*.com*.ruElasticLoad BalancingElasticLoad BalancingS3Web 1Web 2Web NCloudWatch + AutoScalingWeb 1Web 2Web NCloudWatch + AutoScaling……cachecachecachecachecachecacheMySQLmasterMySQLmasterCloudWatchCloudWatchMySQLslaveMySQLslavemaster-master репликацияmanagement, monitoring

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

Следите за нами!twitter.com/1C_Bitrixfacebook.com/1CBitrixwww.1c-bitrix.ru

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

Проектируем облачный веб-сервис "по-взрослому" (Сергей Рыжиков)

More Related Content

What's hot (20)

Similar to Проектируем облачный веб-сервис "по-взрослому" (Сергей Рыжиков) (20)

More from Ontico (20)

Проектируем облачный веб-сервис "по-взрослому" (Сергей Рыжиков)