Dati per carichi di lavoro SaaS in Azure
Considerare i dati come asset più prezioso della soluzione. In qualità di fornitore di software indipendente (ISV), si è responsabili della gestione dei dati dei clienti. La strategia di progettazione dei dati e la scelta dell'archivio dati possono influire significativamente sui clienti.
Questo articolo fornisce indicazioni su come garantire l'integrità e la riservatezza dei dati per i clienti rispettando i requisiti di prestazioni aziendali. Vengono evidenziate le considerazioni chiave che consentono di raggiungere questi obiettivi in modo efficace.
Selezionare un archivio dati
L'archivio dati in una soluzione SaaS (Software as a Service) influisce sull'architettura, sulle prestazioni, sull'affidabilità e sulla complessità transazionale. Confrontare le funzionalità dei servizi gestiti di Azure con offerte non Microsoft simili. In alcune situazioni, è anche possibile considerare l'esecuzione di prodotti open source nelle macchine virtuali.
Considerazioni relative alla progettazione
Distinguere tra le operazioni transazionali e analitiche. Gli archivi dati transazionali sono progettati per supportare le applicazioni e gli archivi dati analitici vengono usati per la creazione di report e attività come Machine Learning. Questi negozi vengono creati con prodotti specializzati e hanno esigenze specifiche per prestazioni, modelli di accesso, schemi e casi d'uso.
Questa guida è incentrata sugli archivi dati transazionali.
Comprendere le esigenze dei dati. Stimare il volume, la frequenza con cui può cambiare e il tipo di dati da archiviare.
Prevedere un aumento significativo dei dati nel tempo. Per le soluzioni SaaS, la crescita si verifica in più dimensioni. Prevedere un aumento del volume e dei tipi di dati man mano che aumenta il numero di clienti. Assicurarsi di pianificare la crescita e investire in tecnologie che possano supportarla.
Scegliere tra una piattaforma dati relazionale o non relazionale in base alla natura dei dati. Per molti carichi di lavoro transazionali, un database relazionale è un'opzione valida per la modellazione delle entità dell'applicazione come tabelle discrete. Questo approccio consente alle query di operare nel modello di dati relazionale. In alternativa, se i dati si adattano naturalmente a un modello di documento o seguono una struttura a grafo, un approccio non relazionale potrebbe essere più adatto.
Per altre informazioni, vedere SQL e piattaforme dati NoSQL.
Ridurre al minimo i tipi di archivi dati. L'archiviazione di diversi tipi di dati in più archivi dati distinti può essere utile per le organizzazioni mature con competenze in diverse piattaforme dati. Tuttavia, questo approccio spesso introduce complessità non necessarie per le startup e le organizzazioni più piccole. È più efficace concentrarsi su uno o un numero ridotto di archivi dati.
Se non si ha la giustificazione aziendale per l'uso di più archivi dati, concentrarsi su uno o un numero ridotto di archivi dati.
Usa ciò che sai e investi in esso. Se il team ha già esperienza con un archivio dati specifico, è spesso preferibile usare tale archivio dati invece di investire in nuove competenze. Gli archivi dati e le piattaforme sono complessi e le decisioni di progettazione possono essere difficili da invertire.
Tuttavia, tenere presente la potenziale crescita. Se l'archivio dati corrente non soddisfa più i requisiti, scegliere un archivio dati in grado di migliorare le prestazioni, la resilienza, la sicurezza e l'efficienza operativa della soluzione. Dovrebbe anche aiutare il team ad approfondire le proprie competenze.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Separare gli archivi dati transazionali per le operazioni quotidiane dagli archivi dati analitici e di report. | La combinazione dell'intento degli archivi dati può causare una complessità non necessaria. La segmentazione dei dati migliora l'efficienza operativa e ottimizza l'utilizzo di ogni archivio dati. |
| Scegliere tra una struttura di dati relazionale o non relazionale in base ai requisiti. Iniziare con uno o un numero ridotto di archivi dati. Classificare in ordine di priorità gli archivi dati gestiti. Le scelte comuni includono Azure Cosmos DB, Azure SQL, MySQL, MongoDB e PostgreSQL. |
Questo approccio consente di ridurre al minimo la complessità e garantisce l'uso del prodotto corretto per ottimizzare l'efficienza. Gli archivi dati gestiti offrono flessibilità nella gestione delle risorse e dei costi in modo elastico e scalabilità in base alle esigenze. L'uso di archivi dati gestiti crea meno carico di gestione rispetto alla distribuzione di un archivio dati personalizzato nell'infrastruttura. |
| Investire nell'apprendimento della tecnologia scelta. Equipaggiare il team per gestire i requisiti di scalabilità elevata e altre complessità delle soluzioni SaaS. | Informazioni sugli strumenti usati e sul relativo ecosistema più ampio, in modo da poter usare in modo efficace la piattaforma dati durante la scalabilità. |
| Adottare flessibilità nella progettazione dei dati. | Man mano che la soluzione SaaS aumenta o cambiano i requisiti, è possibile adattarsi aggiungendo o modificando gli archivi dati. Questa flessibilità consente di iniziare con un archivio dati ed evolversi nel tempo per soddisfare le proprie esigenze. |
Modello di tenancy e strategia di database
Un aspetto chiave della progettazione dei dati è la decisione di ospitare risorse per conto dei clienti o di ospitare risorse nel proprio ambiente. La maggior parte dei provider SaaS ospita risorse per tutti i clienti, che offre flessibilità nella gestione dei database. Se si ospitano risorse nell'ambiente del cliente, prendere in considerazione il modo in cui si accede e si gestiscono tali risorse.
Considerazioni relative alla progettazione
Pianificare la segmentazione del database. Nelle soluzioni SaaS business-to-business (B2B) è consigliabile creare database dedicati per ogni cliente. Questo approccio migliora la sicurezza dei dati mantenendo un isolamento rigoroso tra i clienti, riducendo il rischio di combinare i dati e supportando le chiavi di crittografia gestite dal cliente. Consente anche di soddisfare i requisiti di conformità alle normative per alcuni clienti.
La separazione dei dati dei clienti in singoli database può migliorare le prestazioni riducendo al minimo i problemi dei vicini rumorosi. Alcuni archivi dati gestiti includono controlli di allocazione delle risorse per attenuare questi problemi, offrire efficienza dei costi e incorporare strumenti per la gestione di più database su larga scala.
In alcuni casi, è opportuno archiviare più dati dei clienti in un singolo archivio dati. Ad esempio, nelle soluzioni business-to-consumer (B2C), è possibile salvare i dati in un singolo archivio con partizionamento logico in base all'ID cliente. Nelle soluzioni B2B che condividono i componenti è possibile usare un singolo archivio dati per parti specifiche, ad esempio un archivio eventi, assicurandosi di includere gli ID cliente in ogni evento.
Collocare gli archivi dati con i componenti dell'applicazione. Se si ospitano risorse per conto del cliente, distribuire nella stessa area di Azure per evitare addebiti e latenza della larghezza di banda in uscita. Quando si ospitano applicazioni e archivi dati in un ambiente del cliente, distribuirli insieme nello stesso ambiente per evitare complessità tra ambienti.
Standardizzare la gestione dell'archivio dati come è pratico. L'uniformità è fondamentale per la gestione dei dati tra i clienti. Man mano che l'azienda cresce, le differenze tra i clienti aumentano i rischi e la complessità. Queste differenze possono anche rendere più probabili le interruzioni di produzione e la risoluzione dei problemi più difficile.
Evitare modifiche occasionali nella gestione per supportare singoli clienti. Ad esempio, per supportare i metadati gestiti dal cliente, evitare modifiche dello schema come l'aggiunta di colonne aggiuntive al database. Al contrario, creare funzionalità che consentono ai clienti di aggiungere i propri metadati. Analogamente, se è necessario fornire livelli diversi di prestazioni del database per clienti diversi, creare un unico processo che è possibile usare per applicare configurazioni diverse a livelli diversi di clienti.
Per altre informazioni sul modo in cui il modello di tenancy influisce sulla strategia dei dati, vedere.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Valutare se condividere i database tra più clienti o fornire una piattaforma dati condivisa. Distribuire un database singolo per i dati di ogni cliente, se appropriato. Ridurre questa strategia se l'isolamento rigoroso non è un requisito, ad esempio nelle soluzioni B2C. |
Questo approccio riduce al minimo i problemi del vicino rumoroso e può supportare i requisiti di conformità per alcuni clienti. |
| Distribuire le applicazioni e i relativi database nella stessa area. | Questo approccio ottimizza i costi e la latenza della larghezza di banda sostenuti dall'accesso al database tra aree. |
| Progettare un approccio standardizzato per l'archiviazione di dati o metadati definiti dal cliente. Evitare di modificare lo schema per singoli clienti o causare differenze tra gli ambienti dei clienti. | Questo approccio consente di evitare il carico operativo di gestione delle incoerenze tra i database per ogni cliente. |
| Pianificare le operazioni di manutenzione di routine nell'ambiente distribuito dal cliente. Pianificare l'accesso al database per aggiornamenti, modifiche dello schema, manutenzione e altre operazioni. |
Questo approccio proattivo riduce al minimo i problemi derivanti dalla mancanza di manutenzione e riduce il rischio di tempi di inattività e problemi di prestazioni. |
Pianificare la capacità
La pianificazione della capacità si riferisce alla gestione dell'utilizzo delle risorse, con particolare attenzione alle operazioni cpu, memoria, archiviazione e disco, ad esempio operazioni di input e output al secondo (IOPS). Alcuni archivi dati combinano queste risorse in una semplice metrica di consumo di risorse sintetiche, ad esempio un'unità di velocità effettiva del database (DTU) in AZURE SQL o un'unità richiesta (UR) in Azure Cosmos DB. Gli archivi dati gestiti offrono flessibilità nella gestione delle risorse, che consente modifiche nel tempo. È fondamentale stabilire un piano iniziale ed eseguire l'iterazione man mano che le esigenze si evolvono.
Considerazioni relative alla progettazione
Comprendere i requisiti di allocazione delle risorse. Clienti diversi nelle soluzioni SaaS potrebbero avere esigenze di risorse diverse. I clienti più piccoli potrebbero richiedere risorse minime e i clienti più grandi potrebbero avere bisogno di più. I clienti più grandi spesso pagano di più, che giustifica un'allocazione di risorse più elevata. Usando database separati per ogni cliente, è possibile modificare l'allocazione delle risorse in base alle dimensioni e alle esigenze.
Comprendere i diversi modelli di capacità offerti dalle piattaforme dati. Le piattaforme dati basate sul cloud spesso forniscono più modelli di risorse. Ad esempio, alcuni servizi di Azure, ad esempio Azure Cosmos DB, forniscono modelli basati sulla velocità effettiva e modelli serverless di cui è stato effettuato il provisioning. database SQL di Azure fornisce anche pool elastici.
La velocità effettiva con provisioning richiede l'allocazione predeterminata delle risorse, da un database singolo o da un gruppo di database. I pool elastici consentono la condivisione delle risorse tra più database. I pool elastici vengono comunemente usati nelle soluzioni SaaS.
Anche se la velocità effettiva con provisioning richiede di allocare le risorse in anticipo, i servizi come Azure Cosmos DB offrono velocità effettiva a scalabilità automatica. È possibile impostare regole per l'aggiunta o la rimozione dinamica delle risorse in base ai trigger specificati.
I modelli di risorse serverless vengono ridimensionati automaticamente in base alla richiesta. Questa funzionalità li rende un buon punto di partenza se non è possibile prevedere i requisiti di capacità in anticipo. Tuttavia, potrebbero supportare un minor numero di funzionalità e diventare inefficienti man mano che si aumentano. I modelli serverless sono disponibili in database SQL di Azure e Azure Cosmos DB.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Modellare i requisiti del database per ogni cliente. Determinare se è necessario avere molti database di piccole dimensioni, meno database di grandi dimensioni o una combinazione dei due. Usare un esercizio di ridimensionamento della t-shirt per classificare i clienti in bucket piccoli, medi e grandi. |
Questo approccio fornisce una stima approssimativa delle risorse necessarie per ogni cliente e consente di eseguire il mapping dei clienti al modello di fatturazione. |
| Segmentare i pool di risorse in base alle dimensioni dei database dei clienti che le usano. Usare la capacità di cui è stato effettuato il provisioning per sfruttare i vantaggi. Ad esempio, è possibile creare un pool elastico SQL condiviso per i clienti più piccoli, un pool separato per i clienti medi e risorse dedicate per clienti di grandi dimensioni. |
Segmentando i pool di risorse in base alle dimensioni del database dei clienti, è possibile ottimizzare l'allocazione delle risorse e l'efficienza dei costi. |
| Sfruttare le funzionalità di scalabilità predefinite offerte dai servizi gestiti. | È possibile eseguire l'offload delle responsabilità di ridimensionamento nella piattaforma. Le funzionalità come i pool elastici e la scalabilità automatica consentono di ottimizzare l'uso delle risorse. |
| Esaminare regolarmente gli archivi dati serverless per assicurarsi che continuino a soddisfare le proprie esigenze. | È possibile assicurarsi che l'archivio dati rimanga efficace con le esigenze in continua evoluzione. Ottimizzare le prestazioni e l'efficienza dei costi man mano che cambiano i requisiti. |
Disponibilità elevata e ripristino di emergenza
I clienti delle soluzioni SaaS spesso hanno aspettative elevate per la disponibilità elevata e il ripristino di emergenza. Se i clienti operano in settori regolamentati o si affidano alla soluzione per le operazioni quotidiane, i requisiti potrebbero essere ancora più rigorosi.
Disponibilità elevata e ripristino di emergenza non sono soluzioni adatte a tutte le dimensioni e dipendono da vari fattori. Avere una chiara comprensione delle opzioni disponibili applicabili sia all'utente che ai requisiti dei clienti per prendere decisioni informate sulla mitigazione dei diversi rischi.
Compromesso: affidabilità, costi e prestazioni: la resilienza per i servizi dati spesso richiede la distribuzione di repliche o copie dei dati in un'area geografica più ampia per ridurre i rischi. Tuttavia, ci sono compromessi. Maggiore è la distanza che i dati devono percorrere, maggiore è la protezione rispetto agli errori localizzati. Tuttavia, la copia dei dati tra distanze più lunghe aumenta la latenza e spesso costa di più. Molti archivi dati gestiti forniscono la replica automatica dei dati, ma potrebbero imporre limiti ai tipi di replica che è possibile eseguire in diverse distanze per mantenere le prestazioni.
Considerazioni relative alla progettazione
Quantificare la resilienza. Misurare i requisiti di resilienza usando gli obiettivi a livello di servizio, che includono metriche come tempo di attività, tempo di ripristino e punto di ripristino. Queste metriche sono guidate sia dai requisiti aziendali che da quelli dei clienti, che possono avere esigenze diverse. Se si archiviano grandi quantità di dati per conto dei clienti, la soluzione a disponibilità elevata e ripristino di emergenza potrebbe essere più complessa per soddisfare requisiti rigorosi.
Per altre informazioni sulle metriche di resilienza, vedere RE:04 Recommendations for defining reliability targets (Raccomandazioni RE:04 per la definizione di destinazioni di affidabilità).
Usare le funzionalità della piattaforma. Azure offre funzionalità per la resilienza all'interno di un data center, all'interno di un'area geografica usando zone di disponibilità e in un'area geografica più ampia usando più aree. Combinare strategie come zone di disponibilità, backup tra aree e distribuzioni con più aree per ottenere il livello di resilienza appropriato per la soluzione. Per i requisiti di resilienza elevata, prendere in considerazione un'architettura multiregione attiva-passiva con replica asincrona dei dati tra aree. Questo approccio potrebbe comportare una perdita di dati durante un'interruzione irreversibile.
Compromesso: le progettazioni attive e attive con replica sono le più resilienti, ma sono complesse da compilare e testare. Per la maggior parte delle soluzioni attive, è necessario progettare un approccio di risoluzione dei conflitti che causa ritardi nella sincronizzazione dei dati. La maggior parte delle soluzioni non richiede questo grado di resilienza.Fare riferimento a RE:05 Recommendations for using availability zones and regions (Consigli su RE:05 per l'uso di zone e aree di disponibilità).
Usare i timbri di distribuzione per isolare il raggio di esplosione dei componenti. Il modello di stamp di distribuzione è ampiamente usato nelle soluzioni SaaS perché offre vantaggi per la distribuzione, la gestione, le prestazioni e la resilienza. Ad esempio, la distribuzione di un timbro nel Stati Uniti e un altro timbro in Europa garantisce che i clienti in un'area siano isolati dalle interruzioni nell'altra area e possano operare in modo indipendente.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Concentrarsi sui requisiti di resilienza mentre si pensa ai requisiti generali dei dati per i clienti e gli utenti. | Fondando le decisioni di progettazione in questi requisiti, è possibile assicurarsi di prendere i compromessi appropriati ed evitare sotto-o sovraprogetti per le proprie esigenze. |
| Riflettere i diversi livelli di resilienza nel modello di fatturazione. Impostare le aspettative con i clienti. Una perdita di dati pari a zero durante interruzioni irreversibili o il tempo di attività del 100% potrebbe non essere realistico. |
I modelli di fatturazione possono aiutare i clienti a comprendere la quantità di resilienza garantita per cui si stanno iscrivendo. Ad esempio, con un livello inferiore, i clienti ottengono garanzie minime. In un livello superiore, i clienti ricevono una maggiore resilienza perché è possibile permettersi di replicare le risorse in più aree. |
| Usare le zone di disponibilità di Azure per le soluzioni di produzione. Quando possibile, usare archivi dati con ridondanza della zona. | Le zone di disponibilità offrono resilienza in caso di interruzioni del data center, senza aumentare significativamente il costo, la latenza o la complessità della soluzione. |
| Mantenere i backup degli archivi dati in un formato con ridondanza globale usando la replica tra aree, se disponibile. | I backup tra aree dei dati aggiungono un livello aggiuntivo di resilienza. |
| Usare i francobolli di distribuzione per creare istanze separate della soluzione in posizioni geograficamente distribuite. | Usando indicatori di distribuzione per creare istanze separate della soluzione in posizioni distribuite geograficamente, è possibile aumentare la resilienza e offrire maggiori vantaggi, ad esempio una gestione più semplice delle operazioni. |
| Valutare se è necessaria la distribuzione di più aree e se è necessaria una progettazione attiva-attiva per soddisfare i requisiti. Considerare i compromessi coinvolti. I componenti senza stato sono più facili da replicare rispetto a componenti con stato come un archivio dati. |
La distribuzione della soluzione o dei francobolli tra aree offre livelli di resilienza più elevati replicando i dati tra aree. |
Sicurezza e conformità
L'utente è responsabile di garantire la riservatezza e l'integrità dei dati dei clienti. Quando si crea una baseline di sicurezza, prendere in considerazione i requisiti di sicurezza e le promesse. Pianificare la conformità dei clienti, inclusa la conservazione dei dati.
Considerazioni relative alla progettazione
Rete: prendere in considerazione chi accederà all'archivio dati. In genere, solo l'applicazione richiede la comunicazione diretta, quindi configurarla per la rete privata.
Identità: valutare la modalità di accesso degli archivi dati. Molte soluzioni SaaS usano una singola identità dell'applicazione per tutti gli archivi dati, con il livello applicazione che applica l'isolamento e l'autorizzazione. Per la sicurezza a livello di riga o l'autorizzazione a livello di database, potrebbe essere necessario propagare l'identità dell'utente all'archivio dati, che è complesso in un ambiente multi-tenant.
Conservazione dei dati: pianificare in anticipo i criteri di conservazione dei dati. La gestione di più dati aumenta i costi di archiviazione e la complessità di gestione. Ad esempio, grandi quantità di dati in un database transazionale possono complicare l'esecuzione di query e il troncamento dei processi.
Per la conservazione dei dati a lungo termine, ad esempio per le analisi di conformità o future, è consigliabile rilocare i dati in un archivio adatto per la conservazione a lungo termine.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Configurare gli archivi dati per l'uso di endpoint privati e disabilitare gli endpoint pubblici. | Questo approccio migliora la sicurezza limitando l'accesso alla rete interna. Limitando l'accesso, è possibile ridurre il rischio di accessi non autorizzati e potenziali violazioni dei dati. |
| Usare le identità gestite e l'ID Microsoft Entra per l'autenticazione. Evitare l'uso di chiavi o credenziali del database. | Le identità gestite eliminano la necessità di chiavi o credenziali del database, riducendo il rischio di furto di credenziali e semplificando la gestione degli accessi. |
Quando si utilizzano archivi dati condivisi, assicurarsi che l'applicazione includa tutte le richieste a un singolo tenant includendo l'identificatore del tenant nelle WHERE clausole. |
Questo processo consente di ridurre il rischio di perdita o rappresentazione dei dati tra tenant. |
| Pianificare la strategia di conservazione dei dati in base alle esigenze aziendali e di conformità. Evitare di mantenere dati cronologici non necessari. Per la conservazione a lungo termine, spostare i dati dagli archivi primari all'archiviazione. | Evitando la conservazione non necessaria, si mantiene una superficie di attacco più piccola. |
| Usare le funzionalità dell'archivio dati per supportare le esigenze del ciclo di vita dei dati. In Azure Cosmos DB impostare la durata dei documenti. In Azure SQL implementare una strategia di finestra scorrevole usando il partizionamento delle tabelle per ridurre al minimo l'impatto del processo di archiviazione nel database. |
Questi approcci garantiscono una gestione efficiente del ciclo di vita dei dati, ottimizzano l'archiviazione o l'eliminazione di dati obsoleti e riducono l'intervento manuale quando possibile. |
Operazioni
Le soluzioni SaaS includono spesso un numero elevato di database o altri archivi. È importante pianificare la manutenzione di routine nella flotta ed esplorare le opzioni di automazione per gestire queste attività in modo efficiente.
Considerazioni relative alla progettazione
Comprendere le funzionalità del team. Se non si hanno team di grandi dimensioni di amministratori di database che possono eseguire analisi dettagliate sui database dei singoli clienti, pianificare l'esecuzione di operazioni su larga scala e usare gli strumenti della piattaforma quando possibile.
Pianificare le normali procedure di manutenzione. Elencare le normali operazioni di manutenzione necessarie e la relativa frequenza. Le operazioni specifiche variano in base al tipo di archivio dati usato. Ad esempio:
- Monitorare la quantità totale di dati e dati che si trovano in entità specifiche, ad esempio tabelle importanti.
- Ricompilare gli indici.
- Creare o rimuovere indici in base alla modifica dei modelli di query.
- Ribilanciare le partizioni.
Esplorare le funzionalità della piattaforma che consentono di eseguire regolarmente la manutenzione e cercare in modo proattivo nuovi problemi. Ad esempio, database SQL Advisor in database SQL di Azure monitora la ricerca di problemi.
Progettare per l'automazione. Le operazioni automatizzate sono essenziali per una soluzione SaaS per la scalabilità efficace. Identificare attività regolari e occasionali e creare playbook o script di automazione per loro. Per le attività che non è possibile automatizzare immediatamente, documentare accuratamente i processi per garantire coerenza e chiarezza.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Cercare la coerenza tra gli archivi dati dei clienti, quando possibile. Se un cliente richiede alloggi speciali, integrarli in un processo complessivo anziché personalizzare la configurazione per tale cliente. Ad esempio, usare lo stesso schema per ogni database e usare gli stessi processi per distribuire e gestire le risorse. |
La coerenza semplifica l'esecuzione di modifiche su larga scala e riduce al minimo il rischio di problemi accidentali durante le distribuzioni o le procedure di manutenzione. |
| Distribuire con attenzione risorse limitate e cercare opportunità per semplificare le operazioni. | È possibile evitare piccole efficienze e migliorare l'utilizzo delle risorse e le prestazioni complessive. |
| Creare automazione per attività ripetitive. Scegliere di acquistare strumenti automatizzati invece di creare una soluzione personalizzata. Esplorare le opzioni fornite dalla piattaforma e dai fornitori non Microsoft. |
Investendo nell'automazione della qualità, è possibile usare ripetutamente questi asset e ridurre le attività manuali spesso soggette a errori. Gli strumenti automatizzati sono utili se non si è esperti nell'archivio dati in uso o se non si è certi delle attività di manutenzione necessarie. |
| Distribuire attentamente la capacità di amministrazione del database del team. Riservare amministratori di database umani per le attività più interessate, ad esempio la gestione di clienti di grandi dimensioni o la creazione di automazione che può essere ridimensionata in molti clienti. | Assegnando priorità alle funzioni preziose, è possibile ottimizzare l'efficienza. |
Accesso dei clienti ai dati
Alcuni clienti potrebbero richiedere l'accesso diretto ai dati per report o analisi personalizzati. Valutare attentamente come i clienti possono accedere ai dati nella soluzione e se concedere queste richieste o fornire metodi alternativi per soddisfare le proprie esigenze.
Considerazioni relative alla progettazione
Giustifica i motivi per l'accesso diretto. Comprendere perché i clienti devono accedere ai dati non elaborati ottenendo informazioni sul problema aziendale. Collaborare per trovare una soluzione che soddisfi le proprie esigenze senza introdurre rischi per la piattaforma.
Trovare modi alternativi per soddisfare i requisiti anziché concedere l'accesso diretto. Se l'accesso è necessario per la creazione di report, è preferibile adottare approcci a livello di applicazione. Ad esempio, è possibile creare report per tali report usando Microsoft Power BI oppure esportare un subset di dati in un file fornito. È anche possibile creare API che possono usare per accedere ai dati.
Valutare le implicazioni relative alla sicurezza e all'isolamento. L'accesso diretto a un archivio dati comporta rischi significativi per la sicurezza. Evitare di esporre risorse interne a parti esterne, inclusi i clienti. In un ambiente SaaS con molti clienti che condividono una soluzione, i rischi sono ancora più elevati perché l'ambiente può essere sfruttato per accedere ai dati di altri clienti.
Valutare la possibilità di fornire ai clienti l'accesso ai dati in modo sicuro e isolato che non influisce sul sistema di produzione e consente di apportare modifiche alla progettazione interna del database senza interrompere le query dei clienti.
Prendere in considerazione l'effetto sulle prestazioni. Consentire l'accesso diretto all'archivio dati transazionale può causare problemi di prestazioni per l'applicazione principale. Ad esempio, un cliente potrebbe eseguire una query a elevato utilizzo di risorse che interrompe le funzionalità dell'applicazione.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Evitare di concedere l'accesso diretto agli archivi dati. Se è necessario concedere l'accesso diretto, fornire l'accesso a una replica di sola lettura, se la piattaforma dati la supporta. |
Gli approcci a livello di applicazione consentono di controllare il modo in cui i clienti usano i dati. Se non è possibile creare costrutti a livello di applicazione, l'accesso tramite repliche di sola lettura riduce il carico delle query del cliente sulle operazioni. |
| Evitare di esporre i dettagli dell'implementazione interna. | Controllando l'accesso alle strutture di dati, si impedisce ai clienti di fare ipotesi sulla funzionalità dello schema del database. Questa flessibilità consente di evolvere e ottimizzare la struttura del database nel tempo senza vincoli di strumenti creati dal cliente o presupposti imprecisi. |
Risorse aggiuntive
La multi-tenancy è una metodologia aziendale di base per la progettazione di carichi di lavoro SaaS. Questi articoli forniscono altre informazioni sulle considerazioni sulla progettazione dei dati:
- Approcci architetturali per una soluzione multi-tenant
- Approcci architetturali per l'archiviazione e i dati in soluzioni multi-tenant
- Approcci architetturali per l'integrazione dei tenant e l'accesso ai dati
- Modelli di tenancy
Passaggio successivo
Informazioni sulle considerazioni su DevOps per i carichi di lavoro SaaS, tra cui procedure efficienti per la gestione del ciclo di vita dei clienti e procedure di distribuzione sicure.