Model Přepážka

Azure

Vzor Bulkhead je typ návrhu aplikace, který je odolný proti selhání. V architektuře přepěťování jsou prvky aplikace izolované do fondů, takže pokud selže, ostatní budou dál fungovat. Jmenuje se podle oddílů (přepážek) trupu lodi. Pokud dojde k poškození trupu lodi, naplní se vodou pouze poškozená část. Zabrání se tak potopení lodě.

Kontext a problém

Cloudová aplikace může obsahovat více služeb, přičemž každá služba může mít jednoho nebo více příjemců. Nadměrné zatížení nebo chyba služby ovlivní všechny příjemce služby.

Příjemce navíc může současně posílat požadavky různým službám a prostředky využívat pro každý požadavek. Pokud příjemce pošle požadavek službě, která je špatně nakonfigurovaná nebo neodpovídá, nemusí se prostředky používané požadavkem klienta uvolnit včas. Při přetrvávajících požadavcích na službu může dojít k vyčerpání těchto prostředků. Může třeba dojít k vyčerpání fondu připojení klienta. V tomto okamžiku jsou ovlivněny požadavky příjemce na jiné služby. Příjemce nakonec nebude moct posílat požadavky nejen původní nereagující službě, ale ani ostatním službám.

Stejný problém vyčerpání prostředků se týká služby s více příjemci. Velký počet požadavků pocházejících od jednoho klienta může vyčerpat dostupné prostředky ve službě. Ostatní příjemci už nebudou moct službu využívat, čímž dojde ke kaskádovému selhání.

Řešení

Rozdělte instance služby do různých skupin podle požadavků na zatížení příjemci a dostupnost. Tento návrh pomáhá izolovat chyby a umožňuje zachovat funkčnost služby pro některé příjemce i během selhání.

Příjemce může také rozdělit prostředky, aby zajistil, že prostředky používané k volání jedné služby nebudou mít vliv na prostředky používané k volání jiné služby. Příjemci, který volá více služeb, může být například pro každou službu přiřazen fond připojení. Pokud služba začne selhávat, bude to mít vliv pouze na fond připojení přiřazený dané službě a příjemce bude moct pokračovat v používání jiných služeb.

Mezi výhody tohoto modelu patří:

  • Izoluje uživatele a služby od kaskádových selhání. Problém ovlivňující uživatele nebo službu je možné izolovat v přepážce a zabránit tak selhání celého řešení.
  • V případě selhání služby umožňuje zachovat některé funkce. Ostatní služby a funkce aplikace budou dále fungovat.
  • Umožňuje nasadit služby, které nabízejí různou kvalitu služby pro přijímající aplikace. Fond příjemců s vysokou prioritou lze nakonfigurovat na používání služeb s vysokou prioritou.

Následující diagram znázorňuje přepážky strukturované kolem fondů připojení volajících jednotlivé služby. Pokud služba A selže nebo způsobí jiný problém, fond připojení se izoluje, aby byly zasaženy pouze úlohy používající fond vláken přiřazený službě A. Úlohy, které používají služby B a C, nejsou ovlivněny a mohou bez přerušení dále fungovat.

První diagram vzoru Bulkhead

Následující diagram znázorňuje více klientů volajících jednu službu. Každý klient je přiřazen samostatné instanci služby. Klient 1 poslal příliš mnoho požadavků a svou instanci zahltil. Vzhledem k tomu, že každá instance služby je izolovaná od ostatních, mohou další klienti pokračovat ve volání.

Diagram znázorňující více klientů, kteří volají jednu službu

Problémy a důležité informace

  • Definujte oddíly kolem provozních a technických požadavků aplikace.
  • Při rozdělování služeb a příjemců do přepážek zvažte úroveň izolace, kterou nabízí technologie, a také režii z hlediska nákladů, výkonu a možností správy.
  • Zvažte zkombinování přepážek s modely opakování, jističe a omezení využití sítě za účelem sofistikovanějšího zpracování chyb.
  • Při rozdělování příjemců do přepážek zvažte použití procesů, fondů vláken a semaforů. Projekty, jako je odolnost 4j a Polly , nabízejí architekturu pro vytváření přepážek uživatelů.
  • Při rozdělování služeb do přepážek zvažte jejich nasazení do samostatných virtuálních počítačů, kontejnerů nebo procesů. Kontejnery nabízejí dobrý poměr izolace prostředků a celkem nízkou režii.
  • Služby, které komunikují pomocí asynchronních zpráv, lze izolovat prostřednictvím různých sad front. Každá fronta může mít vyhrazenou sadu instancí zpracovávajících zprávy ve frontě nebo jednu skupinu instancí používající algoritmus pro odstranění z fronty nebo zpracování odeslání.
  • Určete úroveň podrobností pro přepážky. Pokud například chcete distribuovat tenanty mezi oddíly, můžete umístit každého tenanta do samostatného oddílu nebo vložit několik tenantů do jednoho oddílu.
  • Monitorujte výkon a smlouvu SLA jednotlivých oddílů.

Kdy se má tento model použít

Tento model použijte k:

  • Izolování prostředků používaných pro sadu back-endových služeb, zejména v případě, kdy aplikace zvládne poskytovat určitou úroveň funkčnosti i přesto, že některá ze služeb nereaguje.
  • Izolování kritických příjemců od standardních příjemců
  • Ochraně aplikace před kaskádovými selháními

Tento model nebude pravděpodobně vhodný v následujících případech:

  • Méně efektivní použití prostředků nemusí být v projektu přijatelné.
  • Přidaná složitost není nutná.

Návrh úloh

Architekt by měl vyhodnotit způsob použití modelu Bulkhead v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Pilíř Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu. Strategie izolace selhání zavedená prostřednictvím úmyslného a kompletního segmentace mezi komponentami se pokouší obsahovat chyby pouze pro přepážku, u které dochází k problému, což brání dopadu na jiné přepážky.

- RE:02 Kritické toky
- RE:07 Sebezáchování
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. Segmentace mezi komponentami pomáhá omezit incidenty zabezpečení na ohrožené přepážky.

- SE:04 Segmentace
Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. Každá přepěťová hlava může být individuálně škálovatelná tak, aby efektivně splňovala potřeby úkolu zapouzdřeného v přepážce.

- PE:02 Plánování kapacity
- PE:05 Škálování a dělení

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Následující konfigurační soubor Kubernetes vytvoří izolovaný kontejner pro spuštění jedné služby s vlastními prostředky procesoru a paměti a omezeními.

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

Další kroky