Datová platforma pro klíčové úlohy v Azure

V kritické architektuře musí být jakýkoli stav uložen mimo výpočetní prostředky co nejvíce. Volba technologie je založená na těchto klíčových vlastnostech architektury:

Charakteristiky Úvahy
Výkon Kolik výpočetních prostředků je potřeba?
Latence Jaký dopad bude mít vzdálenost mezi uživatelem a úložištěm dat latenci? Jaká je požadovaná úroveň konzistence s kompromisem při latenci?
Přizpůsobivost Vyžaduje se vždy dostupné úložiště dat?
Škálovatelnost Co je schéma dělení?
Stálost Očekává se, že data budou trvalá? Co jsou zásady uchovávání informací?
Odolnost V případě selhání je úložiště dat schopné převzít služby při selhání automaticky? Jaké míry se používají k omezení doby převzetí služeb při selhání?
Zabezpečení Jsou data šifrovaná? Je možné dosáhnout úložiště dat přes veřejnou síť?

Navrhněte svou kritickou úlohu s vhodnými úložišti dat. Zvažte použití dvou primárních typů:

  • Databáze

    Obchody související s pracovní zátěží. Doporučuje se, aby se všechny stavy ukládaly globálně do databáze, která je oddělená od regionálních razítek. Sestavte redundanci nasazením databáze napříč oblastmi. V případě důležitých úloh by synchronizace dat napříč oblastmi měla být primárním zájmem. V případě selhání by také měly být požadavky na zápis do databáze funkční.

    Replikace dat v konfiguraci aktivní-aktivní se důrazně doporučuje. Aplikace by se měla okamžitě připojit k jiné oblasti. Všechny instance by měly být schopné zpracovávat požadavky na čtení a zápis.

  • Zprostředkovatel zpráv

    Jediným stavovým servisem v regionálním razítku je zprostředkovatel zpráv, který ukládá požadavky na krátkou dobu. Zprostředkovatel obsluhuje potřebu ukládání do vyrovnávací paměti a spolehlivého zasílání zpráv. Zpracovávané požadavky se uchovávají v globální databázi.

Pro další aspekty dat se podívejte na kritické pokyny v rámci Well-architected Framework: Aspekty datové platformy.

Databáze

Zvažte použití služby Azure Cosmos DB for NoSQL pro klíčové úlohy. Tato možnost poskytuje základní funkce potřebné pro klíčové návrhy:

  • Víceoblastový zápis

    Zápis do více oblastí je povolený s replikami nasazenými do každé oblasti, ve které je nasazeno razítko. Každé razítko může zapisovat místně a Azure Cosmos DB zpracovává replikaci dat a synchronizaci mezi kolky. Tato funkce výrazně snižuje latenci geograficky distribuovaných koncových uživatelů aplikace. Klíčové úlohy obvykle využívají technologii, která poskytuje možnosti zápisu do více oblastí, aby byla zajištěna maximální odolnost a dostupnost.

    Redundance zón je také povolená v rámci každé replikované oblasti.

    Další informace o zápisech do více oblastí najdete v tématu Konfigurace zápisů do více oblastí v aplikacích, které používají službu Azure Cosmos DB.

  • Správa konfliktů

    Díky schopnosti provádět zápisy dat napříč několika regiony vzniká nutnost přijmout model správy konfliktů, protože souběžné zápisy mohou způsobovat konflikty mezi záznamy. Poslední zapisovač vítězí je výchozí model a používá se pro návrh kritických úkolů. Poslední zapisovač definovaný přidruženými časovými razítky záznamů vyhraje konflikt. Azure Cosmos DB for NoSQL také umožňuje definovat vlastní vlastnost.

  • Optimalizace dotazů

    Obecným doporučením pro efektivitu dotazů kontejnerů s velkým množstvím čtení a vysokým počtem oddílů je přidání rovnostního filtru s identifikovaným itemID. Podrobnou kontrolu doporučení pro optimalizaci dotazů najdete v tématu Řešení potíží s dotazy při použití služby Azure Cosmos DB.

  • Funkce zálohování

    Pro ochranu dat doporučujeme použít nativní funkci zálohování služby Azure Cosmos DB. Funkce zálohování služby Azure Cosmos DB podporuje online zálohování a obnovení dat na vyžádání.

Poznámka:

Většina úloh není čistě OLTP. Existuje rostoucí poptávka po reportování v reálném čase, jako je běh reportů proti provoznímu systému. Označuje se také jako HTAP (Hybridní transakční a analytické zpracování). Azure Cosmos DB tuto funkci podporuje prostřednictvím zrcadlení v prostředcích infrastruktury pro Cosmos DB.

Datový model pro úlohu

Datový model by měl být navržený tak, aby funkce nabízené tradičními relačními databázemi nemusely být povinné. Například cizí klíče, striktní schéma řádků a sloupců, zobrazení a další.

Úloha má tyto charakteristiky přístupu k datům:

  • Vzor pro čtení:
    • Čtení bodů – načtení jednoho záznamu ID položky a klíč oddílu se používají přímo pro maximální optimalizaci (1 RU na požadavek).
    • Čtení seznamu – Získání položek katalogu, které se mají zobrazit v seznamu FeedIterator s omezením počtu výsledků se používá.
  • Vzor zápisu:
    • Malé zápisy – Požadavky obvykle vkládají do transakce jeden nebo několik záznamů.
  • Navržena tak, aby zvládla vysoký provoz pro koncové uživatele a škálovat dle potřeby pro miliony uživatelů.
  • Malý datový náklad nebo velikost sady dat – obvykle v řádu kB.
  • Nízká doba odezvy (v pořadí milisekund).
  • Nízká latence (v pořadí milisekund).

Konfigurace

Služba Azure Cosmos DB je nakonfigurovaná takto:

  • Úroveň konzistence je nastavena na výchozí konzistenci relace, protože je to nejčastěji používaná úroveň pro aplikace v jedné oblasti a globálně distribuované aplikace. Slabší konzistence s vyšší propustností není nutná kvůli asynchronní povaze zpracování zápisu a nevyžaduje nízkou latenci při zápisu do databáze.

    Poznámka:

    Úroveň konzistence Session nabízí rozumný kompromis pro latenci, dostupnost a záruky konzistence pro zásadní aplikace. Je důležité si uvědomit, že úroveň silné konzistence není dostupná pro databáze zápisu s více hlavními databázemi.

  • Klíč oddílu je nastavený na /id pro všechny kolekce. Toto rozhodnutí vychází ze způsobu použití, který je většinou "psaní nových dokumentů s identifikátorem GUID" a "čtení široké škály dokumentů podle ID". Pokud kód aplikace udržuje jedinečnost ID, služba Azure Cosmos DB rovnoměrně distribuuje nová data do oddílů, což umožňuje neomezené škálování.

  • Zásady indexování se konfigurují u kolekcí pro optimalizaci dotazů. K optimalizaci nákladů na RU a výkonu se používá vlastní zásada indexování. Tato zásada indexuje pouze vlastnosti, které se používají v predikátech dotazů. Aplikace například nepoužívá textové pole komentáře jako filtr v dotazech. Byla vyloučena z vlastních zásad indexování.

    Následující příklad ukazuje doporučené nastavení zásad indexování pomocí Terraformu:

    indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Informace o připojení z aplikace ke službě Azure Cosmos DB pro důležité úlohy najdete v tématu Důležité informace o platformě aplikací pro klíčové úlohy.

služby zasílání zpráv

Klíčové systémy často využívají služby zasílání zpráv ke zpracování zpráv nebo událostí. Tyto služby podporují volné spojení a fungují jako tlumič, který chrání systém před neočekávanými špičkami poptávky.

  • Azure Service Bus se doporučuje pro úlohy založené na zprávách při zpracování zpráv s vysokou hodnotou.
  • Služba Azure Event Hubs se doporučuje pro systémy založené na událostech, které zpracovávají velké objemy událostí nebo telemetrie.

Následující části popisují aspekty návrhu a doporučení pro Azure Service Bus Premium a Azure Event Hubs v klíčové architektuře.

Řízení zatížení

Systém zasílání zpráv musí být schopný zpracovat požadovanou propustnost (stejně jako v MB za sekundu). Vezměte v úvahu následující faktory:

  • Požadavky na systém, které nejsou funkční, by měly určovat průměrnou velikost zprávy a maximální počet zpráv za sekundu, které musí každé razítko podporovat. Tyto informace lze použít k výpočtu požadovaného vrcholu MB/s na razítko.
  • Dopad převzetí služeb při selhání je potřeba zvážit při výpočtu požadované špičkové rychlosti MB/s na jednotku.
  • V případě služby Azure Service Bus by měly NFR určovat všechny pokročilé funkce služby Service Bus, jako jsou relace a zprávy o zrušení dušování. Tyto funkce ovlivní propustnost služby Service Bus.
  • Propustnost služby Service Bus s požadovanými funkcemi by se měla vypočítat prostřednictvím testování jako MB/s na jednotku zasílání zpráv (MU). Další informace o tomto tématu najdete v zasílání zpráv ve službě Service Bus v úrovních Premium a Standard.
  • Propustnost služby Azure Event Hubs by se měla vypočítat prostřednictvím testování jako MB/s na jednotku propustnosti (TU) pro úroveň Standard nebo jednotku zpracování (PU) pro úroveň Premium. Další informace o tomto tématu najdete v tématu Škálování pomocí služby Event Hubs.
  • Předchozí výpočty lze použít k ověření, že služba zasílání zpráv dokáže zpracovat požadované zatížení na razítko a požadovaný počet jednotek škálování potřebných ke splnění tohoto zatížení.
  • Oddíl operací se bude zabývat automatickým škálováním.

Každá zpráva musí být zpracována.

Úroveň Premium služby Azure Service Bus je doporučeným řešením pro zprávy s vysokou hodnotou, u kterých musí být zaručeno zpracování. Toto jsou podrobnosti týkající se tohoto požadavku při použití služby Azure Service Bus Premium:

  • Aby se zajistilo, že se zprávy správně přenesou do zprostředkovatele a přijmou je, musí producenti zpráv používat jednoho z podporovaných klientů rozhraní API služby Service Bus. Podporovaná rozhraní API se úspěšně vrátí z operace odeslání pouze tehdy, když je zpráva uložena ve frontě nebo v tématu.

  • Pokud chcete zajistit zpracování zpráv ve sběrnici, měli byste použít režim příjmu PeekLock. Tento režim umožňuje alespoň jedno zpracování. Následující kroky popisují proces:

    • Příjemce zprávy obdrží zprávu ke zpracování.
    • Spotřebiteli je poskytnut výhradní zámek na zprávu po stanovenou dobu.
    • Pokud příjemce zprávu úspěšně zpracuje, odešle potvrzení zpět do zprostředkovatele a zpráva se odebere z fronty.
    • Pokud zprostředkovatel potvrzení neobdrží v přiděleném časovém období nebo obslužná rutina zprávu explicitně opustí, uvolní se výhradní zámek. Tato zpráva je pak k dispozici pro ostatní uživatele, kteří zprávu zpracují.
    • Pokud zpráva není úspěšně zpracována určitý počet opakování, nebo obslužná rutina přepošle zprávu do fronty nedoručených zpráv .
      • Aby se zajistilo, že zprávy odeslané do fronty nedoručených zpráv budou fungovat, je třeba monitorovat frontu nedoručených zpráv a nastavit upozornění.
      • Systém by měl mít nástroje pro operátory, aby mohli kontrolovat, opravovat a znovu odsílat zprávy.

  • Vzhledem k tomu, že zprávy mohou být zpracovány vícekrát, by měli být zpracovatele zpráv idempotentní.

Zpracování idempotentních zpráv

V RFC 7231, Hypertext Transfer Protocol uvádí: "A ... metoda je považována za idempotentní , pokud zamýšlený účinek na server více identických požadavků s touto metodou je stejný jako účinek pro jeden takový požadavek."

Jednou z běžných metod zpracování zpráv idempotentní je zkontrolovat trvalé úložiště, jako je databáze, pokud už byla zpráva zpracována. Pokud byl již zpracován, znovu byste tu logiku nespustili.

  • Mohou nastat situace, kdy zpracování zprávy zahrnuje databázové operace, zvláště pak vložení nových záznamů s identifikátory generovanými databází. Zprostředkovateli mohou být generovány nové zprávy, které obsahují tyto identifikátory. Vzhledem k tomu, že neexistují distribuované transakce, které zahrnují databázi i zprostředkovatele zpráv, může dojít ke komplikacím v případě, že proces, který spouští kód, selže. Podívejte se na následující příklady:
    • Kód, který generuje zprávy, se může spustit před potvrzením databázové transakce, což je běžný způsob, jak mnoho vývojářů pracuje s použitím modelu jednotky práce. Tyto zprávy můžou uniknout, pokud dojde k selhání po volání zprostředkovatele a vyžádáním potvrzení databázové transakce. Vzhledem k tomu, že se transakce zruší, jsou tyto ID generované databází také zrušena, což znamená, že zůstávají dostupné pro jiný kód, který běží ve stejnou dobu. To může způsobit, že příjemci upravených zpráv zpracují nesprávné položky databáze, což naruší celkovou konzistenci a správnost systému.
    • Pokud vývojáři po dokončení databázové transakce vloží kód, který zprávu vygeneruje, může proces mezi těmito operacemi selhat (potvrzená transakce – zpráva odeslána). Když k tomu dojde, zpráva bude znovu zpracována, ale tentokrát klauzule ostrahy idempotence zjistí, že už byla zpracována (na základě dat uložených v databázi). Klauzule přeskočí kód k emisí zpráv, v domnění, že všechno bylo naposledy úspěšně provedeno. Podřízené systémy, které očekávaly, že budou dostávat oznámení o dokončených procesech, nic neobdrží. Tato situace opět vede k celkovému stavu nekonzistence.
  • Řešení dříve popsaných problémů zahrnuje použití vzoru Transakční odesílací schránky, kde jsou odchozí zprávy uloženy stranou ve stejném transakčním úložišti jako obchodní data. Zprávy se pak přenesou do zprostředkovatele zpráv, když byla počáteční zpráva úspěšně zpracována.
  • Vzhledem k tomu, že mnoho vývojářů nezná tyto problémy nebo jejich řešení, doporučujeme, abyste měli funkce outboxu a interakci se zprostředkovatelem zpráv zabalené v nějaké knihovně, aby se tyto techniky konzistentně uplatňovaly v systému důležitém pro misi. Veškeré zpracování kódu a odesílání transakčně významných zpráv by mělo používat tuto knihovnu, nikoli přímo interakci s prostředníkem zpráv.

Vysoká dostupnost a zotavení po havárii

Zprostředkovatel zpráv musí být k dispozici pro producenty, kteří mají odesílat zprávy a příjemce je přijímat. Pokud chcete zajistit vysokou dostupnost pro zprostředkovatele zpráv, proveďte následující kroky:

  • Pokud chcete zajistit nejvyšší dostupnost služby Service Bus, použijte úroveň Premium, která podporuje zóny dostupnosti v podpůrných oblastech. Se zónami dostupnosti se zprávy a metadata replikují napříč třemi různorodými datovými centry ve stejné oblasti.
  • K automatickému opakování neúspěšných čtení nebo zápisu použijte podporované sady SDK služby Service Bus nebo Event Hubs.
  • Zvažte replikaci aktivní-aktivní nebo replikaci aktivní-pasivní, abyste se izolovali před regionálními haváriemi.

Poznámka:

Geografické zotavení po havárii Služby Azure Service Bus replikuje pouze metadata napříč oblastmi. Tato funkce nereplikuje zprávy.

Sledování

Systém zasílání zpráv funguje jako vyrovnávací paměť mezi producenty zpráv a spotřebiteli. Cenné přehledy můžete získat monitorováním klíčových typů ukazatelů v klíčovém systému:

  • Omezování – Omezování značí, že systém nemá požadované prostředky ke zpracování požadavku. Service Bus i Event Hubs podporují monitorování omezených požadavků. Měli byste upozorňovat na tento indikátor.
  • Hloubka fronty – Hloubka fronty, která roste, může znamenat, že procesory zpráv nefungují nebo že není dostatek procesorů pro zpracování aktuálního zatížení. Hloubku fronty lze použít k nastavení automatického škálování obslužných rutin.
    • U služby Service Bus se hloubka fronty zobrazí jako počet zpráv.
    • U služby Event Hubs musí konzumenti vypočítat hloubku fronty na oddíl a odeslat tuto metriku do monitorovacího softwaru. Pro každé čtení příjemce získá pořadové číslo aktuální události a vlastnosti události posledního zařazení události. Příjemce může vypočítat posun.
  • Fronta nedoručených zpráv – Zprávy ve frontě nedoručených zpráv představují zprávy, které nelze zpracovat. Tyto zprávy obvykle vyžadují ruční zásah. Upozornění by měla být nastavena na frontě nedoručených zpráv.
    • Service Bus má frontu nedoručených zpráv a metriku DeadLetteredMessages.
    • Pro službu Event Hubs musí být tato funkce implementována jako vlastní logika na straně příjemce událostí.
  • Využití procesoru a paměti – procesor a paměť by se měly monitorovat, aby systém zasílání zpráv měl dostatek prostředků ke zpracování aktuálního zatížení. Service Bus Premium i Event Hubs úrovně Premium zpřístupňují využití procesoru a paměti.
    • Jednotky zasílání zpráv (MU) se používají ve službě Service Bus k izolaci prostředků, jako je procesor a paměť pro obor názvů. Procesor a paměť rostoucí nad prahovou hodnotu může znamenat, že není nakonfigurovaných dostatek jednotek MU, zatímco pokles pod další prahové hodnoty může znamenat, že je nakonfigurovaných příliš mnoho jednotek MU. Tyto indikátory je možné použít k automatickému škálování MU.
    • Služba Event Hubs úrovně Premium využívá jednotky zpracování (PU) k izolaci prostředků, zatímco úroveň Standard používá jednotky propustnosti (TU). Tyto úrovně nevyžadují interakci s procesorem nebo pamětí k automatickému rozšíření jednotek PU nebo TU.

Kontrola stavu

Stav systému zasílání zpráv se musí brát v úvahu v kontrolách stavu klíčové aplikace. Vezměte v úvahu následující faktory:

  • Systém zasílání zpráv funguje jako vyrovnávací paměť mezi producenty zpráv a spotřebiteli. Razítko lze zobrazit jako v pořádku, pokud producenti můžou úspěšně odesílat zprávy zprostředkovateli a pokud příjemci mohou úspěšně zpracovávat zprávy zprostředkovatele.
  • Kontrola stavu by měla zajistit, aby zprávy mohly být odeslány do systému zpráv.

Další kroky

Kritická mise: Nasazení a testování

  • Last updated on