• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Проектирование высоконагруженного масштабируемого веб-сервиса в облаке на примере Amazon (Александр Демидов, Александр Сербул)
 

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

on

  • 2,064 views

 

Statistics

Views

Total Views
2,064
Views on SlideShare
1,592
Embed Views
472

Actions

Likes
8
Downloads
30
Comments
1

5 Embeds 472

http://www.highload.ru 368
http://www.scoop.it 81
http://www.megaindex.tv 18
http://2012.highload.co 4
http://2012.highload.ru 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Спасибо за мастер класс! Очень понравилось!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Проектирование высоконагруженногомасштабируемого отказоустойчивого веб- сервиса в облаке на примере 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)Выбор типа машиныВыбор AZPublic / private keySecurity groupДругие опции (termination protection, набор дисков, shutdownbehavior и т.д.)
    • «Подводный камень» № 1EC2 – практически тот жеVPS Нет «волшебного ползунка», чтобы гибко задать конфигурацию – как на старте, так и в процессе работы Нет моментального вертикального масштабирования
    • «Подводный камень» № 2 steal
    • EC2 и IPec2-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 Elastic IP: 23.34.176.15EC2 EC2
    • #!/bin/shNODE_INSTANCE_ID=$1# http://aws.amazon.com/ec2/instance-types/NODE_TARGET_TYPE=m2.2xlargeNODE_ELASTIC_IP=$2ec2-stop-instances $NODE_INSTANCE_IDwhile ec2-describe-instances $NODE_INSTANCE_ID | grep -q stoppingdo sleep 5 echo Waitingdoneec2-modify-instance-attribute --instance-type $NODE_TARGET_TYPE $NODE_INSTANCE_IDec2-start-instances $NODE_INSTANCE_IDec2-associate-address $NODE_ELASTIC_IP -i $NODE_INSTANCE_ID
    • Облачные диски - EBSElastic 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Мониторинг (CloudWatch) Балансировщик (ELB) ДЦ1 ДЦ2 Группа автомасштабирования (AutoScaling) Region = группа связанных датацентров Образ машины (AMI)
    • Auto Scaling
    • Elastic Load Balancing
    • 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
    • Деплой и обновления системного ПО Как ставить Сервер Новый обновления на обновлений образ AMI нодах, не допустив рассинхрони- зации данных (веб и база)? Web 1 Elastic Load Web 2 Balancing Web N
    • Как работают обновления ПОКак ставить обновления на нодах, не допустиврассинхронизации данных (веб и база) Каждое клиентское приложение работает с собственной базой. Все обновления ставятся на выделенный instance, куда не приходит нагрузка. Из этого инстанса делается новый образ AMI. Последовательно каждая машина помечается «плохой», при этом новые веб-ноды стартуют уже из нового образа. В веб-приложении существует механизм проверки соответствия версии ПО и базы. Если клиентский запрос приходит на ноду с новым ПО, а база еще старая, по первому хиту происходит обновление.
    • База – RDS или не RDS?У Amazon есть сервис RDS (RelationalDatabase Service). Можно использоватьMySQL или Oracle. Стоит ли использовать? Недостаточно гибкая система (нет полноценного root в базе) Непрозрачно Риск долгого даунтайма Двойная стоимость машин при использовании Multi-AZ При этом – неэффективное использование ресурсов
    • Конфигурация машин 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     Диск может оказаться «узким» местом…
    • Software RAID
    • # cat /proc/partitionsmajor minor #blocks name202 16 880737792 xvdb202 144 157286400 xvdj202 128 157286400 xvdi202 112 157286400 xvdh202 96 157286400 xvdg202 0 8388608 xvda202 1 112423 xvda1202 2 5253255 xvda2202 3 3020220 xvda3202 224 524288000 xvdo202 208 157286400 xvdn202 192 157286400 xvdm202 176 157286400 xvdl202 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 ext4defaults,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_increment auto_increment_offsetБазы в разных датацентрах синхронны, при этом независимыдруг от друга: потеря связности между датацентрами можетсоставлять часы, данные синхронизируются послевосстановления.Пользователь и все сотрудники этой компании работают в одномдатацентре за счет управления балансировщиком.
    • Вертикальное масштабирование базы Для вертикального масштабирования используем slave, потом переключаем его в master Мониторим состояние master через Веб-нода CloudWatch Балансировка SQL Есть slave – минимальной конфигурации – работающий в режиме только бэкапа Elastic IP При необходимости масштабирования меняем тип машины у slave (вертикальное масштабирование) Останавливаем master, делаем slave MySQL мастером MySQL slave Переключаем IP (Amazon Elastic IP) на master машину с новым мастером Веб-ноды не требуют CloudWatch переконфигурирования и продолжают работать без даунтайма
    • Горизонтальное масштабирование базы Образ машины (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)
    • Бэкап 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) на диске консолидация бэкапов, сохранение только инкрементов
    • Бэкап MySQLРецепта «100% целостного» снепшота файлов MySQLпохоже нет, нужно колдовать Percona XtraBackup – инкрементальный бинарный бэкапНужно немало времени на подготовку бинарного бэкапа к«чистому» быстрому восстановлениюЛогический бэкап снимаем со слейвовСлучались тотальные разрушения raid10 при аварии вамазоне – бинарный бэкап (или снепшот машины) +бинлоги
    • Организация системы мониторингаЛучше – стандартные решения (Nagios, Zabbix и т.п.), а несамописные.Дежурная смена и/или мгновенные уведомления.Мониторить – всё.Но – аккуратно. Тысячи уведомлений будут бесполезны.Автоматизация типовых реакций.Мониторить систему мониторинга.В идеальном мире – распределенная система мониторинга.«Мониторинг безопасности» – изменения файлов и т.п.
    • Мониторинг операционной системы Место на дисках Очередь выполнения Размер и использование swapИ т.д.
    • Мониторинг MySQLКлючевые тесты
    • Автоматика – структура теста ЯдроNagios Тест Тест Тест Тест Тест Обработчик события Тест nagios Обработчик события Прослойка Обработчик события вспомогательного кода Pinba (PHP, bash) AWS SDK for PHP CloudWatch - автомасштабирование Утилиты AWS для консоли Обработчик события API Амазона
    • Автоматика – обработчик ЯдроNagios Обработчик события Тест Тест Тест Тест Прослойка вспомогательного кода (PHP, bash) Обработчик события Утилиты AWS AWS SDK for PHP Обработчик события для консоли Обработчик события API Амазона CloudWatch - автомасштабирование Обработчик события
    • АвтоматикаВ CloudWatch недостаточно возможностей, но используем егомаксимальноAWS SDK for PHP и вообще работа с API амазона не всегдапрямолинейна – нужна прослойкаДля основного мониторинга и активной обратной связииспользуем Nagios и его обработчики событийДля аналитики в основном используем Munin, часть данныхберем из CloudWatchПрисматриваемся к gearman, SQS
    • Аналитика
    • Аналитика – со стороны пользователя Мало знать «среднюю температуру по больнице» и мониторить только главную страницу сайта Гистограммы распределения времени хитов, памяти, кодам ответа и т.п. – из логов (awk-скрипт), pinba или других инструментов
    • Пользовательская аналитика – в графикахГистограмма времени обработки запросов (Percona)
    • Пользовательская аналитика – в графикахЧисло ошибок в хитах за 15 минут - меньше L (из pinba)Макс. время хита (тэга) – меньше M сек.Макс. использование памяти хитом – меньше N МБ
    • Итог
    • Масштабируемость под высокие нагрузкиИспользуем связку Elastic Load Balancing + CloudWatch +Auto Scaling Очень высокая посещаемость Elastic Load Balancing Web 1 Web 2 … Web N CloudWatch + Auto Scaling
    • Отказоустойчивость узлов 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
    • Отказоустойчивость узлов 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
    • Отказоустойчивость ДЦ 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
    • Надежность «облака»Само по себе «облако» ненадежнее традиционногохостинга и собственногооборудования. «Облако»дает возможностьорганизовать надежнуюинфраструктуру.
    • Спасибо за внимание! Вопросы?Александр Сербул Александр Демидовserbul@1c-bitrix.ru demidov@1c-bitrix.ru @AlexSerbul @demidov