Javaslatok megbízható skálázási stratégia kialakításához
Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslat:
| RE:06 | Időben és megbízható skálázási stratégiát valósít meg az alkalmazás, az adatok és az infrastruktúra szintjén. |
|---|
Kapcsolódó útmutató: Adatparticionálás
Ez az útmutató a megbízható skálázási stratégia kialakítására vonatkozó javaslatokat ismerteti.
Meghatározások
| Időszak | Definíció |
|---|---|
| Vertikális skálázás | Skálázási módszer, amely számítási kapacitást ad hozzá a meglévő erőforrásokhoz. |
| Horizontális skálázás | Egy skálázási módszer, amely egy adott típusú erőforrás példányait adja hozzá. |
| Automatikus skálázás | Olyan skálázási módszer, amely automatikusan hozzáad vagy eltávolít erőforrásokat egy adott feltétel teljesülése esetén. |
Feljegyzés
A skálázási műveletek lehetnek statikusak (rendszeresen ütemezett napi skálázás a normál terhelési mintáknak megfelelően), automatikus (automatikus folyamat a feltételek teljesülése esetén), vagy manuális (egy operátor egyszeri skálázási műveletet hajt végre egy váratlan terhelésváltozásra reagálva). A függőleges és a vízszintes skálázás is elvégezhető ezen módszerek bármelyikével. Az automatikus vertikális skálázás azonban további egyéni automatizálási fejlesztést igényel, és állásidőt okozhat a skálázott erőforrásoktól függően.
Főbb tervezési stratégiák
Tervezés terhelési minták szerint
Ha megbízható skálázási stratégiát szeretne tervezni a számítási feladatokhoz, koncentráljon a felhasználói és rendszerfolyamatok terhelési mintáinak azonosítására minden olyan számítási feladathoz, amely skálázási művelethez vezet. Íme néhány példa a különböző terhelési mintákra:
Statikus: Minden este 11:00 EST-ig az aktív felhasználók száma 100 alatt van, és az alkalmazáskiszolgálók processzorhasználata 90%-kal csökken az összes csomóponton.
Dinamikus, rendszeres és kiszámítható: Hétfő reggelente több régióban 1000 alkalmazott jelentkezik be az ERP-rendszerbe.
Dinamikus, szabálytalan és kiszámítható: A termékindítás a hónap első napján történik, és a korábbi indítások előzményadatai arról szólnak, hogy ezekben a helyzetekben hogyan nő a forgalom.
Dinamikus, szabálytalan és kiszámíthatatlan: A nagy léptékű események miatt megnő a termék iránti kereslet. Például a párátlanítókat gyártó és értékesítő vállalatok hirtelen megnövekedett forgalmat tapasztalhatnak egy hurrikán vagy más árvízesemény után, amikor az érintett területeken lévő embereknek otthonukban kell száraz helyiségeket használniuk.
Miután azonosította az ilyen típusú terhelési mintákat, a következőkre van lehetőség:
Azonosítsa, hogy az egyes mintákhoz társított terhelésváltozás hogyan befolyásolja az infrastruktúrát.
Automatizálás létrehozása a skálázás megbízható kezelése érdekében.
Az előző példákban a skálázási stratégiák a következőek lehetnek:
Statikus: A számítási csomópontok ütemezett skálája a minimális számra (2) 11:00 és 18:00 óra közötti időpontra van ütemezve.
Dinamikus, rendszeres és kiszámítható: A számítási csomópontok ütemezett skálázása a normál napi kapacitásra van kiállítva, mielőtt az első régió elkezdené a munkát.
Dinamikus, szabálytalan és kiszámítható: A termékindítás reggelén a számítási és adatbázispéldányok egyszeri ütemezett vertikális felskálázását határozza meg, és egy hét után visszaskálázhatja a skálázást.
Dinamikus, szabálytalan és kiszámíthatatlan: Automatikus skálázási küszöbértékek vannak meghatározva, amelyek figyelembe veszik a nem tervezett forgalomnövekedéseket.
Skálázási stratégiák automatizálása
A skálázási automatizálás tervezésekor mindenképpen figyelembe kell vennie az alábbi problémákat:
A számítási feladat minden összetevőjének alkalmasnak kell lennie a skálázás implementálására. A legtöbb esetben a globális szolgáltatások, például a Microsoft Entra ID automatikusan és átláthatóan méretezhetőek Ön és ügyfelei számára. Ügyeljen arra, hogy tisztában legyen a hálózati bejövő és kimenő vezérlők skálázási képességeivel, valamint a terheléselosztási megoldással.
Azok az összetevők, amelyek nem méretezhetők fel. Ilyenek például a nagy méretű, relációs adatbázisok, amelyek nem engedélyezve vannak a horizontális skálázásban, és jelentős hatás nélkül nem lehet újrabontásra. Dokumentálja a felhőszolgáltató által közzétett erőforráskorlátokat, és figyelje szorosan ezeket az erőforrásokat. Vegye fel ezeket az erőforrásokat a skálázható szolgáltatásokba való migrálás jövőbeli tervezésében.
A skálázási művelet végrehajtásához szükséges idő, hogy megfelelően ütemezze a műveletet, mielőtt a többletterhelés eléri az infrastruktúrát. Ha például egy olyan összetevő, mint az API Management 45 percet vesz igénybe, a skálázási küszöbérték 90% helyett 65%-ra való beállítása segíthet a korábbi méretezésben, és felkészülhet a várható terhelésnövekedésre.
A folyamat összetevőinek kapcsolata a skálázási műveletek sorrendjében. Győződjön meg arról, hogy nem túlterheli véletlenül az alárendelt összetevőket egy felsőbb rétegbeli összetevő skálázásával.
Minden állapotalapú alkalmazáselem, amelyet a skálázási művelet és a implementált munkamenet-affinitás (vagy munkamenet-ragadás) szakíthat meg. A ragadósság korlátozhatja a skálázási képességet, és egyetlen meghibásodási pontot vezet be.
Lehetséges szűk keresztmetszetek. A horizontális felskálázás nem old meg minden teljesítményproblémát. Ha például a háttéradatbázis szűk keresztmetszetet jelent, az nem segít további webkiszolgálók hozzáadásában. Először azonosítsa és oldja fel a rendszerben jelentkező szűk keresztmetszeteket, mielőtt csak további példányokat ad hozzá. A szűk keresztmetszeteket általában a rendszer állapottal rendelkező összetevői okozzák.
Az üzembehelyezési bélyeg tervezési mintájának követése segít az általános infrastruktúra-kezelésben. A skálázási terv bélyegekre való alapozása méretezési egységekként is előnyös. Emellett segít a skálázási műveletek szigorú szabályozásában több számítási feladat és a számítási feladatok részhalmazai között. Ahelyett, hogy számos különböző erőforrás skálázási ütemezését és automatikus méretezési küszöbértékeit kezelnék, korlátozott skálázási definíciókat alkalmazhat az üzembehelyezési bélyegzőkre, majd szükség szerint tükrözheti a bélyegek között.
Kompromisszumok: A vertikális felskálázásnak költségvonzatai vannak, ezért optimalizálja a stratégiát, hogy a lehető leghamarabb leskálázza a skálázást, hogy segítsen a költségek szabályozásában. Győződjön meg arról, hogy a vertikális felskálázáshoz használt automatizálás eseményindítókkal is rendelkezik a vertikális felskálázáshoz.
Az Azure megkönnyítése
Az automatikus skálázási funkció számos Azure-szolgáltatásban elérhető. Lehetővé teszi a feltételek egyszerű konfigurálását a példányok horizontális automatikus skálázásához. Egyes szolgáltatások beépített funkciói korlátozottak vagy nincsenek automatikusan skálázhatóak, ezért mindenképpen dokumentálja ezeket az eseteket, és határozza meg a skálázás kezelésére használható folyamatokat.
Számos Azure-szolgáltatás kínál olyan API-kat, amelyekkel egyéni automatikus skálázási műveleteket tervezhet az Azure Automation használatával, például az Azure IoT Hub automatikus méretezéséhez használt kódmintákat. Az eseményvezérelt automatikus skálázáshoz használhat olyan eszközöket, mint a KEDA, amely az Azure Kubernetes Service-ben és az Azure Container Appsben érhető el.
Az Azure Monitor automatikus skálázása az Azure-beli virtuálisgép-méretezési csoportok, a Azure-alkalmazás szolgáltatás, az Azure Spring Apps és egyebek közös automatikus skálázási funkcióját 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. Az ajánlott eljárásokért tekintse meg az Azure Monitor útmutatót .
Kompromisszumok
Automatikus skálázá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. 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 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ás az üzenetsor hosszának növekedésével több szolgáltatáspéldányt is elindíthat. 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. Kellő gondosság nélkül egy ilyen feladat megakadályozhatja, hogy egy folyamat egy példánya teljesen le legyen állítva, amikor a rendszer felskálázódik. Vagy adatvesztést is okozhat, ha a folyamat kényszerítetten leáll. 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 a megoldást.
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. Ezt az állapotot ezután tartós tárolóba mentheti, amely a feladatot futtató folyamat bármely példánya számára elérhető. Ily módon, ha a folyamat le van állítva, az elvégzett munkát egy másik példány folytathatja 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. Előfordulhat például, hogy további felhasználói felületi (UI) számítási példányokat kell üzembe helyeznie anélkül, hogy növelné a háttérbeli számítási példányok számát, vagy fordítva. Ha különböző szolgáltatási szinteket kínál, 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 esetében a szolgáltatásiszint-szerződések (SLA-k) teljesítéséhez.
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 a probléma az egyik lehetséges mutatója a háttérfeladat aktuális terhelése és feldolgozási kapacitása közötti egyensúlyhiánynak vagy különbségnek. A skálázási döntések alapjául szolgáló valamivel összetettebb, de jobb attribútum az üzenet elküldése és a feldolgozás befejezése közötti idő használata. Ezt az időközt kritikus időnek nevezzük. Ha ez a kritikus időérték egy jelentős üzleti küszöbérték alatt van, akkor felesleges 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 a végpont egy külső webszolgáltatással való integrációval foglalkozik az e-mailek küldéséhez. Az üzleti érdekelt felek ezt valószínűleg olyan időszaknak tekintik, amely nem indokolná a skálázásra fordított többletköltséget.
Másfelől 500 üzenet lehet egy üzenetsorban ugyanazzal az 500 ms-os kritikus idővel, de a végpont a kritikus út része egy valós idejű online játékban, ahol az üzleti érdekelt felek 100 ms-os vagy annál kisebb válaszidőt határoztak meg. Ebben az esetben a horizontális felskálázásnak van értelme.
Ha kritikus időt szeretne használni az automatikus skálázási döntésekhez, hasznos lehet, ha egy tár automatikusan hozzáadja a releváns információkat az üzenetek fejlécéhez az üzenetek elküldése és feldolgozása során. A funkciót biztosító egyik kódtár az NServiceBus.
Ha az automatikus skálázási stratégiát olyan számlálókra alapozza, amelyek az üzleti folyamatokat mérik, például az óránként leadott rendelések számát vagy egy összetett tranzakció átlagos futási idejét, győződjön meg arról, hogy teljes mértékben tisztában van az ilyen típusú számlálók eredményei és a tényleges számítási kapacitás követelményei közötti kapcsolatokkal. 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.
Annak érdekében, hogy a rendszer ne próbálja meg túlzottan felskálázni a skálázást, és hogy elkerülje a sok ezer példány futtatásával járó költségeket, fontolja meg az automatikusan hozzáadott példányok maximális számának korlátozását. 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áma üzembe lett helyezve, és a rendszer még mindig 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 kirobbanásának kezelésére. Időt vesz igénybe egy szolgáltatás új példányainak kiépítése és elindítása, vagy erőforrások hozzáadása egy rendszerhez, és a maximális igény a további erőforrások rendelkezésre állásának idejére is áttelhet. Ebben a forgatókönyvben jobb lehet a szolgáltatás szabályozása. További információkért tekintse meg a szabályozás mintáját.
Ezzel szemben, ha az összes kérés feldolgozásához kapacitásra van szüksége, amikor a kötet gyorsan ingadozik, és a költség nem jelentős tényező, fontolja meg egy agresszív automatikus skálázási stratégia használatát, amely gyorsabban indít el több példányt. 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 figyelnie kell az automatikus skálázási folyamatot, és naplóznia kell az egyes automatikus skálázási események részleteit (mi aktiválta, milyen 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 meghatározott felső korlátot, a mechanizmus riasztást is kaphat egy operátorról, aki szükség esetén manuálisan indíthat el több erőforrást. 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.
Példa
Tekintse meg az AKS referenciaarchitektúra skálázási útmutatóját.
Kapcsolódó hivatkozások
Megbízhatósági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.