Due direzioni del traffico, una scatola
Benvenuto
La maggior parte dei diagrammi di architettura mostra il traffico che va in una sola direzione: il client in cima, il server in basso, freccia che punta verso il basso. La realtà ha il traffico che va in entrambe le direzioni.
Ingress: i client esterni raggiungono le tue servizi attraverso questa strada. Un reverse proxy all'estremità della tua rete termina il TLS, gestisce le richieste e applica la politica di accesso.
Egress: i tuoi servizi raggiungono i servizi esterni attraverso questa strada. Chiamare un API di un processore di pagamenti, recuperare un target webhook, inviare una richiesta a un partner. Spesso attraverso un forward proxy o un gateway NAT con un elenco consentiti.
Molti architetture iniziano con una scatola che gestisce entrambi. Funziona, fino al giorno in cui non lo fa. Il modo di fallimento è sottile, si manifesta solo dopo che ci sono abbastanza servizi interni, e insegna una lezione importante di separazione dei concetti.
Alla fine di questa lezione capirai:
- Perché ingress e egress rappresentano schemi di traffico fondamentalmente diversi con assi di scalabilità e modi di errore diversi
- Hairpin NAT e perché un proxy che cerca di connettersi a se stesso fallisce
- Il fork architettonico: una scatola diventa due, e cosa ciascuna di esse possiede poi esclusivamente
- Gli guadagni di isolamento di sicurezza: ogni lato può serrare verso i suoi veri peer consentiti
- Come identificare quando il tuo design a una scatola ha superato il limite in cui la divisione è necessaria
Perché le direzioni richiedono strumenti diversi
Due carichi di lavoro diversi in una stessa frontiera di rete
Caratteristiche del traffico ingress:
- Inizializzato da parti esterne (l'intera rete internet)
- Volume proporzionale alla tua base di utenti
- Terminazione TLS, routing delle richieste, limitazione del tasso per origine
- Preoccupazioni di difesa a profondità: DDoS, abuso, scraping
- IP pubblico che deve accettare connessioni da chiunque
Caratteristiche del traffico egress:
- Inizializzato dai tuoi servizi (un piccolo insieme di client noti)
- Volume proporzionale ai tuoi pattern di chiamata servizio-servizio e API esterna
- Allowlisting IP di origine sui endpoint remoti (hai un solo IP di uscita fissa che i partner trust)
- Preoccupazioni relative alla deepità difensiva: sottrazione dati, servizi interni compromessi che chiamano fuori
- Dovrebbe rifiutare le connessioni da parte di chi non è le tue servizi stessi
L'asimmetria chiave: l'ingresso accetta traffico dal mondo; l'egresso accetta traffico solo dai tuoi servizi. Metterli sulla stessa macchina significa che la macchina deve essere contemporaneamente raggiungibile dal mondo (per l'ingresso) e raggiungibile solo dai tuoi servizi (per l'egresso). Le regole del firewall che soddisfano uno lavorano contro l'altro.
La via della crescita: un piccolo progetto può nascondere entrambi dietro un IP e uno strumento unico, perché il volume è piccolo e l'allowlist IP partner è breve. Man mano che il progetto cresce, l'attrito tra i due ruoli aumenta e un giorno un determinato modo di fallire (NAT a spirale) costringe lo split.
Il bug che costringe lo split
Una storia di interruzione sanificata
Immagina un vero e proprio ramo architettonico che avviene in flotte di produzione. I nomi di seguito sono stati modificati; la forma è identica a quella che gli team colpiscono nel vivo.
Un'organizzazione esegue un unico server proxy su 203.0.113.5. Gestisce l'ingresso (porta 443 per gli utenti) e l'egresso (porta 1080 SOCKS5 per i servizi interni che chiamano fuori). I servizi interni si trovano in sottoreti private e inviano tutto il traffico in uscita attraverso il proxy SOCKS5 su 203.0.113.5:1080.
Uno dei servizi ospitati dietro lo stesso 203.0.113.5 è api.example.com. Il DNS pubblico risolve api.example.com su 203.0.113.5.
Ora un diverso servizio interno deve chiamare api.example.com. La sua strada in uscita:
1. Il servizio interno risolve api.example.com → 203.0.113.5
2. Il servizio interno invia la richiesta attraverso il proxy SOCKS5 di egresso su 203.0.113.5:1080
3. Il proxy cerca di aprire una connessione da se stesso a 203.0.113.5:443
4. Rifiutato. Il pacchetto dovrebbe uscire e rientrare nello stesso NAT, che la maggior parte degli stack di rete rifiuta. Il proxy non può connettersi a se stesso tramite il proprio IP pubblico.
Questo è il NAT a anello: un pacchetto che esce da un NAT e ha bisogno di rientrare nello stesso NAT per raggiungere la propria destinazione. Senza un supporto specifico per il routing a anello, il pacchetto viene perso.
Perché Emerge Tardi
All'inizio della vita del progetto, ogni servizio interna parlava con altri servizi interni utilizzando il nome privato del host (internal-api.local) o non chiamava i propri servizi pubblici. La via dell'anello semplicemente non esisteva.
Poi una nuova funzionalità richiedeva che il servizio A chiamasse api.example.com (un hostname pubblico). La via dell'anello è attivata. Rifiuto della connessione. Outage.
La soluzione ha risolto il sintomo (forzare il risolutore a dare l'IP privato di api.example.com invece di quello pubblico). La causa radice: una singola box stava facendo troppo lavoro.
Il Fork Architettonico
Una Box Diventa Due
La soluzione pulita: separare il proxy in due macchine.
Server di ingresso (IP pubblico 203.0.113.5):
- Caddy / reverse proxy sui porti 80, 443
- I record DNS pubblici puntano qui
- Ospita api.example.com, app.example.com, ecc.
Server di egress (IP pubblico diverso 203.0.113.99):
- SOCKS5 / forward proxy sul porto 1080
- Il firewall limita le connessioni in arrivo solo agli IP del sottorete interna
- I servizi interni inviano tutte le uscite attraverso questa indirizzo
Cosa compra:
1. Risolto il problema dell'anello. Un servizio interno che chiama api.example.com invia le uscite tramite 203.0.113.99 (egress), che poi si connette normalmente a 203.0.113.5 (ingress, un IP diverso). Lo spiraglio NAT scompare perché gli due IP vivono su macchine diverse.
2. Isolamento di sicurezza. Il server di egress può bloccare il firewall su un piccolo set di IP interni. Il server di ingresso mantiene il firewall aperto al mondo. Due set regole separati, ciascuno esprimendo un ruolo pulito.
3. Scaling indipendente. La banda di ingresso scala con gli utenti; la banda di egress scala con l'attività dei servizi interni. Aggiorna uno senza toccare l'altro.
4. Isolamento del failure. Un egress configurato male non rompe più il sito pubblico. Un DDoS contro il sito pubblico non stanci più la banda di egress.
5. Modello mentale più chiaro. Ogni macchina ha un unico compito. Gli ingegneri ragionano sulle preoccupazioni di ingresso senza pensare all'egress, e viceversa.
Due assi, due decisioni di dimensionamento
Scaling indipendente
Prima dello split, l'incremento in entrambe le direzioni metteva sotto stress la stessa macchina. Dopo lo split, ogni direzione ha la propria fornitura.
Dimensionamento di ingresso: scala con gli utenti. Le decisioni di capacità sono presenti nella tier faccia-pubblico (più replica reverse proxy, VM più grandi, CDN davanti). Bilancio di banda calcolato contro il traffico degli utenti al picco.
Dimensionamento di egress: scala con il volume di chiamate interno-service-esterno API. Spesso dominato da consegne webhook, chiamate ai processori di pagamento o fetch di dati terze parti. Bilancio di banda calcolato contro i modelli di chiamata interni.
Isolamento del failure: un DDoS contro l'ingress pubblico non mangia più la banda di egress (quelle chiamate ai processori di pagamento passano comunque). Un crash dell'proxy egress non mette più giù il sito pubblico (gli utenti continuano ad arrivare al sito; solo le chiamate outbound interne falliscono).
SLO diversi: l' disponibilità di ingresso interessa gli utenti (evidente interruzione del sito); l' disponibilità di egress interessa gli operatori (fallimenti di background che potrebbero volerci più tempo per essere rilevati). Ogni lato può portare il proprio SLO.
Multipli server di egress
Una volta che il ruolo di egress è una propria macchina, il prossimo passo ovvio è quello di eseguire più macchine egress dietro un equilibratore di carico per l'HA. Ogni nuovo servizio interno puntava al nomehost di egress (che risolveva nella pool equilibrata) invece che a una singola IP.
Lo stesso lezione come il resto dei sistemi distribuiti: una volta che un tier diventa stateless e ha il proprio ruolo, si moltiplica a buon mercato.
Una nuova integrazione partner
La tua organizzazione esegue lo split ingress/egress come progettato. Il server egress ha un IP pubblico fermo (203.0.113.99) che hai allowlistato con tre API partner esistenti (un processore di pagamento, una gateway SMS, un provider email).
Un team di prodotto vuole aggiungere una quarta integrazione: un sistema di consegna webhook che chiama indietro nei endpoint dei clienti in tutto il mondo. La previsione di volume: 10.000 chiamate al minuto, con picchi di 30.000.
Progetta un confine di rete per un servizio in crescita
Sintesi
Hai imparato perché ingresso e egresso richiedono strumenti diversi, il fallimento della NAT hairpin che costringe lo split nelle flotte reali e come si accumulano la scalabilità indipendente, l'isolamento della sicurezza e l'isolamento delle interruzioni una volta che lo split ha avuto luogo.
Applica tutti e quattro.
Una società SaaS di medie dimensioni gestisce tre sottodomini del prodotto (app, api, admin) per i propri utenti, oltre a quattro integrazioni outbound (Stripe, Twilio, SendGrid, un sistema webhook per i clienti). Oggi tutto vive dietro una singola macchina proxy con un unico IP pubblico. Hanno iniziato a ricevere segnalazioni di fallimenti intermittenti hairpin quando i servizi interni cercano di chiamare api.example.com. Vogliono progettare una soluzione definitiva.
Dove va questo corso
Dove va questo corso
Hai ora visto uno dei rifacimenti più puliti separation-of-concerns nei sistemi distribuiti: una scatola diventa due, ognuna con un ruolo chiaro, e il sistema eredita benefici di scalabilità, sicurezza e isolamento delle interruzioni lungo il modo.
La prossima lezione (cs_distsys_failure_modes_and_blast_radius) estende la ragionevolezza sull'isolamento delle interruzioni. Leggerai un postmortem DNS-SERVFAIL sanificato, identificherai il pattern di fallimento a catena e scriverai azioni senza colpe che mirano a sistemi invece di persone.
Lezione complementare: geometry_of_ingress_egress_separation riformula lo split come un grafo bipartito e esplora i vertici di taglio, le partition dei reti e ciò che la teoria dei grafi ti dice sulla frontiera di una rete.
Ben fatto. Avanti.