Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az Azure Well-Architected-keretrendszer 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. A skálázási stratégiát a tényleges vagy előrejelzett használati mintákra alapozhatja, és minimalizálhatja a manuális beavatkozást. |
---|
Ez az útmutató a megbízható skálázási stratégia kialakítására vonatkozó javaslatokat ismerteti.
Definíciók
Kifejezés | Definíció |
---|---|
Függőleges 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. |
Vízszintes 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. |
Jegyzet
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.
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 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 .
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 és a hozzájuk tartozó skálázási stratégiákra:
Statikus: Minden este 11:00 EST-ig az alkalmazás aktív felhasználóinak száma 100 alá csökken, és az alkalmazáskiszolgálók processzorhasználata 90% csökken az összes csomóponton. Ennek kezeléséhez ütemezheti a számítási csomópontok minimális számát (2) 11:00 és 18:00 óra között.
Dinamikus, reguláris és kiszámítható: Minden hétfő reggel több régióban 1000 alkalmazott jelentkezik be az ERP rendszerbe. Ennek kezeléséhez ütemezheti a számítási csomópontok felskálázását a normál napi kapacitásra, mielőtt az első régió elkezdené a munkát.
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, hogyan nő a forgalom ezekben a helyzetekben. Ennek megoldásához definiálhatja a számítási és adatbázispéldányok egyszeri ütemezett felskálázását egy termékindítás reggelén, és egy hét után visszaskálázhatja a skálázást.
Dinamikus, szabálytalan és kiszámíthatatlan: A nagy léptékű események miatt megnő a termék iránti kereslet. 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 az embereknek meg kell szárítsanak helyiségeket az otthonukban. Ennek kezeléséhez beállíthatja az automatikus skálázási küszöbértékeket úgy, hogy figyelembe vegyék a nem tervezett forgalomcsúcsokat.
Skálázási stratégiák adaptálása az egyes összetevőkhöz vagy folyamatokhoz
Nincs egyetlen méretre illeszkedő skálázási stratégia sem. A különböző felhőszolgáltatások különböző mértékben támogatják a skálázást és a skálázás különböző megközelítéseit. Ezért fontos tisztában lenni azzal, hogy a skálázás hogyan támogatott és implementálható az összes számítási feladat-összetevőben az általános skálázási stratégia kialakításához. Az architektúratervtől függően skálázási stratégiákat alkalmazhat az egyes összetevők szintjén vagy a folyamat szintjén. A számítási feladatok skálázási implementálásának meghatározásakor vegye figyelembe az alábbi tényezőket:
Azokat az összetevőket, amelyek nem méretezhetők ki. 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 folyamat összetevőinek viszonya 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.
Bármely állapottal rendelkező alkalmazáselem, amelyet egy skálázási művelet megszakíthat, és minden implementált munkamenet-affinitás (vagy munkamenet-ragadás). A ragadósság korlátozhatja a skálázási képességet, és egyetlen meghibásodási pontot vezet be. Úgy tervezheti meg a számítási feladatokat, hogy a gyakorlatban is állapot nélküliek legyenek.
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, ahelyett, hogy egyszerűen több példányt hozzáadna. A szűk keresztmetszetek legvalószínűbb oka a rendszer állapotfüggő részei.
Hosszú ideig futó feladatok kezelése. Hosszú ideig futó feladat tervezése a horizontális felskálázás és a skálázás támogatásához. 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 egy hosszú ideig futó feladat újrabontása és az általa végzett feldolgozás lebontása kisebb, különálló adattömbökre. A csövek és szűrők mintája egy példa a megoldás elérésére.
A megfelelő technológia kiválasztása
Ha jól megalapozott technológiai döntéseket hoz a skálázás szem előtt tartásával, azzal biztosíthatja, hogy a számítási feladatok a számítási feladatok fejlődése során megfeleljenek a megbízhatósági céloknak. Vizsgálja meg a különböző erőforrásokhoz kínált skálázási képességeket, amelyek hasonló funkciókat kínálnak, és válassza ki a legjobb kombinációt a jövőbeli növekedési tervekhez. Előfordulhat például, hogy több olyan adattárat is használhat, amelyek a használni kívánt adatbázis-típust üzemeltethetik. Előfordulhat azonban, hogy egy választás jobb skálázási funkciókat biztosít, mint mások, ami jobb választás lehet a számítási feladat számára.
Használja ki az automatikusan skálázható szolgáltatásokat. Gyakorlati esetben olyan SaaS-szolgáltatásokat használjon, amelyek konfiguráció vagy bemenet nélkül automatikusan méretezhetők. Az olyan globális szolgáltatások, mint a Microsoft Entra ID , ezt a funkciót kínálják. A kiszolgáló nélküli megoldások automatikus skálázást is kínálnak, és számos használati esetben jó választás lehet.
Használja ki a beépített skálázást kínáló szolgáltatásokat. Számos PaaS-szolgáltatás integrált, könnyen használható skálázási funkciókat kínál, amelyeket a megbízhatósági követelményeknek megfelelően konfigurálhat. Konfigurálhatja például az átviteli sebesség skálázását a Cosmos DB-hez az adott követelményeknek megfelelően.
Skálázás automatizálása
Automatizálja a számítási feladatok összetevőinek méretezési műveleteit a gyakorlatiasság érdekében. Konfigurálható automatikus skálázási funkcióval rendelkező erőforrások használatakor hozza létre a konfigurációs logikát az infrastruktúra kódként (IaC) üzembehelyezési kódjába. Ha olyan erőforrásokat használ, amelyek nem rendelkeznek automatikus skálázási lehetőségekkel, az automatizálás natív automatizálási eszközökkel történő skálázási műveletek végrehajtásához, és az automatizálási kód belefoglalása az IaC-kódba.
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.
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 korlátozása. További információ: Teljesítménykorlátozási minta.
Ezzel szemben, ha kapacitásra van szüksége az összes kérés feldolgozásához, amikor a forgalom gyorsan ingadozik, és a költség nem jelentős szempont, fontolja meg egy agresszív automatikus skálázási stratégia használatát, amely gyorsabban elindít több példányt. Ü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.
A megfelelő méretezési egységek kiválasztása
A skálázási stratégiát skálázási egységekre alapozza, amelyek a skálázható összetevők logikai csoportosítása és a használni kívánt méretezési növekmények (például az egyik virtuálisgép-termékváltozatról a másikra való áttérés). A megfontolandó lehetőségek a következők:
Erőforrások egyenkénti skálázása: Előfordulhat, hogy csak az egyes virtuális gépeket vagy adatbázisokat kell skáláznia.
Teljes összetevő skálázása egyszerre: Előfordulhat például, hogy rendelkezik egy olyan mikroszolgáltatási API-val, amely egy App Service-ből, adatbázisból és üzenetsorokból áll, amelyeket egyszerre kell skálázni.
A teljes megoldás skálázása: Összetett vagy kritikus fontosságú számítási feladatok esetén a teljes megoldás üzembehelyezési bélyegként való skálázása leegyszerűsítheti a skálázási stratégiát. 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.
Fontos
Állítsa be az automatikusan lefoglalható méretezési egységek maximális számát a többletköltségek elkerülése érdekében.
A méretezési egység inicializálási idejének optimalizálása
A skálázási stratégia tervezésekor vegye figyelembe, hogy a különböző szolgáltatások különböző időskálákon skálázhatók. Vannak olyan szolgáltatások, amelyek szinte azonnal skálázhatók, más szolgáltatások pedig sokkal lassabban skálázhatók. Az API Management-példányok például akár 45 percet is igénybe vehetnek a skálázási műveletek befejezéséhez. A skálázási művelet időskálázásának figyelembe vételéhez megfelelően tervezze meg a méretezési műveletet, mielőtt a várható megnövekedett terhelés eléri a számítási feladatot. További megfontolandó javaslatok:
Az inicializáláshoz szükséges idő csökkentése érdekében üzembe helyezett csomópontok előzetes inicializálása.
Adjon meg pufferidőt a konfigurációs módosítások körül, mielőtt további módosításokat hajt végre, vagy szokatlan módon használja a rendszert. Előfordulhat például, hogy szabálymódosítással felszabadít egy App Gateway-háttérpéldányt. Meg kell várnia, amíg a kapcsolatok kiürülnek az adott példányból, mielőtt biztonságosan eltávolítható lenne.
Erőforrások túlkiosztása a skálázás során megnövekedett terhelés kezelésére. Előfordulhat, hogy a virtuális gépek általában 75% kihasználtsági kapacitáson futnak, hogy a horizontális skálázás során a nagyobb terhelést is kezelni tudják.
A skálázási küszöbértékek finomhangolása monitorozással. A kapacitásmonitorozással biztosíthatja, hogy a méretezési küszöbértékek aktiválják a skálázási műveleteket.
Adattárak skálázása horizontális skálázással és particionálással
Az adattulajdon megbízhatóságának optimalizálásához foglalja bele azokat a skálázási stratégiába. Az adatok particionálása az adatbázist logikai vagy fizikai tárolási erőforrások között szórja szét, így egyetlen hibapontot távolít el. Válassza ki a használati eset legjobb particionálási stratégiáját.
Horizontális particionálás (szegmensek):: A partíciók (szegmensek) külön adattárakban vannak elhelyezve, de minden partíció ugyanazt a sémát használja. Minden szegmens az adatbázis egy részhalmazát tartalmazza. Ez egy jó módszer a megbízhatóság optimalizálására, mivel megkönnyíti a terheléselosztást, és minimalizálja a műveletekre nehezedő terheket a problémák kezelése során. A szegmensek replikálhatók a nagyobb megbízhatóság érdekében.
Függőleges particionálás: Minden partíció az adattár elemeinek mezőinek egy részét tartalmazza. A mezők a használati mintájuknak megfelelően vannak elosztva.
Funkcionális particionálás: Az adatok összesítése annak megfelelően történik, hogy a rendszer minden egyes kötött környezete hogyan használja fel az adatokat.
Érdemes kombinálni ezeket a stratégiákat particionálási séma tervezésekor. Az adatokat például szegmensekre oszthatja, majd függőleges particionálással tovább oszthatja az egyes szegmensekben lévő adatokat.
Optimalizálja a partíciós stratégiát a méretezhetőség érdekében. Elemezze az adathozzáférési mintákat annak meghatározásához, hogy mely műveletek igénylik a legtöbb feldolgozási erőforrást, és egyensúlyozza a partíciókat annak biztosítása érdekében, hogy mindegyik elegendő erőforrással rendelkezzen a méretezhetőségi követelmények kezeléséhez.
A particionálással és a horizontális felosztással kapcsolatos részletes útmutatásért tekintse meg a tervezési útmutatót
A skálázási műveletek figyelése
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). 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. Proaktívan 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.
Az Azure megkönnyítése
Az automatikus skálázási funkció számos Azure-szolgáltatásbanérhető el. 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 Azure Automationhasználatával, például az Azure IoT Hub automatikus méretezésénekkódmintáit. Az eseményvezérelt automatikus skálázáshoz használhat olyan eszközöket, mint a KEDA, amely Azure Kubernetes Service és Azure Container Appsérhető el.
Az Azure Monitor automatikus skálázási funkciókat biztosít az Azure Virtual Machine Scale Sets, az Azure App Service, az Azure Spring Apps és más szolgáltatások számára. 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.
Kompromisszumokat
Kompromisszum: A felskálázás költségvonzatokkal jár, ezért optimalizálja a stratégiát, hogy a lehető leghamarabb csökkentse a skálázást, és segítse a költségek szabályozását. Győződjön meg arról, hogy a felskálázáshoz használt automatizálás rendelkezik olyan eseményindítókkal, amelyek a le- és felskálázást egyaránt lehetővé teszik.
Példa
Tekintse meg az AKS referenciaalapú architektúráját és a skálázási útmutatót.
Kapcsolódó hivatkozások
Megbízhatósági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.