Разработка и администрированиечерез тестирование- облачный сервис «Битрикс24» в Амазоне

Наши цели
Посмотреть на Amazon Web Services (AWS) с «птичьего полета»
Научиться эффективно с ним работать, в т.ч. на PHP
Уверенно развивать функционал, не отставая от рынка
Держать созданную систему под постоянным контролем
Изучить результат - сервис «Битрикс24» - изнутри

AWS с «птичьего полета»
Amazon Elastic Compute Cloud (EC2) – серверы и образы
Amazon Elastic Block Store (EBS) - внешние диски
Auto Scaling – масштабирование (от нагрузки и т.д.)
Elastic Load Balancing - балансировщики
Amazon Simple Storage Service (S3) – облачное хранилище
Управляемый из кода хостинг с множеством реализованных
Enterprise-паттернов :

AWS с «птичьего полета»
Amazon Simple Queue Service (SQS) - очереди сообщений
Amazon Simple Notification Service (SNS) - уведомлялка
Amazon Simple Email Service (SES) – рассылки почты
AWS Identity and Access Management (IAM) – управление учетками

AWS с «птичьего полета»
Amazon CloudFront – CDN по всему миру
Amazon Route 53 – управление DNS
Amazon Relational Database Service (RDS) – MySQL с slaves и auto-failover
Amazon DynamoDB, Amazon SimpleDB - NoSQL
Amazon ElastiCache - «неубиваемый» memcached

AWS с «птичьего полета»
Amazon CloudWatch – мониторинг + аналитика
Amazon Virtual Private Cloud (VPC) – собственная подсетка (с кластерами)
Полезных сервисов много, готовые паттерны позволяют просто масштабироваться и обеспечивать неплохую отказоустойчивость (SLA до 99,95%).

AWS с «птичьего полета»
Availability zone (AZ) = «датацентр»
Высокоскоростные каналы между ДЦ
Region = группа связанных датацентров

AWS с «птичьего полета»
Availability zone (AZ) = «датацентр»
Region = группа связанных датацентров
Серверы (EC2)
Диски (EBS) – доступны только внутри датацентра
Снепшоты дисков
Образы серверов
Данные в облаке (S3)
Учетки (IAM)
Балансировщики
и др. – реплицируются «между» датацентрами, на уровне региона

AWS – все не так гладко
Веб-сервисы внутри архитектурно отличаются друг от друга, в т.ч . по подходу и API. Не всегда удобно стыкуются.
Прослеживается эволюция архитектур – например «наслоения концепций» в IAM/S3
Имеются неочевидные «жесткие» ограничения и лимиты – например число учеток в IAM (<=5000)

AWS – нужно строить свое управляющее ядро
Внутренняя система мониторинга CloudWatch - пока очень ограничена, уступает напр. Nagios/Munin
Измерения внутри машин (top) и из CloudWatch – могут отличаться в разы (CPU, LA, др.)
Нередко «соседи» на виртуальной машине внезапно влияют на производительность (CPU Stolen %)
Нужно научиться держать конфигурацию под контролем, автоматизировав максимум операций.

AWS SDK for PHP
http://aws.amazon.com/php/
http://aws.amazon.com/sdkforphp/
REST API веб-сервисов Амазона
Консольный клиент для unix, написан на java
AWS SDK for PHP
SSL (как правило)
Библиотека, документация, примеры (2.1М)

AWS SDK for PHP - документация
http://docs.amazonwebservices.com/AWSSDKforPHP/latest/

Бэкап данных в S3/Snapshots
Unix: s3tools, s3fs
AWS SDK for PHP:
AmazonS3::create_object ( $bucket, $filename, $opt ) и др.
AWS SDK for PHP:
AmazonEC2::create_snapshot ( $volume_id, $opt )
AWS SDK for PHP:
AmazonEC2::create_image ( $instance_id, $name, $opt )

Бэкап данных в S3/Snapshots
Нет инструментов очистки устаревших снепшотов и образов машин, их нужно писать (иначе можно упереться в лимит).
Нужно писать оболочку, для повтора неудавшихся операций, логирования и т.п.

Бэкап данных в S3/Snapshots
…
foreach ($vols as $path => $id) {
$response = $ec2->create_snapshot($id, array('Description'=>"Snapshot:".$instanceRole.":".$path));
if ( $response->isOK() ) {
bxc_log("Started snapshot for ($id): ".$response->body->snapshotId);
$r = $ec2->create_tags($response->body->snapshotId, array(
array('Key' => 'Name', 'Value' => "Snapshot:".$instanceRole.":".$path),
array('Key' => 'Role', 'Value' => "Snapshot:".$instanceRole.":".$path),
));
if ( !$r->isOK() ) {
bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__);
}
} else {
bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__);
return false;
}
}
Полезно создаваемым объектам присваивать тэги, для дальнейшей фильтрации

Бэкап MySQL в S3/Snapshots
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
Хранилище данных (на базе S3 = Simple Storage Service)
Снепшоты.
Автоматически: консолидация бэкапов, сохранение только инкрементов

Балансировка/Переключение трафика
Хранилище данных (на базе S3 = Simple Storage Service)
Снепшоты.
Автоматически: консолидация бэкапов, сохранение только инкрементов
Availability zone (AZ) = «датацентр»
Region = группа связанных датацентров, SLA = 99,95%
ДЦ1
ДЦ2
Балансировщик (ELB)
Группа автомасштабирования (AutoScaling)
CNAME к «myproj-1873425.us-east-1.elb.amazonaws.com», SSL-терминация

Балансировка/Переключение трафика
Хранилище данных (на базе S3 = Simple Storage Service)
Снепшоты.
Автоматически: консолидация бэкапов, сохранение только инкрементов
Region = группа связанных датацентров
ДЦ1
ДЦ2
Балансировщик (ELB)
Группа автомасштабирования (AutoScaling)

Балансировка/Переключение трафика
Хранилище данных (на базе S3 = Simple Storage Service)
Снепшоты.
Автоматически: консолидация бэкапов, сохранение только инкрементов
Region = группа связанных датацентров
ДЦ1
ДЦ2
Балансировщик (ELB)
Группа автомасштабирования (AutoScaling)

Балансировка/Переключение трафика
Хранилище данных (на базе S3 = Simple Storage Service)
Снепшоты.
Автоматически: консолидация бэкапов, сохранение только инкрементов
Region = группа связанных датацентров
ДЦ1
ДЦ2
Балансировщик (ELB)
Группа автомасштабирования (AutoScaling)
Мониторинг (CloudWatch)
Образ машины (AMI)

Балансировка/Переключение трафика
Хранилище данных (на базе S3 = Simple Storage Service)
Снепшоты.
Автоматически: консолидация бэкапов, сохранение только инкрементов
Можно гибко управлять тремя службами: ELB, AutoScaling, CloudWatch – подстраивая функционал под свои задачи
Автоматическое увеличение числа машин при росте нагрузки
Автоматическая замена вышедших из строя машин
Переключение трафика в другой ДЦ при аварии сервиса или для проведения регламентных работ

Балансировка/Переключение трафика
AWS SDK for PHP:
AmazonELB:: set_load_balancer_listener_ssl_certificate ( $load_balancer_name, $load_balancer_port, $ssl_certificate_id, $opt )
AmazonELB:: configure_health_check ( $load_balancer_name, $health_check, $opt )
AmazonELB::enable_availability_zones_for_load_balancer ( $load_balancer_name, $availability_zones, $opt )
AmazonELB::register_instances_with_load_balancer ( $load_balancer_name, $instances, $opt )
AmazonAS:: update_auto_scaling_group ( $auto_scaling_group_name, $opt )
AmazonAS: set_desired_capacity ( $auto_scaling_group_name, $desired_capacity, $opt )
и другие.

Автоматическое масштабирование
В CloudWatch создаем Alarm, который при среднем CPU>20% вызовет действие по добавлению в AutoScaling Group серверов, например, 2 машин (а также вышлет нам письмо)
Создаем «обратный» Alarm, который при уменьшении нагрузки на CPU<10% будет убирать по 1 машине

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

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

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

Что мы тестируем
Стандартные тесты nagios:
Пинг, LA, место на дисках
Использование swap, число процессов
Мониторинг raid (у нас 10 рейды из EBS-дисков)
Безопасность – наличие обновлений софта
Для общей картины - набор стандартных плагинов к Munin и несколько десятков графиков по каждой машине

Что мы тестируем
Базовые тесты MySQL:
Состояние репликации – отсутствие ошибок, величина отставания slaves
Buffer Pool hitrate
Число активных потоков
Число «долгих» потоков
Частота создания на диске временных таблиц
и другие

Что мы тестируем
Тесты времени выполнения страниц и использования памяти от pinba:
Пиковое время выполнения страницы вирт. хоста
Пиковое использование памяти вирт. хоста
Среднее время выполнения страниц вирт. хоста с префиксом (по разделам)
Среднее использование памяти вирт. хостом
Среднее время выполнения агентов (после fastcgi_finish_request)
Дополнительно выводим гистограмму распределения хитов по ступенькам времени (по pinba и по суточным логам)

Что мы тестируем
Тесты состояния амазона и превышения лимитов:
Проверяем превышения ключевых лимитов амазона
Число живых машин за балансировщиками
Планируем проверять показатели нагрузки от CloudWatch – их, однако, очень мало
Пинг на машину мониторинга nagios в другом регионе амазона и обратно (мониторинг мониторинга ☺)

Что мы тестируем
Тесты выполнения бизнес-операций и обработчиков событий:
Скрипты бэкапов и обработчики обновляют лог-файл (проверка времени модификации)
Скрипты бэкапов и обработчики в обязательном порядке имеют лог ошибок (2> или error_log) – он должен быть пустым
Лог ошибок очень помогает при работе с иногда «нестабильным» API амазона:
Недоступность веб-сервиса
Недоступность ресурса, хотя уже имеется его ID

Администрирование через тестирование
Перед добавлением любого сервиса или обработчика в обязательном порядке:
Добавляется тест на проверку его «живости», иногда на число процессов с данным именем и т.п.
Добавляется тест на наличие и своевременное обновление лог-файла обработчика/сервиса
Добавляется тест на нулевой размер лога ошибок
Сейчас в системе: около 1000 тестов, 5 сервисных групп, 4 групп хостов.
Это конечно замедляет, однако позволяет уверенно двигаться вперед, менять конфигурацию, проводить эксперименты.

Обработчики
Обработчики стараются вернуть систему в рабочее состояние:
При недоступности memcached(ов) делается временное переключение трафика в другой ДЦ
При крахе машины MySQL или процесса, репликации – временное переключение трафика в другой ДЦ
Проводится простая «реанимация» (рестарт memcached) и т.п.
Если все сервисы поднялись – трафик возвращается обратно
Обработчики для nagios написаны на bash, PHP/MySQL.

Pacemaker/Heartbeat vs Nagios
Было несколько безуспешных подходов понять стройность и красоту – Pacemaker/Heartbeat. Документация – ужасна.
Пока нет доверия DRBD.
Пишем свою простую автоматику на базе Nagios/PHP/MySQL и AWS ☺
Используем для кластера AutoScaling, шарды MySQL Master-Master (Active-Passive) и переключение трафика на балансировщиках (можно также Elastic IP). Картинка – ниже.

Архитектура «Битрикс24» (www.bitrix24.ru)
ДЦ1
ДЦ2
Балансировщики (ELB)
Группа
автомасштабирования
(AutoScaling)
Мониторинг (CloudWatch)
Образ машины (AMI)
SSL - терминация
Percona XtraDB Master-Master (Active/Passive)
Memcached
Memcached
Memcached
Memcached
Memcached
Memcached
Масштабирование PHP
Масштабирование MySQL
Файлы/Бэкапы/
Снепшоты – S3