Adobe Experience Manager Assets 性能調整ガイド

Experience Manager Assetsセットアップには、多数のハードウェア、ソフトウェア、およびネットワークコンポーネントが含まれています。 導入のシナリオによっては、パフォーマンス上のボトルネックを排除するために、ハードウェア、ソフトウェアおよびネットワークコンポーネントに対して特殊な設定変更が必要になる場合があります。

さらに、特定のハードウェアおよびソフトウェアの最適化ガイドラインを特定し、遵守することで、Experience Manager Assets導入環境がパフォーマンス、拡張性、信頼性に関する期待に応える確実な基盤を構築できます。

Experience Manager Assetsのパフォーマンスが低いと、インタラクティブパフォーマンス、アセット処理、ダウンロード速度、その他の領域でのユーザーエクスペリエンスに影響を与える可能性があります。

パフォーマンスの最適化は、すべてのプロジェクトでターゲット指標を確立する前に実行する、基本的なタスクです。

ユーザーに影響を及ぼす前にパフォーマンス上の問題を検出して修正する必要がある主な領域は次のとおりです。

プラットフォーム

Experience Managerは数多くのプラットフォームでサポートされていますが、AdobeはLinuxとWindowsでネイティブツールの最大のサポートを見つけ、最適なパフォーマンスと実装の容易さに貢献しています。 Experience Manager Assets導入の高メモリ要件を満たす64ビットオペレーティングシステムを導入するのが理想的です。 Experience Manager導入の場合と同様に、可能な限りTarMKを実装する必要があります。 TarMK は単一のオーサーインスタンスを超えて拡張できませんが、パフォーマンスは MongoMK よりも優れています。TarMKオフロードインスタンスを追加して、Experience Manager Assets導入のワークフロー処理能力を高めることができます。

一時フォルダー

アセットのアップロード時間を改善するには、Javaの一時ディレクトリに高いパフォーマンスのストレージを使用します。 Linux および Windows の場合は、RAM ドライブまたは SSD を使用できます。クラウドベースの環境では、同等の高速ストレージタイプを使用できます。例えば、AmazonEC2では、Ephemeral Driveドライブを一時フォルダーに使用できます。

サーバーに十分なメモリがあるという前提で、RAM ドライブを設定します。Linux の場合、8GB RAM ドライブを作成するには、次のコマンドを実行します。

mkfs -q /dev/ram1 800000
 mkdir -p /mnt/aem-tmp
 mount /dev/ram1 /mnt/aem-tmp
 df -H | grep aem-tmp

Windows OSでは、サードパーティ製のドライバを使用してRAMドライブを作成するか、SSDなどの高パフォーマンスストレージを使用します。

高パフォーマンスの一時ボリュームの準備が整ったら、JVMパラメーター-Djava.io.tmpdirを設定します。 例えば、Experience Managerのbin/startスクリプト内のCQ_JVM_OPTS変数に次のJVMパラメーターを追加できます。

-Djava.io.tmpdir=/mnt/aem-tmp

Java の設定

Java バージョン

Adobeでは、最適なパフォーマンスを得るために、Java 8にExperience Manager Assetsを導入することをお勧めします。

JVM パラメーター

次のJVMパラメーターを設定します。

• -XX:+UseConcMarkSweepGC
• -Doak.queryLimitInMemory=500000
• -Doak.queryLimitReads=100000
• -Dupdate.limit=250000
• -Doak.fastQuerySize=true

データストアとメモリの設定

ファイルデータストアの設定

すべてのExperience Manager Assetsユーザーには、データストアとセグメントストアを分けることをお勧めします。 また、maxCachedBinarySize パラメーターと cacheSizeInMB パラメーターを設定することでパフォーマンスを最大化するのに役立ちます。キャッシュに含めることができるように、maxCachedBinarySize を最小のファイルサイズに設定します。cacheSizeInMB 内のデータストアで使用するインメモリキャッシュのサイズを指定します。この値は合計ヒープサイズの 2～10％に設定することをお勧めします。ただし、負荷テストやパフォーマンステストが理想的な設定を決定するのに役立ちます。

バッファーされる画像キャッシュの最大サイズの設定

大量のアセットをAdobe Experience Managerにアップロードする場合、メモリ消費量が予期せぬ急増を生じさせ、OutOfMemoryErrorsでJVMが失敗するのを防ぐために、バッファされたイメージキャッシュの最大サイズを小さくします。 例えば、最大ヒープ（-Xmx パラメーター）が 5 GB のシステムで、Oak BlobCache が 1 GB、文書キャッシュが 2 GB に設定されているとします。このときに、バッファーされるキャッシュが最大 1.25 GB のメモリを使用した場合、予期しないスパイクに使用できるメモリは 0.75 GB のみとなります。

バッファーされるキャッシュサイズは OSGi Web コンソールで設定します。https://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache で、プロパティ cq.dam.image.cache.max.memory をバイト単位で指定します。例えば、1073741824 は 1 GB です（1024 x 1024 x 1024 = 1 GB）。

Experience Manager6.1 SP1から、sling:osgiConfigノードを使用してこのプロパティを設定する場合は、データタイプをLongに設定する必要があります。 詳しくは、CQBufferedImageCache がアセットのアップロード中にヒープを消費するを参照してください。

共有データストア

S3 または共有ファイルデータストアの実装は、ディスク領域の節約と大規模な実装におけるネットワークスループットの向上に役立ちます。共有データストアの使用の長所と短所について詳しくは、アセットサイズ変更ガイドを参照してください。

S3 データストア

次の S3 データストアの設定（org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.cfg）は、アドビが 12.8 TB のバイナリラージオブジェクト（BLOB）を既存のファイルデータストアから顧客サイトの S3 データストアに抽出するのに役立ちました。

accessKey=<snip>
 secretKey=<snip>
 s3Bucket=<snip>
 s3Region=us-standard
 s3EndPoint=<a href="https://s3.amazonaws.com/">s3.amazonaws.com</a>
 connectionTimeout=120000
 socketTimeout=120000
 maxConnections=80
 writeThreads=60
 concurrentUploadsThreads=30
 asyncUploadLimit=30
 maxErrorRetry=1000
 path=/opt/author/crx-quickstart/repository/datastore
 s3RenameKeys=false
 s3Encryption=SSE_S3
 proactiveCaching=true
 uploadRetries=1000
 migrateFailuresCount=400

ネットワークの最適化

多くの企業には HTTP トラフィックをスニッフィングするファイアウォールがあり、ファイルのアップロードに干渉しファイルを破損するので、HTTPS を有効にすることをお勧めします。サイズの大きなファイルのアップロードについては、Wi-Fi ネットワークでは簡単に飽和するおそれがあるので、必ず有線でネットワークに接続してください。ネットワークのボトルネックの特定に関するガイドラインについては、アセットサイズ設定ガイドを参照してください。 ネットワークトポロジを分析してネットワークのパフォーマンスを評価する方法については、アセットネットワークに関する考慮事項を参照してください。

主に、ネットワーク最適化戦略は、使用可能な帯域幅の量とExperience Managerインスタンスの負荷に依存します。 ファイアウォールやプロキシなどの一般的な設定オプションは、ネットワークのパフォーマンスの改善に役立ちます。留意点は次のとおりです。

• インスタンスのタイプ（小、中、大）に応じて、Experience Managerインスタンスに十分なネットワーク帯域幅があることを確認します。 Experience ManagerがAWSでホストされている場合は、十分な帯域幅の割り当てが特に重要です。
• Experience ManagerインスタンスがAWSでホストされている場合は、用途の広いスケーリングポリシーを利用できるのでメリットが得られます。 高い負荷が予想される場合は、インスタンスのサイズを大きくします。負荷が標準的または低い場合は、インスタンスのサイズを小さくします。
• HTTPS：ユーザーの多くは HTTP トラフィックをスニッフィングするファイアウォールを装備しており、ファイルのアップロード操作に干渉しファイルを破損することもあります。
• サイズの大きなファイルのアップロード：必ず有線でネットワークに接続してください（Wi-Fi 接続は簡単に飽和するおそれがあります）。

ワークフロー

一時的なワークフロー

可能な場合は、DAM Update Assetワークフローを「一時的」に設定します。 この設定にすると、ワークフローが通常のトラッキングやアーカイブ処理をパススルーする必要がなくなるので、ワークフローの処理に必要なオーバーヘッドが大幅に削減されます。

1. https://[aem_server]:[port]/miscadminのExperience Managerデプロイメントの/miscadminに移動します。

2. ツール/ワークフロー/モデル/dam​を展開します。

3. DAM Update Asset​を開きます。 フローティングツールパネルで、「ページ」タブに切り替えて「ページプロパティ」をクリックします。

4. 「一時的なワークフロー​​」を選択し、「OK」をクリックします。

   メモ

   一部の機能は一時的なワークフローをサポートしません。Assetsデプロイメントでこれらの機能が必要な場合は、一過性のワークフローを設定しないでください。

一過性のワークフローを使用できない場合は、定期的にワークフローの削除を実行して、アーカイブされたDAM Update Assetワークフローを削除し、システムのパフォーマンスが低下しないようにします。

通常、パージワークフローは週単位で実行します。 ただし、大規模なアセット取り込みの際など、リソースを大量に消費するシナリオでは、より頻繁にアセットを実行できます。

ワークフローのパージを設定するには、OSGi コンソールで新しい Adobe Granite のワークフローのパージ設定を追加します。次に、ワークフローを週次メンテナンスウィンドウの一部としてスケジュールを設定します。

パージの実行時間が長すぎる場合、タイムアウトします。このため、ワークフローの数が多すぎることが原因でパージワークフローが終わらない状況を避けるために、パージジョブが確実に終わるようにする必要があります。

例えば、多数の非一過性ワークフロー（ワークフローインスタンスノードを作成）を実行した後、ACS AEM Commons Workflow Removerをアドホックに実行できます。 これにより、冗長および完了したワークフローのインスタンスが即座に削除されるので、Adobe Granite のワークフローのパージスケジューラーが実行されるのを待つ必要がありません。

並列ジョブの最大数

デフォルトでは、Experience Managerは、サーバー上のプロセッサ数と同じ数の並列ジョブを実行します。 この設定の問題は、負荷が大きい時間帯に、すべてのプロセッサーがDAM Update Assetワークフローに占有され、UIの応答性が低下し、Experience Managerがサーバーのパフォーマンスと安定性を保護する他のプロセスを実行できないことです。 次の手順を実行して、この値をサーバーで使用できるプロセッサーの半分の値にすることをお勧めします。

1. Experience Manager作成者でhttps://[aem_server]:[port]/system/console/slingeventにアクセスします。

2. Granite Transient Workflow Queue​のように、実装に関連する各ワークフローキューで「編集」をクリックします。

3. Maximum Parallel Jobs​の値を更新し、Save​をクリックします。

まずは、キューを使用できるプロセッサーの半分に設定してください。ただし、場合によっては最大のスループットを得るためにこの値をお使いの環境に合わせて増減させる必要があります。一時的および一時的でないワークフローには別個のキューが用意されているほか、外部ワークフローなどその他の処理も存在します。プロセッサーの 50％に設定された複数のキューが同時にアクティブになると、システムはすぐにオーバーロードします。頻繁に使用されるキューは、ユーザーの実装により大きく異なります。このため、サーバーの安定性を損なうことなく効率を最大化するには、これらを慎重に設定する必要が生じる場合があります。

DAM アセットの更新設定

DAM Update Assetワークフローには、Dynamic MediaPTIFFの生成やAdobe InDesign Server統合など、タスク用に構成されたすべての手順が含まれています。 ただし、大多数のユーザーにとってこれらの手順のうちのいくつかは不要です。Adobeでは、DAM Update Assetワークフローモデルのカスタムコピーを作成し、不要な手順を削除することをお勧めします。 この場合、DAM Update Assetのランチャーを更新して、新しいモデルを指定します。

DAM Update Assetワークフローを大幅に実行すると、ファイルデータストアのサイズを大幅に拡大できます。 アドビが実施した実験の結果によると、8 時間以内に約 5,500 のワークフローを実行した場合、データストアのサイズが約 400 GB 増加する可能性があります。

これは一時的な増加であり、データストアのガベージコレクションタスクを実行すると、データストアは元のサイズに戻ります。

通常、データストアのガベージコレクションタスクは、スケジュールされた他のメンテナンスタスクと共に毎週実行されます。

ディスク領域が限られていて、DAM Update Assetワークフローを集中的に実行する場合は、ガベージコレクションタスクのスケジュールをより頻繁に設定することを検討してください。

実行時のレンディションの生成

お客様は Web サイトやビジネスパートナーへの配布に様々なサイズや形式の画像を使用します。各レンディションによりリポジトリ内のアセットの足跡が増加するので、この機能は適切なタイミングで使用することをお勧めします。画像の処理と保存に必要なリソースを減らすために、これらの画像を取り込み中にではなく実行時にレンディションとして生成できます。

多くの Sites のお客様はリクエストされた時点で画像のサイズを変更および切り抜く画像サーブレットを実装しています。これにより、パブリッシュインスタンスにさらに負荷がかけられます。ただし、これらの画像をキャッシュできる限り、問題を減らすことができます。

別のアプローチは、Dynamic Mediaの技術を使って完全な画像操作を手渡すことです。 さらに、Experience Managerインフラストラクチャのレンディション生成の責任を引き継ぐだけでなく、公開層全体を引き継ぐBrand Portalを展開できます。

ImageMagick

DAM Update AssetワークフローをカスタマイズしてImageMagickを使用したレンディションを生成する場合、Adobeでは/etc/ImageMagick/のpolicy.xmlファイルを変更することを推奨します。 デフォルトでは、ImageMagick は OS ボリュームで使用できるディスク領域と空きメモリをすべて使用します。policy.xmlのpolicymapセクション内で次の設定変更を行い、これらのリソースを制限します。

<policymap>
  <!-- <policy domain="system" name="precision" value="6"/> -->
  <policy domain="resource" name="temporary-path" value="/ephemeral0/imagemagick_tmp"/>
  <policy domain="resource" name="memory" value="1000MiB"/>
  <policy domain="resource" name="map" value="1000MiB"/>
  <!-- <policy domain="resource" name="area" value="1gb"/> -->
  <policy domain="resource" name="disk" value="10000MiB"/>
  <!-- <policy domain="resource" name="file" value="768"/> -->
  <policy domain="resource" name="thread" value="1"/>
  <policy domain="resource" name="throttle" value="50"/>
  <!-- <policy domain="resource" name="time" value="3600"/> -->
</policymap>

さらに、configure.xmlファイル内のImageMagickの一時フォルダーのパスを、十分な容量とIOPSを持つ環境パーティションに設定します（または、ディスク変数MAGIC_TEMPORARY_PATHを設定します）。

Adobe Managed Services(AMS)でExperience Managerを使用している場合は、大量のPSDファイルまたはPSBファイルを処理する予定の場合は、Adobeカスタマーケアにお問い合わせください。 AMS導入のためのこれらのベストプラクティスを実装し、Adobe独自の形式に対して可能な限り最適なツールとモデルを選択するには、Adobeカスタマーケアの担当者にご相談ください。 Experience Manager は、30000 x 23000ピクセルを超える高解像度PSBファイルを処理できない場合があります。

XMP の書き戻し

XMPの書き戻しでは、メタデータがExperience Managerで変更されると元のアセットが更新され、次の結果になります。

• アセット自体が変更されます
• アセットのバージョンが作成されます
• 「DAM アセットの更新」がアセットに対して実行されます

上記の結果により、大量のリソースが消費されます。このため、この機能が必要でない場合は、XMP の書き戻しを無効化することをお勧めします。

ワークフロー実行フラグがチェックされている場合、大量のメタデータを読み込むと、リソースを集中的に使用する XMP 書き戻しアクティビティが発生するおそれがあります。このような読み込みは、他のユーザーのパフォーマンスに影響しないように、サーバー使用率が低いときに計画します。

レプリケーション

Sites の実装などで、アセットを多数のパブリッシュインスタンスにレプリケートするときは、チェーンレプリケーションを使用することをお勧めします。この場合、オーサーインスタンスが単一のパブリッシュインスタンスにレプリケートし、そのパブリッシュインスタンスが代わりに他のパブリッシュインスタンスにレプリケートすることで、オーサーインスタンスを解放します。

チェーンレプリケーションの設定

1. レプリケーションのチェーン先に使用するパブリッシュインスタンスを選択します。
2. そのパブリッシュインスタンスで、他のパブリッシュインスタンスを指すレプリケーションエージェントを追加します。
3. 追加した各レプリケーションエージェントで、「トリガー」タブの「受信時」を有効にします。

検索インデックス

システムインデックスの更新が含まれている場合が多いので、最新のサービスパックやパフォーマンス関連のホットフィックスを実装してください。インデックスの最適化については、パフォーマンス調整のヒントを参照してください。

頻繁に実行するクエリにカスタムインデックスを作成します。詳しくは、スロークエリの分析手法（英語）とカスタムインデックスの作成を参照してください。クエリとインデックスのベストプラクティスに関するその他の洞察については、クエリとインデックスのベストプラクティスを参照してください。

Lucene Index の設定

Experience Manager Assetsのパフォーマンスを向上させるため、Oakインデックスの構成で最適化を行うことができます。 インデックス構成を更新して再インデックス作成時間を改善します。

1. CRXDe /crx/de/index.jspを開き、管理ユーザーとしてログインします。
2. /oak:index/luceneを参照します。
3. 値追加/var、/etc/workflow/instances、および/etc/replicationを持つString[]プロパティexcludedPaths。
4. /oak:index/damAssetLuceneを参照します。 値追加/content/damのString[]プロパティincludedPaths。 変更を保存します。

例えば、PDFドキュメント内のテキストを検索する場合など、アセットをフルテキスト検索する必要がない場合は、これを無効にします。 フルテキストインデックスを無効にすると、インデックスのパフォーマンスが向上します。 Apache Luceneテキスト抽出を無効にするには、次の手順に従います。

1. Experience Managerインターフェイスで、パッケージマネージャーにアクセスします。
2. disable_indexingbinarytextraction-10.zipで入手可能なパッケージをアップロードしてインストールします。

guessTotal

大きな結果セットを生成するクエリを作成するときは、クエリ実行時のメモリ消費を抑えるために guessTotal パラメーターを使用してください。

既知の問題

サイズの大きなファイル

Experience Managerには大きなファイルに関する2つの主な既知の問題があります。 ファイルのサイズが 2 GB 以上に到達すると、コールドスタンバイの同期でメモリ不足のエラーが発生することがあります。場合によっては、スタンバイの同期が実行されなくなります。また、プライマリインスタンスのクラッシュを引き起こすこともあります。このシナリオは、Experience Manager内の2 GBを超えるファイル（コンテンツパッケージを含む）に適用されます。

同様に、共有S3データストアを使用している間にファイルのサイズが2 GBに達した場合は、ファイルがキャッシュからファイルシステムに完全に保持されるまでに時間がかかる場合があります。 結果として、バイナリなしのレプリケーションを使用しているとき、レプリケーションが完了する前にバイナリデータが保持されていなかった可能性があります。この状況は、特にデータの可用性が重要な場合に問題を引き起こす可能性があります。

パフォーマンスのテスト

Experience Manager導入のたびに、ボトルネックを迅速に特定し解決できるパフォーマンステスト体制を確立します。 留意点は次のとおりです。

ネットワークのテスト

お客様からのネットワークのパフォーマンスに関するすべての懸念については、次のタスクを実行してください。

• お客様のネットワーク内からネットワークのパフォーマンスをテストする
• アドビのネットワーク内からネットワークのパフォーマンスをテストする：AMS ユーザーの場合、CSE を使用してアドビのネットワーク内からテストしてください。
• 別のアクセスポイントからネットワークのパフォーマンスをテストする
• ネットワークのベンチマークツールを使用する
• ディスパッチャーに対してテストする

Experience Manager 導入テスト

CPUの効率的な使用率と負荷分散により、待ち時間を最小限に抑え、高いスループットを実現するには、Experience Manager導入環境のパフォーマンスを定期的に監視します。 具体的には、次のことを実行します。

• Experience Manager展開に対してロードテストを実行します。
• アップロードのパフォーマンスと UI の応答性を監視する.

Experience Manager Assets 資産管理タスクの性能チェックリストと影響

• HTTPS を有効化して企業の HTTP トラフィックスニッファーに対応する.
• サイズの大きなアセットのアップロードには有線接続を使用する.
• Java 8 にデプロイする
• 最適な JVM パラメーターを設定する。
• ファイルシステムのDataStoreまたはS3データストアを構成します。
• サブアセットの生成を無効にします。 この機能が有効な場合、AEMワークフローは、複数ページのアセット内の各ページに対して個別のアセットを作成します。 これらの各ページは、追加のディスク領域を消費し、バージョン管理や追加のワークフロー処理が必要な個々のアセットです。 別々のページが必要ない場合は、サブアセットの生成とページ抽出のアクティビティを無効にします。
• 一時的なワークフローを有効化する.
• Granite のワークフローキューを調整して同時に実行されるジョブ数を制限する.
• ImageMagickを設定して、リソースの消費を制限します。
• DAM Update Assetワークフローから不要な手順を削除します。
• ワークフローとバージョンのパージを設定する.
• 最新のサービスパックとホットフィックスでインデックスを最適化する。利用可能なインデックスのその他の最適化については、Adobeカスタマーケアにお問い合わせください。
• guessTotal を使用してクエリのパフォーマンスを最適化する。
• ファイルの内容からファイルの種類を検出するようにExperience Managerを設定した場合(AEM Webコンソール​で​Day CQ DAM MIME Type Service​を有効にして)、リソースを大量に消費するため、多くのファイルを一括アップロードします。