Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Так как облачные приложения и службы становятся более сложными, развертывание изменений и новых выпусков для них может быть сложной задачей. Сбои часто вызываются неисправными развертываниями или выпусками. Но ошибки также могут возникать после развертывания, когда приложение начинает получать реальный трафик, особенно в сложных рабочих нагрузках, работающих в высокораспространяемых мультитенантных облачных средах и поддерживаемых несколькими командами разработчиков. В этих средах требуется больше мер устойчивости, таких как логика повторных попыток и автомасштабирование, которые обычно трудно протестировать во время процесса разработки.
Именно поэтому непрерывная проверка в среде, которая похожа на рабочую среду, важна, чтобы можно было найти и устранить все проблемы или ошибки как можно раньше в цикле разработки. Команды, работающие с нагрузкой, должны проводить тестирование на ранних этапах процесса разработки, перенося его на более ранний этап, и сделать процесс удобным для разработчиков, чтобы проводить тестирование в среде, близкой к производственной среде.
Критически важные рабочие нагрузки имеют требования к доступности с целевыми показателями 3, 4 или 5 девяток (99,9%, 99,99%или 99,999%соответственно). Важно реализовать тщательное автоматизированное тестирование для достижения этих целей.
Непрерывная проверка зависит от каждой рабочей нагрузки и от архитектурных характеристик. В этой статье приведено руководство по подготовке и интеграции Azure Load Testing и Azure Chaos Studio в обычный цикл разработки.
1. Определение тестов на основе ожидаемых пороговых значений
Непрерывное тестирование — это сложный процесс, требующий надлежащей подготовки. Что проверяется и ожидаемые результаты должны быть ясными.
В PE:06 — рекомендации по тестированию производительности и RE:08 — рекомендации по проектированию стратегии тестирования надежности, платформа Azure Well-Architected Framework рекомендует начать с определения ключевых сценариев, зависимостей, ожидаемого использования, доступности, производительности и целевых показателей масштабируемости.
Затем необходимо определить набор измеримых пороговых значений , чтобы оценить ожидаемую производительность ключевых сценариев.
Подсказка
Примеры пороговых значений включают ожидаемое количество входов пользователей, запросов в секунду для заданного API и операций в секунду для фонового процесса.
Для разработки модели работоспособности приложения следует использовать пороговые значения, как для тестирования, так и для работы приложения в рабочей среде.
Затем используйте значения, чтобы определить нагрузочный тест , который создает реалистичный трафик для тестирования базовой производительности приложения и для проверки ожидаемых операций масштабирования. Устойчивый искусственный трафик пользователей необходим в предварительной среде, так как без использования трудно выявить проблемы со средой выполнения.
Нагрузочное тестирование гарантирует, что изменения, внесенные в приложение или инфраструктуру, не вызывают проблем, и система по-прежнему соответствует ожидаемым критериям производительности и тестирования. Сбой тестового запуска, который не соответствует критериям теста, указывает, что необходимо настроить базовый план или произошла непредвиденная ошибка.
Несмотря на то, что автоматические тесты представляют ежедневное использование, следует регулярно запускать нагрузочные тесты вручную , чтобы проверить, как система реагирует на непредвиденные пики.
Второй частью непрерывной проверки является внедрение сбоев (инженерия хаоса). На этом шаге проверяется устойчивость системы, проверяя, как она реагирует на ошибки. Кроме того, все меры устойчивости, такие как логика повторных попыток, автомасштабирование и другие, работают должным образом.
2. Реализация проверки с помощью Load Testing и Chaos Studio
Microsoft Azure предоставляет эти управляемые службы для реализации нагрузочного тестирования и проектирования хаоса:
- Нагрузочное тестирование Azure создает синтетическую нагрузку пользователей на приложения и службы.
- Azure Chaos Studio предоставляет возможность выполнять эксперименты с хаосом, систематически внедряя сбои в компоненты приложений и инфраструктуру.
Вы можете развернуть и настроить Студию Хаоса и нагрузочное тестирование с помощью портала Azure, но в контексте непрерывной проверки более важно, чтобы у вас есть API для развертывания, настройки и запуска тестов программным и автоматизированным способом. Использование этих двух средств позволяет наблюдать, как система реагирует на проблемы и ее способность самостоятельно исцеляться в ответ на ошибки инфраструктуры или приложений.
В следующем видео показана объединенная реализация Chaos и Load Testing , интегрированная в Azure DevOps:
Если вы разрабатываете критически важную рабочую нагрузку, воспользуйтесь подробными рекомендациями, предоставленными в рамках Azure Well-Architected Framework.
Одним из вариантов является выполнение нагрузочного теста непосредственно из сквозного конвейера (e2e), который используется для развертывания отдельных (специфичных для ветвей) сред разработки.
Конвейер автоматически запускает нагрузочный тест с экспериментами хаоса или без них (в зависимости от выбора) в параллельном режиме.
Замечание
Выполнение экспериментов хаоса во время нагрузочного теста может привести к увеличению задержки, увеличению времени отклика и временному увеличению частоты ошибок. Ожидается более высокое время отклика и задержки до завершения операции горизонтального масштабирования или перехода на резервный источник по сравнению с выполнением без экспериментов хаоса.
В зависимости от того, включено ли тестирование хаоса и выбор экспериментов, определения базовых показателей могут отличаться, так как допустимость ошибок может отличаться в "обычном" состоянии и "хаосе".
3. Настройка пороговых значений и установка базовых показателей
Наконец, настройте пороговые значения нагрузочного теста для регулярных запусков , чтобы убедиться, что приложение (по-прежнему) обеспечивает ожидаемую производительность и не создает никаких ошибок. Иметь отдельную базовую линию для тестирования на хаос, которая допускает ожидаемые пики частоты ошибок и временное снижение производительности. Это действие непрерывно и должно повторяться регулярно. Например, после внедрения новых функций, изменения спецификаций услуг (SKU) и других изменений.
Служба нагрузочного тестирования Azure предоставляет встроенную возможность, называемую критериями тестирования , которые позволяют указать определенные критерии, необходимые для прохождения теста. Эту возможность можно использовать для реализации различных базовых показателей.
Эта возможность доступна через портал Azure, а также через API нагрузочного тестирования и скрипты-оболочки, разработанные в рамках миссии Azure, предоставляют возможность передачи определения базовых показателей на основе JSON.
Мы настоятельно рекомендуем интегрировать эти тесты непосредственно в конвейеры CI/CD и запускать их на ранних этапах разработки компонентов.
В итоге, сбой неизбежен в любой сложной распределенной системе, поэтому решение должно быть спроектировано (и протестировано) для обработки сбоев. Рекомендации по критически важным рабочим нагрузкамWell-Architected Framework и эталонные реализации помогут вам разработать и управлять высоконадежными приложениями, чтобы получить максимальное значение из облака Майкрософт.
Следующий шаг
Пересмотрите область проектирования развертывания и тестирования для миссионно-критических рабочих нагрузок.