Javaslatok megbízható skálázási stratégia kialakításához
Erre az Azure Well-Architected Framework megbízhatósági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
| 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.
Definíciók
| Időszak | Definíció |
|---|---|
| Vertikális skálázás | Egy 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, amikor teljesülnek a feltételek. |
Megjegyzé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 (automatizált 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 ezen módszerek bármelyikével elvégezhető. Az automatikus vertikális skálázás azonban további egyéni automatizálási fejlesztést igényel, és a skálázott erőforrásoktól függően állásidőt okozhat.
Fő tervezési stratégiák
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űveletet eredményez. Í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 cpu-kihasználtsága 90%-kal csökken az összes csomóponton.
Dinamikus, rendszeres és kiszámítható: Minden hétfő reggel 1000 alkalmazott jelentkezik be több régióban az ERP-rendszerbe.
Dinamikus, szabálytalan és kiszámítható: A termékbevezetés a hónap első napján történik, és a korábbi indítások előzményadatai arra vonatkozóak, hogy ezekben a helyzetekben hogyan nő a forgalom.
Dinamikus, szabálytalan és kiszámíthatatlan: A nagy léptékű események kiugró keresletet okoznak egy termék iránt. A párátlanítókat gyártó és értékesítő vállalatok például 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 kiszáradniuk a szobákat.
Miután azonosította az ilyen típusú terhelési mintákat, a következőkre van lehetőség:
Határozza meg, 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ők lehetnek:
Statikus: A számítási csomópontok ütemezett skálája a minimális számra (2) 11:00 és 06:00 óra között van.
Dinamikus, rendszeres és kiszámítható: A számítási csomópontok ütemezett felskálázása a normál napi kapacitásra az első régió működésének megkezdése előtt történik.
Dinamikus, szabálytalan és kiszámítható: A termék megjelenésének reggelén definiálja a számítási és adatbázispéldányok egyszeri ütemezett vertikális felskálázását, é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, hogy figyelembe vegyék a nem tervezett forgalomcsúcsokat.
A skálázási automatizálás tervezésekor mindenképpen figyelembe kell vennie az alábbi problémákat:
Azt, hogy 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 az Microsoft Entra azonosító automatikusan és átláthatóan skálázhatók Ön és ügyfelei számára. Ügyeljen arra, hogy tisztában legyen a hálózati bejövő és kimenő forgalom vezérlőinek 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, amelyeken nincs engedélyezve a horizontális skálázás, és nem lehet jelentős hatás nélkül újrabontást alkalmazni. Dokumentálja a felhőszolgáltató által közzétett erőforráskorlátokat, és szorosan monitorozza ezeket az erőforrásokat. A skálázható szolgáltatásokra való migrálás jövőbeni tervezésében vegye fel ezeket az erőforrásokat.
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 API Management összetevő skálázása 45 percet vesz igénybe, a skálázási küszöbérték 90% helyett 65%-ra való módosítása segíthet a korábbi skálázásban, é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 kell véletlenül túlterhelni egy alsóbb rétegbeli összetevőt egy felsőbb rétegbeli összetevő skálázásával.
A skálázási művelet és a megvalósított munkamenet-affinitás (vagy munkamenet-ragadósság) által megszakítható állapotalapú alkalmazáselemek. 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 a szűk keresztmetszet, nem segít további webkiszolgálók hozzáadásában. Először azonosítsa és oldja meg 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 üzembe helyezési bélyeg tervezési mintájának követése segít az infrastruktúra általános felügyeletében. A skálázási tervezés 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 skálázá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 azokat a bélyegek között.
Kompromisszum: 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 is rendelkezik eseményindítókkal a vertikális leskálázáshoz.
Azure-beli facilitálás
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 vízszintes automatikus skálázásához. Egyes szolgáltatásokban korlátozottak vagy nincsenek beépített funkciók az automatikus skálázáshoz, ezért mindenképpen dokumentálja ezeket az eseteket, és definiáljon folyamatokat a skálázás kezeléséhez.
Számos Azure-szolgáltatás kínál olyan API-kat, amelyekkel egyéni automatikus skálázási műveleteket tervezhet Azure Automation használatával, például a Azure IoT Hub automatikus skálázási kódmintáit. A KEDA-hoz hasonló eszközöket használhat az eseményvezérelt automatikus skálázáshoz, amely Azure Kubernetes Service és az Azure Container Appsben érhető el.
Az Azure Monitor automatikus skálázása az Azure Virtual Machine Scale Sets, Azure App Service, Az Azure Spring Apps és egyebek közös automatikus skálázási funkciókészleté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ásokat az Azure Monitor útmutatójában találja.
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ányon fusson. Egy felhőszolgáltatás vagy webhely horizontális skálázása során ne feltételezzük, 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 a szolgáltatás több példányát is elindíthatja az üzenetsor hosszának növekedésével. 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 tiszta módon le legyen állítva, amikor a rendszer felskálázódik. Vagy adatvesztést okozhat, ha a folyamat kényszerített módon 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 bemutatja, hogyan érhető el ez a megoldás.
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 időközök igazodnak a Azure Service Bus üzenetsorokból érkező üzenetek feldolgozásához.
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 a háttérbeli számítási példányok számának növelése nélkül, 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.
Vegye figyelembe annak az üzenetsornak a hosszát, amelyen keresztül a felhasználói felület és a háttérbeli 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 a háttérfeladat aktuális terhelése és feldolgozási kapacitása közötti egyensúlyhiány vagy különbség egyik lehetséges mutatója. 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 nincs szükség skálázásra, még akkor is, ha az üzenetsor hossza hosszú.
Egy üzenetsor például 50 000 üzenetet tartalmazhat. 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ásrészt 500 üzenet lehet egy üzenetsorban, ugyanazzal az 500 ms 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 rövidebb válaszidőt határoznak 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ásra vonatkozó követelmények 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 folyamat számlálóinak változásaira reagálva.
Ha meg szeretné akadályozni, hogy egy rendszer túlzottan felskálázzon, és elkerülje a több ezer példány futtatásával járó költségeket, érdemes lehet korlátozni az automatikusan hozzáadott példányok maximális számá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 érdemes megfontolni a rendszer által biztosított funkciók zökkenőmentes csökkentését, ha a példányok maximális száma üzembe lett helyezve, é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 növekedésének kezeléséhez. Időbe telik 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 többleterőforrások rendelkezésre állásának idejére a csúcsigény is áttelhet. Ebben a forgatókönyvben jobb megoldás lehet a szolgáltatás szabályozása. További információ: Szabályozási minta.
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ő, érdemes lehet agresszív automatikus skálázási stratégiát használni, 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 figyelmeztethet egy operátort is, 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 is felelős lehet az erőforrások manuális eltávolításáért a számítási feladat megkönnyítése után.
Példa
Tekintse meg az AKS alapkonfiguráció referenciaarchitektúrájának 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.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: