Представьте нагрузочный тест сервиса с автоскейлингом: после роста задержки система добавляет экземпляры, а p95 возвращается к целевому уровню. Какой вывод о производительности будет некорректен?
Нельзя считать восстановление p95 доказательством того, что исходная конфигурация выдерживает нагрузку. Автоскейлинг изменил доступную мощность системы, поэтому нужно отдельно оценить производительность фиксированной конфигурации и эффективность масштабирования.
Классические нагрузочные тесты часто проводились на фиксированном наборе серверов: нагрузка изменялась, а ресурсы оставались постоянными. В эластичных инфраструктурах этого недостаточно, потому что сама система может менять число экземпляров в ответ на нагрузку.
Разделение этих аспектов появилось как практический способ отличить базовую емкость сервиса от поведения механизма автоматического масштабирования. Такой подход помогает оценивать не только скорость обработки, но и время реакции инфраструктуры на перегрузку.
Если во время теста автоскейлинг добавляет экземпляры, результат становится измерением составной системы: приложения, политики масштабирования, времени запуска экземпляров и балансировщика. Сравнение такого прогона с тестом фиксированной конфигурации может быть некорректным.
Ошибочный вывод выглядит так: «сервис выдерживает целевую нагрузку, потому что после роста задержки p95 снова стал приемлемым». На самом деле исходная конфигурация могла быть уже насыщена, а временный рост задержки мог нарушить SLA до появления новых экземпляров.
Сначала следует определить, что именно измеряется: фиксированная производительность или эластичность. Для фиксированной производительности автоскейлинг отключают либо фиксируют число экземпляров, после чего находят максимальную устойчивую нагрузку при заданном SLA.
Для оценки эластичности отдельно фиксируют момент и причину масштабирования, число экземпляров, время запуска новых ресурсов, период стабилизации, задержку до восстановления SLA и ошибки во время переходного процесса. Важно анализировать временные ряды, а не только итоговые средние значения за весь тест.
Нужно сопоставлять как минимум следующие показатели:
Пиковая нагрузка может быть допустимой для эластичной системы, если SLA допускает время масштабирования. Если же SLA распространяется на весь период, включая реакцию на всплеск, кратковременное нарушение нельзя скрывать усреднением после стабилизации.
Есть два важных компромисса. Отключение автоскейлинга упрощает измерение базовой емкости, но не показывает поведение production-системы. Включение автоскейлинга делает сценарий реалистичнее, но добавляет переменные: пороги, задержки, ограничения квот, стоимость ресурсов и возможные колебания числа экземпляров.
Сервис тестировали при постоянном росте нагрузки. На шести экземплярах p95 превысил SLA, затем автоскейлинг увеличил их число до десяти, после чего p95 нормализовался.
Рассматривались два варианта. Первый — считать тест успешным по итоговому p95; это быстро, но скрывает период нарушения SLA и не показывает предел шести экземпляров. Второй — разделить тест на два прогона: сначала измерить фиксированную конфигурацию, затем отдельно проверить масштабирование; такой вариант требует больше времени, зато позволяет оценить базовую емкость и время восстановления.
Выбрали второй вариант. В фиксированном прогоне определили предел конфигурации в шесть экземпляров, а в эластичном измерили задержку восстановления, ошибки во время добавления ресурсов и стоимость обслуживания нагрузки. В результате команда получила не ошибочный вывод «сервис выдерживает нагрузку», а две проверяемые характеристики: емкость начальной конфигурации и качество масштабирования.
1. Нужно ли считать нагрузочный тест успешным, если после масштабирования SLA выполняется?
Только если заранее определено, что SLA допускает переходный период с нарушением показателей. Иначе нужно учитывать весь интервал теста, включая время до запуска новых экземпляров, прогрев приложения и перераспределение трафика.
2. Почему нельзя сравнивать версии сервиса по p95, если автоскейлинг сработал в разное время?
Потому что версии могли работать при разном числе экземпляров и разной длительности периода насыщения. Более позднее масштабирование одной версии увеличит её задержку и ошибки, даже если после стабилизации её обработка на одном экземпляре не хуже; для корректного сравнения нужны одинаковые правила масштабирования либо фиксированная конфигурация.
3. Как отличить улучшение приложения от более агрессивного масштабирования?
Нужно сравнить версии при одинаковом числе экземпляров и одинаковой нагрузке, а затем отдельно сравнить их эластичность. Полезно анализировать производительность на экземпляр, момент срабатывания политики, время добавления ресурсов и число экземпляров в каждый момент; одно лишь снижение общей задержки не показывает, какой фактор дал эффект.