DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр

Александр Сербул
Руководитель направления контроля качества интеграции и внедрений
Архитектура Битрикс24
в Amazon Web Services
– изнутри, с пристрастием

Битрикс24
www.bitrix24.ru
Социальный интранет
Структура компании, календари
Работа с задачами
Документы, поиск
Управление временем
CRM
Битрикс24.Диск
и многое другое.

Технологические цели
Высокая отказоустойчивость
Высокая, «неограниченная» производительность
Автомасштабирование
Простота развития, прозрачность архитектуры
Не усложнять без необходимости 

Битрикс24 – в цифрах
• Зарегистрировано компаний: 54 000 +
• Каждый день используют 4 000 + компаний
• Еще 2 100 + компаний - через день
• 1 600 + сотрудников в максимальной
компании
• 22 Гб - максимальный размер
использованного пространства компаний
• Общий размер файлов в облаке Amazon –
790 Гб
• 10 000 000 программных страниц в день
• Максимальное число подключенных
интернет-магазинов к одной CRM – 12

S3
Elastic Load Balancing
Web 1
Elastic Load Balancing
Dynamic
Web N
…
CloudWatch
+
AutoScaling
Web 1 Web 2 Web N
…
CloudWatch
+
AutoScaling
Архитектура – с птичьего полета
S3
management,
monitoring,
backup
Static
CDN
js, css
DynamicStatic
CDN
js, css
images(clients)
images(clients)
local
cache
local
cache
local
cache
local
cache
local
cache
control cache: memcached
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
master-master replication
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
mysqld
Web 2
local
cache

AWS – это «живые»
паттерны проектирования
Приложения тоже имеют «нормальные формы»
Многие этого не понимают
Риск изобретения неудачного велосипеда
Риск: «Зачем делать просто, если можно сложно?»
Используем опыт взрослых расширяемых архитектур

Собираем из «кубиков»
Архитектор собирает костяк проекта «из «LEGO»
Основные усилия тратим на нестандартный функционал

Собираем из «кубиков»

Несколько датацентров
Можно быстро мигрировать машины, данные и сервисы
между датацентрами
Спасает при авариях

Свобода перемещения IP-адресов
EC2
EC2
Elastic IP:
23.34.176.15

#!/bin/sh
NODE_INSTANCE_ID=$1
# http://aws.amazon.com/ec2/instance-types/
NODE_TARGET_TYPE='m2.2xlarge'
NODE_ELASTIC_IP=$2
ec2-stop-instances $NODE_INSTANCE_ID
while ec2-describe-instances $NODE_INSTANCE_ID | grep -q stopping
do
sleep 5
echo 'Waiting'
done
ec2-modify-instance-attribute --instance-type $NODE_TARGET_TYPE $NODE_INSTANCE_ID
ec2-start-instances $NODE_INSTANCE_ID
ec2-associate-address $NODE_ELASTIC_IP -i $NODE_INSTANCE_ID

Диски
Elastic Block Store: 1GB – 1TB
Блочное устройство
AFR (annual failure rate) ~0.1-0.5% (при регулярных
снепшотах)
IO: десятки MB/sec – серьезно уступают «железным»
Хорошо помогает софтварный рейд (md)
raid0 или raid0+1?
Диски живут в одном «ДЦ», а их снепшоты между «ДЦ», на
уровне региона
«Provisioned EBS»: до 4000 IOPS/диск

Снепшоты данных и серверов
Делать снепшоты рейдов можно и нужно
Нет инструментов очистки устаревших снепшотов и образов
машин, их нужно писать
Unix: ec2-consistent-snapshot
или:
fsfreeze –f mountpoint (Linux Ext3/4, ReiserFS, JFS, XFS)
AWS SDK for PHP:
AmazonEC2::create_snapshot ( $volume_id, $opt )
AmazonEC2::create_image ( $instance_id, $name, $opt )
fsfreeze –u mountpoint

Сервер веб-приложений
PHP + APC
Модифицированный «1C-Битрикс:
Корпоративный портал» - кластерная
редакция
nginx
Сервер веб-приложений
Балансировщик ELB (SSL)
Сервер MySQL
MySQL (Percona/XtraDB)
Кэш данных (чтение): APC
Кэш данных (запись): memcached
Изменяемые файлы
Simple Storage Service (s3)

Кластер серверов веб-приложений
Region = группа связанных датацентров
ДЦ1 ДЦ2
Балансировщик (ELB)
Группа автомасштабирования (AutoScaling)
Мониторинг (CloudWatch)
Образ машины (AMI)

Автомасштабирование

Работа с файлами в s3
API хранилища для «прозрачной» работы с файлами
API для разработчиков (не используем стандартные
функции для работы с файлами)
Избегаем «диких» файлов
«Прозрачность» для всех модулей системы
Таблица с данными обо всех подключенных хранилищах
Таблица со списком файлов, и указанием, где они хранятся
(можно сразу хранить дополнительную информацию)
Не используем file_size, getimagesize и т.п. – сохраняем все
данные при аплоаде

Раздача статики: s3 + CDN
Веб-сервер

Временные токены к s3 и др.
Раньше для каждой учетки - новый IAM пользователь,
получаем AccessKey, SecretKey. Но есть лимит: макс. 15 000
(по умолчанию – 5 000)
Сейчас используем Security Token Service (STS) – временные
учетные записи
Права внутри одной директории:
PutObject
GetObject
DeleteObject

Масштабирование БД
ДЦ1 ДЦ2
Балансировщики (ELB)
AutoScaling
Мониторинг
(CloudWatch)
Образ машины (AMI)
Percona XtraDB Master-
Master (Active/Passive)
Масштабирование PHP
Вертикальныйшардинг
DB1
(Passive)
DB1
(Active)
DB2
(Passive)
DB2
(Active)
DB3
(Passive)
DB3
(Active)
Миллионы таблиц,
десятки тысяч баз данных

Бэкап БД
Диск (EBS)
Буферы MySQL
(InnoDB) в памяти
Unix: ec2-consistent-snapshot
или:
“FLUSH TABLES WITH READ
LOCK”
fsfreeze –f mountpoint (Linux
Ext3/4, ReiserFS, JFS, XFS)
AWS SDK for PHP:
AmazonEC2::create_snapshot (
$volume_id, $opt )
AmazonEC2::create_image (
$instance_id, $name, $opt )
fsfreeze –u mountpoint
“UNLOCK TABLES”
Данные MySQL
(InnoDB) на диске
Хранилище данных
(на базе S3 = Simple
Storage Service)
Снепшоты.
Автоматически:
консолидация бэкапов,
сохранение только
инкрементов

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

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

Мониторинг
Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не
самописные.
Дежурная смена и/или мгновенные уведомления.
Мониторить – всё.
Но – аккуратно. Тысячи уведомлений будут бесполезны.
Автоматизация типовых реакций.
Мониторить систему мониторинга.
В идеальном мире – распределенная система мониторинга.
«Мониторинг безопасности» – изменения файлов и т.п.

Мониторинг - тест
Nagios
AWS SDK for PHP
Тест
Тест
Тест
Тест
Обработчик события
CloudWatch -
автомасштабирование
Ядро
Прослойка
вспомогательного кода
(PHP, bash)
Утилиты AWS
для консоли
API Амазона
Тест nagios
Pinba
Тест

Мониторинг - обработчик
Nagios
AWS SDK for PHP
Тест
Тест
Тест
Тест
CloudWatch -
автомасштабирование
Ядро
Прослойка вспомогательного кода (PHP, bash)
Утилиты AWS
для консоли
API Амазона

Мониторинг и аналитика
В CloudWatch недостаточно возможностей, но используем его
максимально
AWS SDK for PHP и вообще работа с API амазона не всегда
прямолинейна – нужна прослойка
Для основного мониторинга и активной обратной связи
используем Nagios и его обработчики событий
Для аналитики в основном используем Munin, часть данных
берем из CloudWatch
Присматриваемся к gearman, используем SQS (сервис очередей
AWS)

Спасибо за внимание!
Вопросы?
Александр Сербул
serbul@1c-bitrix.ru
@AlexSerbul

DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (9)

Similar to DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр

Similar to DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр (20)

More from it-people

More from it-people (20)

DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр