Instradamento del traffico video nell'area Asia-Pacifico con etcd

Una piattaforma di video streaming che serve otto mercati dell'area Asia-Pacifico ha risolto un errore di instradamento ricorrente spostando la configurazione specifica per regione in etcd. Il tempo di propagazione delle modifiche di instradamento è sceso a circa un secondo. Gli editor possono ora potenziare un pool musicale per alcune ore senza toccare il codice, e la piattaforma ha smesso di inviare il feed di Tokyo agli spettatori della Corea del Sud.

Perché il vecchio approccio è fallito

Ogni router leggeva tre valori per ogni richiesta: il pool di tendenza, il tokenizer specifico per lingua e una catena di fallback. Le decisioni di business — promuovere un nuovo artista, reagire a un'interruzione regionale, testare un algoritmo di raccomandazione — guidavano quei valori, non le modifiche al codice.

Inizialmente, ogni deployment includeva un file JSON con la tabella di instradamento. Durante un incidente, un ingegnere reperibile ha modificato il file su un nodo per indirizzare il traffico verso un pool di backup, ma non ha mai aggiornato gli altri sette nodi. È emerso un disallineamento della configurazione (config drift): otto paesi utilizzavano tabelle divergenti e non esisteva un'unica fonte che verificasse la "verità". Il bug che inviava gli spettatori di Seoul a Tokyo è persistito perché il codice rimaneva lo stesso; cambiava solo la configurazione nascosta.

Scegliere etcd come unica fonte di verità

Il team ha confrontato tre opzioni:

  • SQLite/MySQL – avrebbe costretto ogni router a interrogare (poll) un database, aggiungendo latenza o sovraccaricando le query.
  • Consul – uno strumento di service discovery solido, ma la piattaforma non aveva bisogno delle sue complete funzionalità mesh.
  • etcd – un key-value store a forte consistenza con una primitiva watch che notifica i client nel momento esatto in cui una chiave cambia.

La funzione watch ha fatto pendere l'ago della bilancia. Invece di chiedere ripetutamente "è cambiato qualcosa?", i router rimanevano inattivi finché etcd non inviava un aggiornamento. Il traffico di rete non necessario è svanito e ogni istanza ha appreso della modifica simultaneamente.

Pattern che mantengono il sistema al sicuro

etcd da solo non ha risolto tutti i rischi. Gli ingegneri hanno aggiunto tre pattern complementari:

  1. Leases – un editor può impostare un potenziamento temporaneo (ad esempio, aumentare il peso di un pool di K-pop per sei ore). Il lease scade automaticamente, quindi il potenziamento scompare senza rollback manuali.
  2. Compare-and-swap (CAS) – quando due persone modificano la stessa impostazione contemporaneamente, il CAS fallisce esplicitamente per una di esse, evitando sovrascritture silenziose.
  3. Sidecar process – PHP fatica a gestire connessioni a lunga durata. Un piccolo sidecar in Go su ogni macchina monitora etcd e scrive uno snapshot della tabella di instradamento in un file in memoria condivisa (/dev/shm). PHP legge quel file locale, evitando qualsiasi round-trip di rete durante la gestione della richiesta.

Resilienza integrata nell'architettura

Il nuovo design aggiunge diverse reti di sicurezza:

  • Letture a latenza zero – il percorso critico (hot path) di PHP legge dalla memoria locale, quindi le richieste non si bloccano mai in attesa di un archivio remoto.
  • Degradazione controllata (graceful degradation) – se etcd si interrompe, i router continuano a servire l'ultima configurazione valida nota, evitando un'interruzione improvvisa.
  • Aggiornamenti affidabili – il sidecar gestisce la logica di riconnessione e garantisce che nessuna modifica venga persa, anche se la connessione a etcd cade temporaneamente.

Cosa è cambiato sul campo

Dopo la migrazione, il team ha registrato un drastico calo degli incidenti causati da dati di instradamento obsoleti o errati. Una singola console mostra ora la configurazione corrente e ogni modifica si propaga a tutte e otto le regioni entro un secondo. I potenziamenti temporanei si auto-eliminano quando il loro lease scade, eliminando i passaggi di pulizia manuale che in precedenza portavano all'errore umano.

Contro-argomentazione: il costo di un sidecar

Aggiungere un sidecar significa avere un secondo processo per server e un runtime Go in uno stack centrato su PHP. Alcuni operatori si preoccupano dell'uso extra di memoria e della necessità di monitorare un altro binario. In pratica, l'impronta del sidecar rimane modesta e i guadagni in termini di affidabilità — specialmente la garanzia che PHP non blocchi mai su una chiamata di rete — superano l'onere operativo.

Cosa monitorare in seguito

I team che gestiscono servizi multi-regione dovrebbero monitorare:

  • metriche di salute di etcd – lo strato di instradamento dipende da un unico store; tenere d'occhio lo stato del quorum e la latenza.
  • gestione della scadenza dei lease – far coincidere i tempi dei lease con le finestre di business; lease troppo lunghi lasciano in vigore potenziamenti obsoleti.
  • scalabilità del carico watch – man mano che i router aumentano, aumentano anche le connessioni watch; pianificare la capacità dei server etcd di conseguenza.

Conclusione

Per qualsiasi servizio che necessiti di modifiche di configurazione rapide e coordinate in molte regioni, le primitive watch, lease e transaction di etcd offrono un'alternativa leggera e fortemente consistente alle configurazioni basate su file o ai mesh pesanti. Trasformare la configurazione in uno store basato su push e auto-pulente ha eliminato un'intera classe di incidenti e ha conferito alla piattaforma il controllo in tempo reale sulla propria logica di routing.