Istnieje wiele sposobów, aby rozważyć sposób pracy z dzierżawami w rozwiązaniu. Wybór podejścia zależy od tego, czy i jak udostępniasz zasoby między dzierżawami. Intuicyjnie możesz unikać udostępniania wszelkich zasobów, ale takie podejście szybko staje się kosztowne w miarę skalowania firmy i dołączania większej liczby dzierżaw.
Podczas rozważania różnych modeli wielodostępności warto najpierw wziąć pod uwagę sposób definiowania dzierżaw dla organizacji, czynników biznesowych i planowania skalowania rozwiązania. Ten artykuł zawiera wskazówki ułatwiające osobom podejmującym decyzje techniczne ocenę modeli dzierżawy i ich kompromisów.
Definiowanie dzierżawy
Najpierw należy zdefiniować dzierżawę dla swojej organizacji. Zastanów się, kim jest Twój klient. Innymi słowy, do kogo świadczysz usługi? Istnieją dwa typowe modele:
- Firma-firma (B2B). Jeśli twoi klienci są innymi organizacjami, prawdopodobnie zamapujesz dzierżawy na tych klientów. Należy jednak rozważyć, czy klienci mają działy (zespoły lub działy) i czy mają obecność w wielu krajach/regionach. Może być konieczne mapowania pojedynczego klienta na wiele dzierżaw, jeśli istnieją różne wymagania dla tych podgrup. Podobnie klient może chcieć zachować dwa wystąpienia usługi, aby zachować oddzielone od siebie środowiska programistyczne i produkcyjne. Ogólnie rzecz biorąc, jedna dzierżawa ma wielu użytkowników. Na przykład wszyscy pracownicy klienta są użytkownikami w ramach jednej dzierżawy.
- Firma-odbiorca (B2C). Jeśli klienci są konsumentami, często bardziej skomplikowane jest powiązanie klientów, dzierżaw i użytkowników. W niektórych scenariuszach każdy odbiorca może być oddzielną dzierżawą. Należy jednak rozważyć, czy rozwiązanie może być używane przez rodziny, grupy znajomych, kluby, stowarzyszenia lub inne grupy, które mogą wymagać dostępu do danych i zarządzania nimi. Na przykład usługa przesyłania strumieniowego muzyki może obsługiwać zarówno poszczególnych użytkowników, jak i rodzin, i może traktować każdy z tych typów kont inaczej, gdy rozdziela je na dzierżawy.
Definicja dzierżawy ma wpływ na niektóre elementy, które należy wziąć pod uwagę lub podkreślić podczas tworzenia architektury rozwiązania. Rozważmy na przykład następujące typy dzierżaw:
- Jeśli Dzierżawcy są poszczególnymi osobami lub rodzinami, może być szczególnie zaniepokojony sposobem obsługi danych osobowych oraz przepisami dotyczącymi suwerenności danych w każdej jurysdykcji, która służy.
- Jeśli dzierżawcy są firmami, może być konieczne pamiętanie o wymaganiach klientów dotyczących zgodności z przepisami, izolacji ich danych i upewnieniu się, że spełniasz określony cel poziomu usług (SLO), na przykład dostępność czasu pracy lub usługi.
Jak zdecydować, który model ma być używany?
Wybór modelu dzierżawy nie jest tylko decyzją techniczną. Jest to również decyzja komercyjna. Należy wziąć pod uwagę następujące pytania:
- Jakie są cele biznesowe?
- Czy twoi klienci zaakceptują wszystkie formy wielodostępności? Jak każdy model wielodostępności ma wpływ na wymagania dotyczące zgodności lub wymagania dotyczące zgodności klientów?
- Czy rozwiązanie z jedną dzierżawą będzie skalowane do przyszłych aspiracji wzrostu?
- Jak duży jest twój zespół operacyjny i ile zarządzania infrastrukturą można zautomatyzować?
- Czy klienci oczekują, że spełnisz umowy dotyczące poziomu usług (SLA), czy masz cele SLO, dla których dążysz?
Jeśli oczekujesz, że twoja firma będzie skalować do dużej liczby klientów, ważne jest wdrożenie udostępnionej infrastruktury. W przeciwnym razie konieczne będzie utrzymanie dużej i rosnącej floty wystąpień zasobów. Wdrożenie poszczególnych zasobów platformy Azure dla każdego klienta może być niezrównane, chyba że aprowizacja i użycie dedykowanej subskrypcji dla każdej dzierżawy. W przypadku współużytkowania tej samej subskrypcji platformy Azure w wielu dzierżawach mogą zacząć obowiązywać przydziały zasobów i limity zasobów platformy Azure, a koszty operacyjne wdrażania i ponownego konfigurowania tych zasobów rosną wraz z każdym nowym klientem.
Z drugiej strony, jeśli oczekujesz, że twoja firma będzie mieć tylko kilku klientów, warto rozważyć użycie zasobów z jedną dzierżawą przeznaczonych dla każdego klienta. Ponadto, jeśli wymagania dotyczące izolacji klientów są wysokie, podejście infrastruktury pojedynczej dzierżawy może być odpowiednie, mimo że jest bardziej kosztowne.
Dzierżawy i wdrożenia
Następnie należy określić, co oznacza dzierżawa dla konkretnego rozwiązania i czy należy odróżnić dzierżawy logiczne i wdrożenia.
Rozważmy na przykład usługę przesyłania strumieniowego muzyki. Początkowo możesz utworzyć rozwiązanie, które może łatwo obsługiwać tysiące (a nawet dziesiątki tysięcy) użytkowników. W miarę dalszego rozwoju może się okazać, że konieczne może być zduplikowanie rozwiązania lub niektórych jego składników w celu skalowania do nowego zapotrzebowania klientów. Oznacza to, że musisz określić, jak przypisać określonych klientów do określonych wystąpień rozwiązania. Klienci mogą być przypisywani losowo lub geograficznie albo przez wypełnienie pojedynczego wystąpienia, a następnie uruchomienie innego (pakowanie pojemnika). Prawdopodobnie trzeba jednak zachować rekord klientów i infrastrukturę, w której są dostępne dane i aplikacje, aby można było kierować ruch do odpowiedniej infrastruktury. W tym przykładzie możesz reprezentować każdego klienta jako oddzielną dzierżawę, a następnie mapować użytkowników na wdrożenie zawierające ich dane. Istnieje mapowanie jeden do wielu między dzierżawami i wdrożeniami, a dzierżawy można przenosić między wdrożeniami według własnego uznania.
Z kolei rozważmy firmę, która tworzy oprogramowanie w chmurze dla firm prawnych. Klienci mogą nalegać na posiadanie własnej dedykowanej infrastruktury w celu zachowania standardów zgodności. W związku z tym należy przygotować się do wdrożenia wielu różnych wystąpień rozwiązania i zarządzania nimi od samego początku. W tym przykładzie wdrożenie zawsze zawiera jedną dzierżawę, a dzierżawa jest mapowana na własne dedykowane wdrożenie.
Kluczową różnicą między dzierżawami i wdrożeniami jest sposób wymuszania izolacji. Gdy wiele dzierżaw współużytkuje pojedyncze wdrożenie (zestaw infrastruktury), zwykle polega się na kodzie aplikacji i identyfikatorze dzierżawy, który znajduje się w bazie danych, aby zachować oddzielne dane każdej dzierżawy. Jeśli masz dzierżawy z własnymi dedykowanymi wdrożeniami, mają własną infrastrukturę, dlatego kod może być mniej ważny, aby pamiętać, że działa w środowisku wielodostępnym.
Wdrożenia są czasami określane jako superdostępne lub sygnatury.
Po otrzymaniu żądania dla określonej dzierżawy należy zmapować je na wdrożenie, które przechowuje dane tej dzierżawy, jak pokazano poniżej:
Aby dowiedzieć się więcej, zobacz Mapowania żądań do dzierżaw.
Izolacja dzierżawy
Jednym z największych zagadnień związanych z projektowaniem architektury wielodostępnej jest poziom izolacji, którego potrzebuje każda dzierżawa. Izolacja może oznaczać różne rzeczy:
- Posiadanie pojedynczej udostępnionej infrastruktury z oddzielnymi wystąpieniami aplikacji i oddzielnymi bazami danych dla każdej dzierżawy.
- Udostępnianie niektórych typowych zasobów, ale przechowywanie innych zasobów oddzielnie dla każdej dzierżawy.
- Przechowywanie danych w oddzielnej infrastrukturze fizycznej. W chmurze ta konfiguracja może wymagać oddzielnych zasobów platformy Azure dla każdej dzierżawy. W skrajnych sytuacjach może to nawet oznaczać wdrożenie oddzielnej infrastruktury fizycznej przy użyciu dedykowanych hostów.
Zamiast myśleć o izolacji jako odrębnej właściwości, należy myśleć o tym jako o byciu w kontinuum. Możesz wdrożyć składniki architektury, które są mniej lub bardziej izolowane niż inne składniki w tej samej architekturze, w zależności od wymagań. Na poniższym diagramie przedstawiono kontinuum izolacji:
Poziom izolacji ma wpływ na wiele aspektów architektury, w tym następujące:
- Zabezpieczenia. Jeśli udostępniasz infrastrukturę między wieloma dzierżawami, należy zachować szczególną ostrożność, aby nie uzyskiwać dostępu do danych z jednej dzierżawy po powrocie odpowiedzi do innej. Potrzebujesz silnej podstawy dla strategii tożsamości i musisz wziąć pod uwagę zarówno tożsamość dzierżawy, jak i użytkownika w procesie autoryzacji.
- Koszt Udostępniona infrastruktura może być używana przez wiele dzierżaw, więc jest tańsza.
- Wydajność. Jeśli udostępniasz infrastrukturę, wydajność systemu może być większa niż większa ilość użytkowników, ponieważ zasoby mogą być zużywane szybciej. Problemy z wydajnością mogą zostać zaostrzone przez dzierżawców z nietypowymi wzorcami użycia.
- Niezawodność. Jeśli używasz jednego zestawu udostępnionej infrastruktury, problem z jednym składnikiem może spowodować awarię dla wszystkich dzierżaw.
- Czas reakcji na potrzeby poszczególnych dzierżaw. Podczas wdrażania infrastruktury dedykowanej dla jednej dzierżawy może być możliwe dostosowanie konfiguracji zasobów do wymagań tej konkretnej dzierżawy. Możesz nawet rozważyć tę możliwość w modelu cenowym, dzięki czemu klienci mogą płacić więcej za izolowane wdrożenia.
Architektura rozwiązania może mieć wpływ na dostępne opcje izolacji. Rozważmy na przykład architekturę rozwiązania trójwarstwowego:
- Warstwa interfejsu użytkownika może być udostępnioną wielodostępną aplikacją internetową ze wszystkimi dzierżawami, którzy uzyskują dostęp do jednej nazwy hosta.
- Warstwa środkowa może być warstwą aplikacji współużytkowanej z udostępnionymi kolejkami komunikatów.
- Warstwą danych mogą być izolowane bazy danych, tabele lub kontenery obiektów blob.
Możesz rozważyć użycie różnych poziomów izolacji w każdej warstwie. Przed osiągnięciem limitów przydziału i limitów platformy Azure należy podjąć decyzję o tym, co jest udostępniane i co jest izolowane, w tym o kosztach, złożoności, wymaganiach klientów i liczbie zasobów, które można wdrożyć.
Typowe modele dzierżawy
Po ustaleniu wymagań należy je ocenić pod kątem niektórych typowych modeli dzierżawy i odpowiednich wzorców wdrażania.
Zautomatyzowane wdrożenia z jedną dzierżawą
W zautomatyzowanym modelu wdrażania z jedną dzierżawą wdrażasz dedykowany zestaw infrastruktury dla każdej dzierżawy, jak pokazano w tym przykładzie:
Aplikacja jest odpowiedzialna za inicjowanie i koordynowanie wdrażania zasobów każdej dzierżawy. Zazwyczaj rozwiązania korzystające z tego modelu używają infrastruktury jako kodu (IaC) lub interfejsów API usługi Azure Resource Manager w szerokim zakresie. Możesz użyć tego podejścia, jeśli musisz aprowizować całkowicie oddzielne infrastruktury dla każdego z klientów. Rozważ użycie wzorca sygnatur wdrożenia podczas planowania wdrożenia.
Korzyści: Kluczową zaletą tego podejścia jest to, że dane dla każdej dzierżawy są izolowane, co zmniejsza ryzyko przypadkowego wycieku. To zabezpieczenie może być ważne dla niektórych klientów, którzy mają wysokie koszty związane ze zgodnością z przepisami. Ponadto dzierżawy są mało prawdopodobne, aby wpływać na wydajność systemu, problem, który jest czasami nazywany hałaśliwym problemem sąsiada . Aktualizacje i zmiany można wdrażać stopniowo w różnych dzierżawach, co zmniejsza prawdopodobieństwo awarii całego systemu.
Ryzyko: jeśli używasz tego podejścia, efektywność kosztowa jest niska, ponieważ nie udostępniasz infrastruktury między dzierżawami. Jeśli jedna dzierżawa wymaga pewnego kosztu infrastruktury, prawdopodobnie 100 dzierżaw wymaga 100 razy więcej kosztów. Ponadto ciągła konserwacja (na przykład stosowanie nowej konfiguracji lub aktualizacji oprogramowania) prawdopodobnie będzie czasochłonna. Rozważ zautomatyzowanie procesów operacyjnych i rozważ stopniowe stosowanie zmian w środowiskach. Należy również rozważyć inne operacje obejmujące wiele wdrożeń, takie jak raportowanie i analiza całej floty. Podobnie należy zaplanować sposób wykonywania zapytań dotyczących danych w wielu wdrożeniach i manipulowania nimi.
Wdrożenia w pełni wielodostępne
W odwrotnej skrajności można rozważyć wdrożenie w pełni wielodostępne, w którym wszystkie składniki są współużytkowane. Masz tylko jeden zestaw infrastruktury do wdrożenia i konserwacji, a wszystkie dzierżawy korzystają z niego, jak pokazano na poniższym diagramie:
Korzyści: ten model jest atrakcyjny, ponieważ rozwiązanie z udostępnionymi składnikami jest tańsze niż korzystanie z poszczególnych zasobów dla każdej dzierżawy. Nawet jeśli musisz wdrożyć wyższe warstwy lub jednostki SKU zasobów, aby uwzględnić zwiększone obciążenie, ogólny koszt wdrożenia jest często niższy niż koszt zestawu zasobów z jedną dzierżawą. Ponadto, jeśli użytkownik lub dzierżawa musi przenieść swoje dane do innej dzierżawy, może być możliwe zaktualizowanie identyfikatorów dzierżawy i kluczy. Być może nie trzeba migrować danych między dwoma oddzielnymi wdrożeniami.
Ryzyka:
Pamiętaj, aby oddzielić dane dla każdej dzierżawy i nie wyciekać danych między dzierżawami. Może być konieczne zarządzanie danymi fragmentowania. Ponadto może być konieczne zaniepokojenie skutkami, jakie mogą mieć poszczególne dzierżawy w całym systemie. Jeśli na przykład duża dzierżawa spróbuje wykonać duże zapytanie lub operację, może to mieć wpływ na inne dzierżawy.
Określ, jak śledzić i kojarzyć koszty platformy Azure z dzierżawami, jeśli to robisz, jest dla Ciebie ważne.
Konserwacja może być prostsza w przypadku pojedynczego wdrożenia, ponieważ trzeba zaktualizować tylko jeden zestaw zasobów. Jednak często jest to bardziej ryzykowne, ponieważ zmiany mogą mieć wpływ na całą bazę klientów.
Może być również konieczne rozważenie skali. Bardziej prawdopodobne jest osiągnięcie limitów skalowania zasobów platformy Azure w przypadku udostępnionego zestawu infrastruktury. Jeśli na przykład używasz konta magazynu w ramach rozwiązania, w miarę zwiększania skali liczba żądań do tego konta magazynu może osiągnąć limit możliwości obsługi konta magazynu. Aby uniknąć osiągnięcia limitu przydziału zasobów, możesz rozważyć wdrożenie puli wielu wystąpień zasobów (na przykład wielu klastrów usługi AKS lub kont magazynu). Możesz nawet rozważyć dystrybucję dzierżaw między zasobami wdrażanych w wielu subskrypcjach platformy Azure.
Prawdopodobnie istnieje ograniczenie do tego, jak daleko można skalować pojedyncze wdrożenie, a koszty tego mogą wzrosnąć nieliniowo. Jeśli na przykład masz pojedynczą udostępnioną bazę danych, po uruchomieniu na bardzo dużą skalę możesz wyczerpać jego przepływność i płacić coraz więcej za zwiększoną przepływność, aby nadążyć za zapotrzebowaniem.
Wdrożenia partycjonowane w pionie
Nie musisz wybierać jednej z skrajności tych skali. Zamiast tego można rozważyć partycjonowanie w pionie dzierżaw, stosując następujące podejście:
- Użyj kombinacji wdrożeń jednodostępnych i wielodostępnych. Możesz na przykład mieć większość warstw danych i aplikacji klientów w wielodostępnych infrastrukturach, ale wdrażać infrastrukturę z jedną dzierżawą dla klientów, którzy wymagają wyższej wydajności lub izolacji danych.
- Wdróż wiele wystąpień rozwiązania geograficznie i zamapuj każdą dzierżawę na określone wdrożenie. Takie podejście jest szczególnie skuteczne w przypadku dzierżaw w różnych lokalizacjach geograficznych.
Oto przykład ilustrujący wdrożenie współużytkowane dla niektórych dzierżaw i wdrożenie z jedną dzierżawą dla innego:
Korzyści: ponieważ nadal udostępniasz część infrastruktury, możesz uzyskać niektóre korzyści związane z kosztami korzystania z udostępnionych wdrożeń wielodostępnych. Możesz wdrożyć tańsze zasoby udostępnione dla niektórych klientów, takich jak klienci, którzy oceniają usługę przy użyciu wersji próbnej. Możesz nawet rozliczać klientów wyższą stawkę w celu korzystania z wdrożenia z jedną dzierżawą, co ułatwia odzyskanie niektórych kosztów.
Czynniki ryzyka: Baza kodu musi być zaprojektowana tak, aby obsługiwała wdrożenia wielodostępne i pojedyncze dzierżawy. Jeśli planujesz zezwolić na migrację między wdrożeniami, należy wziąć pod uwagę sposób migrowania klientów z wdrożenia wielodostępnego do własnego wdrożenia z jedną dzierżawą. Musisz również wiedzieć, które dzierżawy znajdują się w każdym wdrożeniu, aby można było przekazać informacje o problemach z systemem lub uaktualnieniach do odpowiednich klientów.
Wdrożenia partycjonowane w poziomie
Możesz również rozważyć partycjonowanie w poziomie wdrożeń. W ramach wdrożenia poziomego masz niektóre składniki udostępnione, ale utrzymujesz inne składniki z wdrożeniami z jedną dzierżawą. Można na przykład utworzyć pojedynczą warstwę aplikacji, a następnie wdrożyć poszczególne bazy danych dla każdej dzierżawy, jak pokazano na poniższym diagramie:
Korzyści: Wdrożenia partycjonowane w poziomie mogą pomóc w rozwiązaniu problemu z hałaśliwym sąsiadem: jeśli zidentyfikujesz, że większość obciążenia systemu jest spowodowana przez określone składniki, możesz wdrożyć oddzielne składniki dla każdej dzierżawy. Na przykład bazy danych mogą pochłaniać większość obciążenia systemu, ponieważ obciążenie zapytania jest wysokie. Jeśli pojedyncza dzierżawa wysyła dużą liczbę żądań do rozwiązania, wydajność bazy danych może mieć negatywny wpływ, ale bazy danych innych dzierżaw (i składniki udostępnione, takie jak warstwa aplikacji), pozostają nienaruszone.
Czynniki ryzyka: w przypadku wdrożenia partycjonowanego w poziomie nadal trzeba wziąć pod uwagę automatyczne wdrażanie składników i zarządzanie nimi, zwłaszcza składniki używane przez jedną dzierżawę.
Testowanie modelu izolacji
Niezależnie od wybranego modelu izolacji należy przetestować rozwiązanie, aby sprawdzić, czy dane jednej dzierżawy nie zostaną przypadkowo ujawnione do innej i że wszelkie hałaśliwe efekty sąsiada są akceptowalne. Rozważ użycie usługi Azure Chaos Studio , aby celowo wprowadzać błędy, które symulują awarie w świecie rzeczywistym i sprawdzają odporność rozwiązania nawet wtedy, gdy składniki działają nieprawidłowo.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- John Downs | Główny inżynier oprogramowania
Inni współautorzy:
- Chad Kittel | Główny inżynier oprogramowania
- Paolo Salvatori | Główny inżynier klienta, fasttrack dla platformy Azure
- Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.