このページでは、AEM デプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に以下のページを参照してください。
次の図に、AEMで使用できるデプロイメントオプションを示します(すべてのオプションを表示するまでスクロール)。
AEM 製品 |
トポロジ |
オペレーティングシステム |
アプリケーションサーバー |
JRE |
セキュリティ |
マイクロカーネル |
データストア |
インデックス作成 |
Web サーバー |
ブラウザー |
Marketing Cloud |
Sites |
非 HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
セグメント |
Property |
Apache |
Edge |
ターゲット |
Assets |
パブリッシュ - HA |
Solaris |
WebLogic |
IBM |
SAML |
MongoDB |
File |
Lucene |
IIS |
IE |
分析 |
Communities |
オーサー - CS |
Red Hat |
WebSphere |
HP |
OAuth |
RDB/Oracle |
S3/Azure |
Solr |
iPlanet |
Firefox |
Campaign |
フォーム |
オーサー - オフロード |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Chrome |
Social |
モバイル |
オーサー - クラスター |
IBM AIX |
JBoss |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
対象者 |
Multi-site |
ASRP |
SUSE |
|
|
|
RDB/SQLServer |
|
|
|
|
アセット |
Commerce |
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で使用されるマイクロカーネルには3種類あります。TarMK、MongoDB、およびリレーショナルデータベース(制限付きサポート下)。 インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルの詳細については、推奨されるデプロイメントページを参照してください。
AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先はデータストアと呼ばれます。一方、コンテンツノードおよびプロパティの格納先はノードストアと呼ばれます。
アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方について、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。
リレーショナルデータベースマイクロカーネルは制限付きでサポートされます。このタイプのマイクロカーネルを使用する前に、アドビカスタマーケアにお問い合わせください。
多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトに大量のメディアアセットが必要な場合、FileまたはAzure/S3 Data Storeの下に格納すると、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/コア | インテル® Xeon® CPU E5-2407 @2.40GHz、8コア |
RAM | 32 GB |
ディスク | 磁気 |
Java | OracleJREバージョン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 レプリカセットは常に奇数のインスタンスで構成する必要があります。
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにする必要があります。
優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。設定の変更方法については、このページを参照してください。
設定 | パラメーター | 値 (default) | 説明 |
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/コア | インテル® Xeon® CPU E5-2407 @2.40GHz、8コア | インテル® Xeon® CPU E5-2407 @2.40GHz、8コア |
RAM | 32 GB | 32 GB |
ディスク | 磁気 — 1,000 IOPSを超える | 磁気 — 1,000 IOPSを超える |
Java | OracleJREバージョン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/コア | インテル(R) Xeon(R) CPU E5-2407 @2.40GHz、8コア | インテル(R) Xeon(R) CPU E5-2407 @2.40GHz、8コア | |
RAM | 32 GB | 32 GB | |
ディスク | 磁気 — 1,000 IOPSを超える | 磁気 — 1,000 IOPSを超える | |
Java | OracleJREバージョン8 | 該当なし | |
JVMヒープ16GB | 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 - 10,000 IOPS | SSD - 10,000 IOPS | SSD - 10,000 IOPS |
Java | OracleJREバージョン8 | OracleJREバージョン8 |
該当なし |
JVMヒープ16GB | 30 GB | 30 GB | 該当なし |
製品 | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
ノードストア | TarMK | MongoMK | 該当なし |
データストア | ファイルDS | ファイルDS |
該当なし |
シナリオ |
|
このページで示したガイドラインは、次のように要約できます。
ファイルデータストアを使用する TarMK は、ほとんどの顧客に対する推奨アーキテクチャです。
ファイルデータストアを使用する MongoMK は、オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャです。
ノードストアは、ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納する必要があります。
AmazonS3を使用する場合:
デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します。
ワークフローのカスタマイズは、パフォーマンスを大幅に向上させます。例えば、「アセットを更新」ワークフローのビデオ手順の削除、使用されていないリスナーの無効化など。
詳しくは、推奨されるデプロイメントのページも参照してください。