このページでは、AEMデプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に、次のページを確認してください。
以下に AEM で使用できるデプロイメントオプションを示します(すべてのオプションを表示するにはスクロールしてください)。
AEM 製品 |
トポロジ |
オペレーティングシステム |
アプリケーションサーバー |
JRE |
セキュリティ |
マイクロカーネル |
データストア |
インデックス作成 |
Web サーバー |
ブラウザー |
Experience Cloud |
Sites |
非 HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
セグメント |
プロパティ |
Apache |
Edge |
ターゲット |
Assets |
パブリッシュ - HA |
Solaris™ |
WebLogic |
IBM® |
SAML |
MongoDB |
File |
Lucene |
IIS |
IE |
Analytics |
Communities |
オーサー - CS |
Red Hat® |
WebSphere® |
HP |
OAuth |
RDB/Oracle |
S3/Azure |
Solr |
iPlanet |
Firefox |
Campaign |
Forms |
オーサー - オフロード |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Chrome |
Social |
モバイル |
オーサー - クラスター |
IBM® AIX® |
JBoss® |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
対象読者 |
Multi-site |
ASRP |
SUSE® |
|
|
|
RDB/SQLServer |
|
|
|
|
Assets |
コマース |
MSRP |
Apple OS |
|
|
|
|
|
|
|
|
アクティベーション |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
モバイル |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveFyre |
|
|
|
|
|
|
|
|
|
|
|
スクリーン |
|
|
|
|
|
|
|
|
|
|
|
Doc Security |
|
|
|
|
|
|
|
|
|
|
|
Process Mgt |
|
|
|
|
|
|
|
|
|
|
|
デスクトップアプリケーション |
|
|
|
|
|
|
|
|
|
|
|
パフォーマンスガイドラインは主に AEM Sites に適用されます。
パフォーマンスガイドラインは次の状況で使用します。
この章では、AEM のアーキテクチャと AEM の最も重要なコンポーネントの大まかな概要を説明します。また、開発ガイドラインを示し、TarMK および MongoMK ベンチマークテストで使用されるテストシナリオについて説明します。
AEM のプラットフォームは、次のコンポーネントで構成されています。
AEM のプラットフォームについて詳しくは、AEM とはを参照してください。
AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。オーサーインスタンスは、コンテンツ作成者、編集者、および承認者がコンテンツの作成およびレビューを行うために使用します。コンテンツが承認されると、パブリッシュインスタンスという名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。
マイクロカーネルは AEM で永続性マネージャーとして機能します。AEM で使用されるマイクロカーネルには、TarMK、MongoDB、リレーショナルデータベース(制限付きサポート)の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。
AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先はデータストアと呼ばれます。一方、コンテンツノードおよびプロパティの格納先はノードストアと呼ばれます。
アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方について、顧客がデフォルトで使用する永続性技術として TarMK を推奨します。
リレーショナルデータベースマイクロカーネルは制限付きでサポートされます。このタイプのマイクロカーネルを使用する前に、アドビカスタマーケアにお問い合わせください。
多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは Azure/S3 データストアに格納すると、MongoDB 内に直接格納する場合よりも迅速にアセットにアクセスできます。
使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。
アドビでは、Adobe Managed Services を使用して Azure または Amazon Web Services(AWS)に AEM をデプロイするオプションを選択することをお勧めします。お客様は、これらのクラウドコンピューティング環境で AEM をデプロイおよび運用する経験とスキルを持つチームのメリットを享受できます。Adobe Managed Services に関するドキュメントを参照してください。
Adobe Managed Services の外部で Azure または AWS に AEM をデプロイする場合のレコメンデーションは、クラウドプロバイダーと直接共同作業することです。または、任意のクラウド環境での AEM のデプロイをサポートするアドビのパートナーと協力することもできます。選択したクラウドプロバイダーまたはパートナーは、アーキテクチャのサイズ仕様、設計、および実装を担当し、顧客独自のパフォーマンス、負荷、スケーラビリティおよびセキュリティの要件が満たされるように支援します。
>技術要件ページも参照してください。
この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックス作成について詳しくは、Oak クエリとインデックス作成を参照してください。
アドビでは、ほとんどのデプロイメントで Lucene Index を使用することを推奨します。Solr は、特殊で複雑なデプロイメントでスケーラビリティを確保するためにのみ使用してください。
AEM はパフォーマンスとスケーラビリティを目標として開発してください。指針にすることができるベストプラクティスを次に示します。
DO
DON'T
可能な場合は、JCR API を直接使用しない
/libs を変更せずに、オーバーレイを使用する
可能な限りクエリを使用しない
Java™ コードで OSGi サービスを取得する場合は、Sling Binding を使用せずに以下を使用してください。
AEM での開発について詳しくは、開発の基本を参照してください。その他のベストプラクティスについては、開発のベストプラクティスを参照してください。
このページに表示されているすべてのベンチマークテストは、ラボ設定で行われています。
以下で説明するテストシナリオは、TarMK、MongoMk、および TarMK と MongoMk の章のベンチマークの節で使用されています。特定のベンチマークテストで使用されているシナリオを確認するには、技術仕様表のシナリオフィールドを参照してください。
単一製品シナリオ
AEM Assets:
混合製品シナリオ
AEM 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 の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。
アドビでは、すべてのデプロイメントシナリオにおいて、AEM オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。
TarMK について詳しくは、デプロイメントのシナリオおよび Tar ストレージを参照してください。
以下に示す最小アーキテクチャガイドラインは、実稼動環境および高トラフィックサイト向けです。これらのガイドラインは、AEM を実行するための最小仕様ではありません。
TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。
以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにする必要があります。
AEM Sites での Tar アーキテクチャガイドライン
AEM Assets での Tar アーキテクチャガイドライン
パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください。
設定 | パラメーター | 値 | 説明 |
Sling ジョブキュー | queue.maxparallel |
CPU コア数の半分の値に設定します。 | デフォルトでは、ジョブキューあたりの同時スレッド数は、CPU コア数と同じです。 |
Granite 一時ワークフローキュー | Max Parallel |
CPU コア数の半分の値に設定します。 | |
JVM パラメーター |
|
500000 100000 250000 True |
大規模なクエリによってシステムが過負荷になることを防ぐため、AEM の起動スクリプトにこれらの JVM パラメーターを追加します。 |
Lucene インデックス設定 |
|
Enabled Enabled Enabled |
利用可能なパラメーターについて詳しくは、このページを参照してください。 |
データストア = S3 データストア |
|
1048576(1 MB)以下 最大ヒープサイズの 2~10% |
データストアの設定も参照してください。 |
DAM アセットの更新ワークフロー | Transient Workflow |
チェック済み | このワークフローではアセットの更新を管理します. |
DAM メタデータの書き戻し | Transient Workflow |
チェック済み | このワークフローでは、元のバイナリへの XMP の書き戻しを管理し、JCR で最終変更日を設定します。 |
以下の仕様に基づいてベンチマークテストが実行されました。
オーサーノード | |
---|---|
サーバー | ベアメタルハードウェア(HP) |
オペレーティングシステム | Red Hat® Linux® |
CPU/コア | Intel® Xeon® CPU E5-2407 @2.40GHz、8 コア |
RAM | 32 GB |
ディスク | 磁気 |
Java™ | Oracle JRE バージョン 8 |
JVM ヒープ | 16 GB |
製品 | AEM 6.2 |
ノードストア | TarMK |
データストア | ファイル DS |
シナリオ | 単一の製品:アセット/30 個の同時スレッド |
以下に示す数値は、ベースラインとして 1 に正規化されており、実際のスループットの数値ではありません。
TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。
TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。
MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャを出発点にする必要があります。
実稼動環境では、MongoDB は常に、プライマリと 2 つのセカンダリを持つレプリカセットとして使用されます。プライマリで読み取りと書き込みが行われ、セカンダリでは読み取りが行われることがあります。ストレージを利用できない場合、セカンダリの 1 つをアービターに置き換えることができますが、MongoDB レプリカセットは常に奇数のインスタンスで構成する必要があります。
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにする必要があります。
パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください。
設定 | パラメーター | 値(デフォルト) | 説明 |
Sling ジョブキュー | queue.maxparallel |
CPU コア数の半分の値に設定します。 | デフォルトでは、ジョブキューあたりの同時スレッド数は、CPU コア数と同じです。 |
Granite 一時ワークフローキュー | Max Parallel |
CPU コア数の半分の値に設定します。 | |
JVM パラメーター |
|
500000 100000 250000 True 60000 |
大規模なクエリによってシステムが過負荷になることを防ぐため、AEM の起動スクリプトにこれらの JVM パラメーターを追加します。 |
Lucene インデックス設定 |
|
Enabled Enabled Enabled |
使用可能なパラメーターについて詳しくは、このページを参照してください。 |
データストア = S3 データストア |
|
1048576(1 MB)以下 最大ヒープサイズの 2~10% |
データストアの設定も参照してください。 |
DocumentNodeStoreService |
|
2048 35(25) 20(10) 30(5) 10(3) 4(4) 。/cache,size=2048,binary=0,-compact,-compress |
キャッシュのデフォルトサイズは 256 MB に設定されています。 キャッシュの無効化の実行にかかる時間に影響します。 |
oak-observation |
|
最小および最大 = 20 50000 |
以下の仕様に基づいてベンチマークテストが実行されました。
オーサーノード | MongoDB ノード | |
---|---|---|
サーバー | ベアメタルハードウェア(HP) | ベアメタルハードウェア(HP) |
オペレーティングシステム | Red Hat® Linux® | Red Hat® Linux® |
CPU/コア | Intel® Xeon® CPU E5-2407 @2.40GHz、8 コア | Intel® Xeon® CPU E5-2407 @2.40GHz、8 コア |
RAM | 32 GB | 32 GB |
ディスク | 磁気 - 1,000 IOPS を超える | 磁気 - 1,000 IOPS を超える |
Java™ | Oracle JRE バージョン 8 | 該当なし |
JVM ヒープ | 16 GB | 該当なし |
製品 | AEM 6.2 | MongoDB 3.2 WiredTiger |
ノードストア | MongoMK | 該当なし |
データストア | ファイル DS | 該当なし |
シナリオ | 単一の製品:アセット/30 個の同時スレッド | 単一の製品:アセット/30 個の同時スレッド |
以下に示す数値は、ベースラインとして 1 に正規化されており、実際のスループットの数値ではありません。
この 2 つのうちのどちらかを選択する際に考慮すべき基本ルールは、TarMK はパフォーマンス重視で設計されており、MongoMK はスケーラビリティ重視で使用されているということです。アドビでは、AEM オーサーインスタンスと AEM パブリッシュインスタンスの両方について、すべてのデプロイメントシナリオで顧客がデフォルトで使用する永続性技術として TarMK をお勧めします。
TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。
TarMK と MongoMK の比較について詳しくは、推奨されるデプロイメントを参照してください。
TarMK の利点
MongoMK を選択する基準
以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数値ではありません。
OAK オーサーノード | MongoDB ノード | ||
サーバー | ベアメタルハードウェア(HP) | ベアメタルハードウェア(HP) | |
オペレーティングシステム | Red Hat® Linux® | Red Hat® Linux® | |
CPU/コア | Intel(R) Xeon(R) CPU E5-2407 @2.40GHz、8 コア | Intel(R) Xeon(R) CPU E5-2407 @2.40GHz、8 コア | |
RAM | 32 GB | 32 GB | |
ディスク | 磁気 - 1,000 IOPS を超える | 磁気 - 1,000 IOPS を超える | |
Java™ | Oracle JRE バージョン 8 | 該当なし | |
JVM ヒープ 16 GB | 16 GB | 該当なし | |
製品 | AEM 6.2 | MongoDB 3.2 WiredTiger | |
ノードストア | TarMK または MongoMK | 該当なし | |
データストア | ファイル DS | 該当なし | |
シナリオ |
|
1 つの TarMK システムを使用した場合と同じ数のオーサーを MongoDB で有効にするには、2 つの AEM ノードを含むクラスターが必要です。4 ノードの MongoDB クラスターで処理できるオーサーの数は、1 つの TarMK インスタンスの 1.8 倍です。8 ノードの MongoDB クラスターで処理できるオーサーの数は、1 つの TarMK インスタンスの 2.3 倍です。
TarMK オーサーノード | MongoMK オーサーノード | MongoDB ノード | |
サーバー | AWS c3.8xlarge | AWS c3.8xlarge | AWS c3.8xlarge |
オペレーティングシステム | Red Hat® Linux® | Red Hat® Linux® | Red Hat® Linux® |
CPU/コア | 32 | 32 | 32 |
RAM | 60 GB | 60 GB | 60 GB |
ディスク | SSD - 10k IOPS | SSD - 10k IOPS | SSD - 10k IOPS |
Java™ | Oracle JRE バージョン 8 | Oracle JRE バージョン 8 |
該当なし |
JVM ヒープ 16 GB | 30 GB | 30 GB | 該当なし |
製品 | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
ノードストア | TarMK | MongoMK | 該当なし |
データストア | ファイル DS | ファイル DS |
該当なし |
シナリオ |
|
このページに示されているガイドラインの概要は次の通りです。
ファイルデータストアを使用する TarMK - 大部分の顧客に対する推奨アーキテクチャ:
ファイルデータストアを使用する MongoMK - オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャ:
ノードストア - ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納
Amazon S3 を使用する場合:
標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります - 最も一般的な検索に基づく
ワークフローをカスタマイズすると、パフォーマンスを大幅に改善できます - 「アセットを更新」ワークフローのビデオ手順を削除したり、使用されていないリスナーを無効化したりします。
詳しくは、推奨されるデプロイメントのページも参照してください。