Your SlideShare is downloading. ×
  • Like
Проектирование высоконагруженного масштабируемого веб-сервиса в облаке на примере Amazon (Александр Демидов, Александр Сербул)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 1,942 views
Published

 

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

Views

Total Views
1,942
On SlideShare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
33
Comments
1
Likes
8

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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)Выбор типа машиныВыбор AZPublic / private keySecurity groupДругие опции (termination protection, набор дисков, shutdownbehavior и т.д.)
  • 9. «Подводный камень» № 1EC2 – практически тот жеVPS Нет «волшебного ползунка», чтобы гибко задать конфигурацию – как на старте, так и в процессе работы Нет моментального вертикального масштабирования
  • 10. «Подводный камень» № 2 steal
  • 11. 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
  • 12. Elastic IP Elastic IP: 23.34.176.15EC2 EC2
  • 13. #!/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
  • 14. Облачные диски - EBSElastic 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
  • 19. Elastic Load Balancing
  • 20. Elastic Load Balancing
  • 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. Интеграция приложения с S3API хранилища для «прозрачной» работы с файламиAPI для разработчиков (не используем стандартныефункции для работы с файлами)Избегаем «диких» файлов«Прозрачность» для всех модулей системыТаблица с данными обо всех подключенных хранилищахТаблица со списком файлов, и указанием, где они хранятся(можно сразу хранить дополнительную информацию)Не используем file_size, getimagesize и т.п. – сохраняем вседанные при аплоаде
  • 25. S3 + CDNВеб-сервер
  • 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 (RelationalDatabase 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/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
  • 33. # 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
  • 34. Software RAID – тесты sysbenchРежим random read/write. При увеличении количества потоковединичный диск почти сразу достигает «потолка»,производительность RAID растет.
  • 35. MySQL? Percona Server!Оптимизирован для работы с медленными дискамиБыстрый рестарт базы (Fast Shut-Down, Buffer Pool Pre-Load)Множество счетчиков и расширенных отчетовXtraDB Storage EngineXtraBackupBLOB, 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И т.д.
  • 44. Мониторинг MySQLКлючевые тесты
  • 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