DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр
Download as PPTX, PDF0 likes895 views
Документ описывает архитектуру и технологические цели внедрения Битрикс24 на платформе Amazon Web Services, включая аспекты высокоотказоустойчивости, автомасштабирования и мониторинга. Также представлены цифры, подтверждающие масштаб проекта, такие как количество зарегистрированных компаний и производительность системы. В документе освещаются вопросы миграции, резервного копирования и обновления системы, а также использование различных средств мониторинга.
DUMP-2013 Serverside - Архитектура Битрикс24 в Amazon Web Services – изнутри - Сербул Александр
- 1. Александр Сербул Руководитель направления контроля качества интеграции и внедрений Архитектура Битрикс24 в Amazon Web Services – изнутри, с пристрастием
- 3. Битрикс24 www.bitrix24.ru Социальный интранет Структура компании, календари Работа с задачами Документы, поиск Управление временем CRM Битрикс24.Диск и многое другое.
- 4. Технологические цели Высокая отказоустойчивость Высокая, «неограниченная» производительность Автомасштабирование Простота развития, прозрачность архитектуры Не усложнять без необходимости
- 5. Битрикс24 – в цифрах • Зарегистрировано компаний: 54 000 + • Каждый день используют 4 000 + компаний • Еще 2 100 + компаний - через день • 1 600 + сотрудников в максимальной компании • 22 Гб - максимальный размер использованного пространства компаний • Общий размер файлов в облаке Amazon – 790 Гб • 10 000 000 программных страниц в день • Максимальное число подключенных интернет-магазинов к одной CRM – 12
- 6. 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 master-master replication master-master replication mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld control cache: memcached control cache: memcached control cache: memcached control cache: memcached control cache: memcached Web 2 local cache
- 7. AWS – это «живые» паттерны проектирования Приложения тоже имеют «нормальные формы» Многие этого не понимают Риск изобретения неудачного велосипеда Риск: «Зачем делать просто, если можно сложно?» Используем опыт взрослых расширяемых архитектур
- 8. Собираем из «кубиков» Архитектор собирает костяк проекта «из «LEGO» Основные усилия тратим на нестандартный функционал
- 10. Несколько датацентров Можно быстро мигрировать машины, данные и сервисы между датацентрами Спасает при авариях
- 11. Свобода перемещения IP-адресов EC2 EC2 Elastic IP: 23.34.176.15
- 12. #!/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
- 13. Диски Elastic Block Store: 1GB – 1TB Блочное устройство AFR (annual failure rate) ~0.1-0.5% (при регулярных снепшотах) IO: десятки MB/sec – серьезно уступают «железным» Хорошо помогает софтварный рейд (md) raid0 или raid0+1? Диски живут в одном «ДЦ», а их снепшоты между «ДЦ», на уровне региона «Provisioned EBS»: до 4000 IOPS/диск
- 14. Снепшоты данных и серверов Делать снепшоты рейдов можно и нужно Нет инструментов очистки устаревших снепшотов и образов машин, их нужно писать 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
- 15. Сервер веб-приложений PHP + APC Модифицированный «1C-Битрикс: Корпоративный портал» - кластерная редакция nginx Сервер веб-приложений Балансировщик ELB (SSL) Сервер MySQL MySQL (Percona/XtraDB) Кэш данных (чтение): APC Кэш данных (запись): memcached Изменяемые файлы Simple Storage Service (s3)
- 16. Кластер серверов веб-приложений Region = группа связанных датацентров ДЦ1 ДЦ2 Балансировщик (ELB) Группа автомасштабирования (AutoScaling) Мониторинг (CloudWatch) Образ машины (AMI)
- 18. Балансировка
- 19. Работа с файлами в s3 API хранилища для «прозрачной» работы с файлами API для разработчиков (не используем стандартные функции для работы с файлами) Избегаем «диких» файлов «Прозрачность» для всех модулей системы Таблица с данными обо всех подключенных хранилищах Таблица со списком файлов, и указанием, где они хранятся (можно сразу хранить дополнительную информацию) Не используем file_size, getimagesize и т.п. – сохраняем все данные при аплоаде
- 20. Раздача статики: s3 + CDN Веб-сервер
- 21. Временные токены к s3 и др. Раньше для каждой учетки - новый IAM пользователь, получаем AccessKey, SecretKey. Но есть лимит: макс. 15 000 (по умолчанию – 5 000) Сейчас используем Security Token Service (STS) – временные учетные записи Права внутри одной директории: PutObject GetObject DeleteObject
- 22. Масштабирование БД ДЦ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) Миллионы таблиц, десятки тысяч баз данных
- 23. Бэкап БД Диск (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) Снепшоты. Автоматически: консолидация бэкапов, сохранение только инкрементов
- 24. Обновление кластера Web 1 Web 2 Web N Сервер обновлений Новый образ AMI Elastic Load Balancing Как ставить обновления на нодах, не допустив рассинхрони- зации данных (веб и база)?
- 25. Обновление кластера Как ставить обновления на серверах, не допустив рассинхронизации данных (веб и база): Каждое клиентское приложение работает с собственной базой. Все обновления ставятся на выделенный instance, куда не приходит нагрузка. Из этого инстанса делается новый образ AMI. Последовательно каждая машина помечается «плохой», при этом новые веб-ноды стартуют уже из нового образа. В веб-приложении существует механизм проверки соответствия версии ПО и базы. Если клиентский запрос приходит на ноду с новым ПО, а база еще старая, по первому хиту происходит обновление.
- 26. Мониторинг Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные. Дежурная смена и/или мгновенные уведомления. Мониторить – всё. Но – аккуратно. Тысячи уведомлений будут бесполезны. Автоматизация типовых реакций. Мониторить систему мониторинга. В идеальном мире – распределенная система мониторинга. «Мониторинг безопасности» – изменения файлов и т.п.
- 27. Мониторинг - тест Nagios AWS SDK for PHP Тест Тест Тест Тест Обработчик события Обработчик события Обработчик события CloudWatch - автомасштабирование Обработчик события Ядро Прослойка вспомогательного кода (PHP, bash) Утилиты AWS для консоли API Амазона Тест nagios Pinba Тест
- 28. Мониторинг - обработчик Nagios AWS SDK for PHP Тест Тест Тест Тест Обработчик события Обработчик события Обработчик события CloudWatch - автомасштабирование Обработчик события Ядро Обработчик события Прослойка вспомогательного кода (PHP, bash) Утилиты AWS для консоли API Амазона
- 29. Мониторинг и аналитика В CloudWatch недостаточно возможностей, но используем его максимально AWS SDK for PHP и вообще работа с API амазона не всегда прямолинейна – нужна прослойка Для основного мониторинга и активной обратной связи используем Nagios и его обработчики событий Для аналитики в основном используем Munin, часть данных берем из CloudWatch Присматриваемся к gearman, используем SQS (сервис очередей AWS)
- 30. 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 master-master replication master-master replication mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld mysqld control cache: memcached control cache: memcached control cache: memcached control cache: memcached control cache: memcached Web 2 local cache
- 31. Спасибо за внимание! Вопросы? Александр Сербул [email protected] @AlexSerbul