Sdílet prostřednictvím

Víceklientská architektura a Azure Cosmos DB

  • Článek

Tento článek popisuje funkce služby Azure Cosmos DB, které můžete použít pro víceklientských systémů. Poskytuje pokyny a příklady použití služby Azure Cosmos DB ve víceklientských řešeních.

Požadavky na víceklientské architektury

Při plánování víceklientských řešení máte dva klíčové požadavky:

  • Pomozte zajistit silnou izolaci mezi tenanty a splnit přísné požadavky na zabezpečení pro ty, kteří je potřebují.
  • Udržujte nízké náklady na tenanta. Jako poskytovatel zajistěte, aby náklady na spuštění aplikace zůstaly udržitelné při škálování.

Tyto dvě potřeby můžou často kolidovat a představovat kompromis, ve kterém je nutné upřednostnit jednu před druhou. Pokyny v tomto článku vám můžou pomoct lépe porozumět kompromisům, které musíte učinit, abyste tyto potřeby vyřešili. Tento článek vám pomůže s těmito aspekty, abyste mohli při návrhu víceklientských řešení provádět informovaná rozhodnutí.

Modely izolace

Určete úroveň izolace, kterou potřebujete mezi tenanty. Azure Cosmos DB podporuje celou řadu modelů izolace, ale pro většinu řešení doporučujeme použít jednu z následujících strategií:

  • Klíč oddílu na tenanta se často používá pro plně víceklientská řešení, jako jsou řešení typu software jako služba (B2C SaaS).
  • Účet databáze na tenanta se často používá pro řešení SaaS typu business-to-business (B2B).

Pokud chcete zvolit nejvhodnější model izolace, zvažte obchodní model a požadavky tenantů. Například silná izolace výkonu nemusí být prioritou pro některé modely B2C, kde firma prodává produkt nebo službu přímo individuálnímu zákazníkovi. Modely B2B ale můžou určovat prioritu silného zabezpečení a izolace výkonu a můžou vyžadovat, aby tenanti měli vlastní zřízený databázový účet.

Můžete také kombinovat více modelů tak, aby vyhovovaly různým potřebám zákazníků. Předpokládejme například, že vytvoříte řešení B2B SaaS, které prodáváte podnikovým zákazníkům, a poskytnete bezplatnou zkušební verzi potenciálním novým zákazníkům. Můžete nasadit samostatný databázový účet pro placené podnikové tenanty, kteří potřebují silné záruky zabezpečení a izolace. A můžete sdílet účet databáze a používat klíče oddílů k izolaci zkušebních zákazníků.

Model partition-key-per-tenant a model database-account-per-tenant jsou nejběžnější modely izolace pro víceklientských řešení. Tyto modely poskytují nejlepší rovnováhu mezi izolací tenanta a nákladovou efektivitou.

Model klíče oddílu na tenanta

Pokud tenanty izolujete podle klíče oddílu, propustnost se sdílí mezi tenanty a spravuje se v rámci stejného kontejneru.

Poznámka:

Jednotka požadavku (RU) je logická abstrakce nákladů na operaci databáze nebo dotaz. Obvykle pro úlohu zřídíte definovaný počet jednotek žádostí za sekundu (RU/s), který se označuje jako propustnost.

Zaměstnanecké výhody

  • Efektivita nákladů: Umístíte všechny tenanty do jednoho kontejneru, který je rozdělený podle ID tenanta. Tento přístup má pouze jeden fakturovatelný prostředek, který zřizuje a sdílí ru mezi více tenanty. Tento model je obvykle nákladově efektivnější a jednodušší než mít samostatné účty pro každého tenanta.

  • Zjednodušená správa: Ke správě máte méně účtů Služby Azure Cosmos DB.

Kompromisy

  • Kolize prostředků: Sdílená propustnost (RU/s) napříč tenanty, kteří jsou ve stejném kontejneru, můžou vést k kolizím během špičky. Tato kolize může způsobit hlučné problémy se sousedy a problémy s výkonem, pokud mají vaši tenanti vysoké nebo překrývající se úlohy. Tento model izolace použijte pro úlohy, které potřebují zaručené RU v jednom tenantovi a můžou sdílet propustnost.

  • Omezená izolace: Tento přístup poskytuje logickou izolaci, nikoli fyzickou izolaci. Nemusí splňovat přísné požadavky na izolaci z hlediska výkonu nebo zabezpečení.

  • Menší flexibilita: Pro každého tenanta nemůžete přizpůsobit funkce na úrovni účtu, jako je geografická replikace, obnovení k určitému bodu v čase a klíče spravované zákazníkem, pokud izolujete klíč oddílu nebo databázi nebo kontejner.

Funkce Azure Cosmos DB pro víceklientské prostředí

  • Řízení propustnosti: Prozkoumejte funkce, které vám můžou pomoct řídit problém s hlučným sousedem při použití klíče oddílu k izolaci tenantů. V sadě Java SDK můžete používat funkce, jako je relokace propustnosti, kapacita s nárůstem kapacity a řízenípropustnosti.

  • Hierarchické klíče oddílů: Použijte Službu Azure Cosmos DB, aby každý logický oddíl mohl zvětšit až 20 GB. Pokud máte jednoho tenanta, který potřebuje uložit více než 20 GB dat, zvažte rozložení dat do více logických oddílů. Například místo jediného klíče oddílu můžete klíče oddílu Contosodistribuovat vytvořením více klíčů oddílů pro tenanta, například Contoso1 a Contoso2.

    Když se dotazujete na data pro tenanta, můžete použít WHERE IN klauzuli tak, aby odpovídala všem klíčům oddílu. Pokud máte vysokou kardinalitu tenantů, můžete také použít hierarchické klíče oddílů k poskytování velkých tenantů s úložištěm větším než 20 GB. Pro tuto metodu nemusíte používat syntetické klíče oddílů ani více hodnot klíče oddílu na tenanta.

    Předpokládejme, že máte úlohu, která izoluje tenanty podle klíče oddílu. Jeden tenant, Contoso, je větší a více náročný na zápis než ostatní, a stále roste velikost. Abyste se vyhnuli riziku, že nebudete moct ingestovat více dat pro tohoto tenanta, můžete použít hierarchické klíče oddílů. Zadejte TenantID jako klíč první úrovně a pak přidejte druhou úroveň, například UserId. Pokud očekáváte, že TenantID a UserID kombinace vytvoří logické oddíly, které překročí limit 20 GB, můžete dále rozdělit na jinou úroveň, například SessionID. Dotazy, které určují buď TenantID nebo obojí TenantID a UserID jsou efektivně směrovány pouze na podmnožinu fyzických oddílů obsahujících relevantní data, což zabraňuje úplnému dotazování na ventilátory. Pokud má kontejner 1 000 fyzických oddílů, ale konkrétní TenantId hodnota je pouze na pěti fyzických oddílech, dotaz se směruje na menší počet relevantních fyzických oddílů.

    Pokud vaše první úroveň nemá dostatečně vysokou kardinalitu a dosáhnete limitu 20 GB logického oddílu u klíče oddílu, zvažte použití syntetického klíče oddílu místo hierarchického klíče oddílu.

Model databázového účtu na tenanta

Pokud tenanty izolujete podle databázového účtu, každý tenant má zřízenou vlastní propustnost na úrovni databáze nebo kontejneru.

Zaměstnanecké výhody

  • Vysoká izolace: Tento přístup zabraňuje kolizím nebo rušení kvůli vyhrazeným účtům a kontejnerům Azure Cosmos DB, které zřídily ru na jedinečného tenanta.

  • Vlastní smlouvy o úrovni služeb (SLA): Každý tenant má svůj vlastní účet, takže můžete poskytovat konkrétní přizpůsobené prostředky, smlouvy SLA pro zákazníky a záruky, protože můžete účet databáze každého tenanta ladit nezávisle na propustnosti.

  • Vylepšené zabezpečení: Izolace fyzických dat pomáhá zajistit robustní zabezpečení, protože zákazníci můžou povolit klíče spravované zákazníkem na úrovni účtu na úrovni tenanta. Data každého tenanta jsou izolovaná účtem, nikoli ve stejném kontejneru.

  • Flexibilita: Tenanti můžou podle potřeby povolit funkce na úrovni účtu, jako je geografická replikace, obnovení k určitému bodu v čase a klíče spravované zákazníkem.

Kompromisy

  • Zvýšená správa: Tento přístup je složitější, protože spravujete více účtů služby Azure Cosmos DB.

  • Vyšší náklady: Více účtů znamená, že pro každý prostředek, jako jsou databáze nebo kontejnery, musíte zřídit propustnost pro jednotlivé tenanty. Pokaždé, když prostředek zřídí RU, zvýší se náklady na službu Azure Cosmos DB.

  • Omezení dotazů: Všichni tenanti jsou v různých účtech, takže aplikace, které dotazují více tenantů, vyžadují v logice aplikace více volání.

Funkce Azure Cosmos DB pro víceklientské prostředí

  • Funkce zabezpečení: Tento model poskytuje zvýšenou izolaci zabezpečení přístupu k datům prostřednictvím Azure RBAC. Tento model také poskytuje izolaci zabezpečení šifrování databáze na úrovni tenanta prostřednictvím klíčů spravovaných zákazníkem.

  • Vlastní konfigurace: Umístění databázového účtu můžete nakonfigurovat podle požadavků tenanta. Můžete také ladit konfiguraci funkcí služby Azure Cosmos DB, jako je geografická replikace a šifrovací klíče spravované zákazníkem, aby vyhovovaly požadavkům jednotlivých tenantů.

Pokud používáte vyhrazený účet služby Azure Cosmos DB na tenanta, zvažte maximální počet účtů Služby Azure Cosmos DB na předplatné Azure.

Úplný seznam modelů izolace

Potřeba úlohy Klíč oddílu na tenanta (doporučeno) Kontejner na tenanta (sdílená propustnost) Kontejner na tenanta (vyhrazená propustnost) Databáze na tenanta Účet databáze na tenanta (doporučeno)
Dotazy napříč tenanty Easy (kontejner funguje jako hranice pro dotazy) Závazná Závazná Závazná Závazná
Hustota tenanta Vysoká (nejnižší náklady na tenanta) Střední Nízká Nízká Nízká
Odstranění dat tenanta Snadné Snadné (vyřazení kontejneru po opuštění tenanta) Snadné (vyřazení kontejneru po opuštění tenanta) Snadné (vyřazení databáze po opuštění tenanta) Snadné (vyřazení databáze po opuštění tenanta)
Izolace zabezpečení přístupu k datům Potřeba implementovat v rámci aplikace Řízení přístupu na základě role kontejneru Řízení přístupu na základě role kontejneru Řízení přístupu na základě role v databázi RBAC
Geografická replikace Geografická replikace na tenanta není možná. Seskupování tenantů v rámci databázových účtů na základě požadavků Seskupování tenantů v rámci databázových účtů na základě požadavků Seskupování tenantů v rámci databázových účtů na základě požadavků Seskupování tenantů v rámci databázových účtů na základě požadavků
Hlučná prevence souseda No No Ano Ano Ano
Latence vytváření nového tenanta Okamžité Rychlé Rychlé Střední Pomalá
Výhody modelování dat Nic Kolokace entit Kolokace entit Více kontejnerů pro modelování entit tenanta Více kontejnerů a databází pro modelování tenantů
Šifrovací klíč Stejné pro všechny tenanty Stejné pro všechny tenanty Stejné pro všechny tenanty Stejné pro všechny tenanty Klíč spravovaný zákazníkem na tenanta
Požadavky na propustnost >0 RU na tenanta >100 RU na tenanta >100 RU na tenanta (pouze s automatickým škálováním, jinak >400 RU na tenanta) >400 RU na tenanta >400 RU na tenanta
Příklad případu použití Aplikace B2C Standardní nabídka pro aplikace B2B Nabídka Premium pro aplikace B2B Nabídka Premium pro aplikace B2B Nabídka Premium pro aplikace B2B

Model kontejneru na tenanta

Pro každého tenanta můžete zřídit vyhrazené kontejnery. Vyhrazené kontejnery fungují dobře, když můžete kombinovat data uložená pro vašeho tenanta do jednoho kontejneru. Tento model poskytuje větší izolaci výkonu než model partition-key-per-tenant. Poskytuje také zvýšenou izolaci zabezpečení přístupu k datům prostřednictvím Azure RBAC.

Při použití kontejneru pro každého tenanta zvažte sdílení propustnosti s ostatními tenanty zřízením propustnosti na úrovni databáze. Zvažte omezení a omezení minimálního počtu RU pro vaši databázi a maximální počet kontejnerů v databázi. Zvažte také, jestli tenanti vyžadují zaručenou úroveň výkonu a jestli jsou náchylné k problému hlučného souseda. Když sdílíte propustnost na úrovni databáze, měla by být úloha nebo úložiště napříč všemi kontejnery relativně jednotná. Jinak můžete mít problém s hlučným sousedem, pokud máte jednoho nebo více velkých tenantů. V případě potřeby naplánujte seskupení těchto tenantů do různých databází, které jsou založené na vzorech úloh.

Případně můžete zřídit vyhrazenou propustnost pro každý kontejner. Tento přístup funguje dobře pro větší tenanty a pro tenanty, kteří riskují problém hlučného souseda. Propustnost směrného plánu pro každého tenanta je ale vyšší, proto zvažte minimální požadavky a dopad na náklady tohoto modelu.

Pokud datový model tenanta vyžaduje více než jednu entitu a pokud všechny entity můžou sdílet stejný klíč oddílu, můžete je umístit do stejného kontejneru. Pokud je ale datový model tenanta složitější a vyžaduje entity, které nemůžou sdílet stejný klíč oddílu, zvažte modely databáze podle tenanta nebo účtu databáze na tenanta. Další informace najdete v tématu Modelování a dělení dat ve službě Azure Cosmos DB.

Správa životního cyklu je obecně jednodušší, když dedikujete kontejnery tenantům. Tenanty můžete snadno přesouvat mezi sdílenými a vyhrazenými modely propustnosti. A když zrušíte zřízení tenanta, můžete kontejner rychle odstranit.

Model databáze na tenanta

Databáze můžete zřídit pro každého tenanta ve stejném databázovém účtu. Stejně jako model kontejneru na tenanta poskytuje tento model větší izolaci výkonu než model klíče oddílu na tenanta. Poskytuje také zvýšenou izolaci zabezpečení přístupu k datům prostřednictvím Azure RBAC.

Tento přístup se podobá modelu účtů na tenanta, ale poskytuje nejvyšší úroveň izolace výkonu, ale poskytuje nejnižší hustotu tenanta. Tuto možnost použijte, pokud každý tenant vyžaduje složitější datový model, než je možné v modelu kontejneru na tenanta. Nebo postupujte podle tohoto přístupu, pokud vytváření nového tenanta musí být rychlé nebo bez jakýchkoli režijních nákladů předem. U některých architektur pro vývoj softwaru může být model databáze pro jednotlivé tenanty jedinou úrovní izolace výkonu, kterou tato architektura podporuje. Takové architektury obvykle nepodporují izolaci na úrovni entity (kontejneru) a kolokaci entit.

Funkce služby Azure Cosmos DB, které podporují víceklientské prostředí

dělení na části

Pomocí oddílů s kontejnery Azure Cosmos DB můžete vytvářet kontejnery, které sdílí více tenantů. Obvykle používáte identifikátor tenanta jako klíč oddílu, ale můžete také zvážit použití více klíčů oddílů pro jednoho tenanta. Dobře plánovaná strategie dělení efektivně implementuje model horizontálního dělení. Pokud máte velké kontejnery, Azure Cosmos DB rozloží vaše tenanty do několika fyzických uzlů, aby dosáhla vysokého stupně škálování.

Zvažte hierarchické klíče oddílů, které vám pomůžou zlepšit výkon víceklientských řešení. Pomocí hierarchických klíčů oddílů vytvořte klíč oddílu, který obsahuje více hodnot. Můžete například použít hierarchický klíč oddílu, který obsahuje identifikátor tenanta, jako je identifikátor GUID s vysokou kardinalitou, a umožnit tak téměř nevázané škálování. Nebo můžete zadat hierarchický klíč oddílu, který obsahuje vlastnost, která se často používá. Tento přístup vám pomůže vyhnout se dotazům napříč oddíly. Pomocí hierarchických klíčů oddílů můžete škálovat nad rámec limitu logického oddílu 20 GB na hodnotu klíče oddílu a omezit nákladné dotazy na ventilátory.

Další informace naleznete v následujících zdrojích:

Správa RU

Cenový model služby Azure Cosmos DB vychází z počtu RU/s, které zřídíte nebo využíváte. Azure Cosmos DB nabízí několik možností pro zřízení propustnosti. Ve víceklientských prostředích ovlivňuje výběr výkon a cenu vašich prostředků Azure Cosmos DB.

Pro tenanty, kteří vyžadují zaručenou výkon a izolaci zabezpečení, doporučujeme izolovat tenanty podle účtu databáze a přidělit ru tenantovi. Pro tenanty, kteří mají méně přísné požadavky, doporučujeme izolovat tenanty podle klíče oddílu. Tento model použijte ke sdílení RU mezi tenanty a optimalizaci nákladů na tenanta.

Alternativní model tenantů pro službu Azure Cosmos DB zahrnuje nasazení samostatných kontejnerů pro každého tenanta ve sdílené databázi. Pomocí služby Azure Cosmos DB zřiďte ru pro databázi, aby všechny kontejnery sdílely jednotky RU. Pokud se úlohy tenanta obvykle nepřekrývají, může vám tento přístup pomoct snížit provozní náklady. Tento přístup je ale náchylný k problému hlučného souseda, protože kontejner jednoho tenanta může spotřebovávat nepřiměřenou část sdílených zřízených RU. Pokud chcete tento problém zmírnit, nejprve identifikujte hlučné tenanty. Potom můžete volitelně nastavit zřízenou propustnost pro konkrétní kontejner. Ostatní kontejnery v databázi nadále sdílejí svou propustnost, ale hlučný tenant využívá vlastní vyhrazenou propustnost.

Azure Cosmos DB také poskytuje bezserverovou úroveň, která vyhovuje úlohám, které mají přerušovaný nebo nepředvídatelný provoz. Případně můžete pomocí automatického škálování nakonfigurovat zásady, které určují škálování zřízené propustnosti. Můžete také využít kapacitu nárůstu kapacity služby Azure Cosmos DB, abyste maximalizovali využití zřízené kapacity propustnosti, která je jinak omezená omezeními rychlosti. V víceklientských řešeních můžete všechny tyto přístupy kombinovat, abyste podporovali různé typy tenantů.

Poznámka:

Při plánování konfigurace služby Azure Cosmos DB zvažte kvóty a limity služby.

Pokud chcete monitorovat a spravovat náklady spojené s každým tenantem, nezapomeňte, že každá operace, která používá rozhraní API služby Azure Cosmos DB, zahrnuje spotřebované RU. Tyto informace můžete použít k agregaci a porovnání skutečných RU, které jednotlivé tenanty spotřebovávají. Pak můžete identifikovat tenanty, kteří mají různé charakteristiky výkonu.

Další informace naleznete v následujících zdrojích:

Klíče spravované zákazníkem

Někteří tenanti můžou vyžadovat použití vlastních šifrovacích klíčů. Azure Cosmos DB poskytuje funkci klíče spravovaného zákazníkem. Tuto funkci použijete na úrovni účtu služby Azure Cosmos DB. Pokud tedy tenanti vyžadují vlastní šifrovací klíče, musíte k nasazení tenantů použít vyhrazené účty služby Azure Cosmos DB.

Další informace najdete v tématu Konfigurace klíčů spravovaných zákazníkem pro účet služby Azure Cosmos DB pomocí služby Azure Key Vault.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

  • Tara Bhatia | Program Manager, Azure Cosmos DB
  • Paul Burpo | Hlavní zákaznický inženýr, FastTrack pro Azure
  • John Downs | Hlavní softwarový inženýr

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Další informace o víceklientské službě a službě Azure Cosmos DB:

Projděte si některé z našich dalších scénářů architektury služby Azure Cosmos DB: