Modello degli stamp di distribuzione

Il modello di stamp di distribuzione prevede il provisioning, la gestione e il monitoraggio di un gruppo eterogeneo di risorse per ospitare e gestire 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 o unità di scala può servire un numero predefinito di tenant. È possibile distribuire più stamp 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.

Contesto e problema

Quando si ospita un'applicazione nel cloud, è importante considerare le prestazioni e l'affidabilità dell'applicazione. Se si ospita una singola istanza della soluzione, è possibile che siano previste le limitazioni seguenti:

• Limiti di scalabilità. La distribuzione di una singola istanza dell'applicazione potrebbe comportare limiti di ridimensionamento naturali. Ad esempio, è possibile usare servizi con limiti per il numero di connessioni in ingresso, nomi host, socket TCP 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. Al contrario, può verificarsi un calo improvviso delle prestazioni o un aumento dei costi una volta raggiunta una soglia. Ad esempio, è possibile usare un database e scoprire che il costo marginale dell'aggiunta di maggiore capacità (aumento delle prestazioni) diventa proibitivo e che l'aumento del numero di istanze è una strategia più conveniente.
• Separazione dei clienti. Potrebbe essere necessario mantenere i dati di determinati clienti isolati dai dati di altri clienti. Analogamente, potrebbero essere presenti alcuni clienti che richiedono più risorse di sistema per il servizio rispetto ad altre e valutare la possibilità di raggrupparli in set diversi di infrastruttura.
• Gestione di istanze a tenant singolo e multi-tenant. Potrebbero essere presenti alcuni clienti di grandi dimensioni che necessitano delle proprie istanze indipendenti della soluzione. È anche possibile avere un pool di clienti più piccoli che possono condividere una distribuzione multi-tenant.
• Requisiti di distribuzione complessi. Potrebbe essere necessario distribuire gli aggiornamenti al servizio in modo controllato e per eseguire la distribuzione in subset diversi della base clienti in momenti diversi.
• Frequenza di aggiornamento. Si potrebbero avere alcuni clienti che sono tolleranti di avere aggiornamenti frequenti al sistema, mentre altri potrebbero essere a rischio-averso e desiderano aggiornamenti poco frequenti al sistema che gestiscono le richieste. Potrebbe essere opportuno che questi clienti siano distribuiti in ambienti isolati.
• Restrizioni geografiche o geopolitiche. Per progettare una bassa latenza o per rispettare i requisiti di sovranità dei dati, è possibile distribuire alcuni clienti in aree specifiche.

Queste limitazioni sono spesso applicabili ai fornitori di software indipendenti (ISV) che creano software come servizio (SaaS), che sono spesso progettati per essere multi-tenant. Tuttavia, 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 dei francobolli. Ogni unità di scala ospiterà e servirà un subset dei tenant. Gli stamp operano autonomamente l'uno dall'altro e possono essere distribuiti e aggiornati in modo indipendente. Una singola area geografica può contenere un singolo timbro o contenere più timbri per consentire la scalabilità orizzontale all'interno dell'area. Gli stamp contengono un subset dei clienti.

Gli indicatori di distribuzione possono applicare se la soluzione usa componenti IaaS (Infrastructure as a Service) o PaaS (Platform as a Service) o una combinazione di entrambi. In genere, i carichi di lavoro IaaS richiedono un maggiore intervento per la scalabilità, quindi il modello potrebbe essere utile per i carichi di lavoro con un numero elevato di operazioni IaaS per consentire la scalabilità orizzontale.

Gli stamp possono essere usati per implementare gli anelli di distribuzione. Se diversi clienti vogliono ricevere aggiornamenti del servizio a frequenze diverse, possono essere raggruppati in timbri diversi e ogni timbro potrebbe avere aggiornamenti distribuiti a cadenza diversa.

Poiché gli stamp vengono eseguiti indipendentemente l'uno dall'altro, i dati vengono partizionati in modo implicito. Inoltre, un singolo timbro può usare un ulteriore partizionamento orizzontale per consentire internamente la scalabilità e l'elasticità all'interno del timbro.

Il modello di stamp di distribuzione viene usato internamente da molti servizi di Azure, tra cui servizio app, Azure Stack e Archiviazione di Azure.

I francobolli di distribuzione sono correlati, ma diversi dai geodes. In un'architettura dello stamp di distribuzione vengono distribuite più istanze indipendenti del sistema e contengono un subset di clienti e utenti. Nei geodes, tutte le istanze possono gestire le richieste da qualsiasi utente, ma questa architettura è spesso più complessa 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 uno scenario ibrido di questo tipo.

Distribuzione

A causa della complessità coinvolta nella distribuzione di copie identiche degli stessi componenti, le procedure DevOps consigliate sono fondamentali per garantire il successo durante l'implementazione di questo modello. Prendere in considerazione la descrizione dell'infrastruttura come codice, ad esempio usando Bicep, i modelli di Azure Resource Manager JSON (modelli ARM), Terraform e gli script. Con questo approccio, è possibile assicurarsi 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 gli indicatori in parallelo, nel qual caso è possibile prendere in considerazione tecnologie come i modelli Bicep o Resource Manager per coordinare la distribuzione dell'infrastruttura e delle applicazioni. In alternativa, è possibile decidere di implementare gradualmente gli aggiornamenti in alcuni francobolli e quindi progressivamente ad altri. 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. Per altre informazioni, vedi:

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

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, quindi in generale prendere in considerazione l'uso di una singola sottoscrizione per tutti i francobolli. Tuttavia, alcuni servizi di Azure impongono quote a livello di sottoscrizione, quindi se si usa questo modello per consentire un livello elevato di scalabilità orizzontale, potrebbe essere necessario valutare la possibilità di distribuire stamp tra sottoscrizioni diverse.
• I gruppi di risorse vengono in genere usati per distribuire componenti con lo stesso ciclo di vita. Se si prevede di distribuire gli aggiornamenti a tutti i francobolli contemporaneamente, è consigliabile usare un singolo gruppo di risorse per contenere tutti i componenti per tutti i timbri e usare convenzioni di denominazione delle risorse e tag per identificare i componenti che appartengono a ogni timbro. In alternativa, se si prevede di distribuire gli aggiornamenti a ogni stamp in modo indipendente, valutare la possibilità di distribuire ogni stamp nel proprio gruppo di risorse.

Pianificazione capacità

Usare test di carico e prestazioni per determinare il carico approssimativo che un determinato stamp può contenere. Le metriche di caricamento possono essere basate sul numero di clienti/tenant che un singolo timbro può contenere o metriche dei servizi generati dai componenti all'interno del timbro. Assicurarsi di disporre di strumentazione sufficiente per misurare quando un determinato timbro sta raggiungendo la capacità e la possibilità di distribuire rapidamente nuovi francobolli per rispondere alla domanda.

instradamento del traffico

Il modello Stamp di distribuzione funziona correttamente se ogni stamp viene indirizzato in modo indipendente. Ad esempio, se Contoso distribuisce la stessa applicazione API tra più francobolli, potrebbe prendere in considerazione l'uso del DNS per instradare il traffico al timbro pertinente:

• unit1.aus.myapi.contoso.com indirizza il traffico all'interno unit1 di un'area australiana.
• unit2.aus.myapi.contoso.com indirizza il traffico all'interno unit2 di un'area australiana.
• unit1.eu.myapi.contoso.com indirizza il traffico all'interno unit1 di un'area europea.

I client sono quindi responsabili della connessione al timbro corretto.

Se è necessario un singolo punto di ingresso per tutto il traffico, è possibile usare un servizio di routing del traffico per risolvere il timbro per una determinata richiesta, cliente o tenant. Il servizio di routing del traffico indirizza il client all'URL pertinente per lo stamp (ad esempio, usando un codice di stato della risposta HTTP 302) oppure può fungere da proxy inverso e inoltrare 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 (potenzialmente incluse tutte le aree in cui vengono distribuiti gli indicatori) e quindi assicurarsi che l'archivio dati (mapping dei tenant ai timbri) sia sincronizzato. Il componente di routing del traffico potrebbe essere un'istanza del modello geode.

Ad esempio, è possibile distribuire azure Gestione API per agire nel ruolo del servizio di routing del traffico. Può determinare il timbro appropriato per una richiesta cercando i dati in una raccolta di Azure Cosmos DB che archivia il mapping tra tenant e timbri. Gestione API può quindi impostare dinamicamente l'URL back-end sul servizio API del timbro pertinente.

Per abilitare la distribuzione geografica delle richieste e la ridondanza geografica del servizio di routing del traffico, Gestione API può essere distribuita in più aree o Frontdoor di Azure può essere usata per indirizzare il traffico all'istanza più vicina. Frontdoor può essere configurato con un pool back-end, consentendo di indirizzare le richieste all'istanza di Gestione API disponibile più vicina. Se l'applicazione non è esposta tramite HTTP/S, è possibile usare un'istanza di Azure Load Balancer tra aree per distribuire le chiamate in ingresso ai servizi di bilanciamento del carico di Azure a livello di area. La funzionalità di distribuzione globale di Azure Cosmos DB può essere usata per mantenere aggiornate le informazioni di mapping in ogni area.

Se nella soluzione è incluso un servizio di routing del traffico, valutare se funge da gateway e quindi eseguire l'offload del gateway per gli altri servizi, ad esempio la convalida dei token, la limitazione e l'autorizzazione.

Architettura di routing del traffico di esempio

Si consideri l'architettura di routing del traffico di esempio seguente, che usa Frontdoor di Azure, Azure Gestione API e Azure Cosmos DB per il routing del traffico globale e quindi una serie di indicatori specifici dell'area:

Si supponga che un utente risieda normalmente a New York. I dati vengono archiviati nel timbro 3, nell'area Stati Uniti orientali.

Se l'utente viaggia in California e quindi accede al sistema, la connessione verrà probabilmente instradata attraverso l'area Stati Uniti occidentali 2 perché è più vicina a dove sono geograficamente quando effettuano la richiesta. Tuttavia, la richiesta deve essere servita dal timbro 3, perché si tratta della posizione in cui sono archiviati i dati. Il sistema di routing del traffico garantisce che la richiesta venga instradata al timbro corretto.

Considerazioni e problemi

Prima di decidere come implementare questo schema, è opportuno considerare quanto segue:

• Processo di distribuzione. Quando si distribuiscono più francobolli, è consigliabile avere processi di distribuzione automatizzati e completamente ripetibili. Prendere in considerazione l'uso di moduli Bicep, JSON ARM o Terraform per definire in modo dichiarativo i timbri e mantenere coerenti le definizioni.
• Operazioni crossstamp. Quando la soluzione viene distribuita in modo indipendente tra più francobolli, le domande come "quanti clienti abbiamo in tutti i nostri francobolli?" possono diventare più complesse da rispondere. Potrebbe essere necessario eseguire query su ogni stamp e sui risultati aggregati. In alternativa, prendere in considerazione la possibilità di pubblicare tutti i dati in un data warehouse centralizzato per la creazione di report consolidati.
• Determinazione dei criteri di scalabilità orizzontale. Gli indicatori hanno una capacità limitata, che può essere definita usando una metrica proxy, ad esempio il numero di tenant che possono essere distribuiti nel timbro. È importante monitorare la capacità disponibile e la capacità usata per ogni stamp e distribuire in modo proattivo indicatori aggiuntivi per consentire ai nuovi tenant di essere indirizzati.
• Numero minimo di francobolli. Quando si usa lo schema Deployment Stamp, è consigliabile distribuire almeno due stamp della soluzione. Se si distribuisce un solo timbro, è facile eseguire accidentalmente ipotesi hardcoded nel codice o nella configurazione che non verranno applicate quando si aumenta il numero di istanze.
• Costo. Il modello Deployment Stamp prevede la distribuzione di più copie del componente dell'infrastruttura, che probabilmente comporta un notevole aumento del costo della soluzione operativa.
• Spostamento tra timbri. Ogni timbro viene distribuito e gestito in modo indipendente, quindi lo spostamento dei tenant tra timbri può essere difficile. L'applicazione richiede una logica personalizzata per trasmettere le informazioni su un determinato cliente a un indicatore diverso e quindi rimuovere le informazioni del tenant dal timbro originale. Questo processo potrebbe richiedere un backplane per la comunicazione tra timbri, aumentando ulteriormente la complessità della soluzione complessiva.
• Routing del traffico. Come descritto in precedenza in questo articolo, il routing del traffico al timbro corretto per una determinata richiesta può richiedere un componente aggiuntivo per risolvere i tenant nei timbri. Questo componente, a sua volta, potrebbe essere necessario rendere a disponibilità elevata.
• Componenti condivisi. Potrebbero essere presenti alcuni componenti che possono essere condivisi tra timbri. Ad esempio, se si dispone di un'app a pagina singola condivisa per tutti i tenant, è consigliabile distribuirla in un'area e usare Rete CDN di Azure per replicarla a livello globale.

Quando usare questo modello

Questo modello è utile quando si dispone di:

• Limiti naturali alla scalabilità. Ad esempio, se alcuni componenti non possono o non devono essere ridimensionati oltre un determinato numero di clienti o richieste, valutare la possibilità di aumentare il numero di istanze usando i francobolli.
• Requisito di separare determinati tenant da altri. Se si dispone di clienti che non possono essere distribuiti in un timbro multi-tenant con altri clienti a causa di problemi di sicurezza, possono essere distribuiti nel proprio timbro isolato.
• È necessario avere alcuni tenant in versioni diverse della soluzione contemporaneamente.
• Applicazioni in più aree in cui i dati e il traffico di ogni tenant devono essere indirizzati a un'area specifica.
• Desiderio di ottenere resilienza durante le interruzioni. Poiché i francobolli sono indipendenti l'uno dall'altro, se un'interruzione influisce su un singolo timbro, i tenant distribuiti in altri francobolli non devono essere interessati. Questo isolamento aiuta a contenere il "raggio di esplosione" di un incidente o un'interruzione del servizio.

Questo modello non è adatto per:

• Soluzioni semplici che non devono essere ridimensionate ad alto livello.
• Sistemi che possono essere facilmente ridimensionati o aumentati 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.
• Soluzioni in cui i dati devono essere replicati in tutte le istanze distribuite. Si consideri il modello geode per questo scenario.
• Soluzioni in cui è necessario ridimensionare solo alcuni componenti, ma non altri. Si consideri, ad esempio, se la soluzione può essere ridimensionata partizionando l'archivio dati anziché distribuendo una nuova copia di tutti i componenti della soluzione.
• Soluzioni costituite esclusivamente da contenuto statico, ad esempio un'applicazione JavaScript front-end. Prendere in considerazione l'archiviazione di tali contenuti in un account di archiviazione e l'uso di Rete CDN di Azure.

Progettazione del carico di lavoro

Un architetto deve valutare il modo in cui il modello Deployment Stamps può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:

Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.

Tecnologie di supporto

• Infrastruttura come codice. Ad esempio, Bicep, modelli di Resource Manager, interfaccia della riga di comando di Azure, Terraform, PowerShell, Bash.
• Frontdoor di Azure, che può instradare il traffico a uno stamp specifico o a un servizio di routing del traffico.

Esempio

Nell'esempio seguente vengono distribuiti più stamp di una semplice soluzione PaaS, con un servizio app e un database SQL in ogni timbro. Anche se i francobolli possono essere configurati in qualsiasi area che supporta i servizi distribuiti nel modello, a scopo illustrativo questo modello distribuisce due francobolli all'interno dell'area Stati Uniti occidentali 2 e un ulteriore timbro nell'area Europa occidentale. All'interno di un timbro, il servizio app riceve il proprio nome host DNS pubblico e può ricevere connessioni indipendentemente da tutti gli altri francobolli.

Fare clic sul collegamento seguente per distribuire la soluzione.

Esempio di approccio di routing del traffico

Nell'esempio seguente viene distribuita un'implementazione di una soluzione di routing del traffico che può essere usata con un set di stamp di distribuzione per un'applicazione API ipotetica. Per consentire la distribuzione geografica delle richieste in ingresso, Frontdoor viene distribuito insieme a più istanze di Gestione API nel livello di consumo. Ogni istanza di Gestione API legge l'ID tenant dall'URL della richiesta e quindi cerca il timbro pertinente per la richiesta da un archivio dati di Azure Cosmos DB distribuito geograficamente. La richiesta viene quindi inoltrata al timbro back-end pertinente.

Fare clic sul collegamento seguente per distribuire la soluzione.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• John Downs | Principal Program Manager

Altri contributori:

• Daniel Larsen | Principal Customer Engineer, FastTrack per Azure
• Angel Lopez | Senior Software Engineer, Modelli e procedure di Azure
• Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

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

Risorse correlate

• Il partizionamento orizzontale può essere usato come un altro approccio più semplice e semplice per aumentare il livello dati. Gli stamp partizionano in modo implicito i dati, ma il partizionamento orizzontale non richiede un timbro di distribuzione. Per altre informazioni, vedere il Modello di partizionamento orizzontale.
• Se viene distribuito un servizio di routing del traffico, i modelli di routing del gateway e offload del gateway possono essere usati insieme per sfruttare al meglio questo componente.