Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Best practice per connettere i servizi Amazon ECS in un VPC
Utilizzando le attività di Amazon ECS in un VPC, puoi suddividere le applicazioni monolitiche in parti separate che possono essere distribuite e scalate indipendentemente in un ambiente sicuro. Questa architettura si chiama architettura orientata ai servizi (SOA) o microservizi. Tuttavia, può essere difficile assicurarsi che tutte queste parti, sia all'interno che all'esterno di un VPC, possano comunicare tra loro. Esistono diversi approcci per facilitare la comunicazione, tutti con vantaggi e svantaggi diversi.
Utilizzo di Service Connect
Consigliamo Service Connect, che fornisce la configurazione di Amazon ECS per il rilevamento servizi, la connettività e il monitoraggio del traffico. Con Service Connect, le applicazioni possono utilizzare nomi brevi e porte standard per connettersi ai servizi nello stesso cluster, VPCs in altri cluster, anche all'interno della stessa regione. Per ulteriori informazioni, consulta Service Connect di Amazon ECS.
Quando usi Service Connect, Amazon ECS gestisce tutte le parti del rilevamento servizi: crea i nomi che possono essere rilevati, gestisce dinamicamente le voci per ogni attività all'inizio e all'interruzione, esegue un agente in ogni attività configurato per rilevare i nomi. L'applicazione può cercare i nomi utilizzando la funzionalità standard per i nomi DNS e stabilendo connessioni. Se l'applicazione lo fa già, non è necessario modificare l'applicazione per utilizzare Service Connect.
Le modifiche avvengono solo durante le implementazioni
Fornisci la configurazione completa all'interno di ogni definizione di servizio e attività. Amazon ECS gestisce le modifiche a questa configurazione in ogni implementazione del servizio, per garantire che tutte le attività di un'implementazione si comportino nello stesso modo. Ad esempio, un problema comune relativo al DNS come rilevamento servizi è il controllo di una migrazione. Se si modifica un nome DNS in modo che punti ai nuovi indirizzi IP sostitutivi, potrebbe essere necessario il tempo TTL massimo prima che tutti i client inizino a utilizzare il nuovo servizio. Con Service Connect, l'implementazione del client aggiorna la configurazione sostituendo le attività del client. È possibile configurare l'interruttore automatico di implementazione e altre configurazioni di implementazione per influire sulle modifiche di Service Connect allo stesso modo di qualsiasi altra implementazione.
Utilizzo del rilevamento servizi
Un altro approccio alla service-to-service comunicazione è la comunicazione diretta tramite Service Discovery. In questo approccio, puoi utilizzare l'integrazione del rilevamento dei AWS Cloud Map servizi con Amazon ECS. Utilizzando Service Discovery, Amazon ECS sincronizza l'elenco delle attività avviate con AWS Cloud Map, che mantiene un nome host DNS che si risolve negli indirizzi IP interni di una o più attività di quel particolare servizio. Altri servizi nel VPC Amazon possono utilizzare questo nome host DNS per inviare il traffico direttamente a un altro container utilizzando il suo indirizzo IP interno. Per ulteriori informazioni, consulta Rilevamento servizi.
Nel diagramma precedente sono presenti tre servizi. service-a-local ha un container e comunica con service-b-local, che ha due container. service-b-local deve comunicare anche con service-c-local, che ha un container. Ogni contenitore di tutti e tre questi servizi può utilizzare i nomi DNS interni di AWS Cloud Map per trovare gli indirizzi IP interni di un contenitore dal servizio downstream con cui deve comunicare.
Questo approccio alla service-to-service comunicazione offre una bassa latenza. A prima vista è anche semplice, in quanto non ci sono componenti aggiuntivi tra i container. Il traffico viaggia direttamente da un container all'altro.
Questo approccio è adatto quando si utilizza la modalità di rete awsvpc, in cui ogni attività ha il proprio indirizzo IP univoco. La maggior parte dei software supporta solo l'uso di record A del DNS, che si risolvono direttamente negli indirizzi IP. Quando si utilizza la modalità di rete awsvpc, l'indirizzo IP per ogni attività è un record A. Tuttavia, se si utilizza la modalità di rete bridge, è possibile che più container condividano lo stesso indirizzo IP. Inoltre, le mappature dinamiche delle porte fanno sì che ai container vengano assegnati in modo casuale i numeri di porta su quel singolo indirizzo IP. A questo punto, un record A non è più sufficiente per il rilevamento servizi. Devi utilizzare un record SRV. Questo tipo di record può tenere traccia sia degli indirizzi IP che dei numeri di porta, ma richiede la configurazione appropriata delle applicazioni. Alcune applicazioni predefinite utilizzate potrebbero non supportare i record SRV.
Un altro vantaggio della modalità di rete awsvpc è che si dispone di un gruppo di sicurezza unico per ogni servizio. È possibile configurare questo gruppo di sicurezza per consentire le connessioni in entrata solo dai servizi upstream specifici che devono comunicare con quel servizio.
Il principale svantaggio della service-to-service comunicazione diretta che utilizza il service discovery è che è necessario implementare una logica aggiuntiva per ripetere i tentativi e gestire gli errori di connessione. I record DNS hanno un periodo time-to-live (TTL) che controlla per quanto tempo vengono memorizzati nella cache. L'aggiornamento del record DNS e la scadenza della cache richiedono del tempo per consentire alle applicazioni di recuperare la versione più recente del record DNS. Pertanto, l'applicazione potrebbe finire per risolvere il record DNS in modo tale che punti a un altro container non più presente. L'applicazione deve gestire i nuovi tentativi e disporre di una logica per ignorare i backend non validi.
Utilizzo di un bilanciatore del carico interno
Un altro approccio alla service-to-service comunicazione consiste nell'utilizzare un sistema di bilanciamento del carico interno. Un bilanciatore del carico interno esiste interamente all'interno del tuo VPC ed è accessibile solo ai servizi all'interno del tuo VPC.
Il bilanciatore del carico mantiene un'elevata disponibilità distribuendo risorse ridondanti in ogni sottorete. Quando un container di serviceA deve comunicare con un container di serviceB, apre una connessione al bilanciatore del carico. Il bilanciatore del carico apre quindi una connessione a un container di service B. Il bilanciatore del carico funge da luogo centralizzato per la gestione di tutte le connessioni tra ciascun servizio.
Se un container di serviceB si ferma, il bilanciatore del carico può rimuoverlo dal pool. Il bilanciatore del carico esegue inoltre controlli di integrità su ogni destinazione a valle del relativo pool e può rimuovere automaticamente le destinazioni danneggiate dal pool fino a quando non tornano a funzionare di nuovo. Non è più necessario che le applicazioni siano consapevoli del numero di container a valle presenti. Si limitano ad aprire le connessioni al bilanciatore del carico.
Questo approccio è vantaggioso per tutte le modalità di rete. Il bilanciatore del carico può tenere traccia degli indirizzi IP delle attività quando si utilizza la modalità di rete awsvpc, nonché delle combinazioni più avanzate di indirizzi IP e porte quando si utilizza la modalità di rete bridge. Distribuisce in modo uniforme il traffico su tutte le combinazioni di indirizzi IP e porte, anche se diversi container sono effettivamente ospitati sulla stessa EC2 istanza Amazon, solo su porte diverse.
L'unico svantaggio di questo approccio è il costo. Per garantire un'elevata disponibilità, il bilanciatore del carico deve disporre di risorse in ogni zona di disponibilità. Ciò comporta costi aggiuntivi a causa del sovraccarico dovuto al pagamento del bilanciatore del carico e alla quantità di traffico che attraversa il bilanciatore del carico.
Tuttavia, è possibile ridurre i costi generali facendo in modo che più servizi condividano un bilanciatore del carico. Ciò è particolarmente adatto per i servizi REST che utilizzano un sistema Application Load Balancer. È possibile creare regole di instradamento basate sul percorso che instradano il traffico verso servizi diversi. Ad esempio, /api/user/* potrebbe indirizzare verso un container che fa parte del servizio user, mentre /api/order/* potrebbe indirizzare verso il servizio order associato. Con questo approccio, paghi solo per un Application Load Balancer e disponi di un URL adatto per la tua API. Tuttavia, puoi suddividere il traffico verso vari microservizi sul backend.
