Przygotowywanie
Dodasz własne ulepszenia do istniejącej architektury, która spełnia wymagania organizacji dotyczące wysokiej niezawodności. W tym miejscu omówimy kontekst tła, który należy wykonać z ćwiczeniami.
Kontekst problemu
Firma Contoso Shoes musi być gotowa na kolejne głośne uruchomienie produktu, co powinno spowodować znaczny wzrost ruchu. W ciągu ostatnich dwóch lat doszło do kilku zdarzeń powodujących, że witryna internetowa będzie w trybie offline przez pół dnia. System nie został całkowicie przetestowany w środowisku deweloperskim/testowym, a niektóre usterki wkradły się do środowiska produkcyjnego. Rozwiązywanie problemów i korygowanie trwało długo, ponieważ operatorzy nie byli w stanie szybko zidentyfikować głównych przyczyn.
Wystąpiły pewne wyzwania, gdy niektóre składniki nie są dostępne. Operacje skalowania w poziomie w obliczeniach miały wpływ na błędną konfigurację usługi Azure Key Vault. Ponadto nie ma żadnych strategii w przypadku awarii regionalnych. W niedawnym incydencie cały region Europy Zachodniej spadł. Ponieważ obciążenie działało tylko w tym regionie, firma musiała ponosić straty finansowe do momentu utworzenia kopii zapasowej regionu.
Bieżąca architektura
Aby ukończyć to wyzwanie, musisz dobrze zrozumieć bieżącą architekturę firmy Contoso Shoes. Skoncentrujmy się na warstwie interfejsu API.
Składniki
Wszystkie składniki tej architektury są wdrażane w jednym regionie.
plan usługi aplikacja systemu Azure Jednostka SKU S2 w warstwie Standardowa udostępnia platformę obliczeniową, która hostuje aplikację. Skalowanie automatyczne jest włączone. Środowisko programistyczne używa jednostki SKU Podstawowa B1.
aplikacja systemu Azure Service udostępnia platformę aplikacji, która uruchamia kod interfejsu API w kontenerze. Funkcja uwierzytelniania usługi App Service jest włączona na potrzeby autoryzacji.
Miejsca wdrożenia umożliwiają przygotowanie wdrożenia, a następnie zamianę go na wdrożenie produkcyjne. Są one używane tylko w środowisku produkcyjnym.
Usługa Azure Container Registry przechowuje konteneryzowany kod interfejsu API i jest wypychana przez potoki ciągłej integracji/ciągłego dostarczania (CI/CD), którymi zespół obciążenia tworzy i zarządza. Zarówno środowisko produkcyjne, jak i środowisko deweloperskie/testowe używają rejestru kontenerów.
Usługa Azure Cosmos DB z interfejsem API SQL przechowuje wszystkie stany związane z obciążeniem. Konto bazy danych usługi Cosmos DB ma jedną bazę danych zawierającą kilka kontenerów w modelu udostępnionej przepływności. Konto usługi Azure Cosmos używa trybu pojemności bezserwerowej. Istnieje jedno wystąpienie środowiska produkcyjnego i jedno dla tworzenia i testowania.
Usługa Azure Key Vault przechowuje wpisy tajne wymagane do interfejsu API w celu wykonania wywołania HTTP POST do zewnętrznego interfejsu API innej firmy w ramach jednego przepływu żądań. Aplikacja uzyskuje dostęp do wpisów tajnych za pośrednictwem odwołania usługi Key Vault w konfiguracji aplikacji usługi aplikacja systemu Azure Service. Istnieje jedna usługa Key Vault dla środowiska produkcyjnego i jedna do tworzenia i testowania.
Usługa Azure Log Analytics jest używana jako ujednolicony ujście do przechowywania dzienników i metryk dla wszystkich ustawień Diagnostyka Azure dla wszystkich składników używanych w rozwiązaniu. Istnieje jeden obszar roboczy dla środowiska produkcyjnego i jeden dla tworzenia i testowania.
aplikacja systemu Azure Insights służy do przechwytywania danych telemetrycznych i dzienników z interfejsu API. Usługa Application Insights używa trybu samodzielnego, a nie zapisu w dedykowanym obszarze roboczym usługi Log Analytics. Środowisko produkcyjne i tworzenie/testowanie nie współużytkują wspólnego wystąpienia.
Usługa Azure Pipelines jest używana do ciągłej integracji/ciągłego wdrażania, która kompiluje, testuje i wdraża obciążenie w środowiskach przedprodukcyjnych i produkcyjnych. Zespół ds. obciążeń zarządza potokami, które również zarządzają całą infrastrukturą w swoim rozwiązaniu. Bicep to wybór technologii infrastruktury jako kodu (IaC).
Wybór elementów projektu
Na liście składników sygnatura wdrożenia składa się z usług, które uczestniczą w przetwarzaniu żądania. Usługi te obejmują usługi App Services oraz kod interfejsu API i usługę Cosmos DB. Sygnatura zawiera również składniki niefunkcjonalne: Key Vault i Container Registry. Aplikacja ma zależność innej firmy od struktury wydajności i odporności. Tożsamości zarządzane przez system są używane między składnikami sygnatury.
W sygnaturze usługa App Services jest skonfigurowana do automatycznego skalowania na podstawie obciążenia.
Oddzielne środowiska są używane do produkcji i tworzenia/testowania. Środowisko produkcyjne używa standardowej jednostki SKU planu usługi App Service. Firma dokonała tego wyboru, aby umożliwić wstępne wdrożenie aplikacji w miejscu przed wdrożeniem jej w środowisku produkcyjnym. Środowisko tworzenia i testowania używa jednostki SKU w warstwie Podstawowa do optymalizacji kosztów. Oba środowiska mają własne wystąpienia usług. Środowiska współużytkuje tylko rejestr kontenerów.
Kod konteneryzowanego interfejsu API jest dostarczany w jednym obrazie kontenera, który działa w usłudze App Service. Interfejs API ma wiele punktów końcowych HTTP, których używają różne frontony do odczytu i zapisu. Frontony są poza zakresem tego modułu, ale są one w zakresie w dużym obrazie stanu tej sytuacji o znaczeniu krytycznym. Kod został instrumentowany za pomocą usługi Application Insights w celu przechwycenia niektórych podstawowych danych telemetrycznych. Zespół, który opracował ten kod, zarządza również potokiem ciągłej integracji/ciągłego wdrażania dla obrazu kontenera interfejsu API i potokami ciągłej integracji/ciągłego wdrażania.
Kompromisy
Jednak podobnie jak w przypadku wszystkich, istnieją kompromisy z bieżącą architekturą. Wymagania biznesowe mają priorytet optymalizacji kosztów w zakresie niezawodności i operacji. Aby zachować limity kosztów, architektura nie ewoluowała. Składniki nie są dostępne w przypadku korzystania z możliwości niezawodności oferowanych przez platformę. Na przykład wybór jednostki SKU dla obliczeń uniemożliwia użycie Strefy dostępności obciążenia. W przypadku danych telemetrycznych używana jest starsza wersja usługi Application Insights, która nie jest zintegrowana z usługą Log Analytics.
Ponadto dostęp do obciążenia jest nadmiernie wszechobecny. Na przykład bez integracji z siecią wirtualną wszystkie usługi platformy Azure można uzyskać bezpośrednio za pośrednictwem publicznego Internetu.
Po utworzeniu rozwiązania zespół programistyczny ds. aplikacji użył pojedynczej subskrypcji platformy Azure, colocating dev/test i production w tej samej subskrypcji, aby ułatwić tworzenie narzędzi zespołom DevOps. Jednak zasoby produkcyjne i zasoby deweloperskie/testowe nie są całkowicie odizolowane. Niektóre zasoby są współużytkowane między dwoma środowiskami, choć zostały one wyizolowane z pozostałych rozwiązań firmy Contoso Shoes.
Ponadto środowisko deweloperskie/testowe to jedno środowisko, które jest współużytkowane przez wszystkich członków zespołu deweloperskiego i qa. Wybór był uzasadniony, biorąc pod uwagę wielkość zespołów i koordynację między nimi nie potrzebował wyższego stopnia izolacji. W miarę rozwoju zespołu i rozwiązania pojedyncze środowisko deweloperskie/testowe coraz częściej powodowało złożoność integracji, ponieważ cykle życia strumienia pracy zderzyły się. Współczynnik zmian i jego wpływ na niezawodność były kosztowne.
Specyfikacja projektu
Firma chce dodać możliwości do swojej architektury rozwiązań, aby umożliwić jej obsługę oczekiwanego wzrostu obciążenia. Oto wymagania biznesowe:
- Tworzenie możliwości wytrzymania awarii regionalnych przez rozszerzenie architektury na wiele regionów
- Ulepszanie środowiska klienta dzięki szybszej obsłudze klientów w regionie geograficznie bliżej nich
- Dostosowanie do planu działania platformy Azure i korzystanie z najnowszych funkcji niezawodności oferowanych przez usługi platformy Azure
- Wczesne wykrywanie problemów kaskadowych w systemie przez utworzenie ogólnego modelu kondycji
Te wymagania to tylko priorytetowa lista planów poprawy. Zespół ds. aplikacji zdaje sobie sprawę, że wszystkie obszary projektowe muszą być brane pod uwagę, aby zapewnić niezawodność tego rozwiązania do standardów o krytycznym znaczeniu. Zapewnijmy, że nie przestaną ulepszać swojego rozwiązania i operacji po tym, jak pomogliśmy im w aspektach omówionych w nadchodzących ćwiczeniach.
Witamy w zespole! Firma Contoso Shoes z niecierpliwością oczekuje na wysłuchanie zaleceń.
Ustawienia
W tym projekcie wyzwania zajmiesz się rolą architekta, który pomoże firmie Contoso Shoes osiągnąć wyniki dotyczące niezawodności, począwszy od priorytetowych elementów w poprzedniej sekcji.
- Zalecamy użycie narzędzia do tworzenia diagramów architektury w celu wizualizacji architektury.
- Nie potrzebujesz subskrypcji platformy Azure, jeśli masz doświadczenie z usługami i ich funkcjami.