{"id":7923,"date":"2025-07-16T08:00:00","date_gmt":"2025-07-16T06:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7923"},"modified":"2025-07-15T12:49:04","modified_gmt":"2025-07-15T10:49:04","slug":"testing-del-codice-con-traffico-reale-oltre-lo-staging-con-aws-vpc-traffic-mirroring","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/testing-del-codice-con-traffico-reale-oltre-lo-staging-con-aws-vpc-traffic-mirroring\/","title":{"rendered":"Testing del Codice con Traffico Reale: Oltre lo Staging con AWS VPC Traffic Mirroring"},"content":{"rendered":"\n

Ci siamo passati tutti: gli unit test sono tutti \u201cverdi\u201d, gli integration test passano senza problemi e perfino i test di carico pi\u00f9 rigorosi confermano che il nuovo codice \u00e8 pronto. La fiducia \u00e8 alle stelle. Eppure, una domanda assillante continua ad aleggiare nell’aria: <\/p>\n\n\n\n

“cosa succeder\u00e0 con gli utenti reali<\/em>? Con picchi di traffico imprevedibili che ti fanno esclamare: \u201cNon sapevo nemmeno che l’API potesse essere usata cos\u00ec!\u201d<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

La questione ci \u00e8 particolarmente cara. Avevamo appena completato un importante refactoring di un’applicazione critica, di quelle il cui minimo intoppo provoca ripercussioni sul business.<\/p>\n\n\n\n

Lo Scenario: L\u2019architettura in Produzione<\/h2>\n\n\n\n

La nostra configurazione segue un pattern comune in AWS: un AWS Application Load Balancer distribuisce il traffico su una flotta di istanze Amazon EC2 che ospitano il nostro servizio. La funzione principale del servizio? Interrogare un database MongoDB e restituire i risultati. Semplice, ma fondamentale.<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"
Diagramma semplificato del flusso di produzione<\/em>
<\/figcaption><\/figure><\/div>\n\n\n

“What If”: Replicare la Produzione Senza Rischi<\/h2>\n\n\n\n

Per dissipare ogni dubbio, abbiamo indetto una sessione di brainstorming (alimentata, come da tradizione, da una generosa dose di caff\u00e8). “E se” propone qualcuno, “potessimo spiare<\/em> in modo trasparente il traffico di produzione e inviarlo al nostro nuovo codice, in un ambiente completamente isolato da quello reale?”.<\/p>\n\n\n\n

Sembra un’utopia, ma AWS offre un servizio adattabile al nostro scopo: Amazon VPC Traffic Mirroring<\/strong>.<\/p>\n\n\n\n

Immaginate uno specchio unidirezionale. Da un lato, il traffico di produzione scorre normalmente, gestendo le richieste degli utenti senza interruzioni. Dall’altro, una copia esatta di quel traffico viene inviata a una destinazione designata, come un Network Load Balancer o un’interfaccia di rete.<\/p>\n\n\n\n

Il dettaglio cruciale \u00e8 come<\/em> viene inviata questa copia. I pacchetti replicati sono incapsulati in VXLAN, un protocollo di virtualizzazione di rete che wrappa frame Ethernet di livello 2 in pacchetti UDP per il trasporto su reti IP. Questo impedisce loro di essere trattati come traffico di rete standard e di interferire con qualsiasi altro sistema. Tuttavia, significa anche che la nostra applicazione di test non pu\u00f2 processare questi pacchetti VXLAN come normali richieste HTTP.<\/p>\n\n\n\n

Per colmare questa lacuna, abbiamo bisogno di una semplice utility per:<\/p>\n\n\n\n

    \n
  1. Ricevere<\/strong> i pacchetti incapsulati in VXLAN.<\/li>\n\n\n\n
  2. Decapsularli<\/strong> per estrarre le richieste di produzione originali.<\/li>\n\n\n\n
  3. Inoltrare<\/strong> le richieste al nostro ambiente di test.<\/li>\n<\/ol>\n\n\n\n

    Con questo approccio, il flusso di produzione resta completamente isolato e ignaro dell\u2019ambiente parallelo, mentre il nostro ambiente di test riceve una replica in tempo reale del traffico senza alcun rischio. Non \u00e8 una soluzione pronta all’uso, ma con lo strumento giusto per la decapsulazione, si \u00e8 rivelata un modo potente e sicuro per validare il nostro nuovo codice contro la realt\u00e0.<\/p>\n\n\n\n

    Costruire il nostro Ambiente “Doppelg\u00e4nger”<\/h2>\n\n\n\n

    Con una strategia chiara, ci siamo messi al lavoro.<\/p>\n\n\n\n

    All\u2019inizio abbiamo costruito una replica isolata.<\/strong> Abbiamo rilasciato uno stack completo e parallelo: nuove istanze Amazon EC2 con il codice refattorizzato, un AWS Application Load Balancer “ombra” dedicato e una nuova istanza MongoDB popolata con uno snapshot recente della produzione. Questo era il nostro campo di prova ad alta fedelt\u00e0.<\/p>\n\n\n\n

    Poi abbiamo deployato il nostro ambiente di mirroring.<\/strong> Abbiamo configurato un AWS Network Load Balancer davanti a un AWS Auto Scaling group di istanze Amazon EC2. Su queste istanze, abbiamo installato uno strumento open-source (come questo<\/a>) per gestire la decapsulazione VXLAN e inoltrare il traffico al nostro AWS ALB ombra. Questo gateway era il ponte tra il mondo mirrorato e il nostro ambiente di test.<\/p>\n\n\n\n

    Non avevamo bisogno di mirrorare tutto<\/em> il traffico; le comunicazioni operative avrebbero solo aggiunto rumore e costi. Il nostro servizio opera sulla porta 8080, quindi abbiamo creato un semplice Filtro di Mirroring<\/strong> (Mirror Filter): “Duplica solo il traffico TCP destinato alla porta 8080”. Questo ha focalizzato il nostro esperimento e, soprattutto, ci ha aiutato a gestire i costi.<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    Infine<\/strong>, abbiamo creato una Sessione di Mirroring<\/strong> (Mirror Session) per collegare la sorgente, il filtro e la nostra destinazione (il gateway). E abbiamo premuto l’interruttore.<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"
    Diagramma dell\u2019architettura finale con il traffic mirroring<\/em>
    <\/figcaption><\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    Il Momento della Verit\u00e0<\/h2>\n\n\n\n

    I risultati sono stati immediati e illuminanti. Osservando le nostre dashboard di CloudWatch, abbiamo visto le metriche di CPU e Memoria del nuovo servizio di test iniziare a fluttuare, imitando perfettamente il ritmo dell’ambiente di produzione. La nostra applicazione ombra era viva<\/strong> e stava processando una replica in tempo reale del carico di produzione.<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"\"<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    \u00c8 qui che \u00e8 emerso il vero valore.<\/p>\n\n\n\n

    Abbiamo lasciato il mirroring attivo per un’intera giornata, catturando un ciclo completo di traffico, dai picchi alle ore di calma. L’analisi dei log dell’applicazione e delle metriche del database ha portato alla luce due aspetti:<\/p>\n\n\n\n