Adobe Experience Manager と MongoDB

最終更新日： 2024年8月20日

作成対象：

  • 管理者

この記事では、MongoDB を備えた AEM（Adobe Experience Manager）を正常にデプロイするために必要なタスクと考慮事項に関する知識を深めることを目的としています。

デプロイメントについて詳しくは、このドキュメントのデプロイとメンテナンスの節を参照してください。

AEM で MongoDB を使用すべき状況

MongoDB は通常、次のいずれかの条件を満たす AEM オーサーデプロイメントをサポートするために使用します。

  • 1 日あたり 1,000 人を超える個別ユーザー。
  • 100 人を超える同時ユーザー。
  • 大量のページ編集。
  • 大規模なロールアウトまたはアクティベーション。

上記の条件が適用されるのはオーサーインスタンスのみです。すべて TarMK ベースであるパブリッシュインスタンスには適用されません。オーサーインスタンスでは、未認証のアクセスは許可されないので、ユーザー数は認証済みユーザーの数を表します。

条件が満たされない場合は、可用性に対応するために、TarMK アクティブ／スタンバイデプロイメントをお勧めします。通常は、スケーリング要件が 1 台のハードウェアで実現できる範囲を超える場合に MongoDB を検討してください。

NOTE
オーサーインスタンスのサイズ設定と同時ユーザーの定義について詳しくは、ハードウェアのサイジングのガイドラインを参照してください。

AEM 向けの MongoDB の最小デプロイメント

AEM 向けの MongoDB の最小デプロイメントを以下に示します。説明を簡単にするために、SSL ターミネーションコンポーネントと HTTP プロキシコンポーネントは一般化されています。これは、1 つのプライマリと 2 つのセカンダリを含む単一の MongoDB レプリカセットで構成されています。

chlimage_1-4

最小デプロイメントには、レプリカセットとして設定された 3 つの mongod インスタンスが必要です。1 つのインスタンスはプライマリとして選択され、その他のインスタンスはセカンダリとして選択されます。この選択は、mongod によって管理されます。各インスタンスにローカルディスクが接続されています。クラスターで負荷に対応できるように、1 秒あたりの I/O 操作回数（IOPS）が 3,000 を超える毎秒 12 MB 以上のスループットが推奨されます。

AEM オーサーは mongod インスタンスに接続されます。各 AEM オーサーは 3 つの mongod インスタンスすべてに接続します。書き込みはプライマリに送信され、読み取りはどのインスタンスからも行うことができます。トラフィックは、Dispatcher によって、負荷に基づいてアクティブな AEM オーサーインスタンスのいずれかに分散されます。OAK データストアは FileDataStore であり、MongoDB の監視は、デプロイメントの場所に応じて、MMS または MongoDB Ops Manager によって提供されます。オペレーティングシステムレベルの監視とログの監視は、Splunk や Ganglia などのサードパーティソリューションによって提供されます。

このデプロイメントでは、実装が正常に機能するには、すべてのコンポーネントが必要です。コンポーネントが不足していると、実装は機能しません。

オペレーティングシステム

AEM 6 でサポートされているオペレーティングシステムのリストについては、技術要件のページを参照してください。

環境

プロジェクトを実行する様々な技術チーム間で良好なコミュニケーションが取れている場合に、仮想化環境がサポートされます。このサポートには、AEM を実行しているチーム、オペレーティングシステムを所有しているチームおよび仮想化インフラストラクチャを管理しているチームが含まれます。

MongoDB インスタンスの I/O 処理能力については特定の要件があり、この要件の管理は、仮想化環境を管理するチームで行う必要があります。Amazon Web Services などのクラウドデプロイメントをプロジェクトで使用する場合は、MongoDB インスタンスをサポートするための十分な I/O 処理能力と一貫性を確保できるようにインスタンスをプロビジョニングする必要があります。そうでない場合は、MongoDB プロセスと Oak リポジトリの動作が、信頼性が低い不安定なものになります。

仮想化環境では、VMWare のリソース割り当てポリシーによって MongoDB のストレージエンジンの機能が損なわれることがないように、MongoDB で特定の I/O 設定と VM 設定が必要になります。実装に成功すれば、様々なチーム間の障壁がなくなり、必要なパフォーマンスを実現するために全員が協力して取り組みます。

ハードウェアに関する考慮事項

ストレージ

水平方向のスケーリングを早い段階で行わなくても、読み書きのスループットが最適なパフォーマンスになるようにするには、通常、SSD ストレージまたは SSD 相当のパフォーマンスを提供するストレージが MongoDB で必要になります。

RAM

MMAP ストレージエンジンを使用する MongoDB バージョン 2.6 および 3.0 では、データベースの作業セットとそのインデックスが RAM に収まる必要があります。

十分な RAM がないと、パフォーマンスが大幅に低下します。作業セットとデータベースのサイズは、アプリケーションに大きく依存します。ある程度の推定は可能ですが、必要な RAM の量を判断するための最も信頼できる方法は、AEM アプリケーションを構築して負荷テストを実施することです。

負荷テストを実施する場合は、テストプロセスを支援するために、データベースの合計サイズに対する作業セットの比率を次のように想定することができます。

  • SSD ストレージの場合は 1:10
  • ハードディスクストレージの場合は 1:3

つまり、SSD デプロイメントの場合は、2 TB のデータベースに 200 GB の RAM が必要になります。

MongoDB 3.0 の WiredTiger ストレージエンジンにも同じ制限が適用されますが、作業セット、RAM およびページフォールトの間の相関関係はそれほど強くありません。WiredTiger は、MMAP ストレージエンジンとは異なり、メモリマッピングを使用しません。

NOTE
MongoDB 3.0 を使用する AEM 6.1 のデプロイメントには、WiredTiger ストレージエンジンを使用することをお勧めします。

データストア

MongoDB の作業セットの制限により、データストアを MongoDB とは独立に維持管理することをお勧めします。ほとんどの環境では、すべての AEM インスタンスに対して使用可能な NAS を使用する FileDataStore を使用してください。Amazon Web Services を使用する場合は、S3 DataStore もあります。何らかの理由でデータストアを MongoDB 内で維持管理する場合は、データストアのサイズをデータベースの合計サイズに加算し、作業セットの計算を適切に調整する必要があります。このサイズ設定では、ページフォールトを発生させずにパフォーマンスを維持するために、より多くの RAM をプロビジョニングする可能性があります。

モニタリング

プロジェクトを正常に実装するには、監視が不可欠です。十分な知識があれば、監視を行わずに AEM を MongoDB 上で実行することも可能です。しかし、その知識は、通常、デプロイメントの各セクションを専門とするエンジニアが持っているものです。

この専門知識には、通常、Apache Oak Core に取り組んでいる研究開発エンジニアや MongoDB スペシャリストが関与します。

すべてのレベルで監視を行わない場合、問題の診断には、コードベースの詳細な知識が必要になります。監視が実施され、主要な統計情報に関する適切なガイダンスが提供されれば、実装チームは異常値に的確に対応できます。

コマンドラインツールを使用してクラスターの動作のスナップショットを即座に取得することもできますが、多数のホストに対してこれをリアルタイムで行うのはほぼ不可能です。数分を超える履歴情報がコマンドラインツールで提供されることはほとんどなく、様々なタイプの指標を相互に関連付けることもできません。mongod のバックグラウンド同期が短期間遅くなると、見かけ上は接続されていない仮想マシンからの共有ストレージリソースに対する I/O の待機や過剰な書き込みレベルの相関関係を見つけるために手動による多大な労力が必要になります。

MongoDB Cloud Manager

MongoDB Cloud Manager は、MongoDB インスタンスの監視と管理を可能にする MongoDB 提供の無料サービスです。これを使用することで、MongoDB クラスターのパフォーマンスとヘルスをリアルタイムで把握できます。また、インスタンスが Cloud Manager 監視サーバーにアクセスできる場合は、クラウドでホストされているインスタンスとプライベートにホストされているインスタンスの両方を管理できます。

このサービスを使用するには、監視サーバーに接続する MongoDB インスタンスにエージェントがインストールされている必要があります。エージェントには次の 3 つのレベルがあります。

  • MongoDB サーバー上のすべての処理を完全に自動化できる自動化エージェント
  • mongod インスタンスを監視できる監視エージェント
  • スケジュールされたデータバックアップを実行できるバックアップエージェント

Cloud Manager を使用して MongoDB クラスターのメンテナンスを自動化すると、日常的なタスクの多くが容易になりますが、それは必須ではありません。また、バックアップに Cloud Manager を使用することも必須ではありません。ただし、監視を行うために Cloud Manager を選択した場合、監視は必須です。

MongoDB Cloud Manager について詳しくは、MongoDB のドキュメントを参照してください。

MongoDB Ops Manager

MongoDB Ops Manager は、MongoDB Cloud Manager と同じソフトウェアです。登録すると、Ops Manager をダウンロードして、プライベートデータセンターまたは他のノート PC やデスクトップ PC にローカルにインストールできます。このソフトウェアは、ローカルの MongoDB データベースを使用してデータを保存し、Cloud Manager と同様に管理対象サーバーと通信します。セキュリティポリシーで監視エージェントを禁止している場合は、MongoDB Ops Manager を使用してください。

オペレーティングシステムの監視

AEM MongoDB クラスターを実行するには、オペレーティングシステムレベルの監視が必要です。

そのようなシステムの良い例として Ganglia があります。Ganglia は、対象範囲の状況を報告し、CPU、負荷平均、空きディスク領域などの基本的なヘルス指標にとどまらず、必要な情報の詳細を表示します。問題を診断するには、エントロピープールレベル、CPU I/O 待機、FIN_WAIT2 状態のソケットなど、下位レベルの情報が必要です。

ログの集約

複数のサーバーで構成されるクラスターの場合、実稼動システムでは、ログの一元的な集約が必要になります。Splunk のようなソフトウェアでは、ログの集約をサポートしており、チームは、ログを手動で収集しなくても、アプリケーションの動作のパターンを分析できます。

チェックリスト

ここでは、プロジェクトを実装する前に、AEM と MongoDB のデプロイメントを適切にセットアップするために必要な様々な手順について説明します。

ネットワーク

  1. まず、すべてのホストに DNS エントリがあることを確認します。
  2. ルーティング可能な他のすべてのホストから、すべてのホストがそれぞれの DNS エントリによって解決できる必要があります。
  3. すべての MongoDB ホストは、同じクラスター内の他のすべての MongoDB ホストからルーティング可能です。
  4. MongoDB ホストは、MongoDB Cloud Manager およびその他の監視サーバーにパケットをルーティングできます。
  5. AEM サーバーは、すべての MongoDB サーバーにパケットをルーティングできます。
  6. 任意の AEM サーバーと MongoDB サーバーの間のパケット遅延は 2 ミリ秒未満であり、パケット損失がなく、標準的な配信は 1 ミリ秒以下です。
  7. AEM サーバーと MongoDB サーバーの間のホップは 2 つまでです。
  8. 2 つの MongoDB サーバー間のホップは 2 つまでです。
  9. 任意のコアサーバー（MongoDB、AEM または任意の組み合わせ）間には、OSI レベル 3 を超えるルーターは存在しません。
  10. VLAN トランキングまたは何らかの形のネットワークトンネリングを使用している場合は、パケット遅延チェックに適合している必要があります。