Queue-Based Terheléskiegyenlítő minta

Használjon egy olyan üzenetsort, amely pufferként működik egy feladat és az általa meghívott szolgáltatás között. Ez a megközelítés kisimítja az időszakosan nagy terheléseket, amelyek a szolgáltatás meghibásodását vagy a feladat időtúllépését okozhatják. Segít minimalizálni az igénycsúcsok hatását a feladat és a szolgáltatás rendelkezésre állására és válaszkészségére.

Kontextus és probléma

A felhőben számos olyan megoldás fut, amely szolgáltatásokat hív meg. Ebben a környezetben az időszakos nagy terhelések teljesítmény- vagy megbízhatósági problémákat okozhatnak egy szolgáltatás számára.

Előfordulhat, hogy egy szolgáltatás ugyanahhoz a megoldáshoz tartozik, mint az azt használó feladatok, vagy egy partnerszolgáltatás, amely hozzáférést biztosít a gyakran használt erőforrásokhoz. Ilyen típusú szolgáltatások például a gyorsítótár vagy a tárolási szolgáltatás. Ha egyszerre több tevékenység is fut, és ugyanazt a szolgáltatást használja, nehéz előrejelezni a kérések mennyiségét.

Előfordulhat, hogy egy szolgáltatás túlterheli az igényeket, és a szolgáltatás nem tud gyorsan válaszolni a kérésekre. Ha egy szolgáltatás több egyidejű kéréssel van elárasztva, az a szolgáltatás meghiúsulását is okozhatja, ha nem tudja kezelni a kérések által okozott versengést.

Megoldás

Helyezzen egy várólistát a feladat és a szolgáltatás közé. A feladatok és a szolgáltatás aszinkron módon fut. A feladat egy olyan üzenetet küld az üzenetsorba, amely a szolgáltatás számára szükséges adatokat tartalmazza. Az üzenetsor pufferként működik, és tárolja az üzenetet, amíg a szolgáltatás le nem kéri. A szolgáltatás lekéri az üzeneteket az üzenetsorból, és feldolgozza őket. Több feladat kérései, amelyek nagy mértékben változó sebességgel hozhatók létre, ugyanazon üzenetsoron keresztül továbbíthatók a szolgáltatásnak. Az alábbi ábra azt mutatja be, hogy egy üzenetsor hogyan képes kiegyenlíteni egy szolgáltatás terhelését.

Az ábra azt mutatja be, hogy egy üzenetsor hogyan választja el a változó díjas feladatkéréseket egy olyan szolgáltatástól, amely konzisztens sebességgel dolgozza fel őket. A folyamat balról jobbra halad. A bal oldalon külön nyilak mutatnak három feladatikonról egy központi üzenetsorra, szemléltetve, hogy a feladatok egymástól függetlenül küldenek kéréseket ugyanabba az üzenetsorba. Egyetlen nyíl az üzenetsorból a jobb szélen található szolgáltatáscsomópontra mutat, amely azt jelzi, hogy a szolgáltatás egységes ütemben dolgozza fel az üzeneteket.

Az üzenetsor leválasztja a feladatokat a szolgáltatásról, hogy a szolgáltatás a saját tempójában tudja kezelni az üzeneteket, még akkor is, ha az egyidejű tevékenységek nagy mennyiségű kérést generálnak. Emellett a feladatok végrehajtása nem késik akkor sem, ha a szolgáltatás nem érhető el, amikor üzeneteket küld az üzenetsorba.

Ez a minta az alábbi előnyökkel jár:

• Segít maximalizálni a rendelkezésre állást, mert a szolgáltatás késései nem azonnal és közvetlenül befolyásolják az alkalmazást. Az alkalmazás akkor is közzétehet üzeneteket az üzenetsorba, ha a szolgáltatás nem érhető el, vagy jelenleg nem dolgoz fel üzeneteket.

• Segít maximalizálni a méretezhetőséget, mert az üzenetsorok száma és a szolgáltatások száma az igényeknek megfelelően változhat.

• Segít a költségek szabályozásában, mert a csúcsterhelés helyett csak annyi szolgáltatáspéldányra van szüksége, hogy megfeleljen az átlagos terhelés követelményeinek.

Megjegyzés:

Egyes szolgáltatások korlátozást alkalmaznak, amikor a terhelés elér egy olyan küszöböt, amely rendszerhibához vezethet. A szabályozás csökkentheti a rendelkezésre álló funkciókat. A terhelésszintezés implementálása ezekben a szolgáltatásokban annak biztosítása érdekében, hogy a kereslet ne érje el ezt a küszöbértéket.

Problémák és szempontok

Vegye figyelembe a következő szempontokat, amikor úgy dönt, hogy hogyan valósítja meg ezt a mintát:

• Olyan alkalmazáslogika implementálása, amely szabályozza, hogy a szolgáltatások milyen sebességgel kezelik az üzeneteket, hogy ne terheljék túl a célerőforrást. Ne továbbítsa a terhelési csúcsokat a rendszer következő szakaszára. Tesztelje a terhelés alatt álló rendszert, hogy biztosítsa a szükséges simítást. A szükséges kiegyenlítés eléréséhez módosítsa az üzenetsorok és az üzeneteket kezelő szolgáltatáspéldányok számát.

• Az üzenetsorok egyirányú kommunikációs mechanizmusok. Ha egy feladat választ vár egy szolgáltatástól, előfordulhat, hogy olyan mechanizmust kell implementálnia, amelyet a szolgáltatás a válasz küldéséhez használhat. További információ: Aszinkron üzenetkezelési lehetőségek Azure.

• Az automatikus skálázás a fogyasztói aggregátum alsóbb rétegbeli aránya nélkül csak a túlterhelést helyezi át az alsóbb rétegbeli függőségekre. Ez a túlterhelés növelheti az ezen szolgáltatások által megosztott erőforrások versengésének mértékét, és csökkentheti a várólista hatékonyságát a terhelés kiegyenlítéséhez.

• Ha az átlagos előállítási sebesség meghaladja a feldolgozási sebességet, az üzenetsor tovább növekszik, és a késleltetés is nő. Figyelje a sormélységet, és a biztonságos határokon belül skálázza a fogyasztókat, vagy csökkentse a terhelést a termelő oldalon.

• Ez a minta az üzenetsor tartósságától függ az üzenetvesztés megelőzése érdekében. Ha a közvetítő nem őrzi meg az üzeneteket tartós tárolóba, a lefagyás vagy a kapacitáskorlát miatt a lekérdezett adatok elveszhetnek, mielőtt a felhasználók feldolgozzák azokat. Válasszon egy üzenetsor-szolgáltatást, amely megőrzi az üzeneteket a lemezen vagy a replikált tárolóban, és ismerje meg a méretkvótákat és a megőrzési korlátokat. Azon munkaterhelések esetében, amelyeknél az üzeneteknek túl kell élniük a regionális kieséseket, értékelje a geokatasztrófa-helyreállítási lehetőségeket.

• A legtöbb üzenetsor-szolgáltatás legalább egyszeri kézbesítési szemantikát alkalmaz, ami azt jelenti, hogy a fogyasztók ugyanazt az üzenetet többször is megkaphatják. A fogyasztói logikát úgy tervezheti meg, hogy idempotens legyen, hogy ugyanazt az üzenetet többször feldolgozva ugyanazt az eredményt hozza létre, és elkerülje az olyan problémákat, mint az ismétlődő rekordok vagy az ismétlődő díjak.

• Egyes üzenetek nem dolgozhatók fel, mert hibás adatokat tartalmaznak, hiányzó erőforrásokra hivatkoznak, vagy állandó hibákat váltanak ki. Ahelyett, hogy hagyná ezeket az üzeneteket végtelenül körbejárni és blokkolni az üzenetsort, irányítsa őket egy holtlevelek üzenetsorába. Figyelje a kézbesítetlen üzenetek üzenetsorának mélységét, hogy az operatív csapat kivizsgálhassa a hibákat, kijavíthassa a mögöttes problémát, és szükség esetén újra elküldhesse az üzeneteket.

• A gyártó és a fogyasztó közötti üzenetsor bevezetése nem őrzi meg az eredeti beküldési sorrendet minden körülmények között, különösen akkor, ha több fogyasztó dolgoz fel párhuzamosan üzeneteket. Ha a munkaterhelése szigorú sorrendiséget igényel, használja az Azure Service Bus olyan funkcióit, mint az üzenet-munkamenetek. Ha nincs szükség szigorú rendezésre, úgy tervezze meg a felhasználókat, hogy bármilyen sorrendben kezeljék az üzeneteket, ami leegyszerűsíti a skálázást.

Mikor érdemes használni ezt a mintát?

Használja ezt a mintát a következő esetekben:

• A munkaterhelés időnként megugrik, ami túlterhelheti az utána következő szolgáltatásokat.

• A rugalmasság és a költségszabályozás javítása érdekében el kell különítenie a kérelembevitelt a feldolgozási teljesítménytől.

Ez a minta nem feltétlenül megfelelő, ha:

• A hívó kis késésű, szinkron választ igényel.

• A terhelés volumene előre láthatóan alacsony és stabil, ezért a sorba állítás többletbonyolultsága kevés haszonnal jár.

Munkaterhelés tervezése

Értékelje ki, hogyan használhatja a Queue-Based terhelésegyenlítési mintát a számítási feladatok tervezésében a Azure Well-Architected keretrendszer pilléreiben szereplő célok és alapelvek kezelésére. Az alábbi táblázat útmutatást nyújt arról, hogy ez a minta hogyan támogatja az egyes pillérek céljait.

Alappillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítják, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Az ebben a mintában leírt megközelítés rugalmasságot biztosíthat a hirtelen megnövekedett kereslet ellen azáltal, hogy leválasztja a tevékenységek érkezését a feldolgozásukról. Elkülönítheti az üzenetsor-feldolgozás hibáit is, hogy ne befolyásolják a bevitelt. - RE:06 Skálázás
A költségoptimalizálás a számítási feladatok megtérülésénekfenntartására és javítására összpontosít.	Mivel a terhelésfeldolgozás leválasztva van a kérésről vagy a tevékenységbevitelről, ezzel a módszerrel csökkentheti az erőforrások túlterheltségének szükségességét a csúcsterhelés kezeléséhez. - CO:12 skálázási költségek
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését .	Ez a megközelítés lehetővé teszi az átviteli sebesség szándékos tervezését, mivel a kérelembevitelnek nem kell korrelálnia a feldolgozási sebességgel. - PE:05 Skálázás és particionálás

Ha ez a minta kompromisszumokat vezet be egy pilléren belül, vegye figyelembe őket a többi pillér céljaival szemben.

Example

Egy webalkalmazás adatokat ír egy külső adattárba. Ha a webalkalmazás több példánya egyidejűleg fut, előfordulhat, hogy az adattár nem tud elég gyorsan válaszolni a kérelmekre, aminek következtében a kérelmek időtúllépéssel megszakadhatnak, korlátozás alá eshetnek, vagy más módon meghiúsulhatnak. Az alábbi ábra egy olyan adattárat mutat be, amelyet egy alkalmazás példányaitól érkező egyidejű kérések túlterheltek.

A diagramban a nyilak több függőlegesen halmozott Azure App Service példányikonról egy adattárikonra mutatnak. Néhány App Service-példány sikeresen csatlakozik az adattárhoz. Két példányon egy időtúllépés címkével ellátott blokkolt kapcsolat szimbólum látható, amely azt jelzi, hogy a kapcsolati kísérlet meghiúsult.

A probléma megoldásához használjon üzenetsort az alkalmazáspéldányok és az adattár közötti terhelés kiegyenlítésére. Egy Azure Functions-alkalmazás beolvassa az üzeneteket egy Service Bus üzenetsorból, és végrehajtja az olvasási/írási kéréseket az adattárba. Azure Functions a példányokat Service Bus teendőlista alapján skálázhatja célalapú skálázással, a konfigurált skálázási korlátokon belül. Az eseményindító egyidejűségi beállításait is hangolhatja az adattár védelméhez. A megvalósítással kapcsolatos útmutatásért tekintse meg a célalapú skálázást és a horizontális felskálázás korlátozását. A hangolás nélkül a feldolgozó réteg újra bevezetheti a háttérbeli versengést.

A diagramon nyilak mutatnak több, függőlegesen egymás fölé rendezett App Service-példányikon felől egy Service Bus-üzenetsor felé. Egy másik nyíl az üzenetsorból egy függvényalkalmazáson keresztül az adattárba mutat.

Technológiai változatként ugyanezt a mintát Azure Functions helyett Azure Container Apps használatával valósíthatja meg. Ebben a megközelítésben a tárolóalapú feldolgozó Service Bus üzeneteket használ fel, és az adattárba ír. A Container Apps a várakozási sorokkal kapcsolatos méretezési szabályok alapján skálázza a feldolgozót a konfigurált minimális és maximális replikák között. Ugyanezt a megközelítést az Azure Queue Storage használatával is implementálhatja, mint az eseményforrás. A megvalósítással kapcsolatos útmutatásért lásd: Méretezési szabályok beállítása a Container Appsben , és eseményvezérelt feladat üzembe helyezése a Container Apps használatával.

Következő lépések

A minta megvalósításakor az alábbi útmutatás is releváns lehet:

• Aszinkron üzenetkezelési beállítások a Azure: Az üzenetsorok eredendően aszinkronok. Előfordulhat, hogy újra kell terveznie egy feladat alkalmazáslogikát, ha az közvetlenül kommunikál egy szolgáltatással. Hasonlóképpen előfordulhat, hogy újra kell létrehoznia egy szolgáltatást az üzenetsorból érkező kérések elfogadásához.

• A Azure üzenetkezelési szolgáltatások közötti váltás: További információt kaphat az üzenetkezelési és üzenetsor-kezelési mechanizmus kiválasztásához Azure alkalmazásokban.

• Javaslatok háttérfeladatok fejlesztéséhez: Alkalmazza ezt a mintát a háttérfeladatokra, hogy az üzenetsorok tárolhassák a háttérfeladatokra vonatkozó kéréseket, amikor az alkalmazás nagy terhelést tapasztal.

• Web-Queue-Worker architektúraminta: A webes réteg és a feldolgozó egyaránt állapotmentes. A munkamenet-állapot tárolható egy megosztott gyorsítótárban. A feldolgozó aszinkron módon végez hosszú ideig tartó feladatokat, és az üzenetsorban érkező üzenetek indíthatják el, vagy ütemezetten futhat kötegelt feldolgozás céljából.

Kapcsolódó erőforrások

• Versengő fogyasztók minta: Lehetséges, hogy egy szolgáltatás több példánya fut, és mindegyik a terheléskiegyenlítő üzenetsor üzenetfogyasztójaként működik. Ezzel a módszerrel beállíthatja az üzenetek szolgáltatásból való fogadásának és a szolgáltatásba küldésének sebességét.

• Szabályozási minta: A szolgáltatás szabályozásának egyszerű módja az üzenetsoralapú terhelésszintezés használata, és az összes kérés átirányítása egy szolgáltatáshoz egy üzenetsoron keresztül. A szolgáltatás olyan sebességgel tudja feldolgozni a kéréseket, hogy az ne használja ki a szükséges erőforrásokat, és csökkentse a lehetséges versengés mennyiségét.