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). Wielodostępne rozwiązania 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 konsekwencje 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 kilka typowych wzorców stosowania wielodostępności do usług obliczeniowych, a także niektórych antywzorców, aby uniknąć.

Najważniejsze zagadnienia i wymagania

Wielodostępność i wybrany model izolacji wpływa 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.

Skalowanie

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

Jeśli wdrażasz dedykowane zasoby dla każdej dzierżawy, możesz elastycznie skalować zasoby każdej dzierżawy niezależnie. W rozwiązaniu, w którym zasoby obliczeniowe są współużytkowane między wieloma dzierżawami, w przypadku skalowania tych zasobów wszystkie te dzierżawy mogą korzystać z nowej skali. Jednak wszyscy będą cierpieć, gdy skala jest niewystarczająca do obsługi ogólnego obciążenia. Aby uzyskać więcej informacji, zobacz problem Noisy Neighbor.

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 pułap skali.

Problemy z wydajnością często pozostają niezakryte, dopóki aplikacja nie zostanie obciążona. 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 podejścia używanego do skalowania zazwyczaj należy zaplanować wyzwalacze, które powodują skalowanie składników. W przypadku współużytkowanych składników należy wziąć pod uwagę wzorce obciążeń każdej dzierżawy, która korzysta z zasobów, aby zapewnić, że aprowizowana pojemność może spełniać łączną wymaganą pojemność i zminimalizować prawdopodobieństwo wystąpienia problemu z dzierżawą, w której występuje problem Hałaśliwy sąsiad. Możesz również zaplanować pojemność skalowania, biorąc pod uwagę liczbę dzierżaw. Jeśli na przykład mierzysz zasoby używane do obsługi 100 dzierżaw, podczas dołączania większej liczby dzierżaw możesz zaplanować skalowanie zasobów w taki sposób, 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 dodać nowych procesów roboczych, wystąpień lub węzłów i natychmiast rozpocząć przetwarzanie żądań. Jeśli twoja architektura pozwala na to, możesz również repurpose instances, które są przypisane do jednej dzierżawy i przydzielić je do innej dzierżawy.

Zasoby stanowe mogą być dalej podzielone na podstawie typu stanu, który utrzymują. 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ęć podręczną tylko do odczytu w pamięci oraz magazyn 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 korzystania z 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 Azure Cache for Redis. Zewnętrzne pamięci podręczne są zoptymalizowane pod kątem pobierania danych o małych opóźnieniach, zachowując 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ą poprawę wydajności aplikacji, jednocześnie zachowując bezstanową warstwę obliczeniową.

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 wstępne dołączenie identyfikatora dzierżawy do wszystkich kluczy pamięci podręcznej, aby upewnić się, że dane są oddzielone dla każdej dzierżawy.

Izolacja

Podczas projektowania wielodostępnej warstwy obliczeniowej często istnieje wiele opcji, które należy wziąć pod uwagę pod kątem poziomu izolacji między dzierżawami, w tym wdrażania udostępnionych zasobów obliczeniowych, do użycia przez wszystkie dzierżawy, dedykowane zasoby obliczeniowe dla każdej dzierżawy lub coś między tymi skrajnościami. Każda opcja jest dostarczana z kompromisami. 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ą dzierżaw oraz sposób 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 określonej 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 izolowane nawet wtedy, gdy 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 wprowadzić 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

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 rozważenia, kiedy należy skalować, oraz minimalny i maksymalny poziom skali. Określone opcje dostępne do skalowania zależą od używanych usług obliczeniowych. Zobacz następujące przykładowe usługi:

Wzorzec sygnatur wdrożenia

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 pomaga osiągnąć większą gęstość dzierżaw do infrastruktury obliczeniowej, udostępniając bazowe zasoby obliczeniowe. 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 wystąpienia problemu Noisy Neighbor. Obciążenie każdej 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:

  • Azure App Service i Azure Functions: wdrażanie udostępnionych planów 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 ograniczają ryzyko problemu Noisy Neighbor, 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:

  • Azure App Service i Azure Functions: wdrażanie oddzielnych planów 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: wdrażanie dedykowanych maszyn wirtualnych dla każdej dzierżawy.

Częściowo izolowane zasoby obliczeniowe

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

Podczas pracy z App Service i Azure Functions można wdrażać różne aplikacje dla każdej dzierżawy i hostować aplikacje w udostępnionych planach App Service. Takie podejście zmniejsza koszt warstwy obliczeniowej, ponieważ plany 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śliwych sąsiadów.

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.

Azure Kubernetes Service (AKS) i Kubernetes w szerszym zakresie oferują 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 i o tym, jak te składniki mogą mieć wpływ na wielodostępność. 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żawy w celu izolowania obciążeń aplikacji dzierżawców, serwer interfejsu API może napotkać rywalizację z dużą liczbą żądań w dzierżawach.

Antywzorzec, 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ędniasz nadzór nad zasobami i monitorowanie, aby ograniczyć ryzyko 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 usługi wielodostępnej na platformie Azure, ponieważ firma Microsoft zapewnia ochronę w warstwie platformy. Jednak podczas tworzenia własnej aplikacji wielodostępnej należy wziąć pod uwagę, czy jakiekolwiek zasoby udostępnione (takie jak lokalne pamięci podręczne dysku, 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 zależności od ich wymagań. 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 zwiększania szybkości 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 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 ono 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 między użytkownikami w ramach jednej dzierżawy, warto buforować je, aby zmniejszyć obciążenie warstwy zaplecza/bazy danych.

Niepotrzebna stanowość

Antywzorzec bez buforowania jest taki, ż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ą również koligacji sesji, co może zmniejszyć możliwość efektywnego równoważenia obciążenia ruchu między procesami roboczymi lub węzłami.

Należy wziąć pod uwagę kompromisy dotyczące każdego stanu utrzymywanego w warstwie obliczeniowej oraz tego, 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. Został pierwotnie 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 klienta, fasttrack dla platformy Azure

Inni współautorzy:

Następne kroki

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