AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

Atlas の高可用性に関するガイダンス

高可用性とは、インフラストラクチャの停止、システムメンテナンス、その他の中断時に、アプリケーションが継続的に稼働し、ダウンタイムを最小限に抑える能力です。MongoDB のデフォルトの配置アーキテクチャは、高可用性を実現するように設計されており、データ冗長性や自動フェイルオーバーの機能が組み込まれています。

高可用性は障害復旧とは異なります。高可用性は、データ損失なし (つまり RPO = 0)で障害発生時点に復旧し、RTO を数秒で達成する自動フェイルオーバーにより、ノード、ゾーン、リージョン、またはクラウドプロバイダーの停止時などのインフラストラクチャ障害から保護します。障害復旧は、破損や誤削除などのデータ整合性の問題から保護します。これにはバックアップからの復元が必要です。障害復旧について詳しく学ぶには、「Atlas 障害復旧に関するガイダンス」を参照してください。

このページでは、ゾーン、リージョン、クラウドプロバイダーの停止時に中断を防ぎ、堅牢なフェイルオーバー メカニズムをサポートするために選択できる追加の構成オプションと配置アーキテクチャの強化について説明します。

高可用性を実現するための Atlas の機能

データベース レプリケーション

MongoDB のデフォルトの配置アーキテクチャは、冗長性を確保するように設計されています。Atlas は各クラスターを、選択したクラウドプロバイダーリージョン内の個別のアベイラビリティーゾーンに分散された、少なくとも 3 つのデータベースインスタンス（ノードまたはレプリカセットノードとも）を含むレプリカセットとして配置します。アプリケーションによりレプリカセットのプライマリノードにデータが書き込まれます。その後、Atlas はそのデータを複製して保存し、クラスター内のすべてのノードに保存します。データストレージの耐久性を制御するには、アプリケーションコードの書込み保証 (write concern)を調整して、特定の数のセカンダリが書込み (write) をコミットした後にのみ書込みを完了します。デフォルトの動作では、アクションを確認する前に、選挙可能なノードの過半数にデータを保持します。

次の図は、デフォルトの 3 ノードレプリカセットにおけるレプリケーションの動作を示しています。

3 ノードのレプリカセットにおけるレプリケーションプロセスを示す画像。
クリックして拡大します

自動フェイルオーバー

インフラストラクチャの停止時、定期メンテナンス、またはその他の中断によりレプリカセット内のプライマリノードが利用できなくなったイベント、Atlas はレプリカセットの選挙において既存のセカンダリノードをプライマリノードのロールに昇格させることで、クラスターの自己修復を行います。このフェイルオーバープロセスは完全に自動であり、秒単位でデータを失うことなく（RPO = 0）、障害が発生した時点に回復します。再試行可能な書き込みs が有効になっている場合は、障害時に実行中だった操作は、障害後に再試行されます。レプリカセットの選挙後、Atlas は失敗したノードを復元または置換して、クラスターができるだけ早くターゲット構成に戻るようにします。MongoDBクライアントドライバーも、障害中と障害後にすべてのクライアント接続を自動的に切り替えます。

次の図は、レプリカセットの選挙プロセスを示しています。

3 ノードのレプリカセットにおける自己修復プライマリ選挙プロセスを示す画像。
クリックして拡大します

最も重要なアプリケーションの可用性を向上させるために、ノード、リージョン、またはクラウドプロバイダーを追加して、ゾーン、リージョン、またはプロバイダーの停止にそれぞれ耐えられるように配置を増やすことができます。詳細については、以下の「フォールトトレランスに向けた配置パラダイムのスケーリング」の推奨事項を参照してください。

Atlas の高可用性に関する推奨事項

次の推奨事項では、配置の可用性を高めるための追加の設定オプションと配置アーキテクチャの強化について説明します。

配置の目標に合ったクラスター階層を選択

専用、フレキシブル、または無料の配置タイプで使用可能なクラスター階層の範囲から選択できます。MongoDB Atlasのクラスター階層は、クラスター内の各ノードで使用可能なリソース（メモリ、ストレージ、 vCPU 、 IOPS ）を指定します。より高い階層に拡大すると、クラスターのトラフィックの急増を取り扱う能力が向上し、高いワークロードへの応答がより高速になることでシステムの信頼性が向上します。アプリケーションサイズに推奨されるクラスター階層を決定するには、Atlas クラスター サイズ ガイド を参照してください。

Atlas は、クラスターが需要の急増に対応できるようにするためのオートスケーリングもサポートしています。Atlas は、現在のリソース使用量に基づいてトリガーするリアクティブなオートスケーリングと、予測される定期的需要の急増が発生する前に適格なクラスターを積極的にスケールアップする予測型のオートスケーリングの両方を使用します。スケーリング アクションを自動化すると、リソースの制約による停止時のリスクを軽減できます。詳細については、「Atlas 自動インフラストラクチャのプロビジョニング」に関するガイダンスを参照してください。

フォールトトレランスに向けた配置パラダイムのスケーリング

Atlas 配置のフォールトトレランスとは、配置が引き続き機能している間に使用できなくなる可能性のあるレプリカセットの数です。アベイラビリティーゾーン、リージョン、またはクラウドプロバイダーが停止時イベント、Atlas はレプリカセットの選挙で既存のセカンダリノードを プライマリノードのロールに昇格させ、クラスターの自己修復を行います。プライマリノードが停止時ときにレプリカセット選挙を実行するには、レプリカセット内の投票ノードの過半数が稼働中である必要があります。

部分的なリージョン停止が発生した場合でも、レプリカセットがプライマリを選出できるようにするには、少なくとも 3 つのアベイラビリティゾーンにわたってクラスターを配置する必要があります。アベイラビリティゾーン は、単一のクラウドプロバイダー リージョン内で電源、冷却、ネットワーク インフラを個別に備えたデータセンターのグループとして区分されています。Atlas は、クラウドプロバイダー リージョンが対応している場合、クラスターを複数のアベイラビリティゾーンに自動的に分散します。これにより、1 つのゾーンで停止が発生しても、残りのノードが引き続きリージョナル サービスをサポートします。Atlas が対応するほとんどのクラウドプロバイダー リージョンには、少なくとも 3 つのアベイラビリティゾーンがあります。これらのリージョンは、Atlas UI 内で星アイコン付きで表示されます。

各クラウドプロバイダーは、アベイラビリティーゾーン内でデフォルトのデータ冗長性を提供します。

  • AWS は、AWS リージョン内の少なくとも 3 つのアベイラビリティーゾーンにわたって複数のデバイスにデータを保存します。

  • Microsoft Azure は、選択したリージョン内の単一のデータセンター内でデータを 3 回複製するローカル冗長ストレージ（LRS）を使用します。

  • Google Cloud は、リージョン内の複数のゾーンにデータを分散します。

推奨リージョンの詳細については、「クラウドプロバイダーとリージョン」を参照してください。

最も重要なアプリケーションの耐障害性をさらに向上させるには、ノード、リージョン、またはクラウドプロバイダーを追加して、アベイラビリティーゾーン、リージョン、またはプロバイダーの停止にそれぞれ耐えられるように配置を増やすことができます。ノード数を任意の奇数に増やすことができます。選挙可能なノードの最大数は 7、合計ノード数は 50 です。クラスターを複数のリージョンに配置することで、広域にわたる可用性を高め、プライマリ リージョン内のすべてのアベイラビリティゾーンが無効になるような全リージョン停止の際にも、自動フェイルオーバーを可能にします。同様のパターンは、クラスターを複数のクラウドプロバイダーに配置する場合にも適用され、クラウドプロバイダー全体の停止に耐えられるようにします。

高可用性、低レイテンシ、コンプライアンス、コストのニーズをバランスよく満たす配置を選択するためのガイダンスについては、「Atlas 配置パラダイム」のドキュメントをご覧ください。

配置パラダイム RTO/RPO のトレードオフ

次の表は、さまざまな配置パラダイムの RTO と RPO の特性を比較したものです。majority書込み保証 (write concern)では、これらのすべてのアプローチにより RPO = 0（データ損失なし）と RTO が秒単位で実現されます。配置の複雑さと クラスターのコスト のトレードオフが行われます。

配置パラダイム
カバーされた障害シナリオ
一般的な RTO
RPO （過半数の書込み保証 (write concern)） ）
相対的な複雑さ
相対的なクラスターコスト

単一リージョン配置（1 リージョンの 3 ノード）

単一リージョン内でのノードまたは AZ の障害

秒（自動フェイルオーバー）

0（データの損失なし）

低

$

マルチリージョン、単一クラウド

1 つの地理的における AZ またはリージョンの停止時

秒（自動フェイルオーバー）

0（データの損失なし）

平均

$$

マルチリージョン、マルチジオメトリ

複数の地域にわたるリージョンまたはリージョンの停止時

秒（自動フェイルオーバー）

0（データの損失なし）

中～高

$$–$$$

マルチクラウド（2–3 プロバイダー）

1 つのプロバイダーに影響するクラウドプロバイダーまたはマルチリージョンの停止時

秒（自動フェイルオーバー）

0（データの損失なし）

高

$$$

クラスターの誤削除を防止する

終了保護を有効にすると、クラスターが誤って終了してバックアップからの復元にダウンタイムが必要になることがなくなります。終了保護が有効になっているクラスターを削除するには、まず終了保護を無効にする必要があります。デフォルトでは、Atlas はすべてのクラスターの終了保護を無効にします。

Terraform のような IaC ツールを使用する場合、再デプロイメントが新しいインフラをプロビジョニングしないようにするために、終了保護は特に重要です。

自動フェイルオーバーをテストする

アプリケーションを本番環境にデプロイする前に、自動ノードフェイルオーバーを必要とするさまざまなシナリオをシミュレートして、このようなイベントへの準備状況を測定することを強くお勧めします。Atlas を使用すると、レプリカセットのプライマリノードのフェイルオーバーをテストし、マルチリージョン配置のリージョン停止時をシミュレートできます。

majority 書込み保証 (write concern) を使用

MongoDBは、書込み保証 (write concern) を使用して、書き込み操作に要求される確認応答のレベルを指定できます。Atlas のデフォルトの書込み保証は majority であり、つまり、データは Atlas が成功を報告する前に、クラスター内のノードの過半数で複製される必要があります。2 のような固定値ではなく majority を使用することで、Atlas は一時的なノード停止が発生した場合でも、より少ないノード間でのレプリケーションに自動的に対応し、フェイルオーバー後も一括書き込みを継続できるようにします。これにより、すべての環境で一貫した設定が維持され、テスト環境でノードが 3 つの場合でも、本番環境でより多くのノードがある場合でも、接続文字列は変わりません。

再試行可能なデータベース読み取りおよび書き込みの構成

Atlas は、再試行可能な読み取りおよび再試行可能な書き込み操作をサポートしています。有効化すると、Atlas は断続的なネットワーク停止や、アプリケーションが一時的に正常なプライマリ ノードを検出できないレプリカセット選挙に対する保護として、読み取りおよび書き込み操作を 1 回再試します。再試行可能な書き込みには、確認済みの 書込み保証 (write concern) が必要です。つまり、書込み保証 (write concern) は {w: 0} に設定できません。

リソース利用状況のモニターとプラン

リソース容量の問題を回避するため、リソース利用状況を監視し、定期的にキャパシティー プラン セッションを実施することを推奨します。MongoDB のProfessional Services では、これらのセッションを提供しています。また、リソース容量障害復旧プランに関する推奨事項を確認し、リソース容量の問題からの復旧方法をご参照ください。。

リソース使用率に関するアラートとモニタリングのベストプラクティスについては、Atlas のモニタリングとアラートのガイダンスを参照してください。

MongoDB バージョンの変更を計画する

新機能を活用し、セキュリティ保証を強化するために、最新の MongoDB バージョンを使用することを推奨します。また、現在使用しているバージョンが終了に到達する前に、常に最新の MongoDB メジャー バージョンにアップグレードするようにしてください。

Atlas UIを使用して MongoDB のバージョンをダウングレードすることはできません。このため、MongoDB の Professional Services またはテクニカル サービスと直接連携し、メジャーバージョンのアップグレードを計画・実行することを推奨します。これにより、アップグレード プロセス中に発生し得る問題を回避できます。

メンテナンスウィンドウの構成

Atlas は、一度に 1 つのノードにローリング方式で更新を適用することで、スケジュールされたメンテナンス中にアップタイムを維持します。メンテナンス中に現在のプライマリがオフラインになると、Atlas は新しいプライマリを自動レプリカセット選挙により選出します。これは、計画外のプライマリ ノード停止に対応する自動フェイルオーバー中に発生するプロセスと同じです。

プロジェクトにカスタム メンテナンスウィンドウを構成し、ビジネスに重要な時間帯におけるメンテナンス関連のレプリカセット選挙を回避することを推奨します。メンテナンスウィンドウ設定で保護時間を指定し、標準アップデートを開始できない日次の時間帯を定義することも可能です。標準更新には、クラスターの再起動や再同期は含まれません。

オートメーションの例：Atlas の高可用性

次の例では、Atlas のオートメーション用ツールを使用して、単一リージョン、3 ノード レプリカセット / シャード配置トポロジーを構成します。

これらの例では、次のようなその他の推奨される構成も適用されます。

  • 開発およびテスト環境用にクラスター階層が M10 に設定されました。クラスター サイズ ガイドを使用して、アプリケーションのサイズに合った推奨クラスター階層を確認してください。

  • 単一リージョン、3 ノード レプリカ セットまたはシャード配置トポロジー。

当社の例では、Amazon Web Services、Azure、および Google Cloud Platform を互換的に使用します。これら 3 つのクラウドプロバイダーのいずれかを使用できますが、クラウドプロバイダーに一致するようにリージョン名を変更する必要があります。クラウドプロバイダーとそのリージョンについて学ぶには、「クラウドプロバイダー」を参照してください。

注意

Atlas CLI を使用してリソースを作成する前に、次の手順を実行する必要があります。

プロジェクトごとに 1 つのデプロイメントを作成

開発環境およびテスト環境においては、各プロジェクトに対して以下のコマンドを実行してください。以下の例では、ID や名前を変更し、お使いの値に置き換えてください。

注意

次の例では、開発およびテスト環境におけるコスト管理のため、オートスケーリングは有効になっていません。ステージングおよび本番環境では、オートスケーリングを有効にする必要があります。オートスケーリングを有効にした例については、「ステージングと本番環境」タブをご参照ください。

atlas clusters create CustomerPortalDev \  --projectId 56fd11f25f23b33ef4c2a331 \  --region EASTERN_US \  --members 3 \  --tier M10 \  --provider GCP \  --mdbVersion 8.0 \  --diskSizeGB 30 \  --tag bu=ConsumerProducts \  --tag teamName=TeamA \  --tag appName=ProductManagementApp \  --tag env=dev \  --tag version=8.0 \  --tag email=marissa@example.com \  --watch

この例に関する追加の構成オプションや情報については、atlas clusters create コマンドを参照してください。

戻る
Reliability
次へ
障害復旧
このページを評価

項目一覧