Проектирование высоконагруженного масштабируемого веб-сервиса в облаке на примере Amazon (Александр

Проектирование высоконагруженного масштабируемого отказоустойчивого веб-

сервиса в облаке на примере Amazon

Александр Демидов,Александр Сербул

«1С-Битрикс»

Выбор платформы для разворачивания инфраструктуры

Минусы размещения на собственном оборудовании:

«Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой»

Брет Тейлор, технический директор Facebook

Необходимы вложения в инфраструктуру на старте проектаСложность масштабированияСложность администрирования (в случае размещения в территориально удаленных датацентрах)Сложность резервирования на уровне ДЦСоздание всех сопутствующих сервисов с нуля

Почему Amazon Web Services? Приложения тоже имеют «нормальные формы»

Многие этого не понимают

Риск изобретения неудачного велосипеда

Риск: «Зачем делать просто, если можно сложно?»

Используем опыт взрослых расширяемых архитектур

Почему Amazon Web Services? Архитектор собирает костяк проекта «из «LEGO»

Основные усилия тратим на нестандартный функционал

Почему Amazon Web Services?

Почему Amazon Web Services? Можно легко мигрировать машины и сервисы между датацентрами

Спасает при авариях

Amazon Elastic Compute Cloud EC2) и вертикальное масштабирование

Практически моментальная доступность необходимого количества виртуальных машин (instances) нужной конфигурации (от 613 Мб до 68 Гб RAM, от 1 до до 33.5 ECU CPU)

Множество готовых образов систем (различные дистрибутивы Linux, Microsoft Windows Server, OpenSolaris)

Высокая доступность (99.95% - Amazon EC2 SLA)

Возможность использования дисков различной конфигурации (Amazon Elastic Block Store (EBS))

Возможность размещения виртуальных машин в разных датацентрах (регионах)

Безопасность: удобный файрвол для групп виртуальных машин

Запуск новой машиныВыбор образа (стандартные – Linux, Windows; собственные ранее созданные; community)

Выбор типа машины

Выбор AZ

Public / private key

Security group

Другие опции (termination protection, набор дисков, shutdown behavior и т.д.)

«Подводный камень» № 1

EC2 – практически тот же VPS

Нет «волшебного ползунка», чтобы гибко задать конфигурацию – как на старте, так и в процессе работы

Нет моментального вертикального масштабирования

«Подводный камень» № 2

steal

EC2 и IP

ec2-23-23-231-56.compute-1.amazonaws.com 10.10.26.123

23.23.231.56

Только 1 внешний IP у каждой машины

Разный резолвинг внутри и снаружи

Внутренний и внешний IP не постоянны (кроме использования Elastic IP)

При организации рассылок – не забывайте про IN PTR

Elastic 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 stoppingdo 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

Облачные диски - EBS Elastic Block Store: 1GB – 1TB

До 1000 IOPS/диск

AFR (annual failure rate) ~0.1-0.5% (при регулярных снепшотах)

IO: десятки MB/sec – серьезно уступают «железным»

Хорошо помогает софтварный рейд (md)

raid0 или raid0+1?

Диски живут в одном «ДЦ», а их снепшоты между «ДЦ», на уровне региона

Снэпшоты - EBSДелать снепшоты рейдов можно и нужно

Нет инструментов очистки устаревших снепшотов и образов машин, их нужно писать

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

AMI – образы машин AMI – набор данных, описывающих параметры машины + загрузочный образ

Делать снепшоты машин целиком – гораздо удобнее, чем по одному диску

Машина переносится между «датацентрами» - целиком

Auto Scaling

Region = группа связанных датацентров

ДЦ1 ДЦ2

Балансировщик (ELB)

Группа автомасштабирования (AutoScaling)

Мониторинг (CloudWatch)

Образ машины (AMI)Образ машины (AMI)

Auto Scaling

Elastic Load Balancing


Elastic Load Balancing – SSL

Elastic Load Balancing – особенности

Level 7 (HTTP) балансировщик «пропускает» не все методы: например, не работают REPORT, SEARCH, MKCALENDAR (WebDav, CalDav и т.п.)

Level 4 (TCP) не передает на бэкенд (EC2) real IP

При нагрузочном тестировании нельзя давать нагрузку «ступенькой» - только постепенное плавное увеличение

Amazon Simple Storage Service (S3)

Разные типы хранилищ (наличие Reduced Redundancy Storage – RRS)

SDK: Java, .NET, PHP, Ruby, iOS, Android

S3tools, s3fs, сторонние клиенты

Доступность – 99.99%

Надежность – 99.999999999%

ACL

Версионность

Если каждая веб-нода становится «расходным материалом», где хранить статический контент?

Интеграция приложения с S3API хранилища для «прозрачной» работы с файлами

API для разработчиков (не используем стандартные функции для работы с файлами)

Избегаем «диких» файлов

«Прозрачность» для всех модулей системы

Таблица с данными обо всех подключенных хранилищах

Таблица со списком файлов, и указанием, где они хранятся (можно сразу хранить дополнительную информацию)

Не используем file_size, getimagesize и т.п. – сохраняем все данные при аплоаде

S3 + CDN

Веб-сервер

Изоляция данных пользователей в S3Раньше - новый IAM пользователь, получаем AccessKey, SecretKey. Но есть лимит: макс. 15 000 (по умолчанию – 5 000)

Используем Security Token Service (STS) – временные учетные записи

Права внутри одной директории:

PutObject

GetObject

DeleteObject

Деплой и обновления системного ПО

Web 1

Web 2

Web N

Сервер обновлений

Новый образ AMI

ElasticLoad

Balancing

Как ставить обновления на нодах, не допустив рассинхрони-зации данных (веб и база)?

Как работают обновления ПОКак ставить обновления на нодах, не допустив рассинхронизации данных (веб и база)

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

База – RDS или не RDS?У Amazon есть сервис RDS (Relational Database Service). Можно использовать MySQL или Oracle. Стоит ли использовать?

Недостаточно гибкая система (нет полноценного root в базе)НепрозрачноРиск долгого даунтайма Двойная стоимость машин при использовании Multi-AZПри этом – неэффективное использование ресурсов

Конфигурация машин c базами MySQL

Виртуальная машина (EC2) - m2.2xlarge:

34.2 GB of memory13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each)64-bit platformI/O Performance: HighEBS-Optimized Available: No

Диск может оказаться «узким» местом…

Software RAID

# cat /proc/partitionsmajor minor #blocks name

202 16 880737792 xvdb 202 144 157286400 xvdj 202 128 157286400 xvdi 202 112 157286400 xvdh 202 96 157286400 xvdg 202 0 8388608 xvda 202 1 112423 xvda1 202 2 5253255 xvda2 202 3 3020220 xvda3 202 224 524288000 xvdo 202 208 157286400 xvdn 202 192 157286400 xvdm 202 176 157286400 xvdl 202 160 157286400 xvdk 9 0 629139456 md0

# mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/xvd[g-j]

# mkfs.ext4 /dev/md0

/etc/fstab

/dev/md0 /mnt/raid10 ext4 defaults,noatime,nodiratime,data=writeback,barrier=0 0 0

# mount /mnt/raid10

Software RAID – тесты sysbench

Режим random read/write. При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет.

MySQL? Percona Server!Оптимизирован для работы с медленными дискамиБыстрый рестарт базы (Fast Shut-Down, Buffer Pool Pre-Load)Множество счетчиков и расширенных отчетовXtraDB Storage EngineXtraBackupBLOB, TEXT в таблицах MEMORY (HEAP)

MySQL? Percona Server!mysql> SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME;+----------------+-------+----------------+| time | count | total |+----------------+-------+----------------+| 0.000001 | 0 | 0.000000 || 0.000010 | 2011 | 0.007438 || 0.000100 | 12706 | 0.513395 || 0.001000 | 4624 | 1.636106 || 0.010000 | 2994 | 12.395174 || 0.100000 | 200 | 6.225339 || 1.000000 | 33 | 5.480764 || 10.000000 | 1 | 2.374067 || 100.000000 | 0 | 0.000000 || 1000.000000 | 0 | 0.000000 || 10000.000000 | 0 | 0.000000 || 100000.000000 | 0 | 0.000000 || 1000000.000000 | 0 | 0.000000 || TOO LONG | 0 | TOO LONG |+----------------+-------+----------------+14 rows in set (0.00 sec)

Используем master-master репликацию в MySQL

Особенности настройки MySQL:auto_increment_incrementauto_increment_offset

Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления.Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.

Вертикальное масштабирование базы

CloudWatch

MySQLmaster

MySQLslave

Веб-нодаБалансировка SQL

Elastic IP

Мониторим состояние master через CloudWatchЕсть slave – минимальной конфигурации – работающий в режиме только бэкапаПри необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование)Останавливаем master, делаем slave мастеромПереключаем IP (Amazon Elastic IP) на машину с новым мастеромВеб-ноды не требуют переконфигурирования и продолжают работать без даунтайма

Для вертикального масштабирования используем slave, потом переключаем его в master

Горизонтальное масштабирование базы

ДЦ1 ДЦ2

Балансировщики (ELB)

AutoScaling

Мониторинг (CloudWatch)

Образ машины (AMI)Образ машины (AMI)

Percona XtraDB Master-Master (Active/Passive)

Percona XtraDB Master-Master (Active/Passive)

Масштабирование PHP

Вер

тика

льн

ый

шар

дин

г

DB1 (Passive)

DB1(Active)

DB2(Passive)

DB2(Active)

DB3(Passive)

DB3(Active)

Миллионы таблиц,десятки тысяч баз данных

Бэкап MySQL

Диск (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)

Снепшоты.

Автоматически: консолидация бэкапов, сохранение только инкрементов

Бэкап MySQLРецепта «100% целостного» снепшота файлов MySQL похоже нет, нужно колдовать

Percona XtraBackup – инкрементальный бинарный бэкап

Нужно немало времени на подготовку бинарного бэкапа к «чистому» быстрому восстановлению

Логический бэкап снимаем со слейвов

Случались тотальные разрушения raid10 при аварии в амазоне – бинарный бэкап (или снепшот машины) + бинлоги

Организация системы мониторинга

Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные.

Дежурная смена и/или мгновенные уведомления.

Мониторить – всё.

Но – аккуратно. Тысячи уведомлений будут бесполезны.

Автоматизация типовых реакций.

Мониторить систему мониторинга.

В идеальном мире – распределенная система мониторинга.

«Мониторинг безопасности» – изменения файлов и т.п.

Мониторинг операционной системыМесто на дисках

Очередь выполнения

Размер и использование swap

И т.д.

Мониторинг MySQLКлючевые тесты

Автоматика – структура теста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

Аналитика

Аналитика – со стороны пользователяМало знать «среднюю температуру по больнице» и мониторить только главную страницу сайта

Гистограммы распределения времени хитов, памяти, кодам ответа и т.п. – из логов (awk-скрипт), pinba или других инструментов

Пользовательская аналитика – в графиках

Гистограмма времени обработки запросов (Percona)

Пользовательская аналитика – в графиках

Число ошибок в хитах за 15 минут - меньше L (из pinba)

Макс. время хита (тэга) – меньше M сек.

Макс. использование памяти хитом – меньше N МБ

Итог

Масштабируемость под высокие нагрузки

CloudWatch + Auto Scaling

Web 1

Очень высокая посещаемость


Web 2 Web N…

Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling

Отказоустойчивость узлов

MySQLmaster

ElasticLoad Balancing

Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…

master-master репликация

S3

management, monitoring,

MySQL backup

Датацентр 1 в регионе US East (Virginia)

Мониторинг и масштабирование – CloudWatch + AutoScaling



Отказоустойчивость узлов

MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


S3


MySQL backup





Отказоустойчивость ДЦ

MySQLmaster


Web N…

Web 1

Web 2

MySQLmaster

Web 1

Web 2

Web N…


S3


MySQL backup





Надежность «облака»Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.

Спасибо за внимание!

Вопросы?

Александр Демидов

[email protected]

@demidov

Александр Сербул

[email protected]

@AlexSerbul

mailto:[email protected]

mailto:[email protected]

Documents

Проектирование высоконагруженного масштабируемого веб-сервиса в облаке на примере Amazon (Александр