Udostępnij za pośrednictwem

Wielodostępność i Azure Cosmos DB

W tym artykule opisano funkcje usługi Azure Cosmos DB, których można używać w systemach wielodostępnych. Zawiera wskazówki i przykłady dotyczące korzystania z usługi Azure Cosmos DB w rozwiązaniu wielodostępnym.

Wymagania dotyczące wielu dzierżawców

Podczas planowania rozwiązania wielodostępnego masz dwa kluczowe wymagania:

  • Pomóż zapewnić silną izolację między najemcami i spełnić rygorystyczne wymagania dotyczące zabezpieczeń dla potrzebujących.
  • Utrzymywanie niskich kosztów na dzierżawę. Jako dostawca upewnij się, że koszt uruchamiania aplikacji pozostaje zrównoważony w miarę skalowania.

Te dwa potrzeby mogą często powodować konflikty i wprowadzać kompromis, w którym należy określić priorytety jednej nad drugą. Wskazówki zawarte w tym artykule mogą pomóc lepiej zrozumieć kompromisy, które należy spełnić, aby spełnić te potrzeby. Ten artykuł ułatwia poruszanie się po tych zagadnieniach, dzięki czemu można podejmować świadome decyzje podczas projektowania rozwiązania dla wielu najemców.

Modele izolacji

Określ poziom izolacji, którego potrzebujesz między najemcami. Usługa Azure Cosmos DB obsługuje szereg modeli izolacji, ale w przypadku większości rozwiązań zalecamy użycie jednej z następujących strategii:

  • Klucz partycji dla dzierżawcy jest często używany do w pełni wielodostępnych rozwiązań, na przykład oprogramowania jako usługi (B2C SaaS, business-to-consumer software as a service).
  • Konto w bazie danych na klienta jest często używane w przypadku rozwiązań business-to-business (B2B) typu SaaS.

Aby wybrać najbardziej odpowiedni model izolacji, rozważ model biznesowy oraz wymagania najemców. Na przykład silna izolacja wydajności może nie być priorytetem dla niektórych modeli B2C, w których firma sprzedaje produkt lub usługę bezpośrednio do pojedynczego klienta. Jednak modele B2B mogą określać priorytety silnej izolacji zabezpieczeń i wydajności i mogą wymagać, aby dzierżawcy mieli własne konto aprowizowanej bazy danych.

Można również połączyć wiele modeli, aby dopasować je do różnych potrzeb klientów. Załóżmy na przykład, że tworzysz rozwiązanie SaaS B2B, które sprzedajesz klientom korporacyjnym, i udostępniasz bezpłatną wersję próbną dla potencjalnych nowych klientów. Możesz wdrożyć oddzielne konto bazy danych dla płatnych klientów przedsiębiorstwa, którzy wymagają silnych gwarancji bezpieczeństwa i odizolowania. Możesz również udostępnić konto bazy danych i używać kluczy partycji do izolowania klientów w wersji próbnej.

Model "partition-key-per-tenant" i model "database-account-per-tenant" są najczęściej stosowanymi modelami izolacji w rozwiązaniach wielodostępnych. Te modely zapewniają najlepszą równowagę między izolacją najemcą a efektywnością kosztową.

Model klucza partycji na najemcę

Jeśli izolujesz dzierżawców według klucza partycji, przepustowość jest współdzielona między dzierżawcami i zarządzana w tym samym kontenerze.

Uwaga

Jednostka żądania (RU) to logiczna abstrakcja kosztów operacji bazy danych lub zapytania. Zazwyczaj w przypadku obciążenia przydzielasz zdefiniowaną liczbę jednostek żądań na sekundę (RU/s), która jest nazywana przepustowością.

Świadczenia

  • Efektywność kosztowa: umieszczasz wszystkich tenantów w jednym kontenerze, który jest podzielony na partycje według identyfikatora tenantów. Takie podejście ma tylko jeden zasób rozliczany, który dostarcza i współdzieli zasoby (RUs) między wieloma najemcami. Ten model jest zazwyczaj bardziej opłacalny i łatwiejszy w zarządzaniu niż posiadanie oddzielnych kont dla każdego lokatora.

  • Uproszczone zarządzanie: masz mniej kont usługi Azure Cosmos DB do zarządzania.

Kompromisy

  • Rywalizacja o zasoby: współdzielona przepływność (RU/s) między dzierżawami, które znajdują się w tym samym kontenerze, może prowadzić do rywalizacji podczas szczytowego użycia. Ta rywalizacja może prowadzić do zjawiska hałaśliwego sąsiada i wyzwań związanych z wydajnością, jeśli dzierżawcy mają duże lub nakładające się obciążenia. Użyj tego modelu izolacji dla obciążeń, które potrzebują gwarantowanej dostępności jednostek RU w jednej dzierżawie i mogą współdzielić przepustowość.

  • Ograniczona izolacja: takie podejście zapewnia izolację logiczną, a nie izolację fizyczną. Może nie spełniać rygorystycznych wymagań izolacji z perspektywy wydajności lub zabezpieczeń.

  • Mniejsza elastyczność: nie można dostosowywać funkcji na poziomie konta, takich jak replikacja geograficzna, przywracanie do punktu w czasie i klucze zarządzane przez klienta, dla każdej dzierżawy, jeśli izolujesz według klucza partycji, kontenera albo bazy danych.

Funkcje usługi Azure Cosmos DB na potrzeby wielotenancyjności

  • Kontroluj przepływność: Odkrywaj funkcje, które mogą pomóc w kontrolowaniu problemu hałaśliwego sąsiada, gdy używasz klucza partycji do izolowania dzierżawców. Korzystaj z funkcji, takich jak przydział przepływności, pojemność przepustowości i kontrola przepływności w SDK języka Java.

  • Hierarchiczne klucze partycji: użyj usługi Azure Cosmos DB, aby każda partycja logiczna mogła zwiększyć rozmiar do 20 GB. Jeśli masz jednego klienta, który musi przechowywać ponad 20 GB danych, rozważ rozłożenie danych na wiele partycji logicznych. Na przykład, zamiast pojedynczego klucza partycji Contoso, można rozdzielić klucze partycji, tworząc wiele kluczy partycji dla najemcy, takich jak Contoso1 i Contoso2.

    Podczas wykonywania zapytań dotyczących danych dla dzierżawcy można użyć klauzuli WHERE IN aby dopasować wszystkie klucze partycji. Możesz również użyć hierarchicznych kluczy partycji, aby zapewnić najemcom o dużej liczbie najemców magazyn o pojemności większej niż 20 GB. W tej metodzie nie musisz używać syntetycznych kluczy partycji ani wielu wartości klucza partycji na jednego najemcę.

    Załóżmy, że masz obciążenie, które izoluje najemców według klucza partycji. Jedno dzierżawione konto, Contoso, jest większe i bardziej obciążone zapisami niż inne, i nadal zwiększa swoją wielkość. Aby uniknąć ryzyka niemożności przyswajania więcej danych dla tego najemcy, możesz użyć hierarchicznych kluczy partycji. Określ TenantID jako pierwszy klucz poziomu, a następnie dodaj drugi poziom, taki jak UserId. Jeśli przewidujesz, że kombinacja TenantID i UserID utworzy partycje logiczne przekraczające limit 20 GB, możesz podzielić je dalej na niższy poziom, na przykład SessionID. Zapytania, które określają albo TenantID, albo zarówno TenantID, jak i UserID, są skutecznie kierowane tylko do podzbioru partycji fizycznych zawierających odpowiednie dane, co pozwala uniknąć pełnego zapytania fan-out. Jeśli kontener ma 1000 partycji fizycznych, ale określona TenantId wartość jest tylko na pięciu partycjach fizycznych, zapytanie jest kierowane do mniejszej liczby odpowiednich partycji fizycznych.

    Jeśli pierwszy poziom nie ma wystarczająco wysokiej kardynalności i osiągniesz limit partycji logicznej 20 GB dla klucza partycji, rozważ użycie syntetycznego klucza partycji zamiast klucza partycji hierarchicznej.

Model jednego konta bazy danych na najemcę

Jeśli izolujesz najemców według konta bazy danych, każdy najemca ma przydzieloną przepustowość na poziomie bazy danych lub na poziomie kontenera.

Świadczenia

  • Wysoka izolacja: takie podejście pozwala uniknąć konfliktu lub interferencji dzięki dedykowanym kontom i kontenerom w usłudze Azure Cosmos DB, które mają aprowizowane jednostki RU na unikatowego dzierżawcę.

  • Niestandardowe umowy dotyczące poziomu usług (SLA): każdy najemca ma własne konto, dzięki czemu można zapewnić określone dostosowane zasoby, umowy SLA skierowane do klientów i gwarancje, ponieważ można niezależnie dostroić konto bazy danych każdego najemcy na potrzeby wydajności.

  • Zwiększone zabezpieczenia: Izolacja danych fizycznych pomaga zapewnić niezawodne zabezpieczenia, ponieważ klienci mogą włączyć klucze zarządzane przez klienta na poziomie konta dla każdego najemcy. Dane każdego użytkownika są izolowane według konta, a nie znajdują się w tym samym kontenerze.

  • Elastyczność: Dzierżawcy mogą w razie potrzeby włączyć funkcje na poziomie konta, takie jak replikacja geograficzna, przywracanie do punktu w czasie i klucze zarządzane przez klienta.

Kompromisy

  • Zwiększone zarządzanie: takie podejście jest bardziej złożone, ponieważ zarządzasz wieloma kontami usługi Azure Cosmos DB.

  • Wyższe koszty: więcej kont oznacza, że musisz aprowizować przepływność dla każdego zasobu, takiego jak bazy danych lub kontenery, w ramach konta dla każdego najemcy. Za każdym razem, gdy zasób aprowizuje jednostki (RU), koszty usługi Azure Cosmos DB rosną.

  • Ograniczenia zapytań: Wszyscy najemcy znajdują się na różnych kontach, więc aplikacje, które wysyłają zapytania do wielu najemców, wymagają wielu wywołań w logicznej części aplikacji.

Funkcje usługi Azure Cosmos DB na potrzeby wielotenancyjności

  • Funkcje zabezpieczeń: Ten model zapewnia zwiększoną izolację zabezpieczeń dostępu do danych za pośrednictwem Azure RBAC. Ten model zapewnia również izolację zabezpieczeń szyfrowania bazy danych na poziomie dzierżawy za pośrednictwem kluczy zarządzanych przez klienta.

  • Konfiguracja niestandardowa: możesz skonfigurować lokalizację konta bazy danych zgodnie z wymaganiami dzierżawy. Możesz również dostosować konfigurację funkcji usługi Azure Cosmos DB, takich jak replikacja geograficzna i klucze szyfrowania zarządzane przez klienta, zgodnie z wymaganiami każdej dzierżawy.

W przypadku korzystania z dedykowanego konta Azure Cosmos DB na dzierżawę należy wziąć pod uwagę maksymalną liczbę kont Azure Cosmos DB na subskrypcję platformy Azure.

Pełna lista modeli izolacji

Zapotrzebowanie na obciążenie Klucz partycji na najemcę (zalecane) Kontener na użytkownika (współdzielona przepustowość) Kontener dla najemcy (przepustowość dedykowana) Baza danych dla każdego dzierżawcy Konto bazy danych dla każdego najemcy (zalecane)
Zapytania między dzierżawami Łatwe (kontener działa jako granica dla zapytań) Ostateczna Ostateczna Ostateczna Ostateczna
Gęstość dzierżawy Wysoki (najniższy koszt na najemcę) Średni Niski Niski Niski
Usuwanie danych dzierżawy Łatwe Łatwe (oddanie kontenera po opuszczeniu lokatora) Łatwe (oddanie kontenera po opuszczeniu lokatora) Łatwe (porzucanie bazy danych po opuszczeniu dzierżawy) Łatwe (porzucanie bazy danych po opuszczeniu dzierżawy)
Izolacja zabezpieczeń dostępu do danych Należy zaimplementować w aplikacji Kontenerowe RBAC (kontrola dostępu oparta na rolach) Kontenerowe RBAC (kontrola dostępu oparta na rolach) Kontrola dostępu oparta na rolach bazy danych Kontrola dostępu oparta na rolach
Replikacja geograficzna Replikacja geograficzna dla każdej dzierżawy nie jest możliwa Grupowanie najemców w ramach kont bazy danych na podstawie wymagań Grupowanie najemców w ramach kont bazy danych na podstawie wymagań Grupowanie najemców w ramach kont bazy danych na podstawie wymagań Grupowanie najemców w ramach kont bazy danych na podstawie wymagań
Zapobieganie hałaśliwym sąsiadom Nie Nie Tak Tak Tak
Opóźnienie tworzenia nowego klienta Natychmiastowe Szybko Szybko Średni Powolny
Zalety modelowania danych Brak Kolokacja jednostek Kolokacja jednostek Wiele kontenerów do modelowania jednostek najemców Wiele kontenerów i baz danych do modelowania dzierżaw
klucz szyfrujący Takie same dla wszystkich najemców Takie same dla wszystkich najemców Takie same dla wszystkich najemców Takie same dla wszystkich najemców Klucz zarządzany przez klienta dla każdego najemcy
Wymagania dotyczące przepływności >0 jednostek RU na dzierżawcę >100 jednostek RU na najemcę >100 jednostek RU na dzierżawę (w przypadku włączenia autoskalowania, w przeciwnym razie >400 jednostek RU na dzierżawę) >400 jednostek RU na najemcę >400 jednostek RU na najemcę
Przykładowy przypadek użycia Aplikacje B2C Oferta Standardowa dla aplikacji B2B Oferta Premium dla aplikacji B2B Oferta Premium dla aplikacji B2B Oferta Premium dla aplikacji B2B

Model kontenera dla najemcy

Można udostępniać dedykowane kontenery dla każdego najemcy. Przeznaczone kontenery działają dobrze, gdy można połączyć przechowywane dane dla najemcy w jednym kontenerze. Ten model zapewnia większą izolację wydajności niż model partition-key-per-tenant. Zapewnia również zwiększoną izolację zabezpieczeń dostępu do danych za pośrednictwem Azure RBAC (kontroli dostępu opartej na rolach).

Jeśli używasz kontenera dla każdego najemcy, rozważ możliwość współdzielenia przepustowości z innymi najemcami, przypisując przepustowość na poziomie bazy danych. Rozważ ograniczenia i limity minimalnej liczby jednostek RU dla bazy danych oraz maksymalną liczbę kontenerów w bazie danych. Należy również rozważyć, czy najemcy wymagają gwarantowanej jakości wydajności i czy są podatni na problem hałaśliwego sąsiada. Po udostępnieniu przepływności na poziomie bazy danych obciążenie lub magazyn we wszystkich kontenerach powinny być stosunkowo jednolite. W przeciwnym razie może wystąpić problem z hałaśliwymi sąsiadami, jeśli masz jednego lub więcej dużych najemców. W razie potrzeby zaplanuj grupowanie tych użytkowników w różnych bazach danych w oparciu o wzorce obciążenia.

Alternatywnie można aprowizować dedykowaną przepływność dla każdego kontenera. Takie podejście działa dobrze w przypadku większych najemców oraz tych, którzy są zagrożeni problemem hałaśliwego sąsiada. Jednak bazowa przepustowość dla każdej dzierżawy jest wyższa, dlatego należy uwzględnić minimalne wymagania i potencjalne koszty tego modelu.

Jeśli model danych dzierżawy wymaga więcej niż jednej jednostki i jeśli wszystkie jednostki mogą współdzielić ten sam klucz partycji, możesz umieścić je w tym samym kontenerze. Jeśli jednak model danych najemcy jest bardziej złożony i wymaga jednostek, które nie mogą mieć tego samego klucza partycji, rozważ model bazy danych na najemcę lub model konta bazy danych na najemcę. Aby uzyskać więcej informacji, zobacz Modelowanie i partycjonowanie danych w usłudze Azure Cosmos DB.

Zarządzanie cyklem życia jest zwykle prostsze podczas dedykowania kontenerów do dzierżaw. Najemców można łatwo przenosić między modelami współużytkowanej i dedykowanej przepływności. W przypadku anulowania aprowizacji dzierżawy można szybko usunąć kontener.

Model bazy danych na lokatora

Możesz konfigurować bazy danych dla każdego klienta na tym samym koncie bazy danych. Podobnie jak model kontenera dla każdego najemcy, ten model zapewnia większą izolację wydajności niż model klucza partycji dla każdego najemcy. Zapewnia również zwiększoną izolację zabezpieczeń dostępu do danych za pośrednictwem Azure RBAC (kontroli dostępu opartej na rolach).

Podobnie jak w modelu konta na dzierżawcę, takie podejście zapewnia najwyższy poziom izolacji wydajności, ale zapewnia najniższą gęstość najemców. Użyj tej opcji, jeśli każdy najemca wymaga bardziej skomplikowanego modelu danych, niż to możliwe w modelu kontenera na najemcę. Możesz też postępować zgodnie z tym podejściem, jeśli tworzenie nowego najemcy musi być szybkie lub wolne od jakichkolwiek początkowych obciążeń. W przypadku niektórych platform tworzenia oprogramowania model osobnej bazy danych dla każdego najemcy może być jedynym poziomem izolacji wydajności, jaki obsługuje ta platforma. Takie struktury zwykle nie obsługują izolacji na poziomie jednostki (kontenera) i kolokacji jednostek.

Funkcje usługi Azure Cosmos DB, które obsługują wielodostępność

Partycjonowanie

Użyj partycji z kontenerami usługi Azure Cosmos DB, aby utworzyć kontenery używane przez wielu najemców. Zazwyczaj używasz identyfikatora dzierżawcy jako klucza partycji, ale możesz również rozważyć użycie wielu kluczy partycji dla jednego dzierżawcy. Dobrze zaplanowana strategia partycjonowania skutecznie implementuje wzorzec fragmentowania. Gdy masz duże kontenery, usługa Azure Cosmos DB rozmieszcza dzierżawy w wielu węzłach fizycznych, aby osiągnąć wysoki stopień skalowalności.

Rozważ użycie hierarchicznych kluczy partycji, aby zwiększyć wydajność rozwiązania wielodzierżawczego. Użyj hierarchicznych kluczy partycji, aby utworzyć klucz partycji zawierający wiele wartości. Można na przykład użyć hierarchicznego klucza partycji, który zawiera identyfikator dzierżawy, taki jak identyfikator GUID o wysokiej kardynalności, aby umożliwić niemal nieograniczone skalowanie. Możesz też określić hierarchiczny klucz partycji, który zawiera właściwość często używaną w zapytaniach. Takie podejście pomaga uniknąć zapytań obejmujących wiele partycji. Użyj hierarchicznych kluczy partycji, aby skalować się poza logiczny limit 20 GB przypadający na wartość klucza partycji i ograniczyć kosztowne zapytania typu fan-out.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Zarządzanie jednostkami RU

Model cenowy usługi Azure Cosmos DB jest oparty na liczbie jednostek RU/s, które aprowizujesz lub zużywasz. Usługa Azure Cosmos DB oferuje kilka opcji aprowizacji przepływności. W środowisku wielodostępnym wybór wpływa na wydajność i cenę zasobów usługi Azure Cosmos DB.

W przypadku najemców, którzy wymagają gwarantowanej wydajności i izolacji zabezpieczeń, zalecamy izolowanie najemców według konta bazy danych i przydzielanie RU do najemcy. W przypadku najemców, którzy mają mniej rygorystyczne wymagania, zalecamy izolowanie ich według klucza partycji. Ten model pozwala na udostępnianie jednostek RU między dzierżawami i optymalizowanie kosztów na dzierżawcę.

Alternatywny model najmu dla usługi Azure Cosmos DB obejmuje dostarczanie oddzielnych kontenerów dla każdego lokatora w ramach współdzielonej bazy danych. Użyj usługi Azure Cosmos DB, aby przydzielić jednostki RU do bazy danych, tak aby wszystkie kontenery mogły je współdzielić. Jeśli obciążenia dzierżawy zwykle nie nakładają się na siebie, takie podejście może pomóc zmniejszyć koszty operacyjne. Jednak takie podejście jest podatne na problem głośnego sąsiada, ponieważ kontener pojedynczej dzierżawy może zużywać nieproporcjonalną ilość współdzielonych aprowizowanych jednostek RU. Aby rozwiązać ten problem, najpierw zidentyfikuj hałaśliwych najemców. Następnie możesz opcjonalnie ustawić aprowizowaną przepływność dla określonego kontenera. Inne kontenery w bazie danych nadal współdzielą swoją przepustowość, ale uciążliwy użytkownik zużywa własną dedykowaną przepustowość.

Usługa Azure Cosmos DB udostępnia również warstwę bezserwerową, która odpowiada obciążeniom, które mają sporadycznie lub nieprzewidywalny ruch. Alternatywnie możesz użyć skalowania automatycznego, aby skonfigurować zasady określające skalowanie aprowizowanej przepływności. Możesz również skorzystać z pojemności chwilowej usługi Azure Cosmos DB, aby zmaksymalizować użycie aprowizowanej przepustowości, która w przeciwnym razie jest ograniczona przez limity szybkości. W rozwiązaniu wielodostępnym możesz połączyć wszystkie te podejścia, aby obsłużyć różne typy najemców.

Uwaga

Podczas planowania konfiguracji usługi Azure Cosmos DB należy wziąć pod uwagę limity przydziału i limity usług.

Aby monitorować koszty związane z każdym najemcą i nimi zarządzać, warto pamiętać, że każda operacja używająca Azure Cosmos DB API zawiera zużywane jednostki RU. Te informacje mogą być użyte do agregowania i porównywania rzeczywistych jednostek zasobów RU wykorzystywanych przez każdą dzierżawę. Następnie można zidentyfikować najemców, którzy mają różne charakterystyki wydajności.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Klucze zarządzane przez klienta

Niektórzy najemcy mogą wymagać użycia własnych kluczy szyfrowania. Usługa Azure Cosmos DB udostępnia funkcję klucza zarządzanego przez klienta. Ta funkcja jest stosowana na poziomie konta usługi Azure Cosmos DB. Jeśli więc dzierżawcy wymagają własnych kluczy szyfrowania, musisz użyć dedykowanych kont usługi Azure Cosmos DB do wdrożenia dzierżawców.

Aby uzyskać więcej informacji, zobacz Konfigurowanie kluczy zarządzanych przez klienta dla konta usługi Azure Cosmos DB przy użyciu usługi Azure Key Vault.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główni autorzy

  • Tara Bhatia | Menedżer programu, Azure Cosmos DB
  • Paul Burpo | Główny inżynier klienta, fasttrack dla platformy Azure
  • John Downs | Główny inżynier oprogramowania

Inni współautorzy:

  • Mark Brown | Główny menedżer pm, Azure Cosmos DB
  • Deborah Chen | Główny menedżer programu
  • Theo van Kraay | Starszy menedżer programu, Azure Cosmos DB
  • Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
  • Thomas Weiss | Główny menedżer programu
  • Vic Perdana | Architekt rozwiązań w chmurze — ISV Azure

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Dowiedz się więcej o wielodostępności i usłudze Azure Cosmos DB:

Zapoznaj się z innymi scenariuszami architektury usługi Azure Cosmos DB: