Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

696 views

Published on

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

Как в таком случае правильно вооружиться облачными технологиями? В чём магия AWS Autoscale и как стать магом?

Готовим приложение к горизонтальному автомасштабированию не только для производительности, но и для отказоустойчивости.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

  1. 1. Принципы автоматического масштабирования приложения в AWS Регеда Антон
  2. 2. Масштабируемость физические ресурсы системы должны быть прямо пропорциональны её производительности Ресурсы Производительность
  3. 3. Scale up • ресурсы компьютера/сети ограничены • суперкомпьютеры дорогие • низкая отказоустойчивость 2 CPU 4 CPU 64 CPU Cache server App server Database
  4. 4. Scale out • сеть лагает (timeouts everywhere) • неравномерная нагрузка • DevOps неизбежен 2 CPU 64 CPU App cluster Database 2 CPU 2 CPU Cache server
  5. 5. Автомасштабирование система самостоятельно выделяет ресурсы для своей производительности
  6. 6. Что нагружается? • CPU • Inbound traffic • Queue depth • etc.
  7. 7. Выделенные ресурсы 0 25 50 75 100 9:00 12:00 15:00 18:00 20:00 0:00 2:00 Ресурсы НагрузкаВпустую $$$
  8. 8. Выделенные ресурсы 0 35 70 105 140 9:00 12:00 15:00 18:00 20:00 0:00 2:00 Ресурсы Нагрузка Впустую $$$ Downtime
  9. 9. Облачные ресурсы 0 27.5 55 82.5 110 9:00 12:00 15:00 18:00 20:00 0:00 2:00 Ресурсы Нагрузка
  10. 10. Методологии autoscaling
  11. 11. Когда график нагрузки известен заранее
  12. 12. Основанные на времени Load balancer Server Server
  13. 13. Основанные на времени Load balancer Server Server 20:00
  14. 14. Основанные на времени Load balancer Server Server
  15. 15. Основанные на времени Load balancer Server Server Server
  16. 16. Когда нагрузка непредсказуема
  17. 17. Реагирующие на нагрузку Load balancer Server 60% Server 60%
  18. 18. Реагирующие на нагрузку Load balancer Server 80% Server 80%
  19. 19. Реагирующие на нагрузку Load balancer Server 60% Server 60% Server 40%
  20. 20. Реагирующие на нагрузку Load balancer Server 30% Server 30% Server 30%
  21. 21. Реагирующие на нагрузку Load balancer Server 45% Server 45%
  22. 22. Предсказывающие нагрузку
  23. 23. Миф №1 Автомасштабирование защитит от DDOS
  24. 24. AWS Auto scaling Магии нет!
  25. 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. 26. Scaling plans • scale up early (70% CPU in 3 min) • scale down slowly (30% CPU in 20 min) • разные стратегии для разных приложений
  27. 27. 0:00 0:10 0:20 0:30 0:40 0:50 1:00 Traffic (вчера)
  28. 28. 0:00 0:10 0:20 0:30 0:40 0:50 1:00 Traffic (сегодня) Downtime
  29. 29. 0 30 60 90 0:00 0:10 0:20 0:30 0:40 0:50 1:00 CPU (avg) Traffic (сегодня)
  30. 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. 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. 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. 33. 0 30 60 90 0:00 0:10 0:20 0:30 0:40 0:50 1:00 CPU (avg) Instances Рано! Нагрузка растёт! Я один не справлюсь! Мы не сбалансировались!
  34. 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. 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. 36. 0:00 0:10 0:20 0:30 0:40 0:50 1:00 Instances 22222 11 70 30 CPU (avg)
  37. 37. 0 1 2 0:00 0:10 0:20 0:30 0:40 0:50 1:00 Reserved On-demand
  38. 38. Приложение в условиях autoscaling
  39. 39. Deploy • Async deploy (backward compatibility, session stickness) • Оптимизируй время деплоя (ssd, gzip) • Прогревай кэш до прихода трафика (health check grace period)
  40. 40. Heartbeat • нельзя терять выделенные ресурсы • выбирай правильные условия Deployed Configured Warmed up Ready
  41. 41. Толерантность к падению • no uploads • logs in kibana/graylog • graceful shutdown (SIGTERM, SIGINT, lifecycle hooks) • use transactions
  42. 42. Сессия пользователя • Session store • Signed cookies
  43. 43. Сессия пользователя App Redis HASH:XYZ XYZ ID:1024OK Session store
  44. 44. Сессия пользователя App Redis App Session store
  45. 45. Сессия пользователя App Redis App Redis Session store
  46. 46. Сессия пользователя Signed cookies App ID:1024,HASH:XYZ OK HMAC(1024,SECRET) == XYZ
  47. 47. Сессия пользователя Signed cookies App Redis App HMAC HMAC
  48. 48. Мониторинг • Instances count • CPU, queue depth, etc. (scale condition) • Load traffic • Heartbeat steps
  49. 49. Масштабируемость ≠ производительность
  50. 50. • email: regeda@inbox.ru • twitter: @regeda Hiring!

×