Опыт построения отказоустойчивой архитектуры и ее миграции

Опыт построения отказоустойчивой
архитектуры и ее миграции в Россию
Александр Демидов
«1С-Битрикс»
О чем поговорим
Построение отказоустойчивой архитектуры для высоконагруженного проекта на
примере сервиса «Битрикс24»
Первые технические предпосылки для миграции в Россию
Формирование требований к российским площадкам для миграции в
соответствие с законодательством
Построение архитектуры российской части сервиса и процесс миграции
как все начиналось…
«Битрикс24»
Есть несколько задач на старте и в процессе работы
Новый SaaS сервис – как коммерческие, так и «бесплатные» пользователи
Минимизация расходов на эксплуатацию и снижение финансовых рисков на
старте проекта
Масштабирование при росте нагрузки и обратное масштабирование
Надежность – обеспечение SLA
Работа с разными рынками: США, Европа, Россия
Выбор платформы для разворачивания инфраструктуры
Минусы размещения на собственном оборудовании:
Необходимы вложения в инфраструктуру на старте проекта
Сложность масштабирования
Сложность администрирования (в случае размещения в территориально удаленных
датацентрах)
Создание всех сопутствующих сервисов с нуля
«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить,
покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров –
таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы.
Оглядываясь назад, я думаю, что это было большой ошибкой»
Брет Тейлор
технический директор Facebook
Amazon Web Services
• Некоторый опыт работы с
Amazon
• Несколько территориально
распределенных ДЦ
• Большой выбор готовых
сервисов
Web – автоматическое масштабирование
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling
Очень высокая посещаемость
Elastic Load Balancing
Web 1
Web 2
…
CloudWatch + Auto Scaling
Web N
Web – автоматическое масштабирование
Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling
Автоматически стартуют новые машины, если средняя нагрузка CPU превышает заданный
верхний порог
Автоматически останавливаются и выводятся из эксплуатации, если средняя нагрузка
опускается ниже заданного нижнего порога
Специфика web-нод
Есть несколько задач, которые
необходимо решить:
На веб-нодах нет пользовательского
контента, все ноды должны быть
абсолютно идентичны.
Read only. Никакие пользовательские
данные не пишутся и не сохраняются
на веб-нодах, так как в любой момент
времени любая машина может быть
выключена или стартует новая из
«чистого» образа.
При этом необходимо обеспечить
изоляцию пользователей друг от
друга.
Статический контент пользователей сервиса
Статические данные пользователей храним
в S3
Загрузка осуществляется «прозрачно» для
пользователей – они работают с
привычными интерфейсами
Правильно формируются url’ы к картинкам,
документам и т.п.
Для каждого созданного Корпоративного
портала создается персональный аккаунт –
данные каждого КП полностью
изолированы друг от друга
Готов только первый «двигатель самолета»
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Elastic
Load Balancing
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Используем master-master репликацию в MySQL
Особенности настройки MySQL:
auto_increment_increment
auto_increment_offset
Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря
связности между датацентрами может составлять часы, данные синхронизируются
после восстановления.
В любое время можно добавить новые датацентры.
Пользователь и все сотрудники этой компании работают в одном датацентре.
Сценарий: авария на одной или нескольких веб-нодах
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Сценарий: авария на одной или нескольких веб-нодах
Load Balancing определяет вышедшие из строя машины
Исходя из заданных параметров группы балансировки, автоматически
восстанавливается нужное количество машин
Сценарий: авария на одной или нескольких веб-нодах
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Сценарий: плановые работы с базой или авария всего ДЦ
Elastic
Load Balancing
Web 1
Web 2
Датацентр 1 в
регионе US East
(Virginia)
…
Web N
MySQL
master
S3
master-master
репликация
Web 1
MySQL
master
Web 2
…
Web N
Датацентр 2 в
регионе US East
(Virginia)
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
Мониторинг и
масштабирование –
CloudWatch +
AutoScaling
management,
monitoring,
MySQL backup
Сценарий: авария или плановые работы с базой
Весь траффик переключается в один работающий датацентр
CloudWatch определяет возросшую нагрузку на машины и добавляет их в
соответствие с правилами для AutoScaling
Приостанавливается мастер-мастер репликация
Проводятся все необходимые работы с базой, на которую не идет нагрузка
База включается в работу, восстанавливается репликация
Траффик распределяется на оба датацентра
Гасятся лишние машины, если средняя нагрузка стала ниже порогового значения
Архитектура Битрикс24
Static
HTTPS
*.com/*.de
Static
HTTPS
*.ru
js, css
Elastic Load Balancing
Web 1
Web 2
local
cache
(APC)
local
cache
(APC)
CloudWatch
+
AutoScaling
…
mysqld
control cache: memcached
js, css
Elastic Load Balancing
Web 2
local
cache
(APC)
local
cache
(APC)
local
cache
(APC)
S3
mysqld
master-master replication
mysqld
master-master replication
control cache: memcached
mysqld
mysqld
mysqld
control cache: memcached
CloudWatch
+
AutoScaling
…
local
cache
(APC)
mysqld
mysqld
mysqld
mysqld
mysqld
control cache: memcached
management,
monitoring,
backup
Web N
mysqld
mysqld
mysqld
control cache: memcached
CDN (CDNvideo)
Web 1
master-master replication
mysqld
Dynamic
HTTPS
*.ru
Web N
mysqld
mysqld
images (clients)
CDN (Amazon CloudFront)
images (clients)
Dynamic
HTTPS
*.com/*.de
mysqld
control cache: memcached
Один из приоритетов –
постоянная доступность сервиса,
его отказоустойчивость.
Все веб-ноды идентичны и не
зависимы друг от друга, в случае
аварии автоматически стартуют
новые.
Два датацентра синхронизированы
друг с другом и равноценно
обслуживают клиентов. В случае
аварии на уровне датацентра или
плановых работ с базой, траффик
прозрачно для клиентов
переключается на рабочий
датацентр.
Первые предпосылки к переезду: технические
Возросшие требования к скорости работы порталов:
развитие Битрикс24.Диска, скорость отклика,
мобильное приложение, real-time чаты, уведомления
и т.д. Сетевая связность стала иметь большое
значение.
Два новых ДЦ – в Ирландии
Продублировали инфраструктуру (базы, пулинг, autoscaling и security группы, серверы бэкапов и т.д.)
Свой API для работы с Route53
Без даунтайма для клиентов!
Государство начинает регулировать
интернет.
Но есть ли в этом что-то необычное?
Когда какая-то сфера бизнеса
становится важной для государства,
граждан - государство начинает
регулировать ее.
Избегайте эмоциональной оценки в
этом вопросе.
Почему нужно регулировать интернет с
точки зрения государства?
•
Растет количество преступлений, потеря
персональных данных, похищение банковских
данных, промышленный и государственный
шпионаж.
•
Интернет стал обязательной частью работы
государственных структур, социнститутов,
функционирования бизнеса.
•
Регулировать интернет проблематично, но
необходимо, и государство будет искать способ, как
его отрегулировать.
•
Граждане плохо реагируют на ограничение интернета,
но легко соглашаются после терактов или больших
скандалов с потерей персональной информации.
•
Так происходит не только у нас, а во всем мире.
242-ФЗ вступил в силу на территории России
1 сентября 2015 г.
242-ФЗ
Закон: №242-ФЗ «О внесении изменений в отдельные
законодательные акты РФ в части уточнения порядка обработки
персональных данных в информационно-телекоммуникационных
сетях» от 21 июля 2014 года.
Суть: с 1 сентября 2015 года компании обяжут хранить персональные
данные в базах данных, расположенных только на территории РФ. О
месте хранения таких баз данных нужно уведомлять Роскомнадзор.
•
При этом не запрещается трансграничная передача данных при условии,
что первичный сбор и хранение данных осуществляется на территории
России.
•
В законе предусмотрены исключения. К примеру, персональные данные
россиян могут обрабатываться на территории иностранных государств в
целях исполнения правосудия, исполнения полномочий органов
государственной власти и местного самоуправления, для достижения
целей, предусмотренных международным договором. (Роскомнадзор,
rkn.gov.ru, 13 февраля 2015 г.)
Доброе слово и пистолет делают
больше, чем просто доброе слово…
• В законе много неясностей с
формулировками, но это не так важно.
• Важно то, что сказано по смыслу - вы
должны перевезти серверы в Россию.
В качестве аргумента выбрали
персональные данные.
Риски: Великий Китайский Фаервол
•
20 апреля 1994 года было создано первое кабельное интернетсоединение из Китая в Северную Америку и Европу.
•
Спустя несколько лет китайское правительство начало работу
над ограничением этого нового вида связи.
•
В конце 2003 знаменитый Великий Китайский Фаервол начал
свою работу, за последние десять лет система контроля
разрослась до невиданных масштабов.
В Китае заблокированы:
Twitter, Facebook, Instagram, Google+, YouTube,
Google Play, поисковик Google, Microsoft OneDrive,
Dropbox, Slideshare, Google Drive, Google Docs,
Gmail, Google Translate, Google Calendar, Flickr и
многое другое.
http://habrahabr.ru/
http://www.ted.com/talks/michael_anti_behind_the_great_firewall_of_china
Риски: стоимость хостинга зависит от курсов валют
Стоимость хостинга плохо
прогнозируема
Варианты:
1. Забить.
2. А давайте попробуем всех обмануть 
Сделаем туннель/прокси: возьмем
российский IP, сделаем прокси к западным
серверам и там оставим персональные
данные.
3. Деперсонализировать
Разместим часть данных в России, а не перс.
данные могут остаться и не в РФ.
4. Полностью переехать.
А как будете поступать вы?
225+ стран и территорий
Архитектура Битрикс24
Количество серверов:
• 25-40 - в США
• 35-75 - в Европе
(в зависимости от автомасштабирования)
RTT (Round Trip Time) - время между
отправкой запроса и получением ответа от
сервера:
• США - 130 миллисекунд
• Европа - 70 миллисекунд
• Россия - 5-10 миллисекунд
Территориальные балансировщики
Минимальный RTT
SSL – A+ (ssllabs.com)
Поддержка SPDY для
клиентов
SSL keep alive на бэкенды
Раздельный кэш для общей
статики, пользовательской
статики, композитных
хитов
Работа с территориально
распределенными
бэкендами
В результате – отдельный
продукт «Веб-акселератор»
Как мы выбирали провайдера
1. Первый принципиальный вопрос – это
выбор между размещением на
физическом оборудовании (неважно, это
будут наши собственные серверы или
арендованные) или же на уже развернутой
у провайдера виртуальной инфраструктуре
(по сути – IaaS).
2. Во-вторых, нам было важно, чтобы
провайдер имел как минимум 2 ДЦ для
резервирования на уровне датацентра,
чтобы мы могли строить такую же
структуру, как и раньше.
3. Выбор гипервизора. Коммерческий или
некоммерческий?
Наши требования к «облаку»
• Виртуальные машины с произвольной конфигурацией дисков.
• Динамическая тарификация.
• Наличие API: стоп/старт машин, подключить/отключить диски,
назначить внешний IP и т.д.
• Снэпшоты дисков и целые образы виртуальных машин.
• Балансировщики Level 7 , DNS, Firewall, горизонтальное
масштабирование, сервисы очередей и т.д.
Выбирая провайдера, мы понимали, что в России мы не найдем
полного соответствия нашим требованиям. В любом случае,
придется самим дорабатывать-дописывать, и вот тут важно, чтобы
дорабатывать пришлось не на 70%, а на 20-30%.
А что Amazon?
Мы общались с Amazon, но пока они не открывают ДЦ в
России. Microsoft – тоже самое. Пока у Amazon не будет все
готово для открытия – не анонсируют. В Германии – они
сделали анонс, только когда открыли ДЦ.
Amazon размышляют, продумывают разные стратегии.
Вариантов несколько:
• Будут присутствовать на российском рынке
• Не будут присутствовать, но будут помогать разрабатывать
стратегии.
Мы подумали, что мы не можем рисковать и надеяться на
скорое открытие ДЦ Amazon. Решили, что будем искать уже
существующую площадку.
Перечень провайдеров IaaS, среди которых
проводится исследование «Mystery shopping» компанией
Этапы переезда
• Первый – перенос балансировщика: решили
техническую задачу по увеличению скорости
доступа для клиентов, появилась точка входа в
России, для клиентов стало значительно
быстрее. Отвязывались от балансировщика
Amazon.
• Второй – тестовая, но полностью рабочая
инфраструктура в России. Порталы партнеров,
тестирование, отладка.
• Третий – горизонтальное масштабирование
инфраструктуры, перенос всех клиентов.
• Четвертый – начало регистрации новых
клиентов уже в РФ.
Наш рецепт построения высоконагруженной
отказоустойчивой системы
Правильное облако + …
Несколько территориально распределенных
ДЦ (с возможностью их выбора)
Гибкое управление дисками
Облачные базы данных, кэш, NoSQL,
балансировщики, DNS, мониторинг, сервисы
очередей, файловые хранилища, CDN и т.д.
API и готовые SDK для управления всеми
сервисами
… + готовность приложения к масштабированию
До ~200
виртуальных
серверов + доп.
сервисы: S3, SQS,
CloudFront, Route
53, DynamoDB,
Kinesis.
Три человека – у
которых админство
не является
единственной
деятельностью.
Спасибо за внимание! Вопросы?
Александр Демидов
[email protected]