AWS EC2 CPU Utilization vs PHP Performance - Autoscaling CPU Thresholds?

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

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

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

Это не позволит мне включить изображение, потому что мне нужно 10 очков репутации, поэтому, если бы кто-то мог отредактировать этот пост и сделать его встроенным изображением, я был бы признателен:

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

Интересно, каковы пороги производительности процессора EC2 при работе PHP?

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

Какие процентные пороги ЦП я должен установить для:

Когда добавлять новый экземпляр
Когда удалять лишний экземпляр

Если у кого-то есть графики производительности и загрузки процессора, это было бы замечательно.

Или мне вообще следует использовать другую метрику, чем CPU?

На этот вопрос не существует однозначного ответа. Вы захотите провести нагрузочный тест на одном узле и посмотреть, при каком использовании ЦП время отклика существенно меняется. Это может быть 90% или 10%, в зависимости от вашего приложения и того, как оно обрабатывает параллелизм. JMeter - удобный инструмент для такого рода тестов.

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

Уменьшение масштаба немного проще. Посмотрите на использование вашего среднего узла и установите цель немного ниже, чтобы, если вы увеличили масштаб или объем трафика упал, он уменьшится. Обычно для производительности лучше увеличивать масштаб с большим шагом, чем уменьшать.

Вы можете настроить оповещения CloudWatch, чтобы следить за тем, чтобы размер кластера достиг заданного значения, при этом «максимальное» значение является основным кандидатом. Это разбудит вас, если он достиг своего предела, и может потребоваться некоторое вмешательство.

У меня есть для вас несколько мыслей. Некоторые прямо отвечают на ваш вопрос, некоторые - другие вещи, которые следует учитывать.

Во-первых, PHP обычно интенсивно использует процессор. Вероятно, разумно масштабирование в зависимости от использования ЦП. Вам придется определить пороговые значения на основе вашего опыта, нагрузочного тестирования или проб и ошибок. Вероятно, вам следует быть консервативным с самого начала, понаблюдать за ним некоторое время, а затем скорректировать, чтобы получить хороший баланс использования и затрат.

Есть общие руководства по масштабированию. Это руководство предлагает масштабирование на 80% и уменьшение на 20%, тогда как это Гид по Amazon предлагает увеличение на 80% и уменьшение на 40%.

Кеширование анонимного контента может значительно снизить загрузку процессора в зависимости от приложения. Если 99% ваших пользователей анонимны, вы можете обслуживать их всех с помощью страницы, созданной один раз. Для дальнейшего снижения нагрузки и затрат вы можете использовать CDN, например CloudFront или CloudFlare, для обслуживания этого статического контента. Если вы используете CDN, вам необходимо правильно настроить заголовки кеширования.

Тщательно выбирайте типы инстансов EC2. У экземпляров T2 переменный ЦП, как только у вас закончатся кредиты, этот экземпляр немедленно замедлится. Алгоритм балансировки нагрузки «наименьшее количество соединений» должен учитывать это, но вы можете рассмотреть универсальные экземпляры M, если T2 создает проблемы.

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

Мне также интересно, можно ли иметь экземпляр T2 в вашем ELB, но затем масштабировать с помощью экземпляров M, если нагрузка увеличивается. Я думаю, вы могли бы, используя несколько групп автомасштабирования, аналогично описанной выше технике. Хотя, возможно, это не стоит того.