Podejścia architektoniczne do przechowywania i zarządzania danymi w rozwiązaniach wielodzierżawczych

Dane są często uważane za najbardziej cenną część rozwiązania, ponieważ reprezentują twoje i cenne informacje biznesowe klientów. Ważne jest, aby dokładnie zarządzać danymi. Podczas planowania składników pamięci masowej lub danych dla systemu wielodostępnego należy zdecydować o podejściu do współdzielenia lub izolacji danych dzierżawców.

Ten artykuł zawiera wskazówki dotyczące kluczowych zagadnień i wymagań architektów rozwiązań podczas podejmowania decyzji o podejściu do przechowywania danych w systemie wielodostępnym. W tym artykule opisano również niektóre typowe wzorce zastosowania wielodostępności w usługach magazynowania i danych oraz niektóre antywzorce, aby ich uniknąć. Zawiera również ukierunkowane wskazówki dotyczące niektórych konkretnych scenariuszy.

Kluczowe zagadnienia i wymagania

Ważne jest, aby wziąć pod uwagę podejścia używane do magazynowania i usług danych z kilku perspektyw, w tym filarów platformy Azure Well-Architected Framework.

Skala

Podczas pracy z usługami, które przechowują dane, należy wziąć pod uwagę liczbę dzierżaw, ilość danych i oczekiwane obciążenie — zarówno dla każdej dzierżawy indywidualnie, jak i w agregacji. Te czynniki, wraz z konfiguracją usługi i odpowiednimi limitami zasobów i subskrypcji, wpływają na to, ile pojemności może zapewnić zasób i ile dzierżaw może obsługiwać.

Wraz z rozwojem coraz częściej korzystasz z jasnej strategii skalowania zasobów danych i magazynu oraz automatyzowania zarządzania nimi. Użyj testów wydajnościowych i planowania przepustowości, aby określić, kiedy należy dodać zasoby, i odpowiednio zaplanować skalowanie w poziomie, zanim zbliżysz się do limitu usługi lub subskrypcji.

Przewidywalność wydajności

Wielodostępne usługi danych i magazynowania są podatne na problem z hałaśliwym sąsiadem. Ważne jest, aby wziąć pod uwagę, czy dzierżawcy mogą wpływać na wydajność siebie nawzajem. Rozważmy na przykład, czy dzierżawcy mają nakładające się szczyty w ich wzorcach użycia w czasie. Należy również rozważyć, czy wszyscy klienci korzystają z rozwiązania w tym samym czasie każdego dnia i czy żądania są równomiernie dystrybuowane. Czynniki te wpływają na poziom izolacji, który należy uwzględnić w projekcie, ilość zasobów, które trzeba zapewnić, oraz stopień, w jakim dzierżawcy mogą dzielić się zasobami.

Ważne jest, aby w ramach tej decyzji wziąć pod uwagę limity przydziału zasobów i żądań platformy Azure . Załóżmy na przykład, że wdrażasz pojedyncze konto magazynowe, aby zawierało wszystkie dane dzierżawców. Jeśli przekroczysz określoną liczbę operacji przechowywania danych na sekundę, usługa Azure Storage odrzuci żądania aplikacji, co wpływa na wszystkich najemców. To zachowanie jest nazywane ograniczaniem przepustowości. Ważne jest, aby monitorować żądania ograniczone.

Izolacja danych

Podczas projektowania rozwiązania, które zawiera wielodostępne usługi danych, istnieją różne opcje i poziomy izolacji danych, które mają własne korzyści i kompromisy. Rozważ następujące przykłady:

  • W przypadku korzystania z usługi Azure Cosmos DB można wdrożyć oddzielne kontenery dla każdej dzierżawy, a także udostępniać bazy danych i konta między wieloma dzierżawami. Alternatywnie możesz rozważyć wdrożenie różnych baz danych lub nawet konta dla każdego najemcy, w zależności od wymaganego poziomu izolacji.

  • Gdy używasz usługi Azure Storage do przechowywania danych obiektów blob, możesz wdrożyć oddzielne kontenery obiektów blob dla każdego dzierżawcy lub oddzielne konta magazynu.

  • W przypadku korzystania z usługi Azure SQL można użyć oddzielnych tabel w udostępnionych bazach danych lub wdrożyć oddzielne bazy danych lub serwery dla każdej dzierżawy.

  • W przypadku wszystkich usług platformy Azure można rozważyć wdrożenie zasobów w ramach jednej wspólnej subskrypcji platformy Azure lub użyć wielu subskrypcji platformy Azure, a nawet jednej subskrypcji dla każdego dzierżawcy.

Nie ma jednego rozwiązania, które działa w każdym scenariuszu. Wybrana opcja zależy od kilku czynników i wymagań dzierżawy. Jeśli na przykład projektujesz rozwiązanie typu "klient-klient" (B2C), warto mieć jeden magazyn danych dla wszystkich danych. Jeśli jednak dzierżawcy muszą spełniać określone standardy zgodności lub przepisów, może być konieczne zastosowanie wyższego poziomu izolacji.

Podobnie może istnieć wymagania handlowe dotyczące fizycznego izolowania danych klientów lub może być konieczne wymuszenie izolacji, aby uniknąć problemu hałaśliwego sąsiada. Jeśli którykolwiek z poniższych warunków ma zastosowanie, może być konieczne odizolowanie dzierżaw od innych lub grupowanie ich z dzierżawami, które mają podobne zasady:

  • Dzierżawcy muszą używać własnych kluczy szyfrowania
  • Najemcy mają indywidualne zasady tworzenia kopii zapasowych i przywracania danych
  • Dzierżawcy muszą mieć swoje dane przechowywane w różnych lokalizacjach geograficznych

Złożoność implementacji

Ważne jest, aby wziąć pod uwagę złożoność implementacji. Dobrym rozwiązaniem jest utrzymanie architektury tak proste, jak to możliwe, przy jednoczesnym spełnieniu wymagań. Unikaj zatwierdzania architektury, która może stać się coraz bardziej złożona podczas skalowania lub architektury, do której nie masz zasobów ani wiedzy fachowej potrzebnych do jej opracowania i utrzymania.

Podobnie, jeśli rozwiązanie nie musi być skalowane do dużej liczby dzierżaw lub jeśli nie martwisz się o wydajność lub izolację danych, lepiej jest zachować proste rozwiązanie i uniknąć dodawania niepotrzebnej złożoności.

Szczególnym problemem dla rozwiązań danych z wieloma użytkownikami jest poziom personalizacji, którą obsługujesz. Na przykład możesz zezwolić najemcy na rozszerzenie modelu danych lub zastosowanie niestandardowych reguł przetwarzania danych. Upewnij się, że projektujesz zgodnie z tym wymaganiem od samego początku. Unikaj tworzenia rozwidleń lub zapewniania infrastruktury dopasowanej dla poszczególnych dzierżawców. Dostosowana infrastruktura hamuje możliwość skalowania, testowania rozwiązania i wdrażania aktualizacji. Zamiast tego rozważ użycie flag funkcji i innych form konfiguracji dzierżawy.

Złożoność zarządzania i operacji

Zastanów się, jak planujesz obsługiwać rozwiązanie i jak podejście wielodostępności wpływa na operacje i procesy.

  • Zarządzanie: Rozważ operacje zarządzania, takie jak regularne działania konserwacyjne. Jeśli używasz wielu serwerów, magazynów plików lub baz danych, zaplanuj sposób rozpoczynania i monitorowania działań konserwacyjnych dla zasobów każdego najemcy.

  • Monitorowanie i pomiary: Jeśli monitorujesz lub mierzysz swoich najemców, rozważ sposób, w jaki Twoje rozwiązanie raportuje metryki i czy może łatwo powiązać metryki z najemcą, który wywołał żądanie.

  • Reporting: Zastanów się, czy należy raportować zagregowane dane dla wielu izolowanych dzierżawców. W miarę skalowania rozwiązania staje się uciążliwe uruchamianie zapytań w poszczególnych bazach danych i agregowanie wyników. Inne podejście polega na tym, że aplikacje każdej dzierżawy publikują dane w scentralizowanym magazynie danych.

  • Aktualizacje schematu: Jeśli używasz bazy danych, która wymusza schemat, zaplanuj sposób wdrażania aktualizacji schematu w całej infrastrukturze. Zastanów się, w jaki sposób aplikacja wie, której wersji schematu używać dla zapytań bazy danych danego klienta.

  • Wymagania: Weź pod uwagę wymagania dotyczące wysokiej dostępności najemców, takie jak umowy o poziomie świadczonej usługi (SLA) w zakresie czasu działania, oraz wymagania dotyczące odzyskiwania po awarii, takie jak cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO). Jeśli najemcy mają różne oczekiwania, upewnij się, że możesz spełnić wymagania każdego z nich.

  • Migracja: Zastanów się, czy chcesz umożliwić dzierżawcom przejście do innego typu usługi, innego wdrożenia lub innego regionu. Jeśli planujesz oferować tę funkcję, twórz procesy i narzędzia, aby upewnić się, że jest to powtarzalny i bezpieczny proces.

  • Odzyskiwanie i cykl życia dzierżawcy: Zastanów się, jak podejście do izolacji danych wpływa na procesy tworzenia kopii zapasowych, przywracania, migracji i wycofywania. We współdzielonej bazie danych przywrócenie pojedynczego dzierżawcy może wymagać przywrócenia bazy danych w oddzielnym zasobie i selektywnego odzyskania danych tego dzierżawcy. Bazy danych podzielone na fragmenty lub dedykowane bazy danych mogą zapewnić bardziej szczegółowe odtwarzanie, ale odtworzenie fragmentu może nadal wpływać na wielu dzierżawców. Zautomatyzuj procesy wdrażania dzierżawcy, migracji, przechowywania danych i wycofywania dzierżawcy, tak aby pozostawały one powtarzalne wraz z rozwojem rozwiązania.

Koszt

Ogólnie rzecz biorąc, im większa gęstość najemców w infrastrukturze wdrożeniowej, tym niższy koszt aprowizacji tej infrastruktury. Jednak współdzielona infrastruktura zwiększa prawdopodobieństwo problemów, takich jak hałaśliwy problem sąsiada, więc należy dokładnie rozważyć kompromisy.

Podejścia i wzorce do rozważenia

Kilka wzorców projektowych z Centrum architektury platformy Azure jest istotnych dla wielodostępnych usług magazynowania i danych. Możesz konsekwentnie podążać za jednym wzorcem. Możesz też rozważyć mieszanie i dopasowywanie wzorców. Na przykład możesz użyć bazy danych z wieloma dzierżawcami dla większości dzierżawców, ale wdrożyć dedykowane instancje dla pojedynczych dzierżawców, którzy płacą więcej lub mają nietypowe wymagania.

Wzorzec stempli wdrożeniowych

Aby uzyskać więcej informacji na temat używania wzorca pieczęci wdrożeniowych do obsługi rozwiązania multimodalnego, zobacz Omówienie.

Wskazówka

W przypadku rozwiązań wielodostępnych dobrą praktyką jest utworzenie znaczników wdrożenia. To zalecenie ma zastosowanie nawet wtedy, gdy używasz wielodostępnej bazy danych lub baz danych podzielonych na fragmenty w ramach sygnatury. Modelując rozwiązanie jako pieczęć, można je łatwo ponownie wdrożyć, gdy pojawią się nowe możliwości biznesowe.

Udostępnione wielodostępne bazy danych i magazyny plików

Możesz rozważyć wdrożenie udostępnionej wielodostępnej bazy danych, konta magazynu lub udziału plików i udostępnienie go we wszystkich dzierżawach.

Diagram przedstawiający pojedynczą współdzieloną bazę danych dla danych wszystkich dzierżawców.

Takie podejście zapewnia najwyższą gęstość najemców w stosunku do infrastruktury, co przekłada się na najniższe koszty finansowe spośród wszystkich rozwiązań. Często zmniejsza to obciążenie związane z zarządzaniem, ponieważ istnieje pojedyncza baza danych lub zasób do zarządzania, tworzenia kopii zapasowych i zabezpieczania.

Jednak podczas pracy z udostępnioną infrastrukturą należy wziąć pod uwagę następujące wady:

  • Limity skalowania: W przypadku korzystania z jednego zasobu należy wziąć pod uwagę obsługiwaną skalę i limity tego zasobu. Jeśli na przykład twoja architektura opiera się na pojedynczej udostępnionej bazie danych, maksymalny rozmiar bazy danych lub magazynu plików lub maksymalne limity przepływności, ostatecznie staną się twardym blokiem. Przed wybraniem tego wzorca należy dokładnie rozważyć maksymalną skalę, którą należy osiągnąć i porównać z bieżącymi i przyszłymi limitami.

  • Hałaśli sąsiedzi:Problem z hałaśliwym sąsiadem może stać się czynnikiem, zwłaszcza jeśli masz dzierżawy, które są zajęte lub generują wyższe obciążenia niż inne. Rozważ zastosowanie wzorca ograniczania przepustowości lub wzorca ograniczania szybkości w celu ograniczenia tych skutków.

  • Pomiar zużycia najemców: Zastanów się, czy należy zmierzyć zużycie poszczególnych najemców. Niektóre usługi danych, takie jak Azure Cosmos DB, zapewniają raportowanie użycia zasobów dla każdej transakcji. Możesz śledzić te informacje i agregować je, aby zmierzyć wykorzystanie dla każdego najemcy. Inne usługi nie zapewniają tego samego poziomu szczegółowości. Na przykład, gdy korzystasz z magazynu współdzielonego, sprawdź, czy wybrana usługa i warstwa cenowa udostępniają metryki na poziomie granicy izolacji dzierżawy, z której korzystasz. Jeśli tak nie jest, rozważ użycie oddzielnych zasobów lub pomiarów na poziomie aplikacji.

  • Wymagania dotyczące dzierżawy: Dzierżawcy mogą mieć różne wymagania dotyczące zabezpieczeń, kopii zapasowych, dostępności lub lokalizacji przechowywania. Jeśli te wymagania nie są zgodne z konfiguracją pojedynczego zasobu, być może nie będzie można ich uwzględnić.

  • Dostosowywanie schematu: W przypadku pracy z relacyjną bazą danych lub innym scenariuszem, gdzie schemat danych jest istotny, dostosowanie schematu na poziomie dzierżawców jest trudne.

Sharding pattern (Wzorzec fragmentowania)

Wzorzec fragmentowania obejmuje wdrażanie wielu oddzielnych baz danych nazywanych fragmentami, które przechowują dane jednego lub więcej najemców. W przeciwieństwie do sygnatur wdrażania fragmenty nie oznaczają, że cała infrastruktura jest duplikowana. Możesz dzielić na części bazy danych bez duplikowania lub dzielenia na części innej infrastruktury w rozwiązaniu.

Diagram przedstawiający bazę danych podzielonych na fragmenty. Jedna baza danych zawiera dane dla dzierżaw A i B, a druga baza danych zawiera dane dla dzierżawy C.

Dzielenie na fragmenty jest ściśle związane z partycjonowaniem, a terminy są często używane zamiennie. Zapoznaj się ze wskazówkami dotyczącymi partycjonowania danych poziomych, pionowych i funkcjonalnych.

Wzorzec fragmentowania jest skalowalny do dużej liczby najemców. W zależności od obciążenia może być również możliwe osiągnięcie wysokiej gęstości dzierżawców na fragmenty, co może obniżyć koszty. Możesz użyć wzorca fragmentowania, aby rozwiązać problem z limitami przydziału, limitami i ograniczeniami subskrypcji i usług platformy Azure.

Niektóre magazyny danych, takie jak Azure Cosmos DB, zapewniają natywną obsługę fragmentowania lub partycjonowania. Podczas pracy z innymi rozwiązaniami, takimi jak Azure SQL, może być bardziej złożone utworzenie infrastruktury fragmentowania i skierowanie żądań do poprawnego fragmentu dla danej dzierżawy.

Fragmentowanie utrudnia również obsługę różnic w konfiguracji na poziomie dzierżawy i umożliwienie klientom udostępniania własnych kluczy szyfrowania.

Aplikacja wielodzierżawcza z dedykowanymi bazami danych dla każdego dzierżawcy

Innym powszechnym podejściem jest wdrożenie pojedynczej wielodostępnej aplikacji z dedykowanymi bazami danych dla każdego najemcy.

Diagram przedstawiający różne bazy danych dla każdego dzierżawcy.

W tym modelu dane każdego klienta są odizolowane od danych innych klientów, a ty możesz wspierać pewien stopień dostosowywania dla każdego klienta.

Koszt tego podejścia może być wyższy niż w modelach hostingu współdzielonego, ponieważ zapewniasz dedykowane zasoby danych dla każdego najemcy. Jednak platforma Azure oferuje kilka opcji, które można rozważyć, aby podzielić koszt hostowania poszczególnych zasobów danych w wielu dzierżawach. Na przykład podczas pracy z usługą Azure SQL Database można rozważyć elastyczne pule. W przypadku usługi Azure Cosmos DB można aprowizować przepływność dla bazy danych, a przepływność jest współdzielona między kontenerami w tej bazie danych. Jednak takie podejście nie jest odpowiednie, gdy potrzebujesz gwarantowanej wydajności dla każdego kontenera.

W tym podejściu, ponieważ tylko elementy danych są wdrażane indywidualnie dla każdego najemcy, prawdopodobnie można osiągnąć wysoką gęstość pozostałych komponentów w rozwiązaniu i obniżyć koszty tych komponentów.

Uwaga / Notatka

Ważne jest, aby podczas konfigurowania baz danych dla dzierżaw używać automatycznych metod wdrażania. W przeciwnym razie złożoność ręcznego wdrażania baz danych i zarządzania nimi staje się przytłaczająca.

Wzorzec geode

Wzorzec Geode został zaprojektowany specjalnie dla rozwiązań rozproszonych geograficznie, w tym rozwiązań wielonajemcowych. Obsługuje wysokie obciążenie i wysoki poziom odporności. Jeśli zaimplementujesz wzorzec geode, warstwa danych musi być w stanie replikować dane między regionami geograficznymi i powinna obsługiwać zapisy w wielu lokalizacjach geograficznych.

Diagram przedstawiający wzorzec Geode z bazami danych wdrożonymi w wielu regionach, które są ze sobą synchronizowane.

Usługa Azure Cosmos DB udostępnia operacje zapisu w wielu regionach w celu obsługi tego wzorca, a zarządzane wystąpienie Azure dla Apache Cassandra obsługuje klastry z wieloma regionami. Inne usługi danych zwykle nie mogą obsługiwać tego wzorca bez znaczącego dostosowania.

Antywzorce, których należy unikać

Podczas tworzenia wielodostępnych usług danych ważne jest, aby uniknąć sytuacji, które hamują możliwość skalowania.

W przypadku relacyjnych baz danych te antywzorce obejmują:

  • Izolacja oparta na tabelach. Podczas pracy w jednej bazie danych unikaj tworzenia poszczególnych tabel dla każdego najemcy. Pojedyncza baza danych nie może obsługiwać dużej liczby dzierżaw podczas korzystania z tego podejścia i staje się coraz trudniej wykonywać zapytania o dane, zarządzać nimi i aktualizować je. Zamiast tego rozważ użycie pojedynczego zestawu tabel multitenancy z kolumną identyfikatora klienta. Alternatywnie można użyć zalecanego wzorca do wdrożenia oddzielnych baz danych dla każdego najemcy.

  • Dostosowywanie dzierżawców na poziomie kolumny. Unikaj aktualizacji schematu, które mają zastosowanie tylko do jednej dzierżawy. Wyobraź sobie na przykład, że masz pojedynczą wielodostępną bazę danych. Unikaj dodawania nowej kolumny, aby spełnić wymagania określonej dzierżawy. Może to być akceptowalne w przypadku kilku dostosowań, ale ta metoda szybko staje się niezarządzana, jeśli masz wiele dostosowań do rozważenia. Zamiast tego rozważ zmianę modelu danych, aby śledzić niestandardowe dane dla każdego najemcy w dedykowanej tabeli.

  • Ręczne zmiany schematu. Unikaj ręcznego aktualizowania schematu bazy danych, nawet jeśli masz tylko jedną udostępnioną bazę danych. Łatwo jest utracić śledzenie stosowanych aktualizacji, a jeśli trzeba skalować w poziomie do większej liczby baz danych, trudno jest zidentyfikować prawidłowy schemat do zastosowania. Zamiast tego zbuduj narzędzia lub zautomatyzowany potok do wdrożenia zmian schematu i używaj go konsekwentnie. Śledź wersję schematu używaną dla każdej dzierżawy w dedykowanej bazie danych lub tablicy przeszukiwania.

  • Zależności wersji. Unikaj zależności aplikacji od pojedynczej wersji schematu bazy danych. W miarę skalowania może być konieczne zastosowanie aktualizacji schematu w różnych momentach dla różnych najemców. Zamiast tego upewnij się, że wersja aplikacji jest kompatybilna wstecz z co najmniej jedną poprzednią wersją schematu, a destrukcyjne zmiany w schemacie są rozłożone na wiele wersji, aby umożliwić wycofanie zmian.

Baz danych

Istnieją pewne funkcje, które mogą być przydatne w przypadku wielodostępności. Jednak te funkcje nie są dostępne we wszystkich usługach bazy danych. Zastanów się, czy podczas decydowania o usłudze do użycia w danym scenariuszu są potrzebne następujące funkcje:

  • Zabezpieczenia na poziomie wiersza mogą zapewnić izolację danych konkretnych dzierżawców w wspólnej bazie danych wielodostępnej. Ta funkcja jest dostępna w niektórych bazach danych, takich jak SQL Database i Azure Database for PostgreSQL.

    W przypadku korzystania z zabezpieczeń na poziomie wiersza należy upewnić się, że tożsamość użytkownika i tożsamość dzierżawy są propagowane za pośrednictwem aplikacji i do magazynu danych z każdym zapytaniem. Takie podejście może być złożone do projektowania, implementowania, testowania i konserwacji. Wiele wielodostępnych rozwiązań nie korzysta z zabezpieczeń na poziomie wiersza z powodu tych złożoności.

  • Szyfrowanie na poziomie dzierżawy może być wymagane do obsługi dzierżaw, które udostępniają własne klucze szyfrowania danych. Ta funkcja jest dostępna w programach SQL Server i Azure SQL w ramach funkcji Always Encrypted. Usługa Azure Cosmos DB udostępnia klucze zarządzane przez klienta na poziomie konta, a także obsługuje funkcję Always Encrypted.

  • Buforowanie zasobów umożliwia udostępnianie zasobów i ich kosztów między wieloma bazami danych lub kontenerami. Ta funkcja jest dostępna w elastycznych pulach usługi SQL Database, w usłudze Azure SQL Managed Instance i przepływności bazy danych usługi Azure Cosmos DB.

  • Shardowanie i partycjonowanie ma silniejszą natywną obsługę w niektórych usługach niż w innych. Ta funkcja jest dostępna w usłudze Azure Cosmos DB przy użyciu partycjonowania logicznego i fizycznego. Chociaż usługa SQL Database nie obsługuje natywnie fragmentowania, udostępnia narzędzia fragmentowania do obsługi tego typu architektury.

Ponadto w przypadku utrzymania floty relacyjnych baz danych lub innych baz danych opartych na schemacie należy wziąć pod uwagę, gdzie powinien zostać wyzwolony proces uaktualniania schematu. W małym środowisku baz danych można rozważyć użycie pipeline wdrożeniowego w celu wdrożenia zmian schematu. Wraz ze wzrostem liczby baz danych, lepszym rozwiązaniem może być wykrycie przez warstwę aplikacji wersji schematu dla konkretnej bazy danych, aby mogła zainicjować proces aktualizacji.

Przechowywanie plików i obiektów blob

Rozważ podejście używane do izolowania danych na koncie magazynowym. Możesz na przykład wdrożyć oddzielne konta magazynu dla każdej dzierżawy lub udostępnić konta magazynu i wdrożyć poszczególne kontenery. Alternatywnie możesz utworzyć udostępnione kontenery obiektów blob, a następnie użyć ścieżki obiektu blob do oddzielenia danych dla każdego klienta. Rozważ limity i limity przydziału subskrypcji platformy Azure oraz starannie zaplanuj wzrost, aby zapewnić skalowanie zasobów platformy Azure w celu zapewnienia obsługi przyszłych potrzeb.

Jeśli używasz kontenerów udostępnionych, należy dokładnie zaplanować strategię uwierzytelniania i autoryzacji, aby upewnić się, że dzierżawcy nie będą mogli uzyskiwać dostępu do danych. Podczas zapewniania klientom dostępu do zasobów przechowywania danych należy wziąć pod uwagę wzorzec klucza dostępu tymczasowego.

Alokacja kosztu

Rozważ sposób mierzenia zużycia i przydzielania kosztów dzierżawcom na potrzeby korzystania z udostępnionych usług danych. Jeśli to możliwe, należy użyć wbudowanych metryk zamiast obliczać własne. Jednak w przypadku udostępnionej infrastruktury trudno jest podzielić dane telemetryczne dla poszczególnych najemców i może być konieczne rozważenie niestandardowego pomiaru na poziomie aplikacji.

Ogólnie rzecz biorąc, usługi cloud-native, takie jak Azure Cosmos DB i Azure Blob Storage, zapewniają bardziej szczegółowe metryki do śledzenia i modelowania użycia dla określonego tenanta. Na przykład usługa Azure Cosmos DB zapewnia zużytą przepływność dla każdego żądania i odpowiedzi.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

  • John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure

Inni współautorzy:

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

Aby uzyskać więcej informacji na temat wielodostępności i określonych usług platformy Azure, zobacz następujące zasoby:

  • Last updated on