Как предотвратить объятия смерти на инстансе EC2?


9

У меня есть приложение для iOS в магазине приложений, и недавно я получил огромный приток трафика на мою целевую страницу, размещенную на EC2, и в результате страница не отвечает, к счастью, мне удалось восстановить ее, перезапустив и обновив экземпляр до t2.medium.

Теперь я ищу кого-то, чтобы внедрить технологию, которая предотвратит ту же смерть снова. Мой опыт только расширяется, что позволяет мне понимать основные вещи devops, но недостаточно для балансировки нагрузки в AWS, я хочу знать, что является доступной реализацией для моего экземпляра.

Моя целевая страница и серверная часть приложения iOS размещаются в одном экземпляре.


1
Ваша целевая страница статична?
Майкл - sqlbot

Ответы:


8

Если вы хотите что-то быстро разобрать без особого знания, я бы порекомендовал эластичный бобовый стебель. Это еще одно приложение AWS, которое будет обрабатывать конфигурацию балансировщика нагрузки и масштабирование экземпляров.

Никаких дополнительных затрат на балансировщик нагрузки и экземпляры не требуется, так что вы можете продолжать использовать экземпляры типа t2, но позволяйте гибкому бобовому стеблю масштабировать столько, сколько вы хотите помочь.

Автоматическое масштабирование не является мгновенным, и во время скачков трафика для обработки скачка потребуется небольшое время, обычно минуты, но это будет намного лучше, чем ручное масштабирование размера экземпляра, и его действительно легко получить в руки с.


1

Я бы порекомендовал автоматическое масштабирование, как упомянуто выше, с добавлением некоторых сигналов тревоги CloudWatch, чтобы запустить процесс автоматического масштабирования, когда конкретные пороговые значения начинают увеличиваться, а не тогда, когда это уже слишком далеко.

Например; настройте CloudWatch для мониторинга вашего сервера, когда загрузка процессора составляет 50% или более в течение 30 секунд или более, запустите процесс автоматического масштабирования.

Это может быть не совсем безупречно, но это легко сделать с помощью некоторых онлайн-руководств и все настраивается через графический интерфейс.

Кроме того, если ваша целевая страница статична, почему бы не разместить ее на свободном уровне t2.micro и использовать другой бесплатный уровень t2.micro для своего приложения?


Автоматическое масштабирование не является целостным ответом при внезапном увеличении трафика. Окно обнаружения автоматического масштабирования находится где-то между 1-5 минутами, в зависимости от вашей подготовки, это может занять некоторое время. Как правило, правильный ответ - запускать экземпляры в горячем режиме, т. Е. Превышать предполагаемый уровень трафика и разрешать автоматическое масштабирование для поддержания этого запаса.
Мэтт О.

1

Я хотел бы помочь с этим, если вы ищете помощь. В зависимости от вашей страницы вам может не понадобиться ec2 вообще. Например, если вы предлагаете что-то статичное или JavaScript, оно может обслуживаться из s3 с помощью облачного фронта. Или мы могли бы использовать группу автоматического масштабирования, если это абсолютно необходимо.


1

Существует две основные стратегии борьбы с скачками трафика: увеличение пропускной способности и снижение затрат.

Увеличение емкости означает автоматическое масштабирование, которое очень взволновало всех, когда впервые появились общедоступные облака. В самом простом смысле это загрузит больше веб-серверов для вас в зависимости от нагрузки и добавит их в балансировщик нагрузки, но, поскольку управление может быть затруднено, есть и более автоматические решения, такие как Elastic Beanstalk.

Проблема с автоматическим расширением емкости заключается в том, что его автоматическое расширение счета - 10x нормальный трафик означает, что 10x серверов означает 10x денег, которые вы должны заплатить. Вот почему, несмотря на полезную стратегию, я думаю, вы всегда должны начинать с того, чтобы узнать, сколько вы можете обмануть.

Под читом я подразумеваю кеш, который основывается на идее, что большую часть времени вы можете дать пользователям немного устаревшие данные, а они не заметят, и это может сэкономить вам огромное количество времени. Представьте, что у вас есть страница, с которой вы решаете, что все в порядке, если она устарела на пять секунд и получает 20 запросов в секунду. Без кеширования вы выполняете этот расчет 1200 раз в минуту, тогда как при кешировании - только 12. Вы можете увидеть, как это может иметь огромное значение.

Существует, конечно, много типов кэширования, и успешный сайт будет использовать несколько из них. Но для вашего случая есть два довольно хороших и простых варианта.

Первое - сделать сайт полностью статичным. Это предполагает, что вы можете сделать это, но если вы можете, тогда у вас просто есть Nginx, обслуживающий html напрямую, и он может обслуживать тонны запросов без пота.

Если вам нужен какой-то уровень динамичности, тогда неплохое выполнение кэширования на всю страницу является хорошим вариантом. У Nginx есть некоторые возможности сделать это, но мне очень нравится Varnish из-за его гибкости.

Какой бы вариант или опции вы не использовали, убедитесь, что вы выполняете нагрузочное тестирование, чтобы убедиться, что вы его правильно настроили; иногда исправление одного пятна обнажает новое узкое место.


0

Я хотел бы поделиться нашим опытом с AWS. Мы развернули наше приложение на EC2 и столкнулись с той же проблемой и высокой стоимостью. Мы развернули наше приложение Amazon EC2 Container Service, хотя наше приложение было монолитным, но мы достигли

  • Доступность
  • Экономически эффективным
  • Масштабируемость

Балансировщик нагрузки приложения будет обрабатывать трафик и направлять трафик на работоспособный экземпляр, и вы сможете запускать несколько задач одних и тех же служб, не беспокоясь о масштабировании и балансировке нагрузки.

Эта архитектура облегчает реализацию изоляции отказов. Такие методы, как проверка работоспособности, кэширование, переборки или автоматические выключатели, позволяют уменьшить радиус взрыва неисправного компонента и повысить общую доступность данного приложения.


Для ECS нет отдельной цены , только основные ресурсы EC2, так как же использование ECS было более рентабельным? Он должен потреблять одинаковое количество ресурсов, независимо от того, управляете ли вы контейнерами самостоятельно или разрешаете Amazon это делать.
бойкот SE для Моники

в контейнере, если вы используете Alpine, который составляет 5 МБ, а ec2 вы используете Ubuntu, который составляет 2 ГБ? какая вещь лучше? в t2 micro вы можете запускать 5 php-контейнер с масштабированием и выходом на основе трафика. Можете ли вы работать в ec2 с масштабированием и масштабированием?
Adiii

Вам не нужно использовать Ubuntu для экземпляров ec2; Вы можете загрузить изображение Alpine и использовать его, если хотите. Если у вас есть все, что работает с ECS, это здорово, и вряд ли вы захотите вернуться назад, но я хочу сказать, что простой переход на ECS не делает приложение более масштабируемым или экономически эффективным; это другие изменения, которые вы внесли в приложение, инфраструктуру и архитектуру одновременно с этим.
бойкот SE для Моники

0

Это во многом зависит от конкретной архитектуры, но, например:

  • Фронт загрузите ваш сайт с CloudFront, чтобы уменьшить нагрузку на хост
  • Используйте клиентский хостинг в S3 для масштабирования
  • Эластичный балансировщик нагрузки с группой автоматического масштабирования
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.