Megosztás a következőn keresztül:

Automatikus skálázás

  • Cikk

Az automatikus skálázás az a folyamat, amely dinamikusan lefoglalja az erőforrásokat a teljesítményre vonatkozó követelményeknek megfelelően. Az elvégzendő feladatok mennyiségének növekedésével az alkalmazásoknak további erőforrásokra lehet szükségük ahhoz, hogy fenn tudják tartani a kívánt teljesítményszinteket és megfeleljenek a szolgáltatásiszint-szerződésekben (SLA) leírtaknak. Ahogy az erőforrásigény csökken, a további erőforrások felszabadíthatók a költségek csökkentése érdekében.

Az automatikus skálázás kihasználja a felhőben futtatott környezetek rugalmasságát, ugyanakkor csökkenti a kezelési terheket. Ezzel a megoldással kevésbé van szükség olyan operátorra, aki folyamatosan monitorozza a rendszer teljesítményét, és döntéseket hoz az erőforrások hozzáadásáról vagy eltávolításáról.

Az alkalmazásokat két fő módszerrel lehet skálázni:

  • A vertikális skálázás, más néven fel- és leskálázás az erőforrások kapacitásának módosítását jelenti. Például az alkalmazások áthelyezhetők egy nagyobb méretű virtuális gépre. A vertikális skálázáshoz a rendszereket általában ideiglenesen elérhetetlenné kell tenni az újbóli üzembe helyezés előtt. Emiatt a vertikális skálázás automatizálása kevésbé gyakori.

  • A horizontális skálázás, más néven is néven horizontális fel- és leskálázás erőforráspéldányok hozzáadását vagy eltávolítását jelenti. Az alkalmazás az új erőforrások kiépítése közben továbbra is megszakítás nélkül fut. Ha a kiépítési folyamat befejeződött, a megoldás a további erőforrásokon is üzembe helyezésre kerül. Ha az igény csökken, a további erőforrások probléma nélkül leállíthatók és felszabadíthatók.

Számos felhőalapú rendszer, köztük a Microsoft Azure is támogatja az automatikus horizontális skálázást. A cikk további része a horizontális skálázással foglalkozik.

Feljegyzés

Az automatikus skálázás legfőképp a számítási erőforrásokra vonatkozik. Bár lehetséges az adatbázisok vagy az üzenetsorok horizontális skálázása is, ehhez általában adatparticionálás szükséges, ami legtöbbször nem automatizált.

Összetevők automatikus skálázása

Az automatikus skálázási stratégia általában a következőket foglalja magába:

  • Rendszerek kialakítása és monitorozása az alkalmazás, szolgáltatás és infrastruktúra szintjén. Ezek a rendszerek olyan alapvető metrikákat rögzítenek, mint a válaszidők, az üzenetsorok hossza, a CPU-használat és a memóriahasználat.
  • Döntéshozási logika, amely e metrikákat az előre meghatározott küszöbértékekkel vagy ütemezésekkel összevetve értékeli, és eldönti, hogy szükség van-e skálázásra.
  • A rendszert skálázó összetevők.
  • Az automatikus skálázási stratégia tesztelése, monitorozása és finomhangolása annak érdekében, hogy a várt módon működjön.

Az Azure beépített automatikus skálázási mechanizmusokat biztosít, amelyek a gyakori forgatókönyvekhez használhatók. Ha egy adott szolgáltatás vagy technológia nem rendelkezik beépített automatikus skálázási funkcióval, vagy ha az adott automatikus skálázási követelmények meghaladják a kapacitását, érdemes lehet egy egyéni kialakítást használni. Az egyéni kialakítások összegyűjtik a működési és rendszermetrikákat, amelyeket elemeznek, majd ennek megfelelően skálázzák az erőforrásokat.

Egy Azure-megoldás automatikus skálázásának konfigurálása

Az Azure beépített automatikus skálázást nyújt a legtöbb számítási lehetőséghez.

Ezek a számítási lehetőségek mind az Azure Monitor automatikus skálázása segítségével biztosítják a közös automatikus skálázási funkciókat.

  • Az Azure Functions abban különbözik a korábbi számítási lehetőségektől, hogy nem kell hozzá automatikus skálázási szabályokat konfigurálni. Ehelyett az Azure Functions automatikusan lefoglalja a számítási erőforrásokat a kód futásakor, és szükség szerint végzi el a horizontális felskálázást a terhelés kezeléséhez. További információ: A megfelelő Azure Functions szolgáltatási csomag kiválasztása.

Végül egyes esetekben egy egyéni automatikus skálázási megoldás használata is hasznos lehet. Használhatja például az Azure Diagnosticst és az alkalmazásalapú metrikákat, valamint az egyéni kódot az alkalmazásmetrikák figyeléséhez és exportálásához. Ezután a metrikák alapján megadhat egyéni szabályokat, majd a Resource Manager REST API-k segítségével aktiválhatja az automatikus skálázást. Azonban az egyéni megoldásokat nem egyszerű megvalósítani, ezért a használatuk csak abban az esetben ajánlott, ha az előző módszerek egyike sem fel meg a követelményeknek.

Használja a platform beépített automatikus skálázási funkcióit, ha azok megfelelnek a követelményeinek. Ha nem, alaposan gondolja át, hogy valóban szüksége van-e az összetettebb skálázási funkciókra. További követelmények lehetnek például az irányítás részletesebbsége, a skálázás eseményindító eseményeinek észlelésének különböző módjai, az előfizetések közötti skálázás és más típusú erőforrások skálázása.

Az Azure Monitor automatikus skálázásának használata

Az Azure Monitor automatikus skálázása a virtuálisgép-méretezési csoportok, a Azure-alkalmazás Szolgáltatás és az Azure Cloud Service általános automatikus skálázási funkcióit biztosítja. A skálázás elvégezhető egy ütemezés szerint, vagy futtatókörnyezeti metrikára, például CPU- vagy memóriahasználatra is alapozható.

Példák:

  • Horizontális felskálázás 10 példányra hétköznapokon és horizontális leskálázás 4 példányra hétvégén.
  • Horizontális felskálázás egy példánnyal, ha az átlagos CPU-használat 70% fölé emelkedik és horizontális leskálázás egy példánnyal, ha a CPU-használat 50% alá esik.
  • Horizontális felskálázás egy példánnyal, ha egy üzenetsorban található üzenetek száma meghalad egy adott küszöbértéket.

A rendelkezésre állás biztosítása érdekében vertikálisan felskálázza az erőforrást, amikor a terhelés növekszik. Hasonlóképpen, alacsony használat esetén leskálázhatja a költségeket, így optimalizálhatja a költségeket. Mindig használjon felskálázási és vertikális felskálázási szabálykombinációt. Ellenkező esetben az automatikus skálázás csak egy irányban történik, amíg el nem éri a profilban beállított küszöbértéket (a példányok maximális vagy minimális számát).

Válassza ki a számítási feladat számára biztonságos alapértelmezett példányszámot. Ez az érték alapján skálázható, ha a példányok maximális vagy minimális száma nincs beállítva.

A beépített metrikák listájáért lásd: Az Azure Monitor automatikus skálázáshoz használt közös metrikái. Az Application Insights segítségével megvalósíthat egyéni metrikákat is.

Az automatikus skálázást a PowerShell, az Azure CLI, egy Azure Resource Manager-sablon vagy az Azure Portal használatával konfigurálhatja. Részletesebb vezérléshez használja az Azure Resource Manager REST API-t. Az Azure Monitoring Service Management Library és a Microsoft Insights Library (előzetes verzió) olyan SDK-k, amelyek lehetővé teszik a különböző erőforrások metrikáinak begyűjtését és az automatikus skálázás végrehajtását a REST API-k használatával. Az Azure Resource Managert nem támogató erőforrások, illetve az Azure Cloud Services használata esetén a Service Management REST API használható az automatikus skálázáshoz. Minden egyéb esetben használja az Azure Resource Managert.

Az Azure automatikus skálázás használatakor vegye figyelembe a következő szempontokat:

  • Fontolja meg, hogy az alkalmazás terhelését elég pontosan tudja-e előrejelezni az ütemezett automatikus skálázáshoz, a példányok hozzáadásához és eltávolításához, hogy megfeleljen a várható keresleti csúcsoknak. Ha ez nem lehetséges, használjon a futtatókörnyezeti metrikákon alapuló, reaktív automatikus skálázást, amely képes kezelni az erőforrásigény előre nem látható változásait. Általában ezek a módszerek kombinálhatók. Hozzon létre például egy stratégiát, amely erőforrásokat ad hozzá azon időpontok ütemezése alapján, amikor tudja, hogy az alkalmazás a legforgalmas. Ezzel biztosítható az igény szerinti kapacitás rendelkezésre állása az új példányok elindításából adódó késedelem nélkül. Minden egyes ütemezett szabályhoz megadhatók metrikák, amelyek az adott időszakra lehetővé teszik a reaktív automatikus skálázást annak biztosítása érdekében, hogy az alkalmazás kezelni tudja a tartós, de előre nem látható igénybevételi csúcsokat.

  • A metrikák és a kapacitásbeli követelmények közötti kapcsolatot általában nehéz átlátni, különösen egy alkalmazás első üzembe helyezésekor. A legjobb kezdetben kiépíteni egy kis további kapacitást, majd monitorozás alapján az automatikus skálázási szabályok finomhangolásával közelebb állítani a kapacitást a valós terheléshez.

  • Konfigurálja az automatikus skálázási szabályokat, majd egy ideig monitorozza az alkalmazás teljesítményét. A monitorozás eredményei alapján beállíthatja, hogy a rendszer szükség esetén hogyan végezze el a skálázást. Azonban vegye figyelembe, hogy az automatikus skálázás nem egy azonnali folyamat. Időbe telik, míg a rendszer reagál az olyan metrikákra, mint például amikor az átlagos CPU-használat meghalad egy bizonyos küszöbértéket (vagy az alá csökken).

  • A mért eseményindító attribútumon (például CPU-használaton vagy egy üzenetsor hosszán) alapuló észlelési mechanizmust használó automatikus skálázási szabályok az automatikus skálázási műveleteket nem azonnali értékek, hanem egy adott időszakra vonatkozó összesített érték alapján aktiválják. Alapértelmezés szerint az összesített érték az adott idő alatt mért értékek átlaga. Ez a módszer megakadályozza, hogy a rendszer túl gyorsan reagáljon vagy gyors ingadozást idézzen elő. Emellett lehetővé teszi az automatikusan elindított új példányok futási módba való rendezését, megakadályozva a további automatikus skálázási műveletek végrehajtását az új példányok indításakor. Az Azure Cloud Services és az Azure Virtual Machines esetében az alapértelmezett összesítési időszak 45 perc, tehát ennyi időbe telhet, amíg a metrika az igénybevételi csúcsokra válaszul aktivál egy automatikus skálázási műveletet. Az összesítési időszakot az SDK használatával módosíthatja, de a 25 percnél rövidebb időszakok kiszámíthatatlan eredményeket okozhatnak. A Web Apps esetében az átlagolási időtartam jóval rövidebb, így az új példányok már nagyjából öt perccel a kiváltó átlagolt mérőszám változását követően elérhetők.

  • Kerülje a felskálázást , ahol a vertikális felskálázási és vertikális felskálázási műveletek folyamatosan oda-vissza mennek. Tegyük fel, hogy két példány van, és a felső korlát 80%, az alsó korlát 60%. Ha a terhelés 85%-os, egy másik példány lesz hozzáadva. Egy idő után a terhelés 60%-ra csökken. A skálázás előtt az automatikus méretezési szolgáltatás kiszámítja a teljes terhelés eloszlását (három példányból) egy példány eltávolításakor, és 90%-ra csökkenti azt. Ez azt jelenti, hogy azonnal újra fel kell skáláznia. Ezért kihagyja a skálázást, és előfordulhat, hogy soha nem látja a várt skálázási eredményeket.

    A felskálázási helyzet szabályozható a vertikális felskálázási és a vertikális felskálázási küszöbértékek közötti megfelelő margó kiválasztásával.

  • A manuális skálázás alaphelyzetbe állítása az automatikus skálázáshoz használt példányok maximális és minimális számával történik. Ha manuálisan frissíti a példányok számát a maximális értéknél magasabb vagy alacsonyabb értékre, az automatikus skálázási motor automatikusan visszaskálázódik a minimumra (ha alacsonyabb) vagy a maximális értékre (ha magasabb). Beállíthatja például a 3 és 6 közötti tartományt. Ha egy futó példánya van, az automatikus skálázási motor a következő futtatáskor három példányra skálázható. Hasonlóképpen, ha manuálisan nyolc példányra állítja be a skálázást, a következő futtatáskor az automatikus skálázás a következő futtatáskor hat példányra skálázza vissza. A manuális skálázás ideiglenes, hacsak nem állítja alaphelyzetbe az automatikus skálázási szabályokat is.

  • Az automatikus skálázási motor egyszerre csak egy profilt dolgoz fel. Ha egy feltétel nem teljesül, akkor a következő profilt ellenőrzi. A kulcsmetrikák ne legyenek az alapértelmezett profilban, mert a profil utoljára van bejelölve. Egy profilon belül több szabály is lehet. A vertikális felskálázás esetén az automatikus skálázás akkor fut, ha bármilyen szabály teljesül. A vertikális felskálázáshoz az automatikus skálázáshoz minden szabálynak teljesülnie kell.

Az Azure Monitor méretezésének részleteiért tekintse meg az automatikus skálázás ajánlott eljárásait.

  • Ha az automatikus skálázást a portál helyett az SDK használatával konfigurálja, akkor részletesebb ütemezést adhat meg az aktív szabályokra vonatkozóan. Emellett létrehozhat saját metrikákat is, és felhasználhatja őket az automatikus skálázási szabályokhoz a meglévő metrikákkal együtt vagy azok nélkül is. Használhat például alternatív számlálókat, például a másodpercenkénti kérelmek számát vagy a memória átlagos rendelkezésre állását, vagy egyéni számlálókat használhat adott üzleti folyamatok mérésére.

  • A Service Fabric automatikus skálázásakor a fürt csomóponttípusai virtuálisgép-méretezési csoportokból állnak a háttérrendszerben, ezért minden csomóponttípushoz be kell állítania az automatikus méretezési szabályokat. Vegye figyelembe az automatikus skálázás beállítása előtt szükséges csomópontok számát. Az elsődleges csomóponttípushoz megadott minimálisan szükséges csomópontszámot a kiválasztott megbízhatósági szint határozza meg. További információ: Service Fabric-fürt méretezése automatikus skálázási szabályokkal.

  • A portál segítségével erőforrásokat, például SQL Database-példányokat és üzenetsorokat kapcsolhat egy Cloud Service-példányhoz. Ez könnyebben elérhetővé teszi a különböző manuális és automatikus skálázási konfigurációs beállításokat a kapcsolt erőforrások mindegyikéhez. További információ: Erőforrás összekapcsolása egy felhőalapú szolgáltatással.

  • Ha több házirend és szabály is konfigurálva van, azok ütközhetnek egymással. Az automatikus skálázás az alábbi ütközésfeloldási szabályok használatával biztosítja, hogy mindig elegendő mennyiségű példány fusson:

    • A vertikális felskálázási műveletek mindig elsőbbséget élveznek a vertikális felskálázási műveletekkel szemben.
    • A vertikális felskálázási műveletek ütközése esetén a példányok számának legnagyobb növelését kezdeményező szabály elsőbbséget élvez.
    • Ha horizontális leskálázási műveletek között van ütközés, akkor mindig a példányszámok legkisebb mértékű csökkentését kezdeményező szabály lép érvénybe.

  • App Service-környezetben bármely feldolgozókészlet vagy előtér-metrikák használhatók az automatikus skálázási szabályok meghatározására. További információ: Automatikus skálázás és az App Service Environment-környezet.

Alkalmazáskialakítási szempontok

Az automatikus skálázás nem egy azonnali megoldás. Ha egyszerűen hozzáadunk erőforrásokat egy rendszerhez, vagy több példányban futtatunk egy folyamatot, az nem garantálja a rendszer teljesítményének növekedését. Az automatikus skálázási stratégiák tervezésekor vegye figyelembe a következő szempontokat:

  • A rendszert úgy kell megtervezni, hogy horizontálisan skálázható legyen. Ne hagyatkozzon feltételezésekre a példányok affinitásával kapcsolatban, és ne tervezzen olyan megoldásokat, amelyeknek az az igénye, hogy a kód mindig egy folyamat adott példányán fusson. Egy felhőszolgáltatás vagy webhely horizontális skálázásakor nem szabad azt feltételezni, hogy az azonos forrásból érkező kérelmek mindig ugyanahhoz a példányhoz kerülnek. Ugyanezen okból a szolgáltatásokat állapot nélkülire kell tervezni, hogy az egy adott alkalmazástól érkező kéréseknek ne kelljen mindig a szolgáltatás ugyanazon példányához kerülnie. Amikor egy olyan szolgáltatást tervez meg, amely egy üzenetsor üzeneteit olvassa be és dolgozza fel, akkor ne hagyatkozzon feltételezésekre azt illetően, hogy egy adott üzenetet a szolgáltatás mely példánya fog kezelni. Az automatikus skálázással a szolgáltatás további példányai indíthatók el az üzenetsor hosszának növekedésével párhuzamosan. A versengő fogyasztók minta leírja, hogyan kell kezelni ezt a forgatókönyvet.

  • Ha a megoldás egy hosszan futó feladatot valósít meg, akkor a feladatot úgy kell megtervezni, hogy a horizontális fel- és leskálázást is támogassa. Megfelelő odafigyelés nélkül a feladatok akadályozhatják azt, hogy a folyamatpéldányok megfelelően leálljanak a rendszer leskálázásakor, vagy adatvesztést okozhatnak a folyamat kényszerített leállításakor. Ideális esetben érdemes a hosszan futó feladatot újrabontani, és az általa végzett feldolgozást kisebb, különálló darabokra osztani. A Csövek és szűrők minta egy példa arra, hogyan érheti el ezt.

  • További megoldásként megvalósíthat egy ellenőrzőpontos mechanizmust, amely rendszeres időközönként rögzíti a feladat állapotadatait és elmenti azokat egy tartós tárolóban, amelyhez a feladatot futtató folyamat bármely példánya hozzáférhet. Ily módon, ha a folyamat le van állítva, az elvégzett munka egy másik példány használatával folytatható az utolsó ellenőrzőpontról. Vannak olyan kódtárak, amelyek biztosítják ezt a funkciót, például az NServiceBus és a MassTransit. Transzparensen megőrzik az állapotot, ahol az intervallumok az Azure Service Bus üzenetsoraiból érkező üzenetek feldolgozásához igazodnak.

  • Ha a háttérfeladatok külön számítási példányokon futnak, például egy felhőszolgáltatások által üzemeltetett alkalmazás feldolgozói szerepköreiben, előfordulhat, hogy az alkalmazás különböző részeit különböző skálázási szabályzatok használatával kell skáláznia. Például szükséges lehet a felhasználói felületek (UI) további számítási példányainak üzembe helyezése a háttérbeli számítási példányok számának növelése nélkül, vagy ennek a fordítottja. Ha több különböző szolgáltatási szintet is nyújt (például alapszintű és prémium szolgáltatáscsomagokat), akkor a prémium szolgáltatáscsomagok a számítási erőforrások agresszívabb horizontális felskálázását igényelhetik az SLA betartása érdekében, mint az alapszintű szolgáltatáscsomagok.

  • Fontolja meg annak az üzenetsornak a hosszát, amelyen keresztül a felhasználói felület és a háttér számítási példányok kommunikálnak. Használja az automatikus skálázási stratégia kritériumaként. Ez az egyik lehetséges mutatója az aktuális terhelés és a háttérfeladat feldolgozási kapacitása közötti egyensúlyhiánynak vagy különbségnek. Van egy kissé összetettebb, de jobb attribútuma a méretezési döntések alapjául. Használja az üzenet elküldése és a feldolgozás befejezése közötti időt, amelyet kritikus időnek nevezünk. Ha ez a kritikus időérték egy jelentős üzleti küszöbérték alatt van, akkor nem szükséges skálázni, még akkor is, ha az üzenetsor hossza hosszú.

    • Előfordulhat például, hogy egy üzenetsor 50 000 üzenetet tartalmaz, de a legrégebbi üzenet kritikus ideje 500 ms, és ez a végpont egy külső webszolgáltatással való integrációval foglalkozik az e-mailek küldéséhez. Valószínű, hogy az üzleti érdekelt felek úgy vélik, hogy ez egy olyan időszak, amely nem indokolná a többletköltséget a skálázásra.
    • Másrészt 500 üzenet lehet egy üzenetsorban ugyanazzal az 500 ms kritikus idővel, de a végpont egy valós idejű online játék kritikus útjának része, ahol az üzleti érdekelt felek 100 ms-os vagy annál rövidebb válaszidőt határoztak meg. Ebben az esetben a horizontális felskálázásnak van értelme.
    • Annak érdekében, hogy a kritikus időt kihasználhassa az automatikus skálázási döntések során, hasznos lehet, ha egy tár automatikusan hozzáadja a releváns információkat az üzenetek fejlécéhez, miközben a rendszer elküldi és feldolgozza őket. Az egyik ilyen kódtár, amely ezt a funkciót biztosítja, az NServiceBus.

  • Ha az automatikus skálázási stratégia alapja egy üzleti folyamatokhoz kapcsolódó mérőszám, amely például az óránként leadott megrendelések számát vagy egy összetett tranzakció átlagos végrehajtási idejét méri, akkor mindenképpen legyen tisztában azzal, hogy milyen összefüggés van az ilyen típusú mérőszámok eredményei és a tényleges számítási kapacitásigények között. Elképzelhető, hogy az üzleti folyamatok mérőszámainak változására válaszul egynél több összetevőt vagy számítási egységet is skálázni kell.

  • Annak érdekében, hogy a rendszer ne próbálkozzon túlzott mértékű horizontális felskálázással, illetve a több ezer példány futtatásából adódó költségek elkerüléséhez érdemes korlátozni az automatikusan hozzáadható példányok maximális számát. A legtöbb automatikus skálázási mechanizmus lehetővé teszi az egyes szabályokhoz tartozó minimális és maximális példányszámok megadását. Emellett érdemes lehet megfontolni a rendszer által nyújtott funkciók zökkenőmentes csökkentését abban az esetben, ha az üzembe helyezett példányok száma elérte a maximális értéket, és a rendszer még mindig túl van terhelve.

  • Vegye figyelembe, hogy az automatikus skálázás nem feltétlenül a legmegfelelőbb mechanizmus a terhelés hirtelen növekedésének kezeléséhez. Az új szolgáltatáspéldányok kiépítése és indítása, illetve az erőforrások hozzáadása időigényes művelet, és lehet, hogy mire a további erőforrások elérhetővé válnak, addigra az igénycsúcs már el is múlt. Ebben az esetben érdemesebb lehet a szolgáltatás szabályozását választani. További információkért tekintse meg a szabályozás mintáját.

  • Ezzel szemben amikor az erőforrásigény hirtelen ingadozásakor szükség van az összes kérelem feldolgozásához elegendő kapacitásra, és a költségek nem jelentenek elsődleges szempontot, akkor érdemes egy agresszív automatikus skálázási stratégiát használni, amely gyorsabban elindítja a további példányokat. Használhat egy ütemezett szabályzatot is, amely a várt maximális terhelés kezeléséhez elegendő számú példányt indít el még a terhelés várt időpontja előtt.

  • Az automatikus skálázási mechanizmusnak monitoroznia kell az automatikus skálázási folyamatot, és naplóznia kell az összes automatikus skálázási esemény részleteit (az eseményindítót, illetve hogy mely erőforrások lettek hozzáadva vagy eltávolítva és mikor). Az egyéni automatikus skálázási mechanizmusok létrehozásakor ügyeljen arra, hogy a mechanizmus tartalmazza ezt a funkciót. Elemezze az adatokat, és mérje fel az automatikus skálázási stratégia hatékonyságát, majd szükség esetén finomhangolja a stratégiát. A hangolást elvégezheti rövid távon, a használati minták világosabbá válásával párhuzamosan, vagy hosszú távon, az üzleti bővülését vagy az alkalmazás követelményeinek változását követve. Ha egy alkalmazás eléri az automatikus skálázáshoz megadott felső korlátot, akkor a mechanizmus riasztást küldhet az operátornak, aki szükség esetén manuálisan indíthat el további erőforrásokat. Vegye figyelembe, hogy ilyen körülmények között az operátor is felelős lehet az erőforrások manuális eltávolításáért, miután a számítási feladatok enyhülnek.

Az automatikus skálázás megvalósításakor az alábbi minták és útmutatók is relevánsak lehetnek a forgatókönyvben:

  • Szabályozási minta. Ez a minta azt ismerteti, hogy egy alkalmazás hogyan működhet tovább és hogyan teljesítheti az SLA-k feltételeit, amikor az erőforrásigény növekedése rendkívüli módon leterheli az erőforrásokat. A szabályozás és az automatikus skálázás együttes használatával megelőzhető a rendszer túlterhelődése a felskálázás közben.

  • Versengő felhasználókat ismertető minta. Ez a minta azt ismerteti, hogy hogyan helyezhető üzembe egy szolgáltatáspéldány-készlet, amely képes bármely alkalmazáspéldány üzeneteit kezelni. Az automatikus skálázás használatával a szolgáltatáspéldányok a várt terhelésnek megfelelően indíthatók el és állíthatók le. Ez a megközelítés lehetővé teszi, hogy a rendszer több üzenetet dolgozzon fel párhuzamosan a teljesítmény optimalizálása, a skálázhatóság és rendelkezésre állás javítása és a terhelés elosztása érdekében.

  • Monitorozás és diagnosztika. A kialakítás és a telemetria kulcsfontosságú szerepet játszanak az automatikus skálázást vezérlő adatok összegyűjtésében.