Embed Size (px)
Citation preview
Принципы автоматического масштабирования приложения в AWSРегеда Антон
Масштабируемостьфизические ресурсы системы должны быть прямо пропорциональны её производительности
Ресурсы
Производительность
Scale up• ресурсы компьютера/сети ограничены • суперкомпьютеры дорогие • низкая отказоустойчивость
2 CPU
4 CPU
64 CPU
Cache server
App server
Database
Scale out• сеть лагает (timeouts everywhere) • неравномерная нагрузка • DevOps неизбежен
2 CPU
64 CPU
App cluster
Database
2 CPU
2 CPU
Cache server
Автомасштабированиесистема самостоятельно выделяет ресурсы для своей производительности
Что нагружается?• CPU • Inbound traffic • Queue depth • etc.
Выделенные ресурсы
0
25
50
75
100
9:00 12:00 15:00 18:00 20:00 0:00 2:00
Ресурсы
НагрузкаВпустую$$$
Выделенные ресурсы
0
35
70
105
140
9:00 12:00 15:00 18:00 20:00 0:00 2:00
Ресурсы
Нагрузка
Впустую$$$
Downtime
Облачные ресурсы
0
27.5
55
82.5
110
9:00 12:00 15:00 18:00 20:00 0:00 2:00
Ресурсы
Нагрузка
Методологии autoscaling
Когда график нагрузки известен заранее
Основанные на времени
Load balancer
Server Server
Основанные на времени
Load balancer
Server Server
20:00
Основанные на времени
Load balancer
Server Server
Основанные на времени
Load balancer
Server Server Server
Когда нагрузка непредсказуема
Реагирующие на нагрузку
Load balancer
Server 60%
Server 60%
Реагирующие на нагрузку
Load balancer
Server 80%
Server 80%
Реагирующие на нагрузку
Load balancer
Server 60%
Server 60%
Server 40%
Реагирующие на нагрузку
Load balancer
Server 30%
Server 30%
Server 30%
Реагирующие на нагрузку
Load balancer
Server 45%
Server 45%
Предсказывающие нагрузку
Миф №1Автомасштабирование
защитит от DDOS
AWS Auto scalingМагии нет!
Архитектура AWS Auto scaling
Elastic Load
Balancer
Auto scaling group
EC2 Instance
EC2 Instance
…
Amazon CloudWatch
Scale up Rule
Scale down Rule
Scale up
Scale down
Основные понятия
Groups Launch configurations Scaling plans
Scaling plans• scale up early (70% CPU in 3 min) • scale down slowly (30% CPU in 20 min) • разные стратегии для разных приложений
0:00 0:10 0:20 0:30 0:40 0:50 1:00
Traffic (вчера)
0:00 0:10 0:20 0:30 0:40 0:50 1:00
Traffic (сегодня)
Downtime
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Traffic (сегодня)
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
222
1
2
11
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
70
50
Scaling Plan
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
Alert!
Alert!
Alert!
Alert! Alert!
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
Рано! Нагрузка растёт!
Я один не справлюсь!
Мы не сбалансировались!
$$$
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
222
1
2
11
0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
222
1
2
11
70
50
0:00 0:10 0:20 0:30 0:40 0:50 1:00
Instances
22222
11
70
30
CPU (avg)
0
1
2
0:00 0:10 0:20 0:30 0:40 0:50 1:00
Reserved On-demand
Приложение в условиях autoscaling
Deploy• Async deploy (backward compatibility, session stickness) • Оптимизируй время деплоя (ssd, gzip) • Прогревай кэш до прихода трафика (health check grace
period)
Heartbeat• нельзя терять выделенные ресурсы • выбирай правильные условия
Deployed Configured Warmed up Ready
Толерантность к падению• no uploads • logs in kibana/graylog • graceful shutdown (SIGTERM, SIGINT, lifecycle hooks) • use transactions
Сессия пользователя• Session store • Signed cookies
Сессия пользователя
App Redis
HASH:XYZ XYZ
ID:1024OK
Session store
Сессия пользователя
AppRedis
App
Session store
Сессия пользователя
App Redis
App Redis
Session store
Сессия пользователяSigned cookies
AppID:1024,HASH:XYZ
OK HMAC(1024,SECRET) == XYZ
Сессия пользователяSigned cookies
AppRedis
App
HMAC
HMAC
Мониторинг• Instances count • CPU, queue depth, etc. (scale condition) • Load traffic • Heartbeat steps
Масштабируемость ≠ производительность
