Udostępnij przez

Podejścia architektoniczne do przetwarzania w rozwiązaniach wielodostępnych

Większość rozwiązań opartych na chmurze składa się z zasobów obliczeniowych. Te zasoby mogą obejmować warstwy sieci Web i aplikacji, procesory wsadowe, zaplanowane zadania lub wyspecjalizowane zasoby, takie jak procesory GPU i obliczenia o wysokiej wydajności. Rozwiązania wielodostępne często korzystają ze współużytkowanych zasobów obliczeniowych, ponieważ większa gęstość dzierżaw dla każdej infrastruktury obniża koszty operacyjne i upraszcza zarządzanie. Należy wziąć pod uwagę wymagania dotyczące izolacji i implikacje współużytkowanej infrastruktury.

Ten artykuł zawiera wskazówki dotyczące kluczowych zagadnień i wymagań architektów rozwiązań, które należy wziąć pod uwagę podczas planowania wielodostępnej warstwy obliczeniowej. Te wytyczne obejmują typowe wzorce stosowania wielodzierżawczości do usług obliczeniowych oraz wzorce, których należy unikać.

Kluczowe zagadnienia i wymagania

Zarówno wielodostępność, jak i wybrany model izolacji mają wpływ na skalowanie, wydajność, zarządzanie stanem i zabezpieczenia zasobów obliczeniowych. W poniższych sekcjach omówiono kluczowe decyzje, które należy podjąć podczas planowania rozwiązania obliczeniowego z obsługą wielu użytkowników.

Skala

Systemy muszą działać odpowiednio w miarę zmian zapotrzebowania. W miarę wzrostu liczby dzierżaw i ruchu może być konieczne skalowanie zasobów w celu dopasowania ich do rosnącego zapotrzebowania i utrzymania akceptowalnej wydajności. Podobnie, gdy liczba aktywnych użytkowników lub ilość ruchu spada, należy automatycznie zmniejszyć pojemność obliczeniową, aby obniżyć koszty. Należy jednak zminimalizować wszelkie zakłócenia dla użytkowników podczas dostosowywania pojemności.

W przypadku wdrażania dedykowanych zasobów dla każdej dzierżawy masz elastyczność w skalowaniu zasobów każdej dzierżawy niezależnie. W rozwiązaniu, w którym zasoby obliczeniowe są współużytkowane przez wiele dzierżaw, skalowanie tych zasobów umożliwia wszystkim dzierżawcom korzystanie ze zwiększonej pojemności. Jednak wszyscy najemcy cierpią, gdy skala jest niewystarczająca do obsługi ich całkowitego obciążenia. Aby uzyskać więcej informacji, zobacz Antywzorzec Noisy Neighbor.

Podczas tworzenia rozwiązań w chmurze możesz wybrać, czy skalować w poziomie, czy w pionie. W rozwiązaniu wielodostępnym, które ma rosnącą liczbę dzierżaw, skalowanie w poziomie często zapewnia większą elastyczność i wyższy ogólny limit skali.

Problemy z wydajnością często pozostają niezauważone, dopóki aplikacja nie jest obciążona. Możesz użyć w pełni zarządzanej usługi, takiej jak testowanie obciążenia platformy Azure, aby dowiedzieć się, jak aplikacja działa pod obciążeniem.

Wyzwalacze skalowania

Niezależnie od podejścia używanego do skalowania zazwyczaj należy zaplanować wyzwalacze, które powodują skalowanie składników. W przypadku udostępnionych składników należy wziąć pod uwagę schematy obciążeń każdego podmiotu najemczego, aby upewnić się, czy zaprogramowana pojemność spełnia łączne wymagane zapotrzebowanie. Takie podejście pomaga zapobiegać rywalizacji o zasoby i zmniejsza prawdopodobieństwo wystąpienia problemu dzierżawców z hałaśliwym sąsiadem. Możesz również zaplanować skalowalność, biorąc pod uwagę liczbę najemców. Jeśli na przykład mierzysz zasoby używane do obsługi 100 dzierżaw, podczas dołączania kolejnych dzierżaw możesz zaplanować skalowanie, aby zasoby były dwukrotnie większe dla każdej dodatkowej 100 dzierżaw.

Państwo

Zasoby obliczeniowe mogą być bezstanowe lub mogą być stanowe. Składniki bezstanowe nie utrzymują żadnych danych między żądaniami. Z perspektywy skalowalności, składniki bezstanowe są często łatwe do zwiększania skali, ponieważ można szybko dodawać nowych pracowników, instancje lub węzły. Składniki bezstanowe mogą również natychmiast rozpocząć przetwarzanie żądań. Jeśli architektura obsługuje zmianę przeznaczenia wystąpienia, możesz również ponownie przypisać wystąpienia z jednego najemcy do innego najemcy.

Zasoby stanowe można dalej podzielić na podstawie typu stanu, który utrzymują. Stan trwały to dane, które muszą być przechowywane trwale. W rozwiązaniach w chmurze unikaj przechowywania stanu trwałego w warstwie obliczeniowej. Zamiast tego należy używać usług magazynu, takich jak bazy danych lub konta magazynu. Stan przejściowy to dane przechowywane tymczasowo. Zawiera on pamięci podręczne tylko do odczytu i magazyn plików tymczasowych na dyskach lokalnych.

Stan przejściowy jest często przydatny do zwiększenia wydajności warstwy aplikacyjnej przez zmniejszenie liczby żądań do usług zaplecza magazynowania. Na przykład w przypadku używania pamięci podręcznej w pamięci może być możliwe obsłużenie żądań odczytu bez nawiązywania połączenia z bazą danych i bez wykonywania intensywnego zapytania, które zostało ostatnio wykonane podczas obsługi innego żądania.

W aplikacjach wrażliwych na opóźnienia koszt nawodnienia pamięci podręcznej może stać się znaczący. Rozwiązanie dla wielu użytkowników może pogorszyć ten problem, jeśli każdy użytkownik wymaga buforowania różnych danych. Aby rozwiązać ten problem, niektóre rozwiązania stosują powiązanie sesji. Takie podejście zapewnia, że ten sam węzeł obliczeniowy pracowniczy przetwarza wszystkie żądania dla określonego użytkownika lub najemcy. Koligacja sesji może zwiększyć zdolność warstwy aplikacji do efektywnego korzystania z pamięci podręcznej. Jednak przyleganie sesji komplikuje również skalowanie i równoważenie obciążenia ruchu sieciowego między pracownikami. Rozważ tę kompromisową decyzję dokładnie. Dla wielu aplikacji powiązanie sesji nie jest wymagane.

Istnieje również możliwość przechowywania danych w zewnętrznych pamięciach podręcznych, takich jak Azure Managed Redis. Zewnętrzne pamięci podręczne są zoptymalizowane pod kątem pobierania danych z niskimi opóźnieniami, przy jednoczesnym izolowaniu stanu od zasobów obliczeniowych, co pozwala na ich niezależne skalowanie i zarządzanie. W wielu rozwiązaniach zewnętrzne pamięci podręczne umożliwiają zwiększenie wydajności aplikacji przy zachowaniu bezstanowej warstwy obliczeniowej.

Ważne

Unikaj wycieku danych między dzierżawami, gdy używasz pamięci podręcznych w technologii in-memory lub innych składników, które utrzymują stan danych. Rozważ na przykład dołączenie identyfikatora dzierżawy do wszystkich kluczy pamięci podręcznej, aby upewnić się, że dane są rozdzielone dla każdej dzierżawy.

Izolacja

Projektując wielodostępną warstwę obliczeniową, masz kilka opcji izolacji najemców. Można wdrożyć współużytkowane zasoby obliczeniowe dla wszystkich dzierżaw, dedykowane zasoby obliczeniowe dla poszczególnych dzierżaw lub podejście do częściowej izolacji, które mieści się między tymi skrajnościami. Każda opcja ma kompromisy. Aby ułatwić podjęcie decyzji, która opcja najlepiej odpowiada Twojemu rozwiązaniu, należy wziąć pod uwagę wymagania dotyczące izolacji.

Możesz być zaniepokojony logiczną izolacją najemców i sposobem rozdzielenia odpowiedzialności lub zasad zarządzania, które są stosowane do każdego najemcy. Alternatywnie może być konieczne wdrożenie odrębnych konfiguracji zasobów dla określonych dzierżawców, takich jak wdrożenie konkretnego SKU maszyny wirtualnej w celu dopasowania do obciążenia pracy najemcy.

W zależności od wybranego modelu izolacji, upewnij się, że dane klientów pozostają odpowiednio odizolowane, nawet jeśli wystąpią awarie składników lub przerwy. Rozważ użycie usługi Azure Chaos Studio w regularnym zautomatyzowanym procesie testowania, aby wprowadzić błędy, które symulują awarie w świecie rzeczywistym. To testowanie pomaga sprawdzić, czy rozwiązanie utrzymuje właściwą izolację najemców i nadal działa pod presją.

Podejścia i wzorce do rozważenia

Automatyczne skalowanie

Usługi obliczeniowe platformy Azure zapewniają różne możliwości skalowania obciążeń. Wiele usług obliczeniowych obsługuje skalowanie automatyczne, co wymaga określenia, kiedy należy skalować i ustawiać minimalne i maksymalne poziomy skalowania. Określone opcje skalowania zależą od używanych usług obliczeniowych. Zobacz następujące przykładowe usługi lub składniki:

Wzorzec znaczników wdrożeniowych

Aby uzyskać więcej informacji na temat sposobu używania wzorca znaczków wdrożeniowych do obsługi rozwiązania wielodostępnego, zobacz Podejścia architektoniczne do rozwiązania wielodostępnego.

Wzorzec konsolidacji zasobów obliczeniowych

Wzorzec konsolidacji zasobów obliczeniowych pomaga osiągnąć większą gęstość dzierżawców do infrastruktury obliczeniowej przez udostępnianie bazowych zasobów obliczeniowych. Udostępnianie zasobów obliczeniowych pozwala zmniejszyć bezpośredni koszt tych zasobów. Ponadto koszty zarządzania są często niższe, ponieważ istnieje mniej składników do zarządzania.

Jednak konsolidacja zasobów obliczeniowych zwiększa prawdopodobieństwo problemu z hałaśliwym sąsiadem. Obciążenie dowolnego najemcy może zużywać nieproporcjonalną ilość dostępnej pojemności obliczeniowej. Często można zmniejszyć to ryzyko, zapewniając odpowiednie skalowanie rozwiązania i stosując mechanizmy kontroli, takie jak limity przydziału i limity API, aby uniknąć użytkowników, którzy nieproporcjonalnie zużywają zasoby.

Ten wzorzec jest osiągany na różne sposoby, w zależności od używanej usługi obliczeniowej. Zobacz następujące przykładowe usługi lub składniki:

  • App Service i Azure Functions: Wdrażanie udostępnionych planów usługi App Service reprezentujących infrastrukturę serwera hostingu.

  • Aplikacje kontenera: Wdrażanie środowisk udostępnionych.

  • Usługa AKS: Wdrażanie udostępnionych zasobników za pomocą aplikacji obsługującej wiele dzierżaw.

  • Maszyny wirtualne: Wdroż pojedynczy zestaw maszyn wirtualnych do użytku przez wszystkich dzierżawc.

Dedykowane zasoby obliczeniowe dla każdego klienta

Można również wdrożyć dedykowane zasoby obliczeniowe dla każdego najemcy. Dedykowane zasoby zmniejszają ryzyko problemu z hałaśliwym sąsiadem, zapewniając, że zasoby obliczeniowe dla każdego najemcy są odizolowane między sobą. Umożliwia również wdrożenie odrębnej konfiguracji dla zasobów każdego najemcy, w oparciu o jego wymagania. Jednak zasoby dedykowane zwykle generują wyższy koszt, ponieważ występuje niższa gęstość użytkowników przypadających na zasoby.

W zależności od używanych usług obliczeniowych platformy Azure może być konieczne wdrożenie różnych dedykowanych zasobów:

  • App Service i Azure Functions: Wdróż oddzielne plany usługi App Service dla każdego najemcy.

  • Aplikacje kontenerowe: Wdróż oddzielne środowiska dla każdego użytkownika.

  • AKS: Wdróż dedykowane klastry dla każdego najemcy.

  • VMs: Wdrażanie dedykowanych maszyn wirtualnych dla każdego najemcy.

Izolacja na poziomie hosta fizycznego może być również zapewniana przez uruchamianie maszyn wirtualnych należących do dzierżawcy na dedykowanych hostach platformy Azure, które rezerwują cały serwer fizyczny dla jednego klienta. Jednak takie podejście jest zazwyczaj droższe niż korzystanie z hostów udostępnionych.

Częściowo izolowane zasoby obliczeniowe

Metody częściowo izolowane wymagają wdrożenia aspektów rozwiązania w konfiguracji izolowanej podczas udostępniania innych składników.

W przypadku korzystania z usług App Service i Azure Functions można wdrażać oddzielne aplikacje dla każdej dzierżawy i hostować te aplikacje na wspólnych planach usługi App Service. Takie podejście zmniejsza koszt warstwy przetwarzania, ponieważ plany App Service stanowią jednostkę rozliczeniową. Umożliwia również stosowanie odrębnych konfiguracji i zasad do każdej aplikacji. Jednak takie podejście wprowadza ryzyko problemu hałaśliwego sąsiada.

Za pomocą usługi Container Apps można wdrożyć wiele aplikacji w środowisku udostępnionym, a następnie użyć języka Dapr i innych narzędzi do oddzielnego skonfigurowania każdej aplikacji.

AKS i Kubernetes dostarczają szeroki wybór opcji wielodzierżawczości.

  • Przestrzenie nazw specyficzne dla najemców, które mogą zapewnić logiczną izolację zasobów najemców, wdrażanych w współdzielonych klastrach i pulach węzłów.

  • Węzły albo pule węzłów przeznaczone dla dzierżawcy w ramach współdzielonego klastra

  • Zasobniki pod specyficzne dla najemcy, które mogą używać tej samej puli węzłów

Za pomocą usługi AKS można również zastosować ład na poziomie zasobnika, aby rozwiązać problem z hałaśliwym sąsiadem. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dla deweloperów aplikacji do zarządzania zasobami w usłudze AKS.

Ważne jest również, aby pamiętać o udostępnionych składnikach w klastrze Kubernetes oraz o tym, jak wielodostępność może mieć wpływ na te składniki. Na przykład serwer interfejsu API Kubernetes to usługa udostępniona używana w całym klastrze. Nawet jeśli udostępniasz pule węzłów specyficzne dla dzierżawców w celu odizolowania obciążeń aplikacji dzierżawców, serwer interfejsu API może napotkać konkurencję z dużą liczbą żądań pomiędzy dzierżawcami.

Antywzorce, których należy unikać

Unikaj następujących antywzorców.

Antywzorzec hałaśliwego sąsiada

Podczas wdrażania składników współdzielonych przez najemców, problem z hałaśliwym sąsiadem stanowi potencjalne ryzyko. Upewnij się, że uwzględnisz zarządzanie zasobami i monitorowanie, aby ograniczyć ryzyko aktywności innych dzierżawców wpływającej na obciążenie obliczeniowe dzierżawy.

Wyciek danych między dzierżawcami

Warstwy obliczeniowe mogą podlegać wyciekowi danych między dzierżawami, jeśli nie są one prawidłowo obsługiwane. To ryzyko nie jest zwykle czymś, co należy wziąć pod uwagę podczas korzystania z wielodostępnej usługi na platformie Azure, ponieważ firma Microsoft zapewnia ochronę w warstwie platformy. Jednak podczas tworzenia własnej aplikacji wielodostępnej należy rozważyć, czy jakiekolwiek zasoby udostępnione, takie jak lokalne pamięci podręczne, pamięć RAM i zewnętrzne pamięci podręczne, mogą zawierać dane, które inny lokator może przypadkiem zobaczyć lub zmienić.

Antywzorzec przeładowanego front-endu

Aby uniknąć antywzorzec zajętego front-endu, upewnij się, że warstwa front-endu nie wykonuje większości pracy, którą mogą obsłużyć inne składniki lub warstwy architektury. Ten antywzorzec jest szczególnie ważny podczas tworzenia udostępnionych interfejsów dla rozwiązania multitenantowego, ponieważ zajęty interfejs obniża jakość doświadczenia dla wszystkich najemców.

Zamiast tego rozważ użycie przetwarzania asynchronicznego przy użyciu kolejek lub innych usług obsługi komunikatów. Takie podejście umożliwia również stosowanie kontroli jakości usług (QOS) dla różnych dzierżaw w oparciu o ich wymagania. Na przykład wszyscy użytkownicy mogą współdzielić wspólną warstwę front-end, ale użytkownicy, którzy płacą za wyższy poziom usług, mogą mieć lepszy zestaw dedykowanych zasobów do przetwarzania komunikatów z kolejki.

Nieelastyczne lub niewystarczające skalowanie

Rozwiązania wielodostępne często podlegają nagłemu, zmiennemu skalowaniu. Składniki współdzielone są szczególnie narażone na ten problem, ponieważ zakres gwałtownego wzrostu zapotrzebowania jest wyższy, a efekt jest większy, gdy masz więcej użytkowników, którzy mają zróżnicowane wzorce użycia.

Upewnij się, że korzystasz z elastyczności i skali chmury. Zastanów się, czy należy używać skalowania w poziomie lub w pionie i używać skalowania automatycznego, aby automatycznie obsługiwać skoki obciążenia. Przetestuj rozwiązanie, aby zrozumieć, jak działa na różnych poziomach obciążenia. Upewnij się, że uwzględnisz woluminy obciążenia oczekiwane w środowisku produkcyjnym i oczekiwany wzrost. Możesz użyć w pełni zarządzanej usługi, takiej jak testowanie obciążenia, aby dowiedzieć się, jak aplikacja działa pod obciążeniem.

Antywzorzec braku buforowania

Antywzorzec Bez buforowania występuje, gdy wydajność rozwiązania spada, ponieważ warstwa aplikacji wielokrotnie żąda lub oblicza ponownie informacje, które mogą być ponownie używane we wszystkich żądaniach. Jeśli masz dane, które można udostępniać, czy to między dzierżawcami, czy między użytkownikami w ramach jednej dzierżawy, warto przechowywać je w pamięci podręcznej, aby zmniejszyć obciążenie warstwy zaplecza lub bazy danych.

Niepotrzebna stanowość

Implikacją antywzorca projektowego No Caching (brak buforowania) jest to, że należy również unikać przechowywania niepotrzebnych informacji o stanie w warstwie obliczeniowej. Należy jawnie określać, gdzie utrzymujesz stan i dlaczego. Stanowe warstwy interfejsu użytkownika lub aplikacji mogą zmniejszyć możliwość skalowania. Warstwy obliczeniowe stanowe zwykle wymagają również utrzymania sesji, co może zmniejszyć możliwość efektywnego rozkładania obciążenia między procesami roboczymi lub węzłami.

Rozważ kompromisy dla każdego elementu stanu, który utrzymujesz w warstwie obliczeniowej, i czy ma to wpływ na możliwość skalowania lub rozwoju wraz ze zmianą wzorców obciążeń dzierżawców. Stan można również przechowywać w zewnętrznej pamięci podręcznej, takiej jak Azure Managed Redis.

Współautorzy

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

Główni autorzy:

  • Dixit Arora | Starszy inżynier klienta, fasttrack dla platformy Azure
  • 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.

Zapoznaj się ze wskazówkami specyficznymi dla usługi obliczeniowej:

  • Last updated on