Show Menu
トピック×

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

このページでは、AEM デプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に以下のページを参照してください。
以下に、AEMで使用可能なデプロイメントオプションを示します(スクロールしてすべてのオプションを表示)。
AEM
製品
トポロジ
オペレーティングシステム
アプリケーションサーバー
JRE
セキュリティ
マイクロカーネル
データストア
インデックス作成
Web サーバー
ブラウザー
Marketing Cloud
Sites
非 HA
Windows
CQSE
Oracle
LDAP
Tar
セグメント
プロパティ
Apache
Edge
ターゲット
Assets
パブリッシュ - HA
Solaris
WebLogic
IBM
SAML
MongoDB
ファイル
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
Mobile
オーサー - クラスター
IBM AIX
JBoss
RDB/MySQL
RDBMS
Safari
Audience
Multi-site
ASRP
SUSE
RDB/SQLServer
Assets
Commerce
MSRP
Apple OS
アクティベーション
Dynamic Media
JSRP
Mobile
Brand Portal
J2E
AoD
LiveFyre
スクリーン
Doc Security
Process Mgt
デスクトップアプリ
パフォーマンスガイドラインは主に AEM Sites に適用されます。

パフォーマンスガイドラインの用途

パフォーマンスガイドラインは以下の状況で使用してください。
  • 初回デプロイメント :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 Data storeを使用する。

概要

この章では、AEM のアーキテクチャと AEM の最も重要なコンポーネントの一般的な概要を示します。また、デプロイメントのガイドラインを示し、TarMK と MongoMK のベンチマークテストで使用されるテストシナリオについて説明します。

AEM のプラットフォーム

AEM のプラットフォームは、次のコンポーネントで構成されています。
For more information on the AEM platform, see What is AEM .

AEM のアーキテクチャ

AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。 オーサーインスタンス ​は、コンテンツ作成者、編集者および承認者がコンテンツの作成およびレビューをおこなうために使用します。コンテンツが承認されると、 パブリッシュインスタンス ​という名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。The third building block is the Dispatcher which is a module that handles caching and URL filtering and is installed on the webserver. AEM のアーキテクチャについて詳しくは、 典型的なデプロイメントシナリオ を参照してください。

マイクロカーネル

マイクロカーネルは AEM で永続性マネージャーとして機能します。AEMで使用されるマイクロカーネルには3種類あります。TarMK、MongoDB、およびリレーショナルデータベース(制限付きサポート下)。 インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。For additional information about Micro Kernels, see the Recommended Deployments page.

ノードストア

AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先は​ データストア ​と呼ばれます。一方、コンテンツノードおよびプロパティの格納先は​ ノードストア ​と呼ばれます。
アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方について、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。
リレーショナルデータベースマイクロカーネルは制限付きでサポートされます。このタイプのマイクロカーネルを使用する前に、 アドビカスタマーケア にお問い合わせください。

データストア

多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトに大量のメディアアセットが必要な場合、それらをファイルまたはAzure/S3 Data Storeに保存すると、MongoDBに直接保存するよりも高速にアクセスできます。
For further details on the available configuration options, see Configuring Node and Data Stores .
AEM を Azure または Amazon Web Services(AWS)にデプロイする場合は、Adobe Managed Services を使用することをお勧めします。このサービスでは、これらのクラウドコンピューティング環境での AEM のデプロイと運用の経験とスキルを持つチームのサポートを受けられます。Please see our additional documentation on Adobe Managed Services .
Adobe Managed Services の外部で Azure または AWS に AEM を デプロイする場合は、クラウドプロバイダーまたは使用するクラウド環境への AEM のデプロイメントをサポートするパートナーと直接共同作業することを強くお勧めします。選択したクラウドプロバイダーまたはパートナーは、アーキテクチャのサイズ仕様、設計および実装を担当し、顧客独自のパフォーマンス、負荷、スケーラビリティおよびセキュリティの要件が満たされるように支援します。
For additional details also see the technical requirements page.

検索

この節では AEM で使用されるカスタムインデックスプロバイダーを示します。To know more about indexing, see Oak Queries and Indexing .
アドビでは、ほとんどのデプロイメントで Lucene Index を使用することを推奨します。Solr は、特殊で複雑なデプロイメントでスケーラビリティを確保するためにのみ使用してください。

デプロイメントのガイドライン

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 の章のベンチマークの節で使用されています。To see which scenario was used for a particular benchmark test, read the Scenario field from the Technical Specifications table.
単一製品シナリオ
AEM Assets:
  • ユーザーインタラクション:アセットの参照/アセットの検索/アセットのダウンロード/アセットメタデータの読み取り/アセットメタデータの更新/アセットのアップロード/アセットのアップロードワークフローの実行
  • 実行モード:同時ユーザー、ユーザーごとの単一インタラクション
混合製品シナリオ
AEM Sites + Assets:
  • Sites ユーザーのインタラクション:記事ページの読み取り/ページの読み取り/パラグラフの作成/パラグラフの編集/コンテンツページの作成/コンテンツページのアクティブ化/作成者検索
  • Assets ユーザーのインタラクション:アセットの参照/アセットの検索/アセットのダウンロード/アセットメタデータの読み取り/アセットメタデータの更新/アセットのアップロード/アセットのアップロードワークフローの実行
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション
垂直方向の使用例のシナリオ
メディア:
  • 記事ページの読み取り(27.4 %)、ページの読み取り(10.9 %)、セッションの作成(2.6 %)、コンテンツページのアクティブ化(1.7 %)、コンテンツページの作成(0.4 %)、パラグラフの作成(4.3 %)、パラグラフの編集(0.9 %)、画像コンポーネント(0.9 %)、アセットの参照(20 %)、アセットメタデータの読み取り(8.5 %)、アセットのダウンロード(4.2 %)、アセットの検索(0.2 %)、アセットメタデータの更新(2.4 %)、アセットのアップロード(1.2 %)、プロジェクトの参照(4.9 %)、プロジェクトの読み取り(6.6 %)、プロジェクト追加アセット(1.2 %)、プロジェクト追加サイト(1.2 %)、プロジェクトの作成(0.1 %)、作成者検索(0.4 %)
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション

TarMK

この章では、最小のアーキテクチャ要件および設定を指定した TarMK の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。
アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方のすべてのデプロイメントシナリオで、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。
For more information about TarMK, see Deployment Scenarios and Tar Storage .

TarMK 最小アーキテクチャガイドライン

以下に示す最小アーキテクチャガイドラインは、実稼動環境および高トラフィックサイト向けです。These are not the minimum specifications needed to run AEM.
TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。
  • 1 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 2 つの Dispatcher
以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションを​ オン ​にする必要があります。
AEM Sites での Tar アーキテクチャガイドライン
AEM Assets での Tar アーキテクチャガイドライン

TarMK 設定ガイドライン

優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。For instructions on how to change the settings, see this page .
設定 パラメーター 説明
Sling ジョブキュー queue.maxparallel CPU コア数の半分の値に設定します。 デフォルトでは、ジョブキューあたりの同時スレッド数は CPU コア数と同じです。
Granite 一時的なワークフローキュー Max Parallel CPU コア数の半分の値に設定します。
JVM パラメーター
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
500000
100000
250000
True
AEM の起動スクリプトにこれらの JVM パラメーターを追加して、大量のデータを読み込むクエリによってシステムが過負荷になることを防ぎます。
Lucene インデックス設定
CopyOnRead
CopyOnWrite
Prefetch Index Files
Enabled
Enabled
Enabled
利用可能なパラメーターについて詳しくは、 このページ を参照してください。
データストア = S3 データストア
maxCachedBinarySize
cacheSizeInMB
1048576(1 MB)以下
最大ヒープサイズの 2 ~ 10 %
データストアの設定 も参照してください。
DAM アセットの更新ワークフロー Transient Workflow checked このワークフローではアセットの更新を管理します。
DAM メタデータの書き戻し Transient Workflow checked このワークフローでは、元のバイナリへの XMP の書き戻しを管理し、JCR で最終変更日を設定します。

TarMK パフォーマンスベンチマーク

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。
作成者ノード
サーバー
ベアメタルハードウェア(HP)
オペレーティングシステム
RedHat Linux
CPU /コア
インテル(R) Xeon(R) CPU E5-2407 @2.40 GHz、8コア
RAM
32 GB
ディスク
磁気
Java
Oracle JREバージョン8
JVMヒープ
16 GB
製品
AEM 6.2
ノードストア
TarMK
データストア
ファイルDS
シナリオ
単一製品:アセット/30個の同時スレッド

パフォーマンスベンチマークの結果

以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数ではありません。

MongoMK

永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。
For more information about TarMK, see Deployment Scenarios and Mongo Storage .

MongoMK 最小アーキテクチャガイドライン

MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始する必要があります。
  • 3 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 3 つの MongoDB インスタンス
  • 2 つの Dispatcher
実稼動環境では、MongoDB は 1 つのプライマリと 2 つのセカンダリを含むレプリカセットとして常に使用されます。プライマリでは読み取りと書き込みをおこない、セカンダリでは読み取りをおこなうことができます。ストレージを利用できない場合、セカンダリの 1 つをアービターで置き換えることができますが、MongoDB レプリカセットは常に奇数のインスタンスで構成する必要があります。
ファイルデータストアを共有する場合は、バイナリなしのレプリケーションを​ オン ​にする必要があります。

MongoMK 設定ガイドライン

優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。For instructions on how to change the settings, see this page .
設定 パラメーター 値(デフォルト) 説明
Sling ジョブキュー queue.maxparallel CPU コア数の半分の値に設定します。 デフォルトでは、ジョブキューあたりの同時スレッド数は CPU コア数と同じです。
Granite 一時的なワークフローキュー Max Parallel CPU コア数の半分の値に設定します。
JVM パラメーター
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
Doak.mongo.maxQueryTimeMS
500000
100000
250000
True
60000
AEM の起動スクリプトにこれらの JVM パラメーターを追加して、大量のデータを読み込むクエリによってシステムが過負荷になることを防ぎます。
Lucene インデックス設定
CopyOnRead
CopyOnWrite
Prefetch Index Files
Enabled
Enabled
Enabled
利用可能なパラメーターについて詳しくは、 このページ を参照してください。
データストア = S3 データストア
maxCachedBinarySize
cacheSizeInMB
1048576(1 MB)以下
最大ヒープサイズの 2 ~ 10 %
データストアの設定 も参照してください。
DocumentNodeStoreService
cache
nodeCachePercentage
childrenCachePercentage
diffCachePercentage
docChildrenCachePercentage
prevDocCachePercentage
persistentCache
2048
35(25)
20(10)
30(5)
10(3)
4(4)
。/cache,size=2048,binary=0,-compact,-compress
キャッシュのデフォルトサイズは 256 MB に設定されます。
キャッシュの無効化の実行にかかる時間に影響します。
oak の監視
thread pool
length
最小および最大 = 20
50000

MongoMK パフォーマンスベンチマーク

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。
作成者ノード
MongoDBノード
サーバー
ベアメタルハードウェア(HP)
ベアメタルハードウェア(HP)
オペレーティングシステム
RedHat Linux
RedHat Linux
CPU /コア
インテル(R) Xeon(R) CPU E5-2407 @2.40 GHz、8コア
インテル(R) Xeon(R) CPU E5-2407 @2.40 GHz、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 に正規化されており、実際のスループット数ではありません。

TarMK と MongoMK

この 2 つのいずれかを選択する際には、TarMK はパフォーマンスのために設計されているのに対して、MongoMK はスケーラビリティのために使用されるという基本ルールを考慮する必要があります。アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方のすべてのデプロイメントシナリオで、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。
永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。
TarMK と MongoMK について詳しくは、 推奨されるデプロイメント を参照してください。

TarMK と MongoMk のガイドライン

TarMK の利点
  • コンテンツ管理アプリケーション専用に作成されています。
  • ファイルは常に一貫性が保たれ、任意のファイルベースのバックアップツールを使用してバックアップできます。
  • Provides a failover mechanism - see Cold Standby for more details
  • 最小限の運用オーバーヘッドで高パフォーマンスと信頼性の高いデータストレージを提供します。
  • TCO(総保有コスト)を削減します。
MongoMK を選択するための基準
  • 1 日に接続する名前付きユーザーの数(数千人以上)
  • 同時ユーザーの数(数百人以上)
  • 1 日あたりのアセット収集のボリューム(数十万件以上)
  • 1 日あたりのページ編集のボリューム(数十万件以上)
  • 1 日あたりの検索のボリューム(数万件以上)

TarMK と MongoMK のベンチマーク

以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数ではありません。

シナリオ 1 技術仕様

作成者OAKノード MongoDBノード
サーバー ベアメタルハードウェア(HP) ベアメタルハードウェア(HP)
オペレーティングシステム RedHat Linux RedHat Linux
CPU /コア インテル(R) Xeon(R) CPU E5-2407 @2.40 GHz、8コア インテル(R) Xeon(R) CPU E5-2407 @2.40 GHz、8コア
RAM 32 GB 32 GB
ディスク 磁気 — 1,000 IOPSを超える 磁気 — 1,000 IOPSを超える
Java Oracle JREバージョン8 該当なし
JVMヒープ16GB 16 GB 該当なし
製品 AEM 6.2 MongoDB 3.2 WiredTiger
ノードストア TarMKまたはMongoMK 該当なし
データストア ファイルDS 該当なし
シナリオ
単一製品:1回の実行で30個の同時スレッド

シナリオ 1 パフォーマンスベンチマークの結果

シナリオ 2 技術仕様

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 Oracle JREバージョン8 Oracle JREバージョン8 該当なし
JVMヒープ16GB 30 GB 30 GB 該当なし
製品 AEM 6.2 AEM 6.2 MongoDB 3.2 WiredTiger
ノードストア TarMK MongoMK 該当なし
データストア ファイルDS ファイルDS 該当なし
シナリオ
縦置きの使用例:メディア/2000の同時スレッド

シナリオ 2 パフォーマンスベンチマークの結果

AEM Sites および AEM Assets のアーキテクチャスケーラビリティのガイドライン

パフォーマンスガイドラインのサマリ

このページで示したガイドラインは、次のように要約できます。
  • ファイルデータストアを使用する TarMK は、ほとんどの顧客に対する推奨アーキテクチャです。
    • 最小トポロジ:1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
    • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。
  • ファイルデータストアを使用する MongoMK は、オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャです。
    • 最小トポロジ:3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
    • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。
  • ノードストア ​は、ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納する必要があります。
  • When using Amazon S3 :
    • Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます。
    • バイナリなしのレプリケーションをオンにする必要があります。
    • データストアのガベージコレクションは、最初にすべてのオーサーノードとパブリッシュノードに対して実行し、2 回目にオーサーに対して実行する必要があります。
  • デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します
    • カスタムインデックスには Lucene インデックスを使用してください。
  • ワークフローのカスタマイズは 、例えば、「アセットを更新」ワークフローのビデオ手順の削除、使用されていないリスナーの無効化など、パフォーマンスを大幅に向上させます。
詳しくは、 推奨されるデプロイメント のページも参照してください。