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

このページでは、AEM デプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に以下のページを参照してください。

• 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 または 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 のプラットフォームは、次のコンポーネントで構成されています。

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

AEM のアーキテクチャ

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

マイクロカーネル

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

ノードストア

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

データストア

多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトに大量のメディアアセットが必要な場合、FileまたはAzure/S3 Data Storeの下に格納すると、MongoDBに直接格納するよりも高速にアクセスできます。

使用可能な設定オプションの詳細については、「ノードとデータストアの設定」を参照してください。

検索

この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックスの詳細については、Oakクエリとインデックスを参照してください。

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

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 最小アーキテクチャガイドライン

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

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

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

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

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

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個の同時スレッド

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

MongoMK

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

TarMKの詳細については、導入シナリオおよびMongoストレージを参照してください。

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

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

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

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個の同時スレッド

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

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 技術仕様

	作成者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 パフォーマンスベンチマークの結果

シナリオ 2 技術仕様

	作成者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 パフォーマンスベンチマークの結果

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

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

このページで示したガイドラインは、次のように要約できます。

• ファイルデータストアを使用する TarMK は、ほとんどの顧客に対する推奨アーキテクチャです。

  • 最小トポロジ：1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
  • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。

• ファイルデータストアを使用する MongoMK は、オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャです。

  • 最小トポロジ：3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
  • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。

• ノードストア​は、ネットワーク接続ストレージ（NAS）ではなくローカルディスクに格納する必要があります。

• AmazonS3​を使用する場合：

  • Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます。
  • バイナリなしのレプリケーションをオンにする必要があります。
  • データストアのガベージコレクションは、最初にすべてのオーサーノードとパブリッシュノードに対して実行し、2 回目にオーサーに対して実行する必要があります。

• デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します。

  • カスタムインデックスには Lucene インデックスを使用してください。

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

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