ビジネス メトリックを使用して回復性がある Azure アプリケーションを設計する

ワークロードの可用性の目標

アプリケーションや主要シナリオについて、サービス レベル アグリーメント (SLA)、サービス レベル インジケーター (SLI)、サービス レベル目標 (SLO) などの可用性目標が定義されていますか?

顧客の可用性の期待を理解することは、アプリケーションの全体的な操作を確認するためにきわめて重要です。 たとえば、顧客がアプリケーションの SLO として 99.999% を達成しようと努めている場合、そのアプリケーションに必要な固有の操作アクティビティのレベルは、99.9% の SLO を目標としていた場合よりはるかに高くなります。

使用するソリューション内のワークロードごとに独自のターゲット SLA を定義すれば、アーキテクチャがビジネス要件を満たしているかどうかを判定できます。

コストと複雑さを検討する

他の項目がすべて同じ場合は、可用性が高いほど望ましくなります。 しかし、9 の個数を増やすことを目指すと、コストと複雑さが増大します。 99.99% のアップタイムは、月あたり約 5 分の合計ダウンタイムに換算されます。 ファイブ ナイン (99.999%) の実現のために、複雑さとコストが増える価値はありますか? その答えはビジネス要件によって変わります。

SLA を定義する場合の他の考慮事項を次に示します。

  • 4 つの 9 (99.99%) を実現するには、障害から復旧するために手動による介入に依存することはできません。 アプリケーションには自己診断機能と自己復旧機能が必要です。
  • 4 つの 9 を超えると、SLA を満たすことができるほど迅速に障害を検出することは困難です。
  • SLA を測定する時間枠について考慮します。 この時間枠を短くするほど、許容度は厳格になります。 時間単位または日単位のアップタイムという観点で SLA を定義することは意味がありません。
  • MTBF と MTTR の測定値を考慮します。 SLA が高ければ高いほど、サービスがダウンする可能性は低くなり、サービスをより短時間で回復させる必要があります。
  • アプリケーションの各部分の可用性の目標について顧客から合意を得て、それをドキュメント化します。 そうしないと、顧客の期待を満たす設計にすることはできません。

依存関係を識別する

依存関係マッピングの演習を行って、内部依存関係と外部依存関係を識別します。 たとえば、セキュリティまたは ID (Active Directory など) や、サード パーティーのサービス (支払プロバイダーや電子メール メッセージ サービスなど) に関連する依存関係があります。

単一障害点になったり、ボトルネックを生じさせたりする可能性がある外部依存関係には、特に注意を払ってください。 ワークロードのアップタイム要件が 99.99% でも、SLA が 99.9% のサービスに依存している場合、そのサービスをシステムの単一障害点にしてはなりません。 1 つの救済方法として、サービスが失敗した場合に備えてフォールバック パスを用意します。 あるいは、そのサービス内の障害から復旧するためのその他の手段を実行します。

次の表は、さまざまな SLA レベルで考えられる累積的なダウンタイムの一覧です。

SLA 週あたりのダウンタイム 月あたりのダウンタイム 年あたりのダウンタイム
99% 1.68 時間 7.2 時間 3.65
99.9% 10.1 43.2 8.76 時間
99.95% 5 21.6 4.38 時間
99.99% 1.01 4.32 52.56
99.999% 6 25.9 5.26

重要なシステム フローの特定

重要なシステム フローの理解は、全体的な運用効果を評価するために不可欠です。これを利用して、アプリケーションの正常性モデルを通知する必要があります。 また、これによって、アプリケーションの領域の使用が過剰または過小になっているかどうかがわかります。これは、ビジネス ニーズやコスト目標に合わせて調整する必要があります。

アプリケーション内の重要なサブシステムまたはパスでは、関連するビジネス シナリオと機能の重要性のために、可用性、回復、およびパフォーマンスに関する期待がより高くなることがあります。 これは、このような高いニーズによって、コストが影響を受けるかどうかを理解するのにも役立ちます。

重要性の低いコンポーネントの特定

アプリケーション内の重要性が低いコンポーネントやパスでは、可用性、回復、およびパフォーマンスに関する期待が下がる可能性があります。 重要性が低いコンポーネントでは、パフォーマンスと可用性が低い、低レベルの SKU を選択することで、コストを削減できます。

回復のメトリック

これらの値を取得するには、リスクの評価を実施して、ダウンタイムとデータ損失におけるコストとリスクを確実に把握してください。 これらはシステムの機能要件ではなく、ビジネス要件によって決定する必要があります。

  • 目標復旧時間 (RTO) は、インシデントが発生した後に、アプリケーションに許容する使用不能状態の最大時間です。
  • 回復ポイントの目標 (RPO) は、災害発生時に許容できるデータ損失の最大期間です。

高可用性の設定内の任意の重要なコンポーネントの MTTR 値がシステム RTO を超えた場合、システム内の障害によって、許容できないビジネスの中断が発生する可能性があります。 つまり、定義されている RTO 内でシステムを復元することができなくなります。

可用性のメトリック

これらのメジャーを使用して、冗長性を計画し、顧客の SLA を決定します。

  • 平均復旧時間 (MTTR) とは、障害発生後にコンポーネントを復旧するためにかかる平均時間です。
  • 平均故障間隔 (MTBF) とは、次の障害が発生するまでに合理的に予期されるコンポーネントの稼働時間です。

サービス レベル アグリーメントを理解する

Azure では、サービス レベル アグリーメントに、アップタイムと接続性について Microsoft のコミットメントが示されています。 特定のサービスの SLA が 99.9% の場合は、そのサービスが 99.9% の時間、使用可能であることを期待できます。 サービスの種類によって、SLA もそれぞれ異なります。

また、Azure SLA には、SLA が満たされない場合にサービス クレジットを取得するための規定と、各サービスの 可用性 の詳細な定義も含まれています。 SLA のこの側面は、強制ポリシーとして機能します。

サービス レベル アグリーメント見積もりツール」のサンプルに、アーキテクチャの SLA を計算する方法が示されています。

複合 SLA

複合 SLA では、それぞれの可用性レベルが異なる複数のサービスで、1 つのアプリケーションをサポートする必要があります。 たとえば、Azure SQL Database に書き込む App Service Web アプリについて検討します。 この記事の発行時点で、これらの Azure サービスには次の SLA があります。

  • App Service Web アプリ = 99.95%
  • SQL データベース = 99.99%

このアプリケーションで予想される最大ダウンタイムはどのくらいですか。 いずれかのサービスで障害が発生すると、アプリケーション全体で障害が発生します。 各サービスで障害が発生する可能性は独立しているため、このアプリケーションの複合 SLA は 99.95% × 99.99% = 99.94% です。 これは個々の SLA よりも低い値です。複数のサービスに依存するアプリケーションは潜在的な障害点が多くなるため、これは驚くことではありません。

複合 SLA を改善するには、独立したフォールバック パスを作成する方法があります。 たとえば、SQL Database が使用できない場合は、後で処理できるようにトランザクションをキューに格納します。

Composite SLA

この設計では、データベースに接続できない場合でも、アプリケーションは使用可能な状態です。 ただし、データベースとキューの両方で同時に障害が発生すると、アプリケーションは使用できなくなります。 同時に障害が発生する時間の予測される割合は 0.0001 × 0.001 なので、この組み合わせのパスに関する複合 SLA は次のとおりです。

  • データベース or キュー = 1.0 − (0.0001 × 0.001) = 99.99999%

合計複合 SLA は次のとおりです。

  • Web アプリ and (データベース or キュー) = 99.95% × 99.99999% = \~99.95%

この方法にはトレードオフがあります。 アプリケーション ロジックは複雑になり、キューのコストがかかり、データの一貫性に関する問題も考慮する必要があります。

複数リージョン デプロイの SLA

"複数リージョン デプロイの SLA" では、アプリケーションを複数のリージョンにデプロイすることで、1 つのリージョンのアプリケーションで障害が発生した場合に Azure Traffic Manager を使用してフェールオーバーできるようにする高可用性の方法が必要です。

マルチリージョン デプロイの場合の複合 SLA は次のように計算されます。

  • N は、1 つのリージョンにデプロイされているアプリケーション用の複合 SLA です。
  • R は、アプリケーションがデプロイされているリージョンの数です。

すべてのリージョンでアプリケーションの障害が発生する可能性は ((1 − N) ^ R) と予測されます。 たとえば、1 つのリージョンの SLA が 99.95% の場合:

  • 2 つのリージョンの複合 SLA = (1 − (1 − 0.9995) \^ 2) = 99.999975%
  • 4 つのリージョンの複合 SLA = (1 − (1 − 0.9995) \^ 4) = 99.999999%

Traffic Manager の SLA も要因になります。 アクティブ/パッシブ構成ではフェールオーバーは瞬時に完了しないので、フェールオーバー時にはダウンタイムが発生する可能性があります。 Traffic Manager エンドポイントの監視とフェールオーバーに関するページを参照してください。