ビジネス継続プランにより、中断時にアプリケーションが利用可能であり、回復可能であることが保証されます。プランには次の要素が含まれます。
高可用性（HA）: インフラストラクチャに障害が発生した場合に自動的に自己修復するアーキテクチャを配置します。
障害復旧（DR）: 自動フェイルオーバーが解決しない場合に手動で回復する手順を確立します。
テスト: HA 機能とDR 機能の両方を定期的に検証します。
ドキュメント: 明確な手順とリカバリ目的の維持。
注意
MongoDB Atlas共有責任モデルは、安全で回復力のあるデータ環境を維持するためのMongoDBとそのカスタマーの補完的な役割を定義します。このフレームワークの下、 MongoDB は基礎のプラットフォームのセキュリティと運用上の整合性を管理しますが、カスタマーは特定の配置の構成、管理、データ ポリシーに責任を負います。所有者セキュリティと運用上の優れ性の詳細な内訳については、 共有責任モデル を参照してください。
回復力戦略の選択
要件に基づいて、次のプライマリ アプローチのいずれかを選択します。
高可用性 - 自動自己修復
ダウンタイムがほぼゼロで、複数のアベイラビリティーゾーン（AZ）、リージョン、またはクラウドプロバイダーに配置できる場合は、 HA を選択します。
特徴:
手動介入なしの自動フェイルオーバー。
RPO = （0
majority書込み保証 (write concern)を使用する場合RTO = 秒。
インフラストラクチャのコストが高い。
使用ケース: ほとんどの本番環境の配置、特に次の場合。
複数のリージョンにわたるユーザーがいる場合。
アプリケーションでは継続的な可用性が必要です。
3 以上のアベイラビリティーゾーンを持つリージョンに配置できます。
詳しくは、「 Atlas の高可用性と Atlas 配置パラダイムに関する ガイダンスを参照してください。
障害復旧 - 手動復元
次のような場合に、HA が実行可能でないかコスト効果が低い場合は、DR を選択してください。
地理的制約（2 リージョンのみを持つカナダなど）。
コストのかかるアプリケーション。
手動回復手順の許容度。
特徴:
手動介入が必要です。
RPO > 0（バックアップ頻度に応じて）
RTO = 分から時間。
インフラストラクチャコストの削減 とバックアップストレージのコストの削減が適用されます。
使用ケース:
地理的または規制に関する制約により、マルチリージョン配置が妨げられます。
予算の制約にはコストの最適化が必要です。
アプリケーションは、リカバリのための計画的なダウンタイムを許容できます。
詳細については、「Atlas 障害復旧に関するガイダンス」を参照してください。
HA とDR の組み合わせ
ほとんどの本番環境では、包括的な保護を提供するために両方のアプローチを組み合わせることでメリットが得られます。
インフラストラクチャ障害の場合は HA: 自動フェイルオーバーは、ノード、ゾーン、リージョン、またはプロバイダーの停止から保護します。
データの整合性の問題の場合はDR: バックアップは、自動フェイルオーバーでは処理できないシナリオから保護します。
HA と併用によるメリットが得られる理由
高可用性を配置していても、次の障害復旧手順のメリットが得られます。
- データ破損または誤って削除
- 高可用性では、すべてのノードにわたって破損したデータがレプリケートされます。破損または削除が発生する前の状態に回復するには、バックアップから復元する必要があります。
- アプリケーション レベルの障害
- インフラストラクチャではなくデータの整合性に影響を与える、コードエラーまたは悪意のある攻撃。破損した状態はレプリカセット全体に複製されました。
- コンプライアンス要件
- 多くの規制では、自動フェイルオーバーが提供する機能を超えるポイントインタイムリカバリ機能とバックアップ保持ポリシーが必要です。
この階層型アプローチは、可用性とデータの整合性の両方を最適化すると同時に、包括的な保護を提供します。
リカバリ目的を定義する
アーキテクチャとバックアップの決定をガイドために、明確なリカバリ目的を設定します。
リカバリ点目的（RPO）
時間で測定されたデータ損失の最大許容量。
例:
RPO =:0
majorityの書込み保証 (write concern)で HA を使用します。RPO =1 時間: 時間単位のスナップショットを構成します。
RPO =1 日: 日次スナップショットを構成します。
リカバリ時間目的（RTO）
中断後にサービスを復元する最大時間。
例:
RTO = 秒: 自動フェイルオーバーで HA を使用します。
RTO =1 時間:バックアップ復元手順が1 時間未満に完了するようにします。
RTO =4 時間: 手動復元手順のドキュメントとテストを行います。
配置パラダイムとバックアップ戦略は、これらの目的と一致する必要があります。 Atlas 高可用性のガイダンスと Atlas 障害復旧ガイダンスの比較テーブルを使用して、オプションを評価します。
プランを定期的にテストする
ビジネス継続プランを少なくとも期間ごとにテストします（推奨は四半期ごと）。テストは手順を検証し、チームを強化します。
高可用性フェイルオーバーのテスト
自動テスト:
Atlas UI の プライマリ フェイルオーバーのテスト 機能を使用します。
フェイルオーバー Atlas Administration APIエンドポイントを使用します。
検証:
フェイルオーバーは予想される RTO 内に完了します。
アプリケーションが自動的に再接続されます。
データの損失は発生しません（RPO = 0）。
障害復旧手順のテスト
手動リカバリテスト:
非本番環境でバックアップからの復元をプラクティスします。
実際のリカバリ時間を記録し、RTO と比較します。
復元されたデータの整合性を検証します。
マルチリージョンスナップショット分散を使用する場合は、クロスリージョン復元をテストします。
検証:
チームはドキュメント化された手順に正しく従うため、
リカバリは予想される RTO 内に完了します。
データの損失は、予想される RPO と一致します。
すべての依存関係（ネットワーク、認証情報）が正しく動作します。
一部のテストでは、標準ユーザーが利用できないアクションが必要になる場合があります。少なくとも 1 週間前にサポートケースを開き、人為的な停止やその他の制限されたテストシナリオをスケジュールします。
プランを文書化する
ビジネス継続プランのために明確なドキュメントを維持します。
必要なドキュメント
リカバリ目的:
各アプリケーション層のドキュメント化された RPO と RTO。
選択した配置パラダイムの整合性。
バックアップ頻度と保持の決定。
アーキテクチャのドキュメント:
配置トポロジー（リージョン、ゾーン、クラウドプロバイダー）。
ネットワーク アーキテクチャとフェイルオーバーの動作。
アプリケーション配置のトポロジー。
サードパーティのサービス依存関係。
回復手順:
ステップごとの復元手順。
オンコールチームの連絡先情報。
さまざまなシナリオ タイプのエスカレーション パス。
ダッシュボードとアラートのモニタリング へのリンク。
テスト結果:
過去のテスト実行日付と結果。
特定された問題と修正ステータス。
テスト学習に基づいて手順を変更します。
テストの結果、またはインフラストラクチャの変更ごとに確認して更新することで、ドキュメントを最新の状態に維持します。
一般的なシナリオと対応プラン
一般的な中断シナリオの応答プランを準備します。詳細な手順については、「 Atlas 障害復旧ガイダンス 」のシナリオ固有のセクションを参照してください。
インフラストラクチャの障害（HA シナリオ）
単一ノードの停止時:
HA 配置: 自動フェイルオーバー。アクションは必要ありません。
フェイルオーバーとノードの復元が成功したかどうかを監視します。
アベイラビリティーゾーンの停止時:
マルチAZ配置: 自動フェイルオーバー、アクションは必要ありません。
アプリケーションが引き続きトラフィックを処理することを確認します。
リージョン停止時:
マルチリージョン配置: 別のリージョンへの自動フェイルオーバー。
アプリケーションもマルチリージョンに配置されていることを確認してください。
サードパーティのサービスが引き続きアクセスできることを確認します。
クラウドプロバイダーの停止時:
マルチクラウド配置: 別のプロバイダーへの自動フェイルオーバー。
シングルクラウド配置:DR 手順を実行します。
データの整合性の問題（DR シナリオ）
データの破損:
破損したタイムスタンプを特定します。
破損が発生する前にバックアップから復元します。
継続的なバックアップ: ポイントインタイム復元を使用します。
誤って削除:
削除のタイムスタンプを特定します。
削除する前にバックアップから復元します。
復元されたデータの整合性を検証します。
配置の完全な損失:
文書化されたDR手順を実行する。
最新のバックアップから復元します。
アプリケーション機能を検証します。
コントロール プレーンの障害:
非常にまれです。 Atlas は高い信頼性を維持します。
MongoDBサポートにすぐに問い合わせてください。
各シナリオの詳細な復旧手順については、「 Atlas 障害復旧に関するガイダンス 」を参照してください。