パフォーマンスガイドライン performance-guidelines
このページでは、AEMデプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に、次のページを確認してください。
以下に AEM で使用できるデプロイメントオプションを示します(すべてのオプションを表示するにはスクロールしてください)。
パフォーマンスガイドラインを使用するタイミング when-to-use-the-performance-guidelines
パフォーマンスガイドラインは次の状況で使用します。
- 初回のデプロイメント: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 データストアを使用する場合などです。
はじめに introduction
この章では、AEM のアーキテクチャと AEM の最も重要なコンポーネントの大まかな概要を説明します。また、開発ガイドラインを示し、TarMK および MongoMK ベンチマークテストで使用されるテストシナリオについて説明します。
AEM のプラットフォーム the-aem-platform
AEM のプラットフォームは、次のコンポーネントで構成されています。
AEM のプラットフォームについて詳しくは、AEM とはを参照してください。
AEM のアーキテクチャ the-aem-architecture
AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。オーサーインスタンス は、コンテンツ作成者、編集者、および承認者がコンテンツの作成およびレビューを行うために使用します。コンテンツが承認されると、パブリッシュインスタンス という名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。
マイクロカーネル micro-kernels
マイクロカーネルは AEM で永続性マネージャーとして機能します。AEM で使用されるマイクロカーネルには、TarMK、MongoDB、リレーショナルデータベース(制限付きサポート)の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。
ノードストア nodestore
AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先は データストア と呼ばれます。一方、コンテンツノードおよびプロパティの格納先は ノードストア と呼ばれます。
データストア data-store
多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは Azure/S3 データストアに格納すると、MongoDB 内に直接格納する場合よりも迅速にアセットにアクセスできます。
使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。
技術要件ページも参照してください。
検索 search-features
この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックス作成について詳しくは、Oak クエリとインデックス作成を参照してください。
開発のガイドライン development-guidelines
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 での開発について詳しくは、開発の基本を参照してください。その他のベストプラクティスについては、開発のベストプラクティスを参照してください。
ベンチマークのシナリオ benchmark-scenarios
以下で説明するテストシナリオは、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
この章では、最小のアーキテクチャ要件および設定を指定した TarMK の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。
アドビでは、すべてのデプロイメントシナリオにおいて、AEM オーサーインスタンスとパブリッシュインスタンスの両方に対し TarMK をデフォルトの優先使用する技術とすることを顧客に推奨します。
TarMK について詳しくは、デプロイメントのシナリオおよび Tar ストレージを参照してください。
TarMK 最小アーキテクチャガイドライン tarmk-minimum-architecture-guidelines
TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。
- 1 つのオーサーインスタンス
- 2 つのパブリッシュインスタンス
- 2 つの Dispatcher
以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。
AEM Sites での Tar アーキテクチャガイドライン
AEM Assets での Tar アーキテクチャガイドライン
TarMK 設定ガイドライン tarmk-settings-guideline
パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、パフォーマンスの最適化を参照してください。
TarMK パフォーマンスベンチマーク tarmk-performance-benchmark
技術仕様 technical-specifications
以下の仕様に基づいてベンチマークテストが実行されました。
パフォーマンスベンチマーク結果 performance-benchmark-results
MongoMK mongomk
TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。
TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。
MongoMK 最小アーキテクチャガイドライン mongomk-minimum-architecture-guidelines
MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャを出発点にする必要があります。
- 3 つのオーサーインスタンス
- 2 つのパブリッシュインスタンス
- 3 つの MongoDB インスタンス
- 2 つの Dispatcher
MongoMK 設定ガイドライン mongomk-settings-guidelines
パフォーマンスを高めるには、次に示す設定ガイドラインに従う必要があります。設定を変更する手順については、パフォーマンスの最適化を参照してください。
MongoMK パフォーマンスベンチマーク mongomk-performance-benchmark
技術仕様 technical-specifications-1
以下の仕様に基づいてベンチマークテストが実行されました。
パフォーマンスベンチマーク結果 performance-benchmark-results-1
TarMK と MongoMK tarmk-vs-mongomk
この 2 つのうちのどちらかを選択する際に考慮すべき基本ルールは、TarMK はパフォーマンス重視で設計されており、MongoMK はスケーラビリティ重視で使用されているということです。アドビでは、AEM オーサーインスタンスと AEM パブリッシュインスタンスの両方について、すべてのデプロイメントシナリオで顧客がデフォルトで使用する永続性技術として TarMK をお勧めします。
TarMK よりも MongoMK 永続性バックエンドを選択する主な理由は、インスタンスを水平方向にスケールできることです。つまり、常に 2 つ以上のアクティブなオーサーインスタンスが動作しており、MongoDB が永続性ストレージシステムとして使用されます。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では、同時に実行されるすべてのオーサリングアクティビティをサポートできないからです。
TarMK と MongoMK の比較について詳しくは、推奨されるデプロイメントを参照してください。
TarMK と MongoMk のガイドライン tarmk-vs-mongomk-guidelines
TarMK の利点
- コンテンツ管理アプリケーション専用に設計されています。
- 常にファイルの一貫性が保たれ、任意のファイルベースのバックアップツールを使用してファイルをバックアップできます。
- フェイルオーバーメカニズムを備えています。詳しくは、コールドスタンバイを参照してください。
- 運用上のオーバーヘッドを最小限に抑えながら、パフォーマンスと信頼性の高いデータストレージを提供します。
- TCO(総保有コスト)を削減します。
MongoMK を選択する基準
- 1 日に接続する名前付きユーザーの数:数千人以上
- 同時ユーザーの数:数百人以上
- 1 日に取り込むアセットのボリューム:数十万件以上
- 1 日あたりのページ編集のボリューム:数十万件以上
- 1 日あたりの検索件数:数万件以上
TarMK と MongoMK のベンチマーク比較 tarmk-vs-mongomk-benchmarks
シナリオ 1 技術仕様 scenario-technical-specifications
シナリオ 1 パフォーマンスベンチマークの結果 scenario-performance-benchmark-results
シナリオ 2 技術仕様 scenario-technical-specifications-1
シナリオ 2 パフォーマンスベンチマークの結果 scenario-performance-benchmark-results-1
AEM Sites および AEM Assets のアーキテクチャスケーラビリティのガイドライン architecture-scalability-guidelines-for-aem-sites-and-assets
パフォーマンスガイドラインの概要 summary-of-performance-guidelines
このページに示されているガイドラインの概要は次の通りです。
-
ファイルデータストアを使用する TarMK - 大部分の顧客に対する推奨アーキテクチャ:
- 最小トポロジ:1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher
- ファイルデータストアを共有する場合は、バイナリレスレプリケーションを有効にします
-
ファイルデータストアを使用する MongoMK - オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャ:
- 最小トポロジ:3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher
- ファイルデータストアを共有する場合は、バイナリレスレプリケーションを有効にします
-
ノードストア - ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納
-
Amazon S3 を使用する場合:
- Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます
- バイナリレスレプリケーションを有効にする必要があります
- データストアのガベージコレクションを使用するには、最初にすべてのオーサーノードとパブリッシュノードで実行してから、オーサーノードでもう一度実行する必要があります
-
標準提供のインデックスに加えて、カスタムインデックスを作成する必要があります - 最も一般的な検索に基づく
- カスタムインデックスには Lucene インデックスを使用する必要があります
-
ワークフローをカスタマイズすると、パフォーマンスを大幅に改善できます - 「アセットを更新」ワークフローのビデオ手順を削除したり、使用されていないリスナーを無効化したりします。
詳しくは、推奨されるデプロイメントのページも参照してください。