Szabályozhatja egy alkalmazáspéldány, egyéni bérlő vagy teljes szolgáltatás által használt erőforrások felhasználását. Ez a minta lehetővé teszi, hogy a rendszer tovább működjön és teljesítse a szolgáltatói szerződések feltételeit akkor is, ha az erőforrásigény növekedése rendkívüli terhelést jelent az erőforrások számára.
Kontextus és probléma
A felhőalkalmazások terhelése általában az aktív felhasználók számától vagy az általuk végzett tevékenységek típusától függően változik. Például valószínűleg több felhasználó lesz aktív munkaidőben, vagy lehet, hogy a rendszernek nagy számítási igényű elemzéseket kell végeznie minden hónap végén. Hirtelen és váratlan tevékenységcsúcsok is előfordulhatnak. Ha a rendszer feldolgozási követelményei meghaladják a rendelkezésre álló erőforrások kapacitását, az a rendszer gyenge teljesítményét vagy meghibásodását okozhatja. Ha a rendszernek egy megállapodott szolgáltatási szintet kell teljesítenie, az ilyen meghibásodás nem fogadható el.
Az alkalmazás üzleti céljaitól függően számos stratégia érhető el a felhőben a különböző terhelések kezelésére. Az egyik stratégia az automatikus skálázás használata a kiosztott erőforrásoknak a felhasználó igényeihez való igazodásához bármikor. Ez lehetővé teszi a felhasználói igényeknek való folyamatos megfelelést és a futtatási költségek optimalizálását. Bár az automatikus skálázás több erőforrás kiépítését is kiválthatja, ez a kiépítés nem azonnali. Ha az igények gyorsan növekednek, előfordulhat, hogy bizonyos ideig erőforráshiány lép fel.
Megoldás
Az automatikus skálázás alternatívája, ha az alkalmazások egy adott határig használhatják az erőforrásokat, és ha elérték ezt a határt, a rendszer szabályozza őket. A rendszernek monitoroznia kell az erőforrások felhasználását, így amikor az erőforrás-használat túllépi a küszöbértéket, szabályozhatja az egy vagy több felhasználótól érkező kérelmeket. Ez lehetővé teszi, hogy a rendszer továbbra is működjön, és megfeleljen a érvényben lévő szolgáltatásiszint-szerződéseknek (SLA-k). Az erőforrás-használat monitorozásával kapcsolatos további információkért tekintse meg a rendszerállapottal és a telemetriával kapcsolatos útmutatást.
A rendszer számos szabályozási stratégiát implementálhat, többek között a következőket:
Olyan egyéni felhasználóktól érkező kérelmek visszautasítása, akik másodpercenként több mint n-szer fértek hozzá a rendszer API-jaihoz egy adott időtartamban. Ehhez a rendszernek mérnie az egy adott alkalmazást futtató összes bérlő vagy felhasználó erőforrás-felhasználását. További információkért tekintse meg a szolgáltatások mérésével kapcsolatos útmutatót.
Bizonyos nem létfontosságú szolgáltatások működésének letiltása vagy csökkentése annak érdekében, hogy a létfontosságú szolgáltatások akadálytalanul, elegendő erőforrással futhassanak. Ha például az alkalmazás videókimenetet streamel, alacsonyabb felbontásra válthat.
A tevékenységek mennyiségének egyenletessé tétele terheléskiegyenlítés használatával (erről a megközelítésről bővebben az üzenetsor-alapú terheléskiegyenlítési mintával kapcsolatos részben olvashat). Több-bérlős környezetben ez a megközelítés minden bérlő teljesítményét csökkenti. Ha a rendszernek különböző SLA-kkal rendelkező bérlőket kell kiszolgálnia, az értékes bérlők műveletei azonnal végrehajthatóak. Más bérlők kérelmei visszatarthatóak addig, amíg a várólista ki nem ürült. A prioritási üzenetsor mintája segítheti a megközelítés megvalósítását, valamint különböző végpontokat tárhat fel a különböző szolgáltatási szintekhez/prioritásokhoz.
Az alacsonyabb prioritású alkalmazások vagy bérlők nevében végrehajtott műveletek elhalasztása. Ezek a műveletek felfüggeszthetőek vagy korlátozhatóak, a bérlő pedig az előállított kivétel formájában kap tájékoztatást arról, hogy a rendszer foglalt, és a műveletet később újból meg kell kísérelni.
Óvatosnak kell lennie, ha olyan külső szolgáltatásokkal integrál, amelyek elérhetetlenné válnak, vagy hibákat ad vissza. Csökkentse az egyidejűleg feldolgozott kérések számát, hogy a naplók ne töltődhessenek fel feleslegesen hibákkal. Emellett elkerülheti azokat a költségeket is, amelyek azzal járnak, hogy szükségtelenül újrapróbálkoznak a harmadik féltől származó szolgáltatás miatt meghiúsuló kérések feldolgozása. Ezután a kérelmek sikeres feldolgozása után térjen vissza a normál, szabályozatlan kérésfeldolgozáshoz. A funkciót megvalósító egyik kódtár az NServiceBus.
Az ábrán az erőforráshasználat területdiagramja látható (a memória, CPU, sávszélesség és más tényezők kombinációja) az időben olyan alkalmazásokra vonatkozóan, amelyek három funkciót használnak. A funkció egy működési terület, például egy összetevő, amely adott feladatokat végez, egy kódrészlet, amely egy összetett számítást hajt végre, vagy egy elem, amely valamilyen szolgáltatást – például memórián belüli gyorsítótárat – biztosít. Ezeket a funkciókat az A, B és C jelöli.
A közvetlenül az egyes funkciók vonalai alatti terület az alkalmazások által ezen funkciók igénybevételekor felhasznált erőforrásokat jelöli. Például az A funkció vonala alatti terület az A funkciót használó alkalmazások erőforráshasználatát, az A funkció vonala és a B funkció vonala közötti terület pedig a B funkciót használó alkalmazások erőforráshasználatát mutatja. Az egyes funkciókhoz tartozó területek összesítésével megkapjuk a rendszer teljes erőforráshasználatát.
Az előző ábra a műveletek késleltetésének hatását szemlélteti. Közvetlenül a T1 időpont előtt az ezen funkciókat használó alkalmazásokhoz lefoglalt erőforrások teljes mennyisége elér egy küszöbértéket (az erőforráshasználat határát). Ezen a ponton fennáll a veszély, hogy az alkalmazások kimerítik a rendelkezésre álló erőforrásokat. Ebben a rendszerben a B funkció kevésbé kritikus, mint az A vagy a C funkció, ezért a rendszer ideiglenesen letiltja, és az eddig általa használt erőforrások felszabadulnak. A T1 és a T2 időpont között az A és a C funkciót használó alkalmazások továbbra is normál módon futnak. Idővel az ezen két funkció által igénybe vett erőforrás-mennyiség eléggé lecsökken ahhoz, hogy a T2 időpontban ismét elegendő kapacitás váljon elérhetővé a B funkció engedélyezéséhez.
Az automatikus skálázás és a szabályozás kombinálható is az alkalmazások válaszkészségének megőrzése és az SLA-knak való megfelelés fenntartása érdekében. Ha a kereslet várhatóan továbbra is magas marad, a szabályozás átmeneti megoldást kínál, amíg a rendszer felskálázódik. Ezen a ponton a rendszer teljes funkcionalitása visszaállítható.
A következő ábrán a rendszeren futó összes alkalmazás teljes erőforrás-használatának grafikonja látható az idő függvényében, illusztrálva a szabályozás és az automatikus skálázás kombinálását.
A T1 időpontban a rendszer eléri az erőforráshasználat enyhe korlátjának megfelelő küszöbértéket. Ekkor a rendszer megkezdheti a vertikális felskálázást. Ha azonban az új erőforrások nem lesznek elég gyorsan elérhetővé, előfordulhat, hogy a meglévő erőforrások kimerülnek, és a rendszer meghibásodhat. Ennek elkerülése érdekében a rendszer ideiglenesen szabályozva lesz a korábban leírtaknak megfelelően. Ha az automatikus skálázás befejeződött, és a további erőforrások rendelkezésre állnak, a szabályozás enyhíthető.
Problémák és megfontolandó szempontok
A minta megvalósítása során az alábbi pontokat vegye figyelembe:
Az alkalmazások szabályozása és a felhasznált stratégia az architektúrával kapcsolatos döntés, amely a rendszer teljes kialakítására hatással van. A szabályozást az alkalmazástervezési folyamat korai szakaszában kell megfontolni, mert ezt a stratégiát nem könnyű már implementált rendszerhez hozzáadni.
A szabályozást gyorsan kell végrehajtani. A rendszernek képesnek kell lennie érzékelni a tevékenységek mennyiségének növekedését és megfelelően reagálni. Továbbá az is fontos, hogy a rendszer képes legyen gyorsan visszaállni az eredeti állapotába, miután csökkent a terhelés. Ennek feltétele a megfelelő teljesítményadatok folyamatos rögzítése és monitorozása.
Ha egy szolgáltatásnak ideiglenesen meg kell tagadnia egy felhasználói kérést, egy adott hibakódot kell visszaadnia, például a 429-et ("Túl sok kérés") és az 503-at ("Kiszolgáló túl elfoglalt"), hogy az ügyfélalkalmazás megértse, hogy a kérés kézbesítésének megtagadásának oka a szabályozás.
- A HTTP 429 azt jelzi, hogy a hívó alkalmazás túl sok kérelmet küldött egy időablakban, és túllépte az előre meghatározott korlátot.
- A HTTP 503 azt jelzi, hogy a szolgáltatás nem áll készen a kérés kezelésére. A gyakori ok az, hogy a szolgáltatás a vártnál több ideiglenes terhelésnövekedést tapasztal.
Az ügyfélalkalmazás várhat egy ideig a kérelem újbóli megkísérlése előtt. Egy Retry-After HTTP-fejlécet kell tartalmaznia, amely támogatja az ügyfelet az újrapróbálkozás stratégiájának kiválasztásában.
A szabályozás ideiglenes intézkedésként használható, amíg a rendszer elvégzi az automatikus skálázást. Bizonyos esetekben jobb egyszerűen szabályozni a skálázás helyett, ha hirtelen hirtelen megnő a tevékenység, és nem várható hosszú élettartam, mert a skálázás jelentősen növeli a működési költségeket.
Ha a szabályozás ideiglenes mértékként van használva, miközben a rendszer automatikusan skáláz, és ha az erőforrásigények nagyon gyorsan nőnek, előfordulhat, hogy a rendszer nem tudja folytatni a működését – még akkor sem, ha szabályozott módban működik. Ha ez nem fogadható el, vegye fontolóra nagyobb kapacitástartalék fenntartását és az erőteljesebb automatikus skálázást.
Normalizálja a különböző műveletek erőforrásköltségét, mivel általában nem járnak egyenlő végrehajtási költségekkel. A szabályozás korlátai például alacsonyabbak lehetnek az olvasási műveleteknél, és magasabbak az írási műveleteknél. Ha nem veszi figyelembe egy művelet költségeit, az kimerülhet a kapacitásban, és potenciális támadási vektort tehet ki.
Futásidőben a szabályozás viselkedésének dinamikus konfigurációs módosítása kívánatos. Ha egy rendszer rendellenes terheléssel szembesül, amelyet az alkalmazott konfiguráció nem tud kezelni, a szabályozási korlátoknak növelniük vagy csökkenteniük kell a rendszer stabilizálásához, és lépést kell tartaniuk az aktuális forgalommal. A költséges, kockázatos és lassú üzemelő példányok jelenleg nem kívánatosak. A Külső konfigurációtár mintaszabályozási konfigurációjának használata külsővé vált, és az üzembe helyezés nélkül módosítható és alkalmazható.
Mikor érdemes ezt a mintát használni?
Használja a következő mintát a következő helyzetekben:
Annak biztosítása érdekében, hogy a rendszer folyamatosan megfeleljen a szolgáltatói szerződések feltételeinek.
Annak elkerülése érdekében, hogy egyetlen bérlő kisajátíthassa az alkalmazások által biztosított erőforrásokat.
A tevékenységcsúcsok kezelése érdekében.
A rendszerköltségek optimalizálása érdekében a működéshez szükséges maximális erőforrásszintek korlátozása révén.
Számítási feladatok tervezése
Az építészeknek értékelniük kell, hogy a szabályozási minta hogyan használható a számítási feladat tervezése során az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:
| Pillér | Hogyan támogatja ez a minta a pillércélokat? |
|---|---|
| A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön. | A korlátokat úgy tervezheti meg, hogy megelőzze az erőforrás-kimerülést, amely hibás működéshez vezethet. Ezt a mintát vezérlő mechanizmusként is használhatja egy kecses degradálási tervben. - RE:07 Önmegőrzés |
| A biztonsági tervezési döntések segítenek biztosítani a számítási feladatok adatainak és rendszereinek titkosságát, integritását és rendelkezésre állását. | A korlátokat úgy tervezheti meg, hogy megelőzze az erőforrások kimerülését, amely a rendszer automatikus visszaéléséből eredhet. - Standard kiadás:06 Hálózati vezérlők - Standard kiadás:08 Erőforrások keményítése |
| A költségoptimalizálás a számítási feladatok megtérülésének fenntartására és javítására összpontosít. | A kikényszerített korlátok tájékoztathatják a költségmodellezést, és akár közvetlenül is kötődhetnek az alkalmazás üzleti modelljéhez. A kihasználtságra is egyértelmű felső határokat helyeznek, amelyek az erőforrás-méretezésbe is belefoghatnak. - CO:02 Költségmodell - CO:12 skálázási költségek |
| A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését . | Ha a rendszer nagy terhelés alatt áll, ez a minta segít csökkenteni a torlódásokat, amelyek teljesítménybeli szűk keresztmetszetekhez vezethetnek. Emellett proaktív módon elkerülheti a zajos szomszéd forgatókönyveket. - PE:02 Kapacitástervezés - PE:05 Skálázás és particionálás |
Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.
Példa
Az utolsó ábra bemutatja, hogyan valósítható meg a szabályozás több-bérlős rendszerben. A bérlővállalatok felhasználói egy felhőben futtatott alkalmazáshoz férnek hozzá, amelyben kérdőíveket töltenek ki és küldenek el. Az alkalmazás rendszerállapota monitorozza a felhasználóktól az alkalmazáshoz érkező kérelmek küldési gyakoriságát.
Annak érdekében, hogy egy bérlő felhasználói miatt ne csökkenjen az alkalmazás válaszkészsége és rendelkezésre állása a többi felhasználó számára, a rendszer az egyes bérlők felhasználói által egy másodperc alatt elküldhető kérelmek számára vonatkozó korlátot vezet be. Az ezen korlátot meghaladó kérelmeket az alkalmazás blokkolja.
Következő lépések
A minta megvalósításakor az alábbi útmutatás is releváns lehet:
- Rendszerállapot és telemetria – útmutató. A szabályozás alapját a szolgáltatások igénybevételének mértékére vonatkozó adatok gyűjtése képezi. Ismerteti, hogyan állíthat elő és rögzíthet egyéni monitorozási adatokat.
- Szolgáltatások mérésével kapcsolatos útmutató. Ismerteti, hogyan mérheti a szolgáltatások használatát annak érdekében, hogy megismerje a használatuk módját. Ez az információ hasznos lehet a szolgáltatás szabályozásának megtervezéséhez.
- Útmutató az automatikus skálázáshoz. A szabályozás használható ideiglenes intézkedésként, amíg a rendszer elvégzi az automatikus skálázást, vagy azért, hogy ne legyen szükség automatikus skálázásra. Az automatikus skálázási stratégiákra vonatkozó információkat tartalmaz.
Kapcsolódó erőforrások
A minta megvalósításakor a következő minták is relevánsak lehetnek:
- Üzenetsor-alapú terheléskiegyenlítési minta. Az üzenetsor-alapú terheléskiegyenlítés a szabályozás implementálásához gyakran használt mechanizmus. Az üzenetsor képes pufferként működni, amely segít egyenletesebbé tenni a szolgáltatásokhoz érkező, alkalmazások által küldött kérelmek kézbesítési gyakoriságát.
- Elsőbbségi üzenetsor mintája. Az elsőbbségi üzenetsor szabályozási stratégiába való beépítésével a rendszer képes fenntartani a teljesítményszintet a kritikus fontosságú vagy nagyértékű alkalmazásokhoz, míg a kevésbé fontos alkalmazások teljesítményét csökkenti.
- Külső konfigurációtár-minta. A szabályozási szabályzatok központosítása és külsővé tétele lehetővé teszi a konfiguráció futásidőben történő módosítását anélkül, hogy újra üzembe helyezésre volna szükség. A szolgáltatások előfizethetnek a konfigurációmódosításokra, így az új konfiguráció azonnal alkalmazható a rendszer stabilizálásához.