Adatplatform kritikus fontosságú számítási feladatokhoz az Azure-ban

A kritikus fontosságú architektúrákban minden állapotot a lehető legnagyobb mértékben a számításon kívül kell tárolni. A technológia kiválasztása az alábbi fő architekturális jellemzőken alapul:

Jellemzők	Considerations
Teljesítmény	Mennyi számításra van szükség?
Latency	Milyen hatással lesz a felhasználó és az adattár közötti távolság a késésre? Mi a kívánt konzisztenciaszint a késéssel való kompromisszummal?
Válaszidő	Az adattárnak mindig rendelkezésre kell állnia?
Méretezhetőség	Mi a particionálási séma?
Tartósság	Az adatok várhatóan tartósak lesznek? Mi az adatmegőrzési szabályzat?
Resiliency	Hiba esetén az adattár képes automatikusan feladatátvételre? Milyen intézkedések vannak érvényben a feladatátvételi idő csökkentésére?
Biztonság	Titkosítva van az adat? El lehet érni az adattárat nyilvános hálózaton keresztül?

Ebben az architektúrában két adattár található:

• Adatbázis

  A számítási feladathoz kapcsolódó tárolók. Javasoljuk, hogy minden állapotot globálisan tároljon egy, a regionális bélyegektől elkülönített adatbázisban. Redundancia kiépítése az adatbázis régiók közötti üzembe helyezésével. A kritikus fontosságú számítási feladatok esetében az adatok régiók közötti szinkronizálásának kell elsődleges szempontnak lennie. Hiba esetén az adatbázisba irányuló írási kérelmeknek továbbra is működőképesnek kell lenniük.

  Az aktív-aktív konfigurációban az adatreplikálás erősen ajánlott. Az alkalmazásnak azonnal csatlakoznia kell egy másik régióhoz. Minden példánynak képesnek kell lennie az olvasási és írási kérelmek kezelésére.

• Üzenetközvetítő

  A regionális bélyeg egyetlen állapotalapú szolgáltatása az üzenetközvetítő, amely rövid ideig tárolja a kérelmeket. A közvetítő a pufferelés és a megbízható üzenetküldés szükségességét szolgálja. A feldolgozott kérések megmaradnak a globális adatbázisban.

További adatmegfelelőségeket a Misson-kritikus útmutatóban talál a jól kiépítésű keretrendszerben: Adatplatformokkal kapcsolatos szempontok.

Database

Ez az architektúra az Azure Cosmos DB for NoSQL-t használja. Ez a beállítás azért van kiválasztva, mert a legtöbb szükséges funkciót biztosítja ebben a kialakításban:

• Többrégiós írás

  A többrégiós írás minden régióban üzembe helyezett replikákkal engedélyezve van. Minden egyes bélyeg írhat helyileg, és az Azure Cosmos DB kezeli az adatreplikálást és a bélyegek közötti szinkronizálást. Ez a képesség jelentősen csökkenti az alkalmazás földrajzilag elosztott végfelhasználóinak késését. Az Azure Mission-Critical referencia-implementáció több főtechnológiával biztosítja a maximális rugalmasságot és rendelkezésre állást.

  A zónaredundancia az egyes replikált régiókban is engedélyezve van.

  A többrégiós írásokkal kapcsolatos részletekért lásd : Többrégiós írások konfigurálása az Azure Cosmos DB-t használó alkalmazásokban.

• Ütközéskezelés

  Ha több régióban is képes írást végezni, szükség van egy ütközéskezelési modell bevezetésére, mivel az egyidejű írások rekordütközéseket okozhatnak. A Last Writer Wins az alapértelmezett modell, és a kritikus fontosságú tervezéshez használatos. Az ütközést a rekordok társított időbélyegei által definiált utolsó író nyeri. Az Azure Cosmos DB for NoSQL egyéni tulajdonság definiálásához is lehetővé teszi.

• Lekérdezésoptimalizálás

  A nagy számú partícióval rendelkező írásvédett tárolókra vonatkozó általános lekérdezési hatékonysági javaslat egy egyenlőségi szűrő hozzáadása az elemazonosítóval. A lekérdezésoptimalizálási javaslatok részletes áttekintését az Azure Cosmos DB használatakor felmerülő lekérdezési problémák elhárítása című témakörben találja.

• Biztonsági mentési funkció

  Ajánlott az Azure Cosmos DB natív biztonsági mentési funkcióját használni az adatvédelemhez. Az Azure Cosmos DB biztonsági mentési funkciója támogatja az online biztonsági mentéseket és az igény szerinti adat-visszaállítást.

Megjegyzés:

A legtöbb számítási feladat nem pusztán OLTP. Egyre nagyobb az igény a valós idejű jelentésekre, például jelentések futtatására az operatív rendszeren. Ezt HTAP-nak (hibrid tranzakciós és elemzési feldolgozásnak) is nevezik. Az Azure Cosmos DB ezt a képességet az Azure Cosmos DB-hez készült Azure Synapse Linken keresztül támogatja.

Adatmodell a számítási feladathoz

Az adatmodellt úgy kell megtervezni, hogy a hagyományos relációs adatbázisok által kínált funkciók ne legyenek szükségesek. Például idegen kulcsok, szigorú sor-/oszlopséma, nézetek és egyéb.

A számítási feladat az alábbi adathozzáférési jellemzőkkel rendelkezik:

• Olvasási minta:
  • Pontolvasások – Egyetlen rekord beolvasása. Az elemazonosító és a partíciókulcs közvetlenül használható a maximális optimalizáláshoz (kérelemenként 1 RU).
  • Listaolvasások – Katalóguselemek megjelenítése a listában. FeedIterator az eredmények számának korlátozásával.
• Írási minta:
  • Kis írások – A kérelmek általában egyetlen vagy kis számú rekordot szúrnak be egy tranzakcióba.
• Úgy tervezték, hogy kezelje a végfelhasználóktól érkező nagy forgalmat, és skálázható legyen a forgalom igényének kezelése több millió felhasználó sorrendjében.
• Kis hasznos adat vagy adathalmaz mérete – általában KB sorrendben.
• Alacsony válaszidő (ezredmásodpercben).
• Alacsony késés (ezredmásodpercben).

Konfiguráció

Az Azure Cosmos DB a következőképpen van konfigurálva:

• A konzisztenciaszint az alapértelmezett munkamenet-konzisztenciára van beállítva, mivel ez az egyetlen régióban és globálisan elosztott alkalmazásokban leggyakrabban használt szint. Az írási feldolgozás aszinkron jellege miatt nincs szükség gyengébb konzisztenciára a magasabb átviteli sebességgel, és nem igényel alacsony késést az adatbázis-írásnál.

  Megjegyzés:

  A munkamenet konzisztenciaszintje ésszerű kompromisszumot kínál az adott alkalmazás késésére, rendelkezésre állására és konzisztenciájára vonatkozóan. Fontos tisztában lenni azzal, hogy az erős konzisztenciaszint nem érhető el több főkiszolgálós írási adatbázisokhoz.

• A partíciókulcs az összes gyűjteményhez be van állítva /id . Ez a döntés a használati mintán alapul, amely többnyire "új dokumentumok írása GUID azonosítóval" és "dokumentumok széles skálájának beolvasása azonosítókkal". Ha az alkalmazáskód megőrzi az azonosító egyediségét, az új adatok egyenletesen oszlanak el partíciókban az Azure Cosmos DB-ben, ami végtelen skálázást tesz lehetővé.

• Az indexelési szabályzat gyűjteményeken van konfigurálva a lekérdezések optimalizálásához. A ru költségeinek és teljesítményének optimalizálásához egyéni indexelési szabályzatot használunk. Ez a szabályzat csak a lekérdezési predikátumokban használt tulajdonságokat indexeli. Az alkalmazás például nem használja szűrőként a megjegyzés szövegmezőt a lekérdezésekben. Ki lett zárva az egyéni indexelési szabályzatból.

Íme egy példa az implementációból, amely a Terraform használatával indexeli a szabályzatbeállításokat:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

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

  included_path {
    path = "/*"
  }

}

További információ az alkalmazás és az Azure Cosmos DB közötti kapcsolatról ebben az architektúrában: Alkalmazásplatform–szempontok a kritikus fontosságú számítási feladatokhoz

Üzenetküldő szolgáltatások

A kritikus fontosságú rendszerek gyakran használnak üzenetkezelési szolgáltatásokat üzenet- vagy eseményfeldolgozáshoz. Ezek a szolgáltatások elősegítik a laza összekapcsolást, és pufferként működnek, amely elszigeteli a rendszert a váratlan keresletnövekedéssel szemben.

• Az Azure Service Bus üzenetalapú számítási feladatokhoz ajánlott a nagy értékű üzenetek kezelésekor.
• Az Azure Event Hubs olyan eseményalapú rendszerekhez ajánlott, amelyek nagy mennyiségű eseményt vagy telemetriát dolgoznak fel.

Az alábbiakban a prémium szintű Azure Service Bushoz és az Azure Event Hubshoz kapcsolódó tervezési szempontokat és javaslatokat vesszük figyelembe egy kritikus fontosságú architektúrában.

Terhelés kezelése

Az üzenetkezelő rendszernek képesnek kell lennie kezelni a szükséges átviteli sebességet (mb/másodpercben). Consider the following:

• A rendszer nem funkcionális követelményeinek (NFR-eknek) meg kell határozniuk az átlagos üzenetméretet, és az egyes bélyegeknek támogatniuk kell az üzenetek/másodpercek maximális számát. Ezek az információk felhasználhatók a szükséges mb/másodperc csúcsérték kiszámításához bélyegenként.
• A feladatátvétel hatását figyelembe kell venni a szükséges MB/másodperc csúcsérték kiszámításakor.
• Az Azure Service Bus esetében az NFR-eknek meg kell adniuk az olyan speciális Service Bus-funkciókat, mint a munkamenetek és az üzenetek duplikálása. Ezek a funkciók befolyásolják a Service Bus átviteli sebességét.
• A Szükséges funkciókkal rendelkező Service Bus átviteli sebességét mb/másodperces teszteléssel kell kiszámítani az üzenetkezelési egység (MU) alapján. A témakörről további információt a Service Bus prémium és standard üzenetkezelési szintjeiben talál.
• Az Azure Event Hubs átviteli sebességét mb/másodperc/átviteli egységként (TU) kell kiszámítani a standard szint vagy a prémium szintű feldolgozási egység (PU) esetében. A témakörrel kapcsolatos további információkért lásd : Skálázás az Event Hubs használatával.
• A fenti számítások segítségével ellenőrizhető, hogy az üzenetkezelési szolgáltatás képes-e kezelni a szükséges terhelést bélyegenként, valamint a terhelés teljesítéséhez szükséges méretezési egységek számát.
• A műveleti szakasz az automatikus skálázást ismerteti.

Minden üzenetet fel kell dolgozni

A prémium szintű Azure Service Bus az ajánlott megoldás olyan nagy értékű üzenetekhez, amelyek esetében a feldolgozást garantálni kell. Az Azure Service Bus prémium verzió használatakor az alábbi részletek vonatkoznak erre a követelményre:

• Annak érdekében, hogy az üzenetek megfelelően legyenek átadva a közvetítőnek és fogadják el azokat, az üzenetkészítőknek az egyik támogatott Service Bus API-ügyfelet kell használniuk. A támogatott API-k csak akkor térnek vissza sikeresen a küldési műveletből, ha az üzenet továbbra is megmarad az üzenetsoron/témakörön.

• A buszon lévő üzenetek feldolgozásának biztosítása érdekében a PeekLock fogadási módot kell használnia. Ez a mód legalább egyszer lehetővé teszi a feldolgozást. A folyamat a következő:

  • Az üzenet fogyasztója megkapja a feldolgozandó üzenetet.
  • A fogyasztó egy adott időtartamra kizárólagos zárolást kap az üzeneten.
  • Ha a fogyasztó sikeresen feldolgozza az üzenetet, visszaigazolást küld vissza a közvetítőnek, és az üzenet el lesz távolítva az üzenetsorból.
  • Ha a közvetítő nem kap nyugtát a kiosztott időszakban, vagy a kezelő kifejezetten lemondja az üzenetet, a kizárólagos zárolás felszabadul. Az üzenet ezután más felhasználók számára is elérhető az üzenet feldolgozásához.
  • Ha egy üzenet feldolgozása nem sikerült, konfigurálható számú alkalommal, vagy a kezelő továbbítja az üzenetet a kézbesítetlen levelek üzenetsorába.
    • Annak érdekében, hogy a kézbesítetlen levelek üzenetsorába küldött üzenetek megfelelően működjenek, figyelni kell a kézbesítetlen levelek üzenetsorát, és riasztásokat kell beállítani.
    • A rendszernek rendelkeznie kell olyan eszközök használatával, amelyek segítségével az operátorok megvizsgálhatják, kijavíthatják és újra küldhetik az üzeneteket.

• Mivel az üzenetek több alkalommal is feldolgozhatók, az üzenetkezelőket idempotenssé kell tenni.

Idempotens üzenetfeldolgozás

Az RFC 7231-ben a Hypertext Transfer Protocol a következőt állítja: "A ... a metódus idempotensnek minősül, ha az adott módszerrel több azonos kérelem kiszolgálójára gyakorolt tervezett hatása megegyezik egyetlen ilyen kérelem hatásával."

Az üzenetkezelés idempotenssé tételének egyik gyakori módszere egy állandó tároló, például egy adatbázis ellenőrzése, ha az üzenet már feldolgozásra került. Ha már feldolgozták, nem futtatná a logikát, hogy újra feldolgozhassa.

• Előfordulhatnak olyan helyzetek, amikor az üzenet feldolgozása magában foglalja az adatbázis-műveleteket, különösen új rekordok beszúrását adatbázis által generált azonosítókkal. Új üzeneteket küldhet a közvetítőnek, amelyek tartalmazzák ezeket az azonosítókat. Mivel nincsenek elosztott tranzakciók, amelyek az adatbázist és az üzenetközvetítőt is magukban foglalják, számos bonyodalom léphet fel, ha a kódot futtató folyamat meghiúsul. Lásd a következő példahelyzeteket:
  • Előfordulhat, hogy az üzeneteket kibocsátó kód az adatbázis-tranzakció véglegesítése előtt fut, azaz hány fejlesztő dolgozik a Unit of Work minta használatával. Ezek az üzenetek feloldhatók, ha a hiba a közvetítő meghívása és az adatbázis-tranzakció véglegesítésének kérése között következik be. A tranzakció visszatérve az adatbázis által létrehozott azonosítókat is visszavonja, így azok elérhetők maradnak az egyidejűleg futó más kódok számára is. Ez azt eredményezheti, hogy a menekülő üzenetek címzettjei nem megfelelő adatbázis-bejegyzéseket dolgoznak fel, ami rontja a rendszer általános konzisztenciáját és helyességét.
  • Ha a fejlesztők az adatbázis-tranzakció befejeződése után helyezik el az üzenetet kibocsátó kódot, a folyamat továbbra is meghiúsulhat a műveletek között (véglegesített tranzakció – elküldött üzenet). Ha ez történik, az üzenet újra feldolgozáson megy keresztül, de ezúttal az idempotence guard záradék látni fogja, hogy már feldolgozták (az adatbázisban tárolt adatok alapján). A záradék kihagyja az üzenetet, amely a kódot bocsátja ki, és úgy véli, hogy minden sikeres volt a múltkor. Az alárendelt rendszerek, amelyek arra számítottak, hogy értesítést kapnak a befejezett folyamatról, nem kapnak semmit. Ez a helyzet ismét az inkonzisztencia általános állapotát eredményezi.
• A fenti problémák megoldásához a tranzakciós kimenő üzenetek mintáját kell használni, ahol a kimenő üzeneteket a rendszer az üzleti adatokkal megegyező tranzakciós tárolóban tárolja. Az üzenetek ezután az üzenetközvetítőnek lesznek továbbítva, amikor a kezdeti üzenet feldolgozása sikeresen megtörtént.
• Mivel sok fejlesztő nem ismeri ezeket a problémákat vagy azok megoldásait, annak érdekében, hogy ezek a technikák következetesen érvényesüljenek egy kritikus fontosságú rendszerben, javasoljuk, hogy rendelkezik a kimenő üzenetek funkciójával és az üzenetközvetítővel való interakcióval valamilyen kódtárba csomagolva. A tranzakciós szempontból jelentős üzeneteket feldolgozó és küldő összes kódtárnak ezt a tárat kell használnia ahelyett, hogy közvetlenül kommunikál az üzenetközvetítővel.
  • A .NET-ben ezt a funkciót megvalósító kódtárak közé tartozik az NServiceBus és a MassTransit.

Magas rendelkezésre állás és vészhelyreállítás

Az üzenetközvetítőnek elérhetőnek kell lennie ahhoz, hogy a termelők üzeneteket küldjenek és a fogyasztók megkapják őket. A következő részletek vonatkoznak erre a követelményre:

• A Service Bus legmagasabb rendelkezésre állásának biztosításához használja a prémium szintet, amely támogatja a rendelkezésre állási zónákat a támogató régiókban. A rendelkezésre állási zónák esetében az üzenetek és a metaadatok az ugyanabban a régióban található három különböző adatközpontban replikálódnak.
• A támogatott Service Bus- vagy Event Hubs-SDK-k használatával automatikusan újrapróbálkozhat az olvasási vagy írási hibák.
• Fontolja meg az aktív-aktív replikációt vagy az aktív-passzív replikációs mintákat, hogy elszigetelje a regionális katasztrófákat.

Megjegyzés:

Az Azure Service Bus Geo-vészhelyreállítás csak régiók közötti metaadatokat replikál. Ez a funkció nem replikálja az üzeneteket.

Figyelés

Az üzenetkezelő rendszer pufferként működik az üzenetkészítők és a fogyasztók között. Vannak kulcsfontosságú jelzőtípusok, amelyeket egy kritikus fontosságú rendszerben kell figyelnie, amelyek az alábbiakban ismertetett értékes megállapításokat nyújtják:

• Szabályozás – A szabályozás azt jelzi, hogy a rendszer nem rendelkezik a kérés feldolgozásához szükséges erőforrásokkal. A Service Bus és az Event Hubs is támogatja a szabályozott kérelmek monitorozását. Erről a mutatóról riasztást kell adnia.
• Üzenetsor mélysége – A növekvő üzenetsormélység azt jelezheti, hogy az üzenetfeldolgozók nem működnek, vagy nincs elegendő processzor az aktuális terhelés kezeléséhez. Az üzenetsor mélysége a kezelők automatikus skálázási logikájának tájékoztatására használható.
  • A Service Bus esetében az üzenetsor mélysége üzenetszámként jelenik meg
  • Az Event Hubs esetében a felhasználóknak partíciónként ki kell számítaniuk a várólista mélységét, és le kell küldeniük a metrikát a monitorozási szoftverbe. Minden egyes olvasáshoz a fogyasztó megkapja az aktuális esemény sorszámát és az utolsó lekérdezett esemény eseménytulajdonságait. A fogyasztó kiszámíthatja az eltolást.
• Kézbesítetlen levelek üzenetsora – A kézbesítetlen levelek üzenetsorában lévő üzenetek olyan üzeneteket jelölnek, amelyeket nem sikerült feldolgozni. Ezek az üzenetek általában manuális beavatkozást igényelnek. A riasztásokat a kézbesítetlen levelek várólistáján kell beállítani.
  • A Service Bus holtbetűs üzenetsort és DeadLetteredMessages metrikát is rendelkezik.
  • Az Event Hubs esetében ennek a funkciónak a fogyasztóba épített egyéni logikának kell lennie.
• CPU-/memóriahasználat – A processzort és a memóriát figyelni kell, hogy az üzenetkezelő rendszer elegendő erőforrással rendelkezzen az aktuális terhelés feldolgozásához. A Service Bus prémium és az Event Hubs prémium szintű szolgáltatása is a processzor- és memóriahasználatot teszi elérhetővé.
  • Az üzenetkezelési egységek (MU-k) a Service Busban az erőforrások, például a processzor és a memória elkülönítésére szolgálnak egy névtér esetében. A cpu és a memória a küszöbérték fölé emelkedve azt jelezheti, hogy nincs elég termékváltozat konfigurálva, míg más küszöbértékek alá esve azt jelezheti, hogy túl sok termékváltozat van konfigurálva. Ezek a mutatók használhatók a termékváltozatok automatikus skálázásához.
  • A prémium szintű Event Hubs feldolgozási egységeket (PU-kat) használ az erőforrások elkülönítéséhez, míg a standard szint átviteli egységeket (TU-kat) használ. Ezek a szintek nem igényelnek interakciót a CPU-val/memóriával a PU-k vagy TU-k automatikus felfújásához.

Állapot-ellenőrzés

Az üzenetkezelési rendszer állapotát figyelembe kell venni egy kritikus fontosságú alkalmazás állapot-ellenőrzése során. Fontolja meg a következő tényezőket:

• Az üzenetkezelő rendszer pufferként működik az üzenetkészítők és a fogyasztók között. A bélyeg akkor tekinthető kifogástalannak, ha a termelők sikeresen küldhetnek üzeneteket a közvetítőnek, és ha a fogyasztók sikeresen feldolgozhatják a közvetítőtől érkező üzeneteket.
• Az állapot-ellenőrzésnek biztosítania kell, hogy üzeneteket lehessen küldeni az üzenetrendszernek.

További lépések

A referencia-implementáció üzembe helyezése az architektúra erőforrásainak és konfigurációjának teljes körű megismeréséhez.

Megvalósítás: Kritikus fontosságú online