Architektonické přístupy pro úložiště a data ve víceklientské řešení
Při plánování klientských úložišť nebo datových komponent se musíte rozhodnout pro přístup ke sdílení nebo izolaci dat klientů. Data se často považují za nejvíc užitečnou součást řešení, protože představují cenné firemní informace pro vaše zákazníky. Proto je důležité pečlivě naplánovat přístup, který používáte ke správě dat ve víceklientském prostředí. Na této stránce poskytujeme pokyny pro klíčové úvahy a požadavky, které je potřeba vzít v úvahu při rozhodování o přístupu k ukládání dat ve víceklientském systému. Pak navrhneme některé běžné vzory pro použití víceklientské architektury do úložiště a datových služeb a některé antipatterny se vyhnete. Nakonec poskytujeme cílené pokyny pro některé konkrétní situace.
Klíčové doporučení a požadavky
Je důležité vzít v úvahu přístupy, které používáte pro úložiště a datové služby z řady perspektiv, které se přibližně rovnají sloupkům Azure Well-Architected Framework.
Měřítko
Při práci se službami, které ukládají vaše data, byste měli zvážit počet klientů, které máte, a objem dat, která ukládáte. Pokud máte malý počet klientů (například pět nebo méně) a ukládáte pro každého tenanta malé objemy dat, bude se pravděpodobně jednat o vyřazení vysoce škálovatelného přístupu k úložišti dat nebo k vytvoření plně automatizovaného přístupu ke správě vašich datových prostředků. Při růstu budete mít stále větší výhodu, abyste měli jasnou strategii pro škálování vašich dat a prostředků úložiště a aby se na jejich správě využila automatizace. Pokud máte klienty 50 nebo více, nebo pokud plánujete dosáhnout této úrovně škálování, je obzvláště důležité navrhnout svůj přístup k datům a úložišti s možností škálování jako klíčový ohled.
Vezměte v úvahu rozsah, ve kterém plánujete škálovat, a jasně Naplánujte přístup k architektuře datových úložišť, abyste splnili tuto úroveň škálování.
Předvídatelnost výkonu
Víceklientská data a služby úložiště jsou obzvláště náchylné k problému s vysokou dostupností sousedů. Je důležité vzít v úvahu, jestli by vaši klienti mohli ovlivnit výkon každého druhého. Například klienti mají v průběhu času překrývat špičky ve svých vzorcích použití? Používají všichni vaši zákazníci vaše řešení ve stejnou dobu každý den, nebo jsou požadavky distribuované rovnoměrně? Tyto faktory budou mít vliv na úroveň izolace, kterou potřebujete navrhnout, množství prostředků, které potřebujete zřídit, a stupeň, ve kterém se prostředky můžou sdílet mezi klienty.
V rámci tohoto rozhodnutí je důležité vzít v úvahu kvóty prostředků a požadavků Azure . Předpokládejme například, že nasadíte jeden účet úložiště, který bude obsahovat všechna data vašich tenantů. pokud překročíte určitý počet operací úložiště za sekundu, Azure Storage odmítnou žádosti vaší aplikace a budou mít vliv na všechny vaše klienty. To se označuje jako chování omezování . Je důležité monitorovat omezené požadavky. Další informace najdete v pokynech k opakování pro služby Azure .
Izolace dat
Při navrhování řešení, které obsahuje víceklientské datové služby, jsou obvykle různé možnosti a úrovně izolace dat, z nichž každá má své výhody a kompromisy. Příklad:
- při použití Azure Cosmos DB můžete nasadit samostatné kontejnery pro každého tenanta a můžete sdílet databáze a účty mezi více klienty. Alternativně můžete zvážit nasazení různých databází nebo dokonce účtů pro každého tenanta v závislosti na požadované úrovni izolace.
- při použití Azure Storage pro data objektů blob můžete pro každého tenanta nasadit samostatné kontejnery objektů blob, nebo můžete nasadit samostatné účty úložiště.
- při použití SQL Azure můžete použít samostatné tabulky ve sdílených databázích nebo můžete pro každého tenanta nasadit samostatné databáze nebo servery.
- Ve všech službách Azure můžete zvážit nasazení prostředků v rámci jednoho sdíleného předplatného Azure nebo můžete použít několik předplatných Azure – případně i jednu pro každého tenanta.
Neexistuje žádné jediné řešení, které by bylo pro každou situaci fungovat. Možnost, kterou zvolíte, závisí na několika faktorech a požadavcích klientů. Pokud například vaši klienti potřebují splnit konkrétní dodržování předpisů nebo regulativní normy, možná budete muset použít vyšší úroveň izolace. Podobně můžete mít k dispozici komerční požadavky na fyzickou izolaci dat vašich zákazníků, nebo možná budete muset vyhovět izolaci, abyste se vyhnuli problému s okolním sousedem. Pokud navíc klienti potřebují používat vlastní šifrovací klíče, mají individuální zásady zálohování a obnovení nebo potřebují data ukládat v různých geografických umístěních, možná je budete muset izolovat od ostatních tenantů nebo je seskupit s klienty, kteří mají podobné zásady.
Složitost implementace
Je důležité vzít v úvahu složitost vaší implementace. Dobrým zvykem je udržet svoji architekturu co nejjednodušší, a přitom stále doplněním vašich požadavků. Vyhněte se potvrzování architektury, která bude při škálování stále složitá, nebo architektury, kterou nemáte prostředky nebo odborné znalosti pro vývoj a údržbu.
Podobně platí, že pokud vaše řešení nemusí škálovat na velký počet klientů, nebo pokud nemáte obavy o výkon nebo izolaci dat, je lepší udržet vaše řešení snadno a vyhnout se zbytečné složitosti.
Konkrétní pozornost pro víceklientské řešení dat je úroveň přizpůsobení, které podporujete. Může například klient nastavovat datový model nebo použít pravidla pro vlastní data? Ujistěte se, že navrhujete tuto frontu. Vyhněte se rozvětvení nebo poskytování vlastní infrastruktury pro jednotlivé klienty, protože to brání vaší schopnosti škálovat, testovat vaše řešení a nasazovat aktualizace. Místo toho zvažte použití příznaků funkcí a dalších forem konfigurace klienta.
Složitost správy a operací
Vezměte v úvahu, jak plánujete provozovat vaše řešení a jak má vaše víceklientská přístup ovlivnit vaše operace a procesy. Příklad:
- Uvažujte o operacích správy mezi klienty, jako jsou třeba běžné aktivity údržby. Pokud používáte více účtů, serverů nebo databází, jak budete spouštět a monitorovat operace pro každého tenanta?
- Pokud monitorujte nebo měříte klienty, vezměte v úvahu, jak vaše řešení oznamuje metriky a jestli je možné je snadno propojit s klientem, který požadavek vyvolal.
- Vytváření sestav dat z různých izolovaných klientů může vyžadovat, aby každý tenant publikoval data do centralizovaného datového skladu, a ne postupně spouštět dotazy na každou databázi a pak agregovat výsledky.
- Pokud použijete databázi, která vynutila schéma, naplánujte, jak budete nasazovat aktualizace schématu napříč vaší nemovitosti. Vezměte v úvahu, jak vaše aplikace ví, která verze schématu se má použít pro databázové dotazy konkrétního tenanta.
- Vezměte v úvahu požadavky na vysokou dostupnost klientů (například smlouvy o úrovni služeb v provozu nebo SLA) a požadavky na zotavení po havárii (například cíle pro čas obnovení nebo RTO a cíle bodu obnovení nebo RPO). Pokud mají klienti odlišná očekávání, budete moct uspokojit požadavky jednotlivých tenantů.
- Jak budete migrovat klienty, pokud je potřeba přesunout na jiný typ služby, jiné nasazení nebo jinou oblast?
Náklady
Obecně platí, že čím vyšší je hustota klientů s infrastrukturou nasazení, tím se sníží náklady na zřízení této infrastruktury. Sdílená infrastruktura ale zvyšuje pravděpodobnost problémů, jako je problém s hlučným sousedním směrovačem, takže pečlivě zvažte kompromisy.
Přístupy a vzory, které je třeba zvážit
Několik vzorů návrhu z Cetrum architektury Azure má význam pro Mulitenant úložiště a datové služby. Můžete se rozhodnout, že budete konzistentně postupovat podle jednoho vzoru. Nebo můžete zvážit smíchání a srovnávací vzory. Můžete například použít víceklientské databáze pro většinu klientů, ale pro klienty nasaďte pouze časová razítka, která platí více nebo mají neobvyklé požadavky. Podobně je často vhodné škálovat pomocí razítek nasazení, a to i v případě, že používáte víceklientské databáze nebo horizontálně dělené databáze v rámci razítka.
Vzor razítek nasazení
Vzor razítek nasazení zahrnuje nasazení vyhrazené infrastruktury pro tenanta nebo skupinu klientů. Jedno razítko může obsahovat více tenantů nebo může být vyhrazeno jednomu klientovi.
Pokud používáte razítka s jedním klienty, vzor razítka nasazení by měl být jednoduše implementován, protože každé razítko je pravděpodobně bez ohledu na jiné, takže do aplikační vrstvy nemusíte zabudovány žádné logiky víceklientské architektury ani funkce. Pokud má každý tenant vlastní vyhrazené razítko, tento model poskytuje nejvyšší úroveň izolace a snižuje riziko problému s okolními sousednímipočítači. Nabízí taky možnost nakonfigurovat nebo přizpůsobit klienty podle jejich vlastních požadavků, jako je například umístění v konkrétní geopolitické oblasti nebo konkrétní požadavky na vysokou dostupnost.
Při použití razítek s více klienty je potřeba vzít v úvahu jiné způsoby, jak spravovat víceklientské prostředí v rámci razítka, a problém s okolním sousedním problémem je dál možné použít. Pomocí vzoru razítka nasazení ale můžete zajistit, aby se při zvětšování řešení mohli dál škálovat.
Největší problém se vzorem razítka nasazení, pokud se používá k obsluze jednoho tenanta, představuje náklady na infrastrukturu. Pokud používáte razítka s jedním klienty, musí mít každé razítko svou vlastní samostatnou sadu infrastruktury, která není sdílená s ostatními klienty. Také je potřeba zajistit, aby prostředky nasazené pro razítko splňovaly zatížení ve špičce pro zatížení tohoto tenanta. Ujistěte se, že cenový model kompenzuje náklady na nasazení infrastruktury tenanta.
Razítka s jedním klientem často fungují dobře, když máte malý počet klientů. Vzhledem k tomu, že váš počet klientů roste, je možné, ale stále ještě obtížné spravovat loďstva razítek (Viz Tato případová studie jako příklad). Můžete také použít vzor razítka nasazení a vytvořit loďstva pro víceklientská razítka, která můžou poskytovat výhody pro sdílení prostředků a nákladů.
Chcete-li implementovat vzor razítek pro nasazení, je důležité použít přístupy k automatizovanému nasazení. V závislosti na strategii nasazení můžete zvážit správu razítek v rámci kanálů nasazení pomocí deklarativní infrastruktury jako kódu, například bicep, šablon ARM nebo šablon Terraformu. Alternativně můžete zvážit sestavení vlastního kódu pro nasazení a správu každého razítka, například pomocí sad Azure SDK.
Sdílené databáze s více klienty a úložiště souborů
Můžete zvážit nasazení sdílené víceklientské databáze, účtu úložiště nebo sdílené složky a jejich sdílení napříč všemi vašimi klienty.
Tento přístup poskytuje nejvyšší hustotu tenantů pro infrastrukturu, takže je v dosahu nejnižších nákladů na jakýkoliv přístup. Také často snižuje režijní náklady na správu, protože existuje jedna databáze nebo prostředek pro správu, zálohování a zabezpečení.
Pokud však pracujete se sdílenou infrastrukturou, je třeba zvážit několik aspektů:
- Pokud spoléháte na jeden prostředek, zvažte podporované škálování a omezení tohoto prostředku. Například maximální velikost jedné databáze nebo úložiště souborů nebo maximálních limitů propustnosti se nakonec stane pevným blokováním, pokud vaše architektura spoléhá na izolovanou databázi. Před výběrem tohoto modelu pečlivě zvažte maximální měřítko, které potřebujete, a porovnejte je s aktuálním a budoucím omezením.
- Problém s hlučným sousedním směrovačem se může stát faktorem, zejména pokud máte klienty, kteří jsou zvláště zaneprázdněni nebo generují vyšší zatížení než jiné. Zvážení použití vzoru omezení nebo vzorce omezení četnosti pro zmírnění těchto účinků.
- Můžete mít problémy s monitorováním aktivity a měřením spotřeby pro jednoho tenanta. některé služby, například Azure Cosmos DB, poskytují hlášení o využití prostředků u jednotlivých požadavků, takže tyto informace je možné sledovat pro měření spotřeby pro každého tenanta. Jiné služby neposkytují stejnou úroveň podrobností. Například metriky souborů Azure pro kapacitu souborů jsou k dispozici pro každou dimenzi sdílení souborů, jenom když použijete sdílené složky Premium. Úroveň Standard ale poskytuje metriky jenom na úrovni účtu úložiště.
- Klienti mohou mít různé požadavky na zabezpečení, zálohování, dostupnost nebo umístění úložiště. Pokud se neshodují s konfigurací jednoho prostředku, možná je nebudete moct přizpůsobit.
- Při práci s relační databází nebo jiné situaci, kdy je důležité schéma dat, je přizpůsobení schématu na úrovni tenanta obtížné.
Model horizontálního dělení
Vzor horizontálního dělení zahrnuje nasazení několika samostatných databází s názvem horizontálních oddílů, které obsahují jednu nebo více dat tenantů. Na rozdíl od razítek nasazení horizontálních oddílů neznamená, že celá infrastruktura je duplicitní. Databáze můžete horizontálních oddílů bez duplikování nebo horizontálního dělení jiné infrastruktury ve vašem řešení.
Horizontálního dělení je úzce spojený s vytvářením oddílů a tyto výrazy jsou často používány vzájemně zaměnitelné. Vezměte v úvahu pokyny pro dělení horizontálních, svislých a funkčních dat.
Vzor horizontálního dělení se může škálovat na velmi velký počet klientů. V závislosti na vašich úlohách možná budete moci dosáhnout vysoké hustoty tenantů horizontálních oddílů, takže náklady mohou být atraktivní. Vzor horizontálního dělení se taky dá použít k adresování kvót a limitů a omezení předplatného a služeb Azure.
některá úložiště dat, například Azure Cosmos DB, poskytují nativní podporu pro horizontálního dělení nebo vytváření oddílů. Když pracujete s jinými řešeními, jako je například Azure SQL, může být složitější vytvořit infrastrukturu horizontálního dělení a směrovat požadavky na správné horizontálních oddílů pro daného tenanta.
Víceklientské aplikace s vyhrazenými databázemi pro každého tenanta
Dalším běžným přístupem je nasazení jedné víceklientské aplikace s vyhrazenými databázemi pro každého tenanta.
V tomto modelu jsou data každého tenanta izolovaná od ostatních a je možné, že budete pro každého tenanta podporovat určitý stupeň přizpůsobení.
Vzhledem k tomu, že zřizujete vyhrazené datové prostředky pro každého tenanta, je možné, že náklady na tento přístup budou vyšší než sdílené hostující modely. Azure ale nabízí několik možností, které můžete vzít v úvahu, aby bylo možné sdílet náklady na hostování jednotlivých datových prostředků napříč více klienty. například při práci s Azure SQL můžete zvážit elastické fondy. pro Azure Cosmos DB můžete zřídit propustnost pro databázi a propustnost se sdílí mezi kontejnery v této databázi, i když tento přístup není vhodný, pokud pro každý kontejner potřebujete zaručený výkon.
Vzhledem k tomu, že se v tomto přístupu nasazují jenom datové součásti pro každého tenanta, pravděpodobně můžete dosáhnout vysoké hustoty pro ostatní komponenty v řešení a snížit náklady na tyto komponenty.
Při zřizování databází pro každého tenanta je důležité použít přístupy k automatizovanému nasazení.
Vzor Geodes
Vzor Geode je navržený speciálně pro geograficky distribuovaná řešení, včetně víceklientské řešení. Podporuje vysoké zatížení a vysokou úroveň odolnosti. Při práci se vzorem Geode musí mít Datová vrstva schopnost replikovat data napříč geografickými oblastmi a měla by podporovat multi-geografické zápisy.
Azure Cosmos DB poskytuje více hlavních zápisů pro podporu tohoto modelu a Cassandra podporuje clustery ve více oblastech. Jiné datové služby obecně nejsou schopné tento model podporovat bez významného přizpůsobení.
Antipatterny k zamezení
Při práci s víceklientské datové služby je důležité se vyhnout situacím, které znemožňují možnost škálování.
V případě relačních databází patří mezi ně:
- Izolace na základě tabulky. Když pracujete v rámci izolované databáze, vyhněte se vytváření jednotlivých tabulek pro každého tenanta. Jediná databáze nebude moct při použití tohoto přístupu podporovat velký počet klientů a je tak stále obtížné dotazovat, spravovat a aktualizovat data. Místo toho zvažte použití jedné sady víceklientské tabulky se sloupcem identifikátoru tenanta. Alternativně můžete použít jeden z výše uvedených vzorů k nasazení samostatných databází pro každého klienta.
- Přizpůsobení klienta na úrovni sloupce. Vyhněte se použití aktualizací schématu, které se vztahují pouze na jednoho tenanta. Předpokládejme například, že máte jednu víceklientské databáze. Vyhněte se přidání nového sloupce pro splnění požadavků konkrétního tenanta. Může být přijatelné pro malý počet úprav, ale tato možnost se rychle přestanou spravovat, když máte velký počet úprav, které byste měli zvážit. Místo toho zvažte revizi datového modelu a sledujte vlastní data pro každého tenanta ve vyhrazené tabulce.
- Ruční změny schématu. Neaktualizujte schéma databáze ručně, a to i v případě, že máte jenom jednu sdílenou databázi. Je snadno možné sledovat aktualizace, které jste použili, a pokud potřebujete horizontální navýšení kapacity na více databází, je obtížné identifikovat správné schéma, které se má použít. Místo toho Sestavte automatizovaný kanál pro nasazení změn schématu a používejte ho konzistentně. Sledujte verzi schématu použitou pro každého tenanta ve vyhrazené databázi nebo vyhledávací tabulce.
- Závislosti verzí. Vyhněte se tomu, aby vaše aplikace převzala závislost na jediné verzi schématu databáze. Při škálování možná budete muset pro různé klienty použít aktualizace schématu v různých časech. Místo toho se ujistěte, že je verze vaší aplikace zpětně kompatibilní s minimálně jednou verzí schématu a nepoužívejte destruktivní aktualizace schématu.
Databáze
K dispozici jsou některé funkce, které můžou být užitečné pro víceklientské využití. Nejsou však k dispozici ve všech databázových službách. Zvažte, jestli je potřebujete, pokud se rozhodnete pro službu, která se má použít pro váš scénář:
- Zabezpečení na úrovni řádků může poskytovat izolaci zabezpečení pro konkrétní data klientů ve sdílené víceklientské databázi. tato funkce je k dispozici v Azure SQL a Postgres Flex, ale není dostupná v jiných databázích, jako je MySQL nebo Azure Cosmos DB.
- K podpoře klientů, kteří pro svá data poskytují vlastní šifrovací klíče, může být vyžadováno šifrování na úrovni tenanta . tato funkce je k dispozici v Azure SQL jako součást Always Encrypted. Cosmos DB poskytuje klíče spravované zákazníkem na úrovni účtu a také podporuje Always Encrypted.
- Sdružování prostředků nabízí možnost sdílet prostředky a náklady mezi více databázemi nebo kontejnery. tato funkce je dostupná v elastických fondech Azure SQL a spravovaných instancích a v propustnosti databázeAzure Cosmos DB, i když každá z možností má omezení, o kterých byste měli vědět.
- Horizontálního dělení a vytváření oddílů má silnější nativní podporu některých služeb než jiné. tato funkce je k dispozici v Azure Cosmos DB s využitím logických a fyzických oddílůa v Postgres s měřítkem. i když Azure SQL nativně nepodporuje horizontálního dělení, poskytuje nástroje horizontálního dělení pro podporu tohoto typu architektury.
Kromě toho při práci s relačními databázemi nebo jinými databázemi založenými na schématu zvažte, kde by se měl aktivovat proces upgradu schématu při údržbě loďstva databází. V malých nemovitostích databází můžete zvážit použití kanálu nasazení k nasazení změn schématu. Jak rostete, může být vhodnější, aby vaše aplikační vrstva zjistila verzi schématu pro určitou databázi a zahájila proces upgradu.
Úložiště souborů a objektů BLOB
Vezměte v úvahu přístup, který používáte k izolaci dat v rámci účtu úložiště. Můžete například nasadit samostatné účty úložiště pro každého tenanta nebo můžete sdílet účty úložiště a nasazovat jednotlivé kontejnery. Případně můžete vytvořit sdílené kontejnery objektů BLOB a potom použít cestu objektu BLOB k oddělení dat pro každého tenanta. Vezměte v úvahu omezení a kvóty předplatného Azurea pečlivě Naplánujte růst, abyste zajistili škálování vašich prostředků Azure na podporu budoucích potřeb.
Pokud používáte sdílené kontejnery, naplánujte pečlivě svoji strategii pro ověřování a autorizaci, abyste zajistili, že klienti nebudou mít přístup k datům ostatních. pokud klientům poskytnete přístup k prostředkům Azure Storage, vezměte v úvahu vzor klíče osobního.
Alokace nákladů
Vezměte v úvahu, jak budete měřit spotřebu a přidělit klientům nákladyza použití sdílených datových služeb. Kdykoli je to možné, zacílení na použití vestavěných metrik místo výpočtu vlastní. Nicméně se sdílenou infrastrukturou je obtížné rozdělit telemetrii pro jednotlivé klienty. Je potřeba vzít v úvahu vlastní měření na úrovni aplikace.
obecně cloudové služby, jako je Azure Cosmos DB a Azure Blob Storage, poskytují podrobnější metriky pro sledování a modelování využití pro konkrétního tenanta. Azure Cosmos DB například poskytuje spotřebované propustnosti pro každý požadavek a odpověď.
Další kroky
Další informace o víceklientské architektuře a konkrétních službách Azure najdete v těchto tématech: