Dostarczanie i wydajność aplikacji

Ten artykuł pomaga wybrać odpowiednią usługę Azure do równoważenia obciążenia dla Twoich obciążeń. Porównuje Azure Load Balancer, usługę Application Gateway i Azure Front Door dla dystrybucji ruchu regionalnego i globalnego. Wyjaśnia również, kiedy je połączyć. Aby zapoznać się z krótszym przeglądem poszczególnych usług, zobacz Czym jest równoważenie obciążenia i dostarczanie treści?

Co opisano w tym artykule

Dostarczanie aplikacji obejmuje sposób, w jaki Twoja sieć rozdziela ruch pomiędzy zasobami backendu po jego dotarciu do obwodu sieci. W tym artykule opisano równoważenie obciążenia warstwy 4 i warstwy 7 oraz globalne przyspieszenie ruchu. Obejmuje również kryteria podejmowania decyzji dotyczące wyboru między trzema podstawowymi usługami równoważenia obciążenia Azure.

Note

Ten artykuł uzupełnia Ruch przychodzący z internetu: udostępnianie aplikacji w internecie, który koncentruje się na tym, jak ruch dociera do Twojej sieci. W tym artykule opisano sposób równoważenia i dostarczania tego ruchu do zapleczy aplikacji.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli:

  • Hostuj aplikacje internetowe lub interfejsy API, które wymagają wysokiej dostępności w wielu instancjach zaplecza.
  • Potrzebujesz odciążania SSL/TLS, routingu opartego na adresach URL lub ochrony zapory aplikacji internetowych (WAF) dla ruchu HTTP/HTTPS.
  • Dystrybuuj ruch między wieloma regionami Azure w celu uzyskania wydajności lub odzyskiwania po awarii.
  • Uruchom obciążenia inne niż HTTP (TCP/UDP), które wymagają regionalnego równoważenia obciążenia z sondami kondycji.
  • Chcesz zrozumieć, który moduł równoważenia obciążenia pasuje do typu ruchu, zakresu geograficznego i wymagań dotyczących zabezpieczeń.

Podejście typu lift-and-shift: Wiele wewnętrznych aplikacji przeniesionych bez większych zmian wymaga jedynie regionalnego mechanizmu równoważenia obciążenia. Dodaj usługi dostarczania dostępne z Internetu podczas publikowania aplikacji dla klientów.

Obszar modernizacji: Wybierz sposób dostarczania według typu aplikacji: Azure Front Door dla globalnych aplikacji internetowych oraz Traffic Manager dla aplikacji innych niż internetowe, przed regionalnymi punktami końcowymi w konfiguracji aktywny-aktywny.

Podejście wielochmurowe: Mapuj moduły równoważenia obciążenia z innych chmur na ich odpowiedniki na platformie Azure (na przykład AWS ALB na Application Gateway, NLB na Azure Load Balancer) i udostępniaj je przez sieć spoke, za zaporą sieciową koncentratora.

Usługi i funkcje platformy Azure

Poniższa tabela zawiera podsumowanie trzech podstawowych usług równoważenia obciążenia Azure.

Service Co zapewnia Kiedy należy go używać Ograniczenia klucza
Azure usługa Load Balancer w warstwie Standardowa Równoważenie obciążenia warstwy 4 (TCP/UDP) w regionie. Sondy kondycji, nadmiarowość strefowa, reguły wychodzącego SNAT i porty wysokiej dostępności dla wirtualnych urządzeń sieciowych. zestawy skalowania maszyn wirtualnych, wewnętrzny ruch AKS, regionalne obciążenia inne niż HTTP/HTTPS oraz wysoka dostępność NVA. Brak terminacji SSL/TLS; brak WAF; brak routingu na podstawie adresu URL; tylko zasięg regionalny.
Azure Application Gateway Regionalne równoważenie obciążenia warstwy 7 (HTTP/HTTPS). Kończenie żądań protokołu SSL/TLS, routing oparty na ścieżkach URL, hosting w wielu lokacjach, koligacja sesji na podstawie plików cookie i opcjonalna integracja zapory aplikacji internetowej. Regionalne aplikacje internetowe, które wymagają odciążania SSL, trasowania adresów URL, obsługi protokołu WebSocket lub ochrony WAF. Tylko regionalne; wymaga dedykowanej podsieci; nie nadaje się do obsługi globalnych scenariuszy routingu lub sieci CDN.
Azure Front Door Globalne równoważenie obciążenia emisji i sieć CDN. Terminacja TLS na brzegu sieci, zintegrowany WAF, sondy kondycji serwera źródłowego, podział ruchu oraz buforowanie w ponad 190 globalnych punktach obecności (PoP). Globalne aplikacje internetowe, wdrożenia aktywne-aktywne w wielu regionach, CDN i buforowanie oraz globalne egzekwowanie zasad WAF. tylko HTTP/HTTPS; źródła muszą być publicznie dostępne lub dostępne przez Private Link (poziom premium).

Redundancja strefowa

Nadmiarowość strefowa chroni warstwę dostarczania aplikacji przed awariami centrów danych. Każda usługa obsługuje strefy dostępności inaczej:

  • usługa Load Balancer w warstwie Standardowa (publiczny) jest domyślnie nadmiarowy strefowo, ponieważ publiczne adresy IP w warstwie Standard są domyślnie skonfigurowane jako nadmiarowe strefowo. Ruch będzie nadal przepływać, nawet jeśli jedna strefa dostępności ulegnie awarii. usługa Load Balancer w warstwie Standardowa (wewnętrzny) wymaga jawnej konfiguracji frontonu strefowo nadmiarowego: podczas tworzenia adresu IP frontonu należy wybrać wiele stref.
  • Usługa Application Gateway w wersji 2 obsługuje nadmiarowość stref podczas wdrażania wystąpień w wielu strefach dostępności. Określ strefy podczas wdrażania. Strefowo nadmiarowa usługa Application Gateway rozpowszechnia wystąpienia w wybranych strefach, zachowując dostępność, jeśli pojedyncza strefa przejdzie w tryb offline.
  • Azure Front Door jest z natury strefowo nadmiarowa jako globalna usługa emisji. Ponad 190 brzegowych punktów PoP jest rozmieszczonych w wielu regionach na całym świecie, więc awaria pojedynczej strefy ani regionu nie wpływa na globalne kierowanie ruchem.

Autoscaling

Każda usługa obsługuje skalowanie w inny sposób:

  • Usługa Application Gateway w wersji 2 (warstwa Standard_v2 i WAF_v2) obsługuje skalowanie automatyczne na podstawie obciążenia ruchu. Konfigurujesz minimalną i maksymalną liczbę wystąpień, a brama skaluje się w tych granicach. Ceny korzystają z jednostek pojemności: złożona miara nowych połączeń na sekundę, połączenia trwałe i przepływność. Ustaw minimalną liczbę instancji na co najmniej dwie dla obciążeń produkcyjnych, aby uniknąć opóźnień związanych z zimnym startem podczas nagłych skoków ruchu.
  • Azure Front Door skaluje się automatycznie jako zarządzana usługa globalna. Nie potrzebujesz planowania pojemności ani doboru rozmiaru instancji.
  • usługa Load Balancer w warstwie Standardowa skaluje do milionów przepływów TCP/UDP bez ręcznej interwencji lub zmian konfiguracji. To w pełni zarządzana usługa platformowa bez koncepcji instancji.

Sondy kondycji

Wszystkie trzy usługi korzystają z sond kondycji do wykrywania backendów w złym stanie i zaprzestania kierowania do nich ruchu:

  • usługa Load Balancer w warstwie Standardowa obsługuje sondy kondycji TCP, HTTP i HTTPS. Skonfiguruj interwały sondowania i progi uznania za niezdrowy, aby kontrolować szybkość przełączania awaryjnego. Krótsze interwały wykrywają błędy szybciej, ale generują większy ruch sondy.
  • Application Gateway używa sond kondycji HTTP/HTTPS z konfigurowalnymi ścieżkami, nazwami hostów i dopasowaniem odpowiedzi. Niestandardowe sondy umożliwiają weryfikowanie logiki aplikacji (na przykład sprawdzenie punktu końcowego /health , który weryfikuje łączność z bazą danych).
  • Front Door używa sond kondycji HTTP/HTTPS dla źródeł. Obsługuje konfigurowalne ścieżki sond, interwały i dopasowywanie kodu odpowiedzi. Front Door sonduje źródła z wielu punktów obecności (PoP), zapewniając rozproszoną weryfikację stanu.

Jak wybrać

Poniższy schemat blokowy zawiera podsumowanie podstawowej ścieżki decyzyjnej dotyczącej wybierania usługi równoważenia obciążenia Azure.

Schemat blokowy przedstawiający wybór usługi równoważenia obciążenia na platformie Azure z podziałem według ruchu HTTP i innego niż HTTP, a następnie według zakresu: pojedynczy region lub zasięg globalny.

Skorzystaj z poniższych tabel decyzyjnych, aby wybrać odpowiednią usługę równoważenia obciążenia dla danego scenariusza.

Którego modułu równoważenia obciążenia potrzebuję?

Muszę... Użyj
Równoważenie obciążenia ruchu TCP/UDP w jednym regionie Azure usługa Load Balancer w warstwie Standardowa: równoważenie obciążenia w warstwie 4 z sondami kondycji, nadmiarowością strefową i portami wysokiej dostępności.
Kończenie połączeń SSL/TLS, kierowanie na podstawie ścieżki URL lub nazwy hosta oraz dodanie zapory aplikacji internetowej (WAF) dla regionalnej aplikacji internetowej Azure Application Gateway: Regionalne równoważenie obciążenia warstwy 7 ze zintegrowaną zaporą aplikacji sieci Web (SKU v2).
Kieruj ruchem HTTP/HTTPS globalnie, zmniejszaj opóźnienia dzięki buforowaniu brzegowemu lub stosuj przełączanie awaryjne między regionami Azure Front Door: globalny anycast z siecią CDN, usługą WAF i sondami kondycji źródeł wieloregionowych.

Porównanie kluczowych ograniczeń

Service Warstwa Scope Kluczowe ograniczenie
usługa Load Balancer w warstwie Standardowa Warstwa 4 (TCP/UDP) Regionalne Brak rozpoznawania aplikacji: nie można sprawdzić nagłówków HTTP, adresów URL ani plików cookie.
Application Gateway Warstwa 7 (HTTP/HTTPS) Regionalne Wymaga dedykowanej podsieci (/24 zalecane); nie może kierować ruchu globalnie.
Front Door Warstwa 7 (HTTP/HTTPS) Global Źródła muszą być publiczne lub dostępne przez Private Link (tylko poziom premium); nie obsługuje TCP/UDP.

Łączenie usług

Wiele architektur produkcyjnych łączy wiele usług równoważenia obciążenia w łańcuchu. Każda usługa obsługuje to, co robi najlepiej:

  • Front Door + Application Gateway: Użyj usługi Front Door do globalnej dystrybucji ruchu i brzegowego WAF, a następnie kieruj ruch do regionalnych wystąpień usługi Application Gateway na potrzeby routingu opartego na ścieżkach adresów URL i zarządzania pulami zaplecza. Usługa Front Door Premium może łączyć się z usługą Application Gateway za pośrednictwem Private Link, zachowując prywatność usługi Application Gateway. Ten wzorzec pasuje do wdrożeń w wielu regionach, w których każdy region ma złożone wymagania dotyczące routingu adresów URL.
  • Front Door + Load Balancer: Użyj usługi Front Door do globalnej dystrybucji ruchu HTTP/HTTPS, z umieszczonym za nią wewnętrznym modułem usługa Load Balancer w warstwie Standardowa, aby rozkładać ruch między zestawy skalowania maszyn wirtualnych lub urządzenia NVA w danym regionie. Usługa Front Door obsługuje globalny routing i buforowanie, natomiast usługa Load Balancer zapewnia dystrybucję na poziomie warstwy 4 do wystąpień obliczeniowych.
  • Application Gateway + Load Balancer: użyj usługi Application Gateway do zarządzania ruchem HTTP/HTTPS w frontonie i Load Balancer dla warstw zaplecza innych niż HTTP (bazy danych, kolejki komunikatów) w tym samym wdrożeniu. Ten wzorzec utrzymuje inteligencję warstwy 7 na brzegu sieci, a wewnątrz wykorzystuje lekką dystrybucję ruchu w warstwie 4.

Możliwości routingu

Zrozumienie możliwości routingu pomaga zawęzić wybór:

Capability usługa Load Balancer w warstwie Standardowa Application Gateway Front Door
Routing oparty na ścieżkach URL No Yes Yes
Routing obejmujący wiele witryn (nagłówek hosta) No Yes Yes
Afinacja sesji oparta na plikach cookie No Yes Yes
Ważony podział ruchu No No Yes
Routing geograficzny No No Yes
Odciążanie protokołu SSL/TLS No Yes Yes
Obsługa protokołu WebSocket Przekazywanie Yes Yes
Obsługa protokołu HTTP/2 No Yes Yes

Tip

Usługa Application Gateway w wersji 2 automatycznie skaluje się między minimalną i maksymalną liczbą wystąpień, a płacisz za co najmniej minimalną pojemność nawet wtedy, gdy ruch jest bezczynny. Ustaw minimalną liczbę instancji zgodnie z obciążeniem bazowym, a nie szczytowym, i pozwól automatycznemu skalowaniu obsługiwać nagłe skoki obciążenia. Ustawienie zbyt wysokiej wartości minimalnej jest częstą przyczyną niepotrzebnych kosztów usługi Application Gateway.

Uwagi dotyczące projektowania

Fokus projektowania dostarczania aplikacji metodą "lift-and-shift"

  • Użyj wewnętrznego Azure Load Balancer do obsługi ruchu wschód-zachód między warstwami ponownie hostowanej aplikacji, tak aby odpowiadał mechanizmowi równoważenia obciążenia, z którego aplikacja już korzystała.
  • Dodaj publiczne usługi udostępniania tylko dla aplikacji, które wystawiasz do internetu; wiele zmigrowanych obciążeń wewnętrznych nie wymaga żadnych takich usług.
  • Podczas początkowej migracji typu rehost zachowaj prostą architekturę wdrożenia ograniczoną do jednego regionu.
  • Kierowanie dowolnego przychodzącego ruchu internetowego przez zaporę koncentratora przed dotarciem do obciążenia.

Modernizuj fokus projektowania dostarczania aplikacji

  • Wybierz według typu aplikacji: Azure Front Door dla globalnych aplikacji internetowych (terminacja na brzegu sieci, WAF) oraz Azure Traffic Manager dla aplikacji nieinternetowych, które wymagają regionalnej dystrybucji opartej na DNS.
  • Wdróż architekturę active-active w wielu regionach i rozdystrybuuj ruch do publicznego punktu końcowego w każdym regionie za zaporą sieciową koncentratora, która pełni funkcję SNAT i DNAT.
  • Użyj Application Gateway do regionalnego routingu warstwy 7 i terminacji TLS za usługą Front Door, gdy potrzebujesz dostarczania na skalę globalną.
  • Nie wdrażaj jednocześnie Front Door i Traffic Manager dla tego samego ruchu; wybierz jedno z nich w zależności od tego, czy aplikacja jest internetowa, czy nieinternetowa.

Skoncentrowanie na projektowaniu dostarczania aplikacji między chmurami

  • Mapowanie usług dostarczania aplikacji z innych chmur na platformę Azure: AWS Application Load Balancer lub Google Cloud Application Load Balancing na usługę Azure Application Gateway, a modułów równoważenia obciążenia sieciowego na usługę Azure Load Balancer.
  • Hostuj dostarczanie warstwy 7 (Application Gateway z zaporą aplikacyjną, WAF) w sieci spoke i unikaj przypisywania publicznych adresów IP bezpośrednio do maszyn wirtualnych.
  • Kieruj publiczny ruch przychodzący przez zabezpieczoną zaporę centrum, zanim dotrze do zmigrowanych obciążeń roboczych.
  • Użyj usługi Front Door lub Traffic Manager do obsługi wieloregionowej, gdy obciążenia działają w więcej niż jednym regionie platformy Azure.

Prerequisites

Przed wdrożeniem usług dostarczania aplikacji:

  • Wdrożona sieć wirtualna: Potrzebna jest co najmniej jedna sieć wirtualna z podsieciami. Zobacz Projektowanie sieci wirtualnej i podsieci , aby uzyskać wskazówki dotyczące planowania podsieci.
  • Zidentyfikowano typ ruchu obciążenia: Dowiedz się, czy obciążenie korzysta z protokołu HTTP/HTTPS (warstwa 7) lub TCP/UDP (warstwa 4). Ten typ ruchu decyduje o Twoim głównym wyborze load balancera.
  • Zdefiniowany zakres geograficzny: Ustal, czy użytkownicy znajdują się w jednym regionie, czy w skali globalnej. Globalne grupy użytkowników korzystają z akceleracji anycast usługi Front Door.
  • Pojemność podsieci dla usługi Application Gateway: Usługa Application Gateway wymaga dedykowanej podsieci bez innych zasobów. Podsieć /24 obsługuje do 125 instancji plus pięć adresów zarezerwowanych w Azure.

Zagadnienia dotyczące zabezpieczeń

Usługi równoważenia obciążenia są częścią obwodu zabezpieczeń. Są to pierwsze składniki do przetwarzania ruchu przychodzącego, co sprawia, że ich konfiguracja zabezpieczeń ma kluczowe znaczenie. Postępuj zgodnie z tymi rozwiązaniami, aby chronić warstwę dostarczania aplikacji.

Zapora aplikacji internetowej

Włącz WAF w trybie zapobiegania w usłudze Application Gateway lub Front Door dla wszystkich produkcyjnych obciążeń internetowych. Tryb wykrywania rejestruje zagrożenia tylko bez blokowania ich. Użyj go podczas początkowego dostrajania, aby zidentyfikować wyniki fałszywie dodatnie, a następnie przełącz się do trybu zapobiegania przed przepływami ruchu produkcyjnego.

WAF chroni przed typowymi atakami internetowymi, w tym:

  • Wstrzykiwanie SQL i skryptowanie między witrynami (XSS)
  • Anomalie protokołu i przemycanie żądań
  • Boty i przeszukiwarki (z regułami ochrony botów)
  • Zagrożenia z listy OWASP Top 10 przy użyciu zarządzanych zestawów reguł

Zarówno usługa WAF w Application Gateway, jak i usługa WAF w Front Door używają tego samego aparatu reguł, ale różnią się zakresem. Zapora aplikacji internetowych usługi Application Gateway chroni wdrożenie w regionie, a zapora aplikacji internetowych usługi Front Door egzekwuje zasady na globalnym brzegu sieci, zanim ruch dotrze do jakiegokolwiek źródła pochodzenia. Szczegółowe informacje na temat dostrajania zapory WAF i konfiguracji reguł można znaleźć w artykule Web Application Firewall.

ochrona przed atakami DDoS

Włącz ochronę Azure DDoS na wszystkich publicznych adresach IP powiązanych z usługami load balance. Publiczne adresy IP frontonu usługi usługa Load Balancer w warstwie Standardowa oraz publiczne adresy IP usługi Application Gateway są głównymi celami ataków wolumetrycznych. Te adresy IP reprezentują punkty wejścia aplikacji.

usługa Azure ochrona przed atakami DDoS zapewnia:

  • Zawsze włączone monitorowanie ruchu przy użyciu dostrajania adaptacyjnego.
  • Automatyczne ograniczanie ryzyka ataków, gdy ruch przekracza próg.
  • Telemetria ataków i alerty za pośrednictwem usługi Azure Monitor.
  • Ochrona kosztów (kredyt usługowy) w przypadku skalowania zasobów wywołanego przez ataki DDoS.

Aby zapoznać się z planowaniem i konfiguracją ochrony przed atakami DDoS, zobacz Ochrona przed atakami DDoS.

Azure Front Door Premium obsługuje łączność Private Link z źródłami. Ta funkcja eliminuje konieczność korzystania z publicznie dostępnych serwerów zaplecza. Usługa Front Door łączy się ze źródłem za pośrednictwem sieci szkieletowej Azure zamiast publicznego Internetu. Używaj źródeł Private Link, gdy:

  • Zaplecza to usługi wewnętrzne, które nie powinny mieć publicznych adresów IP.
  • Należy ograniczyć dostęp do źródła wyłącznie do ruchu z usługi Front Door.
  • Wymagania dotyczące zgodności uniemożliwiają publiczne punkty końcowe na serwerach aplikacji.
  • Chcesz usunąć powierzchnię ataku publicznie narażonego źródła.

Obsługiwane źródła z użyciem usługi Private Link obejmują usługę App Service, usługę Azure Storage, usługę Application Gateway, wewnętrzny moduł równoważenia obciążenia w warstwie Standard oraz źródła niestandardowe z usługą Private Link.

Aby uzyskać informacje na temat wzorców architektury Private Link, zobacz Prywatny dostęp do usług PaaS Azure.

Ważna

Warstwa Standardowa usługi Front Door nie obsługuje Private Link ze źródłami. Ta możliwość zapewnia tylko usługa Front Door Premium.

Wzajemne protokoły TLS (mTLS)

Usługa Application Gateway w wersji 2 obsługuje wzajemne protokoły TLS na potrzeby uwierzytelniania zaplecza. Użyj mTLS, gdy serwery zaplecza wymagają uwierzytelniania klienta za pomocą certyfikatów przez bramę. To uwierzytelnianie dodaje warstwę weryfikacji zaufania. Zaplecze może potwierdzić, że ruch pochodzi z legalnej instancji Application Gateway, a nie od złośliwego podmiotu, który ominął bramę.

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Kontrolowanie wychodzącego ruchu internetowego: scentralizowanie dostępu wychodzącego za pośrednictwem zapory centrum i wyłączanie domyślnego ruchu wychodzącego.

Kolejny etap procesu modernizacji:

Skonfiguruj prywatną łączność z usługami PaaS: utwórz podsieci Private Link w każdej sieci wirtualnej typu spoke dla obciążeń AKS, ASE i zarządzanych baz danych.

Kolejny krok w Twojej wielochmurowej podróży:

Zabezpiecz ścieżkę tranzytową między chmurami: wdroż usługę Azure Firewall w bezpiecznym centrum wirtualnym, aby kontrolować cały ruch między chmurami i kierowany do Internetu.