信頼性の重要な要素の概要

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 アプリケーション フレームワークに信頼性を設計することで、ワークロードを確実に使用でき、障害から任意の規模で復旧できます。

信頼性のための構築には次のものが含まれます。

• 高可用性アーキテクチャの実現
• データの損失、重大なダウンタイム、ランサムウェアのインシデントなどの障害からの回復

Microsoft Azure Well-Architected Framework で見つかったテネトを使用してワークロードの信頼性を評価するには、Microsoft Azure Well-Architected Review にアクセスします。

詳細については、Azure ワークロードの信頼性について詳しく説明している次のビデオをご覧ください。

従来のアプリケーション開発では、平均故障間隔 (MTBF) の延長に重点が置かれていました。 システムに障害が発生しないようにすることに労力が費やされていました。 クラウド コンピューティングでは、次のいくつかの要因により、異なる考え方が必要になります。

• 分散システムは複雑です。 ある時点で障害が発生すると、システム全体で連鎖する可能性があります。
• クラウド環境のコストは、コモディティ ハードウェアを通じて低く抑えられます。 ハードウェア障害が発生する場合があります。
• アプリケーションは、多くの場合、外部サービスに依存します。 これらのサービスは一時的に利用できないか、大量のユーザーを調整している可能性があります。
• 今日のユーザーは、アプリケーションはオフラインになることなく毎日 24 時間使用できることを期待しています。

これらの要因すべてが、障害が時折発生することを予期し、障害から回復するようにクラウド アプリケーションを設計する必要があることを示しています。 Azure には、次の例のような多くの回復性機能が既にプラットフォームに組み込まれています。

• Azure Storage、Azure SQL Database、Azure Cosmos DB では、可用性ゾーンとリージョン間で組み込みのデータ レプリケーションが提供されます。
• Azure マネージド ディスクは、ハードウェア障害の影響を抑えるために、さまざまなストレージ スケール ユニットに自動的に配置されます。
• 可用性セット内の仮想マシンは、複数の障害ドメインに分散されます。 障害ドメインは、共通の電源とネットワーク スイッチを共有する仮想マシンのグループです。 障害ドメイン間で仮想マシンを分散すると、物理ハードウェア障害、ネットワーク障害、または停電の影響が制限されます。
• 可用性ゾーン は、Azure リージョン内で物理的に分離された場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワーク インフラストラクチャを備えた 1 つまたは複数のデータセンターで構成されています。 可用性ゾーンがあることで、中断なくゾーン間で自動的に切り替わるアプリケーションやデータベースを設計して運用できます。 この方法により、1 つのゾーンが影響を受けた場合の信頼性が確保されます。 詳細については、「 Azure リージョンと可用性ゾーン」を参照してください。

これらの機能を使用する場合でも、アプリケーションに回復性を構築する必要があります。 回復性戦略は、アーキテクチャのすべてのレベルで適用できます。 一時的なネットワーク障害の後にリモート呼び出しを再試行するなど、一部の軽減策は本質的により戦術的です。 セカンダリ リージョンへのアプリケーション全体のフェールオーバーなど、より大局的な緩和策もあります。

一時的な対処による緩和策で状況を大きく改善できます。 リージョン全体で中断が発生することはまれですが、ネットワークの輻輳などの一時的な問題の方が一般的です。 最初にこれらの問題をターゲットにしてください。 障害発生時に障害を検出し、根本原因を特定するために、監視と診断を適切に行うことも重要です。

回復性のあるアプリケーションを設計するときには、ご自分の可用性要件を理解する必要があります。 どの程度のダウンタイムを許容できるのでしょうか。 ダウンタイムの量は、ある程度はコストによって決まります。 起こり得るダウンタイムによって貴社のビジネスが被るコストはいくらになるでしょうか? アプリケーションの可用性を高めることにいくら投資すべきでしょうか。

トピックとベスト プラクティス

信頼性の重要な要素では、回復力のあるワークロードを構築する際に役立つ次のトピックとベスト プラクティスについて説明します。

信頼性に関する記事	説明
信頼性の設計原則	これらの重要な原則は、Azure にデプロイされたアプリケーションの信頼性を評価するためにレンズとして使用されます。
信頼性を高めるための設計	システムで可用性ゾーンを使用する方法、スケーラビリティを実行する方法、障害に対応する方法、およびアプリケーション設計の信頼性を最適化するその他の戦略を検討します。
特定の Azure サービスの回復性のチェックリスト	各テクノロジには独自の障害モードがあり、アプリケーションの設計および実装の際に考慮する必要があります。 このチェックリストを使用して、個々の Azure サービスの回復性の考慮事項を確認します。
機能要件と非機能要件をターゲットとする	可用性ターゲットや復旧ターゲットなどの機能要件と非機能要件をターゲットにすることで、ワークロードのアップタイムとダウンタイムを測定できます。 明確に定義された目標を設定することは、作業や測定の対象となる目標を持つために非常に重要です。
回復性と依存関係	障害のリスクを回避するために、システムに障害復旧の機能を備えさせるには、初めからアーキテクチャと設計フェーズの一部に組み込む必要があります。 アプリケーションを完全に動作させるには、依存関係が欠かせません。
可用性ゾーンを使用した高可用性	可用性ゾーンを使用すると、ソリューションをリージョン内の複数のゾーンに分散させることができるので、1 つのゾーンで障害が発生しても、アプリケーションは機能し続けることができます。
利用可能なサービス	Azure リージョンをまたぐサービスの可用性は、リージョンの種類によって異なります。 特定リージョンでのサービスのデプロイに関する Azure の一般的なポリシーは、主にリージョンの種類、サービス カテゴリ、および顧客の要望によって決まります。
可用性ゾーンの用語	主な用語や概念を理解することは、Azure のリージョンと可用性ゾーンについて理解を深める上で役立ちます。
アプリケーションの信頼性に関するベスト プラクティス	アーキテクチャ フェーズ中には、ビジネス要件を満たし、障害点を特定し、障害の範囲を最小限に抑えるプラクティスを実装することに専念します。
信頼性のテスト	既存のしきい値、ターゲット、想定を検証するために、通常のテストを主要な変更の一部として実行する必要があります。
信頼性の監視	アプリケーションの正常性の全体像を把握します。 何かが失敗した場合、失敗したこと、失敗したとき、失敗した理由を知る必要があります。
信頼性パターン	可用性を最大限に高めるために、アプリケーションを設計および実装する必要があります。

次の手順

信頼性の設計原則