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

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

• AEM の基本概念
• AEM のストレージの概要
• 推奨されるデプロイメント
• 技術要件

以下に AEM で使用できるデプロイメントオプションを示します（すべてのオプションを表示するにはスクロールしてください）。

パフォーマンスガイドラインを使用するタイミング

次の状況では、パフォーマンスガイドラインを使用する必要があります。

• 初めてのデプロイメント:AEM Sitesまたは Assets の初めてのデプロイを計画する場合は、（デフォルト設定と比べて）マイクロカーネル、ノードストア、データストアを設定する際に使用できるオプションを理解しておくことが重要です。 例えば、TarMK のデータストアのデフォルト設定をファイルデータストアに変更します。
• 新しいバージョンへのアップグレード:新しいバージョンにアップグレードする場合は、実行中の環境と比較したパフォーマンスの違いを理解することが重要です。 例えば、AEM 6.1 から 6.2 へ、またはAEM 6.0 CRX2 から 6.2 OAK へのアップグレードです。
• 応答時間が遅い:選択したノードストアアーキテクチャが要件を満たしていない場合は、他のトポロジオプションと比較してパフォーマンスの違いを理解することが重要です。 例えば、MongoMK の代わりに TarMK をデプロイしたり、Amazon S3 またはMicrosoft Azure Data Store の代わりにファイルデータストアを使用したりします。
• 作成者の追加:推奨される TarMK トポロジがパフォーマンス要件を満たさず、オーサーノードのアップサイズが最大容量に達した場合は、3 つ以上のオーサーノードで MongoMK を使用する場合と比較して、パフォーマンスの違いを理解することが重要です。 例えば、TarMK の代わりに MongoMK をデプロイします。
• コンテンツの追加：推奨データストアアーキテクチャが要件を満たさない場合は、他のデータストアオプションと比較してパフォーマンスの違いを理解することが重要です。例えば、ファイルデータストアの代わりに Amazon S3 または Microsoft Azure データストアを使用する場合などです。

はじめに

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

AEM Platform

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

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

AEMアーキテクチャ

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

マイクロカーネル

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

ノードストア

AEMでは、バイナリデータをコンテンツノードとは独立して保存できます。 バイナリデータが保存される場所は、 データストア​コンテンツノードとプロパティの場所は ノードストア.

データストア

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

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

検索

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

開発のガイドライン

目指すAEMの開発が必要 パフォーマンスと拡張性. 以下に、従うことのできるベストプラクティスをいくつか示します。

実行

• プレゼンテーション、ロジック、コンテンツの分離を適用
• 既存のAEM API を使用 ( 例：Sling) とツール ( 例：レプリケーション )
• 実際のコンテンツのコンテキストで開発
• 最適なキャッシュ性を実現する開発
• 保存数を最小限に抑える ( 例：一時的なワークフローの使用
• すべての HTTP エンドポイントが RESTful であることを確認します。
• JCR 監視の範囲の制限
• 非同期スレッドに注意する

DON'T

• 可能な場合は、JCR API を直接使用しないでください

• /libs を変更せず、オーバーレイを使用

• 可能な限りクエリを使用しない

• Java コードで OSGi サービスを取得する際には Sling バインディングを使用せず、次のように使用します。

  • @Reference in DS component
  • @Inject in a Sling Model
  • Sightly 使用クラスの 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 設定ガイドライン

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

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

技術仕様

ベンチマークテストは以下の仕様に基づいて行われた。

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

MongoMK

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

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

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

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

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

MongoMK 設定のガイドライン

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

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

技術仕様

ベンチマークテストは以下の仕様に基づいて行われた。

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

TarMK と MongoMK

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

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

TarMK と MongoMK の詳細については、 推奨されるデプロイメント.

TarMK と MongoMk のガイドライン

TarMK のメリット

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

MongoMK を選択するための条件

• 1 日に接続した名前付きユーザーの数：何千もの間
• 同時ユーザー数：数百以上の
• 1 日あたりのアセット取り込みの量：何十万以上で
• 1 日あたりのページ編集の量：何十万以上で
• 1 日あたりの検索数：数十万以上で

TarMK と MongoMK のベンチマーク

シナリオ 1 技術仕様

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

シナリオ 2 技術仕様

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

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

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

このページで説明するガイドラインの概要を次に示します。

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

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

• ファイルデータストアを使用する MongoMK は、オーサー層の水平方向の拡張性を実現するための推奨アーキテクチャです。

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

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

• Amazon S3 を使用する場合：

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

• 標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります 最も一般的な検索に基づく

  • Lucene インデックスは、カスタムインデックスに使用する必要があります

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

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

Business.Adobe.com リソース

Asset Collections Content Intelligence Personalized Communications Dynamic Media Dynamic Forms Digital Signage