Megosztás:

Az Azure App Service (Web Apps) architektúrával kapcsolatos ajánlott eljárásai

Az Azure App Service egy szolgáltatásként nyújtott platform (PaaS), amely teljes mértékben felügyelt üzemeltetési környezetet biztosít webalkalmazások létrehozásához, üzembe helyezéséhez és skálázásához. PaaS-megoldásként az App Service elvonja a mögöttes infrastruktúrát, amely lehetővé teszi, hogy az alkalmazásfejlesztésre összpontosítson. Az App Service Web Apps funkciója egy App Service-csomag kontextusában futtatja az alkalmazásokat. Ez a csomag határozza meg az alkalmazás üzemeltetéséhez használt erőforrásokat, operációs rendszert, régiót és díjszabási modellt (SKU).

Ez a cikk feltételezi, hogy tervezőként áttekintette a számítási döntési fát , és az App Service-t választotta számítási feladatának. A cikk útmutatása olyan architekturális javaslatokat tartalmaz, amelyek a Well-Architected Keretrendszer pilléreinekalapelveihez vannak megfeleltetve.

Technológiai hatókör

Ez az áttekintés a következő Azure-erőforrásokhoz tartozó, egymással összefüggő döntésekre összpontosít:

  • App Service-tervek
  • Web Apps

Más Azure-ajánlatok az App Service-hez vannak társítva, például az Azure Functionshez, az Azure Logic Appshez és az App Service-környezethez. Ezek az ajánlatok nem tartoznak a jelen cikk hatókörébe. Az App Service-környezetre időnként hivatkozunk, hogy tisztázzuk az alapvető App Service-ajánlatok funkcióit vagy lehetőségeit.

Reliability

A megbízhatósági pillér célja a folyamatos működés biztosítása azáltal, hogy elegendő rugalmasságot épít ki, és képes gyorsan helyreállni a hibákból.

A megbízhatósági tervezési alapelvek biztosítják az egyes összetevőkre, rendszerfolyamatokra és a rendszer egészére alkalmazott magas szintű tervezési stratégiát.

Munkaterhelés tervezési ellenőrzőlistája

Indítsa el a tervezési stratégiáját a tervezési felülvizsgálati ellenőrzőlista alapján a megbízhatóság érdekében. Az App Service és függőségei szintjeit és funkcióit szem előtt tartva határozza meg az üzleti követelményeknek való relevanciáját. Bővítse ki a stratégiát, hogy szükség szerint további megközelítéseket is tartalmazzon.

  • Felhasználói folyamatok rangsorolása: Nem minden folyamat ugyanolyan fontos. Azonosítsa az alkalmazás kritikus útvonalait, és rendelje hozzá a prioritásokat az egyes folyamatokhoz a tervezési döntések irányításához. A felhasználói folyamat kialakítása befolyásolhatja az App Service-csomaghoz és -konfigurációhoz választott szolgáltatási szinteket és példányok számát.

    Az alkalmazás például tartalmazhat olyan előtér- és háttérrétegeket, amelyek üzenetközvetítőn keresztül kommunikálnak. Dönthet úgy, hogy több webalkalmazás rétegeit szegmentálta, hogy lehetővé tegye a független skálázást, az életciklus-kezelést és a karbantartást. Ha egy nagy alkalmazást egyetlen csomagban helyez el, az memória- vagy PROCESSZORproblémákhoz vezethet, amelyek befolyásolják a megbízhatóságot.

    Előfordulhat, hogy több példányra van szüksége a frontenden a felhasználói felület optimális teljesítményéhez. Előfordulhat azonban, hogy a háttérrendszer nem igényel ugyanannyi példányt.

  • Lehetséges hibák előrejelzése: Tervezze meg a lehetséges hibákra vonatkozó kockázatcsökkentési stratégiákat. Az alábbi táblázat példákat mutat be a hibamód elemzésére.

    Failure Mitigation
    A mögöttes vagy elvont App Service-összetevők hibája Van komponens-redundancia a példányokban és a függőségekben. A példányok, a hálózati teljesítmény és a tárolási teljesítmény állapotának monitorozása.
    Külső függőségek meghibásodása Használjon olyan tervezési mintákat, mint az Újrapróbálkozási minta és az Áramkör-megszakító minta. Figyelje a külső függőségeket, és állítsa be a megfelelő időtúllépéseket.
    Hiba, mert a forgalom nem megfelelő példányokra lesz irányítva Példány állapotának figyelése. Fontolja meg a válaszképességet, és ne küldjön kéréseket rossz állapotú példányokra.

    További információ: Azure-alkalmazások hibamódjának elemzése.

  • Redundancia összeállítása: Redundancia létrehozása az alkalmazásban és az infrastruktúra támogatása. Oszd el a példányokat a rendelkezésre állási zónák között a hibatűrés javítása érdekében. A forgalom más zónákba lesz irányítva, ha egy zóna meghibásodik. Az alkalmazás több régióban való üzembe helyezése annak biztosítása érdekében, hogy az alkalmazás elérhető maradjon, még akkor is, ha egy teljes régióban kimaradás történik.

    Hasonló redundanciaszinteket hozhat létre a függő szolgáltatásokban. Az alkalmazáspéldányok például a Blob Storage-hoz kötődnek. Fontolja meg a társított tárfiók zónaredundáns tárolással való konfigurálását, ha egy alkalmazás zónaredundáns üzembe helyezést használ.

  • Több példány használata: Ha az alkalmazást csak egy példányon futtatja, azonnal egy hibapont lép fel. Több példány hozzárendelése az Ön alkalmazásához a magas rendelkezésre állás biztosítása érdekében. Ha egy példány meghibásodik, a többi példány továbbra is képes kezelni a bejövő kéréseket. Az alkalmazáskódnak képesnek kell lennie több példány szinkronizálási problémák nélkül történő kezelésére, amikor adatforrásokból olvas vagy adatforrásokra ír.

    Legyen redundancia a hálózati összetevőkben. Használjon például zónaredundáns IP-címeket és terheléselosztókat.

  • Megbízható skálázási stratégiával rendelkezik: Az alkalmazás váratlan terhelése megbízhatatlanné teheti. Fontolja meg a megfelelő skálázási módszert a számítási feladatok jellemzői alapján. A horizontális skálázás vagy horizontális felskálázás lehetővé teszi további példányok hozzáadását a terhelés elosztásához. A vertikális skálázás vagy a vertikális felskálázás növeli egy meglévő példány, például a CPU vagy a memória kapacitását. Legyen óvatos a túlkiépítéssel, mert a szükségtelen példányok hozzáadása kézzelfogható teljesítménybeli előnyök nélkül növeli a költségeket.

    Esetenként növelheti a kapacitást, hogy kezelje a terhelést. Ha azonban a terhelés továbbra is növekszik, bővítse ki új példányokra. Válassza ki az automatikus vagy automatikus skálázási megközelítést a manuális megközelítésen keresztül. A teljesítménycsökkenés elkerülése érdekében a skálázási műveletek során mindig tartsa fenn a többletkapacitás pufferét.

    A választott App Service-csomagszint a példányok száma és a számítási egységek tekintetében befolyásolja a skálázást.

    A skálázási stratégia tervezésekor vegye figyelembe a hálózati protokoll követelményeit, így biztosítva, hogy az IPv4 és az IPv6 forgalmi minták is lefedődnek. Az App Service támogatja a bejövő IPv6-kapcsolatokat az IPv4 mellett. Csak az IPv6-hálózatok képesek leküzdeni az IPv4-címek kimerülésének problémáit. Az IPv6-alapú ügyfelek azonban IPv4-ről IPv6-ra fordítási szolgáltatásokat igényelnek, ha az IPv6 nincs engedélyezve, így potenciális hálózati fordítási többletterhelést hozhatnak létre. További információ: Bejövő és kimenő IP-címek az Azure App Service-ben.

  • Gondoskodjon a megfelelő alkalmazás inicializálásról, hogy az új példányok gyorsan felmelegedjenek, és fogadhassák a kéréseket. Ha lehetséges, törekedjen állapot nélküli alkalmazásokra. A megbízható skálázási állapot új példányokkal növelheti az összetettségét. Fontolja meg egy külső adattárat, amelyet egymástól függetlenül skálázhat, ha az alkalmazás állapotát kell tárolnia. A munkamenet-állapot memóriában való tárolása a munkamenet állapotának elvesztését eredményezheti, ha probléma merül fel az alkalmazással vagy az App Service-vel. Emellett korlátozza a terhelés más példányok közötti elosztásának lehetőségét is.

    Az automatikus méretezési szabályok rendszeres tesztelése. A betöltési forgatókönyvek szimulálása annak ellenőrzéséhez, hogy az alkalmazás a várt módon skálázható-e. Naplóznia kell a skálázási eseményeket, hogy elháríthassa az esetlegesen felmerülő problémákat, és optimalizálhassa a skálázási stratégiát.

    Az App Service korlátozza a csomagban lévő példányok számát, ami befolyásolhatja a skálázás megbízhatóságát. Ennek megoldásához az egyik stratégia az azonos bélyegek üzembe helyezése, minden egyes bélyeg saját App Service-csomagpéldányt és -végpontot futtat. Fontos, hogy minden szerver elé egy külső terheléselosztót helyezzünk, hogy a forgalmat elossza közöttük. Az Azure Application Gateway alkalmazása egyzónás telepítésekhez, az Azure Front Door alkalmazása pedig többrégiós telepítésekhez. Ez a megközelítés kritikus fontosságú alkalmazásokhoz ideális, ha a megbízhatóság kulcsfontosságú. További információ: Kritikus fontosságú alapkonfiguráció az App Service.

  • Tervezze meg a helyreállíthatóságot: A redundancia kulcsfontosságú az üzletmenet folytonossága szempontjából. Váltás egy másik példányra, ha az egyik példány nem érhető el. Ismerje meg az App Service automatikus javítási funkcióit, például a példányok automatikus javítását.

    Tervezési mintákat implementálhat az átmeneti hibák, például a hálózati csatlakozási problémák, valamint a nagy léptékű események, mint például a regionális kimaradások fokozatos degradációjának kezelésére. Vegye figyelembe a következő tervezési mintákat:

    • A válaszfalminta izolált csoportokba bontja az alkalmazást, hogy megakadályozza, hogy a hiba a teljes rendszert érintse.

    • A Queue-Based Terhelés simítási minta a munkaelemeket sorba állítja, amelyek pufferként szolgálnak a forgalmi csúcsok kisimításához.

    • Az újrapróbálkozási minta hálózati hibák, megszakadt adatbázis-kapcsolatok vagy foglalt szolgáltatások miatt kezeli az átmeneti hibákat.

    • Az áramkör-megszakító minta megakadályozza, hogy egy alkalmazás ismétlődően megkíséreljen olyan műveletet végrehajtani, amely valószínűleg sikertelen lesz.

    További információ: A megbízhatóságot támogató architektúratervezési minták.

  • Megbízhatósági tesztelés végrehajtása: Végezzen terheléstesztelést az alkalmazás megbízhatóságának és teljesítményének terhelés alatti kiértékeléséhez. A tesztelési terveknek olyan forgatókönyveket kell tartalmazniuk, amelyek ellenőrzik az automatizált helyreállítási műveleteket.

    Használjon hibainjektálást a hibák szándékos bevezetéséhez, és ellenőrizze öngyógyító és önmegőrző mechanizmusait. További információt az Azure Chaos Studio hiba- és művelettárában talál.

    Az App Service erőforráskorlátokat ír elő a üzemeltetett alkalmazásokra. Az App Service-csomag határozza meg ezeket a korlátokat. Győződjön meg arról, hogy a tesztek megerősítik, hogy az alkalmazás ezen erőforráskorláton belül fut. További információ: App Service-korlátok.

  • Az állapot-ellenőrzési funkcióval azonosíthatja a nem válaszoló feldolgozókat: Az App Service beépített képességekkel rendelkezik, amelyek rendszeres időközönként pingelik a webalkalmazás egy adott elérési útját. A platform pingeli ezt az elérési utat annak megállapításához, hogy az alkalmazás kifogástalan állapotban van-e, és válaszol-e a kérésekre.

    Ha a webhely több példányra van skálázva, az App Service kizárja a nem megfelelő állapotú példányokat a kérések kiszolgálásából. Ez a folyamat javítja a teljes rendelkezésre állást.

    Az alkalmazás állapot-ellenőrzési útvonalának le kell kérdeznie az alkalmazás alapvető összetevőit, például az adatbázist, a gyorsítótárat vagy az üzenetkezelési szolgáltatást. Ez a lépés biztosítja, hogy az állapot-ellenőrzési útvonal által visszaadott állapot pontos képet adjon az alkalmazás általános állapotáról.

  • Az automatikus javítás funkció használata: Előfordulhat, hogy az alkalmazás váratlan viselkedést tapasztal, amelyet egy egyszerű újraindítás megoldhat. Az automatikus javítás funkcióval meghatározhatja az automatikus javítást kiváltó feltételt , valamint azt a műveletet , amelyet az automatikus javítás a feltétel teljesülése esetén indít el. További információt az App Service diagnosztikai áttekintésében talál.

  • Az App Service rugalmassági pontszámának jelentése: A személyre szabott ajánlott eljárásokra vonatkozó javaslatok áttekintéséhez tekintse meg az App Service diagnosztikai áttekintését.

Konfigurációs javaslatok

Recommendation Benefit
(App Service) Válassza ki az App Service-csomag prémium v3 szintjét éles számítási feladatokhoz.

Állítsa be a maximális és minimális munkavállalói számot a kapacitástervezésnek megfelelően. További információ: App Service-csomag áttekintése.		 A Prémium v3 App Service-csomag speciális skálázási funkciókat biztosít, és biztosítja a redundanciát meghibásodás esetén.
(App Service) Zónaredundancia engedélyezése.

Fontolja meg több mint három példa kiépítését a hibatűrés javítása érdekében.

Ellenőrizze a zónaredundancia regionális támogatását, mert nem minden régió rendelkezik ezzel a funkcióval.		 Az alkalmazás képes ellenállni a hibáknak egyetlen zónában, ha több példány van elosztva a zónák között. A forgalom automatikusan más zónák kifogástalan példányaira vált, és fenntartja az alkalmazások megbízhatóságát, ha egy zóna nem érhető el.
(Web Apps) Fontolja meg az alkalmazáskérelmek útválasztási (ARR) affinitási funkciójának letiltását. Az ARR affinitás ragadós munkameneteket hoz létre, amelyek átirányítják a felhasználókat a korábbi kéréseiket kezelő csomópontra. Az ARR-affinitás letiltásakor a bejövő kérések egyenletesen oszlanak el az összes elérhető csomópont között. Az egyenletesen elosztott kérések megakadályozzák, hogy a forgalom túlterhelje az egyetlen csomópontot. A kérelmek zökkenőmentesen átirányíthatók más kifogástalan állapotú csomópontokra, ha egy csomópont nem érhető el.

Kerülje a munkamenet-affinitást, hogy az App Service példány állapotmentes maradjon. Az állapot nélküli App Service-példányok csökkentik az összetettséget, és konzisztens viselkedést biztosít a csomópontok között.

Távolítsa el a ragadós munkameneteket, hogy az App Service horizontálisan skálázható példányokat vegyen fel vagy távolítson el.
(App Service) Ne használja az App Service biztonsági mentési és visszaállítási funkcióját a csatolt adatbázisokhoz. A csatolt adatbázisok natív biztonsági mentési és visszaállítási eszközeinek használata megbízhatóbb és biztonságosabb helyreállítási megoldást nyújt a webalkalmazás állapottárolójához.

A csatolt adatbázisok App Service-beli biztonsági mentése elavult.
(Web Apps) Automatikus javítási szabályokat határozhat meg a kérések száma, a lassú kérelmek, a memóriakorlátok és a teljesítménykonfiguráció részét képező egyéb mutatók alapján. Vegye figyelembe ezt a konfigurációt a skálázási stratégia részeként. Az automatikus javítási szabályok segítenek az alkalmazásnak a váratlan problémák automatikus helyreállításában. A konfigurált szabályok gyógyító műveleteket aktiválnak a küszöbértékek átlépésekor.

Az automatikus javítás automatikus proaktív karbantartást tesz lehetővé.
(Web Apps) Engedélyezze az állapot-ellenőrzési funkciót , és adjon meg egy elérési utat, amely válaszol az állapot-ellenőrzési kérelmekre. Az állapot-ellenőrzések időben észlelik a problémákat. Ezután a rendszer automatikusan elvégezheti a korrekciós műveleteket, ha egy állapot-ellenőrzési kérés meghiúsul.

A terheléselosztó átirányítja a forgalmat a nem megfelelő állapotú példányoktól, ami a felhasználókat kifogástalan állapotú csomópontokra irányítja.
(Web Apps) Engedélyezze az Always on lehetőséget, ha a webalkalmazás egy WebJob-feladatot üzemeltet. A webalkalmazások a HTTP-inaktivitás időszaka után időtúllépést okozhatnak. Az Always on beállítással biztosítható, hogy a folyamatos és az aktivált WebJobs megbízhatóan fusson.

Biztonság

A biztonsági pillér célja, hogy bizalmasságot, integritást és rendelkezésre állást biztosítson a számítási feladat számára.

A Biztonsági tervezési alapelvek magas szintű tervezési stratégiát biztosítanak e célok eléréséhez azáltal, hogy megközelítéseket alkalmaznak az App Service-beli üzemeltetés technikai tervezésére.

Munkaterhelés tervezési ellenőrzőlistája

Indítsa el a tervezési stratégiát a biztonsági tervezési felülvizsgálati ellenőrzőlista alapján, és azonosítsa a biztonsági réseket és ellenőrzéseket a biztonsági helyzet javítására. Bővítse ki a stratégiát, hogy szükség szerint további megközelítéseket is tartalmazzon.

  • Biztonsági alapkonfigurációk áttekintése: Az App Service-csomagban üzemeltetett alkalmazás biztonsági helyzetének javításához tekintse át az App Service biztonsági alapkonfigurációját.

  • Használja a legújabb futtatókörnyezetet és kódtárakat: Mielőtt frissítéseket végez, alaposan tesztelje az alkalmazás buildjeinek tesztelését a problémák korai észlelése érdekében, és gondoskodjon az új verzióra való zökkenőmentes áttérésről. Az App Service támogatja a nyelvi futtatókörnyezet támogatási szabályzatát a meglévő veremek frissítéséhez és a támogatás megszűnő veremek kivonásához.

  • Szegmentálás létrehozása elkülönítési határokkal a behatolások megfékezéséhez: Identitásszegmentálás alkalmazása. Például implementálhatja a szerepköralapú hozzáférés-vezérlést (RBAC) a szerepkörök alapján meghatározott engedélyek hozzárendeléséhez. Kövesse a minimális jogosultság elvét, hogy a hozzáférési jogosultságokat csak a szükségesre korlátozza. Emellett hozzon létre szegmentációt a hálózati szinten. Integrálja az App Service-alkalmazásokat egy Azure-beli virtuális hálózattal elkülönítés céljából, és határozza meg a hálózati biztonsági csoportokat (NSG-k) a forgalom szűréséhez.

    Az App Service-csomagok biztosítják az App Service Environment szintet, amely magas fokú elkülönítést biztosít. Az App Service Environment segítségével dedikált számítást és hálózatkezelést kaphat.

  • Hozzáférési vezérlők alkalmazása identitásokra: Korlátozza a webalkalmazáshoz való befelé és a webalkalmazásból más erőforrásokhoz való külső hozzáférést. Ez a konfiguráció hozzáférési vezérlőket alkalmaz az identitásokra, és segít fenntartani a számítási feladat általános biztonsági helyzetét.

    Minden hitelesítési és engedélyezési igényhez használja a Microsoft Entra-azonosítót. Használjon beépített szerepköröket, például egy webcsomag-közreműködői, webhely-közreműködői, valamint egy általános közreműködői, olvasói és tulajdonosi.

  • Hálózati biztonsági vezérlők alkalmazása: Integrálja az App Service-t egy virtuális hálózattal a kimenő forgalom szabályozásához. Privát végpontok használatával szabályozhatja a bejövő forgalmat, korlátozhatja az App Service-példányhoz való hozzáférést a virtuális hálózaton belülről, és letilthatja a nyilvános internet-hozzáférést. További információ: Hálózati útválasztás.

    Webalkalmazási tűzfal (WAF) üzembe helyezése a gyakori biztonsági rések elleni védelem érdekében. Az Application Gateway és az Azure Front Door integrált WAF-képességekkel is rendelkezik.

    A fordított proxyszabályokat és a hálózati beállításokat megfelelően konfigurálja a kívánt biztonsági és vezérlési szint eléréséhez. Adjon hozzá például NSG-szabályokat a privát végpont alhálózatához, hogy csak a fordított proxyból érkező forgalmat fogadja el.

    Az alkalmazásból más PaaS-szolgáltatásokba irányuló kimenő forgalomnak magánvégpontokon kell lennie. Fontolja meg egy tűzfalösszetevő elhelyezését a nyilvános internetre irányuló kimenő forgalom korlátozásához. Mindkét módszer segít megelőzni az adatkiszivárgást.

    További információ: App Service hálózatkezelési funkciók.

  • Adatok titkosítása: Az átvitel alatt lévő adatok védelme a végpontok közötti átviteli réteg biztonságával (TLS) történik. Használja az ügyfél által kezelt kulcsokat az inaktív adatok teljes titkosításához.

    Ne használjon olyan örökölt protokollokat, mint a TLS 1.0 és az 1.1. Győződjön meg arról, hogy minden webalkalmazás csak HTTPS-t használ, és kényszeríti a TLS 1.2 vagy újabb verzióját. Az alapértelmezett minimális TLS-verzió az 1.2. További információ: App Service TLS áttekintése.

    Az App Service-példányok mindegyike alapértelmezett tartománynévvel rendelkezik. Használjon egyéni tartományt, és biztonságossá tegye a tartományt tanúsítványok használatával.

  • Végpontok közötti TLS-titkosítás: A végpontok közötti TLS-titkosítás prémium szintű App Service-tervekben érhető el. Ez a funkció a teljes tranzakció során titkosítja a forgalmat, ami minimálisra csökkenti a forgalom elfogásának kockázatát.

  • Csökkentse a támadási felületet: Távolítsa el a szükségtelen alapértelmezett konfigurációkat. Tiltsa le például a távoli hibakeresést, az SCM-webhelyek helyi hitelesítését és az alapszintű hitelesítést. Tiltsa le a nem biztonságos protokollokat, például a HTTP-t és a fájlátviteli protokollt (FTP). Konfigurációk kényszerítése Azure-szabályzatok használatával. További információ: Azure-szabályzatok.

  • Korlátozó, forrásközi erőforrás-megosztási (CORS-) szabályzatok implementálása: A webalkalmazásban korlátozó CORS-szabályzatokkal csak az engedélyezett tartományokból, fejlécekből és egyéb feltételekből érkező kéréseket fogadhatja el. CORS-szabályzatok kikényszerítése beépített Azure-szabályzatdefiníciókkal.

  • Felügyelt identitások használata: Engedélyezze a felügyelt identitásokat az App Service-példány számára, hogy biztonságosabban férhessen hozzá más Azure-szolgáltatásokhoz anélkül, hogy hitelesítő adatokat kellene kezelnie.

  • Alkalmazás titkos kulcsának védelme: Bizalmas információkat kell kezelnie, például API-kulcsokat vagy hitelesítési jogkivonatokat. A titkos kulcsok közvetlenül az alkalmazáskódba vagy konfigurációs fájlokba való közvetlen bekódolása helyett az Azure Key Vault-referenciákat használhatja az alkalmazásbeállításokban. Az alkalmazás indításakor az App Service automatikusan lekéri a titkos értékeket a Key Vaultból az alkalmazás felügyelt identitásának használatával.

  • Erőforrásnaplók engedélyezése az alkalmazáshoz: Engedélyezze az alkalmazás erőforrásnaplóit olyan átfogó tevékenységnaplók létrehozásához, amelyek értékes adatokat biztosítanak a biztonsági incidenseket követő vizsgálatok során. További információt az Azure Monitor erőforrásnaplóiban talál.

    A fenyegetések felmérése során fontolja meg a naplózást a fenyegetésmodellezési folyamat részeként.

Konfigurációs javaslatok

Recommendation Benefit
(Web Apps) Felügyelt identitások hozzárendelése a webalkalmazáshoz. Az elkülönítési határok fenntartása érdekében ne ossza meg vagy használja újra az identitásokat az alkalmazások között.

Győződjön meg arról, hogy biztonságosan csatlakozni a tárolóregisztrációs adatbázishoz, ha tárolókat használ az üzembe helyezéshez.		 Az alkalmazás lekéri a titkos kulcsokat a Key Vaultból, hogy hitelesítse az alkalmazásból érkező kimenő kommunikációt. Az Azure kezeli az identitást, és nem követeli meg, hogy titkokat hozzon létre vagy forgasson át.

Az irányítás részletezéséhez különálló identitások tartoznak. A különálló identitások megkönnyítik a visszavonást, ha egy identitás sérül.
(Web Apps) Egyéni tartományok konfigurálása alkalmazásokhoz.

Tiltsa le a HTTP-t, és csak HTTPS-kéréseket fogad el.		 Az egyéni tartományok TLS protokoll használatával teszik biztonságossá a HTTPS-kapcsolaton keresztüli kommunikációt, amely biztosítja a bizalmas adatok védelmét, és létrehozza a felhasználói megbízhatóságot.
(Web Apps) Értékelje ki, hogy az App Service beépített hitelesítése a megfelelő mechanizmus-e az alkalmazáshoz hozzáférő felhasználók hitelesítéséhez. Az App Service beépített hitelesítése integrálható a Microsoft Entra-azonosítóval. Ez a funkció több bejelentkezési szolgáltató jogkivonat-érvényesítését és felhasználói identitáskezelését kezeli, és támogatja az OpenID Connectet. Ezzel a funkcióval nem rendelkezik részletes szintű hitelesítéssel, és nem rendelkezik a hitelesítés tesztelésére szolgáló mechanizmussal. Ha ezt a funkciót használja, nem kell hitelesítési kódtárakat használnia az alkalmazáskódban, ami csökkenti az összetettség mértékét. A felhasználó már hitelesítve van, amikor egy kérés eléri az alkalmazást.
(Web Apps) Konfigurálja az alkalmazást a virtuális hálózati integrációhoz.

privát végpontok használata az App Service-alkalmazásokhoz. Tiltsa le az összes nyilvános forgalmat.

A tárolólemezkép-lekérés átirányítása a virtuális hálózaton integráción keresztül. Minden kimenő forgalom az alkalmazásból áthalad a virtuális hálózaton.		 Az Azure-beli virtuális hálózatok használatának biztonsági előnyei. Az alkalmazás például biztonságosan hozzáférhet a hálózaton belüli erőforrásokhoz.

Adjon hozzá egy privát végpontot az alkalmazás védelméhez. A privát végpontok korlátozzák a nyilvános hálózat közvetlen kitettségét, és engedélyezik a fordított proxyn keresztüli szabályozott hozzáférést.
(Web Apps) A megkeményedés implementálása:

- Tiltsa le az alapszintű hitelesítést, amely felhasználónevet és jelszót használ a Microsoft Entra ID-alapú hitelesítés mellett.

– Kapcsolja ki a távoli hibakeresést, hogy a bejövő portok ne nyílnak meg.

– Engedélyezze a CORS-szabályzatokat a bejövő kérelmek szigorításához.

- Tiltsa le a protokollokat, például az FTP-t.		 Nem javasoljuk az alapszintű hitelesítést biztonságos üzembehelyezési módszerként. A Microsoft Entra ID OAuth 2.0 jogkivonatalapú hitelesítést alkalmaz, amely számos előnyt és fejlesztést biztosít, amelyek az alapszintű hitelesítéssel kapcsolatos korlátozásokat kezelik.

A szabályzatok korlátozzák az alkalmazáserőforrásokhoz való hozzáférést, csak adott tartományokból érkező kéréseket engedélyeznek, és biztonságos régiók közötti kéréseket biztosítanak.
(Web Apps) Mindig használja a Key Vault-hivatkozásokat alkalmazásbeállításokként.
A titkos kódokat az alkalmazás konfigurációjától elkülönítve tartjuk. Az alkalmazásbeállítások inaktív állapotban vannak titkosítva. Az App Service a titkos kulcsok rotálását is kezeli.
(App Service) Engedélyezze a Microsoft Defender for Cloud szolgáltatást az App Service-hez. Valós idejű védelmet kaphat az App Service-csomagban futó erőforrásokhoz. A fenyegetések elleni védelem és az általános biztonsági helyzet javítása.
(App Service) A diagnosztikai naplózás engedélyezése és az instrumentáció hozzáadása az alkalmazáshoz. A naplók az Azure Storage-fiókokba, az Azure Event Hubsba és a Log Analyticsbe kerülnek. A naplótípusokról további információt a támogatott naplótípusokcímű témakörben talál. A naplózás rögzíti a hozzáférési mintákat. Olyan releváns eseményeket rögzít, amelyek értékes betekintést nyújtanak abba, hogy a felhasználók hogyan kommunikálnak egy alkalmazással vagy platformmal. Ezek az információk kulcsfontosságúak az elszámoltathatóság, a megfelelőség és a biztonság szempontjából.

Költségoptimalizálás

A költségoptimalizálás a a kiadási minták észlelésére, a kritikus területeken lévő beruházások rangsorolására, valamint a másokban optimalizálására összpontosít, hogy megfeleljenek a szervezet költségvetésének, miközben megfelelnek az üzleti követelményeknek.

A Költségoptimalizálás tervezési alapelvei magas szintű tervezési stratégiát biztosítanak e célok eléréséhez, és szükség szerint kompromisszumokat hozhatnak a Web Appshez és környezetéhez kapcsolódó műszaki tervezésben.

Munkaterhelés tervezési ellenőrzőlistája

Indítsa el tervezési stratégiáját a beruházások költségoptimalizálására vonatkozó tervellenőrzési ellenőrzőlista alapján. Finomhangolja a tervet, hogy a számítási feladat igazodjon a számítási feladathoz lefoglalt költségvetéshez. A tervezésnek a megfelelő Azure-képességeket kell használnia, figyelnie kell a beruházásokat, és meg kell találnia az optimalizálás lehetőségeit az idő függvényében.

  • A kezdeti költség becslése: A költségmodellezési gyakorlat részeként az Azure díjszabási kalkulátorával értékelje ki a különböző szintekhez kapcsolódó hozzávetőleges költségeket a futtatni kívánt példányok száma alapján. Minden App Service-szint különböző számítási lehetőségeket biztosít.

    Folyamatosan monitorozza a költségmodellt a kiadások nyomon követéséhez.

  • Értékelje ki a kedvezményes lehetőségeket: A magasabb szintek dedikált számítási példányokat tartalmaznak. Foglalási kedvezményt akkor alkalmazhat, ha a munkaterhelés kiszámítható és egyenletes használati mintával rendelkezik. A számítási feladatnak megfelelő foglalás típusának meghatározásához elemezze a használati adatokat. További információ: Költségek megtakarítása App Service fenntartott példányokkal.

  • A használati mérők megértése: Az Azure óránkénti díjat számít fel, amely az App Service-csomag árazási szintje alapján másodpercre lebontva van kiszámítva. A díjtételek a csomag minden felskálázott példányára vonatkoznak a virtuálisgép-példány lefoglalásának időpontja alapján. Ügyeljen a kihasználatlan számítási erőforrásokra, amelyek a túlterhelés miatt növelhetik a költségeket az optimálisnál rosszabb termékváltozat kiválasztása vagy a rosszul konfigurált méretezési konfiguráció miatt.

    Az App Service további funkciói, például az egyéni tartományregisztráció és az egyéni tanúsítványok költségekkel járhatnak. Más erőforrások, például a megoldásokat elkülönítő virtuális hálózatok vagy a számítási feladatok titkos kulcsait védő kulcstartók is integrálhatók az App Service-erőforrásokkal, és költségekkel járnak. További információ: Az App Service teljes számlázási modelljének ismertetése.

  • Fontolja meg a sűrűség és az elkülönítés közötti kompromisszumot: Az App Service-csomagok használatával több alkalmazást is üzemeltethet ugyanazon a számításon, ami megosztott környezetekkel takarítja meg a költségeket. További információ: Kompromisszumok.

  • Értékelje ki a skálázási stratégia költségre gyakorolt hatását: Az automatikus skálázás megvalósításakor megfelelő módon kell megterveznie, tesztelnie és konfigurálnia a horizontális felskálázást és a skálázást lefelé. Az automatikus skálázásra vonatkozó pontos maximális és minimális korlátok meghatározása.

    Proaktívan inicializálja az alkalmazást a megbízható skálázás érdekében. Ne várjon például, amíg a processzor eléri a 95% használatot. Ehelyett körülbelül 65%-nál indítsa el a skálázást, hogy elegendő idő álljon rendelkezésre az új példányok hozzárendelésére és inicializálására a skálázási folyamat során. Ez a stratégia azonban kihasználatlan kapacitást eredményezhet.

    Javasoljuk, hogy egyesítse és egyensúlyozza a függőleges és vízszintes skálázási mechanizmusokat. Egy alkalmazás például felskálázható egy ideig, majd szükség szerint skálázható vízszintesen. Fedezze fel a nagy kapacitást és a hatékony erőforrás-használatot biztosító magas szinteket. A használati minták alapján a magasabb prémium szintű szintek gyakran költséghatékonyabbak, mert sokkal hatékonyabbak.

  • A környezeti költségek optimalizálása: Fontolja meg az alapszintű vagy az ingyenes szint használatát az éles üzem előtti környezetek futtatásához. Ezek a szintek alacsony teljesítményt és alacsony költségeket jelentenek. Ha az alapszintű vagy az ingyenes szintet használja, az irányítással kényszerítheti a szintet, korlátozhatja a példányok és processzorok számát, korlátozhatja a skálázást, és korlátozhatja a naplók megőrzését.

  • Tervezési minták implementálása: Ez a stratégia csökkenti a számítási feladat által generált kérelmek mennyiségét. A kérések számának minimalizálása és a költségek csökkentése érdekében érdemes megfontolni olyan minták használatát, mint a Háttérrendszer az előtérrendszer számára minta és az Átjáró aggregációs minta.

  • Az adatokkal kapcsolatos költségek rendszeres ellenőrzése: A hosszabb adatmegőrzési időszakok vagy a költséges tárolási szintek magas tárolási költségeket eredményezhetnek. A sávszélesség-használat és a naplózási adatok tartós megőrzése miatt további költségek halmozódhatnak fel.

    Fontolja meg a gyorsítótárazás implementálását az adatátviteli költségek minimalizálása érdekében. Kezdje a helyi memóriabeli gyorsítótárazással, majd vizsgálja meg az elosztott gyorsítótárazási lehetőségeket, hogy csökkentse a háttéradatbázisra irányuló kérések számát. Vegye figyelembe a régiók közötti kommunikációhoz kapcsolódó sávszélesség-forgalmi költségeket, ha az adatbázis egy másik régióban található.

  • Üzembehelyezési költségek optimalizálása: Használja ki az üzembehelyezési pontok előnyeit a költségek optimalizálásához. A pont ugyanabban a számítási környezetben fut, mint az éles példány. Stratégiailag használhatja őket olyan forgatókönyvekhez, mint a szolgáltatáshelyek közötti váltást alkalmazó kék-zöld telepítések. Ez a megközelítés minimalizálja az állásidőt, és zökkenőmentes átmenetet biztosít.

    Használja körültekintően a telepítési helyeket. Problémákat, például kivételeket vagy memóriavesztést okozhat, amelyek hatással lehetnek a meglévő példányokra és az új példányokra. Győződjön meg arról, hogy alaposan teszteli a módosításokat. A működési útmutatóval kapcsolatos további információkért tekintse meg az Operatív kiválóság című témakört.

Konfigurációs javaslatok

Recommendation Benefit
(App Service) Az alacsonyabb környezetekhez ingyenes vagy alapszintű szinteket választhat . Ezeket a szinteket kísérleti célokra javasoljuk. Távolítsa el a rétegeket, ha már nincs rájuk szüksége. Az ingyenes szintek és az alapszintek költségvetés-barátak a magasabb szintekhez képest. Költséghatékony megoldást nyújtanak olyan nem gyártási környezetekhez, amelyekhez nincs szükség a prémium csomagok teljes funkcióira és teljesítményére.
(App Service) Kihasználhatja a kedvezmények előnyeit, és megismerheti az alábbiak előnyben részesített díjszabását:

- Alacsonyabb környezetek fejlesztési/tesztelési tervekkel.

- Azure-foglalások és Azure-megtakarítási csomagok dedikált számítási feladatokhoz, amelyeket a Prémium v3 szinten és az App Service-környezetben épít ki.

Használjon fenntartott példányokat olyan stabil számítási feladatokhoz, amelyek kiszámítható használati mintákkal rendelkeznek.		 A fejlesztési/tesztelési csomagok kedvezményes díjszabást biztosítanak az Azure-szolgáltatásokhoz, ami költséghatékonysá teszi őket a nem gyártási környezetekben.

Fenntartott példányokkal előre fizethet a számítási erőforrásokért, és jelentős kedvezményeket kaphat.
(Web Apps) Az App Service-erőforrások által felmerülő költségek monitorozása . Futtassa a költségelemzési eszközt az Azure Portalon.

Költségvetések és riasztások létrehozása az érdekelt felek értesítéséhez.		 A költségnövekedéseket, a hatékonysághiányt vagy a váratlan kiadásokat korai időben azonosíthatja. Ez a proaktív megközelítés segít költségvetési ellenőrzésekkel megelőzni a túlterjedést.
(App Service) Skálázás, amikor csökken az igény. A skálázáshoz skálázási szabályokat definiáljon, hogy csökkentse a példányok számát az Azure Monitor. Megelőzheti a beszivárgást, és csökkentheti a szükségtelen kiadásokat.

Működési kiválóság

Az operatív kiválóság elsősorban a fejlesztési eljárásokra, a megfigyelhetőségre és a kiadáskezelésivonatkozó eljárásokra összpontosít.

A Működési kiválóság tervezési alapelvei magas szintű tervezési stratégiát biztosítanak a számítási feladatok működési követelményeihez kitűzött célok eléréséhez.

Munkaterhelés tervezési ellenőrzőlistája

Indítsa el a tervezési stratégiát az Operational Excellence tervezési felülvizsgálati ellenőrzőlistája alapján a Web Appshez kapcsolódó megfigyelhetőségi, tesztelési és üzembe helyezési folyamatok meghatározásához.

  • Kiadások kezelése: Az üzembehelyezési pontok használatával hatékonyan kezelheti a kiadásokat. Üzembe helyezheti az alkalmazást egy ponton, elvégezheti a tesztelést, és ellenőrizheti annak működését. Az ellenőrzés után zökkenőmentesen áthelyezheti az alkalmazást éles környezetbe. ** Ez a folyamat nem jár többletköltséggel, mivel ugyanabban a virtuális gép környezetben fut, mint az éles példány.

    Használja a felcserélést az előzetes verzió (többfázisú felcserélés) funkcióval. Az előzetes verzióval való felcserélés lehetővé teszi az alkalmazás tesztelését az előkészítési pontokon az éles beállításoknak megfelelően, valamint az alkalmazás bemelegítését is. A tesztek elvégzése és az összes szükséges útvonal bemelegítését követően elvégezheti a felcserélést. Ezt követően az alkalmazás megkapja az éles forgalmat újraindítás nélkül.

  • Automatizált tesztek futtatása: Mielőtt előlépteti a webalkalmazás kiadását, alaposan tesztelje annak teljesítményét, funkcióit és más összetevőkkel való integrációját. Az Azure Load Testing használata. Integrálható az Apache JMeterrel, amely a teljesítménytesztelés népszerű eszköze. Ismerje meg az automatizált eszközöket más típusú tesztelésekhez, például a Fantomot a funkcionális teszteléshez.

  • Üzembe helyezés automatizálása: A folyamatos integrációs és folyamatos üzembehelyezési folyamatokat az Azure DevOps vagy a GitHub Actions használatával automatizálhatja az üzembe helyezéseket, és csökkentheti a manuális munkát. További információ: Folyamatos üzembe helyezés az App Service-ben.

  • Nem módosítható egységek üzembe helyezése: Az Üzembehelyezési bélyegek minta implementálása az App Service nem módosítható bélyegbe való felosztásához. Az App Service támogatja a tárolók használatát, amelyek eredendően nem módosíthatók. Fontolja meg az App Service-webalkalmazás egyéni tárolóinak alkalmazását.

    Minden egyes modul egy önálló egységet jelöl, amelyet gyorsan fel- vagy le skálázhat. A bélyegen alapuló egységek ideiglenesek és állapot nélküliek. Az állapot nélküli kialakítás leegyszerűsíti a műveleteket és a karbantartást. Ez a megközelítés ideális a kritikus fontosságú alkalmazásokhoz. További információ: Kritikus fontosságú alapkonfiguráció az App Service.

    Használjon infrastruktúra kódként (IaC) technológiát, például a Bicep-et, hogy ismételhető és konzisztenciával rendelkező egységeket bélyegezze ki.

  • Az éles környezetek biztonságának megőrzése: Hozzon létre külön App Service-csomagokat éles és előzetes környezetek futtatásához. Ne végezzen közvetlen módosításokat az éles környezetben, hogy biztosítsa a stabilitást és a megbízhatóságot. A különálló példányok rugalmasságot biztosítanak a fejlesztéshez és teszteléshez, mielőtt a változtatásokat bevezetik az éles környezetbe.

    Alacsony környezetek használata az új funkciók és konfigurációk izolált feltárásához. A fejlesztési és tesztelési környezetek rövid élettartamának megőrzése.

  • Tanúsítványok kezelése: Egyéni tartományok esetén TLS-tanúsítványokat kell kezelnie.

    A tanúsítványok beszerzéséhez, megújításához és érvényesítéséhez szükséges folyamatokkal rendelkezhet. Ha lehetséges, töltse ki ezeket a folyamatokat az App Service-be. Ha saját tanúsítványt használ, annak megújítását kezelnie kell. Válasszon ki egy, a biztonsági követelményeknek leginkább megfelelő megközelítést.

Recommendation Benefit
(Web Apps) Figyelje a példányok állapotát , és aktiválja a példányállapot-mintavételeket.

Állítson be egy adott elérési utat az állapotadat-mintavételi kérelmek kezeléséhez.		 A problémákat azonnal észlelheti, és megteheti a szükséges lépéseket a rendelkezésre állás és a teljesítmény fenntartása érdekében.
(Web Apps) Diagnosztikai naplók engedélyezése az alkalmazás és az instance számára.

A gyakori naplózás lelassíthatja a rendszer teljesítményét, növeli a tárolási költségeket, és kockázatot jelenthet, ha nem biztonságos hozzáféréssel rendelkezik a naplókhoz. Kövesse az alábbi ajánlott eljárásokat:

- Naplózza a megfelelő szintű információkat.

– Megőrzési szabályzatok beállítása.

- Őrizze meg az engedélyezett hozzáférés és a jogosulatlan kísérletek naplózási nyomait.

- A naplók kezelése adatokként és adatvédelmi vezérlők alkalmazása.		 A diagnosztikai naplók értékes betekintést nyújtanak az alkalmazás viselkedésébe. A forgalmi minták monitorozása és az anomáliák azonosítása.
(Web Apps) Használja ki az App Service által felügyelt tanúsítványokat a tanúsítványkezelés Azure-ba való kiszervezéséhez. Az App Service automatikusan kezeli az olyan folyamatokat, mint a tanúsítványbeszerzés, a tanúsítvány-ellenőrzés, a tanúsítványmegújítás és a tanúsítványok importálása a Key Vaultból. Másik lehetőségként töltse fel a tanúsítványt a Key Vaultba, és engedélyezze az App Service-erőforrás-szolgáltatónak a hozzáférését.
(App Service) Az alkalmazásváltozások ellenőrzése az előzetes (teszt) környezetben, mielőtt felcserélné az éles környezettel. Kerülje el az állásidőt és a hibákat.

Ha a korábban üzembe helyezett éles verziót egy ponton tartja, visszaállhat az utolsó ismert jó állapotra, ha problémát észlel az üzembe helyezés után.

Lehetővé teszi annak biztosítását, hogy az összes példány felmelegedjen, mielőtt felcserélődik az éles környezetbe, hogy elkerülje az átmeneti, hidegindítással kapcsolatos üzembe helyezéssel kapcsolatos problémákat.

Teljesítményhatékonyság

A teljesítményhatékonyság arról szól, a felhasználói élmény fenntartása akkor is, ha a kapacitás kezelésével növekszik a terhelés. A stratégia magában foglalja az erőforrások skálázását, a lehetséges szűk keresztmetszetek azonosítását és optimalizálását, valamint a csúcsteljesítmény optimalizálását.

A Teljesítményhatékonyság tervezési alapelvei magas szintű tervezési stratégiát biztosítanak e kapacitáscélok eléréséhez a várt használattal szemben.

Munkaterhelés tervezési ellenőrzőlistája

Kezdje el a tervezési stratégiáját a tervezési felülvizsgálati ellenőrzőlista alapján, amely a Teljesítményhatékonyságtémakör alapját képezi. Alapkonfiguráció meghatározása a Web Apps fő teljesítménymutatói alapján.

  • Teljesítménymutatók azonosítása és figyelése: Állítsa be az alkalmazás fő mutatóinak céljait, például a bejövő kérelmek mennyiségét, az alkalmazás által a kérelmekre való válaszadáshoz szükséges időt, a függőben lévő kérelmeket és a HTTP-válaszok hibáit. Vegye figyelembe a főbb mutatókat a számítási feladat teljesítménykonfigurációjának részeként.

    Rögzítse a teljesítménymutatók alapját képező App Service-metrikákat. Naplók gyűjtése az erőforrás-használat és a tevékenységek megismeréséhez. Az alkalmazásteljesítmény-monitorozási eszközök, például az Application Insights használatával gyűjtheti és elemezheti az alkalmazás teljesítményadatait. További információ: App Service monitorozási adatreferenciája.

    Tartalmazzon kódszintű rendszerezést, tranzakciókövetést és teljesítményprofilozást.

  • Kapacitás értékelése: Különböző felhasználói forgatókönyvek szimulálása a várt forgalom kezeléséhez szükséges optimális kapacitás meghatározásához. A Terheléstesztelés használatával megismerheti, hogyan viselkedik az alkalmazás különböző terhelési szinteken.

  • Válassza ki a megfelelő szintet: Használjon dedikált számítást éles számítási feladatokhoz. A prémium v3-szintek nagyobb SKU-kat biztosítanak nagyobb memóriával és processzorkapacitással, több példánysal és további funkciókkal, például zónaredundanciával. További információ: Premium v3 tarifacsomag.

  • Skálázási stratégia optimalizálása: Ha lehetséges, használja az automatikus skálázást ahelyett, hogy manuálisan módosítaná a példányok számát az alkalmazás terhelésének változásakor. Az automatikus skálázással az App Service előre meghatározott szabályok vagy eseményindítók alapján módosítja a kiszolgálókapacitást. Győződjön meg arról, hogy megfelelően teszteli a teljesítményt, és beállítja a megfelelő szabályokat a megfelelő eseményindítókhoz.

    Ha a kezdeti beállítás során előnyben részesíti az egyszerűséget, használjon olyan automatikus skálázási beállítást, amely csak beállítási korlátokat igényel, szabályok definiálása nélkül.

    Elegendő erőforrás áll rendelkezésre az optimális teljesítmény biztosításához. Az erőforrások megfelelő kiosztása a teljesítménycélok fenntartása érdekében, mint például a válaszidő vagy az adatátvitel. Vegye fontolóra az erőforrások túlallokálását szükség esetén.

    Az automatikus skálázási szabályok meghatározásakor figyelembe kell venni az alkalmazás inicializálásához szükséges időt. Vegye figyelembe ezt a többletterhelést, amikor minden méretezési döntést meghoz.

  • Gyorsítótárazás használata: Ha olyan erőforrásból szeretne adatokat lekéreni, amely nem változik gyakran, és a hozzáférés költséges, hatással van a teljesítményre. Az összetett lekérdezések, beleértve az illesztéseket és a több keresést is, hozzájárulnak a futtatókörnyezethez. Gyorsítótárazással minimalizálhatja a feldolgozási időt és a késést. Gyorsítótárazhatja a lekérdezési eredményeket, hogy elkerülje az adatbázisba vagy a háttérrendszerbe irányuló ismétlődő utakat, és csökkentse a későbbi kérések feldolgozási idejét.

    A helyi és az elosztott gyorsítótár számítási feladatban való használatával kapcsolatos további információkért lásd a gyorsítótárazást.

  • Tekintse át a teljesítményeltérés-gátlókat: Annak érdekében, hogy a webalkalmazás az üzleti követelményeknek megfelelően teljesítsen és skálázható legyen, kerülje a tipikus antipatterneket. Az alábbi táblázat az App Service által kijavított antipatterneket ismerteti.

    Antipattern Description
    foglalt előtér- Az erőforrás-igényes tevékenységek növelhetik a felhasználói kérések válaszidejének időtartamát, és nagy késést okozhatnak.

    A jelentős erőforrásokat használó folyamatok áthelyezése külön háttérrendszerbe. Üzenetközvetítő használatával várólistára állíthatja az erőforrás-igényes feladatokat, amelyeket a háttérrendszer aszinkron módon felvesz.
    Nincs gyorsítótárazás A késés csökkentése érdekében egy köztes gyorsítótárból érkező kérések kiszolgálása a háttéradatbázis előtt.
    Zajos szomszéd A több-bérlős rendszerek erőforrásokat osztanak meg a bérlők között. Az egyik bérlő tevékenysége negatív hatással lehet egy másik bérlő rendszerhasználatára. Az App Service Environment egy teljesen elkülönített és dedikált környezetet biztosít az App Service-alkalmazások futtatásához.

Konfigurációs javaslatok

Recommendation Benefit
(App Service) Engedélyezze az Always On beállítást, ha az alkalmazások egyetlen App Service-csomagot osztanak meg. Az App Service-alkalmazások inaktív állapotban automatikusan inaktívvá válnak az erőforrások megóvásához. A következő kérés hidegindítást vált ki, ami időtúllépést okozhat. Az alkalmazás soha nem lesz eltávolítva, ha az Always On engedélyezve van.
(Web Apps) Fontolja meg a HTTP/2 használatát alkalmazásokhoz a protokoll hatékonyságának javítása érdekében. HTTP/2 http/1.1-en keresztüli kiválasztása, mert a HTTP/2 teljes mértékben multiplexeli a kapcsolatokat, újra felhasználja a kapcsolatokat a többletterhelés csökkentése érdekében, és tömöríti a fejléceket az adatátvitel minimalizálása érdekében.

Tradeoffs

Ha a pillér ellenőrzőlistáiban szereplő megközelítéseket használja, előfordulhat, hogy kompromisszumot kell hoznia a tervezéssel. Íme néhány példa az előnyökre és hátrányokra.

Sűrűség és elkülönítés

  • Nagyobb sűrűség: Több alkalmazás áthelyezése ugyanabban az App Service-csomagban az erőforrások minimalizálása érdekében. Minden alkalmazás olyan erőforrásokat oszt meg, mint a processzor és a memória, ami pénzt takaríthat meg, és csökkentheti a működési összetettségét. Ez a módszer az erőforrás-használatot is optimalizálja. Az alkalmazások használhatnak üresjárati erőforrásokat egy másik alkalmazásból, ha a terhelési minták idővel változnak.

    Vegye figyelembe a hátrányokat is, például az erőforrás-versengést. Az alkalmazások használatának kiugró száma vagy instabilitása például befolyásolhatja a többi alkalmazás teljesítményét. Az egyik alkalmazásban előforduló incidensek más alkalmazásokat is áthatnak a megosztott környezetben, ami hatással lehet a biztonságra. A magas rendelkezésre állást és teljesítményt igénylő kritikus alkalmazások esetében az olyan elkülönített környezetek, mint az App Service Environment v3 , dedikált erőforrásokat biztosítanak, de magasabb költséggel. Fontolja meg a megosztott környezetek használatát nem kritikus fontosságú számítási feladatokhoz és elszigetelt környezetekhez a kritikus fontosságú alkalmazásokhoz.

  • Magasabb elkülönítés: Az elkülönítés segít megelőzni az interferencia kialakulását. Ez a stratégia a biztonságra, a teljesítményre és a fejlesztési, tesztelési és éles környezetek elkülönítésére vonatkozik.

    Az App Service Environment jobb felügyeletet biztosít a biztonság és az adatvédelem felett, mivel minden alkalmazás saját biztonsági beállításokkal rendelkezhet. A környezet tartalmazhat behatolásokat, mert az elkülönítés korlátozza a robbanás sugarát. Az erőforrás-versengés teljesítmény szempontjából minimálisra csökken. Az elkülönítés lehetővé teszi a független skálázást az adott igény és az egyéni kapacitástervezés alapján.

    Hátránya, hogy ez a megközelítés drágább, és működési szigort igényel.

Megbízható skálázási stratégia

A jól definiált skálázási stratégia segít biztosítani, hogy az alkalmazás a teljesítmény veszélyeztetése nélkül kezelje a különböző terheléseket. Vannak azonban kompromisszumok a költségeken. A skálázási műveletek időigényesek. Új erőforrások lefoglalásakor az alkalmazást megfelelően inicializálni kell, mielőtt hatékonyan feldolgozhatja a kéréseket. A biztonsági háló biztosításához túlméretezheti az erőforrásokat (vagy előmelegítheti az indítási példányokat). Ezen többletkapacitás nélkül az inicializálási fázisban előfordulhat, hogy a kérések kézbesítése késik, ami hatással van a felhasználói élményre. Az automatikus skálázási műveletek elég korán aktiválhatók ahhoz, hogy az ügyfelek mire az erőforrásokat használják, megfelelő erőforrás-inicializálást tegyenek lehetővé.

Hátrányként a túlméretezett erőforrások többe kerülnek. Minden példányért másodpercenkénti díjat számítunk fel, beleértve az előre elkészített példányokat is. A magasabb szintek közé tartoznak az előmelegített példányok. Határozza meg, hogy a drágább szinteket tartalmazó képességek megérik-e a befektetést.

Redundancia kiépítése

A redundancia rugalmasságot biztosít, de költségekkel is jár. A számítási feladat szolgáltatásiszint-célkitűzései (SLO-k) határozzák meg az elfogadható teljesítményküszöböket. Feleslegessé válik, ha a redundancia meghaladja az SLO követelményeit. Értékelje ki, hogy a túlzott redundancia javítja-e az SLO-kat, vagy szükségtelen összetettséghez ad-e hozzá.

Vegye figyelembe a hátrányokat is. A többrégiós redundancia például magas rendelkezésre állást biztosít, de összetettséget és költséget ad hozzá az adatszinkronizálás, a feladatátvételi mechanizmusok és a régiók közötti kommunikáció miatt. Határozza meg, hogy a zónaredundancia megfelel-e az SLO-knak.

Azure-szabályzatok

Az Azure az App Service-hez és annak függőségeihez kapcsolódó beépített szabályzatok széles halmazát biztosítja. A fenti javaslatok némelyike az Azure Policy használatával ellenőrizhető. Például ellenőrizheti, hogy:

  • Megfelelő hálózati vezérlők vannak érvényben. A hálózati szegmentálást például úgy építheti be, hogy az App Service-t virtuális hálózatinjektálással helyezi el az Azure Virtual Networkben, hogy nagyobb mértékben szabályozhassa a hálózati konfigurációt. Az alkalmazás nem rendelkezik nyilvános végpontokkal, és privát végpontokon keresztül csatlakozik az Azure-szolgáltatásokhoz.

  • Az azonosságellenőrzések érvényben vannak. Az alkalmazás például felügyelt identitásokkal hitelesíti magát más erőforrásokon. Az App Service beépített hitelesítése (vagy Easy Auth) ellenőrzi a bejövő kéréseket.

  • Az olyan funkciók, mint a távoli hibakeresés és az alapszintű hitelesítés le vannak tiltva a támadási felület csökkentése érdekében.

Az átfogó szabályozáshoz tekintse át az App Service beépített Azure Policy-definícióit és a számítási réteg biztonságát esetleg befolyásoló egyéb szabályzatokat.

Azure Advisor-javaslatok

Az Azure Advisor egy személyre szabott felhőtanácsadó, amely segít az Ajánlott eljárások követésében az Azure-üzemelő példányok optimalizálása érdekében.

További információ: Azure Advisor.

Példaarchitektúra

Alapvető architektúra, amely bemutatja a legfontosabb javaslatokat: App Service alaparchitektúra.

Következő lépések

Vegye figyelembe az alábbi cikkeket forrásként, amelyek a cikkben kiemelt ajánlásokat mutatják be.

  • Last updated on