パフォーマンスガイドライン

このページでは、AEM デプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に以下のページを参照してください。

• AEM の基本概念
• AEM のストレージの概要
• 推奨されるデプロイメント
• 技術要件

以下に AEM で使用できるデプロイメントオプションを示します（すべてのオプションを表示するにはスクロールしてください）。

パフォーマンスガイドラインの用途

パフォーマンスガイドラインは以下の状況で使用してください。

• 初回デプロイメント：AEM Sites または Assets の初めてのデプロイを計画している場合は、マイクロカーネル、ノードストアおよびデータストアの設定時に使用できるオプションについて理解することが重要です（デフォルト設定と比較して）。例えば、TarMK のデータストアのデフォルト設定をファイルデータストアに変更する場合などです。
• 新バージョンへのアップグレード：新バージョンにアップグレードする場合は、実行中の環境と比較してパフォーマンスの違いを理解することが重要です。例えば、AEM 6.1 から 6.2 へ、または AEM 6.0 CRX2 から 6.2 OAK にアップグレードする場合などです。
• 応答時間が遅い：選択したノードストアアーキテクチャが要件を満たさない場合は、他のトポロジオプションと比較してパフォーマンスの違いを理解することが重要です。例えば、MongoMK の代わりに TarMK をデプロイしたり、Amazon S3 または Microsoft Azure データストアの代わりにファイルデータストアを使用したりする場合です。
• オーサーの追加：推奨 TarMK トポロジがパフォーマンス要件を満たさず、オーサーノードのサイズ拡張が使用可能な最大容量に達した場合は、3 つ以上のオーサーノードで MongoMK を使用する場合と比較してパフォーマンスの違いを理解することが重要です。例えば、TarMK の代わりに MongoMK をデプロイする場合などです。
• コンテンツの追加：推奨データストアアーキテクチャが要件を満たさない場合は、他のデータストアオプションと比較してパフォーマンスの違いを理解することが重要です。例えば、ファイルデータストアの代わりに Amazon S3 または Microsoft Azure データストアを使用する場合などです。

はじめに

この章では、AEM のアーキテクチャと AEM の最も重要なコンポーネントの一般的な概要を示します。また、デプロイメントのガイドラインを示し、TarMK と MongoMK のベンチマークテストで使用されるテストシナリオについて説明します。

AEM のプラットフォーム

AEM のプラットフォームは、次のコンポーネントで構成されています。

AEM のプラットフォームについて詳しくは、AEM とはを参照してください。

AEM のアーキテクチャ

AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。オーサーインスタンス​は、コンテンツ作成者、編集者および承認者がコンテンツの作成およびレビューをおこなうために使用します。コンテンツが承認されると、パブリッシュインスタンス​という名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。

マイクロカーネル

マイクロカーネルは AEM で永続性マネージャーとして機能します。AEM で使用されるマイクロカーネルには、TarMK、MongoDB、リレーショナルデータベース（制限付きサポート）の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。

ノードストア

AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先は​データストア​と呼ばれます。一方、コンテンツノードおよびプロパティの格納先は​ノードストア​と呼ばれます。

データストア

多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは Azure／S3 データストアに格納すると、MongoDB 内に直接格納するよりも迅速にアセットにアクセスできます。

使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。

検索

この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックス作成について詳しくは、Oak クエリとインデックス作成を参照してください。

開発のガイドライン

AEM は​パフォーマンスとスケーラビリティ​を目標として開発してください。指針にすることができるいくつかのベストプラクティスを次に示します。

DO

• 表示、ロジックおよびコンテンツを分離する
• 既存の AEM API（Sling など）およびツール（レプリケーションなど）を使用する
• 実際のコンテンツのコンテキストで開発する
• キャッシュ可能性が最適になるように開発する
• 保存の回数を最小限に抑える（一時的なワークフローなどを使用）
• すべての HTTP エンドポイントが RESTful であるようにする
• JCR 監視の範囲を制限する
• 非同期スレッドに留意する

DON'T

• 可能な場合は、JCR API を直接使用しない

• /libs を変更せずに、オーバーレイを使用する

• 可能な限りクエリを使用しない

• Java コードで OSGi サービスを取得する場合は、Sling Binding を使用せずに以下を使用してください。

  • DS コンポーネントの @Reference
  • Sling Model の @Inject
  • Sightly Use クラスの sling.getService()
  • JSP の sling.getService()
  • ServiceTracker
  • OSGi サービスレジストリへの直接アクセス

AEM での開発について詳しくは、開発の基本を参照してください。その他のベストプラクティスについては、開発のベストプラクティスを参照してください。

ベンチマークのシナリオ

以下で説明するテストシナリオは、TarMK、MongoMk および TarMK と MongoMk の章のベンチマークの節で使用されています。特定のベンチマークテストで使用されているシナリオを確認するには、技術仕様表のシナリオフィールドを参照してください。

単一製品シナリオ

AEM Assets：

• ユーザーインタラクション：アセットの参照／アセットの検索／アセットのダウンロード／アセットメタデータの読み取り／アセットメタデータの更新／アセットのアップロード／アセットのアップロードワークフローの実行
• 実行モード：同時ユーザー、ユーザーごとの単一インタラクション

混合製品シナリオ

AEM Sites + Assets：

• Sites ユーザーのインタラクション：記事ページの読み取り／ページの読み取り／パラグラフの作成／パラグラフの編集／コンテンツページの作成／コンテンツページのアクティブ化／作成者検索
• Assets ユーザーのインタラクション：アセットの参照／アセットの検索／アセットのダウンロード／アセットメタデータの読み取り／アセットメタデータの更新／アセットのアップロード／アセットのアップロードワークフローの実行
• 実行モード：同時ユーザー、ユーザーごとの混合インタラクション

垂直方向の使用例のシナリオ

メディア：

• 記事ページの読み取り（27.4 ％）、ページの読み取り（10.9 ％）、セッションの作成（2.6 ％）、コンテンツページのアクティブ化（1.7 ％）、コンテンツページの作成（0.4 ％）、パラグラフの作成（4.3 ％）、パラグラフの編集（0.9 ％）、画像コンポーネント（0.9 ％）、アセットの参照（20 ％）、アセットメタデータの読み取り（8.5 ％）、アセットのダウンロード（4.2 ％）、アセットの検索（0.2 ％）、アセットメタデータの更新（2.4 ％）、アセットのアップロード（1.2 ％）、プロジェクトの参照（4.9 ％）、プロジェクトの読み取り（6.6 ％）、プロジェクト追加アセット（1.2 ％）、プロジェクト追加サイト（1.2 ％）、プロジェクトの作成（0.1 ％）、作成者検索（0.4 ％）
• 実行モード：同時ユーザー、ユーザーごとの混合インタラクション

TarMK

この章では、最小のアーキテクチャ要件および設定を指定した TarMK の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。

アドビでは、すべてのデプロイメントシナリオにおいて、AEM オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。

TarMK について詳しくは、デプロイメントのシナリオおよび Tar ストレージを参照してください。

TarMK 最小アーキテクチャガイドライン

TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。

• 1 つのオーサーインスタンス
• 2 つのパブリッシュインスタンス
• 2 つの Dispatcher

以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。

AEM Sites での Tar アーキテクチャガイドライン

AEM Assets での Tar アーキテクチャガイドライン

TarMK 設定ガイドライン

優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください。

TarMK パフォーマンスベンチマーク

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。

パフォーマンスベンチマークの結果

MongoMK

永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。

TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。

MongoMK 最小アーキテクチャガイドライン

MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始する必要があります。

• 3 つのオーサーインスタンス
• 2 つのパブリッシュインスタンス
• 3 つの MongoDB インスタンス
• 2 つの Dispatcher

MongoMK 設定ガイドライン

優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください。

MongoMK パフォーマンスベンチマーク

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。

パフォーマンスベンチマークの結果

TarMK と MongoMK

この 2 つのいずれかを選択する際には、TarMK はパフォーマンスを重視して設計されているのに対して、MongoMK はスケーラビリティを重視して使用されるという基本ルールを考慮する必要があります。アドビでは、すべてのデプロイメントシナリオにおいて、AEM オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。

永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。

TarMK と MongoMK について詳しくは、推奨されるデプロイメントを参照してください。

TarMK と MongoMk のガイドライン

TarMK の利点

• コンテンツ管理アプリケーション専用に作成されています。
• ファイルは常に一貫性が保たれ、任意のファイルベースのバックアップツールを使用してバックアップできます。
• フェイルオーバーメカニズムを備えています。詳しくは、コールドスタンバイを参照してください。
• 最小限の運用オーバーヘッドで高パフォーマンスと信頼性の高いデータストレージを提供します。
• TCO（総保有コスト）を削減します。

MongoMK を選択するための基準

• 1 日に接続する名前付きユーザーの数（数千人以上）
• 同時ユーザーの数（数百人以上）
• 1 日あたりのアセット収集のボリューム（数十万件以上）
• 1 日あたりのページ編集のボリューム（数十万件以上）
• 1 日あたりの検索のボリューム（数万件以上）

TarMK と MongoMK のベンチマーク

シナリオ 1 技術仕様

シナリオ 1 パフォーマンスベンチマークの結果

シナリオ 2 技術仕様

シナリオ 2 パフォーマンスベンチマークの結果

AEM Sites および AEM Assets のアーキテクチャスケーラビリティのガイドライン

パフォーマンスガイドラインのサマリ

このページで示したガイドラインは、次のように要約できます。

• ファイルデータストアを使用する TarMK は、ほとんどの顧客に対する推奨アーキテクチャです。

  • 最小トポロジ：1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
  • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。

• ファイルデータストアを使用する MongoMK は、オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャです。

  • 最小トポロジ：3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
  • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。

• ノードストア​は、ネットワーク接続ストレージ（NAS）ではなくローカルディスクに格納する必要があります。

• Amazon S3 を使用する場合：

  • Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます。
  • バイナリなしのレプリケーションをオンにする必要があります。
  • データストアのガベージコレクションは、最初にすべてのオーサーノードとパブリッシュノードに対して実行し、2 回目にオーサーに対して実行する必要があります。

• デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します。

  • カスタムインデックスには Lucene インデックスを使用してください。

• ワークフローをカスタマイズすると、パフォーマンスが大幅に向上する場合があります。例えば、「アセットの更新」ワークフローのビデオ手順を削除したり、使用されないリスナーを削除したりします。

詳しくは、推奨されるデプロイメントのページも参照してください。