Udostępnij za pośrednictwem

Zagadnienia dotyczące platformy aplikacji dotyczące obciążeń o znaczeniu krytycznym na platformie Azure

  • Artykuł

Platforma Azure udostępnia wiele usług obliczeniowych do hostowania aplikacji o wysokiej dostępności. Usługi różnią się możliwościami i złożonością. Zalecamy wybranie usług na podstawie następujących opcji:

  • Wymagania niefunkcjonalne dotyczące niezawodności, dostępności, wydajności i zabezpieczeń.
  • Czynniki decyzyjne, takie jak skalowalność, koszt, funkcjonalność i złożoność.

Wybór platformy hostingu aplikacji to krytyczna decyzja, która ma wpływ na wszystkie inne obszary projektowe. Na przykład starsze lub zastrzeżone oprogramowanie programistyczne może nie działać w usługach PaaS lub konteneryzowanych aplikacjach. To ograniczenie wpływałoby na wybór platformy obliczeniowej.

Aplikacja o krytycznym znaczeniu może używać więcej niż jednej usługi obliczeniowej do obsługi wielu złożonych obciążeń i mikrousług, z których każda ma odrębne wymagania.

Ten obszar projektowania zawiera zalecenia dotyczące opcji wyboru zasobów obliczeniowych, projektowania i konfiguracji. Zalecamy również zapoznanie się z drzewem decyzyjnym Obliczenia.

Ważne

Ten artykuł jest częścią serii obciążeń o krytycznym znaczeniu dla platformy Azure Well-Architected Framework . Jeśli nie znasz tej serii, zalecamy rozpoczęcie pracy z tematem Co to jest obciążenie o znaczeniu krytycznym?

Globalna dystrybucja zasobów platformy

Typowy wzorzec obciążenia o krytycznym znaczeniu obejmuje zasoby globalne i zasoby regionalne.

Usługi platformy Azure, które nie są ograniczone do określonego regionu świadczenia usługi Azure, są wdrażane lub konfigurowane jako zasoby globalne. Niektóre przypadki użycia obejmują dystrybucję ruchu w wielu regionach, przechowywanie stanu trwałego dla całej aplikacji i buforowanie globalnych danych statycznych. Jeśli musisz uwzględnić zarówno architekturę jednostki skalowania , jak i dystrybucję globalną, zastanów się, jak zasoby są optymalnie rozproszone lub replikowane w różnych regionach świadczenia usługi Azure.

Inne zasoby są wdrażane regionalnie. Te zasoby, które są wdrażane w ramach sygnatury wdrożenia, zazwyczaj odpowiadają jednostce skalowania. Jednak region może mieć więcej niż jedną sygnaturę, a sygnatura może zawierać więcej niż jedną jednostkę. Niezawodność zasobów regionalnych ma kluczowe znaczenie, ponieważ są one odpowiedzialne za uruchamianie głównego obciążenia.

Na poniższej ilustracji przedstawiono projekt wysokiego poziomu. Użytkownik uzyskuje dostęp do aplikacji za pośrednictwem centralnego globalnego punktu wejścia, który następnie przekierowuje żądania do odpowiedniego regionalnego sygnatury wdrożenia:

Diagram przedstawiający architekturę o znaczeniu krytycznym.

Metodologia projektowania o krytycznym znaczeniu wymaga wdrożenia w wielu regionach. Ten model zapewnia regionalną odporność na uszkodzenia, dzięki czemu aplikacja pozostaje dostępna nawet wtedy, gdy cały region ulegnie awarii. Podczas projektowania aplikacji z wieloma regionami należy wziąć pod uwagę różne strategie wdrażania, takie jak aktywne/aktywne i aktywne/pasywne, wraz z wymaganiami aplikacji, ponieważ istnieją znaczące kompromisy dla każdego podejścia. W przypadku obciążeń o znaczeniu krytycznym zdecydowanie zalecamy aktywny/aktywny model.

Nie każde obciążenie obsługuje lub wymaga jednoczesnego uruchamiania wielu regionów. Należy rozważyć określone wymagania aplikacji względem kompromisów, aby określić optymalną decyzję projektową. W przypadku niektórych scenariuszy aplikacji, które mają mniejsze cele dotyczące niezawodności, aktywne/pasywne lub fragmentowanie może być odpowiednimi alternatywami.

Strefy dostępności mogą zapewnić wdrożenia regionalne o wysokiej dostępności w różnych centrach danych w regionie. Prawie wszystkie usługi platformy Azure są dostępne w konfiguracji strefowej, w której usługa jest delegowana do określonej strefy lub konfiguracji strefowo nadmiarowej, gdzie platforma automatycznie zapewnia, że usługa obejmuje strefy i może wytrzymać awarię strefy. Te konfiguracje zapewniają odporność na uszkodzenia do poziomu centrum danych.

Zagadnienia dotyczące projektowania

  • Możliwości regionalne i strefowe. Nie wszystkie usługi i możliwości są dostępne w każdym regionie świadczenia usługi Azure. Ta kwestia może mieć wpływ na wybrane regiony. Ponadto strefy dostępności nie są dostępne w każdym regionie.

  • Pary regionalne. Regiony platformy Azure są pogrupowane w pary regionalne składające się z dwóch regionów w jednej lokalizacji geograficznej. Niektóre usługi platformy Azure używają sparowanych regionów w celu zapewnienia ciągłości działania i zapewnienia poziomu ochrony przed utratą danych. Na przykład magazyn geograficznie nadmiarowy platformy Azure (GRS) replikuje dane do pomocniczego sparowanego regionu automatycznie, zapewniając trwałość danych, jeśli region podstawowy nie jest możliwy do odzyskania. Jeśli awaria ma wpływ na wiele regionów świadczenia usługi Azure, priorytetem odzyskiwania jest co najmniej jeden region w każdej parze.

  • Spójność danych. W przypadku wyzwań związanych ze spójnością rozważ użycie globalnie rozproszonego magazynu danych, architektury regionalnej z sygnaturą i częściowo aktywnego/aktywnego wdrożenia. W częściowym wdrożeniu niektóre składniki są aktywne we wszystkich regionach, podczas gdy inne znajdują się centralnie w regionie podstawowym.

  • Bezpieczne wdrożenie. Platforma SDP (Safe Deployment Practice) platformy Azure zapewnia, że wszystkie zmiany kodu i konfiguracji (planowana konserwacja) na platformie Azure przechodzą etapowe wdrażanie. Kondycja jest analizowana pod kątem degradacji w trakcie wydania. Po pomyślnym zakończeniu faz kanarowych i pilotażowych aktualizacje platformy są serializowane między parami regionalnymi, więc tylko jeden region w każdej parze jest aktualizowany w danym momencie.

  • Pojemność platformy. Podobnie jak każdy dostawca usług w chmurze, platforma Azure ma ograniczone zasoby. Niedostępność może być wynikiem ograniczeń pojemności w regionach. Jeśli wystąpi awaria regionalna, istnieje wzrost zapotrzebowania na zasoby, ponieważ obciążenie próbuje odzyskać w sparowanym regionie. Awaria może spowodować problem z pojemnością, w którym podaż tymczasowo nie spełnia zapotrzebowania.

Zalecenia dotyczące projektowania

  • Wdróż rozwiązanie w co najmniej dwóch regionach świadczenia usługi Azure, aby chronić się przed awariami regionalnymi. Wdróż go w regionach, które mają możliwości i cechy wymagane przez obciążenie. Możliwości powinny spełniać cele dotyczące wydajności i dostępności podczas spełniania wymagań dotyczących przechowywania i przechowywania danych.

    Na przykład niektóre wymagania dotyczące zgodności danych mogą ograniczać liczbę dostępnych regionów i potencjalnie wymuszać naruszenia projektu. W takich przypadkach zdecydowanie zalecamy dodanie dodatkowych inwestycji w otoki operacyjne w celu przewidywania, wykrywania i reagowania na błędy. Załóżmy, że masz ograniczenie do lokalizacji geograficznej z dwoma regionami, a tylko jeden z tych regionów obsługuje strefy dostępności (model centrum danych 3 + 1). Utwórz wzorzec wdrażania pomocniczego przy użyciu izolacji domeny błędów, aby umożliwić wdrażanie obu regionów w aktywnej konfiguracji i upewnij się, że region podstawowy zawiera wiele sygnatur wdrożenia.

    Jeśli odpowiednie regiony platformy Azure nie oferują potrzebnych możliwości, należy przygotować się do naruszenia spójności regionalnych sygnatur wdrożenia w celu nadania priorytetów dystrybucji geograficznej i zmaksymalizowania niezawodności. Jeśli tylko jeden region platformy Azure jest odpowiedni, wdróż wiele sygnatur wdrożenia (jednostek skalowania regionalnego) w wybranym regionie, aby ograniczyć pewne ryzyko i użyć stref dostępności, aby zapewnić odporność na uszkodzenia na poziomie centrum danych. Jednak taki znaczący kompromis w dystrybucji geograficznej znacznie ogranicza osiągalną złożoną umowę SLA i ogólną niezawodność.

    Ważne

    W przypadku scenariuszy przeznaczonych dla celu celu slo, który jest większy lub równy 99,99%, zalecamy co najmniej trzy regiony wdrażania, aby zmaksymalizować złożoną umowę SLA i ogólną niezawodność. Oblicz złożoną umowę SLA dla wszystkich przepływów użytkowników. Upewnij się, że złożona umowa SLA jest zgodna z celami biznesowymi.

  • W przypadku scenariuszy aplikacji o dużej skali, które mają znaczne ilości ruchu, zaprojektuj rozwiązanie do skalowania w wielu regionach, aby poruszać się po potencjalnych ograniczeniach pojemności w jednym regionie. Dodatkowe sygnatury wdrożenia regionalnego zapewnią większą złożoną umowę SLA. Użycie zasobów globalnych ogranicza wzrost złożonej umowy SLA, którą można osiągnąć, dodając więcej regionów.

  • Zdefiniuj i zweryfikuj cele punktu odzyskiwania (RPO) i cele czasu odzyskiwania (RTO).

  • W ramach jednej lokalizacji geograficznej należy określić priorytety użycia par regionalnych w celu skorzystania z serializacji wdrożeń SDP na potrzeby planowanej konserwacji i priorytetyzacji regionalnej w przypadku nieplanowanej konserwacji.

  • Geograficznie colocate zasobów platformy Azure z użytkownikami, aby zminimalizować opóźnienie sieci i zmaksymalizować kompleksową wydajność.

  • Wyrównuj bieżącą dostępność usługi za pomocą planów rozwoju produktów podczas wybierania regionów wdrażania. Niektóre usługi mogą nie być natychmiast dostępne w każdym regionie.

Przechowywanie w kontenerach

Kontener zawiera kod aplikacji oraz powiązane pliki konfiguracji, biblioteki i zależności, które aplikacja musi uruchomić. Konteneryzacja zapewnia warstwę abstrakcji dla kodu aplikacji i jej zależności oraz tworzy separację od bazowej platformy hostingu. Pojedynczy pakiet oprogramowania jest wysoce przenośny i może działać spójnie na różnych platformach infrastruktury i dostawców usług w chmurze. Deweloperzy nie muszą ponownie pisać kodu i mogą wdrażać aplikacje szybciej i bardziej niezawodnie.

Ważne

Zalecamy używanie kontenerów dla pakietów aplikacji o znaczeniu krytycznym. Zwiększają one wykorzystanie infrastruktury, ponieważ można hostować wiele kontenerów w tej samej infrastrukturze zwirtualizowanej. Ponadto, ponieważ wszystkie oprogramowanie jest dołączone do kontenera, można przenieść aplikację w różnych systemach operacyjnych, niezależnie od środowisk uruchomieniowych lub wersji biblioteki. Zarządzanie jest również łatwiejsze w przypadku kontenerów niż w przypadku tradycyjnego hostingu zwirtualizowanego.

Aplikacje o krytycznym znaczeniu muszą szybko skalować, aby uniknąć wąskich gardeł wydajności. Ponieważ obrazy kontenerów są wstępnie utworzone, można ograniczyć uruchamianie tylko podczas uruchamiania aplikacji, co zapewnia szybką skalowalność.

Zagadnienia dotyczące projektowania

  • Monitorowanie. Monitorowanie usług w celu uzyskania dostępu do aplikacji w kontenerach może być trudne. Zwykle potrzebne jest oprogramowanie innych firm do zbierania i przechowywania wskaźników stanu kontenera, takich jak użycie procesora CPU lub pamięci RAM.

  • Bezpieczeństwo. Jądro systemu operacyjnego platformy hostingu jest współużytkowane przez wiele kontenerów, tworząc pojedynczy punkt ataku. Jednak ryzyko dostępu do maszyny wirtualnej hosta jest ograniczone, ponieważ kontenery są odizolowane od bazowego systemu operacyjnego.

  • Stan. Chociaż istnieje możliwość przechowywania danych w działającym systemie plików kontenera, dane nie będą utrwalane po ponownym utworzeniu kontenera. Zamiast tego utrwalaj dane przez zainstalowanie magazynu zewnętrznego lub użycie zewnętrznej bazy danych.

Zalecenia dotyczące projektowania

  • Konteneryzowanie wszystkich składników aplikacji. Użyj obrazów kontenerów jako podstawowego modelu pakietów wdrażania aplikacji.

  • Określanie priorytetów środowiska uruchomieniowego kontenera opartego na systemie Linux, gdy jest to możliwe. Obrazy są bardziej lekkie, a nowe funkcje dla węzłów/kontenerów systemu Linux są często wydawane.

  • Umożliwianie niezmiennego i zastępowania kontenerów krótkimi cyklami życia.

  • Pamiętaj, aby zebrać wszystkie odpowiednie dzienniki i metryki z kontenera, hosta kontenera i bazowego klastra. Wyślij zebrane dzienniki i metryki do ujednoliconego ujścia danych w celu dalszego przetwarzania i analizy.

  • Przechowywanie obrazów kontenerów w Azure Container Registry. Replikacja geograficzna umożliwia replikowanie obrazów kontenerów we wszystkich regionach. Włącz Microsoft Defender dla rejestrów kontenerów, aby zapewnić skanowanie pod kątem luk w zabezpieczeniach dla obrazów kontenerów. Upewnij się, że dostęp do rejestru jest zarządzany przez identyfikator Microsoft Entra.

Hosting i aranżacja kontenerów

Kilka platform aplikacji platformy Azure może efektywnie hostować kontenery. Istnieją zalety i wady związane z każdą z tych platform. Porównaj opcje w kontekście wymagań biznesowych. Jednak zawsze optymalizuj niezawodność, skalowalność i wydajność. Więcej informacji można znaleźć w następujących artykułach:

Ważne

Azure Kubernetes Service (AKS) i Azure Container Apps powinny być jednymi z pierwszych wyborów do zarządzania kontenerami w zależności od wymagań. Chociaż Azure App Service nie jest orkiestratorem, jako platforma kontenerów o niskim tarciu, nadal jest to możliwa alternatywa dla usługi AKS.

Zagadnienia dotyczące projektowania i zalecenia dotyczące Azure Kubernetes Service

Usługa AKS, zarządzana usługa Kubernetes, umożliwia szybką aprowizację klastra bez konieczności wykonywania złożonych działań administracyjnych klastrów i oferuje zestaw funkcji, który obejmuje zaawansowane funkcje sieciowe i tożsamości. Aby uzyskać pełny zestaw zaleceń, zobacz Przegląd platformy Azure Well-Architected Framework — AKS.

Ważne

Istnieją pewne podstawowe decyzje dotyczące konfiguracji, których nie można zmienić bez ponownego wdrożenia klastra usługi AKS. Przykłady obejmują wybór między publicznymi i prywatnymi klastrami usługi AKS, włączaniem usługi Azure Network Policy, integracją Microsoft Entra i używaniem tożsamości zarządzanych dla usługi AKS zamiast jednostek usługi.

Niezawodność

Usługa AKS zarządza natywną płaszczyzną sterowania kubernetes. Jeśli płaszczyzna sterowania nie jest dostępna, obciążenie doświadcza przestoju. Skorzystaj z funkcji niezawodności oferowanych przez usługę AKS:

  • Wdrażanie klastrów usługi AKS w różnych regionach platformy Azure jako jednostki skalowania w celu zmaksymalizowania niezawodności i dostępności. Strefy dostępności umożliwiają zmaksymalizowanie odporności w regionie świadczenia usługi Azure przez dystrybucję płaszczyzny sterowania usługi AKS i węzłów agentów w fizycznie oddzielnych centrach danych. Jeśli jednak opóźnienie kolokacji jest problemem, możesz wykonać wdrożenie usługi AKS w jednej strefie lub użyć grup umieszczania w pobliżu , aby zminimalizować opóźnienie międzywęźle.

  • Użyj umowy SLA czasu działania usługi AKS dla klastrów produkcyjnych, aby zmaksymalizować gwarancje dostępności punktu końcowego interfejsu API platformy Kubernetes.

Skalowalność

Weź pod uwagę limity skalowania usługi AKS, takie jak liczba węzłów, pule węzłów na klaster i klastry na subskrypcję.

Izolacja

Utrzymywanie granic między infrastrukturą używaną przez obciążenie i narzędziami systemowymi. Udostępnianie infrastruktury może prowadzić do wysokiego wykorzystania zasobów i hałaśliwych scenariuszy sąsiadów.

  • Użyj oddzielnych pul węzłów dla usług systemowych i obciążeń. Dedykowane pule węzłów dla składników obciążenia powinny być oparte na wymaganiach dotyczących wyspecjalizowanych zasobów infrastruktury, takich jak maszyny wirtualne procesora GPU o dużej ilości pamięci. Ogólnie rzecz biorąc, aby zmniejszyć niepotrzebne obciążenie związane z zarządzaniem, unikaj wdrażania dużej liczby pul węzłów.

  • Użyj defektów i tolerancji , aby zapewnić dedykowane węzły i ograniczyć aplikacje intensywnie korzystające z zasobów.

  • Oceń wymagania dotyczące koligacji aplikacji i ochrony przed koligacją oraz skonfiguruj odpowiednią kolokację kontenerów w węzłach.

Zabezpieczenia

Domyślna waniliowa platforma Kubernetes wymaga znacznej konfiguracji, aby zapewnić odpowiedni stan zabezpieczeń dla scenariuszy o znaczeniu krytycznym. Usługa AKS eliminuje różne zagrożenia bezpieczeństwa gotowe do użycia. Funkcje obejmują klastry prywatne, inspekcję i logowanie do usługi Log Analytics, obrazy węzłów ze wzmocnionymi zabezpieczeniami i tożsamości zarządzane.

  • Zastosuj wskazówki dotyczące konfiguracji podane w punkcie odniesienia zabezpieczeń usługi AKS.

  • Użyj funkcji usługi AKS do obsługi zarządzania tożsamościami klastra i dostępem, aby zmniejszyć obciążenie operacyjne i zastosować spójne zarządzanie dostępem.

  • Użyj tożsamości zarządzanych zamiast jednostek usługi, aby uniknąć zarządzania i rotacji poświadczeń. Tożsamości zarządzane można dodawać na poziomie klastra. Na poziomie zasobnika można używać tożsamości zarządzanych za pośrednictwem Tożsamość obciążeń Microsoft Entra.

  • Użyj integracji Microsoft Entra w celu scentralizowanego zarządzania kontami i haseł, zarządzania dostępem do aplikacji i rozszerzonej ochrony tożsamości. Użyj kontroli dostępu opartej na rolach platformy Kubernetes z identyfikatorem Microsoft Entra w celu uzyskania najniższych uprawnień i zminimalizuj przyznawanie uprawnień administratora, aby ułatwić ochronę dostępu do konfiguracji i wpisów tajnych. Ponadto ogranicz dostęp do pliku konfiguracji klastra Kubernetes przy użyciu kontroli dostępu opartej na rolach platformy Azure. Ogranicz dostęp do akcji, które kontenery mogą wykonywać, zapewniają najmniejszą liczbę uprawnień i unikaj stosowania eskalacji uprawnień głównych.

Uaktualnienia

Klastry i węzły muszą być regularnie uaktualniane. Usługa AKS obsługuje wersje platformy Kubernetes zgodnie z cyklem wydania natywnego rozwiązania Kubernetes.

Sieć

Oceń wtyczki sieciowe, które najlepiej pasują do twojego przypadku użycia. Ustal, czy potrzebujesz szczegółowej kontroli nad ruchem między zasobnikami. Platforma Azure obsługuje platformę Kubenet, usługę Azure CNI i własną sieć CNI w określonych przypadkach użycia.

Określanie priorytetów użycia usługi Azure CNI po ocenie wymagań sieciowych i rozmiaru klastra. Usługa Azure CNI umożliwia korzystanie z zasad sieciowych platformy Azure lub Calico na potrzeby kontrolowania ruchu w klastrze.

Monitorowanie

Narzędzia do monitorowania powinny mieć możliwość przechwytywania dzienników i metryk z uruchomionych zasobników. Należy również zebrać informacje z interfejsu API metryk platformy Kubernetes w celu monitorowania kondycji uruchomionych zasobów i obciążeń.

Nadzór

Zasady umożliwiają stosowanie scentralizowanych zabezpieczeń w klastrach usługi AKS w spójny sposób. Stosowanie przypisań zasad w zakresie subskrypcji lub wyższym w celu zwiększenia spójności między zespołami deweloperów.

  • Kontroluj, które funkcje są przyznawane zasobnikom i czy uruchomione są sprzeczne z zasadami przy użyciu Azure Policy. Ten dostęp jest definiowany za pomocą wbudowanych zasad udostępnianych przez dodatek Azure Policy dla usługi AKS.

  • Ustanów spójną niezawodność i punkt odniesienia zabezpieczeń dla konfiguracji klastra i zasobnika usługi AKS przy użyciu Azure Policy.

  • Użyj dodatku Azure Policy dla usługi AKS, aby kontrolować funkcje zasobników, takie jak uprawnienia główne, i nie zezwalać zasobnikom, które nie są zgodne z zasadami.

Uwaga

Podczas wdrażania w strefie docelowej platformy Azure zasady platformy Azure ułatwiające zapewnienie spójnej niezawodności i bezpieczeństwa powinny być udostępniane przez implementację strefy docelowej.

Implementacje referencyjne o znaczeniu krytycznym zapewniają zestaw zasad punktu odniesienia w celu zapewnienia zalecanej niezawodności i konfiguracji zabezpieczeń.

Zagadnienia i zalecenia dotyczące projektowania dla Azure App Service

W przypadku scenariuszy obciążeń opartych na sieci Web i interfejsie API App Service może być wykonalną alternatywą dla usługi AKS. Zapewnia platformę kontenerów o niskim tarciu bez złożoności rozwiązania Kubernetes. Aby uzyskać pełny zestaw zaleceń, zobacz Zagadnienia dotyczące niezawodności dotyczące App Service i doskonałości operacyjnej dla App Service.

Niezawodność

Oceń użycie portów TCP i SNAT. Połączenia TCP są używane dla wszystkich połączeń wychodzących. Porty SNAT są używane do połączeń wychodzących z publicznymi adresami IP. Wyczerpanie portów SNAT jest typowym scenariuszem awarii. Ten problem należy wykryć predykcyjnie, testując obciążenie podczas korzystania z Diagnostyka Azure do monitorowania portów. Jeśli wystąpią błędy SNAT, należy przeprowadzić skalowanie między większą lub większą skalę procesów roboczych lub zaimplementować praktyki kodowania w celu zachowania i ponownego użycia portów SNAT. Przykłady praktyk kodowania, których można użyć, obejmują buforowanie połączeń i leniwe ładowanie zasobów.

Wyczerpanie portów TCP to inny scenariusz awarii. Występuje, gdy suma połączeń wychodzących z danego procesu roboczego przekracza pojemność. Liczba dostępnych portów TCP zależy od rozmiaru procesu roboczego. Aby uzyskać zalecenia, zobacz Porty TCP i SNAT.

Skalowalność

Zaplanuj przyszłe wymagania dotyczące skalowalności i wzrost aplikacji, aby od początku można było zastosować odpowiednie zalecenia. Dzięki temu można uniknąć długu migracji technicznej w miarę wzrostu rozwiązania.

  • Włącz skalowanie automatyczne, aby upewnić się, że odpowiednie zasoby są dostępne dla żądań obsługi. Oceń skalowanie na aplikację w celu hostowania o wysokiej gęstości na App Service.

  • Należy pamiętać, że App Service ma domyślny, miękki limit wystąpień na plan App Service.

  • Zastosuj reguły automatycznego skalowania. Plan App Service skaluje się w poziomie, jeśli jakakolwiek reguła w profilu jest spełniona, ale tylko skaluje się w przypadku spełnienia wszystkich reguł w profilu. Użyj kombinacji reguł skalowania w poziomie i skalowania w poziomie, aby upewnić się, że skalowanie automatyczne może podejmować działania w celu skalowania w poziomie i skalowania w poziomie. Omówienie zachowania wielu reguł skalowania w jednym profilu.

  • Należy pamiętać, że można włączyć skalowanie poszczególnych aplikacji na poziomie planu App Service, aby umożliwić aplikacji skalowanie niezależnie od planu App Service, który go hostuje. Aplikacje są przydzielane do dostępnych węzłów za pośrednictwem podejścia do równomiernego rozkładu. Mimo że równomierna dystrybucja nie jest gwarantowana, platforma zapewnia, że dwa wystąpienia tej samej aplikacji nie są hostowane w tym samym wystąpieniu.

Monitorowanie

Monitoruj zachowanie aplikacji i uzyskaj dostęp do odpowiednich dzienników i metryk, aby upewnić się, że aplikacja działa zgodnie z oczekiwaniami.

  • Rejestrowanie diagnostyczne umożliwia pozyskiwanie dzienników na poziomie aplikacji i na poziomie platformy do usługi Log Analytics, usługi Azure Storage lub narzędzia innej firmy za pośrednictwem Azure Event Hubs.

  • Monitorowanie wydajności aplikacji za pomocą usługi Application Insights zapewnia szczegółowe informacje na temat wydajności aplikacji.

  • Aplikacje o znaczeniu krytycznym muszą mieć możliwość samodzielnego naprawiania, jeśli wystąpią błędy. Włącz automatyczne naprawianie w celu automatycznego ponownego odzyskiwania pracowników w złej kondycji.

  • Należy użyć odpowiednich kontroli kondycji, aby ocenić wszystkie krytyczne zależności podrzędne, co pomaga zapewnić ogólną kondycję. Zdecydowanie zalecamy włączenie sprawdzania kondycji w celu identyfikowania niesponsywnych procesów roboczych.

Wdrożenie

Aby obejść domyślny limit wystąpień na plan App Service, wdróż plany App Service w wielu jednostkach skalowania w jednym regionie. Wdróż plany App Service w konfiguracji strefy dostępności, aby upewnić się, że węzły procesu roboczego są rozproszone między strefami w regionie. Rozważ otwarcie biletu pomocy technicznej, aby zwiększyć maksymalną liczbę procesów roboczych do dwukrotnie większej liczby wystąpień, które muszą obsługiwać normalne obciążenie szczytowe.

Rejestr kontenerów

Rejestry kontenerów hostują obrazy wdrożone w środowiskach środowiska uruchomieniowego kontenera, takich jak AKS. Należy dokładnie skonfigurować rejestry kontenerów dla obciążeń o krytycznym znaczeniu. Awaria nie powinna powodować opóźnień w ściąganiu obrazów, zwłaszcza podczas operacji skalowania. Poniższe zagadnienia i zalecenia koncentrują się na Azure Container Registry i eksplorują kompromisy związane ze scentralizowanymi i federacyjnymi modelami wdrażania.

Zagadnienia dotyczące projektowania

  • Formatuj. Rozważ użycie rejestru kontenerów, który opiera się na formacie dostarczanym przez platformę Docker i standardach dla operacji wypychania i ściągania. Te rozwiązania są zgodne i w większości zamienne.

  • Model wdrażania. Rejestr kontenerów można wdrożyć jako scentralizowaną usługę używaną przez wiele aplikacji w organizacji. Możesz też wdrożyć go jako dedykowany składnik dla określonego obciążenia aplikacji.

  • Rejestry publiczne. Obrazy kontenerów są przechowywane w Docker Hub lub innych publicznych rejestrach, które istnieją poza platformą Azure i daną siecią wirtualną. Niekoniecznie jest to problem, ale może to prowadzić do różnych problemów związanych z dostępnością usługi, ograniczaniem przepustowości i eksfiltracją danych. W przypadku niektórych scenariuszy aplikacji należy replikować publiczne obrazy kontenerów w prywatnym rejestrze kontenerów, aby ograniczyć ruch wychodzący, zwiększyć dostępność lub uniknąć potencjalnego ograniczania przepustowości.

Zalecenia dotyczące projektowania

  • Użyj wystąpień rejestru kontenerów przeznaczonych dla obciążenia aplikacji. Unikaj tworzenia zależności od scentralizowanej usługi, chyba że wymagania dotyczące dostępności organizacji i niezawodności są w pełni zgodne z aplikacją.

    W zalecanym podstawowym wzorcu architektury rejestry kontenerów są zasobami globalnymi, które są długotrwałe. Rozważ użycie pojedynczego globalnego rejestru kontenerów na środowisko. Na przykład użyj globalnego rejestru produkcyjnego.

  • Upewnij się, że umowa SLA dla rejestru publicznego jest zgodna z celami dotyczącymi niezawodności i zabezpieczeń. Zwróć szczególną uwagę na limity ograniczania przepustowości dla przypadków użycia, które zależą od Docker Hub.

  • Określanie priorytetów Azure Container Registry do hostowania obrazów kontenerów.

Zagadnienia i zalecenia dotyczące projektowania dla Azure Container Registry

Ta natywna usługa udostępnia szereg funkcji, w tym replikację geograficzną, uwierzytelnianie Microsoft Entra, automatyczne kompilowanie kontenerów i stosowanie poprawek za pomocą zadań usługi Container Registry.

Niezawodność

Skonfiguruj replikację geograficzną do wszystkich regionów wdrażania, aby usunąć zależności regionalne i zoptymalizować opóźnienie. Usługa Container Registry obsługuje wysoką dostępność za pośrednictwem replikacji geograficznej do wielu skonfigurowanych regionów, zapewniając odporność na awarie regionalne. Jeśli region stanie się niedostępny, inne regiony będą nadal obsługiwać żądania obrazów. Gdy region jest z powrotem w trybie online, usługa Container Registry odzyskuje i replikuje zmiany do niego. Ta funkcja zapewnia również kolokację rejestru w każdym skonfigurowanym regionie, co zmniejsza opóźnienie sieci i transfer danych między regionami.

W regionach platformy Azure, które zapewniają obsługę strefy dostępności, warstwa Premium Container Registry obsługuje nadmiarowość strefy w celu zapewnienia ochrony przed awarią strefową. Warstwa Premium obsługuje również prywatne punkty końcowe , aby zapobiec nieautoryzowanemu dostępowi do rejestru, co może prowadzić do problemów z niezawodnością.

Hostowanie obrazów w pobliżu zużywających zasobów obliczeniowych w tych samych regionach świadczenia usługi Azure.

Blokowanie obrazu

Obrazy mogą zostać usunięte, na przykład w wyniku błędu ręcznego. Usługa Container Registry obsługuje blokowanie wersji obrazu lub repozytorium w celu zapobiegania zmianom lub usuwaniu. Gdy wcześniej wdrożona wersja obrazu zostanie zmieniona, wdrożenia w tej samej wersji mogą zapewnić różne wyniki przed zmianą i po jej zmianie.

Jeśli chcesz chronić wystąpienie usługi Container Registry przed usunięciem, użyj blokad zasobów.

Oznakowane obrazy

Obrazy tagów usługi Container Registry są domyślnie modyfikowalne, co oznacza, że ten sam tag może być używany na wielu obrazach wypychanych do rejestru. W scenariuszach produkcyjnych może to prowadzić do nieprzewidywalnego zachowania, które może mieć wpływ na czas pracy aplikacji.

Zarządzanie tożsamościami i dostępem

Użyj Microsoft Entra zintegrowanego uwierzytelniania, aby wypychać i ściągać obrazy zamiast polegać na kluczach dostępu. W przypadku zwiększonych zabezpieczeń w pełni wyłącz użycie klucza dostępu administratora.

Bezserwerowe usługi obliczeniowe

Przetwarzanie bezserwerowe zapewnia zasoby na żądanie i eliminuje konieczność zarządzania infrastrukturą. Dostawca chmury automatycznie aprowizuje, skaluje i zarządza zasobami wymaganymi do uruchomienia wdrożonego kodu aplikacji. Platforma Azure udostępnia kilka platform obliczeniowych bezserwerowych:

  • Azure Functions. W przypadku korzystania z Azure Functions logika aplikacji jest implementowana jako odrębne bloki kodu lub funkcji, które są uruchamiane w odpowiedzi na zdarzenia, takie jak żądanie HTTP lub komunikat kolejki. Każda funkcja jest skalowana zgodnie z potrzebami w celu spełnienia wymagań.

  • Azure Logic Apps. Usługa Logic Apps najlepiej nadaje się do tworzenia i uruchamiania zautomatyzowanych przepływów pracy, które integrują różne aplikacje, źródła danych, usługi i systemy. Podobnie jak Azure Functions, usługa Logic Apps używa wbudowanych wyzwalaczy do przetwarzania opartego na zdarzeniach. Jednak zamiast wdrażania kodu aplikacji można tworzyć aplikacje logiki przy użyciu graficznego interfejsu użytkownika, który obsługuje bloki kodu, takie jak warunkowe i pętle.

  • Azure API Management. Za pomocą API Management można publikować, przekształcać, obsługiwać i monitorować interfejsy API zwiększonych zabezpieczeń przy użyciu warstwy Zużycie.

  • Power Apps i Power Automate. Te narzędzia zapewniają środowisko programistyczne o niskim kodzie lub braku kodu z prostą logiką przepływu pracy i integracją konfigurowalną za pośrednictwem połączeń w interfejsie użytkownika.

W przypadku aplikacji o krytycznym znaczeniu technologie bezserwerowe zapewniają uproszczone programowanie i operacje, które mogą być przydatne w przypadku prostych przypadków użycia firmy. Jednak ta prostota wiąże się z kosztem elastyczności w zakresie skalowalności, niezawodności i wydajności oraz nie jest to możliwe w przypadku większości scenariuszy aplikacji o znaczeniu krytycznym.

W poniższych sekcjach przedstawiono zagadnienia i zalecenia dotyczące projektowania dotyczące używania Azure Functions i usługi Logic Apps jako alternatywnych platform dla scenariuszy przepływu pracy niekrytycznych.

Zagadnienia i zalecenia dotyczące projektowania Azure Functions

Obciążenia o krytycznym znaczeniu mają krytyczne i niekrytyczne przepływy systemu. Azure Functions jest opłacalnym wyborem dla przepływów, które nie mają tych samych rygorystycznych wymagań biznesowych co krytyczne przepływy systemowe. Dobrze nadaje się do przepływów opartych na zdarzeniach, które mają procesy krótkotrwałe, ponieważ funkcje wykonują różne operacje, które są uruchamiane tak szybko, jak to możliwe.

Wybierz opcję hostingu Azure Functions odpowiednią dla warstwy niezawodności aplikacji. Zalecamy plan Premium, ponieważ umożliwia skonfigurowanie rozmiaru wystąpienia obliczeniowego. Plan dedykowany jest najmniej bezserwerową opcją. Zapewnia automatyczne skalowanie, ale te operacje skalowania są wolniejsze niż te z innych planów. Zalecamy użycie planu Premium w celu zmaksymalizowania niezawodności i wydajności.

Istnieją pewne zagadnienia dotyczące zabezpieczeń. Gdy używasz wyzwalacza HTTP do uwidocznienia zewnętrznego punktu końcowego, użyj zapory aplikacji internetowej (WAF), aby zapewnić poziom ochrony punktu końcowego HTTP z typowych wektorów ataków zewnętrznych.

Zalecamy używanie prywatnych punktów końcowych do ograniczania dostępu do prywatnych sieci wirtualnych. Mogą również ograniczyć ryzyko eksfiltracji danych, takie jak złośliwe scenariusze administratora.

Należy użyć narzędzi do skanowania kodu w kodzie Azure Functions i zintegrować te narzędzia z potokami ciągłej integracji/ciągłego wdrażania.

Zagadnienia i zalecenia dotyczące projektowania usługi Azure Logic Apps

Podobnie jak Azure Functions, usługa Logic Apps używa wbudowanych wyzwalaczy do przetwarzania opartego na zdarzeniach. Jednak zamiast wdrażania kodu aplikacji można tworzyć aplikacje logiki przy użyciu graficznego interfejsu użytkownika, który obsługuje bloki, takie jak warunkowe, pętle i inne konstrukcje.

Dostępnych jest wiele trybów wdrażania . Zalecamy tryb standardowy, aby zapewnić wdrożenie z jedną dzierżawą i ograniczyć hałaśliwych scenariuszy sąsiadów. W tym trybie jest używane konteneryzowane środowisko uruchomieniowe usługi Logic Apps z jedną dzierżawą, które jest oparte na Azure Functions. W tym trybie aplikacja logiki może mieć wiele przepływów pracy stanowych i bezstanowych. Należy pamiętać o limitach konfiguracji.

Migracje ograniczone za pośrednictwem usługi IaaS

Wiele aplikacji, które mają istniejące wdrożenia lokalne, korzystają z technologii wirtualizacji i nadmiarowego sprzętu w celu zapewnienia krytycznych poziomów niezawodności. Modernizacja jest często utrudniona przez ograniczenia biznesowe, które uniemożliwiają pełne dopasowanie do natywnego dla chmury wzorca architektury (North Star), który jest zalecany dla obciążeń o znaczeniu krytycznym. Dlatego wiele aplikacji stosuje podejście etapowe z początkowymi wdrożeniami w chmurze przy użyciu wirtualizacji i platformy Azure Virtual Machines jako podstawowego modelu hostingu aplikacji. Korzystanie z maszyn wirtualnych IaaS może być wymagane w niektórych scenariuszach:

  • Dostępne usługi PaaS nie zapewniają wymaganej wydajności ani poziomu kontroli.
  • Obciążenie wymaga dostępu do systemu operacyjnego, określonych sterowników lub konfiguracji sieci i systemu.
  • Obciążenie nie obsługuje uruchamiania w kontenerach.
  • Nie ma obsługi dostawców dla obciążeń innych firm.

Ta sekcja koncentruje się na najlepszych sposobach korzystania z usługi Azure Virtual Machines i skojarzonych usług w celu zmaksymalizowania niezawodności platformy aplikacji. Wyróżnia kluczowe aspekty metodologii projektowania o znaczeniu krytycznym, które transponują scenariusze migracji IaaS natywne dla chmury i IaaS.

Zagadnienia dotyczące projektowania

  • Koszty operacyjne korzystania z maszyn wirtualnych IaaS są znacznie wyższe niż koszty korzystania z usług PaaS ze względu na wymagania związane z zarządzaniem maszynami wirtualnymi i systemami operacyjnymi. Zarządzanie maszynami wirtualnymi wymaga częstego wprowadzania pakietów i aktualizacji oprogramowania.

  • Platforma Azure oferuje możliwości zwiększenia dostępności maszyn wirtualnych:

    • Zestawy dostępności mogą pomóc w ochronie przed awariami sieci, dysku i zasilania przez dystrybucję maszyn wirtualnych w domenach błędów i domenach aktualizacji.
    • Strefy dostępności mogą pomóc w osiągnięciu jeszcze wyższego poziomu niezawodności przez dystrybucję maszyn wirtualnych w fizycznie oddzielonych centrach danych w regionie.
    • Virtual Machine Scale Sets zapewniają funkcje automatycznego skalowania liczby maszyn wirtualnych w grupie. Zapewniają one również możliwości monitorowania kondycji wystąpienia i automatycznego naprawiania wystąpień w złej kondycji.

Zalecenia dotyczące projektowania

Ważne

Używaj usług PaaS i kontenerów, jeśli to możliwe, aby zmniejszyć złożoność operacyjną i koszty. Używaj maszyn wirtualnych IaaS tylko wtedy, gdy jest to konieczne.

  • Rozmiar jednostki SKU maszyny wirtualnej o odpowiednim rozmiarze w celu zapewnienia efektywnego wykorzystania zasobów.

  • Wdróż co najmniej trzy maszyny wirtualne w różnych strefach dostępności , aby osiągnąć odporność na uszkodzenia na poziomie centrum danych.

    • Jeśli wdrażasz komercyjne oprogramowanie gotowe do obsługi, zapoznaj się z dostawcą oprogramowania i odpowiednio przetestuj go przed wdrożeniem oprogramowania w środowisku produkcyjnym.

  • W przypadku obciążeń, których nie można wdrożyć w różnych strefach dostępności, użyj zestawów dostępności zawierających co najmniej trzy maszyny wirtualne.

    • Rozważ zestawy dostępności tylko wtedy, gdy strefy dostępności nie spełniają wymagań dotyczących obciążeń, takich jak obciążenia czatty z wymaganiami dotyczącymi małych opóźnień.

  • Określanie priorytetów użycia Virtual Machine Scale Sets w celu zapewnienia skalowalności i nadmiarowości stref. Jest to szczególnie ważne w przypadku obciążeń, które mają różne obciążenia. Jeśli na przykład liczba aktywnych użytkowników lub żądań na sekundę jest różna.

  • Nie uzyskujesz bezpośredniego dostępu do poszczególnych maszyn wirtualnych. Używaj modułów równoważenia obciążenia przed nimi, jeśli jest to możliwe.

  • Aby chronić się przed awariami regionalnymi, wdróż maszyny wirtualne aplikacji w wielu regionach świadczenia usługi Azure.

  • W przypadku obciążeń, które nie obsługują wdrożeń aktywnych/aktywnych w wielu regionach, rozważ zaimplementowanie aktywnych/pasywnych wdrożeń przy użyciu gorących/ciepłych maszyn wirtualnych rezerwowych na potrzeby regionalnego trybu failover.

  • Użyj standardowych obrazów z Azure Marketplace, a nie niestandardowych obrazów, które należy zachować.

  • Zaimplementuj zautomatyzowane procesy w celu wdrażania i wdrażania zmian na maszynach wirtualnych, unikając ręcznej interwencji. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące IaaS w obszarze projektowania procedur operacyjnych .

  • Zaimplementuj eksperymenty chaosu, aby wstrzyknąć błędy aplikacji do składników maszyny wirtualnej i obserwować ograniczanie błędów. Aby uzyskać więcej informacji, zobacz Ciągła walidacja i testowanie.

  • Monitoruj maszyny wirtualne i upewnij się, że dzienniki diagnostyczne i metryki są pozyskiwane do ujednoliconego ujścia danych.

  • Zaimplementuj rozwiązania zabezpieczeń dla scenariuszy aplikacji o znaczeniu krytycznym, jeśli ma to zastosowanie, oraz najlepsze rozwiązania dotyczące zabezpieczeń obciążeń IaaS na platformie Azure.

Następny krok

Zapoznaj się z zagadnieniami dotyczącymi platformy danych.

Platforma danych