このページでは、AEMデプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。 AEMを初めて使用する場合は、パフォーマンスガイドラインを読む前に、次のページを参照してください。
以下に AEM で使用できるデプロイメントオプションを示します(すべてのオプションを表示するにはスクロールしてください)。
AEM 製品 |
トポロジ |
オペレーティングシステム |
アプリケーションサーバー |
JRE |
セキュリティ |
マイクロカーネル |
データストア |
インデックス作成 |
Web サーバー |
ブラウザー |
Marketing Cloud |
Sites |
非 HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
セグメント |
プロパティ |
Apache |
Edge |
ターゲット |
Assets |
Publish-HA |
Solaris |
WebLogic |
IBM |
SAML |
MongoDB |
File |
Lucene |
IIS |
IE |
Analytics |
Communities |
Author-CS |
Red Hat |
WebSphere |
HP |
OAuth |
RDB/Oracle |
S3/Azure |
Solr |
iPlanet |
FireFox |
Campaign |
Forms |
オーサー — オフロード |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Chrome |
ソーシャル |
モバイル |
オーサー — クラスター |
IBM AIX |
JBoss |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
対象読者 |
マルチサイト |
ASRP |
SUSE |
|
|
|
RDB/SQLServer |
|
|
|
|
Assets |
コマース |
MSRP |
Apple OS |
|
|
|
|
|
|
|
|
アクティベーション |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
モバイル |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
LiveFyre |
|
|
|
|
|
|
|
|
|
|
|
スクリーン |
|
|
|
|
|
|
|
|
|
|
|
Doc Security |
|
|
|
|
|
|
|
|
|
|
|
Process Mgt |
|
|
|
|
|
|
|
|
|
|
|
デスクトップアプリケーション |
|
|
|
|
|
|
|
|
|
|
|
パフォーマンスガイドラインは主にAEM Sitesに適用されます。
次の状況では、パフォーマンスガイドラインを使用する必要があります。
この章では、AEMのアーキテクチャと最も重要なコンポーネントの概要を説明します。 また、開発ガイドラインを提供し、TarMK および MongoMK ベンチマークテストで使用されるテストシナリオについて説明します。
AEMプラットフォームは、次のコンポーネントで構成されています。
AEM のプラットフォームについて詳しくは、AEM とはを参照してください。
AEMデプロイメントには、3 つの重要な構築要素があります。 この オーサーインスタンス コンテンツ作成者、編集者および承認者がコンテンツの作成とレビューに使用する コンテンツが承認されると、コンテンツは、 発行インスタンス エンドユーザーがアクセスする場所から。 3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。
マイクロカーネルは、AEMの永続性マネージャーとして機能します。 AEM で使用されるマイクロカーネルには、TarMK、MongoDB、リレーショナルデータベース(制限付きサポート)の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。
AEMでは、バイナリデータをコンテンツノードとは独立して保存できます。 バイナリデータが保存される場所は、 データストアコンテンツノードとプロパティの場所は ノードストア.
Adobeでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方で顧客が使用するデフォルトの永続化テクノロジーとして TarMK を推奨します。
リレーショナルデータベースマイクロカーネルは制限付きでサポートされています。 連絡先 Adobeカスタマーケア このタイプのマイクロカーネルを使用する前に。
多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは Azure/S3 データストアに格納すると、MongoDB 内に直接格納するよりも迅速にアセットにアクセスできます。
使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。
AEM を Azure または Amazon Web Services(AWS)にデプロイする場合は、Adobe Managed Services を使用することをお勧めします。このサービスでは、これらのクラウドコンピューティング環境での AEM のデプロイと運用の経験とスキルを持つチームのサポートを受けられます。Adobe Managed Services に関するドキュメントも参照してください。
Adobe Managed Services 以外の Azure またはAWSにAEMをデプロイする方法に関する推奨事項については、クラウドプロバイダー、または選択したクラウド環境でのAEMのデプロイをサポートするパートナーと直接連携することを強くお勧めします。 選択したクラウドプロバイダーまたはパートナーは、特定のパフォーマンス、負荷、拡張性、セキュリティ要件を満たすためにサポートするアーキテクチャのサイズ設定、設計、実装を担当します。
詳細については、技術要件ページも参照してください。
この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックス作成について詳しくは、Oak クエリとインデックス作成を参照してください。
ほとんどのデプロイメントでは、Adobeは Lucene インデックスを使用することをお勧めします。 Solr は、特殊で複雑なデプロイメントのスケーラビリティにのみ使用してください。
目指すAEMの開発が必要 パフォーマンスと拡張性. 以下に、従うことのできるベストプラクティスをいくつか示します。
実行
DON'T
可能な場合は、JCR API を直接使用しないでください
/libs を変更せず、オーバーレイを使用
可能な限りクエリを使用しない
Java コードで OSGi サービスを取得する際には Sling バインディングを使用せず、次のように使用します。
AEMでの開発について詳しくは、 開発 — 基本. その他のベストプラクティスについては、 開発のベストプラクティス.
このページに表示されるすべてのベンチマークテストは、ラボ設定で実行されています。
以下に説明するテストシナリオは、TarMK、MongoMk、TarMK と MongoMk の各章のベンチマークセクションで使用されます。 特定のベンチマークテストで使用されているシナリオを確認するには、技術仕様表のシナリオフィールドを参照してください。
単一製品シナリオ
AEM Assets:
製品の混在シナリオ
AEM Sites + Assets:
垂直方向の使用例のシナリオ
メディア:
この章では、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) |
オペレーティングシステム | RedHat 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 を永続性ストレージシステムとして使用します。 複数のオーサーインスタンスを実行する必要があるのは、通常、すべての同時オーサリングアクティビティをサポートする単一のサーバーの 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) |
オペレーティングシステム | RedHat Linux | RedHat 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 オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。
TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールすることです。 つまり、2 つ以上のアクティブなオーサーインスタンスが常に実行され、MongoDB を永続性ストレージシステムとして使用します。 通常、複数のオーサーインスタンスを実行する必要があるのは、同時に実行するすべてのオーサリングアクティビティをサポートする単一のサーバーの CPU とメモリの容量が維持できなくなったためです。
TarMK と MongoMK の詳細については、 推奨されるデプロイメント.
TarMK のメリット
MongoMK を選択するための条件
以下に示す数値は、ベースラインとして 1 に正規化されており、実際のスループット数ではありません。
OAK オーサーノード | MongoDB ノード | ||
サーバー | ベアメタルハードウェア(HP) | ベアメタルハードウェア(HP) | |
オペレーティングシステム | RedHat Linux | RedHat 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 |
オペレーティングシステム | RedHat Linux | RedHat Linux | RedHat 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 を使用する場合:
標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります 最も一般的な検索に基づく
ワークフローをカスタマイズすると、パフォーマンスが大幅に向上する場合があります。例えば、「アセットの更新」ワークフローのビデオ手順を削除したり、使用されないリスナーを削除したりします。
詳しくは、推奨されるデプロイメントのページも参照してください。