Data se často považují za nejcennější součást řešení, protože představují cenné obchodní informace – a vaše zákazníky. Proto je důležité pečlivě spravovat data. Při plánování úložiště nebo datových komponent pro víceklientských systémů se musíte rozhodnout o přístupu ke sdílení nebo izolování dat tenantů.
V tomto článku poskytujeme pokyny ke klíčovým aspektům a požadavkům, které jsou nezbytné pro architekty řešení při rozhodování o přístupu k ukládání dat ve víceklientských systémech. Pak doporučujeme některé běžné vzory pro použití víceklientské architektury pro úložiště a datové služby a některé antipatterny, kterým se chcete vyhnout. Nakonec poskytujeme cílené pokyny pro některé konkrétní situace.
Klíčové aspekty 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, což je přibližně v souladu s pilíři architektury 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 tenantů, které máte, a objem dat, která ukládáte. Pokud máte malý počet tenantů (například pět nebo méně) a ukládáte malé objemy dat pro každého tenanta, bude pravděpodobně plýtvání úsilím naplánovat vysoce škálovatelný přístup k ukládání dat nebo vytvořit plně automatizovaný přístup ke správě datových prostředků. S rostoucím růstem ale stále více získáte jasnou strategii škálování prostředků dat a úložiště a použití automatizace pro jejich správu. Pokud máte 50 tenantů nebo více, nebo pokud máte v plánu dosáhnout této úrovně škálování, je důležité navrhnout přístup k datům a úložišti s ohledem na klíčové aspekty škálování.
Vezměte v úvahu rozsah, do kterého plánujete škálování, a jasně naplánujte přístup architektury úložiště dat tak, aby splňoval tuto úroveň škálování.
Předvídatelnost výkonu
Víceklientské datové služby a služby úložiště jsou zvláště náchylné k problému hlučného souseda. Je důležité zvážit, jestli vaše tenanti můžou ovlivnit výkon jednotlivých tenantů. Mají například tenanti překrývající se špičky ve vzorech jejich využití v průběhu času? Používají vaše řešení všichni vaši zákazníci ve stejnou dobu každý den nebo se žádosti distribuují rovnoměrně? Tyto faktory ovlivní úroveň izolace, pro kterou je potřeba navrhnout, množství prostředků, které potřebujete zřídit, a stupeň sdílení prostředků mezi tenanty.
V rámci tohoto rozhodnutí je důležité zvážit 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 tenantů. Pokud překročíte určitý počet operací úložiště za sekundu, Azure Storage odmítne požadavky vaší aplikace a ovlivní to všechny vaše tenanty. Tomu se říká chování omezování . Je důležité monitorovat omezené požadavky. Další informace najdete v doprovodných materiálech k opakování služeb Azure.
Izolaci dat
Při navrhování řešení, které obsahuje víceklientských datových služeb, existují obvykle různé možnosti a úrovně izolace dat, z nichž každá má vlastní výhody a kompromisy. Příklad:
- Při použití služby Azure Cosmos DB můžete pro každého tenanta nasadit samostatné kontejnery a sdílet databáze a účty mezi více tenanty. Případně 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í Služby 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í Azure SQL 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 více předplatných Azure – možná i jedno na tenanta.
Neexistuje žádné řešení, které by fungovalo pro každou situaci. Možnost, kterou zvolíte, závisí na řadě faktorů a požadavcích vašich tenantů. Pokud například vaši tenanti potřebují splňovat konkrétní standardy dodržování předpisů nebo právních předpisů, možná budete muset použít vyšší úroveň izolace. Podobně můžete mít komerční požadavky na fyzickou izolaci dat vašich zákazníků nebo možná budete muset vynutit izolaci, abyste se vyhnuli problému hlučného souseda. Pokud navíc tenanti potřebují používat vlastní šifrovací klíče, mají samostatné zásady zálohování a obnovení nebo potřebují mít svá data uložená v různých geografických umístěních, možná je budete muset izolovat od jiných tenantů nebo je seskupit s tenanty, kteří mají podobné zásady.
Složitost implementace
Je důležité zvážit složitost implementace. Je vhodné zachovat architekturu co nejsnádžněji a zároveň splnit vaše požadavky. Vyhněte se závazku k architektuře, která se při škálování stane stále složitějším, nebo architekturou, kterou nemáte k vývoji a údržbě prostředků ani odborných znalostí.
Podobně platí, že pokud vaše řešení nemusí škálovat na velký počet tenantů nebo pokud nemáte obavy ohledně výkonu nebo izolace dat, je lepší řešení zjednodušit a vyhnout se zbytečné složitosti.
Konkrétním problémem pro víceklientských datových řešení je úroveň přizpůsobení, kterou podporujete. Může například tenant rozšířit datový model nebo použít vlastní pravidla dat? Ujistěte se, že pro tento požadavek navrhujete předem. Vyhněte se vytváření forků nebo poskytování vlastní infrastruktury pro jednotlivé tenanty. Přizpůsobená infrastruktura inhibuje schopnost š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 tenanta.
Složitost správy a provozu
Zvažte, jak plánujete provozovat vaše řešení a jak váš přístup s více tenanty ovlivňuje vaše operace a procesy. Příklad:
- Správa: Zvažte operace správy napříč tenanty, jako jsou běžné aktivity údržby. Pokud používáte více účtů, serverů nebo databází, jak zahájíte a budete monitorovat operace pro každého tenanta?
- Monitorování a měření: Pokud monitorujete nebo měříte tenanty, zvažte, jak vaše řešení hlásí metriky a jestli se dají snadno propojit s tenantem, který žádost aktivoval.
- Vytváření sestav: Vytváření sestav dat z různých izolovaných tenantů může vyžadovat, aby každý tenant publikoval data do centralizovaného datového skladu, a ne spouštěl dotazy na každou databázi jednotlivě a pak agregoval výsledky.
- Aktualizace schématu: Pokud používáte databázi, která vynucuje schéma, naplánujte, jak budete nasazovat aktualizace schématu v rámci vašich aktiv. Zvažte, jak vaše aplikace ví, jakou verzi schématu použít pro databázové dotazy konkrétního tenanta.
- Požadavky: Vezměte v úvahu požadavky na vysokou dostupnost vašich tenantů (například smlouvy o úrovni služeb dostupnosti nebo smlouvy SLA) a požadavky na zotavení po havárii (například cíle doby obnovení nebo cíle bodů obnovení nebo cíle bodů obnovení). Pokud mají tenanti různá očekávání, budete schopni splnit požadavky každého tenanta?
- Migrace: Jak budete migrovat tenanty, pokud se potřebují přesunout do jiného typu služby, jiného nasazení nebo jiné oblasti?
Náklady
Obecně platí, že čím vyšší je hustota tenantů pro vaši infrastrukturu nasazení, tím nižší jsou náklady na zřízení této infrastruktury. Sdílená infrastruktura ale zvyšuje pravděpodobnost problémů, jako je problém hlučného souseda, proto pečlivě zvažte kompromisy.
Přístupy a vzory, které je potřeba zvážit
Několik vzorů návrhu z Centra architektury Azure má význam pro víceklientských úložišť a datových služeb. Můžete se rozhodnout dodržovat jeden vzor konzistentně. Nebo můžete zvážit kombinování a porovnávání vzorů. Můžete například použít víceklientovou databázi pro většinu tenantů, ale nasadit kolek s jedním tenantem pro tenanty, kteří platí více nebo mají neobvyklé požadavky. Podobně je často vhodné škálovat pomocí razítek nasazení, i když v rámci razítka používáte víceklientskou databázi nebo horizontálně dělené databáze.
Model razítka nasazení
Další informace o tom, jak lze model razítka nasazení použít k podpoře víceklientského řešení, najdete v tématu Přehled.
Sdílené víceklientové databáze a úložiště souborů
Můžete zvážit nasazení sdílené víceklientové databáze, účtu úložiště nebo sdílené složky a jeho sdílení napříč všemi tenanty.
Tento přístup poskytuje nejvyšší hustotu tenantů k infrastruktuře, takže má tendenci přicházet s nejnižšími náklady na jakýkoli přístup. Často také 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 ale pracujete se sdílenou infrastrukturou, je potřeba zvážit několik upozornění:
- Omezení škálování: Pokud se spoléháte na jeden prostředek, zvažte podporované škálování a omezení daného prostředku. Například maximální velikost jedné databáze nebo úložiště souborů nebo maximální limity propustnosti se nakonec stanou pevným blokátorem, pokud vaše architektura spoléhá na jednu databázi. Před výběrem tohoto vzoru pečlivě zvažte maximální měřítko, které potřebujete k dosažení, a porovnejte ho s vašimi aktuálními a budoucími limity.
- Hlučné sousedy: Problém s hlučným sousedem se může stát faktorem, zejména pokud máte tenanty, kteří jsou obzvláště zaneprázdněni nebo generují vyšší úlohy než ostatní. Zvažte použití vzoru omezování nebo modelu omezování rychlosti, aby se tyto účinky zmírňovaly.
- Monitorování jednotlivých tenantů: Možná budete mít potíže s monitorováním aktivity a měřením spotřeby pro jednoho tenanta. Některé služby, jako je Azure Cosmos DB, poskytují sestavy o využití prostředků pro jednotlivé požadavky, aby se tyto informace mohly sledovat a měřit spotřebu jednotlivých tenantů. Jiné služby neposkytují stejnou úroveň podrobností. Například metriky služby Azure Files pro kapacitu souborů jsou k dispozici pro jednotlivé dimenze sdílené složky, pouze pokud používáte sdílené složky úrovně Premium. Úroveň Standard ale poskytuje metriky pouze na úrovni účtu úložiště.
- Požadavky na tenanta: Tenanti můžou 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 pojmout.
- Přizpůsobení schématu: 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í
Model horizontálního dělení zahrnuje nasazení několika samostatných databází, označovaných jako horizontální oddíly, které obsahují data jednoho nebo více tenantů. Na rozdíl od kolků nasazení neznamenají horizontální oddíly, že je celá infrastruktura duplikovaná. Databáze horizontálních oddílů můžete bez duplikování nebo horizontálního dělení jiné infrastruktury ve vašem řešení.
Shardování úzce souvisí s dělením a termíny se často používají zaměnitelně. Zvažte pokyny k horizontálnímu, vertikálnímu a funkčnímu dělení dat.
Model horizontálního dělení se může škálovat na velmi velký počet tenantů. V závislosti na vaší úloze navíc můžete být schopni dosáhnout vysoké hustoty tenantů s horizontálními oddíly, aby náklady mohly být atraktivní. Model horizontálního dělení se dá použít také k řešení kvót, limitů a omezení předplatného a služeb Azure.
Některá úložiště dat, jako je Azure Cosmos DB, poskytují nativní podporu pro horizontální dělení nebo dělení. Při práci s jinými řešeními, jako je 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í oddíl pro daného tenanta.
Horizontální dělení také ztěžuje podporu rozdílů v konfiguraci na úrovni tenanta a umožňuje zákazníkům poskytovat vlastní šifrovací klíče.
Víceklientní aplikace s vyhrazenými databázemi pro každého tenanta
Dalším běžným přístupem je nasazení jedné víceklientové aplikace s vyhrazenými databázemi pro každého tenanta.
V tomto modelu jsou data jednotlivých tenantů izolovaná od ostatních a pro každého tenanta můžete podporovat určitý stupeň přizpůsobení.
Vzhledem k tomu, že pro každého tenanta zřizujete vyhrazené datové prostředky, můžou být náklady na tento přístup vyšší než sdílené hostitelské modely. Azure ale nabízí několik možností, které můžete zvážit, abyste mohli sdílet náklady na hostování jednotlivých datových prostředků napříč několika tenanty. Když například pracujete s Azure SQL, můžete zvážit elastické fondy. Pro službu 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 potřebujete zaručený výkon pro každý kontejner.
V tomto přístupu, protože pro každého tenanta se nasazují jenom datové komponenty, můžete pravděpodobně dosáhnout vysoké hustoty pro ostatní komponenty ve vašem ř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žívat přístupy k automatizovanému nasazení.
Model geodes
Model Geode je navržený speciálně pro geograficky distribuovaná řešení, včetně víceklientských řešení. Podporuje vysokou zátěž a vysokou úroveň odolnosti. Pokud implementujete model Geode, vaše datová vrstva musí být schopná replikovat data napříč geografickými oblastmi a měla by podporovat zápisy do více zeměpisných oblastí.
Azure Cosmos DB poskytuje zápisy s více hlavními servery pro podporu tohoto modelu a Cassandra podporuje clustery s více oblastmi. Ostatní datové služby obvykle tento model nepodporují bez významných přizpůsobení.
Antipatterny, aby se zabránilo
Když vytváříte víceklientské datové služby, je důležité se vyhnout situacím, které brání škálování.
Pro relační databáze patří:
- Izolace založená na tabulce Pokud pracujete v rámci jedné databáze, vyhněte se vytváření jednotlivých tabulek pro každého tenanta. Jedna databáze nebude moct při použití tohoto přístupu podporovat velmi velký počet tenantů a stává se stále obtížnější dotazovat, spravovat a aktualizovat data. Místo toho zvažte použití jedné sady víceklientských tabulek se sloupcem identifikátoru tenanta. Alternativně můžete použít jeden z výše popsaných vzorů k nasazení samostatných databází pro každého tenanta.
- Přizpůsobení tenanta na úrovni sloupců Nepoužívejte aktualizace schématu, které platí jenom pro jednoho tenanta. Předpokládejme například, že máte jednu víceklientovou databázi. Vyhněte se přidávání nového sloupce, abyste splnili požadavky konkrétního tenanta. Může být přijatelné pro malý počet přizpůsobení, ale tato možnost se rychle stává nespravovatelnou, pokud máte velký počet přizpůsobení, které je potřeba zvážit. Místo toho zvažte revizi datového modelu, abyste mohli sledovat vlastní data pro každého tenanta ve vyhrazené tabulce.
- Ruční změny schématu. Vyhněte se ruční aktualizaci schématu databáze, i když máte jenom jednu sdílenou databázi. Je snadné ztratit přehled o aktualizacích, které jste použili, a pokud potřebujete škálovat na více databází, je obtížné identifikovat správné schéma, které se má použít. Místo toho vytvořte automatizovaný kanál pro nasazení změn schématu a konzistentně ho používejte. Sledujte verzi schématu používanou pro každého tenanta ve vyhrazené databázi nebo vyhledávací tabulce.
- Závislosti verzí Vyhněte se tomu, aby vaše aplikace závisela na jedné verzi schématu databáze. Při škálování možná budete muset v různých tenantech použít aktualizace schématu v různých časech. Místo toho se ujistěte, že je verze aplikace zpětně kompatibilní s alespoň jednou verzí schématu, a vyhněte se destruktivním aktualizacím schématu.
Databáze
Některé funkce můžou být užitečné pro víceklientské prostředí. Nejsou ale dostupné ve všech databázových službách. Při rozhodování o službě, která se má pro váš scénář použít, zvažte, jestli je potřebujete:
- Zabezpečení na úrovni řádků může poskytovat izolaci zabezpečení pro data konkrétních tenantů ve sdílené víceklientové databázi. Tato funkce je dostupná v Azure SQL a Postgres Flex, ale není dostupná v jiných databázích, jako je MySQL nebo Azure Cosmos DB.
- Pro podporu tenantů, kteří pro svá data poskytují vlastní šifrovací klíče, může být vyžadováno šifrování na úrovni tenanta. Tato funkce je dostupná v Azure SQL jako součást funkce Always Encrypted. Azure Cosmos DB poskytuje klíče spravované zákazníkem na úrovni účtu a podporuje také funkci Always Encrypted.
- Sdružování zdrojů umožňuje sdílet prostředky a náklady mezi několika databázemi nebo kontejnery. Tato funkce je dostupná v elastických fondech a spravovaných instancích Azure SQL a v propustnosti databáze Azure Cosmos DB, i když každá možnost má určitá omezení, o které byste měli vědět.
- Horizontální dělení a dělení má silnější nativní podporu v některých službách než jiné. Tato funkce je dostupná ve službě Azure Cosmos DB pomocí logického a fyzického dělení a v PostgreSQL Hyperscale. Azure SQL sice nativně nepodporuje horizontální dělení, ale poskytuje nástroje pro horizontální dělení, které podporují tento typ 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 se má proces upgradu schématu aktivovat, když udržujete vozový park databází. V malých aktivech databází můžete zvážit použití kanálu nasazení k nasazení změn schématu. Při růstu může být pro vaši aplikační vrstvu lepší zjistit verzi schématu pro konkrétní databázi a zahájit proces upgradu.
Úložiště souborů a objektů blob
Zvažte 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. Alternativně můžete vytvořit sdílené kontejnery objektů blob a pak můžete použít cestu k objektu blob k oddělení dat pro každého tenanta. Zvažte limity a kvóty předplatného Azure a pečlivě naplánujte růst, abyste zajistili škálování prostředků Azure tak, aby podporovaly vaše budoucí potřeby.
Pokud používáte sdílené kontejnery, pečlivě naplánujte strategii ověřování a autorizace, abyste zajistili, že tenanti nebudou mít přístup k datům ostatních. Při poskytování přístupu k prostředkům Azure Storage zvažte vzor Valet Key.
Přidělení nákladů
Zvažte, jak budete měřit spotřebu a přidělovat náklady tenantům pro použití sdílených datových služeb. Pokud je to možné, snažte se místo výpočtu vlastních metrik použít předdefinované metriky. U sdílené infrastruktury je ale obtížné rozdělit telemetrii pro jednotlivé tenanty a měli byste zvážit vlastní měření na úrovni aplikace.
Obecně platí, že služby nativní pro cloud, jako jsou 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řebovanou propustnost pro každý požadavek a odpověď.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- John Downs | Hlavní zákaznický inženýr, FastTrack pro Azure
Další přispěvatelé:
- Paul Burpo | Hlavní zákaznický inženýr, FastTrack pro Azure
- Daniel Scott-Raynsford | Partner Technology Strategist
- Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.
Další kroky
Další informace o víceklientské a konkrétní službě Azure najdete v tématech: