Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,957 views

Published on

  • Be the first to comment

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

  1. 1. Проектируем облачныйвеб-сервис «по-взрослому»<br />Сергей Рыжиков<br />генеральный директор компании «1С-Битрикс»<br />
  2. 2. Запускаем новый SaaSпродуктBitrix24<br />Есть несколько задач на старте и в процессе работы<br />Новый SaaSсервис – как коммерческие, так и «бесплатные» пользователи<br />Минимизация расходов на эксплуатацию и снижение финансовых рисков на старте проекта<br />Масштабирование при росте нагрузки и обратное масштабирование<br />Надежность – обеспечение SLA<br />Работа с разными рынками: США, Европа, Россия<br />Быстрая отдача статического контента<br />
  3. 3. Из «бизнес-требований» появились технические<br />Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)<br />Большой объем базы данных –шардинг – возможность разделить базу данных по территории и группам клиентов<br />MultiTenancyархитектура<br />Полное разделение логики (кода продукта) и данных<br />Пользовательские данные – это большой объем статических файлов и база данных<br />Универсальный API платформы для многолетней разработки<br />Динамическое масштабирование по нагрузке<br />Две итоговые задачи:<br />Выбор технической платформы для инфраструктуры<br />Выбор платформы разработки<br />
  4. 4. Традиционное устройство<br />веб-продуктов<br />Веб-приложение <br />Кэширование<br />на диск<br />База данных<br />Обычный продут не поддерживает гео веб-кластер, облачные файлы, распределенное кэширование, multitenancy…<br />
  5. 5. Облачная платформа: веб-кластер<br />Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)<br />Репликация MySQLи балансирование нагрузки между серверами<br />Распределенный кешданных (memcached)<br />Непрерывность сессий между веб-серверами (хранение сессий в базе данных)<br />Кластеризация веб-сервера:<br />Синхронизация файлов (это – проблема для облачного сервиса)<br />Балансирование нагрузки между серверами<br />
  6. 6. 1-ый этап реализации<br />Балансировщик (клиентские запросы по HTTP)<br />Веб-сервер 1<br />Веб-сервер 2<br />memcached 1<br />memcached2<br />MySQL<br />master<br />MySQL<br />slave<br />
  7. 7. 2-ой этап – гео веб-кластер<br />Асинхронная master-master репликация для обеспечения работы географически распределенных веб-кластеров.<br />Потеря связи между ДЦ может составлять часы.<br />«Веб-кластер», ДЦ в России<br />«Веб-кластер», ДЦ в США<br />Веб-нода<br />Веб-нода<br />Веб-нода<br />Веб-нода<br />Веб-нода<br />Веб-нода<br />Кэш<br />Кэш<br />Кэш<br />Кэш<br />Кэш<br />Кэш<br />«Веб-кластер», ДЦ в Германии<br />БД<br />БД<br />БД<br />БД<br />БД<br />БД<br />Веб-нода<br />Веб-нода<br />Веб-нода<br />Кэш<br />Кэш<br />Кэш<br />БД<br />БД<br />БД<br />
  8. 8. Облачное хранилище<br />файлов<br />ДЦ в США<br />Посетители<br />Веб-сервер<br />Веб-сервера<br />Веб-серверы<br />ДЦ в России<br />Веб-сервер<br />Веб-сервера<br />Веб-серверы<br />Веб-приложение<br />Облачное хранилище файлов (Amazon S3, Azure, Google Storage, OpenStack Swift) + CDN<br />БД (master)<br />Веб-приложение<br />slave<br />БД (master)<br />slave<br />
  9. 9. Из «бизнес-требований» появились технические<br />Отказоустойчивость – умение размещаться сразу в нескольких разных территориально распределенных датацентрах (в разных странах)<br />Большой объем базы данных –шардинг – возможность разделить базу данных по территории и группам клиентов<br />MultiTenancyархитектура<br />Полное разделение логики (кода продукта) и данных<br />Пользовательские данные – это большой объем статических файлов и база данных<br />Универсальный API платформы для многолетней разработки<br />Динамическое масштабирование по нагрузке<br />
  10. 10. Выбор платформыдля разворачивания инфраструктуры<br />Минусы размещения на собственном оборудовании:<br />Необходимы вложения в инфраструктуру на старте проекта<br />Сложность масштабирования<br />Сложность администрирования (в случае размещения в территориально удаленных датацентрах)<br />Создание всех сопутствующих сервисов с нуля<br />«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверыили же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой»<br />Брет Тейлор<br />технический директор Facebook<br />
  11. 11. Используем AWS:<br />Amazon Web Services<br />У нас есть успешный опыт работы с Amazon (сайт www.1c-bitrix.ruи другие сайты компании). В Amazon много дополнительных сервисов, которые помогают решить наши задачи.<br />Всю архитектуру строим из «кирпичиков» – сервисов AWS.<br />
  12. 12. Используем все возможности масштабирования в Amazon – исходя из экономики проекта.<br />
  13. 13. Статический контент пользователей сервиса<br />Для хранения и отдачи статического контента пользователей сервиса используем Amazon S3 (Simple Storage Service)<br />Любое количество объектов (до 5 Тб каждый)<br />Возможность размещения в разных датацентрах (регионах)<br />Группировка объектов<br />Механизмы авторизации<br />REST и SOAP интерфейсы для работы с объектами<br />Высокая доступность<br />Низкая цена (по сравнению с EBS)<br />
  14. 14. Статический контент пользователей сервиса<br />Какие задачи решаем, используя S3?<br />Снижаем стоимость эксплуатации<br />Можем использовать совместно с CDN для ускорения отдачи контента<br />Снижаем нагрузку на web-узлы<br />Используя централизованное хранилище, решаем задачу синхронизации контента между множественными web-узлами<br />Разделяем пользовательские данные и код<br />
  15. 15. Web<br />Используем связку Elastic Load Balancing + CloudWatch+ Auto Scaling<br />Очень высокая посещаемость<br />Elastic Load Balancing<br />CloudWatch + Auto Scaling<br />Web 1<br />Web 2<br />…<br />Web N<br />
  16. 16. Web<br />Используем связку Elastic Load Balancing + CloudWatch+ Auto Scaling<br />Все клиентские запросы (HTTP и HTTPS) поступают на балансировщикAmazon<br />При росте нагрузки (и обратно) используем горизонтальное (а не вертикальное) масштабирование. Для каждой отдельной веб-ноды можем использовать хоть micro instance, а управлять – их количеством.<br />Рост и снижение нагрузки мониторим через CloudWatchдвумя путями – состояние нод (EC2) и балансировщика.<br />Все ноды – абсолютно идентичны. Каждая новая нода поднимается из заранее созданного образа (AMI). Любая веб-нода может обслуживать любого клиента.<br />
  17. 17. Web<br />Используем связку Elastic Load Balancing + CloudWatch+ Auto Scaling<br />Мы задаем в конфигурации минимально необходимое количество машин. В случае сбоев или аварий машина помечается «плохой», гасится, и поднимается новый instance.<br />Балансировщик умеет распределять нагрузку между разными AZ. Можем держать машины в разных зонах на случай аварии уровня AZ.<br />
  18. 18. Обновления ПО на web-нодах<br />Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)<br />Сервер обновлений<br />Новый образ AMI<br />Web 1<br />Elastic<br />Load Balancing<br />Web 2<br />Web N<br />
  19. 19. Обновления ПО на web-нодах<br />Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)<br />Каждое клиентское приложение работает с собственной базой.<br />Все обновления ставятся на выделенный instance, куда не приходит нагрузка.<br />Из этого инстанса делается новый образ AMI.<br />Последовательно каждая машина помечается «плохой», при этом новые веб-ноды стартуют уже из нового образа.<br />В веб-приложении существует механизм проверки соответствия версии ПО и базы.<br />Если клиентский запрос приходит на ноду с новым ПО, а база еще старая, по первому хиту происходит обновление.<br />
  20. 20. Специфика web-нод<br />На веб-нодах нет пользовательского контента, все ноды абсолютно идентичны. При этом необходимо обеспечить изоляцию пользователей<br />У каждого клиента свой домен<br />Был разработан модуль для PHP:<br />проверяет корректность HTTP_HOST, завершает хит с ошибкой, если имя некорректно<br />устанавливает соединение с нужной базой в зависимости от HTTP_HOST<br />авторизация внутри приложения определяется непосредственно логикой самого приложения<br />
  21. 21. Конфигурация машин<br />с базами MySQL<br />Виртуальная машина (EC2) - High-Memory Extra Large Instance – 17.1 Gb RAM<br />«Узким» местом может оказаться производительность дисковой системы. Решение – из EBS дисков Amazon можно построить software RAID.<br />Выбираем RAID-10, так как он и быстрый, и надежный.<br />
  22. 22. Как определить конфигурацию RAID?<br />Любое решение выбирается, исходя из конкретной поставленной задачи.<br />Для работы MySQL используем InnoDB. Следовательно, необходимо эффективно работать с операциями random read/write на больших файлах (ibdata).<br />Тесты sysbench<br />Работы с одиночным файлом 16 Гб в режиме random read/write.<br />При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет.<br />
  23. 23. Как делать бэкапRAID-10?<br />Для Amazon EC2 есть удобный механизм snapshot’ов. Как сделать целостный бэкапRAID-10 из нескольких дисков? А лучше – всей машины в целом<br />Используем файловую систему, поддерживающую freeze (xfs, утилита xfs_freeze; или на новых ядрах Linux и ext3/ext4 и механизм fsfreeze).<br />Делаем freeze файловой системы (в случае MySQL правильно предварительно сделать FLUSH TABLES WITH READ LOCK).<br />Делаем снэпшоты всех дисков.<br />«Размораживаем» файловую систему.<br />Для бэкапа файлов – достаточно, но если хотим быстро и удобно переезжать между AZ (Availability Zones), используем более высокий уровень абстракции и оперируем образами целых машин – AMI (Amazon Machine Image).<br />
  24. 24. Масштабирование базы<br />Для масштабирования только чтения используем master-slave репликацию<br />Приложение умеет отправлять запросы на запись на master, а запросы на чтение – на slave. После запросов, изменяющих данные, в случае «отставания» slave – некоторое время чтение идет с мастера<br />Веб-нода<br />Балансировка SQL<br />MySQL<br />master<br />MySQL<br />slave<br />
  25. 25. Если требуется масштабирование мастера MySQL<br />Для вертикального масштабирования используем slave, потом переключаем его в master<br />Мониторим состояние master через CloudWatch<br />Есть slave – минимальной конфигурации – работающий в режиме только бэкапа<br />При необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование)<br />Останавливаем master, делаем slave мастером<br />Переключаем IP (Amazon Elastic IP) на машину с новым мастером<br />Веб-ноды не требуют переконфигурирования и продолжают работать без даунтайма<br />Веб-нода<br />Балансировка SQL<br />Elastic IP<br />CloudWatch<br />MySQL<br />slave<br />MySQL<br />master<br />
  26. 26. Шардинг базы данных в рамках региона<br />Аккаунтыa-m<br />База данных MySQL 1<br />База данных MySQL 1<br />База данных MySQL<br />База данных MySQL<br />База данных MySQL 2<br />База данных MySQL 2<br />Аккаунты n-z<br />Вертикальный шардинг<br />Горизонтальный шардинг<br />
  27. 27. Почему не RDS?<br />У Amazon есть сервис RDS (Relational Database Service).Можно использовать MySQL или Oracle. Почему не стали использовать его?<br />Недостаточно гибкая система (нет полноценного root в базе)<br />Непрозрачно<br />Риск долгого даунтайма (пример попадания молнии в европейский ДЦ в августе)<br />Двойная стоимость машин при использовании Multi-AZ<br />
  28. 28. Общая схема<br />HTTP/HTTPS<br />*.ru<br />HTTP/HTTPS<br />*.com<br />HTTP/HTTPS<br />*.com<br />*.ru<br />Elastic<br />Load Balancing<br />Elastic<br />Load Balancing<br />S3<br />Web 1<br />Web 2<br />Web N<br />CloudWatch + AutoScaling<br />Web 1<br />Web 2<br />Web N<br />CloudWatch + AutoScaling<br />…<br />…<br />cache<br />cache<br />cache<br />cache<br />cache<br />cache<br />MySQL<br />master<br />MySQL<br />master<br />CloudWatch<br />CloudWatch<br />MySQL<br />slave<br />MySQL<br />slave<br />master-master репликация<br />management, monitoring<br />
  29. 29. Надежность<br />Один из приоритетов – постоянная доступность сервиса<br />Внутри региона все веб-ноды не зависимы друг от друга, поднимаются в любой AZ (резервирование на случай аварии на уровне AZ)<br />Реплика базы (slave) поднята в другой AZ<br />Между регионами настроена master-master репликация<br />В случае аварии на уровне целого региона:<br />вDNS меняется IP – на балансировщик в другой зоне<br />веб-ноды идентичны для каждого региона<br />требуется поменять только адрес подключения к базе<br />
  30. 30. Следите за нами!<br />twitter.com/1C_Bitrix<br />facebook.com/1CBitrix<br />www.1c-bitrix.ru<br />
  31. 31. Спасибо за внимание!<br />Вопросы?<br />

×