Obciążenia o znaczeniu krytycznym

Ta sekcja stara się sprostać wyzwaniom związanym z projektowaniem obciążeń o krytycznym znaczeniu na platformie Azure. Wskazówki są oparte na lekcjach pochodzących z przeglądania wielu aplikacji klientów i rozwiązań innych firm. Ta sekcja zawiera wskazówki umożliwiające podejmowanie działań i autorytatywne, które stosują Well-Architected najlepsze rozwiązania jako podstawy techniczne do tworzenia i obsługi wysoce niezawodnego rozwiązania na platformie Azure na dużą skalę.

Co to jest obciążenie o znaczeniu krytycznym?

Termin obciążenie odnosi się do kolekcji zasobów aplikacji, które obsługują wspólny cel biznesowy lub wykonywanie wspólnego procesu biznesowego, z wieloma usługami, takimi jak interfejsy API i magazyny danych, współpracują ze sobą w celu zapewnienia konkretnej funkcji kompleksowej.

Termin mission-critical odnosi się do skali krytycznej, która obejmuje znaczne koszty finansowe (krytyczne dla działania firmy) lub koszty ludzkie (krytyczne dla bezpieczeństwa) związane z niedostępnością lub niedostateczną wydajnością.

W związku z tym obciążenie o znaczeniu krytycznym opisuje kolekcję zasobów aplikacji, które muszą być wysoce niezawodne na platformie. Obciążenie musi być zawsze dostępne, odporne na awarie i działanie.

Wideo: Obciążenia o znaczeniu krytycznym na platformie Azure

Jakie są typowe wyzwania?

Platforma Microsoft Azure ułatwia wdrażanie rozwiązań w chmurze i zarządzanie nimi. Jednak tworzenie obciążeń o znaczeniu krytycznym, które są wysoce niezawodne na platformie, pozostaje wyzwaniem z następujących głównych powodów:

• Projektowanie niezawodnej aplikacji na dużą skalę jest złożone. Wymaga obszernej wiedzy na temat platformy, aby wybrać odpowiednie technologie i optymalnie skonfigurować je w celu zapewnienia kompleksowej funkcjonalności.

• Awaria jest nieunikniona w każdym złożonym systemie rozproszonym, dlatego rozwiązanie musi być zaprojektowane w celu obsługi awarii ze skorelowanym lub kaskadowym wpływem. Jest to zmiana sposobu myślenia dla wielu deweloperów i architektów wprowadzających chmurę ze środowiska lokalnego; inżynieria niezawodności nie jest już przedmiotem infrastruktury, ale powinna być problemem pierwszej klasy w procesie tworzenia aplikacji.

• Operacjonalizacja obciążeń o krytycznym znaczeniu wymaga wysokiego stopnia dyscypliny inżynieryjnej i dojrzałości w całym cyklu życia inżynieryjnego, a także możliwości uczenia się od awarii.

Czy misja ma krytyczne znaczenie tylko w przypadku niezawodności?

Chociaż głównym celem obciążeń o znaczeniu krytycznym jest niezawodność, inne filary platformy Well-Architected Framework są równie ważne podczas tworzenia i obsługi obciążenia o krytycznym znaczeniu na platformie Azure.

• Zabezpieczenia: w jaki sposób obciążenie ogranicza zagrożenia bezpieczeństwa, takie jak ataki DDoS (Distributed Denial of Service), będą miały znaczący wpływ na ogólną niezawodność.

• Doskonałość operacyjna: sposób, w jaki obciążenie może skutecznie reagować na problemy operacyjne, będzie miało bezpośredni wpływ na dostępność aplikacji.

• Wydajność: dostępność jest większa niż prosty czas pracy, ale raczej spójny poziom usługi aplikacji i wydajności względem znanego stanu dobrej kondycji.

Osiągnięcie wysokiej niezawodności nakłada znaczne kompromisy kosztowe, które mogą nie być uzasadnione dla każdego scenariusza obciążenia. Dlatego zaleca się, aby decyzje projektowe opierać się na wymaganiach biznesowych.

Jakie są kluczowe obszary projektowania?

Wskazówki krytyczne dla misji w tej serii składają się z zagadnień dotyczących architektury i zaleceń zorientowanych na te kluczowe obszary projektowe.

Obszary projektowe są powiązane, a decyzje podejmowane w jednym obszarze mogą mieć wpływ na decyzje w całym projekcie lub wpływać na nie. Zalecamy, aby czytelnicy zapoznali się z tymi obszarami projektowymi, zapoznając się z podanymi zagadnieniami i zaleceniami, aby lepiej zrozumieć konsekwencje obejmujących decyzje. Aby na przykład zdefiniować architekturę docelową, kluczowe jest określenie, jak najlepiej monitorować kondycję aplikacji w kluczowych składnikach. W tym przypadku czytelnik powinien przejrzeć obszar projektowania modelowania kondycji , korzystając z opisanych zaleceń, aby pomóc w podejmowaniu decyzji.

Obszar projektowania	Podsumowanie
Projekt aplikacji	Użycie architektury jednostki skalowania w kontekście tworzenia wysoce niezawodnej aplikacji. Poznaj również wzorce projektowe aplikacji w chmurze, które umożliwiają skalowanie i obsługę błędów.
Platforma aplikacji	Czynniki decyzyjne i zalecenia związane z wyborem, projektowaniem i konfiguracją odpowiedniej platformy hostingu aplikacji, zależności aplikacji, struktur i bibliotek.
Platforma danych	Wybory w technologiach magazynu danych, poinformowane przez ocenę wymaganej ilości, szybkości, różnorodności, prawdziwości.
Sieć i łączność	Pojęcia topologii sieci na poziomie aplikacji, biorąc pod uwagę wymaganą łączność i nadmiarowe zarządzanie ruchem. Krytyczne zalecenia mające na celu informowanie o projektowaniu bezpiecznej i skalowalnej globalnej topologii sieci.
Modelowanie i obserwowanie kondycji	Procesy definiowania niezawodnego modelu kondycji, mapowania kwantyfikowanych stanów kondycji aplikacji za pomocą możliwości obserwowania i konstrukcji operacyjnych w celu osiągnięcia dojrzałości operacyjnej.
Wdrażanie i testowanie	Eliminowanie przestojów i utrzymywanie kondycji aplikacji na potrzeby operacji wdrażania, zapewniając kluczowe zagadnienia i zalecenia mające na celu informowanie o projektowaniu optymalnych potoków ciągłej integracji/ciągłego wdrażania dla aplikacji o krytycznym znaczeniu.
Zabezpieczenia	Ochrona aplikacji przed zagrożeniami, które mają być bezpośrednio lub pośrednio zagrożone jego niezawodnością.
Procedury operacyjne	Wdrożenie metodyki DevOps i powiązanych metod wdrażania służy do prowadzenia skutecznych i spójnych procedur operacyjnych.

Przykłady ilustracyjne

Wskazówki przedstawione w tej serii są oparte na podejściu zorientowanym na rozwiązania, aby zilustrować kluczowe zagadnienia i zalecenia dotyczące projektowania. Dostępnych jest kilka implementacji referencyjnych, które mogą być używane jako podstawa do dalszego opracowywania rozwiązań.

• Architektura bazowa aplikacji dostępnej z Internetu — stanowi podstawę do tworzenia natywnej dla chmury, wysoce skalowalnej, dostępnej z Internetu aplikacji na platformie Microsoft Azure. Dostęp do obciążenia jest uzyskiwany za pośrednictwem publicznego punktu końcowego i nie wymaga łączności z siecią prywatną z otaczającym środowiskiem technicznym organizacji.

  Zapoznaj się z implementacją: Mission-Critical Online

• Architektura bazowa aplikacji dostępnej z Internetu z kontrolkami sieci — rozszerza architekturę punktu odniesienia z rygorystycznymi mechanizmami kontroli sieci, aby zapobiec nieautoryzowanemu dostępowi publicznemu z Internetu do dowolnego zasobu obciążenia.

• Architektura linii bazowej w strefie docelowej platformy Azure — stanowi podstawę do tworzenia aplikacji natywnej dla chmury połączonej z firmą na platformie Microsoft Azure przy użyciu istniejącej infrastruktury sieciowej i prywatnych punktów końcowych. Obciążenie wymaga prywatnej łączności z innymi zasobami organizacji i pobiera zależność od wstępnie udostępnianych sieci wirtualnych w celu łączności z innymi zasobami organizacyjnymi. Ten przypadek użycia jest przeznaczony dla scenariuszy wymagających integracji z szerszą infrastrukturą techniczną organizacji dla obciążeń publicznych lub wewnętrznych.

  Zapoznaj się z implementacją: Połączono o krytycznym znaczeniu

Scenariusze branżowe

Wskazówki o znaczeniu krytycznym w tej serii tworzą niezależną od branży metodologię projektowania, która może być stosowana w wielu różnych kontekstach branżowych. Poniższa lista zawiera konkretne przykłady, w których zastosowano metodologię projektowania o znaczeniu krytycznym i dostosowaną do konkretnego scenariusza branżowego.

• Klasa przewoźnika w branży telekomunikacyjnej

Obciążenie klasy przewoźnika jest przestawne zarówno na aspektach krytycznych dla działania firmy, jak i krytycznych pod względem bezpieczeństwa, w których istnieje fundamentalne wymaganie działania z zaledwie minutami, a nawet sekundami przestojów w roku kalendarzowym. Brak osiągnięcia tego wymogu w zakresie czasu pracy może spowodować znaczną utratę życia, ponieść znaczne grzywny lub kary umowne.

Następny krok

Zacznij od przejrzenia metodologii projektowania scenariuszy aplikacji o znaczeniu krytycznym.

Metodologia projektowania