Stosowanie wzorców WAF w rzeczywistych architekturach

Stosowanie wzorców WAF w rzeczywistych architekturach nie jest ćwiczeniem teoretycznym — wymaga oceny każdej decyzji projektowej względem pięciu filarów i podejmowania świadomych kompromisów. Typowym punktem wyjścia jest diagram architektury: należy prześledzić drogę żądania użytkownika przez każdy komponent i dla każdego etapu zadać pytania: co się stanie, jeśli ten komponent ulegnie awarii, jaki będzie to koszt i w jaki sposób komponent jest zabezpieczony.

Rozważmy tradycyjną monolityczną aplikację internetową: pojedynczą maszynę wirtualną, na której razem działają serwer internetowy i baza danych, dostępną za pośrednictwem publicznego adresu IP. W odniesieniu do filarów WAF uzyskuje ona słabe wyniki we wszystkich pięciu obszarach: brak nadmiarowości (niezawodność), baza danych na tym samym hoście co warstwa internetowa (bezpieczeństwo), zawsze włączona maszyna wirtualna niezależnie od natężenia ruchu (koszty), brak CI/CD (doskonałość operacyjna) oraz wyłącznie skalowanie pionowe (efektywność wydajnościowa).

Aby uwzględnić filar niezawodności, należy rozmieścić warstwę internetową na wielu maszynach wirtualnych w różnych strefach dostępności, zastosować replikację geograficzną bazy danych do regionu pomocniczego oraz umieścić przed nimi usługę Azure Load Balancer. Eliminuje to pojedynczy punkt awarii i pozwala aplikacji działać mimo awarii strefy lub regionu, bez ręcznej interwencji.

W przypadku filaru bezpieczeństwa należy umieścić warstwę internetową i bazę danych w różnych podsieciach oraz skonfigurować reguły NSG, które zezwalają wyłącznie warstwie internetowej na łączenie się z portem bazy danych. Należy przechowywać parametry połączenia z bazą danych w usłudze Azure Key Vault i używać tożsamości zarządzanej w aplikacji internetowej do pobierania ich w czasie działania — eliminuje to zakodowane na stałe dane uwierzytelniające z kodu aplikacji i plików konfiguracyjnych.

W ramach filaru optymalizacji kosztów należy zastąpić stale działające maszyny wirtualne usługą Virtual Machine Scale Set, która zmniejsza skalę poza godzinami szczytu. W przypadku bazy danych należy ocenić, czy zarządzana usługa PaaS, taka jak Azure SQL Database z odpowiednią warstwą DTU, będzie tańsza niż pełna maszyna wirtualna z SQL Server. Dla przewidywalnej przepustowości bazowej, którą można oszacować z 12-miesięcznym wyprzedzeniem, należy kupić Reserved Instances.

Doskonałość operacyjną można poprawić, definiując całą infrastrukturę za pomocą szablonów Bicep lub ARM przechowywanych w systemie kontroli wersji. Należy utworzyć potok CI/CD w Azure Pipelines lub GitHub Actions, który automatycznie wdraża zmiany infrastruktury i kod aplikacji. Przed udostępnieniem zmian w środowisku produkcyjnym należy dodać bramki wdrożeniowe — automatyczne testy dymne i ręczne zatwierdzenie.

W ramach filaru efektywności wydajnościowej należy wprowadzić usługę Azure Cache for Redis przed bazą danych, aby buforować często odczytywane zapytania i zmniejszyć obciążenie bazy danych. Zasoby statyczne (obrazy, CSS, JavaScript) należy dostarczać za pośrednictwem usługi Azure CDN, aby były serwowane z węzłów brzegowych znajdujących się blisko użytkowników na całym świecie. Po każdej zmianie należy przeprowadzić test obciążeniowy aplikacji, aby potwierdzić mierzalność ulepszeń.

Każda zmiana architektoniczna wiąże się z kompromisem. Na przykład przejście na architekturę obejmującą wiele stref poprawia niezawodność, ale zwiększa koszty (dwie strefy = dwie maszyny wirtualne). Dodanie buforowania Redis poprawia wydajność, ale zwiększa złożoność operacyjną (dochodzi kolejna usługa, którą należy monitorować i utrzymywać). Dobra dokumentacja architektury jasno opisuje te kompromisy, aby przyszli architekci rozumieli, dlaczego podjęto dane decyzje.

Należy unikać prób osiągnięcia doskonałości podczas jednego przeprojektowania — takie podejście jest kosztowne, ryzykowne i powolne. Zamiast tego należy przyjąć cykl iteracyjnego doskonalenia: przeprowadzić przegląd Well-Architected, zidentyfikować trzy problemy o największym wpływie, rozwiązać je, zmierzyć poprawę i powtórzyć cały proces. Takie podejście łączy ulepszenia architektury ze zwinnym dostarczaniem i sprawia, że postępy są widoczne dla interesariuszy podczas każdego sprintu.

Firma Microsoft publikuje architektury referencyjne dla typowych wzorców obciążeń w Azure Architecture Center. Obejmują one architektury aplikacji internetowych, mikrousługi w usłudze AKS, potoki analityki danych i wiele innych rozwiązań. Każda architektura referencyjna została już oceniona pod kątem filarów WAF i zawiera informacje o kompromisach przyjętych dla danego wzorca.

Do dokumentowania istotnych wyborów architektonicznych, kontekstu, w którym ich dokonano, rozważanych alternatyw oraz konsekwencji dla filarów WAF należy używać Architecture Decision Records (ADR). Umieszczenie dokumentów ADR w systemie kontroli wersji obok bazy kodu tworzy możliwą do prześledzenia historię, która pomaga nowym członkom zespołu zrozumieć, dlaczego architektura wygląda właśnie tak.

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznano następujące zagadnienia: wzorce WAF stosuje się, oceniając każdą decyzję architektoniczną w odniesieniu do wszystkich pięciu filarów; ulepszenia można wprowadzać iteracyjnie, zaczynając od problemów o największym wpływie; a kompromisy należy dokumentować, aby przyszli architekci rozumieli przesłanki podjętych decyzji. Następnie omówimy umowy SLA platformy Azure oraz sposób obliczania złożonych umów SLA dla architektur obejmujących wiele usług.