Udostępnij za pośrednictwem

Podejścia architektury do obliczeń w rozwiązaniach wielodostępnych

  • Artykuł

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

Ten artykuł zawiera wskazówki dotyczące zagadnień i wymagań, które są niezbędne dla architektów rozwiązań do rozważenia podczas planowania wielodostępnej warstwy obliczeniowej. Obejmuje to niektóre typowe wzorce stosowania wielodostępności do usług obliczeniowych, a także niektóre antywzorce, aby uniknąć.

Kluczowe zagadnienia i wymagania

Wielodostępność i wybrany model izolacji ma wpływ na skalowanie, wydajność, zarządzanie stanem i zabezpieczenia zasobów obliczeniowych. W tej sekcji zapoznamy się z niektórymi kluczowymi decyzjami, które należy podjąć podczas planowania wielodostępnego rozwiązania obliczeniowego.

Skaluj

Systemy muszą działać odpowiednio na zmieniającym się zapotrzebowaniu. W miarę wzrostu liczby dzierżaw i ilości ruchu może być konieczne zwiększenie pojemności zasobów, aby utrzymać rosnącą liczbę dzierżaw i utrzymać akceptowalną wydajność. Podobnie, gdy liczba aktywnych użytkowników lub ilość ruchu spada, należy automatycznie zmniejszyć pojemność obliczeniową, aby zmniejszyć koszty, ale należy zmniejszyć pojemność przy minimalnym wpływie na użytkowników.

W przypadku wdrażania dedykowanych zasobów dla każdej dzierżawy można elastycznie skalować zasoby każdej dzierżawy niezależnie. W rozwiązaniu, w którym zasoby obliczeniowe są współdzielone między wieloma dzierżawami, w przypadku skalowania tych zasobów wszystkie te dzierżawy mogą korzystać z nowej skali. Jednak wszystkie one również będą cierpieć, gdy skala jest niewystarczająca do obsługi ogólnego obciążenia. Aby uzyskać więcej informacji, zobacz problem z hałaśliwym sąsiadem.

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

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

Wyzwalacze skalowania

Niezależnie od tego, które podejście jest używane do skalowania, zazwyczaj należy zaplanować wyzwalacze, które powodują skalowanie składników. Jeśli udostępniono składniki, rozważ wzorce obciążeń każdej dzierżawy, która korzysta z zasobów, aby zapewnić, że aprowizowana pojemność może spełnić łączną wymaganą pojemność i zminimalizować prawdopodobieństwo wystąpienia problemu dzierżawy z hałaśliwym sąsiadem. Możesz również zaplanować pojemność skalowania, biorąc pod uwagę liczbę dzierżaw. Jeśli na przykład zmierzysz zasoby używane do obsługi 100 dzierżaw, po dołączeniu kolejnych dzierżaw możesz zaplanować skalowanie tak, aby zasoby podwoiły się dla każdej dodatkowej 100 dzierżaw.

Stan

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 skalowania w poziomie, ponieważ można szybko dodawać nowych procesów roboczych, wystąpień lub węzłów i natychmiast rozpocząć przetwarzanie żądań. Jeśli twoja architektura pozwala na to, można również ponownie zaalokować wystąpienia przypisane do jednej dzierżawy i przydzielić je do innej dzierżawy.

Zasoby stanowe można dalej podzielić na podstawie typu stanu, który utrzymuje. Stan trwały to dane, które muszą być trwale przechowywane. W rozwiązaniach w chmurze należy unikać 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 i obejmują pamięci podręczne tylko do odczytu w pamięci oraz przechowywanie plików tymczasowych na dyskach lokalnych.

Stan przejściowy jest często przydatny w celu zwiększenia wydajności warstwy aplikacji przez zmniejszenie liczby żądań do usług magazynu zaplecza. 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 wielodostępne może zaostrzyć ten problem, jeśli każda dzierżawa wymaga buforowania różnych danych. Aby rozwiązać ten problem, niektóre rozwiązania używają koligacji sesji, aby upewnić się, że wszystkie żądania dla określonego użytkownika lub dzierżawy są przetwarzane przez ten sam węzeł procesu roboczego obliczeniowego. Mimo że koligacja sesji może zwiększyć zdolność warstwy aplikacji do efektywnego korzystania z pamięci podręcznej, utrudnia również skalowanie i równoważenie obciążenia ruchu między procesami roboczymi. Ten kompromis musi być starannie przemyślany. W przypadku wielu aplikacji koligacja sesji nie jest wymagana.

Istnieje również możliwość przechowywania danych w zewnętrznych pamięciach podręcznych, takich jak usługa Azure Cache for Redis. Zewnętrzne pamięci podręczne są zoptymalizowane pod kątem pobierania danych o małych opóźnieniach, zachowując jednocześnie stan odizolowany od zasobów obliczeniowych, dzięki czemu można je skalować i zarządzać oddzielnie. 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ęcznej w pamięci lub innych składników, które utrzymują stan. 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

Podczas projektowania wielodostępnej warstwy obliczeniowej często istnieje wiele opcji, które należy wziąć pod uwagę na poziomie izolacji między dzierżawami, w tym wdrażanie współużytkowanych zasobów obliczeniowych, które mają być używane przez wszystkie dzierżawy, dedykowane zasoby obliczeniowe dla każdej dzierżawy lub coś między tymi skrajnościami. Każda opcja zawiera 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że dotyczyć logicznej izolacji dzierżaw i sposobu oddzielenia obowiązków lub zasad zarządzania, które są stosowane do każdej dzierżawy. Alternatywnie może być konieczne wdrożenie odrębnych konfiguracji zasobów dla określonych dzierżaw, takich jak wdrożenie konkretnej jednostki SKU maszyny wirtualnej w celu dopasowania do obciążenia dzierżawy.

Niezależnie od wybranego modelu izolacji upewnij się, że dane dzierżawy pozostają odpowiednio odizolowane, nawet jeśli składniki są niedostępne lub działają nieprawidłowo. Rozważ użycie usługi Azure Chaos Studio w ramach regularnego zautomatyzowanego procesu testowania, aby celowo wprowadzać błędy, które symulują rzeczywiste awarie, i sprawdź, czy rozwiązanie nie wycieka danych między dzierżawami i działa prawidłowo nawet pod presją.

Podejścia i wzorce do rozważenia

Skalowanie automatyczne

Usługi obliczeniowe platformy Azure zapewniają różne możliwości skalowania obciążeń. Wiele usług obliczeniowych obsługuje skalowanie automatyczne, co wymaga rozważenia, kiedy należy skalować, oraz minimalnych i maksymalnych poziomów skali. Dostępne opcje skalowania zależą od używanych usług obliczeniowych. Zobacz następujące przykładowe usługi:

Wzorzec sygnatur wdrażania

Aby uzyskać więcej informacji na temat sposobu użycia wzorca sygnatur wdrożenia do obsługi rozwiązania wielodostępnego, zobacz Omówienie.

Wzorzec konsolidacji zasobów obliczeniowych

Wzorzec konsolidacji zasobów obliczeniowych ułatwia osiągnięcie większej gęstości dzierżaw w infrastrukturze obliczeniowej przez udostępnianie bazowych zasobów obliczeniowych. Dzięki udostępnianiu zasobów obliczeniowych często można 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 Noisy Neighbor. Obciążenie dowolnej dzierżawy może zużywać nieproporcjonalną ilość dostępnej pojemności obliczeniowej. Często można ograniczyć to ryzyko, zapewniając odpowiednie skalowanie rozwiązania i stosując mechanizmy kontroli, takie jak limity przydziału i limity interfejsu API, aby uniknąć dzierżaw, które zużywają więcej niż ich sprawiedliwy udział w pojemności.

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:

  • aplikacja systemu Azure Service i Azure Functions: wdrażanie udostępnionych planów usługi App Service reprezentujących infrastrukturę serwera hostingu.
  • Azure Container Apps: wdrażanie środowisk udostępnionych.
  • Azure Kubernetes Service (AKS): wdrażanie udostępnionych zasobników przy użyciu aplikacji obsługującej wiele dzierżaw.
  • Maszyny wirtualne: wdróż pojedynczy zestaw maszyn wirtualnych dla wszystkich dzierżaw do użycia.

Dedykowane zasoby obliczeniowe na dzierżawę

Można również wdrożyć dedykowane zasoby obliczeniowe dla każdej dzierżawy. Dedykowane zasoby zmniejszają ryzyko wystąpienia problemu z hałaśliwym sąsiadem, zapewniając, że zasoby obliczeniowe dla każdej dzierżawy są odizolowane od innych. Umożliwia również wdrożenie odrębnej konfiguracji dla zasobów każdej dzierżawy na podstawie ich wymagań. Jednak zasoby dedykowane zwykle mają wyższy koszt, ponieważ masz niższą gęstość dzierżaw do zasobów.

W zależności od używanych usług obliczeniowych platformy Azure należy wdrożyć różne dedykowane zasoby w następujący sposób:

  • aplikacja systemu Azure Service i Azure Functions: wdróż oddzielne plany usługi App Service dla każdej dzierżawy.
  • Azure Container Apps: wdrażanie oddzielnych środowisk dla każdej dzierżawy.
  • Azure Kubernetes Service (AKS): wdrażanie dedykowanych klastrów dla każdej dzierżawy.
  • Maszyny wirtualne: wdróż dedykowane maszyny wirtualne dla każdej dzierżawy.

Częściowo izolowane zasoby obliczeniowe

Metody częściowo izolowane wymagają wdrożenia aspektów rozwiązania w izolowanej konfiguracji, a pozostałe składniki są współużytkowane.

Podczas pracy z usługami App Service i Azure Functions można wdrażać odrębne aplikacje dla każdej dzierżawy i hostować aplikacje w udostępnionych planach usługi App Service. Takie podejście zmniejsza koszt warstwy obliczeniowej, ponieważ plany usługi App Service reprezentują jednostkę rozliczeń. 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.

Usługa Azure Container Apps umożliwia wdrażanie wielu aplikacji w środowisku udostępnionym, a następnie używanie języka Dapr i innych narzędzi do oddzielnego konfigurowania każdej aplikacji.

Usługa Azure Kubernetes Service (AKS) i platforma Kubernetes szerzej udostępniają różne opcje wielodostępności, w tym następujące:

  • Przestrzenie nazw specyficzne dla dzierżawy służą do logicznej izolacji zasobów specyficznych dla dzierżawy, które są wdrażane w udostępnionych klastrach i pulach węzłów.
  • Węzły specyficzne dla dzierżawy lub pule węzłów w udostępnionym klastrze.
  • Zasobniki specyficzne dla dzierżawy, które mogą używać tej samej puli węzłów.

Usługa AKS umożliwia również stosowanie ładu na poziomie zasobnika w celu wyeliminowania problemu Noisy Neighbor. Aby uzyskać więcej informacji, zobacz Best practices for application developers to manage resources in Azure Kubernetes Service (AKS) (Najlepsze rozwiązania dla deweloperów aplikacji do zarządzania zasobami w usłudze Azure Kubernetes Service (AKS).

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

Antywzorzecy, aby uniknąć

Hałaśliwy antywzorzec sąsiada

Za każdym razem, gdy wdrażasz składniki współużytkowane przez dzierżawy, problem Noisy Neighbor jest potencjalnym zagrożeniem. Upewnij się, że uwzględnisz nadzór nad zasobami i monitorowanie, aby ograniczyć ryzyko wystąpienia obciążenia obliczeniowego dzierżawy, którego dotyczy działanie innych dzierżaw.

Wyciek danych między dzierżawami

Warstwy obliczeniowe mogą podlegać wyciekom danych między dzierżawami, jeśli nie są one prawidłowo obsługiwane. Zazwyczaj nie jest to coś, 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 inna dzierżawa może przypadkowo wyświetlać lub modyfikować.

Antywzorzec zajętego frontonu

Aby uniknąć antywzorzec zajętego frontonu, należy unikać wykonywania wielu czynności, które mogą być obsługiwane przez inne składniki lub warstwy architektury. Ten antywzorzec jest szczególnie ważny podczas tworzenia udostępnionych frontonów dla rozwiązania wielodostępnego, ponieważ zajęty fronton obniży środowisko dla wszystkich dzierżaw.

Zamiast tego rozważ użycie przetwarzania asynchronicznego, korzystając z 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 wszystkie dzierżawy mogą współdzielić wspólną warstwę frontonu, ale dzierżawcy, którzy płacą za wyższy poziom usług, mogą mieć wyższy zestaw dedykowanych zasobów do przetwarzania pracy z komunikatów w kolejce.

Nieelastyczne lub niewystarczające skalowanie

Rozwiązania wielodostępne często podlegają wzorom skalowania z dużą skalę. Składniki udostępnione są szczególnie podatne na ten problem, ponieważ zakres serii jest wyższy, a wpływ jest większy, gdy masz więcej dzierżaw z różnymi wzorcami użycia.

Upewnij się, że dobrze wykorzystujesz elastyczność i skalę 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 platformy Azure, aby dowiedzieć się, jak działa aplikacja pod obciążeniem.

Antywzorzec dotyczący braku buforowania

Antywzorzec No Caching występuje, gdy wydajność rozwiązania występuje, ponieważ warstwa aplikacji wielokrotnie żąda lub ponownie skompiluje informacje, które mogą być ponownie używane w żądaniach. Jeśli masz dane, które można udostępniać, między dzierżawami lub użytkownikami w ramach jednej dzierżawy, warto buforować je, aby zmniejszyć obciążenie warstwy zaplecza/bazy danych.

Niepotrzebna stanowość

Corollary na antywzorzec No Caching jest to, że należy również unikać przechowywania niepotrzebnego stanu w warstwie obliczeniowej. Należy jawnie określać, gdzie utrzymujesz stan i dlaczego. Stanowe warstwy frontonu lub aplikacji mogą zmniejszyć możliwość skalowania. Warstwy obliczeniowe stanowe zwykle wymagają koligacji sesji, co może zmniejszyć możliwość efektywnego równoważenia obciążenia ruchu między procesami roboczymi lub węzłami.

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

Współautorzy

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

Autorzy zabezpieczeń:

  • Dixit Arora | Starszy inżynier klienta, fasttrack dla platformy Azure
  • John Downs | Główny inżynier oprogramowania

Inni współautorzy:

Następne kroki

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