このページでは、AEM デプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に以下のページを参照してください。
以下に AEM で使用できるデプロイメントオプションを示します(すべてのオプションを表示するにはスクロールしてください)。
AEM 製品 |
トポロジ |
オペレーティングシステム |
アプリケーションサーバー |
JRE |
セキュリティ |
マイクロカーネル |
データストア |
インデックス作成 |
Web サーバー |
ブラウザー |
Marketing 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 内に直接格納するよりも迅速にアセットにアクセスできます。
使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。
AEM を Azure または Amazon Web Services(AWS)にデプロイする場合は、Adobe Managed Services を使用することをお勧めします。このサービスでは、これらのクラウドコンピューティング環境での 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:
垂直方向の使用例のシナリオ
メディア:
この章では、最小のアーキテクチャ要件および設定を指定した 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 有効 有効 |
利用可能なパラメーターについて詳しくは、このページを参照してください。 |
データストア = S3 データストア |
|
1048576(1 MB)以下 最大ヒープサイズの 2 ~ 10 % |
データストアの設定も参照してください。 |
DAM アセットの更新ワークフロー | Transient Workflow |
checked | このワークフローではアセットの更新を管理します。 |
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 を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。
TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。
MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始する必要があります。
実稼動環境では、MongoDB は 1 つのプライマリと 2 つのセカンダリを含むレプリカセットとして常に使用されます。プライマリでは読み取りと書き込みをおこない、セカンダリでは読み取りをおこなうことができます。ストレージを利用できない場合、セカンダリの 1 つをアービターで置き換えることができますが、MongoDB レプリカセットは常に奇数のインスタンスで構成する必要があります。
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにする必要があります。
優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください。
設定 | パラメーター | 値(デフォルト) | 説明 |
Sling ジョブキュー | queue.maxparallel |
CPU コア数の半分の値に設定します。 | デフォルトでは、ジョブキューあたりの同時スレッド数は CPU コア数と同じです。 |
Granite 一時的なワークフローキュー | Max Parallel |
CPU コア数の半分の値に設定します。 | |
JVM パラメーター |
|
500000 100000 250000 True 60000 |
AEM の起動スクリプトにこれらの JVM パラメーターを追加して、大量のデータを読み込むクエリによってシステムが過負荷になることを防ぎます。 |
Lucene インデックス設定 |
|
有効 有効 有効 |
利用可能なパラメーターについて詳しくは、このページを参照してください。 |
データストア = 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 の監視 |
|
最小および最大 = 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 を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの 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 | 該当なし | |
シナリオ |
|
MongoDB で 1 つの TarMK システムと同じ数のオーサーを有効にするには、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 - 10,000 IOPS | SSD - 10,000 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 を使用する場合:
デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します。
ワークフローをカスタマイズすると、パフォーマンスが大幅に向上します例えば、「アセットを更新」ワークフローでビデオ手順を削除したり、使用されていないリスナーを無効にしたりする場合などです。
詳しくは、推奨されるデプロイメントのページも参照してください。