Трафик к нашему сервису не совсем предсказуем. Чтобы поддерживать сервис немного избыточным и заблаговременно предупреждать о любых ухудшениях работы в результате увеличения трафика, мы поддерживаем своего рода «генератор непрерывной буферной нагрузки». Это создает постоянную нагрузку на наш производственный API помимо пользовательского трафика. Если мы обнаруживаем, что сервис ухудшается, он автоматически отключается, и в идеале у нас есть немного времени, чтобы выяснить проблему и увеличить масштаб до того, как естественный пользовательский трафик совпадет с расширенным трафиком, который привел к ухудшению качества обслуживания. Буферная загрузка снова включается, когда служба снова становится стабильной.
Хотя мы называем это непрерывное генерирование трафика «непрерывным нагрузочным тестом», это кажется запутанной формулировкой и затрудняет отличия от «реальных» нагрузочных тестов (это то, что я называю экспериментами с определенным началом и концом, шаблон загрузки и двоичный результат прошел / не прошел в конце). Я почти хочу называть это «канареечным трафиком», поскольку мы отправляем дополнительный трафик, чтобы предупредить нас о проблемах до того, как с ним столкнутся наши пользователи, но это не соответствует общему пониманию значения канарейки в этой отрасли. .
Это дополнительная стратегия помимо балансировки нагрузки, автомасштабирования и т. Д. Мы не пытаемся заменить здесь какие-либо стандартные для отрасли шаги по управлению трафиком.
Я подозреваю, что это случай, когда я не знаю правильных слов для Google, поэтому:
Синтетический или активный мониторинг это термин для искусственной нагрузки, которая имитирует то, что на самом деле делает приложение. В контексте измерения производительности приложений.
Имитация реальной нагрузки - это фантастика. Однако использование значительной части ваших ресурсов в производстве неэффективно, это потребляет ресурсы. Что еще более важно, механизм автоматического отключения становится критически важным для поддержания хорошей производительности. Вместо этого постоянно снижайте скорость до минимального уровня и продолжайте измерять время отклика и частоту ошибок. Никогда не прекращайте измерения, поскольку деградация покажет влияние событий на пользователя.
Реалистичные генераторы нагрузки хороши для тестирования и планирования мощности. Подготовьте другой размер вычислительного экземпляра в тестовой среде и поддерживайте нагрузку, пока она не упадет. В рамках теста высокой доступности или последовательного обновления временно добавьте некоторую нагрузку, чтобы проверить, что в противном случае система не работала.
Решите, что цель времени отклика является. Узнайте, сколько запросов в секунду безопасно. Установите автоматическое масштабирование или оповещения при определенных пороговых значениях.
Измерение целевых уровней обслуживания, а также знание ограничений предоставят вам инструменты для правильного планирования ресурсов. Без искусственного сжигания буферной емкости.