Проектирование высоконагруженного масштабируемого веб-сервиса в облаке на примере Amazon (Александр Демидов, Александр Сербул)
Download as PPTX, PDF9 likes2,878 views
Документ посвящен проектированию высоконагруженного и устойчивого веб-сервиса на платформе Amazon Web Services (AWS). Описываются преимущества использования облачных технологий, таких как масштабируемость, высокая доступность и безопасность, а также связанные риски и сложности. Приводится пример архитектуры с использованием различных сервисов AWS, включая Elastic Load Balancing, Auto Scaling и RDS.
![# 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](https://image.slidesharecdn.com/amazon-121022011842-phpapp01/85/Amazon-33-320.jpg)
Проектирование высоконагруженного масштабируемого веб-сервиса в облаке на примере Amazon (Александр Демидов, Александр Сербул)
- 1. Проектирование высоконагруженного масштабируемого отказоустойчивого веб- сервиса в облаке на примере Amazon Александр Демидов, Александр Сербул «1С-Битрикс»
- 2. Выбор платформы для разворачивания инфраструктуры Минусы размещения на собственном оборудовании: Необходимы вложения в инфраструктуру на старте проекта Сложность масштабирования Сложность администрирования (в случае размещения в территориально удаленных датацентрах) Сложность резервирования на уровне ДЦ Создание всех сопутствующих сервисов с нуля «Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг- провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой» Брет Тейлор, технический директор Facebook
- 3. Почему Amazon Web Services? Приложения тоже имеют «нормальные формы» Многие этого не понимают Риск изобретения неудачного велосипеда Риск: «Зачем делать просто, если можно сложно?» Используем опыт взрослых расширяемых архитектур
- 4. Почему Amazon Web Services? Архитектор собирает костяк проекта «из «LEGO» Основные усилия тратим на нестандартный функционал
- 5. Почему Amazon Web Services?
- 6. Почему Amazon Web Services? Можно легко мигрировать машины и сервисы между датацентрами Спасает при авариях
- 7. 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)) Возможность размещения виртуальных машин в разных датацентрах (регионах) Безопасность: удобный файрвол для групп виртуальных машин
- 8. Запуск новой машины Выбор образа (стандартные – Linux, Windows; собственные ранее созданные; community) Выбор типа машины Выбор AZ Public / private key Security group Другие опции (termination protection, набор дисков, shutdown behavior и т.д.)
- 9. «Подводный камень» № 1 EC2 – практически тот же VPS Нет «волшебного ползунка», чтобы гибко задать конфигурацию – как на старте, так и в процессе работы Нет моментального вертикального масштабирования
- 10. «Подводный камень» № 2 steal
- 11. 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
- 12. Elastic IP Elastic IP: 23.34.176.15 EC2 EC2
- 13. #!/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
- 14. Облачные диски - EBS Elastic Block Store: 1GB – 1TB До 1000 IOPS/диск AFR (annual failure rate) ~0.1-0.5% (при регулярных снепшотах) IO: десятки MB/sec – серьезно уступают «железным» Хорошо помогает софтварный рейд (md) raid0 или raid0+1? Диски живут в одном «ДЦ», а их снепшоты между «ДЦ», на уровне региона
- 15. Снэпшоты - 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
- 16. AMI – образы машин AMI – набор данных, описывающих параметры машины + загрузочный образ Делать снепшоты машин целиком – гораздо удобнее, чем по одному диску Машина переносится между «датацентрами» - целиком
- 17. Auto Scaling Мониторинг (CloudWatch) Балансировщик (ELB) ДЦ1 ДЦ2 Группа автомасштабирования (AutoScaling) Region = группа связанных датацентров Образ машины (AMI)
- 18. Auto Scaling
- 21. Elastic Load Balancing – SSL
- 22. Elastic Load Balancing – особенности Level 7 (HTTP) балансировщик «пропускает» не все методы: например, не работают REPORT, SEARCH, MKCALENDAR (WebDav, CalDav и т.п.) Level 4 (TCP) не передает на бэкенд (EC2) real IP При нагрузочном тестировании нельзя давать нагрузку «ступенькой» - только постепенное плавное увеличение
- 23. Amazon Simple Storage Service (S3) Если каждая веб-нода становится «расходным материалом», где хранить статический контент? Разные типы хранилищ (наличие Reduced Redundancy Storage – RRS) SDK: Java, .NET, PHP, Ruby, iOS, Android S3tools, s3fs, сторонние клиенты Доступность – 99.99% Надежность – 99.999999999% ACL Версионность
- 24. Интеграция приложения с S3 API хранилища для «прозрачной» работы с файлами API для разработчиков (не используем стандартные функции для работы с файлами) Избегаем «диких» файлов «Прозрачность» для всех модулей системы Таблица с данными обо всех подключенных хранилищах Таблица со списком файлов, и указанием, где они хранятся (можно сразу хранить дополнительную информацию) Не используем file_size, getimagesize и т.п. – сохраняем все данные при аплоаде
- 26. Изоляция данных пользователей в S3 Раньше - новый IAM пользователь, получаем AccessKey, SecretKey. Но есть лимит: макс. 15 000 (по умолчанию – 5 000) Используем Security Token Service (STS) – временные учетные записи Права внутри одной директории: PutObject GetObject DeleteObject
- 27. Деплой и обновления системного ПО Как ставить Сервер Новый обновления на обновлений образ AMI нодах, не допустив рассинхрони- зации данных (веб и база)? Web 1 Elastic Load Web 2 Balancing Web N
- 28. Как работают обновления ПО Как ставить обновления на нодах, не допустив рассинхронизации данных (веб и база) Каждое клиентское приложение работает с собственной базой. Все обновления ставятся на выделенный instance, куда не приходит нагрузка. Из этого инстанса делается новый образ AMI. Последовательно каждая машина помечается «плохой», при этом новые веб-ноды стартуют уже из нового образа. В веб-приложении существует механизм проверки соответствия версии ПО и базы. Если клиентский запрос приходит на ноду с новым ПО, а база еще старая, по первому хиту происходит обновление.
- 29. База – RDS или не RDS? У Amazon есть сервис RDS (Relational Database Service). Можно использовать MySQL или Oracle. Стоит ли использовать? Недостаточно гибкая система (нет полноценного root в базе) Непрозрачно Риск долгого даунтайма Двойная стоимость машин при использовании Multi-AZ При этом – неэффективное использование ресурсов
- 30. Конфигурация машин c базами MySQL Виртуальная машина (EC2) - m2.2xlarge: 34.2 GB of memory 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each) 64-bit platform I/O Performance: High EBS-Optimized Available: No Диск может оказаться «узким» местом…
- 31. Software RAID
- 32. # cat /proc/partitions major 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
- 33. # 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
- 34. Software RAID – тесты sysbench Режим random read/write. При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет.
- 35. MySQL? Percona Server! Оптимизирован для работы с медленными дисками Быстрый рестарт базы (Fast Shut-Down, Buffer Pool Pre-Load) Множество счетчиков и расширенных отчетов XtraDB Storage Engine XtraBackup BLOB, TEXT в таблицах MEMORY (HEAP)
- 36. 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)
- 37. Используем master-master репликацию в MySQL Особенности настройки MySQL: auto_increment_increment auto_increment_offset Базы в разных датацентрах синхронны, при этом независимы друг от друга: потеря связности между датацентрами может составлять часы, данные синхронизируются после восстановления. Пользователь и все сотрудники этой компании работают в одном датацентре за счет управления балансировщиком.
- 38. Вертикальное масштабирование базы Для вертикального масштабирования используем slave, потом переключаем его в master Мониторим состояние master через Веб-нода CloudWatch Балансировка SQL Есть slave – минимальной конфигурации – работающий в режиме только бэкапа Elastic IP При необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование) Останавливаем master, делаем slave MySQL мастером MySQL slave Переключаем IP (Amazon Elastic IP) на master машину с новым мастером Веб-ноды не требуют CloudWatch переконфигурирования и продолжают работать без даунтайма
- 39. Горизонтальное масштабирование базы Образ машины (AMI) Миллионы таблиц, десятки тысяч баз данных Мониторинг Балансировщики (ELB) (CloudWatch) ДЦ1 ДЦ2 AutoScaling Масштабирование PHP DB1 DB1 (Active) Вертикальный шардинг (Passive) Percona XtraDB Master- Master (Active/Passive) DB2 DB2 (Passive) (Active) DB3 DB3 (Active) (Passive)
- 40. Бэкап MySQL Unix: ec2-consistent-snapshot или: “FLUSH TABLES WITH READ LOCK” Буферы MySQL fsfreeze –f mountpoint (Linux (InnoDB) в памяти 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” Хранилище данных Диск (EBS) (на базе S3 = Simple Storage Service) Снепшоты. Данные MySQL Автоматически: (InnoDB) на диске консолидация бэкапов, сохранение только инкрементов
- 41. Бэкап MySQL Рецепта «100% целостного» снепшота файлов MySQL похоже нет, нужно колдовать Percona XtraBackup – инкрементальный бинарный бэкап Нужно немало времени на подготовку бинарного бэкапа к «чистому» быстрому восстановлению Логический бэкап снимаем со слейвов Случались тотальные разрушения raid10 при аварии в амазоне – бинарный бэкап (или снепшот машины) + бинлоги
- 42. Организация системы мониторинга Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные. Дежурная смена и/или мгновенные уведомления. Мониторить – всё. Но – аккуратно. Тысячи уведомлений будут бесполезны. Автоматизация типовых реакций. Мониторить систему мониторинга. В идеальном мире – распределенная система мониторинга. «Мониторинг безопасности» – изменения файлов и т.п.
- 43. Мониторинг операционной системы Место на дисках Очередь выполнения Размер и использование swap И т.д.
- 45. Автоматика – структура теста Ядро Nagios Тест Тест Тест Тест Тест Обработчик события Тест nagios Обработчик события Прослойка Обработчик события вспомогательного кода Pinba (PHP, bash) AWS SDK for PHP CloudWatch - автомасштабирование Утилиты AWS для консоли Обработчик события API Амазона
- 46. Автоматика – обработчик Ядро Nagios Обработчик события Тест Тест Тест Тест Прослойка вспомогательного кода (PHP, bash) Обработчик события Утилиты AWS AWS SDK for PHP Обработчик события для консоли Обработчик события API Амазона CloudWatch - автомасштабирование Обработчик события
- 47. Автоматика В CloudWatch недостаточно возможностей, но используем его максимально AWS SDK for PHP и вообще работа с API амазона не всегда прямолинейна – нужна прослойка Для основного мониторинга и активной обратной связи используем Nagios и его обработчики событий Для аналитики в основном используем Munin, часть данных берем из CloudWatch Присматриваемся к gearman, SQS
- 48. Аналитика
- 49. Аналитика – со стороны пользователя Мало знать «среднюю температуру по больнице» и мониторить только главную страницу сайта Гистограммы распределения времени хитов, памяти, кодам ответа и т.п. – из логов (awk-скрипт), pinba или других инструментов
- 50. Пользовательская аналитика – в графиках Гистограмма времени обработки запросов (Percona)
- 51. Пользовательская аналитика – в графиках Число ошибок в хитах за 15 минут - меньше L (из pinba) Макс. время хита (тэга) – меньше M сек. Макс. использование памяти хитом – меньше N МБ
- 52. Итог
- 53. Масштабируемость под высокие нагрузки Используем связку Elastic Load Balancing + CloudWatch + Auto Scaling Очень высокая посещаемость Elastic Load Balancing Web 1 Web 2 … Web N CloudWatch + Auto Scaling
- 54. Отказоустойчивость узлов Elastic 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
- 55. Отказоустойчивость узлов Elastic 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
- 56. Отказоустойчивость ДЦ Elastic 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
- 57. Надежность «облака» Само по себе «облако» не надежнее традиционного хостинга и собственного оборудования. «Облако» дает возможность организовать надежную инфраструктуру.
- 58. Спасибо за внимание! Вопросы? Александр Сербул Александр Демидов serbul@1c-bitrix.ru demidov@1c-bitrix.ru @AlexSerbul @demidov