MongoDB Atlasクラスタを作成する前にネットワークIP範囲を意識しよう
メディア統括本部 サービスリライアビリティグループ（SRG）の小原です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、MongoDB AtlasのVPCピアリングにおけるIPアドレス競合問題と、そのダウンタイムを抑えた移行方法について説明します。
はじめにVPCピアリング設定でIPアドレスの競合エラーなぜIPアドレスが重複したか？AtlasのデフォルトCIDRVPCピアリングの制約解決策1. shared クラスタを削除し、再作成する2. 競合している stg とのVPCピアリングを削除し、パブリックアクセスで妥協する3. 新しいプロジェクトで適切なCIDRを設定し、 shared → shared_v2 でデータを移行する（採用）Live Migrationによるデータ移行とVPCピアリングの再設定設計の重要性
はじめに
MongoDB Atlasは、データベースの管理を自動化し開発者がアプリケーション構築に集中できるようにする、フルマネージドのクラウドデータベースサービスです。GCPやAWSなどのクラウド環境からVPCピアリングの機能を使うことで、プライベートIPアドレスで安全に接続できます。
今回は、MongoDB AtlasとGCPのVPCピアリングを設定した際に発生した、ネットワークのIPアドレス範囲の競合問題と、その解決策について解説します。
VPCピアリング設定でIPアドレスの競合エラー
私たちの環境では、GCP上のVPC と、MongoDB Atlasプロジェクト との間で、既にVPCピアリングが設定されていました。
今回、新たに別のAtlasプロジェクト を、 にピアリングしようとTerraformで適用したところ、IPアドレス範囲の重複エラーが発生し、ピアリング設定に失敗してしまいました。
なぜIPアドレスが重複したか？
調査の結果、問題の原因はMongoDB Atlasのクラスタ作成時の仕様が関係していました。
AtlasのデフォルトCIDR
MongoDB Atlasでは、クラスタを作成する際にネットワーク設定（ネットワークコンテナ）を明示的に指定しないと、デフォルトのCIDRブロックとして が自動的に割り当てられます。
今回のケースでは、既存の プロジェクトと、新しい プロジェクトのどちらも、このデフォルト設定でクラスタが作成されていました。
はじめに考えたことは、このネットワークコンテナで定義しているCIDRを変更することでしたが、Atlasの仕様上、一度作成されたクラスタのVPC CIDRを変更するにはクラスタの再作成が必要であることがわかりました。
以上のクラスターまたはネットワーク ピアリング接続がすでにそのリージョンに存在する場合、Atlas はそのリージョンに対してこの値をロックします。ターゲット プロジェクトに次のアイテムが含まれている場合、CIDR ブロックは変更できません。
- 対象領域にノードを持つ 以上のクラスター
- ターゲット リージョンに保存されているクラウドバックアップのスナップショット
- ターゲット リージョンへのその他の VPC ピアリング接続
VPCピアリングの制約
当然ながら、VPCピアリング時にサブネット同士のIPレンジは重複してはいけません。
から見ると、接続しようとしている2つのAtlas VPCのCIDRがどちらも の範囲であったためエラーとなりました。
解決策
以下の3つの案を検討しました。
Atlasネットワークの再設定にはダウンタイムが発生するので、できればより影響の少ない方法を考慮する必要があります。
1. クラスタを削除し、再作成する
データのバックアップとリストアのために / コマンドを使用する必要があります。この方法は作業中のサービス停止（ダウンタイム）が避けられません。
さらに、Atlasの仕様により再作成時には既存のスナップショットも削除する必要があり、迅速な復旧手段が制限されます。
2. 競合している とのVPCピアリングを削除し、パブリックアクセスで妥協する
stgへのアクセスはsharedへのアクセスに比べてそれほど頻繁ではなく、プロダクトとして重要なアクセスもほとんどなかったので候補に挙がりました。
→ のピアリング設定は可能になるものの、DBへパブリックアクセスするデメリットが増えたり、別の環境をピアリング追加したい場合の根本的な解決になっていないため、見送りました。
3. 新しいプロジェクトで適切なCIDRを設定し、 → でデータを移行する（採用）
データ移行にはAtlasのLive Migration機能を利用します。この機能を使えば、アプリケーションを稼働させたまま、２つのDBを同期して並行稼働させることができ、ダウンタイムをほぼ発生させることなく切り替えができます。既存システムに影響を与えずに想定通りにCIDR変更、ピアリング設定までできるか、インフラとしての妥当性の検証もできます。
最も安全で影響が少ないと判断し、この案を採用しました。
Live Migrationによるデータ移行とVPCピアリングの再設定
採用した解決策の具体的な手順は以下の通りです。
- 新しいAtlasプロジェクトとして を作成
- プロジェクトでIP範囲が重複しないCIDR を持つネットワークコンテナを先に作成しつつクラスタを作成 terraformでクラスタ作成時にネットワークコンテナリソースがある前提にするため、depens_onで依存関係を明示します。
- 新しいネットワークのCIDRを確認
- と との間で、VPCピアリングを設定
- AtlasのLive Migration機能を使い、古い クラスタから新しい クラスタへのデータ移行を実施
この対応により、データ移行とVPCピアリング設定は無事に完了し、 から のMongoDBクラスタへプライベート接続できる状態になりました。
設計の重要性
マネージドサービスは非常に簡単に構築・管理できる一方、プロバイダ固有の仕様や制限など、設計時に考慮すべき項目が多くあります。
ネットワーク設計に限らず、構築の初期段階で設計をしっかり行うことで、将来発生しうる大規模な手戻りや、複雑なデータ移行作業を防ぐことができます。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。