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

最終更新日: 2023-12-07
  • トピック:
  • Configuring
    このトピックの詳細を表示
  • 作成対象:
  • Developer

このページでは、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 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 データストアを使用する場合などです。

はじめに

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

AEM のプラットフォーム

AEM のプラットフォームは、次のコンポーネントで構成されています。

chlimage_1

AEM のプラットフォームについて詳しくは、AEM とはを参照してください。

AEM のアーキテクチャ

AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。オーサーインスタンス​は、コンテンツ作成者、編集者、および承認者がコンテンツの作成およびレビューを行うために使用します。コンテンツが承認されると、パブリッシュインスタンス​という名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。

chlimage_1-1

マイクロカーネル

マイクロカーネルは AEM で永続性マネージャーとして機能します。AEM で使用されるマイクロカーネルには、TarMK、MongoDB、リレーショナルデータベース(制限付きサポート)の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。

chlimage_1-2

ノードストア

AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先は​データストア​と呼ばれます。一方、コンテンツノードおよびプロパティの格納先は​ノードストア​と呼ばれます。

メモ

アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方について、顧客がデフォルトで使用する永続性技術として TarMK を推奨します。

注意

リレーショナルデータベースマイクロカーネルは制限付きでサポートされます。このタイプのマイクロカーネルを使用する前に、アドビカスタマーケアにお問い合わせください。

chlimage_1-3

データストア

多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは 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 は、特殊で複雑なデプロイメントでスケーラビリティを確保するためにのみ使用してください。

chlimage_1-4

開発のガイドライン

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 の章のベンチマークの節で使用されています。特定のベンチマークテストで使用されているシナリオを確認するには、技術仕様表のシナリオフィールドを参照してください。

単一製品シナリオ

AEM Assets:

  • ユーザーインタラクション:アセットを参照/アセットを検索/アセットをダウンロード/アセットメタデータを読み取り/アセットメタデータを更新/アセットをアップロード/アセットのアップロードワークフローを実行
  • 実行モード:同時ユーザー、ユーザーごとの単一インタラクション

混合製品シナリオ

AEM Sites + Assets:

  • 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

この章では、最小のアーキテクチャ要件および設定を指定した TarMK の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。

アドビでは、すべてのデプロイメントシナリオにおいて、AEM オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。

TarMK について詳しくは、デプロイメントのシナリオおよび Tar ストレージを参照してください。

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

メモ

以下に示す最小アーキテクチャガイドラインは、実稼動環境および高トラフィックサイト向けです。これらのガイドラインは、AEM を実行するための最小仕様では​ありません

TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。

  • 1 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 2 つの Dispatcher

以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。

メモ

ファイルデータストアを共有する場合は、バイナリなしのレプリケーションを​オン​にする必要があります。

AEM Sites での Tar アーキテクチャガイドライン

chlimage_1-5

AEM Assets での Tar アーキテクチャガイドライン

chlimage_1-6

TarMK 設定ガイドライン

パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください

設定 パラメーター 説明
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 チェック済み このワークフローではアセットの更新を管理します.
DAM メタデータの書き戻し Transient Workflow チェック済み このワークフローでは、元のバイナリへの XMP の書き戻しを管理し、JCR で最終変更日を設定します。

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

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。

オーサーノード
サーバー ベアメタルハードウェア(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 に正規化されており、実際のスループットの数値ではありません。

chlimage_1-7 chlimage_1-8

MongoMK

TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。

TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。

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

MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャを出発点にする必要があります。

  • 3 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 3 つの MongoDB インスタンス
  • 2 つの Dispatcher
メモ

実稼動環境では、MongoDB は常に、プライマリと 2 つのセカンダリを持つレプリカセットとして使用されます。プライマリで読み取りと書き込みが行われ、セカンダリでは読み取りが行われることがあります。ストレージを利用できない場合、セカンダリの 1 つをアービターに置き換えることができますが、MongoDB レプリカセットは常に奇数のインスタンスで構成する必要があります。

メモ

ファイルデータストアを共有する場合は、バイナリなしのレプリケーションを​オン​にする必要があります。

chlimage_1-9

MongoMK 設定ガイドライン

パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください

設定 パラメーター 値(デフォルト) 説明
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-observation

thread pool

length

最小および最大 = 20

50000

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

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。

オーサーノード 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 に正規化されており、実際のスループットの数値ではありません。

chlimage_1-10 chlimage_1-11

TarMK と MongoMK

この 2 つのうちのどちらかを選択する際に考慮すべき基本ルールは、TarMK はパフォーマンス重視で設計されており、MongoMK はスケーラビリティ重視で使用されているということです。アドビでは、AEM オーサーインスタンスと AEM パブリッシュインスタンスの両方について、すべてのデプロイメントシナリオで顧客がデフォルトで使用する永続性技術として TarMK をお勧めします。

TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。

TarMK と MongoMK の比較について詳しくは、推奨されるデプロイメントを参照してください。

TarMK と MongoMk のガイドライン

TarMK の利点

  • コンテンツ管理アプリケーション専用に設計されています。
  • 常にファイルの一貫性が保たれ、任意のファイルベースのバックアップツールを使用してファイルをバックアップできます。
  • フェイルオーバーメカニズムを備えています。詳しくは、コールドスタンバイを参照してください。
  • 運用上のオーバーヘッドを最小限に抑えながら、パフォーマンスと信頼性の高いデータストレージを提供します。
  • TCO(総保有コスト)を削減します。

MongoMK を選択する基準

  • 1 日に接続する名前付きユーザーの数:数千人以上
  • 同時ユーザーの数:数百人以上
  • 1 日に取り込むアセットのボリューム:数十万件以上
  • 1 日あたりのページ編集のボリューム:数十万件以上
  • 1 日あたりの検索件数:数万件以上

TarMK と MongoMK のベンチマーク比較

メモ

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

シナリオ 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 該当なし
シナリオ


単一の製品:Assets/実行あたり 30 個の同時スレッド

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

chlimage_1-12

シナリオ 2 技術仕様

メモ

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

該当なし
シナリオ



垂直方向の使用例:メディア/2000 の同時スレッド

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

chlimage_1-13

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

chlimage_1-14

パフォーマンスガイドラインの概要

このページに示されているガイドラインの概要は次の通りです。

  • ファイルデータストアを使用する TarMK - 大部分の顧客に対する推奨アーキテクチャ:

    • 最小トポロジ:1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher
    • ファイルデータストアを共有する場合は、バイナリレスレプリケーションを有効にします
  • ファイルデータストアを使用する MongoMK - オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャ:

    • 最小トポロジ:3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher
    • ファイルデータストアを共有する場合は、バイナリレスレプリケーションを有効にします
  • ノードストア - ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納

  • Amazon S3 を使用する場合:

    • Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます
    • バイナリレスレプリケーションを有効にする必要があります
    • データストアのガベージコレクションを使用するには、最初にすべてのオーサーノードとパブリッシュノードで実行してから、オーサーノードでもう一度実行する必要があります
  • 標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります - 最も一般的な検索に基づく

    • カスタムインデックスには Lucene インデックスを使用する必要があります
  • ワークフローをカスタマイズすると、パフォーマンスを大幅に改善できます - 「アセットを更新」ワークフローのビデオ手順を削除したり、使用されていないリスナーを無効化したりします。

詳しくは、推奨されるデプロイメントのページも参照してください。

このページ