Прямой ответ
Теневой трафик (traffic mirroring) — копирование продуктивных запросов на новую версию без возврата её ответов пользователям. Новая версия обрабатывает реальные запросы, а пользователь получает ответ от текущей версии и не замечает проверки.
Отличие от других подходов:
| Подход | Кто видит ответ новой версии | Риск для пользователя |
|---|---|---|
| Нагрузочное тестирование | Никто (синтетические запросы) | Нет |
| Теневой трафик | Никто (реальные запросы) | Нет |
| Канареечное развёртывание | Часть пользователей | Ограничен долей |
| Полное развёртывание | Все пользователи | Полный |
Ценность теневого трафика в том, что запросы реальные: они содержат настоящие данные, неожиданные форматы и распределение нагрузки, которое сложно воспроизвести синтетически. Синтетический тест проверяет ожидаемое поведение, теневой трафик — поведение на реальных входных данных; о синтетике — в статье про Locust.
В Istio зеркалирование настраивается правилом маршрутизации:
apiVersion: networking.istio.io/v1
kind: VirtualService
spec:
hosts: ["orders"]
http:
- route:
- destination: {host: orders, subset: v1}
weight: 100
mirror:
host: orders
subset: v2
mirror_percentage: {value: 10}
Ответы зеркальной версии отбрасываются, поэтому пользователь их не видит; о механизмах mesh — в статье про Istio.
Главный риск — побочные эффекты. Зеркальный запрос, выполняющий запись, создаёт дубли данных либо отправляет уведомление пользователю. Поэтому для зеркальной версии обязательны три условия:
1. Запись в базу отключена либо идёт в отдельный экземпляр.
2. Внешние вызовы (почта, платежи, SMS) подменены заглушками.
3. Публикация событий в очередь отключена.
Второй риск — данные. Зеркальный трафик содержит персональные данные, поэтому копия должна попадать в среду с тем же уровнем защиты либо данные обезличиваются; о требованиях — в статье про 152-ФЗ и GDPR.
Ограничения подхода и когда он не применим
Теневой трафик решает не все задачи проверки, и его ограничения стоит учитывать до настройки.
Проверка не покрывает состояние. Зеркальные запросы выполняются без записи, поэтому поведение при конфликте обновлений, блокировках и транзакциях не проверяется. Для этого нужны интеграционные тесты с реальной базой.
Результат зависит от состава трафика. Если проверяемая функциональность вызывается редко, доля зеркалирования может не включать нужные запросы. В таком случае доля увеличивается либо трафик отбирается по типу операции.
Нагрузка на зависимости растёт. Зеркальный трафик увеличивает число запросов к базе и внешним системам, что требует учёта при планировании ёмкости.
Сравнение ответов требует эталона. Если новая версия должна изменить ответ намеренно, расхождение не является ошибкой. Перечень ожидаемых изменений фиксируется до начала проверки.
Персональные данные попадают в копию. Зеркалирование передаёт данные в другую среду, поэтому уровень защиты копии должен соответствовать оригиналу либо данные обезличиваются.
При наличии этих ограничений теневой трафик остаётся полезным дополнением к тестам, а не заменой: он проверяет поведение на реальных входных данных, но не заменяет проверку состояний и транзакций.
Практика: настройка проверки теневым трафиком
1. Отключите побочные эффекты в зеркальной версии. Запись, внешние вызовы и публикация событий отключаются через конфигурацию, а не полагаются на отсутствие вызова в коде.
2. Используйте отдельную базу либо режим только для чтения. Запись в продуктивную базу из зеркальной версии создаёт дубли, которые сложно отличить от настоящих.
3. Начните с малой доли. Зеркалирование 5 процентов трафика даёт достаточно данных и ограничивает нагрузку на новую версию.
4. Сравнивайте ответы. Задержка, код ответа и размер тела сравниваются между версиями. Расхождение — признак изменения поведения.
5. Проверяйте ошибки отдельно. Рост числа ошибок в зеркальной версии при отсутствии влияния на пользователей — цель проверки.
6. Не возвращайте ответы зеркальной версии пользователю. Это основное отличие от канареечного развёртывания; о канарейке — в статье про canary releases.
7. Ограничьте время проверки. Теневой трафик — этап проверки, а не постоянный режим работы.
8. Фиксируйте расхождения. Отличия в ответах разбираются до развёртывания, поскольку после них отличия уже видны пользователям.
Рекомендации:
- Проверяйте, что побочные эффекты действительно отключены. Отдельный тест на попытку записи в зеркальном режиме обязателен.
- Учитывайте нагрузку на зависимости. Зеркальный трафик увеличивает число запросов к базе и внешним системам.
- Не зеркалируйте запросы с чувствительными операциями. Запросы оплаты и смены пароля лучше исключать из копирования.
- Сравнивайте процентили, а не среднее задержки. Различие видно на p95 и p99, а среднее его скрывает.
- Документируйте результат проверки. Перечень найденных расхождений — основание для решения о развёртывании.
Практический сценарий: обнаружение изменения формата ответа до развёртывания
Контекст: переписывался сервис формирования заказов: менялась библиотека сериализации. Тесты проходили, а канареечное развёртывание планировалось на следующую неделю.
- Диагностика. При зеркалировании 10 процентов трафика сравнение ответов показало, что в 4 процентах случаев порядок полей в JSON отличался, а числовые значения с плавающей точкой сериализовались с иной точностью.
- Причина. Новая библиотека сериализации иначе обрабатывала порядок ключей и представление чисел. Тесты проверяли структуру и значения, но не побайтовое представление ответа.
- Действия. (а) Один из клиентов разбирал ответ построчно и зависел от порядка полей, что выяснилось при разборе расхождений; (б) настройку сериализации привели к прежнему представлению; (в) добавили тест, сравнивающий представление ответа с эталонным; (г) повторили зеркалирование и убедились в отсутствии расхождений; (д) развёртывание выполнили по плану.
- Результат. Проблема обнаружена до развёртывания. При канареечном развёртывании она проявилась бы у части клиентов как ошибка разбора ответа.
Вывод: теневой трафик выявляет расхождения, которые не покрываются тестами, поскольку они возникают на реальных данных и форматах. Условие применимости — отключённые побочные эффекты: без этого зеркалирование создаёт дубли данных и нежелательные внешние вызовы.
FAQ
Чем теневой трафик отличается от канареечного развёртывания? Ответы новой версии не возвращаются пользователям. Канарейка отдаёт часть реального трафика новой версии, теневой трафик — только копирует запросы.
Можно ли зеркалировать записывающие запросы? Только при отключённой записи либо отдельной базе. Запись в продуктивную базу создаёт дубли, которые сложно отделить от настоящих данных.
Какая доля трафика нужна для проверки? Достаточно 5–10 процентов: этого хватает для выявления расхождений без существенной нагрузки на новую версию.
Что сравнивать между версиями? Код ответа, задержку по процентилям, размер тела и наличие ошибок. Побайтовое сравнение тела выявляет изменения формата.
Источники: Istio docs (Traffic Mirroring), nginx mirror module, Kubernetes docs — ссылки в шапке.