Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
REL01-BP03 Soddisfa quote e vincoli di servizio fissi tramite l'architettura
Identifica con attenzione quote di servizio, vincoli del servizio e limiti delle risorse fisiche che non possono essere modificati. Progetta architetture per applicazioni e servizi in modo da impedire che questi limiti pregiudichino l'affidabilità.
Gli esempi includono la larghezza di banda di rete, la dimensione del payload per l'invocazione di funzioni senza server, la velocità di accelerazione per un gateway e le connessioni simultanee degli utenti a un database. API
Risultato desiderato: funzionamento dell'applicazione o del servizio come previsto in condizioni di traffico normale e intenso. L'applicazione o il servizio è stato progettato per operare entro i limiti dei vincoli o delle quote di servizio fissi della risorsa.
Anti-pattern comuni:
-
Scelta di una progettazione che usa una risorsa di un servizio, senza essere al corrente della presenza di vincoli che causeranno errori di progettazione durante il dimensionamento.
-
Esecuzione di benchmark poco realistici e che raggiungono le quote di servizio fisse durante i test. Ad esempio, l'esecuzione di test a un limite di espansione per un periodo di tempo prolungato.
-
Scelta di una progettazione non scalabile o modificabile in caso di superamento delle quote di servizio fisse. Ad esempio, una dimensione del payload di 256 KB. SQS
-
Mancata progettazione e implementazione dell'osservabilità per monitorare e inviare avvisi circa le soglie per le quote di servizio a rischio durante eventi di traffico elevato.
Vantaggi dell'adozione di questa best practice: verifica del funzionamento dell'applicazione con tutti i livelli di carico dei servizi previsti senza interruzioni o deterioramenti.
Livello di rischio associato se questa best practice non fosse adottata: medio
Guida all'implementazione
A differenza delle quote o delle risorse di soft service che vengono sostituite con unità di capacità superiore, le quote fisse AWS dei servizi non possono essere modificate. Ciò significa che tutti questi tipi di AWS servizi devono essere valutati per i potenziali limiti di capacità rigida quando vengono utilizzati nella progettazione di un'applicazione.
I limiti fissi vengono mostrati nella console di Service Quotas. Se le colonne visualizzano ADJUSTABLE = No, il servizio ha un limite fisso. I limiti fissi vengono mostrati anche in alcune pagine di configurazione delle risorse. Ad esempio, Lambda presenta un limite fisso specifico che non può essere modificato.
Ad esempio, durante la progettazione di un'applicazione Python da eseguire in una funzione Lambda, l'applicazione deve essere valutata per determinare la probabilità di un'esecuzione di Lambda superiore a 15 minuti. Se il codice potrebbe restare in esecuzione oltre questo limite della quota di servizio, devi prendere in considerazione tecnologie o progettazioni alternative. In caso di raggiungimento del limite dopo l'implementazione nell'ambiente di produzione, l'applicazione sarà soggetta a errori o interruzioni fino alla correzione. A differenza dalle quote flessibili, non esiste alcun metodo per modificare i limiti, anche in caso di eventi di emergenza con livello di gravità 1.
Una volta implementata l'applicazione in un ambiente di test, occorre adottare una strategia per determinare se l'eventuale probabilità di raggiungere i limiti fissi. I test di stress, di carico e di caos devono fare parte del piano di test iniziale.
Passaggi dell'implementazione
-
Consulta l'elenco completo dei AWS servizi che potrebbero essere utilizzati nella fase di progettazione dell'applicazione.
-
Esamina i limiti di quota flessibili e fissi per tutti i servizi. Non tutti i limiti vengono mostrati nella console di Service Quotas. Alcuni servizi indicano tali limiti in posizioni alternative.
-
Nel progettare l'applicazione, esamina i principali fattori commerciali e tecnologici del carico di lavoro, come risultati aziendali, casi d'uso, sistemi dipendenti, obiettivi di disponibilità e oggetti di ripristino di emergenza. Orienta il processo di identificazione del sistema distribuito corretto per il carico di lavoro in base a tali fattori commerciali e tecnologici.
-
Analizza il carico dei servizi tra regioni e account. Molti limiti fissi per i servizi variano a seconda della regione. Tuttavia, alcuni limiti dipendono dagli account.
-
Analizza le architetture di resilienza per l'utilizzo delle risorse durante un guasto a livello di zona e di regione. Nel corso dello sviluppo di progettazioni multi-regione che usano approcci attivo/attivo, attivo/passivo con standby a caldo, attivo/passivo con standby a freddo e attivo/passivo con Pilot Light, i casi di errore determineranno un utilizzo più elevato. Questo comportamento crea un possibile caso d'uso per il raggiungimento dei limiti fissi.
Risorse
Best practice correlate:
Documenti correlati:
-
AWS Il pilastro dell'affidabilità di Well-Architected Framework: disponibilità
-
AWS Service Quotas (precedentemente denominate limiti di servizio)
-
APNPartner: partner che possono aiutare nella gestione della configurazione
-
Gestione del ciclo di vita dell'account in ambienti SaaS account-per-tenant su AWS
-
Gestione e monitoraggio della limitazione dei carichi di API lavoro
-
Visualizza i AWS Trusted Advisor consigli su larga scala con AWS Organizations
-
Automatizzazione degli aumenti dei limiti di servizio e del supporto aziendale con AWS Control Tower
Video correlati:
Strumenti correlati:
