次の方法で共有

Azure の信頼性に関するドキュメント

  • [アーティクル]

信頼性は、回復性と可用性という 2 つの原則で構成されます。 回復性の目標は、障害を回避し、発生したとしてもアプリケーションを完全に機能する状態に戻すことです。 可用性の目標は、アプリケーションまたはワークロードへの一貫したアクセスを提供することです。 アプリケーションの要件に基づいてプロアクティブな信頼性を計画することが重要です。

Azure には、ビジネス ニーズに基づいて使用および管理できる組み込みの信頼性サービスが含まれています。 障害が 1 つのハードウェア ノードの障害、ラック レベルの障害、データセンターの停止、大規模なリージョンの停止のどれであっても、Azure には、信頼性を向上させるソリューションが用意されています。 たとえば、可用性セットを使用すると、Azure にデプロイされる仮想マシンは、クラスター内の分離された複数のハードウェア ノードに分散配置されます。 可用性ゾーンにより、リージョン内の複数の物理的な場所でデータセンターの障害からお客様のアプリケーションとデータが保護されます。 リージョンと可用性ゾーンは、アプリケーション設計と回復性戦略の中心であり、この記事の後半で詳しく説明します。

Azure の信頼性に関するドキュメントでは、Azure サービスの信頼性に関するガイダンスを提供しています。 このガイダンスには、可用性ゾーンのサポート、ディザスター リカバリー ガイダンス、サービスの可用性に関する情報が含まれます。

可用性ゾーン、ディザスター リカバリー、高可用性など、サービス固有の信頼性に関するガイダンスの詳細については、Azure サービス固有の信頼性に関するガイダンスの概要の記事を参照してください。

Microsoft Azure サービスの信頼性と信頼性の原則とアーキテクチャについては、「Microsoft Azure Well-Architected Framework: 信頼性」を参照してください。

信頼性の要件

Azure ソリューションに必要な信頼性のレベルは、いくつかの考慮事項によって決まります。 可用性と待機時間の SLA と他のビジネス要件に基づきアーキテクチャを選択しますが、回復性レベルを最初に検討する必要があります。 可用性の要件は、どの程度のダウンタイムを許容できるか、ビジネスにどれだけのコストがかかるかなどから、アプリケーションの可用性を高めるために実際にどれだけの資金と時間を投資できるかまでさまざまです。

Azure で信頼性システムを構築するのは、共同責任です。 Microsoft は、クラウド プラットフォーム (そのグローバル ネットワークとデータセンターを含む) の信頼性について責任を持ちます。 Azure のお客様とパートナーは、各ワークロードの要件に基づくアーキテクチャのベスト プラクティスを使用して、クラウド アプリケーションの回復性について責任を持ちます。 Azure では、クラウド プラットフォームの SLA で可能な限り高い回復性を継続的に目指しますが、ユーザーは、ソリューション内のワークロードごとに独自のターゲット SLA を定義する必要があります。 SLA があると、アーキテクチャがビジネス要件を満たしているかどうかを評価できるようになります。 SLA で保証されるアップタイムの割合を高くしようとすると、そのレベルの可用性を実現するためのコストと複雑性が増加します。 99.99 パーセントのアップタイムは、月あたり約 5 分の合計ダウンタイムに換算されます。 この割合を実現するために複雑性とコストが増加しますが、その価値はありますか? その答えは、個々のビジネス要件によって異なります。 最終的な SLA コミットメントを決定するとき、Microsoft でサポートされる SLA について理解してください。 各 Azure サービスには独自の SLA があります。

Diagram showing the shared responsibility model for Azure business continuity.

従来のオンプレミス モデルでは、コンピューティング、ストレージ、ネットワーク用のハードウェアからアプリケーションに至るまで、管理の全責任を負うのはユーザーです。 ディザスター リカバリー戦略を作成することで、さまざまな障害とその対処方法を計画する必要があります。 IaaS では、ストレージ、ネットワーク、コンピューティングを含むコア インフラストラクチャの回復性に責任を負うのはクラウド サービス プロバイダーです。 IaaS から PaaS、そして SaaS へと移行するにつれて、ユーザーが責任を負う範囲は少なくなり、クラウド サービス プロバイダーが責任を負う範囲は多くなります。  

信頼性原則の詳細については、適切に設計されたフレームワークの信頼性に関するドキュメントを参照してください。  

信頼性の構築

計画の開始時に、アプリケーションの信頼性の要件を定義する必要があります。 特定の期間中に 100% の高可用性を必要としないアプリケーションがわかっている場合は、その重要でない期間中にコストを最適化できます。 アプリケーションで発生する可能性のある障害の種類と、各障害の潜在的な影響を特定します。 復旧計画では、個々のコンポーネントとアプリケーション全体のレベルで復旧戦略を完成させることで、重要なすべてのサービスをカバーする必要があります。 ゾーン、リージョン、アプリケーションの各レベルの障害から保護する復旧戦略を設計します。 エンドツーエンドのアプリケーション環境のテストを実行して、予期しない障害に対するアプリケーションの信頼性と復旧性を測定します。

次のチェックリストは、信頼性計画の範囲をカバーしています。

信頼性の計画
ビジネス要件を満たすために可用性と復旧のターゲットを定義します。
可用性の要件に基づき、アプリケーションの信頼性機能を設計します。
信頼性の要件を満たすようにアプリケーションとデータのプラットフォームを調整します。
可用性が促進されるように接続パスを構成します。
信頼性を向上させ、コストを最適化するために、可能な場合は可用性ゾーンとディザスター リカバリーの計画を使用します。
アプリケーション アーキテクチャが障害に対する回復力を備えていることを確認します。
SLA 要件が満たされない場合に何が起こるか認識します。
システム内の潜在的な障害点を特定します。アプリケーション設計で、サーキット ブレークをデプロイすることで、依存関係エラーを許容する必要があります。
依存関係なしで動作するアプリケーションを構築します。

RTO と RPO

考慮すべき 2 つの重要なメトリックとして、ディザスター リカバリーに関連している目標復旧時間と目標復旧時点があります。  機能設計要件と非機能設計要件の詳細については、適切に設計されたフレームワークの機能および非機能の要件に関する記事を参照してください。

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

  • 回復ポイントの目標 (RPO) は、災害発生時に許容できるデータ損失の最大期間です。

RTO と RPO はシステムの機能要件ではありません。これらはビジネス要件によって決定する必要があります。 これらの値を得るためにリスク評価を実施し、ダウンタイムまたはデータ損失のコストを明確に理解しておくことをお勧めします。  

リージョンと可用性ゾーン

リージョンと可用性ゾーンは、信頼性の方程式で大きな役割を担います。 リージョンは、複数の物理的に分離された可用性ゾーンを備えています。 これらの可用性ゾーンは、物理ゾーン間の待機時間が 2 ミリ秒未満の高パフォーマンス ネットワークによって接続されています。 低待機時間は、問題が発生した場合にデータの同期とアクセス可能性を維持するのに役立ちます。 ゾーン間およびリージョン間で中断不可のサービスを自動的にレプリケートして提供するアプリケーションとデータのインフラストラクチャを設計する場合、このインフラストラクチャを戦略的に使用できます。

Microsoft Azure サービスは、クロスリージョン リカバリーと事業継続戦略のニーズをサポートする一方で、可用性ゾーンをサポートし、最適な高可用性でクラウド運用を推進できるようにします。

ディザスター リカバリー計画の場合、他のリージョンとペアになっているリージョンはクロスリージョン レプリケーションを提供し、他の Azure リージョン間で非同期にデータをレプリケートすることで保護を提供します。 ペアのないリージョンは、データ所在地のガイドラインに従い、可用性ゾーンとローカル冗長ストレージまたはゾーン冗長ストレージによる高可用性を提供します。 お客様は、RTO と RPO のニーズに基づいてリージョン間のディザスター リカバリーを計画する必要があります。

サービスの機能、データ所在地、コンプライアンス要件、待機時間などの技術上および規制上の考慮事項に基づいて、ニーズに最適なリージョンを選択し、信頼性戦略をより高度にしていきます。 詳細については、「Azure リージョンと可用性ゾーン」を参照してください。

Azure サービスの依存関係

Microsoft Azure サービスは、クラウド運用を最適なレベルで推進できるよう、グローバルに利用可能です。

Azure リージョンにデプロイされている Azure サービスは、Azure グローバル インフラストラクチャ製品ページに記載されています。 Azure のリージョンと Availability Zones について理解を深めるには、「リージョンと Availability Zones」を参照してください。

Azure サービスは、高可用性とディザスター リカバリーを含む信頼性を確保するために構築されています。 単一の論理データセンターに依存しているサービスはありません (単一障害点を回避するため)。 Azure グローバル インフラストラクチャ製品に記載されている非リージョン サービスは、特定の Azure リージョンに依存しないサービスです。 リージョンに依存しないサービスは 2 つ以上のリージョンにデプロイされており、あるリージョンで障害が発生した場合は、別のリージョンのサービスのインスタンスが引き続き顧客にサービスを提供します。 一定の非リージョン サービスを利用すると、お客様はサービスを実行する基盤となる仮想マシン (VM) をデプロイするリージョンを指定できます。 たとえば、Azure Virtual Desktop を利用すると、お客様は VM が存在するリージョンの場所を指定できます。 顧客データを格納するすべての Azure サービスを利用すると、お客様はデータを格納する固有のリージョンを指定できます。 Microsoft Entra ID は例外であり、地理的配置 (ヨーロッパや北米など) があります。 データ ストレージの所在地の詳細については、データ所在地マップを参照してください。

アプリケーションとサービスをより適切に設計できるように Azure サービス間の依存関係を理解する必要がある場合は、Microsoft の営業担当者またはカスタマー担当者に連絡して、Azure サービスの依存関係ドキュメントを要求することができます。 このドキュメントには、コントロール プレーン サービスなど、一般的な主要内部サービスへの依存関係を含む、Azure サービスの依存関係が示されています。 このドキュメントを入手するには、Microsoft のお客様であること、Microsoft と適切な秘密保持契約書 (NDA) をお持ちであることが必要です。

次のステップ