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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Фронт загрузите ваш сайт с CloudFront, чтобы уменьшить нагрузку на хост
• Используйте клиентский хостинг в S3 для масштабирования
• Эластичный балансировщик нагрузки с группой автоматического масштабирования