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

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

Audience

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 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 をデプロイする場合などです。
  • コンテンツの追加:推奨データストアアーキテクチャが要件を満たさない場合は、他のデータストアオプションと比較してパフォーマンスの違いを理解することが重要です。例:ファイルデータストアの代わりに、AmazonS3または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

データストア

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

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 チェック済み このワークフローでは、元のバイナリへの 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)ではなくローカルディスクに格納する必要があります。

  • AmazonS3​を使用する場合:

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

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

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

このページ