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

このページでは、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

分析

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

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 Data Storeを使用する。

はじめに

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

AEM のプラットフォーム

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

chlimage_1

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

AEM のアーキテクチャ

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

chlimage_1-1

マイクロカーネル

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

chlimage_1-2

ノードストア

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

メモ

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

注意

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

chlimage_1-3

データストア

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

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 ユーザーのインタラクション:アセットの参照/アセットの検索/アセットのダウンロード/アセットメタデータの読み取り/アセットメタデータの更新/アセットのアップロード/アセットのアップロードワークフローの実行
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション

垂直方向の使用例のシナリオ

メディア:

  • 記事ページの読み取り(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 を推奨します。

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

有効

有効

利用可能なパラメーターについて詳しくは、このページを参照してください。
データストア = S3 データストア

maxCachedBinarySize

cacheSizeInMB

1048576(1 MB)以下

最大ヒープサイズの 2 ~ 10 %

データストアの設定も参照してください。
DAM アセットの更新ワークフロー Transient Workflow checked このワークフローではアセットの更新を管理します。
DAM メタデータの書き戻し Transient Workflow checked このワークフローでは、元のバイナリへの XMP の書き戻しを管理し、JCR で最終変更日を設定します。

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

技術仕様

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

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

chlimage_1-7 chlimage_1-8

MongoMK

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

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

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

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

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

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

メモ

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

chlimage_1-9

MongoMK 設定ガイドライン

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

設定 パラメーター 値 (default) 説明
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

有効

有効

有効

利用可能なパラメーターについて詳しくは、このページを参照してください。
データストア = 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/コア インテル® 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 に正規化されており、実際のスループット数ではありません。

chlimage_1-10 chlimage_1-11

TarMK と MongoMK

この 2 つのいずれかを選択する際には、TarMK はパフォーマンスのために設計されているのに対して、MongoMK はスケーラビリティのために使用されるという基本ルールを考慮する必要があります。アドビでは、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)
オペレーティングシステム 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 該当なし
シナリオ


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

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

chlimage_1-12

シナリオ 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 OracleJREバージョン8
OracleJREバージョン8
該当なし
JVMヒープ16GB 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 データストアは、オーサー層とパブリッシュ層の間で共有されます。
    • バイナリなしのレプリケーションをオンにする必要があります。
    • データストアのガベージコレクションは、最初にすべてのオーサーノードとパブリッシュノードに対して実行し、2 回目にオーサーに対して実行する必要があります。
  • デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します

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

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

このページ