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

  • Článek

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 Důležité informace
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 trvat dlouho? 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íť?

V této architektuře existují dvě úložiště dat:

  • Databáze

    Ukládá se v souvislosti s úlohou. Doporučuje se, aby se všechny stavy ukládaly globálně do databáze 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.

Další aspekty dat najdete v tématu Důležité pokyny pro Misson v dobře architektuře: Aspekty datové platformy.

Databáze

Tato architektura používá Službu Azure Cosmos DB for NoSQL. Tato možnost je zvolená, protože poskytuje nejvíce funkcí potřebných v tomto návrhu:

  • Zápis do více oblastí

    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. Referenční implementace Azure Mission-Critical využívá multi-master technologii k zajištění maximální odolnosti a dostupnosti.

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

    Podrobnosti 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 možnosti provádět zápisy napříč několika oblastmi je nutnost přijmout model správy konfliktů, protože souběžné zápisy můžou zavádět konflikty záznamů. Poslední zapisovač wins je výchozí model a používá se pro návrh Mission Critical. 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 efektivity dotazů pro kontejnery náročné na čtení s vysokým počtem oddílů je přidání filtru rovnosti s identifikovaným ID položky. Podrobná kontrola doporučení pro optimalizaci dotazů najdete v tématu Řešení potíží s dotazy při používání 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 generování sestav v reálném čase, jako je spouštění sestav proti operační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 Azure Synapse Linku pro Azure 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 limitem počtu výsledků.
  • Vzor zápisu:
    • Malé zápisy – Požadavky obvykle vkládají do transakce jeden nebo malý počet záznamů.
  • Navržená tak, aby zvládla vysoký provoz od koncových uživatelů s možností škálovat tak, aby zvládla poptávku po provozu v pořadí od milionů uživatelů.
  • Malá datová část nebo velikost datové sady – obvykle v pořadí podle 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 nastavená na výchozí konzistenci relace, protože se jedná o nejčastěji používanou úroveň pro jednu oblast 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 relace nabízí rozumný kompromis pro latenci, dostupnost a záruky konzistence pro tuto konkrétní aplikaci. 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 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". Poskytnutí kódu aplikace udržuje jedinečnost ID, nová data se rovnoměrně distribuují do oddílů službou Azure Cosmos DB a umožňují nekonečné š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í.

Tady je příklad z implementace, která zobrazuje 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 v této architektuře najdete v tématu Aspekty aplikační platformy 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é párování a fungují jako vyrovnávací paměť, 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.

Tady jsou aspekty návrhu a doporučení pro Azure Service Bus Úrovně Premium a Azure Event Hubs v klíčové architektuře.

Zpracování 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í skutečnosti:

  • 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é špičky MB/s na kolek.
  • Dopad převzetí služeb při selhání je potřeba zvážit při výpočtu požadovaného počtu MB/s za kolek.
  • 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 tématu Úrovně zasílání zpráv service Bus úrovně 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.
  • Výše uvedené 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í. Tady 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 z operace odeslání úspěšně vrátí pouze v případě, že zpráva byla zachována ve frontě nebo 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í informace popisují proces:

    • Příjemce zprávy obdrží zprávu ke zpracování.
    • Příjemci se zobrazí výhradní zámek zprávy po danou dobu trvání.
    • 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 úspěšně nezpracovala konfigurovatelný počet, nebo obslužná rutina zprávu přepošla 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 je možné zpracovat vícekrát, měly by být obslužné rutiny zpráv vytvořené 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 zpracován, logiku byste znovu nezpracovali.

  • V situacích, kdy zpracování zprávy zahrnuje databázové operace, konkrétně vložení nových záznamů s identifikátory vygenerovaný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 k řadě komplikací, ke kterým může dojít v případě, že proces spuštění kódu selže. Podívejte se na následující příklady situací:
    • Kód, který generuje zprávy, se může spustit před potvrzením databázové transakce, což je počet vývojářů, kteří pracují pomocí modelu jednotek práce. Tyto zprávy můžou utéct, pokud dojde k selhání mezi voláním zprostředkovatele a dotazem, zda je databáze transakce potvrzena. Vzhledem k tomu, že transakce se vrátí zpět, tyto ID generované databází jsou také vráceny zpět, což je ponechá dostupné pro jiný kód, který může běžet ve stejnou dobu. To může způsobit, že příjemci řídicích zpráv zpracují nesprávné položky databáze, což zneškodní 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ávat, ale tentokrát klauzule idempotence guard uvidí, že už byla zpracována (na základě dat uložených v databázi). Klauzule přeskočí zprávu vygenerující kód a věří, že všechno bylo úspěšně provedeno naposledy. 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í výše uvedených problémů zahrnuje použití vzorce Transakční pošta k odeslání, kde jsou odchozí zprávy uloženy na straně 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í, abychom zajistili, že se tyto techniky používají konzistentně v kritickém systému, doporučujeme mít funkce složky Pošta k odeslání a interakci s zprostředkovatelem zpráv zabaleným v nějaké knihovně. Veškeré zpracování kódu a odesílání zpráv s transakčním významem by mělo tuto knihovnu využívat, a ne přímo komunikovat s zprostředkovatelem 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. Toto jsou podrobnosti týkající se tohoto požadavku:

  • 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 vzory replikace typu aktivní-pasivní, abyste izolovat 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. V klíčovém systému byste měli monitorovat klíčové typy ukazatelů, které poskytují cenné přehledy popsané níže:

  • 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 informování logiky automatického škálování obslužných rutin.
    • U služby Service Bus se hloubka fronty zobrazí jako počet zpráv.
    • V případě služby Event Hubs musí příjemci vypočítat hloubku fronty na oddíl a odeslat 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 ve 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 vlastní logika integrovaná do příjemce.
  • 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í jednotek 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 nafouknutí jednotek PU nebo JEDNOTek.

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

Nasaďte referenční implementaci, abyste získali úplný přehled o prostředcích a jejich konfiguraci používaných v této architektuře.

Implementace: Klíčové online