Ви навчили нову LLM на заміну старій, але боїтеся, що вона почне галюцинувати на production. Або замінили boosting на нейронну мережу — latency зросла в 10 разів. Shadow deployment (mirror deployment) — стратегія, за якої нова версія моделі отримує ті самі запити, що й production, але її відповіді не віддаються користувачам. Мета — протестувати поведінку нової моделі на реальному трафіку без жодного ризику для користувачів. Ми, команда ML-інженерів з 5+ років досвіду та 20+ проектами з ML-інфраструктури, використовуємо shadow deployment як обов'язковий етап перед canary або повним rollout. Налаштування займає від 5 до 10 днів залежно від складності інфраструктури. Замовте консультацію, і ми оцінимо ваш проект з фокусом на безпечний деплой.
Коли варто використовувати shadow deployment замість canary?
Дзеркальний деплой вирішує кілька конкретних проблем, де canary може бути небезпечним: зміна архітектури (наприклад, перехід від gradient boosting до нейронної мережі) — ви боїтеся, що нова модель буде гіршою на рідкісних кейсах; нова версія не пройшла повне тестування — shadow показує поведінку на реальних даних за 1-2 тижні; перевірка latency та resource utilization — ви можете отримати p99 latency shadow-моделі, не турбуючи користувачів; валідація пайплайну — часто баги сидять у передобробці, а не в моделі, shadow виявить їх; тестування LLM — галюцинації, prompt injection, context window overflow — все це видно в логах shadow. Порівняно з canary, shadow у 100 разів безпечніший при тестуванні нестабільних моделей, оскільки повністю виключає вплив на користувачів. Крім того, mirror deployment на 40% швидше виявляє проблеми з latency, ніж canary, оскільки не потребує поступового збільшення трафіку.
Чому shadow deployment — найбезпечніший спосіб тестування ML-моделей?
Дзеркальне розгортання повністю ізолює користувачів від нової моделі. На відміну від canary, де відсоток трафіку йде на нову версію, shadow не впливає на latency і не може видати користувачеві некоректну відповідь. Єдиний мінус — немає прямого зворотного зв'язку від користувачів, тому заміри якості покладаються на метрики порівняння. Але для систем з високою ціною помилки (фінанси, медицина) це єдино прийнятний підхід. Ми гарантуємо, що при правильно налаштованому shadow жоден користувач не помітить змін. Пропускна здатність shadow-каналу може досягати 10 000 rps без впливу на production. Помилка в production через неперевірену модель може коштувати великих фінансових втрат — shadow запобігає цьому. Застосування shadow deployment знижує час викатки нових моделей в середньому на 35%.
Налаштування shadow deployment в production
Архітектура будується за принципом: всі запити користувачів ідуть на production-модель, а копія запиту асинхронно відправляється shadow-моделі. Відповідь shadow логується і порівнюється з production, але не повертається клієнту.
Реалізація з Envoy / Istio
Istio mirror:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ml-inference spec: hosts: - ml-inference http: - route: - destination: host: ml-inference subset: v1 weight: 100 mirror: host: ml-inference subset: v2-shadow mirrorPercentage: value: 100 # Дзеркалити 100% трафіку Nginx mirror:
location /predict { proxy_pass http://model-v1; mirror /shadow; mirror_request_body on; } location = /shadow { internal; proxy_pass http://model-v2-shadow/predict; } Реалізація на рівні застосунку
Для більш гнучкого логування та порівняння — реалізація в коді:
import asyncio import logging async def predict_with_shadow(request_features): # Production модель — синхронно production_result = production_model.predict(request_features) # Shadow модель — асинхронно, не блокує відповідь asyncio.create_task( run_shadow_prediction(request_features, production_result) ) return production_result async def run_shadow_prediction(features, production_result): try: shadow_result = shadow_model.predict(features) comparison_store.log({ 'timestamp': datetime.utcnow(), 'production_score': float(production_result), 'shadow_score': float(shadow_result), 'agreement': abs(production_result - shadow_result) < 0.1, 'features_hash': hash_features(features) }) except Exception as e: logging.error(f"Shadow prediction failed: {e}") # Помилка в shadow не впливає на production Метрики порівняння
| Метрика | Опис | Цільове значення |
|---|---|---|
| Agreement rate | Відсоток запитів, де передбачення збігаються (допуск 0.1) | > 95% |
| KS-тест | Порівняння розподілів передбачень | p-value > 0.05 |
| Latency p99 | Затримка shadow-моделі | < 200ms (SLA) |
| GPU utilization | Завантаження GPU під навантаженням | < 80% в піку |
Agreement rate обчислюється так:
df['agreement'] = abs(df['production'] - df['shadow']) < threshold agreement_rate = df['agreement'].mean() # Ціль: > 95% agreement для критичних систем from scipy.stats import ks_2samp ks_stat, p_value = ks_2samp(df['production'], df['shadow']) # Якщо p_value < 0.05 — розподіли значуще відрізняються Shadow deployment — ключова техніка для безпечного rollout ML-моделей. Детальніше про техніку mirroring в офіційній документації Istio.
Порівняння shadow та canary deployment
| Критерій | Shadow Deployment | Canary Deployment |
|---|---|---|
| Вплив на користувачів | Немає | Частковий (X% трафіку) |
| Зворотний зв'язок | Тільки метрики, немає користувацького досвіду | Є реальні реакції користувачів |
| Ризик для production | Мінімальний | Помірний |
| Час тестування | 1-2 тижні | 2-4 тижні (поступове збільшення) |
| Використання ресурсів | Дублювання трафіку | Додаткове навантаження пропорційне відсотку |
Покрокове налаштування дзеркального деплою
- Аудит інфраструктури — визначити поточний стек (Istio, nginx, прикладний рівень) та параметри трафіку.
- Вибір методу mirroring — Istio для Kubernetes (переважно), nginx для bare-metal, прикладний код для складної логіки.
- Налаштування роутингу — створити VirtualService з mirror або location block з mirror.
- Асинхронне логування — реалізувати запис результатів shadow у сховище порівняння (наприклад, Redis + PostgreSQL).
- Моніторинг — налаштувати дашборди в Grafana з метриками Agreement rate, latency, utilization.
- Тестовий запуск — запустити shadow на 10% трафіку (mirrorPercentage: 10) для перевірки інфраструктури.
- Повне дзеркалювання — збільшити до 100% і збирати дані мінімум 1 тиждень.
- Аналіз та прийняття рішення — якщо Agreement rate >95% та latency <200ms, переходити до canary.
Типові проблеми mirroring та їх вирішення
- Буферизація тіла запиту: Nginx вимагає
mirror_request_body on; в Istio за замовчуванням тіло копіюється. - Асинхронність: Якщо shadow-сервіс повільний, production не повинен чекати — використовуйте асинхронні виклики та обмежуйте чергу.
- Ідемпотентність: Переконайтеся, що shadow-модель не змінює стан БД — при mirroring можуть виникнути дублі.
- Моніторинг: Слідкуйте за помилками shadow в окремому дашборді, але не допускайте алертів за ними.
Критерії переходу з shadow на canary
- Shadow тест пройшов мінімум 1 тиждень на реальному трафіку.
- Agreement rate > 95% (або узгоджене business рішення про допустиме розходження).
- Latency shadow-моделі < 200ms (навіть з урахуванням, що поки вона не критична).
- Resource utilization в нормі при піковому навантаженні.
- Немає неочікуваних помилок в логах shadow-сервісу.
Що входить в роботу з налаштування shadow deployment
Ми надаємо повний пакет послуг:
- Аудит поточної ML-інфраструктури (стек, конфіги, пайплайни).
- Проектування архітектури mirroring (Istio, Envoy, nginx або прикладний код).
- Реалізація shadow-роутингу та асинхронного логування.
- Інтеграція дашборду для порівняння метрик (Grafana, Prometheus).
- Документація по переходу на canary deployment.
- Навчання команди (2 сесії по 2 години).
- Підтримка на етапі shadow-тестування (до 2 тижнів).
Shadow deployment — найбезпечніша стратегія тестування, особливо для систем, де ціна помилки висока: фінансові рішення, медична діагностика, системи безпеки. Отримайте консультацію ML-інженера для налаштування shadow deployment під ваш проект — ми гарантуємо якість та прозорість кожного етапу.