この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

この記事ではAzure Well-Architected Framework 5つの柱の一つ、信頼性 について記載します。
Well-Architected Framework そのものについては以下を参照ください。
[Azure Well-Architected Framework] パフォーマンスの品質向上のためのチェックリスト(設計編)

信頼性 とは

Well-Architected Framework における信頼性とは、システムが障害から回復し、機能し続ける能力のこと を指します。クラウドでは従来のオンプレミスシステムのように障害発生を完全に防止するのではなく、障害発生時の影響を最小限に抑えることを目標とします。クラウドのアプリケーション設計においては信頼性の要素が追加されているかどうかの確認を行うことが重要となります。
信頼性の高いワークロードとは、回復性と可用性の両方を備えていることを言います。

回復性	システムが障害から回復して機能し続ける能力。障害発生後にアプリが完全に機能する情報に戻すことを目標とする。
可用性	ユーザーが必要な時にワークロードにアクセスできるようにしておく能力。

信頼性の原則

Well-Architected Framework には5つの柱それぞれに基本原則が存在します。アプリケーションに信頼性が備わっている場合はこの基本原則に則っていると言えます。
信頼性の基本原則は次の通り。内容は原文から多少書き換えを行っています。

カテゴリ	基本原則　※原文を翻訳	説明
設計	可用性と回復目標の定義とテスト	サービスレベルアグリーメント（SLA）やサービスレベル目標（SLO）などの可用性の目標を定義すること。および目標復旧時間（RTO）や目標復旧時点（RPO）などの回復性の目標を定義すること。 またアプリケーションの信頼性(可用性・回復性)がビジネス要件(上記で定めた目標)に適合していることを確認するためにテストを実施すること。
設計	障害に耐えられるようにアプリケーションを設計する	アプリケーションが定義された信頼性の目標に沿って、障害などによる停止から回復ができる設計となっていること。
設計	対象のリージョンで必要な容量とサービスを利用できるようにする	Azureのサービスと容量はリージョンによって異なる可能性があるため、対象のリージョンが必要な機能を提供しているかどうかを確認すること。
設計	災害復旧の計画	災害復旧(DR)は、壊滅的な障害が発生した後にアプリケーションの機能を復元するプロセス。 サービスによっては障害があっても機能低下した状態で継続できる場合もあるが、耐えられない場合もある。既存アーキテクチャーのDR計画を検討する必要がある。
設計	信頼性要件を満たすようにアプリケーションプラットフォーム・データプラットフォームを設計する	アプリケーション全体の信頼性を確保するために、アプリケーションプラットフォーム・データプラットフォームの回復性と可用性を設計すること。
テスト	エラーからの回復	回復性のあるアプリケーションは、最新のクラウドアプリケーションコードパターンを活用することで、エラーから自動的に回復できるようにすること。 自動修復機能は非常に高度である。
設計	ネットワークと接続が信頼性の要件を満たしていることを確認する	潜在的なネットワークのボトルネックまたは障害点を特定して軽減することで、回復性のあるアプリケーションコンポーネントが通信できる信頼性の高いスケーラブルな基盤がサポートされる。
設計	スケーラビリティとパフォーマンスの信頼性を考慮	回復性のあるアプリケーションは、負荷の変化に応じて自動的にスケーリングして、アプリケーションの可用性を維持し、パフォーマンス要件を満たすことができる必要がある。
設計	セキュリティ関連のリスクに対処する	セキュリティ関連のリスクを特定して対処することで、予期しないセキュリティの露出によって引き起こされるアプリケーションのダウンタイムとデータ損失を最小限に抑えること。
テスト	運用プロセスの定義、自動化、およびテスト	ロールフォワードやロールバックなど(回復手法)のアプリケーション展開の運用プロセスを定義し、十分に自動化し、テストして、信頼性の目標との整合性を確保する必要があります。
テスト	フォールトトレランス(※)のテスト ※問題が起こることを前提とする仕組み	アプリケーションのワークロードをテストして、定義された信頼性目標に対する信頼性を検証する必要があります。
監視	アプリケーションの状態を監視および測定する	アプリケーションの可用性を監視および測定することは、アプリケーション全体の状態を認定し、定義された信頼性目標に向けて前進するために不可欠です。

信頼性の設計

信頼性の備わったアプリケーションを設計するためには以下を検討する必要があります。

• チェックリスト
  信頼性を念頭に置いてアプリをどのように設計しているか確認
• 可用性・回復性の目標
  可用性、回復性の目標からワークロードのアップタイムとダウンタイムを測定
• 非機能要件(アプリプラットフォーム、データプラットフォーム、ネットワーク)
  目標を満たすための要件を確認

チェックリスト

信頼性の高いアプリは事前に定義された稼働率(可用性)を維持する必要があるが、コストとのバランスを取る必要もあります。またアプリが障害から回復できる回復性を持っている必要もあります。以下は信頼性を念頭に置いてアプリをどのように設計しているか、確認のためのチェックリストです。

• ビジネス要件を満たすために、可用性とリカバリの目標を定義する。
• 要件を収集し、アプリに回復性と可用性を組み込む。
• アプリケーションとデータプラットフォームが信頼性の要件を満たしていることを確認する。
• 可用性を促進するために接続パスを構成する。　※ネットワークの可用性
• 必要に応じて可用性ゾーンを使用して、信頼性を向上させ、コストを最適化する。
• アプリケーションアーキテクチャが障害に対して回復性があることを確認する。
• サービスレベルアグリーメントの要件が満たされない場合はどうなるか？を理解しておくこと。
• 回復性を構築するために、システムで発生する可能性のある障害点を特定する。
• アプリケーションが依存関係がなくても動作できることを確認する。
  
  

可用性・回復性の目標

可用性、回復性の目標からワークロードのアップタイムとダウンタイムを測定ができます。加えてビジネス継続のための信頼性要件を確認することができます。以下は要件を収集するための質問例です。

• どのくらいのダウンタイムが許容されるか？
• 潜在的なダウンタイムはあなたのビジネスにどのくらいの費用がかかるか？
  どのくらいのダウンタイムが許容されるか？
• 顧客の可用性要件は何か？
• アプリケーションの高可用性を実現するためにいくら投資できるか？
• リスクとコストはどのくらいか？

これらの要件を収集し、以下を決定します。

• ワークロードのアップタイムの許容レベル
• ワークロードを利用できない期間と、災害時に失われる可能性のあるデータの量

これらを踏まえてAzureサービスを使用して信頼性を向上させて、ワークロードのアプリケーション状態を評価します。

可用性の目標

以下を考慮して運用するアプリケーションの目標とするSLAを決定します。

• Azure SLAを使用してアプリや主要シナリオの複合SLAを計算しているか？
  アーキテクチャーを確認し各AzureサービスのSLAを確認し、複合SLAを計算する。それが期待通りなのかどうかを確認する。
  https://docs.microsoft.com/ja-jp/azure/architecture/framework/resiliency/business-metrics#composite-slas
• システムがディザスタリカバリモードで実行されているときに、可用性の目標を考慮するか？
  DR環境を構成していたとして、仮に障害が発生してDRモードで実行している場合。その環境の可用性目標は何であるか確認する。
• SLAを満たさないことで金銭的費用などのペナルティがあるか？
  可用性の目標が満たされない場合の結果は何であるか確認する。

回復性の目標

災害や障害などのインシデント発生時の目標復旧時間（RTO）と目標復旧時点（RPO）を決めます。
RTO：インシデント後にアプリケーションが利用できない最大許容時間
RPO：災害時に許容できるデータ損失の最大期間

非機能要件

アプリプラットフォーム、データプラットフォーム、ネットワーク それぞれについて非機能要件を確認するための観点を記載します。

アプリケーションプラットフォームの要件

アプリケーションの非機能要件を確認するために以下を確認します。

• 使用するAzureサービスのSLAを確認する
• ゾーンの使用で要件をカバーできるか確認する
• 複数リージョンへの展開が必要な場合はペアリージョンを確認する(日本は東日本と西日本)
  https://docs.microsoft.com/en-us/azure/availability-zones/cross-region-replication-azure
• 可用性セットと可用性ゾーンについて
  可用性セットは、含まれている仮想マシンインスタンスをAzureリージョン内の複数の障害ドメインと更新ドメインに分散する必要があることをAzureに通知する論理構造です。可用性ゾーンは、Azureリージョン内の複数のデータセンターにレプリカインスタンスをデプロイできるようにすることで、仮想マシンの障害レベルを物理データセンターに引き上げます。

また以下について考慮します。

• アプリケーションは2つ以上のアプリケーションプラットフォームノードでホストされているか？
  信頼性確保のためにはアプリを2つのノードにホストして単一障害点を無くすことが重要。利用はn+1である。 nはアプリの可用性とパフォーマンス要件をサポートするために必要なインスタンス数。ただしその分コストは増加する。
• リージョン、ゾーン、またはネットワークが停止した場合、クライアントトラフィックはどのようにアプリケーションにルーティングされるか？
  

データプラットフォームの要件

データプラットフォームの非機能要件を確認するために以下を確認します。

• ゾーン間またはペアのリージョン間でデータを複製することにより、アプリの可用性目標をサポートすることができる
• バックアップからデータを復元する機能により、データ破損からの回復に備えられる
• ゾーンおよびリージョンの障害に対応するには、バックアップをゾーンやリージョン間で保存する必要がある
• データ復元プロセスを定義およびテストし、アプリケーション状態を確認する
• リージョン、ゾーン、またはネットワークが停止した場合に、アプリケーショントラフィックがデータソースにどのようにルーティングされるかを検討する
  

ネットワークの要件

ネットワークの非機能要件を確認するために以下を確認します。

• リージョン間でトラフィックやフェイルオーバーを分散するために使用されるグローバルロードバランサーを使用する。複数のリージョンにデプロイされた外部向けアプリにリクエストを分散できる。そのためリージョン間でフェールオーバーに対応できる。
• クロスプレミス接続（ExpressRouteまたはVPN）の場合は、異なるリージョンからの冗長接続があることを確認してください。例えばExpressRouteのバックアップパスとしてサイト間VPN接続を使用する
• データパス(経路)からすべての単一障害点を排除します。
  ※シングルインスタンスネットワーク仮想アプライアンス（NVA）は、Azureまたはオンプレミスにあるかは問わない

Well-Architected Frameworkの基本原則のうちの一つ、信頼性について記載しました。既存のワークロードが信頼性を備えているかどうかチェックするためにご利用いただければと思います。