Automatikus skálázás

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. A munkamennyiség növekedésével az alkalmazásoknak több erőforrásra lehet szükségük a kívánt teljesítményszintek fenntartásához és a szolgáltatási szintű célkitűzések (SLO-k) teljesítéséhez. Mivel a keresleti tartalékok és a többleterőforrások már nem szükségesek, a költségek minimalizálása érdekében megszüntethetők.

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 vertikális fel- és leskálázás az erőforrás kapacitásának módosítását jelenti. Áthelyezhet például egy alkalmazást egy nagyobb méretű virtuális gépre. A vertikális skálázáshoz gyakran szükséges, hogy a rendszer ideiglenesen elérhetetlenné váljon az újbóli üzembe helyezés során. Ezért kevésbé gyakori a függőleges skálázás automatizálása.

  • A horizontális skálázás, más néven horizontális felskálázás egy erőforrás példányainak 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. Amikor a kiépítési folyamat befejeződött, a megoldás üzembe lesz helyezve ezeken a további erőforrásokon. Ha csökken az igény, a többleterőforrások 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ásra összpontosít.

Megjegyzés:

Az automatikus skálázás többnyire a számítási erőforrásokra vonatkozik. Bár lehetséges egy adatbázis vagy üzenetsor horizontális skálázása, ez a folyamat általában adatparticionálást is magában foglal, amely általában nem automatizált.

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

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

  • Eszközfelügyeleti és monitorozási rendszerek az alkalmazás, a szolgáltatás és az infrastruktúra szintjén. Ezek a rendszerek rögzítik a főbb metrikákat, például a válaszidőket, az üzenetsor hosszát, a processzorhasználatot és a memóriahasználatot.

  • A döntéshozatali logika ezeket az élő használati metrikákat előre meghatározott küszöbértékek vagy ütemezések alapján értékeli ki, és dönti el, hogy skálázni szeretne-e.

  • Az összetevők és mechanizmusok elvégzik a skálázási műveletet. Ideális esetben ezeket az összetevőket és mechanizmusokat függetleníteni kell a számítási feladat kódjától, és külső folyamatként kell kezelni. A tétlen vagy túlterhelt kód nem lehet felelős a skálázásért.

  • Az automatikus skálázási stratégia tesztelése, monitorozása és hangolása a képességek biztosítása érdekében, hogy a kívánt módon működjön.

Az Azure beépített automatikus skálázási mechanizmusokat biztosít, amelyek a gyakori forgatókönyveket kezelik. Ha egy adott szolgáltatás vagy technológia nem rendelkezik beépített automatikus skálázási funkcióval, vagy ha a képességein túl konkrét automatikus skálázási követelményekkel rendelkezik, fontolja meg az egyéni implementációt. Az egyéni implementációk összegyűjtik a működési és rendszermetrikákat, elemzik a metrikákat, és ennek megfelelően méretezik az erőforrásokat.

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

Az Azure beépített automatikus skálázást biztosít 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ási funkcióját használják az automatikus skálázási funkciók általános készletének biztosítására.

  • Az Azure Functions eltér az előző számítási beállításoktól, mivel nem kell automatikus skálázási szabályokat konfigurálnia. Ehelyett az Azure Functions automatikusan lefoglalja a számítási teljesítményt a kód futtatásakor. Az Azure Functions szükség szerint felskálázható a terhelés kezeléséhez. További információ: Az Azure Functions megfelelő üzemeltetési csomagjának kiválasztása.

Az egyéni automatikus skálázási megoldások néha hasznosak lehetnek. 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 definiálhat egyéni szabályokat ezek alapján a metrikák alapján, és az Azure Resource Manager REST API-kkal aktiválhatja az automatikus skálázást. Az egyéni megoldások azonban jelentős erőfeszítéseket igényelhetnek, ezért csak akkor vegye figyelembe, ha az előző megközelítések egyike sem felel meg a követelményeknek.

Ha megfelelnek a követelményeknek, használja a platform beépített automatikus skálázási funkcióit. Ha nem, alaposan gondolja át, hogy összetettebb skálázási funkciókra van-e szüksége. Más követelmények közé tartozhat 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ási funkciójának használata

Az Azure Monitor automatikus skálázási funkciója a virtuálisgép-méretezési csoportok, az App Service és az Azure Cloud Services általános automatikus méretezési funkcióit biztosítja. A skálázás ütemezés szerint vagy futtatókörnyezeti metrika alapján végezhető el, például processzor- vagy memóriahasználat alapján.

Vegye figyelembe a következő példákat:

  • Hétköznapokon skálázzon ki 10 példányra, szombaton és vasárnap pedig skálázzon be négy példányra.

  • Ha az átlagos cpu-használat nagyobb, mint 70%, egy példányra skálázható fel, ha a processzorhasználat 50%alá esik.

  • Horizontális skálázás egy példánnyal, ha az üzenetsorban lévő üzenetek száma meghaladja a megadott küszöbértéket.

Az erőforrást felskálázza, amikor a terhelés növekszik, hogy biztosítsa a rendelkezésre állást. Alacsony használat idején mérsékelje a költségeket, hogy optimalizálhassa azokat. Mindig használjon skálázás kifelé és skálázás befelé 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. Az erőforrás skálázása ezen érték alapján történik, 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 tekintse meg az Azure Monitor gyakori metrikák automatikus skálázását. Az Application Insights használatával egyéni metrikákat is implementálhat.

Az automatikus skálázást a PowerShell, az Azure CLI, az Azure Resource Manager-sablon vagy az Azure Portal használatával konfigurálhatja. Részletesebb vezérléshez használja a Resource Manager REST API-t. Az Azure Monitoring Management Library és a Microsoft Insights Library (előzetes verzióban) olyan SDK-k, amelyek lehetővé teszik a metrikák gyűjtését különböző erőforrásokból, és automatikus skálázást hajtanak végre a REST API-k használatával. Olyan erőforrások esetében, ahol a Resource Manager-támogatás nem érhető el, vagy ha az Azure Cloud Servicest használja, a Service Management REST API használható az automatikus skálázáshoz. Minden más esetben használja a Resource Managert.

Az 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 nem, használjon reaktív automatikus skálázást futtatókörnyezeti metrikák alapján a kiszámíthatatlan keresletváltozások kezeléséhez. Ezeket a megközelítéseket általában kombinálhatja.

    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. A további erőforrások segítenek biztosítani, hogy szükség esetén a kapacitás rendelkezésre álljon, az új példányok indításától való késedelem nélkül. Minden ütemezett szabályhoz definiáljon olyan metrikákat, amelyek lehetővé teszik a reaktív automatikus skálázást ebben az időszakban annak érdekében, hogy az alkalmazás kezelni tudja a tartós, de kiszámíthatatlan keresleti csúcsokat.

  • Gyakran nehéz megérteni a metrikák és a kapacitáskövetelmények közötti kapcsolatot, különösen akkor, ha egy alkalmazás üzembe helyezése először történik. Az elején konfiguráljon egy kis extra kapacitást, majd figyelje és hangolja az automatikus méretezési szabályokat, hogy közelebb hozza a kapacitást a tényleges terheléshez.

  • Konfigurálja az automatikus méretezési szabályokat, majd figyelje az alkalmazás teljesítményét az idő függvényében. A monitorozás eredményeinek használatával szükség esetén módosíthatja a rendszer méretezési módját. Ne feledje azonban, hogy az automatikus skálázás nem azonnali folyamat. Egy metrika, például az átlagos processzorkihasználtság túllépése vagy egy megadott küszöbérték alá esése időt vesz igénybe.

  • A mért triggerattribútumon alapuló észlelési mechanizmust használó automatikus skálázási szabályok a pillanatnyi értékek helyett egy összesített értéket használnak az automatikus skálázási művelet aktiválásához. Az eseményindító attribútumok közé tartozik a processzorhasználat vagy az üzenetsor hossza. Alapértelmezés szerint az összesítés az értékek átlaga. Ez a megközelítés megakadályozza, hogy a rendszer túl gyorsan reagáljon, vagy gyors oszcillációt okoz. Emellett időt biztosít az új példányok számára, amelyek automatikusan elindulnak, hogy stabilan fussanak. Más automatikus skálázási műveletek nem végezhetők el az új példányok indításakor. Az Azure Cloud Services és az Azure Virtual Machines esetében az összesítés alapértelmezett időtartama 45 perc. Így a metrika akár ennyi ideig is képes automatikus skálázást aktiválni a megnövekedett keresletre reagálva. 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. Az App Service Web Apps szolgáltatása esetében az átlagolási időszak rövidebb, így az új példányok körülbelül öt percen belül elérhetők lesznek az átlagos eseményindító mérték módosítása után.

  • Kerülje az ingadozást, amikor a skálacsökkentési és skálanövelési műveletek folyamatosan oda-vissza mennek. Tegyük fel, hogy két példány van. A felső korlát 80% CPU, az alsó korlát pedig 60%. Ha a terhelés eléri a 85%-t, hozzáadunk egy másik példányt. Egy idő után a terhelés 60%- ra csökken. Mielőtt az automatikus skálázási szolgáltatás visszaskálázódik, kiszámítja a teljes terhelés (három példány közötti) eloszlását, amikor eltávolítanak egy példányt, így az eléri a 90%értéket. Azonnal újra ki kell bővíteni a kapacitást. 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 hullámzó helyzet szabályozható azáltal, hogy megfelelő margót választunk a bővítési és csökkentési küszöbértékek között.

  • A manuális skálázás újra beállítása az automatikus skálázáshoz használt példányok maximális és minimális száma alapján 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 három és a hat közötti tartományt. Ha van egy futó példánya, az automatikus skálázási motor a következő futtatásakor három példányra növeli a számot. 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, a következő profilt ellenőrzi. Az alapértelmezett profilba ne helyezze a kulcsfontosságú metrikákat, mert ezt a profilt ellenőrzik utoljára. 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. Skála-leskálázás esetén az automatikus skálázásnál minden szabálynak teljesülnie kell.

    Az Azure Monitor skálázásával kapcsolatos további információké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, megadhat egy részletesebb ütemezést, amely során a szabályok aktívak. Saját metrikákat is létrehozhat, és használhatja őket az automatikus skálázási szabályok bármelyik meglévőjével vagy anélkül. Előfordulhat például, hogy alternatív számlálókat szeretne használni, például a másodpercenkénti kérések számát vagy az átlagos memória-rendelkezésre állást. Vagy egyéni számlálókat is használhat adott üzleti folyamatok mérésére.

  • Ha több szabályzatot és szabályt konfigurál, azok ütközhetnek egymással. Az automatikus skálázás a következő konfliktusmegoldási szabályokkal biztosítja, hogy mindig elegendő számú példány fusson.

    • A felskálázási műveletek mindig elsőbbséget élveznek a visszaská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.

    • A méretezési műveletek ütközése esetén a példányok számának legkisebb csökkenését kezdeményező szabály elsőbbséget élvez.

  • App Service-környezetben bármely feldolgozói készlet vagy front-end metrikák használhatók az automatikus skálázási szabályok meghatározására. További információ: App Service Environment – áttekintés.

Alkalmazástervezési szempontok

Az automatikus skálázás nem azonnali megoldás. Ha erőforrásokat ad hozzá egy rendszerhez vagy több folyamatpéldányt futtat, az nem garantálja a jobb teljesítményt. Az automatikus méretezési stratégia tervezésekor vegye figyelembe az alábbi szempontokat:

  • A rendszert vízszintesen skálázhatónak kell lennie. Kerülje a példány-affinitással kapcsolatos feltételezéseket. Ne tervezzen olyan megoldásokat, amelyek megkövetelik, hogy a kód mindig egy adott folyamatpéldányban fusson. Felhőszolgáltatás vagy webhely horizontális skálázása esetén ne feltételezze, hogy az ugyanabból a forrásból érkező kérések sorozata mindig ugyanarra a példányra lesz irányítva. Ugyanezen okból a tervezési szolgáltatások állapot nélkülinek kell lenniük, hogy ne követeljék meg, hogy egy alkalmazás kéréseinek sorozata mindig ugyanarra a szolgáltatáspéldányra legyen irányítva. Ha olyan szolgáltatást tervez, amely üzeneteket olvas be egy üzenetsorból, és feldolgozza őket, ne tegyen feltételezéseket arról, hogy a szolgáltatás melyik példánya kezeli az adott üzenetet. Az automatikus skálázás az üzenetsor hosszának növekedésével több szolgáltatáspéldányt is elindíthat. A konkurens fogyasztók mintája leírja, hogyan kell kezelni ezt a forgatókönyvet.

  • Ha a megoldás hosszan futó feladatot valósít meg, úgy tervezze meg ezt a feladatot, hogy támogassa a horizontális kinyitást és visszaskálázást is. Megfelelő tervezés nélkül egy ilyen feladat megakadályozhatja, hogy egy folyamat egy példánya tiszta módon le legyen állítva, amikor a rendszer felskálázódik. Vagy adatvesztést okozhat, ha a folyamat kényszerítetten leáll. Ideális esetben egy hosszú ideig futó feladat újrabontása és az általa végzett feldolgozás lebontása kisebb, különálló adattömbökre. Példa: Csövek és szűrők minta.

  • Másik lehetőségként olyan ellenőrzőpont-mechanizmust is implementálhat, amely rendszeres időközönként rögzíti a tevékenység állapotadatait. Mentse ezt az állapotinformációt tartós tárolóba, amelyhez a feladatot futtató folyamat bármely példánya hozzáférhet. Ha a folyamat leáll, a munka, amelyet végzett, egy másik példány használatával az utolsó ellenőrzőpontról folytatható. 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. Előfordulhat például, hogy több felhasználói felületi számítási példányt kell üzembe helyeznie anélkül, hogy növelné a háttérbeli számítási példányok számát, vagy ellenkezőleg. Különböző szolgáltatási szinteket kínálhat, például alapszintű és prémium szolgáltatási csomagokat. Előfordulhat, hogy a prémium szolgáltatási csomagok számítási erőforrásait agresszívabban kell felskáláznia, mint az alapszintű szolgáltatási csomagok erőforrásait. Ez a megközelítés segít az SLA-knak való megfelelésben.

Egyéb skálázási feltételek

  • Fontolja meg annak az üzenetsornak a hosszát, amelyen keresztül a felhasználói felület és a háttérben futó számítási folyamatok kommunikálnak. Használja az automatikus skálázási stratégiájának kritériumaként. Ez a feltétel kiegyensúlyozatlanságot vagy különbséget jelezhet az aktuális terhelés és a háttérfeladat feldolgozási kapacitása között. A skálázási döntések alapjául valamivel összetettebb, de jobb attribútum is van. 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 elfogadható üzleti tartományon belül van, akkor nem szükséges skálázni, még akkor is, ha az üzenetsor hossza hosszú.

    • Egy üzenetsorban például 50 000 üzenet lehet. A legrégebbi üzenet kritikus ideje azonban 500 ms, és ez a végpont egy partner webszolgáltatással való integrációval foglalkozik az e-mailek küldéséhez. Előfordulhat, hogy az üzleti érdekelt felek nem tartják elég sürgősnek ezt a forgatókönyvet a horizontális felskálázás költségeinek igazolásához.

    • Másrészt 500 üzenet lehet egy üzenetsorban, ugyanazzal az 500 ms kritikus idővel. A végpont azonban 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 kiterjesztésnek 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 kódtár automatikusan hozzáadja a releváns információkat az üzenetek fejlécéhez az átvitel és feldolgozás során. Az egyik ilyen kódtár, amely ezt a funkciót biztosítja, az NServiceBus.

  • Ha az automatikus skálázási stratégiát üzleti folyamatokat mérő számlálókra alapozza, győződjön meg arról, hogy tisztában van az ilyen típusú számlálók eredményei és a tényleges számítási kapacitásra vonatkozó követelmények közötti kapcsolatokkal. Számlálók például az óránként leadott rendelések száma vagy egy összetett tranzakció átlagos futási ideje. Előfordulhat, hogy egynél több összetevőt vagy számítási egységet kell skálázni az üzleti folyamatszámlálók változásaira reagálva.

  • Ha meg szeretné akadályozni, hogy a rendszer túlzott mértékű felskálázást kíséreljen meg, fontolja meg az automatikusan hozzáadható példányok maximális számának korlátozását. Ez a megközelítés a több ezer példány futtatásával járó költségeket is elkerüli. A legtöbb automatikus skálázási mechanizmus lehetővé teszi egy szabály példányainak minimális és maximális számának megadását. Emellett fontolja meg a rendszer által biztosított funkciók kecses romlását, ha a példányok maximális számát telepíti, és a rendszer továbbra is túlterhelt.

  • Ne feledje, hogy előfordulhat, hogy az automatikus skálázás nem a legmegfelelőbb mechanizmus a számítási feladatok hirtelen felgyülemléséhez. Időbe telik egy szolgáltatás új példányainak beállítása és elindítása, illetve erőforrások hozzáadása a rendszerhez. A csúcsigény pedig eltelhet, mire ezek a többleterőforrások rendelkezésre állnak. Ebben a forgatókönyvben jobb lehet a szolgáltatás korlátozása. További információ: Korlátozási minta.

  • Ezzel szemben, ha az összes kérés feldolgozásához kapacitásra van szüksége, amikor a terhelés gyorsan változik, fontolja meg egy agresszív automatikus skálázási stratégia használatát, amely gyorsabban indítja a további példányokat. Győződjön meg arról, hogy a költség nem jelentős tényező. Ütemezett irányelvet is használhat, amely elegendő számú példányt indít el a terhelés maximális értékének teljesítése érdekében, még mielőtt a terhelés elérné azt az értéket.

  • Az automatikus skálázási mechanizmusnak figyelnie kell az automatikus skálázási folyamatot, és naplóznia kell az egyes automatikus skálázási események részleteit. Ezek a részletek magukban foglalják az esemény kiváltó okát, az erőforrások hozzáadását vagy eltávolítását, valamint azt, hogy mikor történt. Ha egyéni automatikus skálázási mechanizmust hoz létre, győződjön meg arról, hogy ez magában foglalja ezt a képességet. Elemezze az információkat az automatikus skálázási stratégia hatékonyságának méréséhez és szükség esetén finomhangolásához. Rövid távon mindkettőt finomhangolhatja, mivel a használati minták egyre nyilvánvalóbbá válnak, és hosszú távon az üzlet bővülése vagy az alkalmazás követelményeinek fejlődése során. Ha egy alkalmazás eléri az automatikus skálázáshoz megadott felső korlátot, a mechanizmus riasztást is kaphat egy operátorról, aki szükség esetén manuálisan indíthat el további erőforrásokat. Ilyen körülmények között az operátor felelős lehet az erőforrások manuális eltávolításáért is, 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:

  • A szabályozási minta azt ismerteti, hogyan működhet tovább egy alkalmazás, és hogyan felel meg az SLA-knak, amikor az igények növekedése rendkívüli terhelést okoz az erőforrásokon. A terhelésvezérlés együtt alkalmazható az automatikus skálázással annak érdekében, hogy a rendszer ne legyen túlterhelt, miközben a rendszer felskálázódik.

  • A versengő fogyasztók mintája leírja, hogyan implementálhat olyan szolgáltatáspéldány-készletet, amely képes kezelni az alkalmazáspéldányok üzeneteit. Az automatikus skálázással elindíthatja és leállíthatja a szolgáltatáspéldányokat a várt számítási feladatnak megfelelően. Ez a módszer lehetővé teszi, hogy a rendszer egyszerre több üzenetet is feldolgozva optimalizálja az átviteli sebességet, javítsa a méretezhetőséget és a rendelkezésre állást, és egyensúlyba hozhassa a számítási feladatot.

  • A monitorozás és a diagnosztikák, beleértve a rendszerállapotokat és a metrikákat, elengedhetetlenek az automatikus skálázási folyamatot hajtó információk összegyűjtéséhez.

  • Utolsó frissítés időpontja: