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

このページでは、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 ユーザーのインタラクション：アセットを参照／アセットを検索／アセットをダウンロード／アセットメタデータを読み取り／アセットメタデータを更新／アセットをアップロード／アセットのアップロードワークフローを実行
• 実行モード：同時ユーザー、ユーザーごとの混合インタラクション

垂直方向のユースケースのシナリオ

メディア：

• Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (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 オーサーインスタンスと 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 データストアは、オーサー層とパブリッシュ層の間で共有されます
  • バイナリレスレプリケーションを有効にする必要があります
  • データストアのガベージコレクションを使用するには、最初にすべてのオーサーノードとパブリッシュノードで実行してから、オーサーノードでもう一度実行する必要があります

• 標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります - 最も一般的な検索に基づく

  • カスタムインデックスには Lucene インデックスを使用する必要があります

• ワークフローをカスタマイズすると、パフォーマンスを大幅に改善できます - 「アセットを更新」ワークフローのビデオ手順を削除したり、使用されていないリスナーを無効化したりします。

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