1. Архитектура
и
запуск
облачного
сервиса
в
Amazon
AWS.
Как
обеспечить
реальные
24?
Сергей
Рыжиков
генеральный
директор
компании
«1С-­‐Битрикс»

2. Цель
на
2012
год
Задача
для
компании
в
2012
году
–
запустить
в
коммерческую
эксплуатацию
«Битрикс24»
• Аренда
Корпоративного
портала
как
инструмента
социального
интранета
• Развитие
социального
Project-­‐
и
Task-­‐менеджмента
• Развитие
Social
CRM
-­‐
готового,
простого
в
использовании
решения
• Собрать
и
накопить
опыт
по
эксплуатации
облачных
веб-­‐
сервисов,
поделиться
им
с
партнерами

3. Битрикс24

4. Битрикс24

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

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

7. Независимые
факторы
надежности
Человечество
уже
сделало
определенный
путь
для
обеспечения
независимых
факторов
надежности.
Для
«Битрикс24»
нужен
аналогичный
подход
–
продолжать
работу
без
потери
данных
в
случае
выхода
из
строя
одного
ДЦ
и
быть
способными
восстанавливать
базы
данных
за
несколько
минут.

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

9. 1
этап
:
Веб-­‐кластер
Балансировщик
(клиентские
запросы
по
HTTP)
Веб-­‐сервер
1
Веб-­‐сервер
2
MySQL
MySQL
memcached
1
memcached
2
master
slave

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

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

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

13. Платформа
для
разработки
облачных
веб-­‐сервисов
• В
версии
10.
0
реализована
поддержка
веб-­‐кластера.
• В
версии
11.0
–
географический
веб-­‐кластер
master-­‐master.
• В
версии
11.0
–
поддержка
облачных
хранилищ,
тайм-­‐зон,
автомасштабирования.
• В
2011
году
разработана
облачная
архитектура
эксплуатации
в
Амазоне.
• Накоплен
опыт
работы
в
Амазоне
,
опыт
эксплуатации
и
особенности
работы
в
облачной
инфраструктуре.
• В
конце
2011
г
была
запущена
первая
опытная
версия
сервиса
«Битрикс24».

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

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

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

17. Архитектура
«Битрикс24»
ElasZc
Load
Balancing
… …
Web
1
Web
2
Web
N
S3
Web
1
Web
2
Web
N
Датацентр
1
в
MySQL
MySQL
Датацентр
2
в
регионе
US
East
master
master
регионе
US
East
master-­‐master
(Virginia)
репликация
(Virginia)
Мониторинг
и
Мониторинг
и
масштабирование
–
масштабирование
–
CloudWatch
+
CloudWatch
+
AutoScaling
AutoScaling
management,
monitoring,
MySQL
backup

18. Web
–
автоматическое
масштабирование
Используем
связку
Elaswc
Load
Balancing
+
CloudWatch
+
Auto
Scaling
Очень
высокая
посещаемость
ElasZc
Load
Balancing
…
Web
1
Web
2
Web
N
CloudWatch
+
Auto
Scaling

19. Web
–
автоматическое
масштабирование
Используем
связку
Elaswc
Load
Balancing
+
CloudWatch
+
Auto
Scaling
" Автоматически
стартуют
новые
машины,
если
средняя
нагрузка
CPU
превышает
60%
" Автоматически
останавливаются
и
выводятся
из
эксплуатации,
если
средняя
нагрузка
менее
30%
" Ставили
верхний
порог
на
80%,
однако
начинается
общая
деградация
системы
–
пользователям
работать
некомфортно
(долго
загружаются
страницы)

20.
Специфика
веб-­‐нод
Есть
несколько
задач,
которые
необходимо
решить:
• На
веб-­‐нодах
нет
пользовательского
контента,
все
ноды
должны
быть
абсолютно
идентичны.
• Read
only.
Никакие
пользовательские
данные
не
пишутся
и
не
сохраняются
на
веб-­‐нодах,
так
как
в
любой
момент
времени
любая
машина
может
быть
выключена
или
стартует
новая
из
«чистого»
образа.
• При
этом
необходимо
обеспечить
изоляцию
пользователей
друг
от
друга.

21.
Специфика
веб-­‐нод
• Нет
Apache.
Есть
PHP-­‐FPM
+
nginx
• У
каждого
клиента
свой
домен
• Был
разработан
модуль
для
PHP:
• проверяет
корректность
домена,
завершает
хит
с
ошибкой,
если
имя
некорректно
• устанавливает
соединение
с
нужной
базой
в
зависимости
от
домена
• обеспечивает
безопасность
и
изоляцию
пользователей
друг
от
друга
• служит
для
шардинга
данных
разных
пользователей
по
разным
базам

22. Bitrix24
-­‐
cвой
модуль
для
PHP
• Обеспечивает
переопределние
функции
соединения
с
базой
данных.
• В
отдельной
таблице
хранит
строки
соединения
с
разными
мастерами
и
«слейвами»,
обслуживающими
БД.
• Позволяет
выполнять
горизонтальное
масштабирование
БД
(шардинг)
по
любому
количеству
серверов
вплоть
до
«один
клиент
на
одном
сервере».
• Обеспечивает
запуск
(fork)
процессов
для
PHP
и
быструю
отдачу
страницы
пользователю.

23. Статический
контент
пользователей
сервиса
" Статические
данные
пользователей
храним
в
S3.
" Загрузка
осуществляется
«прозрачно»
для
пользователей
–
они
работают
с
привычными
интерфейсами.
" Правильно
формируются
url’ы
к
картинкам,
документам
и
т.п.
" Для
каждого
созданного
Корпоративного
портала
создается
персональный
аккаунт
–
данные
каждого
КП
полностью
изолированы
друг
от
друга.

24. Полная
изоляция
данных
• Данные
одной
компании
полностью
изолированы
от
данных
другой.
• Для
каждого
клиента
данные
хранятся
раздельно:
o свой
логин
пароль
к
БД
o своя
БД
со
структурой
таблиц
o свое
облачное
хранилище
S3
с
отдельным
логином/
паролем
o отдельное
пространство
для
кеширования
данных
• Все
веб-­‐ноды
могут
обслуживать
любых
клиентов,
набор
данных
определяется
по
домену
и
не
может
быть
изменен.

25. Готов
только
первый
«двигатель
самолета»
ElasZc
ElasZc
Load
Balancing
Load
Balancing
… …
Web
1
Web
2
Web
N
S3
Web
1
Web
2
Web
N
Датацентр
1
в
MySQL
MySQL
Датацентр
2
в
регионе
US
East
master
master
регионе
US
East
master-­‐master
(Virginia)
репликация
(Virginia)
Мониторинг
и
Мониторинг
и
масштабирование
–
масштабирование
–
CloudWatch
+
CloudWatch
+
AutoScaling
AutoScaling
management,
monitoring,
MySQL
backup

26. Используем
master-­‐master
репликацию
в
MySQL
• Особенности
настройки
MySQL:
• auto_increment_increment
• auto_increment_offset
• Базы
в
разных
датацентрах
синхронны,
при
этом
независимы
друг
от
друга:
потеря
связности
между
датацентрами
может
составлять
часы,
данные
синхронизируются
после
восстановления.
• В
любое
время
можно
добавить
новые
датацентры.
• Пользователь
и
все
сотрудники
этой
компании
работают
в
одном
датацентре
за
счет
управления
балансировщиком.
• Сессии
храним
в
базе,
но
не
реплицируем
между
серверами
из-­‐за
большого
траффика:
• SET
sql_log_bin
=
0
…
или
…
• replicate-­‐wild-­‐ignore-­‐table
=
%.b_sec_session%

27. Сценарий
1:
авария
на
одной
или
нескольких
веб-­‐нодах
ElasZc
Load
Balancing
… …
Web
1
Web
2
Web
N
S3
Web
1
Web
2
Web
N
Датацентр
1
в
MySQL
MySQL
Датацентр
2
в
регионе
US
East
master
master
регионе
US
East
master-­‐master
(Virginia)
репликация
(Virginia)
Мониторинг
и
Мониторинг
и
масштабирование
–
масштабирование
–
CloudWatch
+
CloudWatch
+
AutoScaling
AutoScaling
management,
monitoring,
MySQL
backup

28. Сценарий
1:
авария
на
одной
или
нескольких
веб-­‐нодах
" Load
Balancing
определяет
вышедшие
из
строя
машины.
" Исходя
из
заданных
параметров
группы
балансировки,
автоматически
восстанавливается
нужное
количество
машин.

29. Сценарий
1:
авария
на
одной
или
нескольких
веб-­‐нодах
ElasZc
Load
Balancing
… …
Web
1
Web
2
Web
N
S3
Web
1
Web
2
Web
N
Датацентр
1
в
MySQL
MySQL
Датацентр
2
в
регионе
US
East
master
master
регионе
US
East
master-­‐master
(Virginia)
репликация
(Virginia)
Мониторинг
и
Мониторинг
и
масштабирование
–
масштабирование
–
CloudWatch
+
CloudWatch
+
AutoScaling
AutoScaling
management,
monitoring,
MySQL
backup

30. Сценарий
2:
потеря
связности
между
датацентрами
ElasZc
ElasZc
ElasZc
Load
Balancing
Load
Balancing
Load
Balancing
… …
Web
1
Web
2
Web
N
S3
Web
1
Web
2
Web
N
Датацентр
1
в
MySQL
MySQL
Датацентр
2
в
регионе
US
East
master
master
регионе
US
East
master-­‐master
(Virginia)
репликация
(Virginia)
Мониторинг
и
Мониторинг
и
масштабирование
–
масштабирование
–
CloudWatch
+
CloudWatch
+
AutoScaling
AutoScaling
management,
monitoring,
MySQL
backup

31. Сценарий
2:
потеря
связности
между
датацентрами
" Каждый
датацентр
продолжает
обслуживать
свой
сегмент
клиентов.
" Данные
синхронизируются
после
восстановления
связности.

32. Сценарий
3:
плановые
работы
с
базой
или
авария
всего
ДЦ
ElasZc
Load
Balancing
… …
Web
1
Web
2
Web
N
S3
Web
1
Web
2
Web
N
Датацентр
1
в
MySQL
MySQL
Датацентр
2
в
регионе
US
East
master
master
регионе
US
East
master-­‐master
(Virginia)
репликация
(Virginia)
Мониторинг
и
Мониторинг
и
масштабирование
–
масштабирование
–
CloudWatch
+
CloudWatch
+
AutoScaling
AutoScaling
management,
monitoring,
MySQL
backup

33. Сценарий
3:
плановые
работы
с
базой
или
авария
всего
ДЦ
" Весь
трафик
переключается
в
один
работающий
датацентр.
" CloudWatch
определяет
возросшую
нагрузку
на
машины
и
добавляет
их
в
соответствие
с
правилами
для
AutoScaling.
" Приостанавливается
мастер-­‐мастер
репликация.
" Проводятся
все
необходимые
работы
с
базой,
на
которую
не
идет
нагрузка.
" База
включается
в
работу,
восстанавливается
репликация.
" Траффик
распределяется
на
оба
датацентра.
" Гасятся
лишние
машины,
если
средняя
нагрузка
стала
ниже
порогового
значения.

34. MySQL?
Percona
Server!
Один
из
выводов
в
процессе
эксплуатации:
используем
один
из
fork’ов
MySQL
–
Percona
Server
(обратно
совместим
с
MySQL)
• Оптимизирован
для
работы
в
«облаке»
(с
относительно
медленными
дисками)
• Быстрое
восстановление
кэша
при
рестарте
базы
• Оптимизирован
для
Mulwtenancy
приложений
с
тысячами
таблиц
• Оптимизирован
для
сбора
статистики
по
отдельным
пользователям
• Подробная
статистика
по
медленным
запросам
• XtraDB
и
XtraBackup

35. Конфигурация
машин
с
базами
MySQL
Виртуальная
машина
(EC2)
-­‐
Extra
Large
Instance
–
15
Gb
RAM
Этапы
масштабирования:
1) Вертикальное
масштабирование
(дисковая
система
RAID-­‐10
на
EBS)
2) Веб-­‐кластер
master-­‐slave.
Запуск
необходимого
числа
слейвов
в
конфигурации
веб-­‐кластера
master-­‐slave
3) Горизонтальное
масштабирование,
разделение
мастера
на
несколько
серверов
Все
этапы
выполняются
без
остановки
сервиса.

36. Бэкап
базы
данных
Еще
один
вывод:
для
разных
сценариев
восстановления
данных
необходимо
использовать
разные
бэкапы.
" Для
восстановления
целого
сервера
БД
в
случае
аварии
используем
образ
машин
со
всеми
дисками
(AMI)
–
делаем
целостный
бэкап
RAID’а,
используя
файловую
систему,
поддерживающую
freeze
и
механизм
snapshot’ов
в
Амазоне.
" Логические
(mysqldump)
и
бинарные
инкрементальные
(Xtrabackup)
бэкапы
используются
для
восстановления
отдельных
баз
или
таблиц,
поврежденных
в
случае
некорректных
операций
в
системе
или
ошибок
пользователей.
" Второй
тип
бэкапов
делается
на
выделенном
slave,
на
который
не
распределяется
общая
нагрузка.
Тем
самым
ресурсоемкие
операции
создания
бэкапов
не
влияют
на
работу
пользователей.

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

38. Контроллер
Используется
для
логического
управления
проектами,
выполнения
любых
команд,
SQL-­‐запросов
и
PHP-­‐кода
на
любой
из
копии
проекта.
Обеспечивает
биллинг,
включение
тарифных
планов,
ограничения
по
пользователям,
дисковому
пространству
и
т.д.

39. Итоговая
архитектура
Битрикс24
HTTP/HTTPS
HTTP/HTTPS
HTTP/HTTPS
*.com
*.com
*.ru
*.ru
ElasZc
ElasZc
Load
Balancing
Load
Balancing
CloudWatch
CloudWatch
… …
+
+
AutoScaling
S3
AutoScaling
Web
1
Web
2
Web
N
Web
1
Web
2
Web
N
cache
MySQL
MySQL
cache
master
master
master-­‐master
репликация
MySQL
slave
MySQL
slave
management,
CloudWatch
monitoring,
CloudWatch
MySQL
backup

40.
Надежность
Один
из
приоритетов
–
постоянная
доступность
сервиса,
его
отказоустойчивость.
" Все
веб-­‐ноды
идентичны
и
не
зависимы
друг
от
друга,
в
случае
аварии
автоматически
стартуют
новые.
" Два
датацентра
синхронизированы
друг
с
другом
и
равноценно
обслуживают
клиентов.
В
случае
аварии
на
уровне
датацентра
или
плановых
работ
с
базой,
трафик
прозрачно
для
клиентов
переключается
на
рабочий
датацентр.

41. Идет
тестирование
Ваш
персональный
«инвайт»
на
Битрикс24
XXX-­‐XXX-­‐XX
• Не
раздавайте
«инвайты»,
используйте
только
сами!
• Для
тестирования
ограничение
по
пользователям
не
установлено.
• Тем,
кто
перейдет
на
использование
компанией,
сервис
предоставим
бесплатно
(50
Гб).

42. Следите
за
нами!
twi¦er.com/1C_Bitrix
facebook.com/1CBitrix
www.1c-­‐bitrix.ru

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