Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•Download as PPTX, PDF•
•
1 of 31
Проектируем облачныйвеб-сервис «по-взрослому»Сергей Рыжиковгенеральный директор компании «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

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

  • 1. Проектируем облачныйвеб-сервис «по-взрослому»Сергей Рыжиковгенеральный директор компании «1С-Битрикс»
  • 2. Запускаем новый SaaSпродуктBitrix24Есть несколько задач на старте и в процессе работыНовый SaaSсервис – как коммерческие, так и «бесплатные» пользователиМинимизация расходов на эксплуатацию и снижение финансовых рисков на старте проектаМасштабирование при росте нагрузки и обратное масштабированиеНадежность – обеспечение SLAРабота с разными рынками: США, Европа, РоссияБыстрая отдача статического контента
  • 3. Из «бизнес-требований» появились техническиеОтказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)Большой объем базы данных –шардинг – возможность разделить базу данных по территории и группам клиентовMultiTenancyархитектураПолное разделение логики (кода продукта) и данныхПользовательские данные – это большой объем статических файлов и база данныхУниверсальный API платформы для многолетней разработкиДинамическое масштабирование по нагрузкеДве итоговые задачи:Выбор технической платформы для инфраструктурыВыбор платформы разработки
  • 4. Традиционное устройствовеб-продуктовВеб-приложение Кэшированиена дискБаза данныхОбычный продут не поддерживает гео веб-кластер, облачные файлы, распределенное кэширование, multitenancy…
  • 5. Облачная платформа: веб-кластерВертикальный шардинг (вынесение модулей на отдельные серверы MySQL)Репликация MySQLи балансирование нагрузки между серверамиРаспределенный кешданных (memcached)Непрерывность сессий между веб-серверами (хранение сессий в базе данных)Кластеризация веб-сервера:Синхронизация файлов (это – проблема для облачного сервиса)Балансирование нагрузки между серверами
  • 6. 1-ый этап реализацииБалансировщик (клиентские запросы по HTTP)Веб-сервер 1Веб-сервер 2memcached 1memcached2MySQLmasterMySQLslave
  • 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 BalancingCloudWatch + Auto ScalingWeb 1Web 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-нодахКак ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)Сервер обновленийНовый образ AMIWeb 1ElasticLoad BalancingWeb 2Web 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 – некоторое время чтение идет с мастераВеб-нодаБалансировка SQLMySQLmasterMySQLslave
  • 25. Если требуется масштабирование мастера MySQLДля вертикального масштабирования используем slave, потом переключаем его в masterМониторим состояние master через CloudWatchЕсть slave – минимальной конфигурации – работающий в режиме только бэкапаПри необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование)Останавливаем master, делаем slave мастеромПереключаем IP (Amazon Elastic IP) на машину с новым мастеромВеб-ноды не требуют переконфигурирования и продолжают работать без даунтаймаВеб-нодаБалансировка SQLElastic IPCloudWatchMySQLslaveMySQLmaster
  • 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*.ruHTTP/HTTPS*.comHTTP/HTTPS*.com*.ruElasticLoad BalancingElasticLoad BalancingS3Web 1Web 2Web NCloudWatch + AutoScalingWeb 1Web 2Web NCloudWatch + AutoScaling……cachecachecachecachecachecacheMySQLmasterMySQLmasterCloudWatchCloudWatchMySQLslaveMySQLslavemaster-master репликацияmanagement, monitoring
  • 29. НадежностьОдин из приоритетов – постоянная доступность сервисаВнутри региона все веб-ноды не зависимы друг от друга, поднимаются в любой AZ (резервирование на случай аварии на уровне AZ)Реплика базы (slave) поднята в другой AZМежду регионами настроена master-master репликацияВ случае аварии на уровне целого региона:вDNS меняется IP – на балансировщик в другой зоневеб-ноды идентичны для каждого регионатребуется поменять только адрес подключения к базе