Előkészítés

Befejeződött

Saját fejlesztéseket fog hozzáadni egy meglévő architektúrához, amely megfelel a szervezet magas megbízhatósági követelményeinek. Itt bemutatjuk a gyakorlatok sikerességéhez szükséges háttérkörnyezetet.

Problémakörnyezet

A Contoso Cipőknek készen kell állniuk a következő nagy profilú termékbevezetésre, ami várhatóan jelentősen növeli a forgalmat. Az elmúlt két évben több incidens is történt, ami miatt a webhely akár fél napig is offline állapotban volt. A rendszert nem tesztelték teljesen a fejlesztői/tesztelési környezetben, és néhány hiba éles környezetben ásott. A hibaelhárítás és a szervizelés hosszú ideig tartott, mert az operátorok nem tudták gyorsan azonosítani a kiváltó okokat.

Voltak kihívások, amikor bizonyos összetevők nem érhetők el. A számítási vertikális felskálázási műveletek az Azure Key Vault helytelen konfigurálásakor voltak hatással. Emellett nincsenek stratégiák a regionális kimaradásokra vonatkozóan. Egy közelmúltbeli incidens során az egész nyugat-európai régió leállt. Mivel a számítási feladat csak abban a régióban futott, a vállalatnak pénzügyi veszteséget kellett viselnie, amíg a régió biztonsági mentésre nem került.

Aktuális architektúra

Ahhoz, hogy ezt a kihívást teljesíteni tudja, jól ismernie kell a Contoso Shoes jelenlegi architektúráját. Koncentráljunk az API-rétegükre.

Egy webalkalmazás alapszintű architektúrájának diagramja.

Összetevők

Az architektúra összes összetevője egyetlen régióban van üzembe helyezve.

  • Azure-alkalmazás szolgáltatáscsomagok A standard S2 termékváltozat biztosítja az alkalmazást üzemeltető számítási platformot. Az automatikus skálázás engedélyezve van. A fejlesztői környezet az alapszintű B1 termékváltozatot használja.

  • Azure-alkalmazás szolgáltatás biztosítja az API-kódot tárolóban futtató alkalmazásplatformot. Az App Service-hitelesítés funkció engedélyezve van az engedélyezéshez.

  • Az üzembehelyezési pontok lehetővé teszik az üzembe helyezést, majd felcserélheti az éles üzembe helyezéssel. Csak éles környezetben használják őket.

  • Az Azure Container Registry tárolja a tárolóalapú API-kódot, és a rendszer folyamatos integrációs/folyamatos kézbesítési (CI/CD) folyamatokon keresztül küldi el, amelyet a számítási feladatokért felelős csapat hoz létre és kezel. Az éles és a fejlesztői/tesztelési környezet egyaránt a tárolóregisztrációs adatbázist használja.

  • Az SQL API-val rendelkező Azure Cosmos DB a számítási feladathoz kapcsolódó összes állapotot tárolja. A Cosmos DB-adatbázisfiók egyetlen adatbázissal rendelkezik, amely néhány tárolót tartalmaz a megosztott átviteli sebesség modellben. Az Azure Cosmos-fiók kiszolgáló nélküli kapacitásmódot használ. Van egy példány az éles környezetben, egy pedig fejlesztési/tesztelési célra.

  • Az Azure Key Vault tárolja az API-hoz szükséges titkos kulcsokat, hogy http POST-hívást kezdeményezhessenek egy külső, külső API-hoz egy kérési folyamat részeként. Az alkalmazás egy Key Vault-referencián keresztül fér hozzá a titkos kulcsokhoz a Azure-alkalmazás Szolgáltatás alkalmazáskonfigurációjában. Az éles környezetben egy Key Vault, egy pedig fejlesztési/tesztelési célokra használható.

  • Az Azure Log Analytics egységes fogadóként szolgál a megoldásban használt összes összetevő naplóinak és metrikáinak tárolására az Azure Diagnostics összes beállításához. Egy munkaterület van éles környezetben, egy pedig fejlesztési/tesztelési célokra.

  • Azure-alkalmazás Insights a telemetriai adatok és naplók API-ból való rögzítésére szolgál. Az Application Insights az önálló módot használja, nem dedikált log analytics-munkaterületre való írást. Az éles és fejlesztői/tesztelési példányok nem közösek.

  • Az Azure Pipelines a CI/CD-hez használatos, amely létrehozza, teszteli és üzembe helyezi a számítási feladatot az előkészítési és éles környezetekben. A számítási feladatokat kezelő csapat kezeli a folyamatokat, amelyek a megoldás összes infrastruktúráját is kezelik. A Bicep a kódként használható infrastruktúra (IaC) technológiájának kiválasztása.

Tervezési megfontolások

Az összetevők listájában az üzembe helyezési bélyeg olyan szolgáltatásokból áll, amelyek részt vesznek egy kérés feldolgozásában. Ezek a szolgáltatások közé tartozik az App Services, az API-kód és a Cosmos DB. A bélyeg nem funkcionális összetevőket is tartalmaz: Key Vault és Container Registry. Az alkalmazás külső féltől függ egy teljesítmény- és rugalmassági keretrendszertől. A rendszer által felügyelt identitások a bélyeg összetevői között használatosak.

A bélyegzőben az App Services úgy van konfigurálva, hogy a terhelés alapján automatikusan skálázható legyen.

A rendszer külön környezeteket használ az éles környezetekhez és a fejlesztéshez/teszteléshez. Az éles környezet az App Service-csomag Standard termékváltozatát használja. A vállalat ezt a döntést hozta, hogy az alkalmazást előre meg tudja elővenni egy pontra, mielőtt éles környezetben üzembe helyeznénk. A fejlesztési/tesztelési környezet az alapszintű termékváltozatot használja a költségoptimalizáláshoz. Mindkét környezet saját szolgáltatáspéldányokkal rendelkezik. A környezetek csak a Tárolóregisztrációs adatbázist osztják meg.

A tárolóalapú API-kód egyetlen, az App Service-ben futó tárolórendszerképben lesz kézbesítve. Az API több HTTP-végpontot is használ, amelyet a különböző előtérrendszerek olvasáshoz és íráshoz egyaránt használnak. A frontendek nem tartoznak a modul hatókörébe, de a helyzet kritikus állapotának szempontjából nagy képben vannak a hatókörben. A kód az Application Insights segítségével lett kialakítva néhány alapszintű telemetriai adat rögzítéséhez. A kódot fejlesztő csapat az API-tároló lemezképéhez és a CI/CD-folyamatokhoz tartozó CI/CD-folyamatot is kezeli.

Kompromisszumok

Azonban, mint minden, vannak kompromisszumok a jelenlegi architektúra. Az üzleti követelmények a megbízhatóság és a műveletek helyett a költségoptimalizálást részesítik előnyben. A költségkorlátok megtartása érdekében az architektúra nem fejlődött. Az összetevők rövidek lesznek, amikor kihasználják a platform által kínált megbízhatósági képességeket. A számítási termékváltozat kiválasztása például megakadályozza, hogy a számítási feladat a rendelkezésre állási zónákat használja. Telemetria esetén az Application Insights egy régebbi verzióját használjuk, amely nem integrálva van a Log Analyticsszel.

Emellett a számítási feladatokhoz való hozzáférés túlságosan átható. Virtuális hálózati integráció nélkül például az összes Azure-szolgáltatás közvetlenül elérhető a nyilvános interneten keresztül.

A megoldás fejlesztésekor az alkalmazásfejlesztő csapat egyetlen Azure-előfizetést használt, amelyben a dev/test és az éles környezet ugyanabban az előfizetésben található, hogy megkönnyítse az eszközök használatát a DevOps-csapatok számára. Az éles erőforrások és a fejlesztési/tesztelési erőforrások azonban nem különülnek el teljesen. Egyes erőforrások meg vannak osztva a két környezet között, bár külön előfizetést kaptak a Contoso Shoes többi megoldásától.

Emellett a fejlesztői/tesztelési környezet egy olyan környezet, amely a fejlesztési és minőségbiztosítási csapat összes tagja között meg van osztva. A választás indokolt volt, mivel a csapatok mérete és a köztük lévő koordináció nem igényelt magasabb fokú elkülönítést. A csapat és a megoldás fejlődésével az egyetlen fejlesztői/tesztelési környezet egyre összetettebbé tette az integrációt, ahogy a munkafolyamat életciklusai ütköztek. A változás és annak a megbízhatóságra gyakorolt hatása drága volt.

Projekt specifikációja

A vállalat képességeket szeretne hozzáadni a megoldásarchitektúrához, hogy képes legyen kezelni a várható terhelésnövekedést. Az alábbi üzleti követelmények teljesülnek:

  • Az architektúra több régióra való kiterjesztésével képes ellenállni a regionális hibáknak
  • Az ügyfelek élményének javítása az ügyfelek gyorsabb kiszolgálásával egy hozzájuk földrajzilag közelebbi régióban
  • Igazodjon az Azure ütemtervéhez, és használja ki az Azure-szolgáltatások legújabb megbízhatósági funkcióit
  • A problémák korai felismerése és kaszkádolt hatásuk észlelése a rendszerben egy általános állapotmodell létrehozásával

Ezek a követelmények csak a fejlesztési tervek rangsorolását képezik. Az alkalmazás csapata tisztában van azzal, hogy minden tervezési területet figyelembe kell venni, hogy a megoldás megbízhatósága megfeleljen a kritikus fontosságú szabványoknak. Biztos lehet benne, hogy nem fogják leállítani a megoldás és a műveletek fejlesztését, miután segített nekik a közelgő gyakorlatokban tárgyalt szempontokban.

Üdvözöljük a csapatban! Contoso Cipő alig várja, hogy hallja a javaslatokat.

Beállítás

Ebben a Kihívás projektben egy olyan építész szerepét fogja átvenni, aki segít a Contoso Shoesnak a megbízhatósági eredmények elérésében, kezdve az előző szakaszban található rangsorolt elemekkel.

  • Javasoljuk, hogy az architektúra diagramkészítési eszközével vizualizálja az architektúrát.
  • Ehhez a kihíváshoz nincs szüksége Azure-előfizetésre, ha jól ismeri a szolgáltatásokat és azok funkcióit.