В большинстве случаев нагрузка на приложение в течение дня непостоянная: ночью пользователи спят, а днём сервер работает на пике своих возможностей. Поэтому мощности выделяются под максимальную нагрузку и в 60% случаях простаивают. Как в таком случае правильно вооружиться облачными технологиями? В чём магия AWS Autoscale и как стать магом? Готовим приложение к горизонтальному автомасштабированию не только для производительности, но и для отказоустойчивости.

1. Принципы автоматического
масштабирования
приложения в AWS
Регеда Антон

2. Масштабируемость
физические ресурсы системы должны
быть прямо пропорциональны её
производительности
Ресурсы
Производительность

3. Scale up
• ресурсы компьютера/сети ограничены
• суперкомпьютеры дорогие
• низкая отказоустойчивость
2 CPU
4 CPU
64 CPU
Cache server
App server
Database

4. Scale out
• сеть лагает (timeouts everywhere)
• неравномерная нагрузка
• DevOps неизбежен
2 CPU
64 CPU
App cluster
Database
2 CPU
2 CPU
Cache server

5. Автомасштабирование
система самостоятельно выделяет ресурсы для своей
производительности

6. Что нагружается?
• CPU
• Inbound traffic
• Queue depth
• etc.

7. Выделенные ресурсы
0
25
50
75
100
9:00 12:00 15:00 18:00 20:00 0:00 2:00
Ресурсы
НагрузкаВпустую
$$$

8. Выделенные ресурсы
0
35
70
105
140
9:00 12:00 15:00 18:00 20:00 0:00 2:00
Ресурсы
Нагрузка
Впустую
$$$
Downtime

9. Облачные ресурсы
0
27.5
55
82.5
110
9:00 12:00 15:00 18:00 20:00 0:00 2:00
Ресурсы
Нагрузка

10. Методологии autoscaling

11. Когда график
нагрузки
известен
заранее

12. Основанные на времени
Load balancer
Server Server

13. Основанные на времени
Load balancer
Server Server
20:00

14. Основанные на времени
Load balancer
Server Server

15. Основанные на времени
Load balancer
Server Server Server

16. Когда нагрузка
непредсказуема

17. Реагирующие на нагрузку
Load balancer
Server
60%
Server
60%

18. Реагирующие на нагрузку
Load balancer
Server
80%
Server
80%

19. Реагирующие на нагрузку
Load balancer
Server
60%
Server
60%
Server
40%

20. Реагирующие на нагрузку
Load balancer
Server
30%
Server
30%
Server
30%

21. Реагирующие на нагрузку
Load balancer
Server
45%
Server
45%

22. Предсказывающие нагрузку

23. Миф №1
Автомасштабирование
защитит от DDOS

24. AWS Auto scaling
Магии нет!

25. Архитектура 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

26. Scaling plans
• scale up early (70% CPU in 3 min)
• scale down slowly (30% CPU in 20 min)
• разные стратегии для разных приложений

27. 0:00 0:10 0:20 0:30 0:40 0:50 1:00
Traffic (вчера)

28. 0:00 0:10 0:20 0:30 0:40 0:50 1:00
Traffic (сегодня)
Downtime

29. 0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Traffic (сегодня)

30. 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

31. 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

32. 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!

33. 0
30
60
90
0:00 0:10 0:20 0:30 0:40 0:50 1:00
CPU (avg) Instances
Рано! Нагрузка растёт!
Я один
не справлюсь!
Мы не
сбалансировались!

34. $$$
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

35. 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

36. 0:00 0:10 0:20 0:30 0:40 0:50 1:00
Instances
22222
11
70
30
CPU (avg)

37. 0
1
2
0:00 0:10 0:20 0:30 0:40 0:50 1:00
Reserved On-demand

38. Приложение в условиях autoscaling

39. Deploy
• Async deploy (backward compatibility, session stickness)
• Оптимизируй время деплоя (ssd, gzip)
• Прогревай кэш до прихода трафика (health check grace
period)

40. Heartbeat
• нельзя терять выделенные ресурсы
• выбирай правильные условия
Deployed Configured Warmed up Ready

41. Толерантность к падению
• no uploads
• logs in kibana/graylog
• graceful shutdown (SIGTERM, SIGINT, lifecycle hooks)
• use transactions

42. Сессия пользователя
• Session store
• Signed cookies

43. Сессия пользователя
App Redis
HASH:XYZ XYZ
ID:1024OK
Session store

44. Сессия пользователя
App
Redis
App
Session store

45. Сессия пользователя
App Redis
App Redis
Session store

46. Сессия пользователя
Signed cookies
App
ID:1024,HASH:XYZ
OK HMAC(1024,SECRET) == XYZ

47. Сессия пользователя
Signed cookies
App
Redis
App
HMAC
HMAC

48. Мониторинг
• Instances count
• CPU, queue depth, etc. (scale condition)
• Load traffic
• Heartbeat steps

49. Масштабируемость ≠ производительность

50. • email: regeda@inbox.ru
• twitter: @regeda
Hiring!