Автоматическое масштабирование AWS не работает / загрузка ЦП остается ниже 30%

Question

Я настроил AWS AutoScaling следующим образом:

1) создал балансировщик нагрузки и зарегистрировал на нем один экземпляр;
2) добавлены проверки здоровья в ELB;
3) добавлено 2 тревоги:
- загрузка процессора -> 60% в течение 60 с, раскрутить 1 экземпляр;
- загрузка ЦП
4) написал скрипт jMeter для отправки трафика на рассматриваемый веб-сайт: 250 потоков, время нарастания 200 секунд, количество циклов 5.

То, что я вижу, было очень странно.

Я ожидаю, что загрузка ЦП будет расти с ростом числа пользователей. Но вместо этого загрузка ЦП остается на уровне 20-30% (именно поэтому новый экземпляр никогда не запускается), и запущенный экземпляр начинает выдавать ошибки тайм-аута, когда он достигает значения, превышающего 100 пользователей.

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

Идеи

Answer 1

Похоже, вы тестируете AutoScaling, чтобы убедиться, что он будет работать для ваших нужд.В качестве первого шага, чтобы просто увидеть, запустит ли AS новый экземпляр, попробуйте уменьшить проверку загрузки процессора до 25%.Я понимаю, что это намного ниже, чем вы надеетесь использовать для продвижения вперед, но это поможет проверить работоспособность вашей первоначальной конфигурации.

В качестве второго шага вы должны взглянуть на свое приложение и посмотреть,CPU - лучший показатель для масштабирования монитора AS.Возможно, что где-то в вашем приложении есть узкое место, которое не обязательно связано с процессором (настройка веб-сервера, память, базы данных, хранилище и т. Д.).Вы не упомянули, какой тип контента вы раздаете;это статическое или генерируется интерпретатором (например, PHP или что-то еще)?Вы также можете отправить свои собственные данные метрики в CloudWatch и использовать эту метрику для запуска масштабирования.

Вы также можете указать время, необходимое для того, чтобы экземпляр был готов обслуживать трафик с холодного старта.Если это занимает более 60 секунд, вы можете соответствующим образом настроить пороговое время мониторинга (или установить периоды охлаждения).Как отметил Чантеман, для ELB может потребоваться некоторое время, чтобы также зарегистрировать экземпляр (и больше времени, если новый экземпляр находится в другом AZ).

Надеюсь, все это поможет.

Answer 2

Мы обнаружили, что когда вы используете автоматическое масштабирование в экземплярах t2 и при большой нагрузке, эти экземпляры исчерпывают кредиты ЦП, а затем они ограничиваются 20% ЦП (с точки зрения мониторинга, внутренний htopвсе еще 100%).Внутренне они находятся в режиме максимальной нагрузки.

Это отправляет ложную метрику в автоматическое масштабирование, и экземпляры новостей не срабатывают.

Вам необходимо изменить метрику или разработать собственную или перейти к m экземплярам.

Answer 3

Это может быть проблемой с ELB.ELB не масштабируется очень быстро, ему требуется постоянный объем трафика, чтобы позволить Amazon узнать, что вам нужно больше.Если вы просто сильно ударили по нему сразу, это не поможет масштабироваться.Так что у ELB могут быть проблемы с обработкой всех соединений.

Это SSL?Вы делаете SSL на ELB?Это также добавит накладные расходы к недооцененному ELB.

Я бы честно рекомендовал вообще не использовать ELB.haproxy - намного лучший продукт и в большинстве случаев гораздо быстрее.Я могу уточнить, если нужно, но просто посмотрите, как Amazon обрабатывает cname против того, что вы можете делать с haproxy ...