Azure Cosmos DB for MongoDB 仮想コアの信頼性

  • [アーティクル]

適用対象: MongoDB 仮想コア

この記事には、Azure Cosmos DB for MongoDB 仮想コアの可用性ゾーンを使用したリージョンの回復性、およびリージョン間のディザスター リカバリーとビジネス継続性に関する詳細情報が含まれています。

Azure における信頼性のアーキテクチャ概要については、「Azure の信頼性」を参照してください。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

可用性ゾーンのサポートを得るには、高可用性 (HA) を有効にする必要があります。

HA は、クラスター内のすべてのシャードのスタンバイ レプリカを維持して、データベースのダウンタイムを回避します。 シャードがダウンした場合、Azure Cosmos DB for MongoDB 仮想コアでは、障害が発生したシャードからそのスタンバイに受信接続が切り替えられます。

可用性ゾーンをサポートするリージョンで HA が有効になっている場合、HA レプリカ シャードはプライマリ シャードとは異なる可用性ゾーンにプロビジョニングされます。 HA レプリカは、プライマリ シャードが失敗しない限り、クライアントから要求を受信しません。

HA が無効になっている場合、各シャードには独自のローカル冗長ストレージ (LRS) があり、3 つの同期レプリカが Azure Storage サービスによって維持されます。 1 つのレプリカ エラーが発生した場合、Azure Storage サービスでエラーが検出され、関連するデータが透過的に再作成されます。 LRS ストレージの持続性については、「冗長オプションの概要」を参照してください。 ただし、リージョンの障害が発生した場合、長時間にわたるダウンタイムやデータ損失の可能性が発生するリスクがあります。

可用性ゾーンが有効になっているリソースを作成する

可用性ゾーンを有効にするには、クラスターの作成時に、または Azure portal 内の既存のクラスターの [スケール] セクションで、指定できます。高可用性 (HA) を有効にする必要があります。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

Azure Cosmos DB for MongoDB 仮想コアでは、組み込みの自動フェールオーバーやディザスター リカバリーは提供されていません。 高可用性の計画は、ソリューションがスケーリングするにつれて重要な手順となります。

単一リージョンの地域でのディザスター リカバリー

アップタイムを最大化するには、Azure Cosmos DB for MongoDB 仮想コアでの事業継続の維持とディザスター リカバリーの準備について事前に計画を立てておきます。

Azure サービスはアップタイムを最大化するように設計されていますが、計画外のサービス停止が発生する可能性があります。 ディザスター リカバリー計画により、リージョン規模のサービス停止に対処するための戦略を用意することができます。

Azure Cosmos DB for MongoDB 仮想コアでは、データのバックアップが一定の間隔で自動的に取得されます。 自動バックアップは、データベース操作のパフォーマンスや可用性に影響を与えずに取得されます。 すべてのバックアップはバックグラウンドで自動的に実行され、ストレージ サービス内のソース データとは別に格納されます。 これらの自動バックアップは、リソースを誤って削除または変更し、後で元のバージョンが必要となるシナリオで役立ちます。

自動バックアップは、クラスターが現在アクティブであるか、最近削除されたかに基づいて、さまざまな間隔で保持されます。

保持期間
アクティブなクラスター 35 日
削除されたクラスター 7 日

高可用性向けの設計

運用ワークロードを実行している重要な Azure Cosmos DB for MongoDB 仮想コアでは、高可用性 (HA) を有効にする必要があります。 HA 対応クラスターでは、各シャードは、プライマリと、別の可用性ゾーン内にプロビジョニングされたホット スタンバイ シャードとして機能します。 プライマリおよびセカンダリ シャード間のレプリケーションは、既定では同期です。 データベースに対する変更は、そのデータベースからの応答が受信される前に、プライマリおよびセカンダリ (ホット スタンバイ) シャードの両方で保持されます。

サービスは、クラスターの各プライマリおよびセカンダリ シャードへの正常性チェックとハートビートを管理します。 ゾーンまたはリージョンの停止によってプライマリ シャードが使用できなくなった場合、セカンダリ シャードが自動的に新しいプライマリに昇格され、次のセカンダリ シャードがその新しいプライマリ用に構築されます。 さらに、セカンダリ シャードが使用できなくなった場合、サービスではプライマリからのデータの完全なコピーを含む、新しいセカンダリ シャードが自動的に作成されます。

サービスでプライマリからセカンダリ シャードへのフェールオーバーがトリガーされた場合、接続はその新しいプライマリ シャードに内部的にシームレスにルーティングされます。

プライマリとセカンダリ シャード間の同期レプリケーションでは、フェールオーバーが発生してもデータ損失が発生しないことが保証されます。

次のステップ