Globalny ruch przychodzący HTTP o znaczeniu krytycznym

Aplikacje o znaczeniu krytycznym muszą utrzymywać wysoki poziom czasu pracy, nawet jeśli składniki sieciowe są niedostępne lub mają obniżoną wydajność. Podczas projektowania ruchu przychodzącego, routingu i zabezpieczeń ruchu internetowego można rozważyć połączenie wielu usług platformy Azure w celu osiągnięcia wyższego poziomu dostępności i uniknięcia pojedynczego punktu awarii.

Jeśli zdecydujesz się zastosować to podejście, musisz zaimplementować oddzielną ścieżkę sieci na serwerach aplikacji, a każda ścieżka musi być skonfigurowana i przetestowana oddzielnie. Należy dokładnie rozważyć pełne implikacje tego podejścia.

W tym artykule opisano podejście do obsługi globalnego ruchu przychodzącego HTTP za pośrednictwem usługi Azure Front Door i Azure Application Gateway. Takie podejście może odpowiadać Twoim potrzebom, jeśli twoje rozwiązanie wymaga:

• Usługa Azure Front Door na potrzeby globalnego routingu ruchu. Może to oznaczać, że masz wiele wystąpień aplikacji w oddzielnych regionach świadczenia usługi Azure lub obsługujesz wszystkich użytkowników globalnych z jednego regionu.
• Zapora aplikacji internetowej (WAF) w celu ochrony aplikacji, niezależnie od ścieżki ruchu w celu dotarcia do serwerów pochodzenia.

Buforowanie na brzegu sieci nie jest krytyczną częścią dostarczania aplikacji. Jeśli buforowanie jest ważne, zobacz Globalne dostarczanie zawartości o znaczeniu krytycznym , aby zapoznać się z alternatywnym podejściem.

Uwaga

Ten przypadek użycia jest częścią ogólnej strategii projektowania, która obejmuje alternatywne podejście, gdy usługa Azure Front Door jest niedostępna. Aby uzyskać informacje o kontekście i zagadnieniach, zobacz Globalne aplikacje internetowe o znaczeniu krytycznym.

Podejście

To rozwiązanie do równoważenia obciążenia opartego na systemie DNS używa wielu profilów usługi Azure Traffic Manager do monitorowania usługi Azure Front Door. W mało prawdopodobnym przypadku problemu z dostępnością usługa Traffic Manager przekierowuje ruch przez Application Gateway.

Rozwiązanie zawiera następujące składniki:

• Usługa Traffic Manager korzystająca z trybu routingu priorytetowego ma dwa punkty końcowe. Domyślnie usługa Traffic Manager wysyła żądania za pośrednictwem usługi Azure Front Door. Jeśli usługa Azure Front Door jest niedostępna, drugi profil usługi Traffic Manager określa, gdzie należy skierować żądanie. Drugi profil został opisany poniżej.

• Usługa Azure Front Door przetwarza i kieruje większość ruchu aplikacji. Usługa Azure Front Door kieruje ruch do odpowiedniego serwera aplikacji pochodzenia i udostępnia podstawową ścieżkę do aplikacji. Zapora aplikacji internetowej usługi Azure Front Door chroni aplikację przed typowymi zagrożeniami bezpieczeństwa. Jeśli usługa Azure Front Door jest niedostępna, ruch jest automatycznie przekierowywany przez ścieżkę pomocniczą.

• Usługa Traffic Manager korzystająca z trybu routingu wydajności ma punkt końcowy dla każdego wystąpienia Application Gateway. Usługa Traffic Manager wysyła żądania do wystąpienia Application Gateway o najlepszej wydajności z lokalizacji klienta.

• Application Gateway jest wdrażana w każdym regionie i wysyła ruch do serwerów źródłowych w tym regionie. zapora aplikacji internetowej Application Gateway chroni każdy ruch, który przepływa przez ścieżkę pomocniczą.

• Serwery aplikacji pochodzenia muszą być gotowe do akceptowania ruchu zarówno z usługi Azure Front Door, jak i Azure Application Gateway w dowolnym momencie.

Zagadnienia do rozważenia

W poniższych sekcjach opisano niektóre ważne zagadnienia dotyczące tego typu architektury. Należy również zapoznać się z globalnymi aplikacjami internetowymi o znaczeniu krytycznym , aby poznać inne ważne zagadnienia i kompromisy w przypadku korzystania z usługi Azure Front Door w rozwiązaniu o znaczeniu krytycznym.

Konfiguracja usługi Traffic Manager

To podejście używa zagnieżdżonych profilów usługi Traffic Manager do osiągnięcia zarówno opartego na priorytecie, jak i opartego na wydajności routingu razem dla alternatywnej ścieżki ruchu aplikacji. W prostym scenariuszu ze źródłem w jednym regionie może być potrzebny tylko jeden profil usługi Traffic Manager skonfigurowany do korzystania z routingu opartego na priorytetach.

Dystrybucja regionalna

Usługa Azure Front Door to usługa globalna, a Application Gateway jest usługą regionalną.

Punkty obecności usługi Azure Front Door są wdrażane globalnie, a połączenia TCP i TLS kończą się w najbliższym punkcie obecności klienta. To zachowanie poprawia wydajność aplikacji. Natomiast gdy klienci nawiązują połączenie z Application Gateway, ich połączenia TCP i TLS kończą się na Application Gateway, który odbiera żądanie, niezależnie od tego, skąd pochodzi ruch.

Połączenia od klientów

Jako globalna usługa wielodostępna usługa Azure Front Door zapewnia nieodłączną ochronę przed różnymi zagrożeniami. Usługa Azure Front Door akceptuje tylko prawidłowy ruch HTTP i HTTPS i nie akceptuje ruchu w innych protokołach. Firma Microsoft zarządza publicznymi adresami IP używanymi przez usługę Azure Front Door do obsługi połączeń przychodzących. Ze względu na te cechy usługa Azure Front Door może pomóc w ochronie źródła przed różnymi typami ataków, a źródła można skonfigurować do korzystania z łączności Private Link.

Natomiast Application Gateway to usługa dostępna z Internetu z dedykowanym publicznym adresem IP. Należy chronić serwery sieciowe i początkowe przed różnymi typami ataków. Aby uzyskać więcej informacji, zobacz Zabezpieczenia źródła.

Private Link połączenia z serwerami pochodzenia

Usługa Azure Front Door Premium zapewnia Private Link łączność ze źródłami, co zmniejsza publiczny obszar powierzchni dostępny z Internetu w rozwiązaniu.

Jeśli używasz Private Link do nawiązywania połączenia z źródłami, rozważ wdrożenie prywatnego punktu końcowego w sieci wirtualnej i skonfiguruj Application Gateway do używania prywatnego punktu końcowego jako zaplecza aplikacji.

Skalowanie

Podczas wdrażania Application Gateway wdrażasz dedykowane zasoby obliczeniowe dla rozwiązania. Jeśli nieoczekiwanie dotrze do Application Gateway duże ilości ruchu, możesz zaobserwować problemy z wydajnością lub niezawodnością.

Aby wyeliminować to ryzyko, rozważ skalowanie wystąpienia Application Gateway. Użyj skalowania automatycznego lub upewnij się, że skalowanie zostało ręcznie skalowane w celu obsługi ilości ruchu, który może zostać odebrany po przejściu w tryb failover.

Buforowanie

Jeśli używasz funkcji buforowania usługi Azure Front Door, ważne jest, aby pamiętać, że po przełączeniu ruchu do alternatywnej ścieżki i użyciu Application Gateway zawartość nie jest już obsługiwana z pamięci podręcznych usługi Azure Front Door.

Jeśli zależysz od buforowania dla rozwiązania, zobacz Globalne dostarczanie zawartości o znaczeniu krytycznym , aby zapoznać się z alternatywnym podejściem, które korzysta z usługi CDN partnera jako powrotu do usługi Azure Front Door.

Alternatywnie, jeśli używasz buforowania, ale nie jest to kluczowa część strategii dostarczania aplikacji, rozważ, czy możesz skalować w poziomie lub skalować źródła w górę, aby poradzić sobie ze zwiększonym obciążeniem spowodowanym przez większą liczbę nieodebranych pamięci podręcznych podczas pracy w trybie failover.

Kompromisy

Ten typ architektury jest najbardziej przydatny, jeśli chcesz, aby alternatywna ścieżka ruchu korzystała z funkcji, takich jak reguły przetwarzania żądań, zapora aplikacji internetowej i odciążanie protokołu TLS. Zarówno usługa Azure Front Door, jak i Application Gateway zapewniają podobne możliwości.

Istnieją jednak kompromisy:

• Złożoność operacyjna. Jeśli używasz dowolnej z tych funkcji, musisz skonfigurować je zarówno w usłudze Azure Front Door, jak i Application Gateway. Jeśli na przykład wprowadzisz zmianę konfiguracji w zaporze aplikacji internetowej usługi Azure Front Door, musisz również zastosować tę samą zmianę konfiguracji do zapory aplikacji internetowej Application Gateway. Złożoność operacyjna staje się znacznie wyższa, gdy trzeba ponownie skonfigurować i przetestować dwa oddzielne systemy.

• Parzystość funkcji. Chociaż istnieją podobieństwa między funkcjami oferowanymi przez usługę Azure Front Door i Application Gateway, wiele funkcji nie ma dokładnej parzystości. Należy pamiętać o tych różnicach, ponieważ mogą one mieć wpływ na sposób dostarczania aplikacji na podstawie ścieżki ruchu, którą śledzi.

  Application Gateway nie zapewnia buforowania. Aby uzyskać więcej informacji na temat tej różnicy, zobacz Buforowanie.

  Usługi Azure Front Door i Application Gateway są odrębnymi produktami i mają różne przypadki użycia. W szczególności te dwa produkty różnią się w sposobie wdrażania ich w regionach świadczenia usługi Azure. Upewnij się, że rozumiesz szczegóły poszczególnych produktów i sposób ich używania.

• Koszt. Zazwyczaj należy wdrożyć wystąpienie Application Gateway w każdym regionie, w którym masz źródło. Ponieważ każde wystąpienie Application Gateway jest rozliczane oddzielnie, koszt może stać się wysoki, gdy źródła są wdrażane w kilku regionach.

  Jeśli koszt jest istotnym czynnikiem dla rozwiązania, zobacz Globalne dostarczanie zawartości o znaczeniu krytycznym dla alternatywnej metody, która korzysta z partnerskiej sieci dostarczania zawartości (CDN) jako powrotu do usługi Azure Front Door. Niektóre sieci CDN rozliczają ruch w oparciu o zużycie, więc takie podejście może być bardziej opłacalne. Jednak niektóre inne zalety korzystania z Application Gateway dla rozwiązania mogą zostać utracone.

  Alternatywnie można rozważyć wdrożenie alternatywnej architektury, w której usługa Traffic Manager może kierować ruch bezpośrednio do usług aplikacji typu platforma jako usługa (PaaS), unikając konieczności Application Gateway i obniżania kosztów. Możesz rozważyć to podejście, jeśli używasz usługi, takiej jak Azure App Service lub Azure Container Apps dla swojego rozwiązania. Jeśli jednak zastosujesz to podejście, należy wziąć pod uwagę kilka ważnych kompromisów:

  • WAF: Usługi Azure Front Door i Application Gateway zapewniają możliwości zapory aplikacji internetowej. Jeśli uwidaczniasz usługi aplikacji bezpośrednio w Internecie, możesz nie być w stanie chronić aplikacji za pomocą zapory aplikacji internetowej.
  • Odciążanie protokołu TLS: Usługi Azure Front Door i Application Gateway obu zakończą połączenia TLS. Usługi aplikacji należy skonfigurować tak, aby przerywały połączenia TLS.
  • Routingu: Zarówno usługa Azure Front Door, jak i Application Gateway wykonywać routing między wieloma źródłami lub zapleczami, w tym routingiem opartym na ścieżkach, i obsługują złożone reguły routingu. Jeśli usługi aplikacji są uwidocznione bezpośrednio w Internecie, nie można wykonywać routingu ruchu.

Ostrzeżenie

Jeśli rozważasz uwidacznianie aplikacji bezpośrednio w Internecie, utwórz dokładny model zagrożeń i upewnij się, że architektura spełnia wymagania dotyczące zabezpieczeń, wydajności i odporności.

Jeśli używasz maszyn wirtualnych do hostowania rozwiązania, nie należy uwidaczniać maszyn wirtualnych w Internecie.

Następne kroki

Przejrzyj globalny scenariusz dostarczania zawartości , aby dowiedzieć się, czy dotyczy twojego rozwiązania.