Introduction au module de miroir de trafic Nginx

Depuis la version 1.13, Nginx intègre le module ngx_http_mirror_module, conçu pour dupliquer le trafic entrant vers des serveurs secondaires. Le principe fondamental de cette fonctionnalité est que les réponses générées par les serveurs cibles de la duplication sont systématiquement ignorées par Nginx. Cela garantit que le traitement effectué par l'environnement miroir n'a aucun impact sur la latence ou la réponse finale renvoyée au client légitime.

Cependant, il est crucial de noter une limitation architecturale : la requête originale et sa copie sont couplées au niveau du cycle de vie. Tant que le traitement de la requête dupliquée n'est pas terminé, la requête principale reste en attente, ce qui peut introduire des goulots d'étranglement si le backend miroir est lent.

Directives principales et configuration

Le mécanisme repose sur deux directives essentielles qui peuvent être déclarées dans les contextes http, server ou location.

La directive mirror

Cette insturction définit l'URI de destination pour la copie du trafic. Il est possible de déclarer plusieurs directives mirror pour envoyer le trafic vers plusieurs cibles simultanément. Si la même URI est spécifiée plusieurs fois, cela agit comme un multiplicateur de charge sur cette cible spécifique.

Syntaxe : mirror uri | off;
Défaut : mirror off;

La directive mirror_request_body

Elle contrôle si le corps de la requête (payload) doit être inclus dans la duplication. Elle est activée par défaut.

Syntaxe : mirror_request_body on | off;
Défaut : mirror_request_body on;

Attension aux conflits de bufferisation : L'activation de cette directive désactive automatiquement les tampons de requête pour les modules proxy (proxy_request_buffering), FastCGI, SCGI et uWSGI. De plus, une incohérence entre mirror_request_body, proxy_pass_request_body et l'en-tête Content-Length peut provoquer des timeouts. Par exemple, si le transfert du corps est désactivé mais que Content-Length indique une taille supérieure à zéro, le serveur en aval attendra indéfiniment des données qui n'arriveront jamais, résultant en une erreur "upstream timed out".

Exemple de configuration refactorisé

Voici une implémentation typique où le trafic principal est routé vers un cluster de production, tandis qu'une copie est envoyée à un environnement de staging pour analyse.

upstream production_cluster {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

upstream staging_analytics {
    server 10.0.2.50:9090;
}

server {
    listen 80;
    server_name api.example.com;

    # Point d'entrée principal
    location /api/v1/ {
        mirror /shadow_traffic;
        proxy_pass http://production_cluster;
        
        # Assurer la cohérence des en-têtes pour éviter les timeouts
        proxy_set_header Content-Length "";
    }

    # Cible interne pour le trafic dupliqué
    location = /shadow_traffic {
        internal;
        proxy_pass http://staging_analytics$request_uri;
        
        # Désactiver le corps si non nécessaire pour l'analyse
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }
}

Cas d'utilisation stratégiques

La duplication de trafic (ou "shadowing") est particulièrement utile dans les scénarios suivants :

• Tests de pré-production (Shadow Testing) : Évaluer les performances et la stabilité d'une nouvelle version d'application sous une charge réelle sans affecter les utilisateurs finaux.
• Analyse de données et Machine Learning : Alimenter des pipelines de données en temps réel pour l'entraînement de modèles ou l'analyse comportementale.
• Ajustement des Web Application Firewalls (WAF) : Affiner les règles de sécurité avant leur déploiement en mode bloquant.

Optimisation des règles WAF en environnement réel

Le déploiement direct de solutions WAF open-source comme ModSecurity ou Naxsi en mode bloquant présente un risque élevé de faux positifs, car les règles basées sur des signatures pienent à distinguer les requêtes légitimes complexes des attaques sophistiquées.

En s'inspirant des techniques de télémétrie réseau (comme le port mirroring sur les switchs), on peut configurer le WAF en mode "miroir". Le trafic de production est dupliqué vers le moteur WAF. Lorsqu'une requête est jugée malveillante, le WAF ne la bloque pas (puisque c'est une copie), mais génère un log d'alerte. En analysant ces journaux sur une période donnée, les ingénieurs de sécurité peuvent identifier les faux positifs, ajuster les règles de détection, et finalement basculer le WAF en mode bloquant avec un taux de faux positifs minimisé.