AEMとMongoDBの連携徹底解説：MongoMKのアーキテクチャとマルチサイト運用の落とし穴

MongoDBとは何か？

MongoDBは、ドキュメント指向のNoSQLデータベースです。従来のリレーショナルモデル（RDBMS）から離れ、柔軟かつ水平スケール可能なデータ管理の仕組みを提供します。JSONライクなドキュメント形式（BSON）でデータを格納するため、構造が流動的なコンテンツやアプリケーション開発に適しており、Adobe Experience Manager（AEM）のような大規模コンテンツ管理プラットフォームとの組み合わせでも注目されてきました。

AEMとMongoDBはどのように連携するのか？

AEMとMongoDBの連携は、crx3mongo ランモードと、JVMオプションの -Doak.mongo.uri および -Doak.mongo.db を指定することで実現されます。これにより、AEM 6.x系で採用されたMongoDBマイクロカーネル（MongoMK）が有効化され、デフォルトのTarMKの代わりにMongoDBをリポジトリのバックエンドとして利用できるようになります。

なぜMongoDBを使うのか？

最大の目的は、旧来のCRXクラスタ構成に代わるHA（高可用性）構成の提供です。実際のところ、そのアーキテクチャは「真のクラスタリング」というより、NFS上の共有カタログやNetAppの共有ストレージに近いものです。MongoDBを使用する各オーサーインスタンスやパブリッシュインスタンスは、互いの存在を必ずしも意識していません。

CRXクラスタリングの限界

率直に言えば、CRXクラスタリングには決して輝かしい実績があるわけではありません。ローカル専用のオブジェクトカタログに内在する課題を踏まえると、大規模環境においては単一の共有カタログの方が、次のようなメリットをもたらします。

• データ重複の削減
• パフォーマンス分析・チューニングの対象範囲の集中
• ノード間通信を必要としないHA可用性の実現
• 冗長性とパフォーマンスのための水平スケーリング

完璧に動作するCRXクラスタであっても、これらのメリットは一切実現できません。こうして「共有データ層」の時代が幕を開けました。

NFS／NetAppによる共有リポジトリの時代

AEM 5.6.1以前では、大規模かつ拡大中のデプロイメントは、オブジェクトリポジトリを共有NFSとしてマウントすることが可能でした。プロトコルまたはNFSサーバーがロック機構を提供することで、衝突の少ないマルチライト動作を実現していたのです。この選択肢は今でも有効ですが、NetAppを採用しない限り、コントローラーやデータ層に単一障害点（SPOF）のリスクが残り、「n*9」レベルの可用性を持つアーキテクチャの実現を妨げる要因となっていました。

MongoMKの登場

AEM 6.xへのMongoDBマイクロカーネルの導入により、本質的には同じアーキテクチャを、より注目度の高いデータベース技術で実現できるようになりました。

MongoMKの主なユースケース：オーサーインスタンス

MongoMKが最も力を発揮するのは、AEMオーサーインスタンスです。オーサーの同時アクティブユーザー数上限（約25〜30人）という制約があるため、水平スケーリングにはまず同時実行性の問題を解決する必要があります。こここそ共有データ層が輝く場面です。パフォーマンスよりもスケーラビリティと整合性が優先され、同時にノード間通信の必要性も排除されるからです。

パブリッシャーを同様の方法で接続すること自体は可能ですが、同時実行性の問題が存在しないため（スケールが必要ならパブリッシャーを追加すればよい）、メリットは相対的に小さくなります。さらに、非ローカルのカタログ参照によるパフォーマンス低下も無視できません。

これで万事解決！無限にスケールできる！……と言いたいところですが、少し待ってください。落とし穴があります。

マルチサイト展開における課題：oplogの落とし穴

単一サイト内のMongoDBであれば、高速アクセス可能なデータ配置とインラインネットワーキングのおかげで、非常に効果的にスケールすることが期待できます。この場合、可能性は無限大とも言えます。しかし、複数のデータセンター間でMongoDBレプリカセットが通信しなければならないマルチサイト展開を想像してみてください。そこに立ちはだかるのが、オペレーションログ（oplog）です。

oplogは、レプリカ同士が同期を維持するための中継役であり、順番に適用されるべき差分操作のシーケンスを提供します。これは他の一部のデータベースクラスタ構成とよく似ています。

最適化された運用では、oplogはプライマリに対してリアルタイムに極めて近い形で実行されますが、MongoDBは一定の遅延（ドリフト）を許容しています。ところがマルチサイト運用では、回線遅延と操作遅延が積み重なり、ドリフトが拡大します。この構成には次のような課題があります。

• oplogは機能的には「コマンドのスタック」である。
• 多くのスタックと同じく、先入れ先出し（FIFO）で動作する。
• スタックの挙動上、次の書き込み（プッシュ）が未読出し（ポップ）のレコードを上書きすると、データ損失が発生する。

再構築ループという悪夢

MongoDBの開発者たちはこの状況に対処するため、レプリカを停止させて再構築し、その後の新しいoplogから前方同期を行う方式を採用しました。表面上、この操作に特別なものも危険なものもありません。しかし、再構築の手順をよく見てください。すべてのデータを消去したうえで、正常なプライマリから最新コピーを取得します。仮にエクスポートがゼロ秒で完了したとしても、遅延のある回線を通じてデータを転送する以上、リモートのレプリカがインポートを完了する前に、新たなドリフトが確実に生まれます。

さらに、回線遅延だけが課題であり、再構築後のoplogには再構築時に発生したドリフトのみが含まれると仮定してみましょう。それでも、レプリケーションラグを引き起こした元々の問題は残ったままです。結果として、時間の経過とともに新しく構築されたセカンダリは、再び再構築を余儀なくされることになります。

場合によっては、この挙動がレプリケーションラグと再構築の無限ループに陥り、リモートのセカンダリが一度も正常な稼働状態に達せずに終わることさえあります。

AEMにとっての意味

AEMにとって、これは重大な教訓を意味します。MongoDBレプリカをクロスサイトオーサリングの主要データソースとして採用すると、リモート拠点のオーサーが深刻なリスクにさらされるのです。マルチサイトでのMongoMK導入を検討する際は、サイト間のネットワーク遅延の実測、oplogサイズの適切な設計、そしてTarMK構成との比較検証など、入念なアーキテクチャ評価が不可欠といえるでしょう。