Použití obchodních metrik k navrhování odolných aplikací Azure

Cíle dostupnosti úloh

Jsou k dispozici cíle dostupnosti, jako jsou smlouvy o úrovni služeb (SLA), ukazatele na úrovni služby (SLIs) a cíle na úrovni služby (SLO) definované pro aplikace nebo klíčové scénáře?

Porozumění očekávání dostupnosti zákazníků je důležité pro kontrolu celkových operací aplikace. Pokud se například zákazník snaží dosáhnout aplikace na úrovni webu, bude úroveň základní 99.999% provozní aktivity, kterou aplikace vyžaduje, mnohem větší, než kdyby 99.9% byl cílem objektu slo.

Definujte vlastní cílové SLA pro každou úlohu ve vašem řešení, abyste mohli zjistit, jestli architektura splňuje požadavky na podnik.

Zvážení nákladů a složitosti

Všechno ostatní je stejné, vyšší dostupnost je lepší. Ale s tím, jak se snažíte dosáhnout více devíti, získáte náklady a složitost. Doba provozu 99.99% překládá asi na pět minut celkového výpadku za měsíc. Je potřeba mít vyšší složitost a náklady na dosažení pěti devíti? Odpověď závisí na obchodních požadavcích.

Při definování SLA je dobré vzít v úvahu ještě další věci:

• Chcete-li dosáhnout čtyř devíti ( 99.99% ), nemůžete při obnovení ze selhání spoléhat na ruční zásah. Aplikace musí mít schopná se sama monitorovat a opravovat.
• Nad rámec čtyř devíti je obtížné detekovat výpadky dostatečně rychle pro splnění smlouvy SLA.
• Vezměte si třeba časový interval, ve kterém se vaše smlouva SLA měří. Čím menší interval, tím těsnější je tolerance. Nedává smysl definovat smlouvu SLA na základě hodin nebo každodenního provozu.
• Vezměte v úvahu měření MTBF a MTTR. Čím vyšší vaše smlouvy SLA, tím méně často může služba přejít a rychlejší služba musí být obnovena.
• Získejte smlouvu od svých zákazníků pro cíle dostupnosti jednotlivých částí vaší aplikace a zdokumentujte ji. V opačném případě váš návrh nemusí splňovat očekávání zákazníků.

Identifikovat závislosti

Pro identifikaci interních a externích závislostí proveďte cvičení mapování závislostí. Příklady zahrnují závislosti týkající se zabezpečení nebo identity, jako je například služba Active Directory nebo služby třetích stran, jako je zprostředkovatel plateb nebo služba zasílání zpráv o e-mailu.

Věnujte zvláštní pozornost externím závislostem, které by mohly představovat jediný bod selhání nebo způsobují problémová místa. Pokud úloha vyžaduje 99.99% dobu provozu, ale závisí na službě s smlouvou 99.9% SLA, tato služba nemůže být v systému jediným bodem selhání. Jedním z náprav je mít záložní cestu pro případ, že se služba nezdařila. Případně proveďte další opatření k zotavení po selhání této služby.

V následující tabulce jsou uvedeny potenciální kumulativní výpadky pro různé úrovně SLA.

Identifikace důležitých systémových toků

Princip důležitých systémových toků je zásadní pro vyhodnocení celkové provozní efektivity a měl by se používat k informování modelu stavu aplikace. Může taky informovat o tom, jestli jsou oblasti aplikace starší nebo nevyužité a že se mají upravit tak, aby lépe vyhovovaly obchodním potřebám a cenovým cílům.

Kritické subsystémy nebo cesty prostřednictvím aplikace mohou mít větší očekávání kolem dostupnosti, obnovení a výkonu z důvodu závažnosti přidružených obchodních scénářů a funkcí. Pomůže vám to také pochopit, jestli budou náklady ovlivněné z důvodu těchto vyšších potřeb.

Identifikujte méně důležité součásti

Některé méně důležité komponenty nebo cesty prostřednictvím aplikace mohou mít nižší očekávání kolem dostupnosti, obnovení a výkonu. Méně důležité součásti můžou mít za následek snížení nákladů tím, že si vyberete nižší skladové položky s nižším výkonem a dostupností.

Metriky obnovení

Tyto hodnoty jsou odvozeny pomocí vyhodnocení rizik a musí pochopit náklady a riziko výpadku a ztráty dat. Tyto požadavky na systém nejsou funkční a měly by být vydány obchodními požadavky.

• Plánovaná Doba obnovení (RTO) je maximální přijatelná doba, po kterou je aplikace po incidentu nedostupná.
• Cílem bodu obnovení (RPO) je maximální doba ztráty dat, která je během havárie přijatelná.

Pokud hodnota MTTR kterékoli důležité součásti v nastavení s vysokou dostupností přesáhne systém RTO, může selhání systému způsobit nepřijatelný výpadek firmy. To znamená, že systém nebude možné obnovit v rámci definované hodnoty RTO.

Metriky dostupnosti

Tyto míry použijte k naplánování redundance a určení zákaznických SLA.

• Střední doba obnovení (MTTR) je průměrná doba potřebná k obnovení komponenty po selhání.
• Střední doba mezi chybami (MTBF) je doba , po kterou může součást rozumně očekávat poslední časový limit mezi výpadky.

Porozumění smlouvám o úrovni služeb

V Azure smlouva SLA popisuje závazky Microsoftu pro dobu provozu a konektivitu. Pokud je smlouva SLA pro určitou službu 99.9% , měli byste očekávat, že služba bude k dispozici v 99.9% daném čase. Různé služby mají různé SLA.

Smlouva SLA pro Azure zahrnuje také ustanovení pro získání kreditu služby, pokud se smlouva SLA nesplní, a konkrétní definice dostupnosti pro každou službu. Tento aspekt smlouvy SLA funguje jako penále za nedodržení.

Ukázka smlouva SLA Estimator ukazuje, jak vypočítat smlouvu SLA vaší architektury.

Složené smlouvy SLA

Složené SLA zahrnují různé služby, které podporují aplikaci, z nichž každá má různou úroveň dostupnosti. Zvažte například App Service webovou aplikaci, která zapisuje do Azure SQL Database. V době publikace mají tyto služby Azure následující SLA:

• App Service Web Apps = 99.95%
• SQL Database =99.99%

Jaký je maximální výpadek přijatelný pro tuto aplikaci? Pokud selže kterákoli služba, selže celá aplikace. Pravděpodobnost selhání každé služby je nezávislá, a proto je složená smlouva SLA pro tuto aplikaci 99.95% × 99.99% = 99.94% . Je menší než jednotlivé SLA, což není překvapivé, protože aplikace, která spoléhá na více služeb, má více bodů potenciálního selhání.

Složenou smlouvu SLA můžete vylepšit vytvořením nezávislých záložních cest. například pokud SQL Database není k dispozici, vložte transakce do fronty ke zpracování později.

Při tomto řešení je aplikace dostupná i v případě, že se nemůže připojit k databázi. K výpadku dojde, až když bude nedostupná současně databáze i fronta transakcí. Očekávané procento času pro souběžné selhání je 0.0001 × 0.001 , takže složená smlouva SLA pro tuto kombinovanou cestu je:

• Databáze nebo fronta = 1.0 − (0.0001 × 0.001) = 99.99999%

Celková hodnota složené SLA je:

• Webová aplikace a (databáze nebo fronta) = 99.95% × 99.99999% = \~99.95%

Tento přístup má jenom kompromis. Logika aplikace je složitější, platíte za frontu a musíte zvážit problémy s konzistencí dat.

Smlouvy SLA pro nasazení ve více oblastech

Smlouvy SLA pro nasazení ve více oblastech zahrnují techniku vysoké dostupnosti pro nasazení aplikace ve více než jedné oblasti a použití služby Azure Traffic Manager k převzetí služeb při selhání aplikace v jedné oblasti.

Složená smlouva SLA pro nasazení ve více oblastech se vypočítá takto:

• N je složená smlouva SLA pro aplikaci nasazenou v jedné oblasti.
• R je počet oblastí, ve kterých je aplikace nasazená.

Očekávaná pravděpodobnost, že aplikace selže ve všech oblastech současně, je ( (1 − N) \^ R ). Pokud je například smlouva SLA s jednou oblastí 99.95% :

• Kombinovaná smlouva SLA pro dvě oblasti = (1 − (1 − 0.9995) \^ 2) = 99.999975%
• Kombinovaná smlouva SLA pro čtyři oblasti = (1 − (1 − 0.9995) \^ 4) = 99.999999%

Smlouva SLA pro Traffic Manager je také faktorem. Převzetí služeb při selhání není okamžité v konfiguracích aktivní-pasivní, což může způsobit výpadky během převzetí služeb při selhání. Viz Monitorování koncových bodů Traffic Manageru a převzetí služeb při selhání.