# Architettura del carico di lavoro
Un carico di lavoro affidabile comincia con decisioni iniziali di progettazione sia per il software sia per l'infrastruttura. Le tue scelte architetturali avranno un impatto sul comportamento del carico di lavoro su tutti e sei i pilastri del Framework Well-Architected. Per l'affidabilità, è necessario seguire modelli specifici.
Le sezioni seguenti illustrano le best practice da utilizzare con questi modelli per l'affidabilità.
**Topics**
+ [Progettazione dell'architettura del servizio di carico di lavoro](design-your-workload-service-architecture.md)
+ [Progetta interazioni in un sistema distribuito per prevenire guasti](design-interactions-in-a-distributed-system-to-prevent-failures.md)
+ [Progettazione di interazioni in un sistema distribuito per mitigare o affrontare gli errori](design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.md)
# Progettazione dell'architettura del servizio di carico di lavoro
Crea carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici.
Le interfacce di architettura orientata ai servizi (SOA) utilizzano standard di comunicazione comuni in modo da integrarle rapidamente in nuovi carichi di lavoro. La SOA ha sostituito la pratica di costruire architetture monolitiche, che consistevano in unità interdipendenti e indivisibili.
In AWS, abbiamo sempre utilizzato la SOA, ma ora abbiamo adottato la creazione dei nostri sistemi utilizzando microservizi. Anche se i microservizi presentano diverse qualità interessanti, il vantaggio più importante per la disponibilità è che i microservizi sono più piccoli e semplici. Consentono di differenziare la disponibilità richiesta di diversi servizi, concentrando quindi gli investimenti in modo più specifico sui microservizi che hanno le maggiori esigenze di disponibilità. Ad esempio, per distribuire pagine di informazioni sui prodotti su Amazon.com ("pagine dei dettagli"), vengono richiamati centinaia di microservizi per creare porzioni discrete della pagina. Sebbene ci siano alcuni servizi che devono essere disponibili per fornire prezzo e dettagli del prodotto, la maggior parte dei contenuti della pagina può essere semplicemente esclusa se il servizio non è disponibile. Anche elementi come foto e recensioni non sono necessari per fornire un'esperienza in cui un cliente può acquistare un prodotto.
**Topics**
+ [REL03-BP01 Scegli come segmentare il tuo carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornire contratti di assistenza per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Scegli come segmentare il tuo carico di lavoro
La segmentazione del carico di lavoro è importante nel determinare i requisiti di resilienza dell'applicazione. L'architettura monolitica va evitata, se possibile. Valuta invece con particolare attenzione quali componenti dell'applicazione possono essere suddivisi in microservizi. A seconda dei requisiti dell'applicazione, questa potrebbe finire per essere una combinazione di un'architettura orientata ai servizi () con microservizi, ove possibile. SOA I carichi di lavoro stateless sono più idonei all'implementazione come microservizi.
**Risultato desiderato:** i carichi di lavoro devono essere supportabili, scalabili e caratterizzati dal maggiore accoppiamento debole possibile.
Quando scegli come segmentare il carico di lavoro, trova il giusto compromesso tra i vantaggi e le complessità. Ciò che è giusto per un nuovo prodotto al primo lancio è diverso dai requisiti di un carico di lavoro creato per scalare le risorse. Durante la rifattorizzazione di un monolito esistente, dovrai considerare la capacità dell'applicazione di supportare la suddivisione in servizi stateless. La suddivisione dei servizi in elementi più piccoli consente a team ristretti e ben definiti di svilupparli e gestirli. Tuttavia, servizi di piccole dimensioni possono introdurre complessità, che includono un eventuale aumento della latenza, un debug più complesso e un maggiore carico operativo.
**Anti-pattern comuni:**
+ Il [microservizio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un guasto verificatosi in un componente genera un guasto molto più grande, rendendo i componenti rigidi e fragili se considerati come monolito.
**Vantaggi dell'adozione di questa best practice:**
+ Segmenti più specifici comportano maggiore agilità, flessibilità organizzativa e scalabilità.
+ Riduzione dell'impatto derivante dall'interruzione dei servizi.
+ I componenti dell'applicazione possono avere requisiti di disponibilità diversi, che a loro volta possono essere supportati da una segmentazione più atomica.
+ Responsabilità ben definite per i team che supportano il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Scegli il tipo di architettura in base al tipo di segmentazione del carico di lavoro. Scegliete un'SOAarchitettura a microservizi (o, in alcuni rari casi, un'architettura monolitica). Anche se scegli di iniziare con un'architettura monolitica, devi assicurarti che sia modulare e che alla fine possa evolversi verso i nostri microservizi man mano che il prodotto cresce con l'SOAadozione da parte degli utenti. SOAe i microservizi offrono rispettivamente una segmentazione più ridotta, che è preferibile in un'architettura moderna, scalabile e affidabile, ma ci sono dei compromessi da considerare, soprattutto quando si implementa un'architettura di microservizi.
Uno dei principali compromessi è che ora disponi di un'architettura di calcolo distribuita che può rendere più difficile il raggiungimento dei requisiti di latenza degli utenti ed è presente un'ulteriore complessità nel debug e nel tracciamento delle interazioni degli utenti. Puoi utilizzare AWS X-Ray per risolvere questo problema. Un altro effetto da considerare è l'aumento della complessità operativa man mano che aumenta il numero di applicazioni che gestisci, che richiede l'implementazione di più componenti di indipendenza.
![\[Diagramma che illustra il confronto tra architettura monolitica, orientata ai servizi e di microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Passaggi dell'implementazione
+ Determina l'architettura più opportuna per rifattorizzare o creare l'applicazione. SOAe i microservizi offrono rispettivamente una segmentazione più piccola, preferibile come architettura moderna, scalabile e affidabile. SOApuò essere un buon compromesso per ottenere una segmentazione più piccola evitando al contempo alcune delle complessità dei microservizi. Per ulteriori dettagli, consulta [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se il carico di lavoro è adatto e la tua organizzazione può supportarla, è consigliabile utilizzare un'architettura di microservizi per ottenere la massima agilità e affidabilità. Per ulteriori dettagli, consulta [Implementazione](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) dei microservizi su. AWS
+ Valuta l'idea di attenerti al [modello *Strangler Fig*](https://martinfowler.com/bliki/StranglerFigApplication.html) per rifattorizzare un monolite in componenti più piccoli. Ciò comporta la sostituzione graduale di componenti applicativi specifici con nuove applicazioni e servizi. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) funge da punto di partenza per procedere a rifattorizzare in modo incrementale. Per ulteriori dettagli, consulta [Seamlessly migrate on-premises legacy workloads using a strangler pattern](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implementazione dei microservizi può richiedere un meccanismo di rilevamento dei servizi per consentire a questi servizi distribuiti di comunicare tra loro. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)può essere utilizzato con architetture orientate ai servizi per fornire l'individuazione e l'accesso affidabili ai servizi. [AWS Cloud Map](https://aws.amazon.com/cloud-map/)può essere utilizzato anche per l'individuazione dinamica dei servizi. DNS
+ Se stai migrando da un monolite a, [Amazon SOA MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) può aiutarti a colmare il divario come bus di servizio durante la riprogettazione delle applicazioni legacy nel cloud.
+ Per i monoliti esistenti con un unico database condiviso, scegli come riorganizzare i dati in segmenti più piccoli. Questa riorganizzazione può avvenire per business unit, schema di accesso o struttura dei dati. A questo punto del processo di refactoring, dovresti scegliere di procedere con un tipo di database relazionale o non relazionale (No). SQL [Per maggiori dettagli, consulta From to No. SQL SQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html)
**Livello di impegno per il piano di implementazione:** elevato
## Risorse
**Best practice correlate:**
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di un REST API utilizzo di Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Cosa si intende per SOA (architettura orientata ai servizi)?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi su AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [Microservizi attivi AWS](https://aws.amazon.com/microservices/)
+ [Che cos'è AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Esempi correlati:**
+ [Iterative App Modernization Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video correlati:**
+ [Offrire l'eccellenza con i microservizi attivi AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici
L'architettura orientata ai servizi (SOA) definisce servizi con funzioni ben delineate determinate dalle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per tracciare i limiti dei servizi lungo i confini del contesto aziendale. Concentrarsi sui domini e sulle funzionalità aziendali aiuta i team a definire requisiti di affidabilità indipendenti per i propri servizi. I contesti delimitati isolano e incapsulano la logica aziendale, consentendo ai team di ragionare meglio su come gestire gli errori.
**Risultato desiderato:** ingegneri e parti interessate aziendali definiscono congiuntamente contesti delimitati e li utilizzano per progettare sistemi come servizi che soddisfano funzioni aziendali specifiche. Questi team utilizzano pratiche consolidate come l'event storming per definire i requisiti. Le nuove applicazioni sono concepite come servizi con confini ben definiti e con accoppiamento debole. Avviene la scomposizione dei monoliti esistenti in [contesti delimitati](https://martinfowler.com/bliki/BoundedContext.html) e i progetti di sistema migrano verso architetture SOA o microservizi. In caso di rifattorizzazione dei monoliti, vengono applicati approcci consolidati come contesti a bolle e schemi di decomposizione dei monoliti.
I servizi orientati al dominio vengono eseguiti come uno o più processi che non condividono lo stato. Rispondono in modo indipendente alle fluttuazioni della domanda e gestiscono gli scenari di errore alla luce dei requisiti specifici del dominio.
**Anti-pattern comuni:**
+ I team sono formati su domini tecnici specifici come UI e UX, middleware (software intermediario) o database anziché su domini aziendali specifici.
+ Le applicazioni coprono le responsabilità di dominio. I servizi che coprono contesti delimitati possono essere più difficili da gestire, richiedere maggiori sforzi di test ed esigere la partecipazione di più team di dominio agli aggiornamenti software.
+ Le dipendenze a livello di dominio, come le librerie di entità di dominio, sono condivise tra i servizi, in modo che le modifiche per il dominio di un servizio richiedano modifiche ad altri domini dei servizi.
+ I contratti di servizio e la logica aziendale non esprimono le entità in un linguaggio di dominio comune e coerente, con il risultato di livelli di traduzione che complicano i sistemi e aumentano le attività di debug.
**Vantaggi dell'adozione di questa best practice:** le applicazioni sono progettate come servizi indipendenti limitati da domini aziendali e utilizzano un linguaggio aziendale comune. I servizi sono testabili e implementabili in modo indipendente. I servizi soddisfano i requisiti di resilienza specifici del dominio implementato.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
La progettazione basata sul dominio (DDD) costituisce l'approccio fondamentale alla progettazione e alla creazione di software attorno ai domini aziendali. È utile utilizzare un framework esistente quando si creano servizi incentrati sui domini aziendali. Quando si utilizzano applicazioni monolitiche esistenti, è possibile sfruttare i modelli di decomposizione che forniscono tecniche consolidate per modernizzare le applicazioni in servizi.
![\[Diagramma di flusso che illustra l'approccio incentrato sulla progettazione basata sul dominio.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Passaggi dell'implementazione
+ I team possono organizzare workshop di [event storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) per identificare rapidamente eventi, comandi, aggregati e domini in un formato leggero simile a quello delle note adesive.
+ Una volta create le entità e le funzioni di dominio in un contesto di dominio, puoi suddividere il dominio in servizi mediante il [contesto delimitato](https://martinfowler.com/bliki/BoundedContext.html), che raggruppa entità con funzionalità e attributi simili. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi.
+ Ad esempio, le entità del sito Web Amazon.com possono includere elementi quali pacchetti, distribuzione, pianificazione, prezzo, sconto e valuta.
+ Il pacchetto, la distribuzione e la pianificazione sono raggruppati nel contesto di spedizione, mentre il prezzo, lo sconto e la valuta sono raggruppati nel contesto dei prezzi.
+ La [scomposizione dei monoliti in microservizi](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) delinea i modelli per rifattorizzare i microservizi. L'utilizzo di modelli per la decomposizione in base a capacità aziendale, sottodominio o transazione si allinea bene agli approcci basati sul dominio.
+ Tecniche di strategia come il [contesto a bolle](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) consentono di introdurre la decisione basata sul dominio (DDD) in applicazioni esistenti o legacy senza riscritture anticipate e impegni completi nei confronti di DDD. In un approccio basato sul contesto delle bolle, si crea un contesto ristretto e delimitato mediante un livello di mappatura e coordinamento dei servizi o il [livello anticorruzione](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), che protegge il modello di dominio appena definito dalle influenze esterne.
Dopo aver eseguito l'analisi del dominio e definito le entità e i contratti di servizio, i team possono utilizzare i servizi AWS per implementare la progettazione basata sul dominio come servizi basati sul cloud.
+ Inizia a sviluppare definendo test che applichino le regole aziendali del tuo dominio. Lo sviluppo basato sui test (TDD) e lo sviluppo basato sul comportamento (BDD) aiutano i team a focalizzare i servizi sulla risoluzione dei problemi aziendali.
+ [Seleziona i [servizi AWS](https://aws.amazon.com/microservices/) ideali per i requisiti del tuo dominio aziendale e l'architettura dei microservizi](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [AWS Serverless](https://aws.amazon.com/serverless/) consente al team di concentrarsi su una logica di dominio specifica anziché sulla gestione di server e infrastrutture.
+ I [container in AWS](https://aws.amazon.com/containers/) semplificano la gestione della tua infrastruttura, in modo da poterti concentrare sui requisiti del tuo dominio.
+ I [database dedicati](https://aws.amazon.com/products/databases/) ti aiutano ad adattare i requisiti del tuo dominio al tipo di database più idoneo.
+ La [creazione di architetture esagonali in AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) delinea un framework per integrare la logica aziendale nei servizi che funzionano a ritroso da un dominio aziendale per soddisfare i requisiti funzionali e, quindi, per collegare adattatori di integrazione. I modelli che separano i dettagli dell'interfaccia dalla logica aziendale con i servizi AWS aiutano i team a concentrarsi sulla funzionalità del dominio e a migliorare la qualità del software.
## Risorse
**Best practice correlate:**
+ [REL03-BP01 Scegli come segmentare il tuo carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Fornire contratti di assistenza per API](rel_service_architecture_api_contracts.md)
**Documenti correlati:**
+ [Microservizi AWS](https://aws.amazon.com/microservices/)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software ](https://www.amazon.com/gp/product/0321125215)
+ [ Building hexagonal architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Decomposing monoliths into microservices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Messages Between Bounded Contexts ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Sviluppo basato su test ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Sviluppo basato sul comportamento ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Esempi correlati:**
+ [ Progettazione di microservizi cloud-native (nativi del cloud) su AWS (da DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Strumenti correlati:**
+ [Database Cloud AWS](https://aws.amazon.com/products/databases/)
+ [ Serverless in AWS](https://aws.amazon.com/serverless/)
+ [ Container in AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Fornire contratti di assistenza per API
I contratti di assistenza sono accordi documentati tra API produttori e consumatori definiti in una definizione leggibile da una macchinaAPI. Una strategia di controllo delle versioni contrattuali consente ai consumatori di continuare a utilizzare le applicazioni esistenti API e di migrare le proprie applicazioni a una versione più recente quando sono pronte. API L'implementazione da parte del produttore può avvenire in qualsiasi momento, purché il processo sia conforme al contratto. I team di assistenza possono utilizzare lo stack tecnologico di loro scelta per soddisfare il contratto. API
**Risultato desiderato:** le applicazioni create con architetture orientate ai servizi o ai microservizi sono in grado di funzionare in modo indipendente pur avendo una dipendenza di runtime integrata. Le modifiche apportate a un API consumatore o a un produttore non interrompono la stabilità dell'intero sistema quando entrambe le parti seguono un contratto comune. API I componenti che comunicano tramite servizio APIs possono eseguire rilasci funzionali indipendenti, aggiornamenti alle dipendenze di runtime o eseguire il failover su un sito di disaster recovery (DR) con un impatto reciproco minimo o nullo. Inoltre, i servizi discreti sono in grado di scalare in modo indipendente assorbendo la richiesta di risorse senza che gli altri servizi debbano ridurre orizzontalmente di conseguenza.
**Anti-pattern comuni:**
+ Creazione di servizi APIs senza schemi fortemente tipizzati. Ciò comporta APIs che non può essere utilizzato per generare API associazioni e payload che non possono essere convalidati programmaticamente.
+ Non adottare una strategia di controllo delle versioni, che costringerebbe gli API utenti ad aggiornare e rilasciare o fallire quando i contratti di assistenza si evolvono.
+ Messaggi di errore che divulgano dettagli sull'implementazione del servizio sottostante anziché descrivere errori di integrazione nel contesto e nel linguaggio del dominio.
+ Non utilizzare API contratti per sviluppare casi di test e API implementazioni fittizie per consentire test indipendenti dei componenti del servizio.
**Vantaggi derivanti dall'adozione di questa best practice:** i sistemi distribuiti composti da componenti che comunicano tramite contratti di API assistenza possono migliorare l'affidabilità. Gli sviluppatori possono individuare potenziali problemi nelle prime fasi del processo di sviluppo grazie al controllo del tipo durante la compilazione per verificare che le richieste e le risposte siano conformi al API contratto e che i campi obbligatori siano presenti. APIi contratti forniscono una chiara interfaccia di autodocumentazione APIs e forniscono una migliore interoperabilità tra diversi sistemi e linguaggi di programmazione.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Dopo aver identificato i domini aziendali e determinato la segmentazione del carico di lavoro, puoi sviluppare il tuo servizio. APIs Innanzitutto, definisci contratti di assistenza leggibili automaticamente e poi implementa una strategia di controllo delle APIs versioni. API Quando sei pronto per integrare i servizi tramite protocolli comuni come REST GraphQL o eventi asincroni, puoi incorporare AWS servizi nella tua architettura per integrare i componenti con contratti fortemente tipizzati. API
**AWS APIservizi per contratti di assistenza**
Incorpora AWS servizi tra cui [Amazon API Gateway](https://aws.amazon.com/api-gateway/) e [Amazon EventBridge](https://aws.amazon.com/eventbridge/) nella tua architettura per utilizzare i contratti di API servizio nella tua applicazione. [AWS AppSync](https://aws.amazon.com/appsync/) Amazon API Gateway ti aiuta a integrarti con AWS servizi nativi diretti e altri servizi Web. APIGateway supporta le [APIspecifiche e il controllo delle versioni Open](https://github.com/OAI/OpenAPI-Specification). AWS AppSync è un endpoint [GraphQL](https://graphql.org/) gestito che puoi configurare definendo uno schema GraphQL per definire un'interfaccia di servizio per query, mutazioni e sottoscrizioni. Amazon EventBridge utilizza schemi di eventi per definire eventi e generare associazioni di codice per i tuoi eventi.
## Passaggi dell'implementazione
+ Innanzitutto, definisci un contratto per il tuo. API Un contratto esprimerà le capacità di un e API definirà oggetti di dati e campi fortemente tipizzati per l'APIinput e l'output.
+ Quando esegui la configurazione APIs in API Gateway, puoi importare ed esportare API le specifiche aperte per i tuoi endpoint.
+ [L'importazione di una API definizione aperta](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) semplifica la creazione della propria definizione API e può essere integrata con l' AWS infrastruttura come strumenti di codice come la e. [AWS Serverless Application Model[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)](https://aws.amazon.com/serverless/sam/)
+ [L'esportazione di una API definizione](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) semplifica l'integrazione con gli strumenti di API test e fornisce ai consumatori di servizi una specifica di integrazione.
+ Puoi definire e gestire GraphQL APIs AWS AppSync [definendo un file di schema GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) per generare l'interfaccia del contratto e semplificare l'interazione con REST modelli complessi, più tabelle di database o servizi legacy.
+ [AWS Amplify](https://aws.amazon.com/amplify/)i progetti integrati AWS AppSync generano file di JavaScript query fortemente tipizzati da utilizzare nella tua applicazione e una libreria client AWS AppSync GraphQL per le tabelle Amazon [DynamoDB](https://aws.amazon.com/dynamodb/).
+ Quando utilizzi gli eventi di servizio di Amazon EventBridge, gli eventi aderiscono a schemi già esistenti nel registro degli schemi o definiti con Open API Spec. Con uno schema definito nel registro, puoi anche generare associazioni client dal contratto dello schema per integrare il codice con gli eventi.
+ Estendere o modificare il tuo. API L'estensione di un API è un'opzione più semplice quando si aggiungono campi che possono essere configurati con campi opzionali o valori predefiniti per i campi obbligatori.
+ JSONi contratti basati su protocolli come REST GraphQL possono essere adatti per l'estensione del contratto.
+ XMLi contratti basati su protocolli, ad esempio, SOAP dovrebbero essere testati con i consumatori di servizi per determinare la fattibilità dell'estensione del contratto.
+ Quando si effettua il versionamento di unAPI, è consigliabile implementare il controllo delle versioni proxy, in cui viene utilizzata una facciata per supportare le versioni in modo che la logica possa essere mantenuta in un'unica base di codice.
+ Con API Gateway puoi utilizzare le [mappature di richiesta e risposta](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) per semplificare l'assorbimento delle modifiche contrattuali, stabilendo una facciata per fornire valori predefiniti per nuovi campi o per eliminare i campi rimossi da una richiesta o risposta. Con questo approccio, il servizio sottostante può avere un'unica base di codice.
## Risorse
**Best practice correlate:**
+ [REL03-BP01 Scegli come segmentare il tuo carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementare dipendenze liberamente accoppiate](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Controlla e limita le chiamate di nuovo tentativo](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Imposta i timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
**Documenti correlati:**
+ [Che cos'è una API (interfaccia di programmazione delle applicazioni)?](https://aws.amazon.com/what-is/api/)
+ [Implementazione di microservizi su AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Microservice Trade-Offs ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices - a definition of this new architectural term ](https://www.martinfowler.com/articles/microservices.html)
+ [Microservizi attivi AWS](https://aws.amazon.com/microservices/)
+ [Utilizzo delle estensioni API Gateway to Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [Apri API - Specificazione](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: schemi e tipi ](https://graphql.org/learn/schema/)
+ [Associazioni di EventBridge codice Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Esempi correlati:**
+ [Amazon API Gateway: configurazione di un REST API utilizzo di Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Da Amazon API Gateway all'applicazione Amazon CRUD DynamoDB tramite Open API](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Modelli di integrazione delle applicazioni moderni nell'era senza server: API Gateway Service Integration](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [Implementazione del controllo delle versioni API Gateway basato su header con Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: Building a client application ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Video correlati:**
+ [Utilizzo di Open API in AWS SAM per gestire Gateway API](https://www.youtube.com/watch?v=fet3bh0QA80)
**Strumenti correlati:**
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)
# Progetta interazioni in un sistema distribuito per prevenire guasti
I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti, ad esempio server o servizi. Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati su queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice consentono di prevenire gli errori e migliorare il tempo medio tra guasti (MTBF).
**Topics**
+ [REL04-BP01 Identificazione del tipo di sistema distribuito da cui si dipende](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementare dipendenze liberamente accoppiate](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Fai un lavoro costante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendere idempotenti le operazioni di mutazione](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificazione del tipo di sistema distribuito da cui si dipende
I sistemi distribuiti possono essere sincroni, asincroni o batch. I sistemi sincroni devono elaborare le richieste il più rapidamente possibile e comunicare tra loro effettuando chiamate di richiesta e risposta sincrone utilizzando i protocolli HTTP/S, REST o RPC (Remote Procedure Call). I sistemi asincroni comunicano tra loro scambiando i dati in modo asincrono tramite un servizio intermediario senza associare singoli sistemi. I sistemi batch ricevono un grande volume di dati di input, eseguono i processi di dati automatizzati senza intervento umano e generano i dati di output.
**Risultato desiderato**: progettazione di un carico di lavoro in grado di interagire in modo efficace con dipendenze sincrone, asincrone e batch.
**Anti-pattern comuni:**
+ Il carico di lavoro attende a tempo indeterminato una risposta dalle dipendenze, con eventuale timeout del client del carico di lavoro, senza informazioni sulla ricezione della richiesta.
+ Il carico di lavoro utilizza una catena di sistemi dipendenti che effettuano chiamate reciproche in modo sincrono. A tal fine, ogni sistema deve essere disponibile ed elaborare correttamente la richiesta prima che l'intera catena possa essere completata, con conseguenti comportamenti e disponibilità complessiva potenzialmente fragili.
+ Il carico di lavoro comunica con le dipendenze in modo asincrono e si basa sul concetto di distribuzione garantita dei messaggi esattamente una volta, quando spesso è ancora possibile ricevere messaggi duplicati.
+ Il carico di lavoro non utilizza strumenti di pianificazione batch adeguati e consente l'esecuzione simultanea dello stesso processo batch.
**Vantaggi dell'adozione di questa best practice**: non è insolito che un determinato carico di lavoro implementi uno o più stili di comunicazione tra sincroni, asincroni e batch. Questa best practice consente di identificare i diversi compromessi associati a ogni stile di comunicazione per rendere il carico di lavoro in grado di tollerare interruzioni in tutte le sue dipendenze.
**Livello di rischio associato se questa best practice non fosse adottata**: elevato
## Guida all’implementazione
Le sezioni seguenti contengono le linee guida per l'implementazione generali e specifiche di ogni tipo di dipendenza.
**Informazioni generali**
+ Assicurati che gli obiettivi del livello di servizio (SLO) in termini di prestazioni e affidabilità offerti dalle dipendenze soddisfino i requisiti di prestazioni e affidabilità del tuo carico di lavoro.
+ Utilizza [i servizi di osservabilità AWS](https://aws.amazon.com/cloudops/monitoring-and-observability) per [monitorare i tempi di risposta e i tassi di errore](https://www.youtube.com/watch?v=or7uFFyHIX0) così da verificare che la tua dipendenza fornisca un servizio ai livelli richiesti dal carico di lavoro.
+ Individua le potenziali sfide che il carico di lavoro può affrontare quando comunica con le dipendenze. I sistemi distribuiti [presentano un'ampia gamma di sfide](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) in grado di far aumentare complessità dell'architettura, carico operativo e costi. Le sfide più comuni includono latenza, interruzioni della rete, perdita dei dati, scalabilità e ritardo nella replica dei dati.
+ Implementa una gestione e una [creazione di log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) affidabili degli errori per risolvere i problemi quando si verificano quelli legati alle dipendenze.
**Dipendenza sincrona**
Nelle comunicazioni sincrone, il carico di lavoro invia una richiesta alla dipendenza e blocca l'operazione in attesa della risposta. Quando la dipendenza riceve la richiesta, cerca di gestirla il prima possibile e invia una risposta al carico di lavoro. Una sfida significativa con la comunicazione sincrona è rappresentata dall'accoppiamento temporale, che richiede che il carico di lavoro e le sue dipendenze siano disponibili nello stesso momento. Quando il carico di lavoro deve comunicare in modo sincrono con le dipendenze, valuta le seguenti linee guida:
+ Il carico di lavoro non deve fare affidamento su più dipendenze sincrone per eseguire una singola funzione. Questa catena di dipendenze aumenta la fragilità complessiva perché tutte le dipendenze nel percorso devono essere disponibili affinché la richiesta venga completata correttamente.
+ Quando una dipendenza non è integra o non è disponibile, applica le strategie di gestione degli errori e riprova. Evita di usare un comportamento bimodale. Il comportamento bimodale si verifica quando il carico di lavoro presenta un comportamento diverso in modalità normale e in modalità di guasto. Per ulteriori dettagli sul comportamento bimodale, consulta [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ Tieni presente che anticipare l'errore (fail fast) è meglio che far aspettare il carico di lavoro. Ad esempio, la [guida per gli sviluppatori AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) illustra come gestire tentativi ed errori nel richiamare le funzioni Lambda.
+ Imposta i timeout per le chiamate delle dipendenze da parte del carico di lavoro. Questa tecnica evita di aspettare troppo a lungo o all'infinito una risposta. Per un'utile discussione su questo argomento, consulta [Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/).
+ Riduci al minimo il numero di chiamate effettuate dal carico di lavoro alla dipendenza per soddisfare una singola richiesta. Le lunghe chiamate aumentano l'associazione e la latenza.
**Dipendenza sincrona**
Per disaccoppiare temporaneamente il carico di lavoro dalla dipendenza, è necessario che comunichino in modo asincrono. Con l'approccio asincrono, il carico di lavoro può continuare qualsiasi altra elaborazione senza dover attendere che la dipendenza o la catena di dipendenze invii la risposta.
Quando il carico di lavoro deve comunicare in modo asincrono con la dipendenza, tieni conto delle seguenti indicazioni:
+ Determina in base al caso d'uso e ai requisiti se utilizzare la messaggistica o lo streaming di eventi. La [messaggistica](https://aws.amazon.com/messaging/) consente al carico di lavoro di comunicare con la relativa dipendenza, inviando e ricevendo messaggi tramite un broker di messaggi. Lo [streaming di eventi](https://aws.amazon.com/streaming-data/) consente al carico di lavoro e alla relativa dipendenza di utilizzare un servizio di streaming per la pubblicazione e l'abbonamento a eventi, forniti come flussi continui di dati, da elaborare il prima possibile.
+ La messaggistica e lo streaming di eventi gestiscono i messaggi in modo diverso, quindi devi stabilire i compromessi in base a:
+ **Priorità dei messaggi:** i broker di messaggi sono in grado di elaborare messaggi ad alta priorità prima di quelli normali. Nello streaming di eventi, tutti i messaggi presentano la stessa priorità.
+ **Consumo di messaggi**: i broker di messaggi garantiscono la ricezione del messaggio da parte dei consumatori. Gli utenti che utilizzano lo streaming di eventi devono tenere traccia dell'ultimo messaggio letto.
+ **Ordinamento dei messaggi**: utilizzando la messaggistica, la ricezione dei messaggi nell'ordine esatto di invio non è garantita, salvo in caso di un approccio first-in-first-out (FIFO). Lo streaming di eventi mantiene sempre l'ordine in cui i dati sono stati prodotti.
+ **Eliminazione dei messaggi**: con la messaggistica, il consumatore deve eliminare il messaggio dopo la relativa elaborazione. Il servizio di streaming di eventi aggiunge il messaggio a un flusso e lo conserva fino alla scadenza del periodo di conservazione del messaggio. Questa policy di eliminazione rende lo streaming di eventi adatto alla riproduzione dei messaggi.
+ Definisci in che modo il carico di lavoro riconosce il completamento del lavoro della dipendenza. Ad esempio, quando il carico di lavoro procede a richiamare una [funzione Lambda in modo asincrono](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html), Lambda inserisce la richiesta in una coda e restituisce una risposta di esito positivo senza ulteriori informazioni. Al termine dell'elaborazione, la funzione Lambda può [inviare il risultato a una destinazione](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations), configurabile in base all'esito positivo o negativo.
+ Crea il tuo carico di lavoro per gestire i messaggi duplicati utilizzando l'idempotenza. Con l'idempotenza i risultati del carico di lavoro non cambiano anche se il carico di lavoro viene generato più volte per lo stesso messaggio. È importante sottolineare che i servizi di [messaggistica](https://aws.amazon.com/sqs/faqs/#FIFO_queues) o [streaming](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) recapiteranno di nuovo un messaggio in caso di errore di rete o mancata ricezione della conferma.
+ Se il carico di lavoro non riceve una risposta dalla dipendenza, deve inviare nuovamente la richiesta. Valuta la possibilità di limitare il numero di tentativi per preservare la CPU, la memoria e le risorse di rete del carico di lavoro al fine di gestire le altre richieste. La [documentazione AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) illustra come gestire gli errori di invocazione asincrona.
+ Utilizza gli strumenti di osservabilità, debug e monitoraggio adeguati per gestire e usare la comunicazione asincrona del carico di lavoro con le relative dipendenze. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) ti consente di monitorare i servizi di [messaggistica](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) e [streaming di eventi](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html). Puoi anche dotare di strumenti il tuo carico di lavoro con [AWS X-Ray](https://aws.amazon.com/xray/) per [ottenere informazioni utili](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html) rapidamente per la risoluzione dei problemi.
**Dipendenza dal batch**
I sistemi batch acquisiscono i dati di input, avviano una serie di processi per elaborarli e producono i dati di output, senza intervento manuale. A seconda delle dimensioni dei dati, i processi possono durare da minuti a diversi giorni in alcuni casi. Quando il carico di lavoro comunica con la dipendenza batch, tieni conto delle seguenti indicazioni:
+ Definisci la finestra temporale in cui il carico di lavoro deve eseguire il processo batch. Puoi impostare un modello di ricorrenza per il carico di lavoro per richiamare il sistema batch, ad esempio ogni ora o alla fine di ogni mese.
+ Determina la posizione dei dati di input e di output elaborati. Scegli un servizio di archiviazione, come [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) e [Amazon FSx per Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html), in modo che il tuo carico di lavoro possa leggere e scrivere file su larga scala.
+ Se il tuo carico di lavoro deve richiamare più processi batch, puoi sfruttare [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) per semplificare l'orchestrazione dei processi batch eseguiti in AWS o on-premises. Questo [progetto di esempio](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app) mostra l'orchestrazione di processi batch utilizzando Step Functions, [AWS Batch](https://aws.amazon.com/batch/) e Lambda.
+ Monitora i processi batch per individuare eventuali anomalie, ad esempio un processo che richiede più tempo del dovuto per essere completato. Puoi utilizzare strumenti come [CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html) per monitorare ambienti e processi AWS Batch. In tal caso, il carico di lavoro interrompe l'inizio del processo successivo e comunica l'eccezione al team competente.
## Risorse
**Documenti correlati**:
+ [Cloud AWS Operations: monitoraggio e osservabilità](https://aws.amazon.com/cloudops/monitoring-and-observability)
+ [Amazon Builders' Library: difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [AWS Lambda Developer Guide: Error handling and automatic retries in AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
+ [Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)
+ [Messaggi AWS](https://aws.amazon.com/messaging/)
+ [Cosa sono i flussi di dati?](https://aws.amazon.com/streaming-data/)
+ [AWS Lambda Developer Guide: Asynchronous invocation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)
+ [Amazon Simple Queue Service FAQ: FIFO queues](https://aws.amazon.com/sqs/faqs/#FIFO_queues)
+ [Amazon Kinesis Data Streams Developer Guide: Handling Duplicate Records](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)
+ [Amazon Simple Queue Service Developer Guide: Available CloudWatch metrics for Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)
+ [Amazon Kinesis Data Streams Developer Guide: Monitoring the Amazon Kinesis Data Streams Service with Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)
+ [AWS X-Ray Developer Guide: AWS X-Ray concepts](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html)
+ [Esempi AWS su GitHub: AWS Step functions Complex Orchestrator App](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app)
+ [Guida per l'utente AWS Batch: AWS Batch CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html)
**Video correlati:**
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS (COP310)](https://www.youtube.com/watch?v=or7uFFyHIX0)
**Strumenti correlati**:
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon FSx per Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc)
+ [AWS Batch](https://aws.amazon.com/batch/)
# REL04-BP02 Implementare dipendenze liberamente accoppiate
Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e bilanciatori del carico sono con accoppiamento debole. L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
Il disaccoppiamento delle dipendenze, come i sistemi di coda, quelli di streaming e i flussi di lavoro, favorisce la riduzione al minimo dell'impatto sul sistema di modifiche o guasti. Tale separazione isola il comportamento di un componente dall'impatto sugli altri dipendenti dallo stesso, migliorando resilienza e agilità.
Nei sistemi con accoppiamento stretto, le modifiche a un componente possono richiedere modifiche agli altri componenti basati su di esso, con conseguente riduzione delle prestazioni di tutti i componenti. L'accoppiamento *debole* interrompe questa dipendenza, in modo che i componenti dipendenti debbano conoscere solo l'interfaccia con versione e pubblicata. L'implementazione di un accoppiamento debole tra dipendenze isola un errore all'interno di una dipendenza affinché non influenzi l'altra.
L'accoppiamento debole consente di modificare il codice o aggiungere funzionalità a un componente riducendo al minimo il rischio per gli altri componenti che dipendono da esso. Garantisce inoltre una resilienza granulare a livello di componente in cui è possibile aumentare orizzontalmente o persino modificare l'implementazione sottostante della dipendenza.
Per migliorare ulteriormente la resilienza tramite accoppiamento debole, rendi le interazioni dei componenti asincrone laddove possibile. Questo modello è idoneo a qualsiasi interazione che non richieda una risposta immediata e laddove la conferma della registrazione di una richiesta sia sufficiente. Include un componente che genera eventi e un altro che li utilizza. I due componenti non si integrano tramite un' point-to-pointinterazione diretta, ma di solito attraverso un livello di storage intermedio durevole, come una SQS coda Amazon, una piattaforma di dati di streaming come Amazon Kinesis o. AWS Step Functions
![\[Diagramma che mostra dipendenze come sistemi di accodamento e bilanciatori del carico con accoppiamento debole\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/dependency-diagram.png)
Amazon mette in SQS coda e AWS Step Functions sono solo due modi per aggiungere uno strato intermedio per l'accoppiamento libero. Le architetture basate sugli eventi possono anche essere create utilizzando Cloud AWS Amazon EventBridge, che può astrarre i clienti (produttori di eventi) dai servizi su cui fanno affidamento (consumatori di eventi). Amazon Simple Notification Service (AmazonSNS) è una soluzione efficace quando è necessaria una messaggistica basata su push ad alta velocità. many-to-many Utilizzando SNS gli argomenti di Amazon, i tuoi sistemi di pubblicazione possono inviare messaggi a un gran numero di endpoint di abbonati per l'elaborazione parallela.
Mentre le code offrono diversi vantaggi, nella maggior parte dei sistemi hard real-time, le richieste più vecchie di una soglia temporale (spesso secondi) dovrebbero essere considerate obsolete (il client ha abbandonato e non è più in attesa di una risposta) e non elaborate. In questo modo, è possibile elaborare invece le richieste più recenti (e probabilmente ancora valide).
**Risultato desiderato:** riduzione al minimo l'area della superficie in caso di guasto a livello di componente, supportando così diagnostica e risoluzione dei problemi, grazie all'implementazione di dipendenze con accoppiamento debole. Inoltre, semplifica i cicli di sviluppo, consentendo ai team di implementare le modifiche a livello modulare senza pregiudicare le prestazioni di altri componenti che dipendono da esso. Questo approccio offre la possibilità di aumentare orizzontalmente a livello di componente in base al fabbisogno di risorse, nonché di utilizzare un componente che contribuisce alla competitività in termini di costi.
**Anti-pattern comuni:**
+ Implementazione di un carico di lavoro monolitico.
+ Richiamo diretto APIs tra livelli di carico di lavoro senza possibilità di failover o elaborazione asincrona della richiesta.
+ Accoppiamento stretto utilizzando dati condivisi. I sistemi con accoppiamento debole dovrebbero evitare di condividere i dati tramite database condivisi o altre forme di archiviazione di dati con accoppiamento stretto, che possono reintrodurre l'accoppiamento stretto e compromettere la scalabilità.
+ Ignorare la contropressione. Il carico di lavoro dovrebbe essere in grado di rallentare o arrestare i dati in arrivo quando un componente non è in grado di elaborarli alla stessa velocità.
**Vantaggi dell'adozione di questa best practice:** l'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità. L'errore in un componente è isolato dagli altri.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Implementazione di dipendenze con accoppiamento debole Esistono varie soluzioni che consentono di creare applicazioni con accoppiamento debole. Questi includono servizi per l'implementazione di code completamente gestite, flussi di lavoro automatizzati, la reazione agli eventi e, APIs tra gli altri, che possono aiutare a isolare il comportamento dei componenti dagli altri componenti e, di conseguenza, aumentare la resilienza e l'agilità.
+ **Crea architetture basate sugli eventi: [ EventBridgeAmazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ti aiuta a creare architetture basate sugli** eventi liberamente accoppiate e distribuite.
+ **Implementazione di code in sistemi distribuiti:** puoi utilizzare [Amazon Simple Queue Service SQS (Amazon)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) per integrare e disaccoppiare sistemi distribuiti.
+ **Containerizza i componenti come microservizi: i [microservizi](https://aws.amazon.com/microservices/)** consentono ai team di creare applicazioni composte da piccoli componenti indipendenti che comunicano in modo ben definito. APIs [Amazon Elastic Container Service (AmazonECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) e [Amazon Elastic Kubernetes Service (EKSAmazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)) possono aiutarti a iniziare a usare i container più velocemente.
+ **Gestisci i flussi di lavoro con Step Functions:** [Step Functions](https://aws.amazon.com/step-functions/getting-started/) ti aiuta a coordinare più AWS servizi in flussi di lavoro flessibili.
+ **Sfrutta le architetture di messaggistica publish-subscribe (pub/sub): Amazon Simple Notification Service (Amazon SNS**[)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) fornisce il recapito dei messaggi dagli editori agli abbonati (noti anche come produttori e consumatori).
### Passaggi dell'implementazione
+ I componenti in un'architettura basata su eventi vengono avviati dagli eventi. Gli eventi sono azioni che si verificano in un sistema, ad esempio un utente che aggiunge un articolo a un carrello. Quando un'azione ha successo, viene generato un evento che attiva il successivo componente del sistema.
+ [Creazione di applicazioni basate sugli eventi con Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022 - Progettazione di integrazioni basate sugli eventi con Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ I sistemi di messaggistica distribuiti sono composti da tre parti principali che devono essere implementate per un'architettura basata su code. Includono componenti del sistema distribuito, la coda utilizzata per il disaccoppiamento (distribuita sui SQS server Amazon) e i messaggi in coda. Un sistema tipico prevede produttori che inviano il messaggio alla coda e il consumatore che riceve il messaggio dalla coda. La coda archivia i messaggi su più SQS server Amazon per motivi di ridondanza.
+ [SQSArchitettura Amazon di base](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ I microservizi, se ben utilizzati, migliorano la manutenibilità e aumentano la scalabilità, poiché i componenti ad accoppiamento debole sono gestiti da team indipendenti. Consentono inoltre l'isolamento dei comportamenti in un unico componente in caso di modifiche.
+ [Implementazione di microservizi su AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Let's Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Con AWS Step Functions puoi creare applicazioni distribuite, automatizzare i processi, orchestrare microservizi, tra le altre cose. L'orchestrazione di più componenti in un flusso di lavoro automatizzato consente di disaccoppiare le dipendenze nell'applicazione.
+ [Crea un flusso di lavoro serverless con e AWS Step FunctionsAWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [Guida introduttiva con AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Risorse
**Documenti correlati:**
+ [AmazonEC2: garantire l'idempotenza](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [What Is Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [Orchestra i microservizi basati sulle code con Amazon AWS Step Functions SQS](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [SQSArchitettura Amazon di base](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Queue-Based Architecture ](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Video correlati:**
+ [AWS New York Summit 2019: introduzione alle architetture basate sugli eventi e ad Amazon (05) EventBridge MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: Come prendere il controllo di sistemi, grandi e piccoli ARC337 (include accoppiamento libero, lavoro costante, stabilità statica)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Passaggio ad architetture basate sugli eventi (08) SVS3](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: applicazioni scalabili senza server basate su eventi con Amazon e Lambda SQS](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Progettazione di integrazioni basate sugli eventi con Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Approfondimento e best practice su Elastic Load Balancing](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Fai un lavoro costante
I sistemi possono presentare guasti quando si verificano modifiche rapide e di grandi dimensioni nel carico. Ad esempio, se il carico di lavoro effettua un controllo dell'integrità di migliaia di server deve inviare ogni volta lo stesso payload delle dimensioni (uno snapshot completo dello stato corrente). Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dell'integrità esegue un lavoro costante con modifiche rapide e di piccole dimensioni.
Ad esempio, se il sistema di controllo dell'integrità monitora 100.000 server, il carico su di esso è nominale al di sotto del tasso di errore normalmente basso del server. Tuttavia, se un evento importante rendesse la metà di questi server non integra, il sistema di controllo dell'integrità sarebbe sovraccarico nel tentativo di aggiornare i sistemi di notifica e comunicare lo stato con i client. Pertanto, il sistema di controllo dell'integrità dovrebbe inviare ogni volta lo snapshot completo dello stato attuale. 100.000 stati di integrità del server, ciascuno rappresentato da un bit, equivarrebbero a un payload di soli 12,5 KB. Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dell'integrità esegue un lavoro costante e le modifiche rapide e di grandi dimensioni non rappresentano una minaccia per la stabilità del sistema. Questo è in realtà il modo in cui Amazon Route 53 gestisce i controlli dell'integrità degli endpoint (come gli indirizzi IP) per stabilire come gli utenti finali vengono instradati verso di loro.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all'implementazione
+ Esegui un lavoro costante in modo che i sistemi non presentino guasti quando si verificano cambiamenti rapidi e significativi nel carico.
+ Implementazione di dipendenze con accoppiamento debole Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e bilanciatori del carico sono con accoppiamento debole. L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Chiudere i circuiti e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli (include un lavoro costante) ARC337](https://youtu.be/O8xLxNje30M?t=2482)
+ Per l'esempio di un sistema di controllo dell'integrità che monitora 100.000 server, progetta i carichi di lavoro in modo che le dimensioni dei payload rimangano costanti indipendentemente dal numero di successi o di fallimenti.
## Risorse
**Documenti correlati:**
+ [AmazonEC2: garantire l'idempotenza](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video correlati:**
+ [AWS New York Summit 2019: introduzione alle architetture basate sugli eventi e ad Amazon (05) EventBridge MAD2](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Chiudere i circuiti e aprire le menti: come assumere il controllo di sistemi, grandi e piccoli (include un lavoro costante) ARC337](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: Come prendere il controllo dei sistemi, grandi e piccoli ARC337 (include accoppiamento libero, lavoro costante, stabilità statica)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Passaggio ad architetture basate sugli eventi (08) SVS3](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Rendere idempotenti le operazioni di mutazione
Un servizio idempotente promette che ogni richiesta venga elaborata esattamente una volta, in modo che effettuare più richieste identiche abbia lo stesso effetto di una singola richiesta. Questo rende più facile per un client implementare i tentativi senza temere che una richiesta venga erroneamente elaborata più volte. A tal fine, i client possono inviare richieste API con un token di idempotenza, che viene utilizzato ogni volta che la richiesta viene ripetuta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata, anche se lo stato sottostante del sistema è cambiato.
In un sistema distribuito, è relativamente semplice eseguire un'azione al massimo una volta (il client effettua una sola richiesta) o almeno una volta (continuando a richiedere fino a quando il client non riceve una conferma di successo). È più difficile garantire che un'azione venga eseguita *esattamente una volta*, in modo che più richieste identiche abbiano lo stesso effetto di una singola richiesta. Utilizzando i token di idempotenza nelle API, i servizi possono ricevere una richiesta di mutazione una o più volte senza la necessità di creare record duplicati o effetti collaterali.
**Risultato desiderato:** hai un approccio coerente, ben documentato e ampiamente adottato per garantire l'idempotenza in tutti i componenti e servizi.
**Anti-pattern comuni:**
+ Applichi l'idempotenza indiscriminatamente, anche quando non è necessaria.
+ Introduci una logica troppo complessa per implementare l'idempotenza.
+ Utilizzi i timestamp come chiavi per l'idempotenza. Questo può causare imprecisioni a causa del disallineamento dell'orologio o a causa di più client che utilizzano gli stessi timestamp per applicare le modifiche.
+ Archivi interi payload per l'idempotenza. In questo approccio, salvi i payload completi dei dati per ogni richiesta e li sovrascrivi a ogni nuova richiesta. Questo può ridurre le prestazioni e influenzare la scalabilità.
+ Generi le chiavi in modo incoerente tra i vari servizi. Senza chiavi coerenti, i servizi potrebbero non riconoscere le richieste duplicate, con conseguenti risultati indesiderati.
**Vantaggi dell'adozione di questa best practice:**
+ Maggiore scalabilità: il sistema può gestire tentativi e richieste duplicate senza dover eseguire una logica aggiuntiva o una complessa gestione dello stato.
+ Maggiore affidabilità: l'idempotenza aiuta i servizi a gestire più richieste identiche in modo coerente, riducendo il rischio di effetti collaterali indesiderati o di record duplicati. Questo aspetto è particolarmente importante nei sistemi distribuiti, dove gli errori di rete e i tentativi sono frequenti.
+ Miglioramento della coerenza dei dati: poiché la stessa richiesta produce la stessa risposta, l'idempotenza aiuta a mantenere la coerenza dei dati nei sistemi distribuiti. Questo è essenziale per mantenere l'integrità delle transazioni e delle operazioni.
+ Gestione degli errori: i token di idempotenza rendono più semplice la gestione degli errori. Se un client non riceve una risposta a causa di un problema, può tranquillamente inviare nuovamente la richiesta con lo stesso token di idempotenza.
+ Trasparenza operativa: l'idempotenza consente di migliorare il monitoraggio e la registrazione. I servizi possono registrare le richieste con i propri token di idempotenza, il che facilita il monitoraggio e il debug dei problemi.
+ Contratto API semplificato: può semplificare il contratto tra i sistemi lato client e lato server e ridurre il timore di un'elaborazione errata dei dati.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
In un sistema distribuito, eseguire un'azione al massimo una volta (il client effettua una sola richiesta) o almeno una volta (il client continua a richiedere finché non viene confermato l'esito positivo) è relativamente semplice. Tuttavia, è difficile implementare *esattamente una volta* il comportamento. A tal fine, i client devono generare e fornire un token di idempotenza per ogni richiesta.
Utilizzando i token di idempotenza, un servizio può distinguere tra nuove richieste e richieste ripetute. Quando un servizio riceve una richiesta con un token di idempotenza, controlla se il token è già stato utilizzato. Se il token è stato utilizzato, il servizio recupera e restituisce la risposta memorizzata. Se il token è nuovo, il servizio elabora la richiesta, memorizza la risposta insieme al token e restituisce la risposta. Questo meccanismo rende tutte le risposte idempotenti, migliorando l'affidabilità e la coerenza del sistema distribuito.
Anche l'idempotenza è un comportamento importante delle architetture basate su eventi. Queste architetture sono in genere supportate da una coda di messaggi come Amazon SQS, Amazon MQ, Amazon Kinesis Streams o Amazon Managed Streaming per Apache Kafka (MSK). In alcune circostanze, un messaggio pubblicato una sola volta può essere accidentalmente recapitato più di una volta. Quando un publisher genera e include i token di idempotenza nei messaggi, richiede che l'elaborazione di qualsiasi messaggio duplicato ricevuto non comporti un'azione ripetuta per lo stesso messaggio. I consumatori devono tenere traccia di ogni token ricevuto e ignorare i messaggi che contengono token duplicati.
I servizi e i consumatori devono anche passare il token di idempotenza ricevuto a tutti i servizi a valle che vengono chiamati. Ogni servizio a valle della catena di elaborazione ha la stessa responsabilità di assicurarsi che l'idempotenza sia implementata per evitare l'effetto collaterale di elaborare un messaggio più di una volta.
### Passaggi dell'implementazione
1. **Identifica le operazioni idempotenti**
Determina quali operazioni richiedono idempotenza. Questi includono in genere i metodi HTTP POST, PUT e DELETE e le operazioni di inserimento, aggiornamento o eliminazione del database. Le operazioni che non mutano lo stato, come le query di sola lettura, di solito non richiedono idempotenza, a meno che non abbiano effetti collaterali.
1. **Utilizza identificatori univoci**
Includi un token univoco in ogni richiesta di operazione idempotente inviata dal mittente, direttamente nella richiesta o come parte dei relativi metadati (ad esempio, un'intestazione HTTP). Ciò consente al destinatario di riconoscere e gestire richieste o operazioni duplicate. Gli identificatori comunemente usati per i token includono [Universally Unique Identifier (UUID)](https://datatracker.ietf.org/doc/html/rfc9562) e [K-Sortable Unique Identifier (KSUID)](https://github.com/segmentio/ksuid).
1. **Monitora e gestisci lo stato**
Mantieni lo stato di ogni operazione o richiesta nel carico di lavoro. Ciò può essere ottenuto memorizzando il token di idempotenza e lo stato corrispondente (come in attesa, completato o non riuscito) in un database, una cache o un altro archivio persistente. Queste informazioni sullo stato consentono al carico di lavoro di identificare e gestire richieste o operazioni duplicate.
Mantieni la coerenza e l'atomicità utilizzando, se necessario, meccanismi di controllo della simultaneità appropriati, come blocchi, transazioni o controlli ottimistici della simultaneità. Questo include il processo di registrazione del token idempotente e l'esecuzione di tutte le operazioni di mutazione associate al servizio della richiesta. Questo aiuta a prevenire le condizioni di gara e verifica che le operazioni idempotenti vengano eseguite correttamente.
Rimuovi periodicamente i vecchi token di idempotenza dal datastore per gestire l'archiviazione e le prestazioni. Se il sistema di archiviazione lo supporta, prendi in considerazione l'utilizzo di timestamp di scadenza per i dati (spesso noti come valori di time-to-live, o TTL). La probabilità di riutilizzo dei token di idempotenza diminuisce nel tempo.
Le comuni opzioni di archiviazione AWS genericamente utilizzate per memorizzare i token di idempotenza e il relativo stato includono:
+ **Amazon DynamoDB**: DynamoDB è un servizio di database NoSQL che offre prestazioni a bassa latenza ed elevata disponibilità, il che lo rende adatto all'archiviazione di dati correlati all'idempotenza. Il modello di dati chiave-valore e documento di DynamoDB consente di memorizzare e recuperare in modo efficiente i token di idempotenza e le informazioni di stato associate. DynamoDB può anche far scadere automaticamente i token di idempotenza se l'applicazione imposta un valore TTL al momento dell'inserimento.
+ **Amazon ElastiCache**: ElastiCache è in grado di archiviare token di idempotenza con un elevato throughput, bassa latenza e a costo ridotto. ElastiCache (Redis) e ElastiCache (Memcached) possono entrambi far scadere automaticamente i token di idempotenza se l'applicazione imposta un valore TTL al momento dell'inserimento.
+ **Amazon Relational Database Service (RDS):** puoi utilizzare Amazon RDS per archiviare i token di idempotenza e le informazioni di stato correlate, soprattutto se l'applicazione utilizza già un database relazionale per altri scopi.
+ **Amazon Simple Storage Service (S3):** Amazon S3 è un servizio di archiviazione di oggetti altamente scalabile e durevole che può essere utilizzato per archiviare i token di idempotenza e i metadati correlati. Le funzionalità di controllo delle versioni di S3 possono essere particolarmente utili per il mantenimento dello stato di operazioni idempotenti. La scelta del servizio di archiviazione dipende in genere da fattori quali il volume dei dati correlati all'idempotenza, le caratteristiche di prestazione richieste, l'esigenza di durabilità e disponibilità e il modo in cui il meccanismo di idempotenza si integra con l'architettura complessiva del carico di lavoro.
1. **Implementa operazioni idempotenti**
Progetta l'API e i componenti del carico di lavoro in modo che siano idempotenti. Incorpora i controlli di idempotenza nei componenti del carico di lavoro. Prima di elaborare una richiesta o eseguire un'operazione, controlla se l'identificatore univoco è già stato elaborato. In caso affermativo, restituisci il risultato precedente invece di eseguire nuovamente l'operazione. Ad esempio, se un client invia una richiesta per creare un utente, verifica se esiste già un utente con lo stesso identificatore univoco. Se l'utente esiste, deve restituire le informazioni utente esistenti anziché crearne una nuovo. Allo stesso modo, se un consumatore di code riceve un messaggio con un token di idempotenza duplicato, deve ignorare il messaggio.
Crea suite di test complete che convalidino l'idempotenza delle richieste. Devono coprire un'ampia gamma di scenari, come richieste andate a buon fine, richieste non riuscite e richieste duplicate.
Se il carico di lavoro sfrutta le funzioni AWS Lambda, prendi in considerazione Powertools per AWS Lambda. Powertools per AWS Lambda è un kit di strumenti per sviluppatori che aiuta a implementare le best practice serverless e ad aumentare la velocità di sviluppo quando si lavora con le funzioni AWS Lambda Lambda. In particolare, fornisce un'utilità per convertire le funzioni Lambda in operazioni idempotenti, sicure per riprovare.
1. **Comunica chiaramente l'idempotenza**
Documenta l'API e i componenti del carico di lavoro per comunicare chiaramente la natura idempotente delle operazioni. Questo aiuta i clienti a comprendere il comportamento previsto e a capire come interagire con il carico di lavoro in modo affidabile.
1. **Monitora ed esegui audit**
Implementa meccanismi di monitoraggio e audit per rilevare eventuali problemi correlati all'idempotenza delle risposte, come variazioni impreviste delle risposte o gestione eccessiva di richieste duplicate. Questo può aiutare a rilevare e indagare su eventuali problemi o comportamenti imprevisti nel carico di lavoro.
## Risorse
**Best practice correlate:**
+ [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+ [REL06-BP01 Monitoraggio di tutti i componenti per il carico di lavoro (generazione)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Invio di notifiche (elaborazione e avvisi in tempo reale)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL08-BP02 Esecuzione di test funzionali come parte integrante dell'implementazione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_functional_testing.html)
**Documenti correlati:**
+ [The Amazon Builders' Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
+ [The Amazon Builders' Library: difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon Elastic Container Service: Ensuring idempotency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)
+ [Come faccio a rendere idempotente la mia funzione Lambda?](https://repost.aws/knowledge-center/lambda-function-idempotent)
+ [Garantire l'idempotenza nelle richieste Amazon EC2 API](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)
**Video correlati:**
+ [Building Distributed Applications with Event-driven Architecture - AWS Online Tech Talks](https://www.youtube.com/watch?v=gA2-eqDVSng&t=1668s)
+ [AWS re:Invent 2023 - Building next-generation applications with event-driven architecture](https://www.youtube.com/watch?v=KXR17uwLEC8)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [AWS re:Invent 2018 - Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 - Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
**Strumenti correlati:**
+ [Idempotenza con AWS Lambda Powertools (Java)](https://docs.powertools.aws.dev/lambda/java/utilities/idempotency/)
+ [Idempotenza con AWS Lambda Powertools (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
+ [Pagina GitHub AWS Lambda Powertools](https://github.com/aws-powertools/)
# Progettazione di interazioni in un sistema distribuito per mitigare o affrontare gli errori
I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati su queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice consentono ai carichi di lavoro di tollerare le sollecitazioni o i guasti, recuperare più rapidamente e mitigare l'impatto di tali problemi. Il risultato è un miglioramento del tempo medio di ripristino (MTTR).
Queste best practice consentono di prevenire gli errori e migliorare il tempo medio tra guasti (MTBF).
**Topics**
+ [REL05-BP01 Implementazione della normale riduzione delle prestazioni per trasformare le dipendenze forti applicabili in dipendenze deboli](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlla e limita le chiamate di nuovo tentativo](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Anticipare l’errore (fail fast) e limitare le code](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Imposta i timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendere i sistemi senza stato ove possibile](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementare leve di emergenza](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementazione della normale riduzione delle prestazioni per trasformare le dipendenze forti applicabili in dipendenze deboli
I componenti dell'applicazione devono continuare a svolgere la loro funzione principale anche se le dipendenze non sono disponibili. Potrebbero fornire dati leggermente obsoleti, dati alternativi o addirittura nessun dato. Ciò garantisce che la funzionalità complessiva del sistema sia ostacolata solo in minima parte da errori localizzati, garantendo al contempo il valore aziendale intrinseco.
**Risultato desiderato:** quando le dipendenze di un componente non sono integre, il componente stesso può comunque funzionare, anche se in modo degradato. Le modalità di errore dei componenti devono essere considerate come funzionamenti normali. I flussi di lavoro devono essere progettati in modo tale che questi errori non conducano a un fallimento completo o almeno a stati prevedibili e recuperabili.
**Anti-pattern comuni:**
+ Mancata identificazione della funzionalità aziendale di base necessaria. Mancata verifica del funzionamento dei componenti anche in caso di errori di dipendenza.
+ Mancata restituzione di dati sugli errori o quando solo una delle dipendenze non è disponibile e possono comunque essere restituiti risultati parziali.
+ Creazione di uno stato incoerente quando una transazione non va a buon fine parzialmente.
+ Mancata disponibilità di alternative per accedere a un archivio di parametri centralizzato.
+ Invalidare o svuotare lo stato locale a seguito di un aggiornamento non riuscito senza considerare le conseguenze di tale operazione.
**Vantaggi dell'adozione di questa best practice:** la normale riduzione delle prestazioni migliora la disponibilità del sistema nel suo complesso e conserva la funzionalità delle funzioni più importanti anche in caso di errori.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
L'implementazione di una normale riduzione delle prestazioni aiuta a ridurre al minimo l'impatto degli errori di dipendenza sul funzionamento dei componenti. Idealmente, un componente rileva gli errori nelle dipendenze e trova soluzioni alternative in modo da avere un impatto minimo sugli altri componenti o clienti.
Progettare per una normale riduzione delle prestazioni significa considerare le potenziali modalità di errore durante la progettazione delle dipendenze. Per ogni modalità di errore, disponi di un modo per fornire la maggior parte delle funzionalità o almeno quelle più critiche del componente a chiamanti o clienti. Queste considerazioni possono diventare requisiti aggiuntivi testabili e verificabili. Idealmente, un componente è in grado di svolgere la sua funzione principale in modo accettabile anche in caso di errore di una o più dipendenze.
Questa è una discussione di carattere tanto commerciale quanto tecnico. Tutti i requisiti aziendali sono importanti e devono essere soddisfatti, se possibile. Tuttavia, ha ancora senso chiedersi cosa dovrebbe succedere quando non tutti i requisiti possono essere soddisfatti. Un sistema può essere progettato per essere disponibile e coerente, ma nelle circostanze in cui è necessario eliminare un requisito, qual è quello più importante? Per l'elaborazione dei pagamenti, potrebbe essere la coerenza. Per un'applicazione in tempo reale, potrebbe essere la disponibilità. Per un sito Web rivolto ai clienti, la risposta può dipendere dalle aspettative dei clienti.
Il significato di ciò dipende dai requisiti del componente e da ciò che dovrebbe essere considerato la sua funzione principale. Esempio:
+ Un sito di e-commerce potrebbe visualizzare dati provenienti da più sistemi diversi, come consigli personalizzati, prodotti con il punteggio più alto e lo stato degli ordini dei clienti sulla pagina di destinazione. Quando in un sistema upstream si verifica un errore, ha comunque senso mostrare tutto il resto, invece di mostrare una pagina di errore a un cliente.
+ Un componente che esegue la scrittura in batch può continuare a elaborare un batch se una delle singole operazioni fallisce. Dovrebbe essere semplice implementare un meccanismo di ripetizione dei tentativi. A tale scopo, è sufficiente restituire al chiamante informazioni su quali operazioni hanno avuto successo, quali e perché non sono riuscite, oppure inserendo le richieste non riuscite in una coda DLQ per implementare nuovi tentativi asincroni. Anche le informazioni sulle operazioni non riuscite devono essere registrate.
+ Un sistema che elabora le transazioni deve verificare che vengano eseguiti tutti gli aggiornamenti o nessun aggiornamento. Per le transazioni distribuite, il modello Saga può essere utilizzato per ripristinare le operazioni precedenti nel caso in cui fallisca un'operazione successiva della stessa transazione. Qui, la funzione principale è mantenere la coerenza.
+ I sistemi critici dal punto di vista temporale dovrebbero essere in grado di gestire le dipendenze che non rispondono in modo tempestivo. In questi casi, è possibile utilizzare lo schema dell'interruttore. Quando inizia a verificarsi il timeout delle risposte di una dipendenza, il sistema può passare a uno stato chiuso in cui non vengono effettuate chiamate aggiuntive.
+ Un'applicazione può leggere i parametri da un archivio di parametri. Può essere utile creare immagini di container con un set di parametri predefinito e utilizzarli nel caso in cui l'archivio dei parametri non sia disponibile.
Si noti che i percorsi seguiti in caso di errore dei componenti devono essere testati e devono essere significativamente più semplici del percorso primario. In genere, [è consigliabile evitare strategie di fallback](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Passaggi dell'implementazione
Identifica le dipendenze esterne e interne. Considera i tipi di errore che si possono verificare nelle dipendenze. Considera i modi per ridurre al minimo l'impatto negativo sui sistemi upstream e downstream e sui clienti durante questi errori.
Di seguito è riportato un elenco di dipendenze e di come ridurre normalmente le prestazioni quando si verifica un errore a livello di dipendenze:
1. **Errore parziale delle dipendenze:** un componente può effettuare più richieste ai sistemi downstream, sia come richieste multiple a un sistema sia come richiesta a più sistemi. A seconda del contesto aziendale, possono essere appropriate diverse modalità di gestione (per maggiori dettagli, consulta gli esempi precedenti nella Guida all'implementazione).
1. **Un sistema downstream non è in grado di elaborare le richieste a causa del carico elevato:** se le richieste rivolte a un sistema downstream non vanno costantemente a buon fine, non ha senso continuare a riprovare. Ciò può creare un carico aggiuntivo su un sistema già sovraccarico e rendere più difficile il ripristino. Qui è possibile utilizzare lo schema dell'interruttore, che monitora le chiamate non riuscite a un sistema downstream. Se un numero elevato di chiamate ha esito negativo, interromperà l'invio di altre richieste al sistema downstream e solo occasionalmente lascerà passare le chiamate per verificare se il sistema downstream è nuovamente disponibile.
1. **Un archivio di parametri non è disponibile:** per trasformare un archivio di parametri, è possibile utilizzare la cache delle dipendenze a protezione debole o i valori predefiniti integri inclusi nelle immagini del container o del computer. Tieni presente che queste impostazioni predefinite devono essere costantemente aggiornate e incluse nelle suite di test.
1. **Un servizio di monitoraggio o altra dipendenza non funzionale non è disponibile:** se un componente non è in grado di inviare a intermittenza log, metriche o tracce a un servizio di monitoraggio centralizzato, spesso è meglio continuare a eseguire le funzioni aziendali come al solito. Non registrare o eseguire il push delle metriche in modo invisibile all'utente per un lungo periodo di tempo spesso non è una procedura accettabile. Inoltre, in alcuni casi d'uso potrebbero essere necessari dati di controllo completi per soddisfare i requisiti di conformità.
1. **Un'istanza primaria di un database relazionale potrebbe non essere disponibile:** come quasi tutti i database relazionali, Amazon Relational Database Service può presentare solo un'istanza di scrittura primaria. Questo crea un unico punto di errore per i carichi di lavoro di scrittura e rende più difficile il dimensionamento. Questo problema può essere parzialmente mitigato utilizzando una configurazione Multi-AZ per una disponibilità elevata o Amazon Aurora Serverless per un migliore dimensionamento. Per requisiti di disponibilità molto elevati, può essere logico non fare affatto affidamento sull'istanza di scrittura primaria. Per le query che si limitano a leggere, è possibile utilizzare repliche di lettura, che forniscono ridondanza e la possibilità di aumentare orizzontalmente e anche verticalmente. Le operazioni di scrittura possono essere memorizzate nel buffer, ad esempio in una coda Amazon Simple Queue Service, in modo che le richieste di scrittura dei clienti possano comunque essere accettate anche se l'istanza primaria non è temporaneamente disponibile.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (riepilogo dell'interruttore dal libro "Release It\$1")](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard "Release It\$1 Design and Deploy Production-Ready Software](https://pragprog.com/titles/mnee2/release-it-second-edition/)"
+ [The Amazon Builders' Library: evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)
Usa le richieste di limitazione (della larghezza di banda della rete) per mitigare l'esaurimento delle risorse dovuto ad aumenti imprevisti della domanda. Le richieste inferiori alla percentuale di limitazione (della larghezza di banda della rete) vengono elaborate, mentre quelle che superano il limite definito vengono rifiutate con un messaggio che indica che la richiesta è stata limitata.
**Risultato desiderato:** i picchi di volume di grandi dimensioni dovuti a improvvisi aumenti del traffico dei clienti, attacchi di flooding o tempeste di ripetizioni dei tentativi sono mitigati dalla limitazione (della larghezza di banda della rete) delle richieste, che consente ai carichi di lavoro di continuare la normale elaborazione del volume di richieste supportato.
**Anti-pattern comuni:**
+ Le limitazioni (della larghezza di banda della rete) degli endpoint API non sono implementate o vengono implementate in base ai valori predefiniti senza considerare i volumi previsti.
+ Gli endpoint delle API non sono sottoposti a test di carico né i limiti relativi alla limitazione (della larghezza di banda della rete) vengono testati.
+ Limitazione (della larghezza di banda della rete) dei tassi di richiesta senza considerare le dimensioni o la complessità delle richieste.
+ Verifica delle percentuali massime di richieste o delle dimensioni massime delle richieste, senza però testarle congiuntamente.
+ Le risorse non vengono allocate entro gli stessi limiti stabiliti durante i test.
+ I piani di utilizzo non sono stati configurati o considerati per gli utenti di API Application to Application (A2A).
+ Gli utenti di code con scalabilità orizzontale non hanno configurato le impostazioni di simultaneità massima.
+ La limitazione della velocità per indirizzo IP non è stata implementata.
**Vantaggi dell'adozione di questa best practice:** i carichi di lavoro che stabiliscono limiti di accelerazione sono in grado di funzionare normalmente ed elaborare correttamente il caricamento delle richieste accettate in presenza di picchi di volume imprevisti. I picchi improvvisi o prolungati di richieste alle API e alle code vengono applicate limitazioni (della larghezza di banda della rete) e non esauriscono le risorse di elaborazione delle richieste. La limitazione (della larghezza di banda della rete) limita i singoli richiedenti in modo che gli alti volumi di traffico provenienti da un singolo indirizzo IP o da un consumatore di API non esauriscano le risorse che impattano sugli altri consumatori.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
I servizi devono essere progettati per elaborare una capacità nota di richieste; tale capacità può essere stabilita mediante test di carico. Se le percentuali di arrivo delle richieste superano i limiti, la risposta appropriata segnala che una richiesta ha subito la limitazione (della larghezza di banda della rete). Ciò consente all'utente di gestire l'errore e riprovare in un secondo momento.
Quando il servizio richiede un'implementazione della limitazione (della larghezza di banda della rete), prendi in considerazione l'implementazione dell'algoritmo token bucket, in cui un token conta come una richiesta. I token vengono alimentati a una specifica velocità di limitazione (della larghezza di banda della rete) al secondo e svuotati in modo asincrono in base a un token per richiesta.
![\[Diagramma che descrive l'algoritmo token bucket.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Gateway Amazon API](https://aws.amazon.com/api-gateway/) implementa l'algoritmo token bucket in base ai limiti dell'account e della regione e può essere configurato per cliente con piani di utilizzo. Inoltre, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) e [Amazon Kinesis](https://aws.amazon.com/kinesis/) possono memorizzare in buffer le richieste in modo da ridurre la frequenza delle richieste e consentire percentuali di limitazione (della larghezza di banda della rete) più elevate per le richieste che è possibile soddisfare. Infine, puoi implementare limitazioni della velocità con [AWS WAF](https://aws.amazon.com/waf/) per la limitazione (della larghezza di banda della rete) di specifici utenti di API che generano un carico insolitamente elevato.
## Passaggi dell'implementazione
Puoi configurare API Gateway con limiti relativi alla limitazione (della larghezza di banda della rete) per le tue API e restituire errori `429 Too Many Requests` in caso di superamento dei limiti. Puoi utilizzare AWS WAF con gli endpoint AWS AppSync e API Gateway per abilitare la limitazione della velocità per indirizzo IP. Inoltre, laddove il sistema può tollerare l'elaborazione asincrona, è possibile inserire i messaggi in una coda o in un flusso per velocizzare le risposte ai client del servizio, il che consente di aumentare i tassi di limitazione (della larghezza di banda della rete).
Grazie all'elaborazione asincrona, dopo aver configurato Amazon SQS come origine di eventi per AWS Lambda, puoi [configurare la simultaneità massima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) per evitare che percentuali elevate di eventi consumino la quota di esecuzione simultanea disponibile dell'account necessaria ad altri servizi nel carico di lavoro o nell'account.
Sebbene API Gateway fornisca un'implementazione gestita dell'algoritmo token bucket, nei casi in cui non sia possibile utilizzare API Gateway, puoi sfruttare le implementazioni open source specifiche del linguaggio (consulta gli esempi correlati nella sezione Risorse) dell'algoritmo token bucket per i tuoi servizi.
+ Analizza e configura i [limiti relativi alla limitazione (della larghezza di banda della rete) di API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) a livello di account per regione, API per fase e chiave API per livelli del piano di utilizzo.
+ Applica [regole di limitazione della velocità AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) all'API Gateway e agli endpoint AWS AppSync per proteggerti dagli attacchi flood e bloccare gli IP dannosi. Le regole di limitazione (della larghezza di banda della rete) possono anche essere configurate su chiavi API AWS AppSync per gli utenti A2A.
+ Valuta se ti occorre un controllo maggiore sulla limitazione (della larghezza di banda della rete) rispetto al controllo sulla limitazione della velocità per le API AWS AppSync. In tal caso, configura un'API Gateway prima dell'endpoint AWS AppSync.
+ Se le code Amazon SQS sono configurate come trigger per gli utenti delle code Lambda, imposta la [simultaneità massima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) su un valore che garantisca un'elaborazione sufficiente da soddisfare i tuoi obiettivi di livello di servizio, senza consumare limiti di simultaneità che influiscono su altre funzioni Lambda. Valuta la possibilità di impostare la simultaneità riservata su altre funzioni Lambda nello stesso account e nella stessa regione quando utilizzi le code con Lambda.
+ Utilizza API Gateway con integrazioni di servizi native per Amazon SQS o Kinesis per memorizzare le richieste nel buffer.
+ Se non puoi utilizzare API Gateway, consulta le librerie specifiche della lingua per implementare l'algoritmo token bucket per il tuo carico di lavoro. Controlla la sezione degli esempi e cerca una libreria adatta.
+ Verifica i limiti che intendi impostare o che prevedi di incrementare e documenta i limiti testati.
+ Non aumentare i limiti oltre i valori stabiliti durante i test. Quando si aumenta un limite, verifica che le risorse allocate siano equivalenti o superiori a quelle degli scenari di test prima di applicare l'aumento.
## Risorse
**Best practice correlate:**
+ [REL04-BP03 Fai un lavoro costante](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Controlla e limita le chiamate di nuovo tentativo](rel_mitigate_interaction_failure_limit_retries.md)
**Documenti correlati:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF: Rate-based rule statement ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introducing maximum concurrency of AWS Lambda when using Amazon SQS as an event source ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: Maximum Concurrency ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Esempi correlati:**
+ [ The three most important AWS WAF rate-based rules ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Algoritmo token bucket per Python ](https://pypi.org/project/token-bucket/)
+ [ Algoritmo token bucket a livello di nodo ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitazione della velocità di threading del sistema .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Video correlati:**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Strumenti correlati:**
+ [ Gateway Amazon API ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [ Sala d'attesa virtuale su AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# REL05-BP03 Controlla e limita le chiamate di nuovo tentativo
Utilizza il backoff esponenziale per rieseguire le richieste a intervalli progressivamente più lunghi tra i singoli nuovi tentativi. Introduci il jitter tra i tentativi per la randomizzazione degli intervalli di ripetizione. Limita il numero massimo di tentativi.
**Risultato desiderato:** i componenti tipici di un sistema software distribuito includono server, sistemi di bilanciamento del carico, database e server. DNS Durante il normale funzionamento, questi componenti possono rispondere alle richieste con errori temporanei o limitati e anche errori che sarebbero persistenti indipendentemente dai nuovi tentativi. Quando i client effettuano richieste ai servizi, le richieste consumano risorse tra cui memoria, thread, connessioni, porte o altre risorse limitate. Controllare e limitare i nuovi tentativi è una strategia per liberare risorse e ridurne al minimo il consumo in modo che i componenti del sistema sottoposti a stress non vengano sovraccaricati.
Quando vanno in timeout o ricevono risposte di errore, le richieste client devono decidere se eseguire o meno nuovi tentativi. Se vengono eseguiti nuovi tentativi, questi verranno eseguiti con un backoff esponenziale con jitter e un numero massimo di tentativi. Di conseguenza, i servizi e i processi backend riducono il carico e i tempi di riparazione automatica, con un conseguente ripristino più rapido e una corretta gestione delle richieste.
**Anti-pattern comuni:**
+ Implementazione di nuovi tentativi senza aggiungere il backoff esponenziale, il jitter e il numero massimo di tentativi. Il backoff e il jitter aiutano a evitare picchi di traffico artificiali dovuti a tentativi involontariamente coordinati a intervalli standard.
+ Implementazione di nuovi tentativi senza testarne gli effetti o presupponendo che i nuovi tentativi siano già integrati in scenari di ripetizione e senza test. SDK
+ La mancata comprensione dei codici di errore pubblicati nelle dipendenze porta a ritentare tutti gli errori, compresi quelli la cui causa è chiara e indica la mancanza di autorizzazione, un errore di configurazione o un'altra condizione che prevedibilmente non si risolverà senza un intervento manuale.
+ Mancata gestione delle best practice di osservabilità, compresi il monitoraggio e la segnalazione di ripetuti guasti del servizio, in modo che i problemi sottostanti siano resi noti e possano essere risolti.
+ Sviluppo di meccanismi di ripetizione personalizzati quando le funzionalità di ripetizione dei tentativi integrate o di terze parti sono sufficienti.
+ Riprovare su più livelli dello stack di applicazioni in modo da accrescere in modo significativo i nuovi tentativi e pertanto da consumare ulteriormente le risorse in una tempesta di ripetizioni dei tentativi. Assicurati di comprendere in che modo questi errori influiscono sulla tua applicazione e sulle dipendenze su cui fai affidamento, quindi implementa i nuovi tentativi a un solo livello.
+ Riesecuzione delle chiamate dei servizi non idempotenti, con effetti collaterali imprevisti come risultati duplicati.
**Vantaggi dell'adozione di questa best practice:** i nuovi tentativi aiutano i client a ottenere i risultati desiderati quando le richieste non vanno a buon fine, ma consumano più tempo del server per ottenere le risposte corrette desiderate. Quando gli errori sono rari o transitori, i nuovi tentativi funzionano correttamente. Quando gli errori sono causati da un sovraccarico di risorse, i nuovi tentativi possono peggiorare le cose. L'aggiunta di un backoff esponenziale con jitter ai tentativi dei client consente ai server di recuperare risorse quando gli errori sono causati dal sovraccarico delle risorse. Il jitter evita l'allineamento delle richieste in picchi e il backoff riduce l'aumento del carico causato dall'aggiunta di nuovi tentativi al normale carico delle richieste. Infine, è importante configurare un numero massimo di tentativi o il tempo trascorso per evitare la creazione di backlog che producono errori metastabili.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Controlla e limita le chiamate riproposte. Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per la randomizzazione degli intervalli di ripetizione e limitare il numero massimo di tentativi.
Per impostazione predefinita, alcuni AWS SDKs implementano nuovi tentativi e il backoff esponenziale. Utilizza queste AWS implementazioni integrate laddove applicabile nel tuo carico di lavoro. Implementa una logica simile nel tuo carico di lavoro nelle chiamate di servizi idempotenti e i cui tentativi migliorano la disponibilità dei client. Potrai decidere quali sono i timeout e quando cessare i tentativi in base al tuo caso d'uso. Crea ed esegui scenari di test per quei casi d'uso relativi ai nuovi tentativi.
## Passaggi dell'implementazione
+ Determina il livello ottimale nello stack di applicazioni per implementare nuovi tentativi per i servizi su cui si basa l'applicazione.
+ Sii consapevole delle strategie esistenti SDKs che implementano strategie di ripetizione comprovate con backoff e jitter esponenziali per il linguaggio che preferisci, e preferiscile alla stesura di implementazioni personalizzate con nuovi tentativi.
+ Verifica che i [servizi siano caratterizzati dall'idempotenza](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) prima dell'implementazione di nuovi tentativi. Una volta implementati i nuovi tentativi, assicurati che siano testati e che vengano regolarmente eseguiti in produzione.
+ Quando chiami il AWS servizioAPIs, usa [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)and e [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)comprendi le opzioni di configurazione Retry. Determina se le impostazioni predefinite sono adatte al tuo caso d'uso, esegui i test e regola i valori secondo necessità.
## Risorse
**Best practice correlate:**
+ [REL04-BP04 Rendere idempotenti le operazioni di mutazione](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Anticipare l’errore (fail fast) e limitare le code](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Imposta i timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md)
**Documenti correlati:**
+ [Errore, tentativi e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Exponential Backoff and Jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [Rendere sicuri i nuovi tentativi con idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Esempi correlati:**
+ [ Spring Retry ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j Retry ](https://resilience4j.readme.io/docs/retry)
**Video correlati:**
+ [Riprova, backoff e jitter: AWS re:Invent 2019: Presentazione di The Amazon Builders' Library () DOP328](https://youtu.be/sKRdemSirDM?t=1884)
**Strumenti correlati:**
+ [AWS SDKsStrumenti e strumenti: Riprova il comportamento](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: AWS CLI riprova](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Anticipare l’errore (fail fast) e limitare le code
Se un servizio non è in grado di rispondere correttamente a una richiesta, procede ad anticipare l’errore (fail fast). Ciò consente il rilascio delle risorse associate a una richiesta e permette al servizio di recuperare le risorse se queste sono in esaurimento. L’anticipazione degli errori (fail fast) è un modello di progettazione software consolidato che può essere usato per creare carichi di lavoro altamente affidabili nel cloud. Anche l’accodamento è un modello di integrazione aziendale consolidato che può semplificare il carico e consentire ai client di rilasciare risorse quando l’elaborazione asincrona può essere tollerata. Quando un servizio è in grado di rispondere correttamente in condizioni normali ma restituisce un esito negativo quando la frequenza delle richieste è troppo alta, utilizza una coda per memorizzare le richieste nel buffer. Tuttavia, non consentire la creazione di backlog di code lunghe che possono comportare l’elaborazione di richieste obsolete già dismesse dal client.
**Risultato desiderato:** quando i sistemi rilevano conflitti a livello di risorse, timeout, eccezioni o errori che rendono irraggiungibili gli obiettivi dei livelli di servizio, le strategie volte ad anticipare l’errore (fail fast) consentono un ripristino più rapido del sistema. I sistemi che devono assorbire i picchi di traffico e sono in grado di gestire l’elaborazione asincrona possono migliorare l’affidabilità consentendo ai client di rilasciare rapidamente le richieste utilizzando le code per archiviare le richieste nei servizi di backend. Quando le richieste vengono memorizzate nei buffer delle code, vengono implementate strategie di gestione delle code per evitare backlog ingestibili.
**Anti-pattern comuni:**
+ Implementazione delle code di messaggi senza la configurazione delle code DLQ o degli allarmi nei volumi DLQ per rilevare quando un sistema è in errore.
+ Mancata misurazione dell’età dei messaggi in una coda, misurazione della latenza per capire quando gli utenti della coda sono in ritardo o generano errori che causano un nuovo tentativo.
+ Mancata cancellazione dei messaggi nel backlog da una coda quando non è più necessario elaborare questi messaggi se l’azienda non lo richiede più.
+ La configurazione delle code First in First Out (FIFO) quando le code Last In First Out (LIFO) soddisferebbe meglio le esigenze dei client, ad esempio quando non sono richiesti ordini rigorosi e l’elaborazione dei backlog sta ritardando tutte le richieste nuove e urgenti, con conseguente violazione dei livelli di servizio per tutti i client.
+ Esposizione delle code interne ai client, invece dell’esposizione delle API che gestiscono l’acquisizione del lavoro e l’inserimento delle richieste in code interne.
+ Combinazione di un numero eccessivo di tipi di richieste di lavoro in un’unica coda: ciò può aggravare le condizioni dei backlog in seguito alla distribuzione delle richieste di risorse tra i tipi di richiesta.
+ Elaborazione di richieste complesse e semplici nella stessa coda, nonostante siano necessari monitoraggio, timeout e allocazioni di risorse diversi.
+ Mancata convalida degli input o utilizzo di asserzioni per implementare meccanismi in grado di anticipare l’errore (fail fast) nel software che generano eccezioni a componenti di livello superiore in grado di gestire normalmente gli errori.
+ Mancata rimozione delle risorse in errore dall’instradamento delle richieste, soprattutto quando gli errori generano risultati sia positivi che negativi dovuti ad arresti anomali e riavvii, errori intermittenti a livello di dipendenze, capacità ridotta o perdita di pacchetti di rete.
**Vantaggi dell’adozione di questa best practice:** i sistemi in grado di anticipare l’errore (fail fast) sono più facili da sottoporre al debug e alla correzione degli errori e spesso presentano problemi di codifica e configurazione prima che le versioni vengano pubblicate in produzione. I sistemi che incorporano strategie di accodamento efficaci forniscono maggiore resilienza e affidabilità in caso di picchi di traffico e di condizioni intermittenti di errore del sistema.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Le strategie volte ad anticipare l’errore (fail fast) possono essere codificate in soluzioni software e configurate nell’infrastruttura. Oltre ad anticipare l’errore (fail fast), le code sono una tecnica semplice ma affidabile di definizione dell’architettura che consente il caricamento senza problemi di componenti disaccoppiati del sistema. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) fornisce funzionalità per il monitoraggio e la segnalazione di guasti. Una volta accertato il malfunzionamento di un sistema, è possibile richiamare strategie di mitigazione, ad esempio per evitare problemi dovuti a risorse danneggiate. Se i sistemi implementano code con [Amazon SQS](https://aws.amazon.com/sqs/) e altre tecnologie di accodamento, per semplificare il caricamento, devono valutare come gestire i backlog e gli errori di utilizzo dei messaggi.
## Passaggi dell’implementazione
+ Implementa asserzioni programmatiche o metriche specifiche nel tuo software e usale per ricevere avvisi espliciti in caso di problemi di sistema. Con Amazon CloudWatch puoi creare metriche e allarmi basati sul modello di log delle applicazioni e sulla strumentazione SDK.
+ Usa le metriche CloudWatch e gli allarmi per eseguire il failover per le risorse danneggiate responsabili dell’incremento della latenza dell’elaborazione o che ripetutamente non riescono a elaborare le richieste.
+ Utilizza l’elaborazione asincrona. A tale scopo, progetta API in grado di accettare le richieste e aggiungere richieste alle code interne mediante Amazon SQS e, quindi, rispondere al client che genera il messaggio con un messaggio di successo, in modo che il client possa rilasciare risorse e passare ad altre attività mentre gli utenti nella coda di backend elaborano le richieste.
+ Misura e monitora la latenza di elaborazione delle code generando una metrica CloudWatch ogni volta che escludi un messaggio da una coda confrontandolo con il timestamp del messaggio.
+ Quando gli errori impediscono la corretta elaborazione dei messaggi o il traffico aumenta a livelli tali da impedirne l’elaborazione in base agli accordi sul livello di servizio, escludi il traffico obsoleto o in eccesso indirizzandolo a una coda per il traffico eccedente. Ciò consente l’elaborazione prioritaria del nuovo processo e del processo più vecchio quando si rende disponibile nuova capacità. Questa tecnica è un’approssimazione dell’elaborazione LIFO e consente la normale elaborazione del sistema per tutti i nuovi processi.
+ Usa le code DLQ o le code di reindirizzamento per spostare i messaggi che non possono essere elaborati dal backlog in una posizione che può essere ricercata e risolta in un secondo momento.
+ Riprova o, se possibile, elimina i vecchi messaggi confrontandoli con il timestamp del messaggio ed eliminando i messaggi che non sono più rilevanti per il client richiedente.
## Risorse
**Best practice correlate:**
+ [REL04-BP02 Implementare dipendenze liberamente accoppiate](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlla e limita le chiamate di nuovo tentativo](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Definizione e calcolo dei parametri (aggregazione)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema](rel_monitor_aws_resources_end_to_end.md)
**Documenti correlati:**
+ [ Evitare insormontabili backlog di code ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Fail Fast](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ Come posso prevenire un aumento del backlog di messaggi nella mia coda Amazon SQS? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: spostamento zonale ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Amazon Application Recovery Controller: controllo dell’instradamento per il failover del traffico ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Esempi correlati:**
+ [ Modelli di integrazione aziendale: canale DLQ ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Video correlati:**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Strumenti correlati:**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Imposta i timeout dei client
Imposta i timeout in modo appropriato per connessioni e richieste, verificali sistematicamente e non fare affidamento sui valori predefiniti perché non fanno riferimento alle specifiche del carico di lavoro.
**Risultato desiderato:** i timeout dei client devono considerare il costo per client, server e carico di lavoro associato all'attesa di richieste il cui completamento richiede una quantità di tempo anomala. Poiché non è possibile conoscere la causa esatta di un timeout, i client devono fare riferimento ai servizi per sviluppare ipotesi sulle cause probabili e sui timeout appropriati.
Il timeout delle connessioni client si verifica in base ai valori configurati. Dopo aver rilevato un timeout, i client decidono di riprovare o aprire un [interruttore](https://martinfowler.com/bliki/CircuitBreaker.html). Questi modelli evitano la generazione di richieste che potrebbero aggravare una condizione di errore sottostante.
**Anti-pattern comuni:**
+ Non essere a conoscenza dei timeout di sistema o dei timeout predefiniti.
+ Non essere a conoscenza dei normali tempi di completamento delle richieste.
+ Non essere a conoscenza delle possibili cause dei tempi anomali necessari per il completamento delle richieste o dei costi in termini di prestazioni di client, servizio o carico di lavoro associati all'attesa di tali completamenti.
+ Non essere consapevoli della probabilità che una rete danneggiata causi un errore di esecuzione della richiesta solo al raggiungimento del timeout, nonché dei costi in termini di prestazioni del client e del carico di lavoro derivanti dalla mancata adozione di un timeout più breve.
+ Non testare gli scenari di timeout sia per le connessioni che per le richieste.
+ Impostazione di timeout troppo elevati, che può comportare lunghi tempi di attesa e aumentare l'utilizzo delle risorse.
+ Impostazione di timeout troppo bassi, con conseguenti errori artificiali.
+ Mancata verifica degli schemi per gestire gli errori di timeout per chiamate remote come interruttori e nuovi tentativi.
+ Non considerare il monitoraggio delle percentuali di errore delle chiamate dei servizi, degli obiettivi del livello di servizio per la latenza e dei valori anomali della latenza. Queste metriche possono fornire informazioni sui timeout restrittivi o permissivi.
**Vantaggi dell'adozione di questa best practice:** i timeout delle chiamate remote sono configurati e i sistemi sono progettati per gestirli correttamente, in modo da preservare le risorse quando le chiamate remote rispondono in modo eccessivamente lento e gli errori di timeout vengono gestiti correttamente dai client di servizio.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Imposta sia un timeout di connessione che un timeout della richiesta su qualsiasi chiamata della dipendenza del servizio e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma è necessario prestare attenzione perché alcuni sono caratterizzati da valori predefiniti infiniti o superiori a quelli accettabili per gli obiettivi dei tuoi servizi. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul backend e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni vere e proprie perché tutte le richieste vengono ritentate.
Considera quanto segue per determinare le strategie di timeout:
+ L'elaborazione delle richieste può richiedere più tempo del normale a causa del loro contenuto, di problemi nel servizio di destinazione o di un errore nella partizione della rete.
+ Le richieste con contenuti troppo costosi potrebbero consumare risorse server e client non necessarie. In questo caso, forzare il timeout di queste richieste e non eseguire nuovi tentativi possono preservare le risorse. I servizi dovrebbero, inoltre, proteggersi da contenuti eccessivamente costosi con limitazione (della larghezza di banda della rete) e timeout lato server.
+ Per le richieste con tempi di elaborazione eccessivamente lunghi a causa di un'interruzione del servizio è possibile forzare il timeout e, quindi, eseguire un nuovo tentativo. È necessario considerare i costi del servizio per la richiesta e il nuovo tentativo, ma se la causa è un problema localizzato, è probabile che un nuovo tentativo non sia costoso e riduca il consumo di risorse del client. Il timeout può anche liberare risorse del server a seconda della natura del problema.
+ Per le richieste il cui completamento richiede troppo tempo o per risposte non distribuite dalla rete è possibile forzare il timeout e, quindi, eseguire un nuovo tentativo. Poiché la richiesta o la risposta non è stata distribuita, viene comunque restituito un errore indipendentemente dalla durata del timeout. Il timeout in questo caso non rilascerà le risorse del server, ma le risorse del client, con il conseguente miglioramento delle prestazioni del carico di lavoro.
Sfrutta gli schemi di progettazione consolidati, come i tentativi e gli interruttori automatici, per gestire i timeout in modo corretto e supportare approcci di tipo fail-fast. [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks)e [AWS CLI](https://aws.amazon.com/cli/)consentono la configurazione dei timeout di connessione e di richiesta e i nuovi tentativi con backoff e jitter esponenziali. [AWS Lambda](https://aws.amazon.com/lambda/)le funzioni supportano la configurazione dei timeout e, con [AWS Step Functions](https://aws.amazon.com/step-functions/), è possibile creare interruttori automatici a basso codice che sfruttano le integrazioni predefinite con i servizi e. AWS SDKs [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy fornisce funzionalità di tipo timeout e interruttore.
## Passaggi dell'implementazione
+ Configura i timeout per le chiamate remote dei servizi e sfrutta le funzionalità di timeout integrate o le librerie di timeout open source.
+ Quando il tuo carico di lavoro effettua chiamate con un AWS SDK, consulta la documentazione per la configurazione del timeout specifica della lingua.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Quando utilizzi AWS CLI i comandi AWS SDKs or nel tuo carico di lavoro, configura i valori di timeout predefiniti impostando i valori di AWS [configurazione](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) predefiniti per e. `connectTimeoutInMillis` `tlsNegotiationTimeoutInMillis`
+ Applica [le opzioni della riga di comando](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` e controlla comandi singoli `cli-read-timeout` AWS CLI ai servizi. AWS
+ Monitora le chiamate remote dei servizi per i timeout e imposta gli allarmi sugli errori persistenti in modo da poter gestire in modo proattivo gli scenari di errore.
+ Implementa le [CloudWatch metriche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e il [rilevamento delle CloudWatch anomalie](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) sui tassi di errore delle chiamate, sugli obiettivi dei livelli di servizio per la latenza e sui valori anomali di latenza per fornire informazioni sulla gestione di timeout eccessivamente aggressivi o permissivi.
+ Configura i timeout sulle [funzioni Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ APII client Gateway devono implementare i propri tentativi quando gestiscono i timeout. APIGateway supporta un [timeout di integrazione da 50 millisecondi a 29 secondi](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) per le integrazioni downstream e non riprova quando le richieste di integrazione scade.
+ Implementa il modello dell'[interruttore](https://martinfowler.com/bliki/CircuitBreaker.html) per evitare di effettuare chiamate remote quando si è verificato il timeout. Apri l'interruttore per evitare chiamate non riuscite e chiudi l'interruttore quando le chiamate rispondono normalmente.
+ Per i carichi di lavoro basati su container, esamina le funzionalità di [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) per sfruttare timeout e interruttori integrati.
+ Utilizzali AWS Step Functions per creare interruttori automatici a basso codice per chiamate di assistenza remota, in particolare quando richiami integrazioni Step Functions AWS native SDKs e supportate per semplificare il carico di lavoro.
## Risorse
**Best practice correlate:**
+ [REL05-BP03 Controlla e limita le chiamate di nuovo tentativo](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Anticipare l’errore (fail fast) e limitare le code](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Monitoraggio del tracciamento end-to-end delle richieste attraverso il sistema](rel_monitor_aws_resources_end_to_end.md)
**Documenti correlati:**
+ [AWS SDK: Tentativi e timeout](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [The Amazon Builders' Library: timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Quote e note importanti di Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: opzioni della riga di comando ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: Configura API i timeout](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore utilizzando l'oggetto config e Config Reference](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK per .NET: nuovi tentativi e timeout ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: configurazione delle opzioni della funzione Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Esempi correlati:**
+ [Utilizzo del pattern di interruttore automatico con AWS Step Functions e Amazon DynamoDB](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [Martin Fowler: CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Strumenti correlati:**
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Rendere i sistemi senza stato ove possibile
I sistemi non devono richiedere lo stato né eseguire l'offload dello stato in modo tale che, tra diverse richieste client, non vi sia alcuna dipendenza dai dati archiviati localmente su disco o in memoria. I server possono così essere sostituiti a piacimento senza compromettere la disponibilità.
Quando gli utenti o i servizi interagiscono con un'applicazione, spesso eseguono una serie di interazioni che formano una sessione. Una sessione è un dato univoco per gli utenti che persistono tra le richieste mentre utilizzano l'applicazione. Un'applicazione stateless è un'applicazione che non richiede la conoscenza delle interazioni precedenti e non memorizza le informazioni sulla sessione.
Una volta progettati per essere stateless, è possibile utilizzare servizi di elaborazione serverless, come o. AWS Lambda AWS Fargate
Oltre alla sostituzione dei server, un altro vantaggio delle applicazioni stateless è la possibilità di scalare orizzontalmente perché tutte le risorse di elaborazione disponibili (come EC2 istanze e AWS Lambda funzioni) possono soddisfare qualsiasi richiesta.
**Vantaggi dell'adozione di questa best practice:** i sistemi con progettazione stateless sono più adattabili alla scalabilità orizzontale, così da poter aggiungere o rimuovere capacità in base alle fluttuazioni di traffico e domanda. Sono inoltre intrinsecamente resistenti ai guasti e offrono flessibilità e agilità allo sviluppo delle applicazioni.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Trasforma le applicazioni in stateless. Le applicazioni stateless consentono la scalabilità orizzontale e sono tolleranti ai guasti di un singolo nodo. Analizza e individua i componenti della tua applicazione che mantengono lo stato dell'architettura. Questo processo ti aiuta a valutare il potenziale impatto della transizione a una progettazione stateless. Un'architettura stateless separa i dati degli utenti ed esegue l'offload dei dati della sessione, offrendo la flessibilità necessaria per scalare ogni componente in modo indipendente al fine di soddisfare le diverse richieste del carico di lavoro e ottimizzare l'utilizzo delle risorse.
### Passaggi dell'implementazione
+ Individua e comprendi i componenti stateful dell'applicazione.
+ Suddividi i dati, separando e gestendo i dati dell'utente dalla logica dell'applicazione principale.
+ [Amazon Cognito](https://aws.amazon.com/cognito/) è in grado di separare i dati degli utenti dal codice dell'applicazione mediante funzionalità come [pool di identità](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), [pool di utenti](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) e [Amazon Cognito Sync](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html).
+ Puoi separare dati degli utenti con [Gestione dei segreti AWS](https://aws.amazon.com/secrets-manager/), archiviando i segreti in un luogo sicuro e centralizzato. Il codice dell'applicazione pertanto non dovrà più memorizzare i segreti, rendendolo più sicuro.
+ Per archiviare dati non strutturati di grandi dimensioni, come immagini e documenti, prendi in considerazione l'utilizzo di [Amazon S3](https://aws.amazon.com/s3/). L'applicazione può recuperare questi dati quando richiesto, eliminando la necessità di archiviarli in memoria.
+ Utilizza [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) per archiviare informazioni come i profili utente. L'applicazione può eseguire query su questi dati pressoché in tempo reale.
+ Trasferisci i dati della sessione in un database, una cache o in file esterni.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Amazon DynamoDB[, Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon) e EFS [Amazon](https://aws.amazon.com/memorydb/) MemoryDB sono esempi AWS di servizi che puoi utilizzare per scaricare i dati della sessione.
+ Progetta un'architettura stateless dopo aver identificato lo stato e i dati dell'utente che devono essere mantenuti con la tua soluzione di archiviazione preferita.
## Risorse
**Best practice correlate:**
+ [REL11-BP03 Automatizza la guarigione su tutti i livelli](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**Documenti correlati:**
+ [The Amazon Builders' Library: evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Best practice per Stateless Web Tier su AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 Implementare leve di emergenza
Le leve di emergenza sono processi rapidi che possono mitigare l'impatto sulla disponibilità sul carico di lavoro.
Le leve di emergenza disabilitano, applicano la limitazione (della larghezza di banda della rete) o modificano il comportamento di componenti o dipendenze mediante meccanismi noti e testati. Ciò può ridurre i danni causati al carico di lavoro dall'esaurimento delle risorse dovuto ad aumenti imprevisti della domanda e l'impatto dei guasti nei componenti non critici all'interno del carico di lavoro.
**Risultato desiderato:** l'implementazione delle leve di emergenza consente di definire processi noti e validi per mantenere la disponibilità dei componenti critici nel carico di lavoro. Il carico di lavoro dovrebbe diminuire gradualmente e continuare a svolgere le sue funzioni aziendali critiche durante l'attivazione di una leva di emergenza. Per maggiori dettagli sulla degradazione graduale, vedere [REL05-BP01](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) Implementare graceful degradation per trasformare le dipendenze rigide applicabili in dipendenze morbide.
**Anti-pattern comuni:**
+ L'errore a livello di dipendenze non critiche influisce sulla disponibilità del carico di lavoro principale.
+ Mancato test o mancata verifica del comportamento dei componenti critici durante il deterioramento delle prestazioni dei componenti non critici.
+ Mancata definizione di criteri chiari e deterministici per l'attivazione o la disattivazione di una leva di emergenza.
**Vantaggi dell'adozione di questa best practice:** l'implementazione delle leve di emergenza migliora la disponibilità dei componenti critici del carico di lavoro fornendo agli addetti alla risoluzione processi consolidati per rispondere a picchi imprevisti della domanda o a guasti delle dipendenze non critiche.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
+ Identifica i componenti critici del tuo carico di lavoro.
+ Progetta e definisci l'architettura dei componenti critici del tuo carico di lavoro in modo che sia in grado di sostenere i guasti dei componenti non critici.
+ Esegui i test per convalidare il comportamento dei componenti critici in caso di guasti dei componenti non critici.
+ Definisci e monitora le metriche o i trigger pertinenti per avviare le procedure relative alle leve di emergenza.
+ Definisci le procedure (manuali o automatiche) che includono la leva di emergenza.
### Passaggi dell'implementazione
+ Identifica i componenti business-critical nel tuo carico di lavoro.
+ Ogni componente tecnico del carico di lavoro deve essere mappato alla funzione aziendale pertinente e classificato come critico o non critico. Per esempi di funzionalità critiche e non critiche di Amazon, consulta [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Si tratta di una decisione sia tecnica che aziendale e varia in base all'organizzazione e al carico di lavoro.
+ Progetta e definisci l'architettura dei componenti critici del tuo carico di lavoro in modo che sia in grado di sostenere i guasti dei componenti non critici.
+ Durante l'analisi delle dipendenze, valuta tutte le potenziali modalità di guasto e verifica che i meccanismi basati su leve di emergenza forniscano le funzionalità critiche ai componenti a valle.
+ Esegui i test per convalidare il comportamento dei componenti critici durante l'attivazione delle leve di emergenza.
+ Evita il comportamento bimodale. [Per maggiori dettagli, consulta -BP05 Utilizzare la stabilità statica per prevenire comportamenti bimodali. REL11](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ Definisci, monitora e attiva gli avvisi per le metriche pertinenti per avviare la procedura relative alla leva di emergenza.
+ L'individuazione delle metriche da monitorare dipende dal carico di lavoro. Alcuni esempi di metrica sono la latenza o il numero di richieste non riuscite nei confronti di una dipendenza.
+ Definisci le procedure (manuali o automatiche) che includono la leva di emergenza.
+ Ciò può includere meccanismi come la [riduzione del carico](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), le [richieste di limitazione (della larghezza di banda della rete)](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) o l'implementazione della [normale riduzione delle prestazioni](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Risorse
**Best practice correlate:**
+ [REL05-BP01 Implementa una degradazione graduale per trasformare le dipendenze rigide applicabili in dipendenze morbide](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Richieste Throttle](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Usa la stabilità statica per prevenire comportamenti bimodali](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Documenti correlati:**
+ [ Automatizzazione di distribuzioni pratiche e sicure ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Video correlati:**
+ [AWS re:Invent 2020: affidabilità, coerenza e fiducia grazie all'immutabilità](https://www.youtube.com/watch?v=jUSYnRztttY)