Modello dei timbri di distribuzione

Il modello Deployment Stamps fornisce, gestisce e monitora un gruppo di risorse per ospitare e operare più carichi di lavoro o tenant. Ogni singola copia viene chiamata stamp o a volte un'unità di servizio, un'unità di scala o una cella. In un ambiente multi-tenant ogni stamp serve un numero predefinito di tenant. Si distribuiscono più timbri per ridimensionare la soluzione quasi linearmente e gestire un numero crescente di tenant. Questo approccio può migliorare la scalabilità della soluzione, consentire di distribuire istanze in più aree e separare i dati dei clienti.

Annotazioni

Per altre informazioni, vedere Progettare soluzioni multi-tenant in Azure.

Contesto e problema

Quando si ospita un'applicazione nel cloud, prendere in considerazione le prestazioni e l'affidabilità dell'applicazione. Se si ospita una singola istanza della soluzione, potrebbero essere applicate le limitazioni seguenti:

• Limiti di scalabilità: Una singola istanza dell'applicazione potrebbe raggiungere limiti di ridimensionamento naturali. Ad esempio, i servizi usati potrebbero limitare il numero di connessioni in ingresso, nomi host, socket TCP (Transmission Control Protocol) o altre risorse.

• Scalabilità non lineare o costo: Alcuni componenti della soluzione potrebbero non essere ridimensionati in modo lineare con il numero di richieste o la quantità di dati. Invece, le prestazioni possono peggiorare o i costi possono aumentare dopo aver raggiunto una soglia. Ad esempio, si potrebbe notare che aggiungere maggiore capacità a un database, o scalare verso l'alto, diventa eccessivamente costoso e che scalare verso l'esterno è più conveniente.

• Separazione dei clienti: Potrebbe essere necessario isolare i dati di un cliente dai dati di un altro cliente. È anche possibile che i clienti consumino più risorse di sistema rispetto ad altri. È possibile raggrupparli in diversi set di infrastrutture.

• Istanze a tenant singolo e multi-tenant: Alcuni clienti di grandi dimensioni potrebbero avere bisogno di istanze indipendenti della soluzione. I clienti più piccoli possono condividere una distribuzione multi-tenant.

• Requisiti di distribuzione complessi: Potrebbe essere necessario distribuire gli aggiornamenti al servizio in modo controllato e distribuirlo in diversi subset della base clienti in momenti diversi.

• Frequenza di aggiornamento: Alcuni clienti tollerano aggiornamenti frequenti, mentre i clienti a rischio vogliono aggiornamenti non frequenti al sistema che gestisce le richieste. È possibile distribuire questi clienti in ambienti isolati.

• Restrizioni geografiche o geopolitiche: Per ottenere bassa latenza o rispettare i requisiti di sovranità dei dati, è possibile distribuire alcuni clienti in aree specifiche.

Queste limitazioni si applicano spesso alle aziende di sviluppo software che creano software come servizio (SaaS), che in genere progettano come multi-tenant. Le stesse limitazioni possono essere applicate anche ad altri scenari.

Soluzione

Per evitare questi problemi, è consigliabile raggruppare le risorse in unità di scala e effettuare il provisioning di più copie delle stampe. Ogni unità di scala ospita e fornisce un sottoinsieme dei tuoi clienti. Gli stamp vengono eseguiti indipendentemente l'uno dall'altro ed è possibile distribuirli e aggiornarli in modo indipendente. Una singola area geografica può contenere uno stampo o più stampi che si ridimensionano orizzontalmente all'interno dell'area. Ciascun stamp gestisce un subset dei clienti.

Il diagramma mostra cinque righe in pila. Ogni riga rappresenta un'etichetta di distribuzione. Ogni riga ha un'etichetta in alto a sinistra che denomina il timbro e la relativa area Azure, un'etichetta in alto a destra che elenca i tenant serviti dal timbro e due componenti sotto le etichette: Servizio app di Azure a sinistra e un database SQL a destra. Dall'alto verso il basso, i francobolli sono stamp 1 negli Stati Uniti occidentali 2, che serve i tenant A, B e C; Stamp 2 negli Stati Uniti occidentali 2, che serve il tenant D; Stamp 3 negli Stati Uniti orientali, che serve i tenant E, F e G; Stamp 4 in Europa occidentale, che serve i tenant H, I e J; e stamp 5 in Australia orientale, che serve tenant K, L e M. I cinque timbri condividono la stessa composizione interna, ma differiscono in area e nel set di tenant assegnati, e l'area Stati Uniti occidentali 2 contiene due francobolli separati, mentre ognuna delle altre aree contiene un timbro.

Gli stampi di distribuzione si applicano sia che la soluzione utilizzi componenti IaaS (Infrastruttura come Servizio) o PaaS (Piattaforma come Servizio), o una combinazione di entrambi. I carichi di lavoro IaaS richiedono in genere un maggiore intervento per la scalabilità, quindi questo modello può aiutare i carichi di lavoro IaaS a aumentare le prestazioni.

È possibile usare i francobolli per implementare gli anelli di distribuzione. Se diversi clienti desiderano aggiornamenti del servizio a frequenze diverse, raggrupparli in timbri diversi e distribuire gli aggiornamenti a ogni timbro a cadenza diversa.

I francobolli vengono eseguiti in modo indipendente, quindi partizionano in modo implicito i dati. Un singolo timbro può anche usare un ulteriore partizionamento orizzontale internamente per ridimensionare e rimanere elastico.

La distribuzione di copie identiche degli stessi componenti è complessa, quindi le procedure DevOps consigliate sono fondamentali. Descrivi la tua infrastruttura come codice, in modo che la distribuzione di ogni istanza sia prevedibile e ripetibile.

Le stampe di distribuzione sono correlate a, ma differiscono dai geodes. In un'architettura di modellino di distribuzione, ogni istanza del sistema, indipendente, gestisce un sottoinsieme di clienti e utenti. In un'architettura geode ogni istanza può gestire le richieste da qualsiasi utente, ma questo approccio è in genere più complesso da progettare e compilare. È anche possibile combinare i due modelli all'interno di una soluzione. L'approccio di routing del traffico descritto più avanti in questo articolo è un esempio di scenario ibrido di questo tipo.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

• Processo di distribuzione: Quando si distribuiscono più francobolli, automatizzare e ripetere completamente i processi di distribuzione. Usare Bicep o Terraform moduli per definire in modo dichiarativo i timbri e mantenere coerenti le definizioni.

• Operazioni crossstamp: Quando si distribuisce la soluzione in modo indipendente tra più francobolli, può essere difficile determinare il numero di clienti presenti in tutti i francobolli. Potrebbe essere necessario interrogare ogni timbro e aggregare i risultati. In alternativa, è possibile disporre di tutti i francobolli che pubblicano i dati in un data warehouse centralizzato per la creazione di report consolidati.

• Criteri di scalabilità orizzontale: Gli stamp hanno una capacità limitata, che è possibile definire usando una metrica proxy, ad esempio il numero di tenant che è possibile distribuire nello stamp. Monitorare la capacità disponibile e utilizzata per ogni istanza e distribuire proattivamente più istanze per indirizzare i nuovi tenant a esse.

• Numero minimo di istanze: Quando si usa il modello Deployment Stamps, distribuire almeno due istanze della tua soluzione. Se si distribuisce un solo timbro, è possibile impostare facilmente presupposti hardcoded nel codice o nella configurazione che non si applicano quando si aumenta il numero di istanze.

• Costo: Il modello Deployment Stamps distribuisce più copie dei componenti dell'infrastruttura, aumentando notevolmente il costo della soluzione.

• Spostamento tra timbri: Ogni timbro viene eseguito in modo indipendente, quindi lo spostamento dei tenant tra timbri può essere difficile. L'applicazione necessita di logica personalizzata per trasmettere le informazioni di un cliente a un timbro diverso e quindi rimuovere le informazioni del tenant dal timbro originale. Questo processo potrebbe richiedere un backplane per comunicare tra stampi, aumentando ulteriormente la complessità della tua soluzione.

• Routing del traffico: Come descritto in precedenza in questo articolo, il routing del traffico verso il timbro corretto per una determinata richiesta può richiedere un componente aggiuntivo che risolve i tenant nei francobolli. Questo componente potrebbe necessitare anche di un'elevata disponibilità.

• Osservabilità tra timbri: Man mano che aumenta il numero di francobolli, diventa più difficile comprendere l'integrità complessiva e rilevare rapidamente gli eventi imprevisti. Usare Monitoraggio di Azure per raccogliere e correlare metriche, log, tracce e avvisi in tutti i data center. Usare questi dati per identificare i timbri non sani e diagnosticare i problemi.

• Impatto dell'errore a livello di area: Gli stamp vengono eseguiti in modo indipendente, ma non sono intrinsecamente ridondanti tra le aree. Se una regione che ospita uno o più nodi diventa non disponibile, i tenant su quei nodi perdono l'accesso fino a quando la regione non viene ripristinata o si esegue la migrazione dei tenant ai nodi in un'altra regione. Per pianificare questo scenario, documentare le procedure di ripristino, impostare le aspettative del tenant e valutare se i tenant critici necessitano del posizionamento del timbro con ridondanza geografica.

• Componenti condivisi: Potrebbero essere presenti componenti che è possibile condividere tra timbri. Ad esempio, se si dispone di un'applicazione a pagina singola, condivisa per tutti i tenant, distribuirla in una regione e usare il caching edge di Frontdoor di Azure per replicarla a livello globale.

• Governance e deviazione della configurazione: Man mano che aumenta il numero di indicatori, diventa più difficile mantenere coerenti i criteri di sicurezza, le assegnazioni di controllo degli accessi in base al ruolo, i controlli di rete, le impostazioni di osservabilità e le configurazioni del servizio. Usare Criteri di Azure per considerare la governance come codice e convalidare continuamente ogni istanza per rilevare derive, prevenendo comportamenti incoerenti e lacune di conformità.

Quando usare questo modello

Usare questo modello quando:

• La soluzione presenta limiti naturali per la scalabilità. Ad esempio, se alcuni componenti non possono o non devono essere ridimensionati oltre un determinato numero di clienti o richieste, usare stamp per aumentare il numero di istanze.

• È necessario separare determinati tenant da altri. Se i problemi di sicurezza impediscono la distribuzione di alcuni clienti in un timbro multi-tenant, distribuirli nel proprio timbro isolato.

• È necessario ospitare alcuni tenant in versioni diverse della soluzione contemporaneamente.

• Si creano applicazioni multiregione che devono indirizzare i dati e il traffico di ogni tenant a un'area specifica.

• Si vuole ottenere resilienza durante le interruzioni. Le partizioni funzionano in modo indipendente, quindi se un'interruzione influisce su una singola partizione, i tenant su altre partizioni rimangono invariati. Questo isolamento contiene il raggio dell'esplosione di un incidente o di un'interruzione.

Questo modello potrebbe non essere adatto quando:

• La soluzione è semplice e non deve essere ridimensionata a un livello elevato.

• È possibile aumentare o aumentare le prestazioni del sistema all'interno di una singola istanza, ad esempio aumentando le dimensioni del livello dell'applicazione o aumentando la capacità riservata per i database e il livello di archiviazione.

• È necessario replicare i dati in tutte le istanze distribuite. Si consideri il modello Geode per questo scenario.

• È sufficiente ridimensionare alcuni componenti e non altri. Si consideri, ad esempio, se è possibile ridimensionare la soluzione partizionando l'archivio dati invece di distribuire una nuova copia di tutti i componenti della soluzione.

• La soluzione è costituita esclusivamente da contenuto statico, ad esempio un'applicazione JavaScript front-end. Distribuire questo contenuto da una rete per la distribuzione di contenuti.

Progettazione del carico di lavoro

Valutare come usare il modello Deployment Stamps nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro	Come questo modello supporta gli obiettivi di pilastro
decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto.	Gli stamp funzionano in modo indipendente, quindi un guasto in un timbro è isolato e non influisce sui tenant su altri francobolli. La distribuzione di più francobolli tra aree offre anche una base per la pianificazione della ridondanza e del ripristino, riducendo così il raggio di esplosione delle interruzioni a livello di area. - Ridondanza RE:05 - RE:07 Autoconservazione
L'eccellenza operativa consente di offrire la qualità del carico di lavoro attraverso processi standardizzati e coesione del team.	Questo modello supporta obiettivi di infrastruttura non modificabili, modelli di distribuzione avanzati e può facilitare procedure di distribuzione sicure. - OE:05 Infrastruttura come codice - OE:11 Procedure di distribuzione sicura
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice.	Questo modello è spesso allineato alle unità di scala definite nel carico di lavoro. Quando è necessaria una capacità maggiore rispetto a una singola unità di scala, si implementa un altro stamp per aumentare il numero di istanze. - PE:05 Ridimensionamento e partizionamento

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Esempio

L'architettura di esempio seguente usa Frontdoor di Azure, Gestione API di Azure e Azure Cosmos DB per instradare il traffico a livello globale a una serie di indicatori specifici dell'area.

All'estrema sinistra, Frontdoor di Azure (globale) rappresenta il punto di ingresso. A destra, il centro del diagramma contiene tre livelli di routing del traffico regionali impilati verticalmente, uno ciascuno per West US 2, East US e Australia East. In ogni livello, un'istanza di Gestione API si trova a sinistra e un'istanza di Azure Cosmos DB si trova a destra e una query con freccia doppia con etichetta per il timbro del tenant le connette. Le frecce a due punte verticali contrassegnate con la replica geografica collegano le tre istanze di Azure Cosmos DB. Frontdoor di Azure si connette con freccia bidirezionale a tutte e tre le istanze di Gestione API. All'estrema destra, cinque francobolli sono impilati verticalmente. Ogni timbro mostra il nome e l'area, i tenant che serve e un'istanza del servizio app abbinata a un database SQL. I francobolli sono stamp 1 (Stati Uniti occidentali 2) per i tenant A, B e C; Stamp 2 (Stati Uniti occidentali 2) per il tenant D; Stamp 3 (Stati Uniti orientali) per i tenant E, F e G; Stamp 4 (Europa occidentale) per i tenant H, I e J; e Stamp 5 (Australia orientale) per i tenant K, L e M. Frecce curve portano dalle istanze di Gestione API ai timbri appropriati a destra.

Si supponga che un utente risieda a New York. Stamp 3, nell'area Stati Uniti orientali, archivia i dati.

Se l'utente viaggia in California e accede al sistema, il sistema instrada la connessione attraverso l'area Stati Uniti occidentali 2 perché tale area è più vicina quando effettua la richiesta. Tuttavia, il timbro 3 deve alla fine soddisfare la richiesta perché archivia i loro dati. Il sistema di routing del traffico indirizza la richiesta al timbro corretto.

Distribuzione

Descrivere l'infrastruttura come codice usando Bicep o Terraform. Questo approccio garantisce che la distribuzione di ogni stamp sia prevedibile e ripetibile. Riduce inoltre la probabilità di errori umani, ad esempio mancate corrispondenze accidentali nella configurazione tra timbri.

È possibile distribuire automaticamente gli aggiornamenti in tutti i francobolli in parallelo. Tecnologie come Bicep possono coordinare la distribuzione dell'infrastruttura e delle applicazioni. In alternativa, è possibile decidere di implementare gradualmente gli aggiornamenti ad alcuni francobolli e quindi progressivamente ad altri francobolli. Prendere in considerazione l'uso di uno strumento di gestione delle versioni come Azure Pipelines o GitHub Actions per orchestrare le distribuzioni in ogni stamp.

Considerare attentamente la topologia delle sottoscrizioni e dei gruppi di risorse di Azure per le distribuzioni:

• In genere, una sottoscrizione contiene tutte le risorse per una singola soluzione, pertanto è consigliabile usare una singola sottoscrizione per tutti i francobolli. Tuttavia, alcuni servizi di Azure impongono quote a livello di abbonamento. Se si usa questo modello per consentire un livello elevato di scalabilità orizzontale, potrebbe essere necessario distribuire stamp in sottoscrizioni diverse.

• I gruppi di risorse in genere contengono componenti che condividono lo stesso ciclo di vita. Se si prevede di distribuire gli aggiornamenti a tutti i francobolli contemporaneamente, è possibile usare un singolo gruppo di risorse che contiene tutti i componenti per tutti i francobolli. Usare convenzioni di denominazione delle risorse e tag per identificare i componenti che appartengono a ogni stamp. In alternativa, se prevedi di distribuire gli aggiornamenti a ciascun stampo in modo indipendente, puoi distribuire ogni stampo nel proprio gruppo di risorse.

Pianificazione della capacità

Utilizzare test di carico e di prestazione per determinare il carico approssimativo che un determinato timbro può contenere. Le metriche di carico possono essere basate sul numero di clienti o tenant che un singolo stamp può contenere o sulle metriche che i servizi nello stamp generano. Instrumentare ogni stamp in modo che sia possibile misurare quando si avvicina alla sua capacità e assicurarsi di poter distribuire rapidamente nuovi timbri per rispondere alla domanda.

instradamento del traffico

Il modello Deployment Stamps funziona bene quando si indirizza ogni timbro in modo indipendente. Ad esempio, se Contoso distribuisce la stessa applicazione API tra più francobolli, Contoso potrebbe usare Domain Name System (DNS) per instradare il traffico al timbro pertinente:

• unit1.aus.myapi.contoso.com indirizza il traffico verso il servizio unit1 all'interno di una regione australiana.
• unit2.aus.myapi.contoso.com instrada il traffico verso il nodo unit2 all'interno di una regione australiana.
• unit1.eu.myapi.contoso.com indirizza il traffico verso il nodo unit1 all'interno di un'area europea.

In Azure è possibile ospitare questi record in DNS di Azure e usare una convenzione di sottodominio coerente per ogni area e timbro. Questo approccio mantiene il routing e le operazioni prevedibili.

I clienti sono responsabili della connessione alla stampante corretta.

Se la tua soluzione richiede un singolo punto di ingresso per tutto il traffico, è possibile usare un servizio di routing del traffico per determinare l'identificativo per una determinata richiesta, cliente o inquilino. Il servizio di routing del traffico indirizza il client all'URL pertinente per lo stamp (ad esempio, restituendo un codice di stato della risposta HTTP 302) oppure funge da proxy inverso e inoltra il traffico al timbro pertinente senza che il client sia a conoscenza.

Un servizio di routing del traffico centralizzato può essere un componente complesso da progettare, soprattutto quando una soluzione viene eseguita in più aree. Valutare la possibilità di distribuire il servizio di routing del traffico in più aree, incluse potenzialmente tutte le aree che ospitano timbri e sincronizzare l'archivio dati che esegue il mapping dei tenant ai timbri. Il componente di routing del traffico potrebbe essere un'istanza del modello Geode.

Ad esempio, è possibile distribuire Gestione API per fungere da servizio di routing del traffico. Gestione API determina il timbro appropriato per una richiesta cercando i dati in una raccolta Azure Cosmos DB che archivia il mapping tra tenant e timbri. Gestione API imposta quindi dinamicamente l'URL back-end sul servizio API del timbro pertinente.

Per distribuire geograficamente le richieste e fornire ridondanza geografica per il servizio di routing del traffico, deploy API Management in più aree e usare Frontdoor di Azure per indirizzare il traffico al gateway di Gestione API più vicino. In questa topologia, Frontdoor di Azure usa gruppi di origine, sonde di integrità e un metodo di routing appropriato per instradare le richieste dai gateway regionali di API Management non funzionanti. Gestione API indirizza quindi al timbro appropriato usando il mapping da tenant a stamp e la relativa configurazione back-end (o pool back-end), incluse le regole di failover tra gli endpoint stamp in base alle esigenze. Se l'applicazione non è esposta tramite HTTP o HTTPS, è possibile usare un bilanciatore di carico cross-region Azure per distribuire le chiamate in ingresso ai bilanciatori di carico regionali Azure. Usare la funzionalità di distribuzione globale di Azure Cosmos DB per mantenere aggiornate le informazioni di mapping in ogni area.

Se la soluzione include un servizio di routing del traffico, valutare se funge da gateway e può eseguire lo scaricamento del gateway per gli altri servizi, ad esempio la convalida del token, la limitazione e l'autorizzazione.

Passaggi successivi

• Frontdoor di Azure
• Integrare Bicep con Azure Pipelines
• Integrare modelli di Resource Manager JSON con Azure Pipelines

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

• John Downs | Principal Software Engineer, Azure Patterns & Pratiche

Altri contributori:

• Federico Arambarri | Senior Software Developer, Clarius Consulting
• Daniel Larsen | Ingegnere Cliente Principale, FastTrack per Azure
• Angel Lopez | Senior Software Engineer, Modelli e procedure di Azure
• Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
• Arsen Vladimirskiy | Ingegnere principale per i clienti, FastTrack per Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Risorse correlate

• È possibile usare il partizionamento orizzontale come un approccio alternativo e più semplice per aumentare il livello dei dati. Gli stamp suddividono in modo implicito i dati, ma lo sharding non richiede un marcatore di distribuzione. Per altre informazioni, vedere modello di partizionamento orizzontale.
• Se la tua soluzione distribuisce un servizio di routing del traffico, è possibile combinare i modelli di routing del gateway e di scaricamento del gateway per ottimizzare l'uso di questo componente.