ドキュメントExperience Cloud KCS

Dispatcherのキャッシュを最適化する方法

最終更新日： 2026年6月24日

この記事では、Dispatcher キャッシュを最適化するための様々な方法について詳しく説明します。 さらに、TTL （「Time to Live」または有効期限）スタイルの無効化、Dispatcher フラッシュエージェントの無効化、Dispatcher フラッシュの再取得などを有効にする手順について説明します。

説明 description

環境

Adobe Experience Manager

問題/症状

この記事では、AEM Dispatcherの最新の最適化機能と、それらを最大限に活用する方法について説明します。 AEM Dispatcherは、Adobe Experience Managerで使用するために設計されたキャッシュ ​ リバースプロキシ ​ サーバーです。 既存のweb サーバーソフトウェア内でモジュールとしてインストールして実行できます。 この記事を書いている時点では、Apache HTTP Server、Microsoft IIS、iPlanetでDispatcher モジュールがサポートされています。

解決策 resolution

Dispatcherのキャッシュの仕組みはどのようになっていますか？

最も基本的なレベルでは、AEM Dispatcherは、キャッシュ、キャッシュフラッシュ、キャッシュ無効化を実行して機能するリバースプロキシです。

Dispatcherについて詳しくは、関連リンクを参照してください。

  1. Dispatcherの仕組みとインストール方法。
  2. Dispatcher🔗で使用できる設定オプション。
  3. Dispatcherの仕組みに関するウェビナー - プレゼンテーションの一部の情報は、Dispatcherの古いバージョンに基づいていることに注意してください。
  4. Dispatcherの機能、CDNの使用状況、セキュリティに関するGems ウェビナーセッション ​。
  5. Dispatcherの新しい機能（v4.1.9以降）に関するGems セッション ​。

Dispatcher キャッシュの最適化

Dispatcherのキャッシュを最適化する方法を以下に示します。

  1. ほとんどすべてをキャッシュ – これは、ユーザーから複数回リクエストされるコンテンツをキャッシュすることを意味します。

  2. パーソナライズされたコンテンツを異なる期間にキャッシュ - サイトにパーソナライズされたコンテンツがある場合は、AEM アプリケーションでApache Sling Dynamic Includesを使用して、Ajax （非同期JavaScriptおよびXML呼び出しをブラウザーレベルで）、SSI （サーバーサイドインクルードをWeb サーバーレベルで）、ESI （EdgeサイドインクルードをCDN レベルで）を活用し、ページの異なる期間キャッシュすることを検討してください。

  3. ライブDispatcherでDispatcher キャッシュを削除しない - Dispatcherがライブコンテンツを配信しており、キャッシュを削除すると、大量のリクエストがAEMに戻されます。  このため、Dispatcher キャッシュは、ライブ Dispatcher上で削除しないでください。

  4. Prime キャッシュ - Dispatcher キャッシュを削除する前に、Dispatcherをロードバランサーから削除し、キャッシュを削除してから、web web クローラーツールを実行してDispatcher上のファイルをキャッシュしてから、ロードバランサーに配置します。

  5. Cache error pages - DispatcherPassError 1 （Apache Web Server固有）ディレクティブを活用して、Dispatcher キャッシュから404sなどのエラーページを配信します。

  6. GZipは、事前に圧縮された以外のすべてのファイルタイプを圧縮します – Apache Web Serverでは、mod_deflateを使用できますが、Vary: User-Agent header が設定されていないことを確認してください。  Microsoft IIS では、動的圧縮を使用します。

    Apache設定の例（事前圧縮されたファイルタイプを避けるために、特定のコンテンツタイプのみを指定）:

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

  7. Enable /serveStaleOnError in the /cache configuration - AEM インスタンスがエラーを処理しているときに古いキャッシュファイルを処理します。

  8. 最後のコンテンツ公開イベント （「アクティベーション」）の後に、古い自動無効化されたリソースがキャッシュから引き続き提供される可能性がある秒数を定義します。/gracePeriodを/cache設定に追加します。  これにより、「ツリーのアクティブ化」などの大規模なコンテンツ公開アクティビティの際にパブリッシュインスタンスに戻るリクエストの数が減ります。

  9. ルールを/ignoreUrlParamsに追加 – アプリケーションで必要または使用されていないクエリ文字列パラメーターを無視します。  これにより、クエリ文字列が存在する場合でも、URL のキャッシュが可能になります。

  10. Cache-Control ヘッダーとLast-Modified レスポンス ヘッダーをキャッシュ - /headers設定を使用して、HTTP レスポンス ヘッダー Cache-Control およびLast-Modified （および/またはETag ヘッダーをAEMから送信する場合）をキャッシュします。  これは、CDN およびブラウザーレベルでキャッシュを簡素化し、最適化するのに役立ちます。  これらのヘッダーをキャッシュすることで、web サーバー自体ではなく、AEM のみがヘッダーを設定するようになります。  この場合、AEM アプリケーションからヘッダーの送信を開始する必要があります。

  11. コンテンツをできるだけ長くキャッシュするおよびAEMに戻るリクエストを減らす – すべてのフラッシュエージェントでフラッシュのリフェッチを有効にすることで、フラッシュリクエストを最適化します。 以下の「Dispatcher フラッシュの再取得」の節を参照してください。 または、/enableTTLを使用してCache-Control: max-age=…ファイルをできるだけ長くキャッシュする ヘッダー。  このトピックについて詳しくは、こちらを参照してください。

TTLの使用

Dispatcher バージョン 4.1.11以降、/enableTTL 1は任意のファイル設定で設定できます。  この設定により、Dispatcherは、HTTP Cache-Control レスポンスヘッダーで設定されたキャッシュの有効期限を尊重します。  つまり、Dispatcherは、ファイルの有効期限が切れるとプライマリ形式のキャッシュ無効化が発生するCDNと同様に機能します。  これを実装し、Cache-Control: max-age=…の送信を開始すると、 AEMからのすべての回答について、パブリッシュインスタンスでDispatcher フラッシュエージェントを安全に無効にできます。

パブリッシュインスタンスでフラッシュエージェントを無効にした後も、Dispatcher キャッシュをフラッシュできる場合があります。  その場合、ACS Commons - Dispatcher フラッシュ UI を使用することができます。  このツールは、オーサーインスタンスにインストールされています。  これは、ユーザーが手動でキャッシュのフラッシュリクエストを実行できる UI を提供します。

I. TTL（「Time to Live」または有効期限）スタイルの無効化を有効にするための手順：

  1. AEM アプリケーションのソースコードを変更して、まだ設定されていないすべてのリクエストに対してCache-Control ヘッダーとLast-Modified を送信します。
  2. Dispatcher 4.1.11以降をインストールします。
  3. サイトの任意のファーム設定で /enableTTL 1 を設定します。
  4. /headers 設定を設定して、Cache-ControlおよびLast-Modified ヘッダーをキャッシュします。
  5. Web サーバーを再起動します。

II. パブリッシュインスタンスでDispatcher フラッシュエージェントを無効にします：

Dispatcherでは、Cache-Control ヘッダーを使用して、キャッシュファイルの無効化を制御するようになりました。  この場合、パブリッシュインスタンスからのDispatcherのフラッシュは不要になります。

  1. 各パブリッシュインスタンスで/etc/replication/agents.publish.htmlに移動します。
  2. 各フラッシュエージェントの設定に移動して、エージェントを無効にします。

III. オーサーインスタンスからの手動のDispatcher フラッシュリクエストを許可：

フラッシュエージェントが無効になったので、Cache-Control ヘッダーを使用して、Dispatcherでコンテンツを更新するタイミングを制御します。  引き続き、Dispatcher キャッシュの手動フラッシュを発行できます。

  1. ACS Commons - Dispatcher フラッシュ UI をオーサーインスタンスにインストールします。
  2. オーサーインスタンスでフラッシュエージェントを設定します。
  3. 各エージェント設定で、トリガー => デフォルト オプションを有効に設定します。 このオプションは、ユーザーが AEM UI で 公開（非公開） または アクティブ化（非アクティブ化） をクリックしたときに、フラッシュエージェントを無視するようにします。

Dispatcher フラッシュを再取得しています

Dispatcher フラッシュリクエストを最適化するには、すべてのDispatcher フラッシュエージェントで、フラッシュのリフェッチを有効にするという機能を使用する必要があります。

Dispatcher フラッシュの再フェッチを有効にするには、次の操作を行います。

  1. http://aemhost:port/crx/packmgr/index.jspに移動し、管理者としてログインします。

  2. こちらからパッケージをダウンロードします。

  3. パッケージマネージャーにパッケージをアップロードしてインストールします。

  4. Dispatcher フラッシュエージェント設定に移動します。 例： /etc/replication/agents.author/flush.html

  5. 「編集」をクリックします。

  6. 次の内容を設定します。

    • Serialization Type = Re-fetch Dispatcher Flush
    • Extended => HTTP Method = POST

  7. 「Save」をクリックします

メモ – 上記のパッケージは基本的な例に過ぎません。  フラッシュの再取得をカスタマイズおよび最適化するために、送信する URI のリストを変更できます。  このコードはオープンソースで、こちらで見つけることができます。  このコードは、Dispatcherに再フェッチするパスを示すパラメーターとして、リクエスト本文にURIのリストを追加します。  アプリケーションの要件に合わせてパスを追加することで、サイトのキャッシュ機能を最適化できます。

フラッシュの再取得に関する詳細な説明

通常、Dispatcher フラッシュはファイルを削除することで機能します。

  1. .stat ファイルをタッチ
  2. /content/foo.*を削除
  3. /content/foo/_jcr_contentを削除します

手順2でファイルが削除されたため、ユーザーが/content/foo.htmlや/content/foo.jsonなどのファイルを次回リクエストすると、ファイルが「再フェッチ」される間、同じファイルに対する後続のリクエストも、ファイルがキャッシュされるまでパブリッシュインスタンスに送信されます。  応答が遅いページやホームページなどのトラフィックが多いページでは、これが、パブリッシュインスタンス層がフラッディングする原因となる可能性があります。

この問題を解決するには、Dispatcherのリフェッチという機能を有効にします。  この機能を使用すると、Dispatcherが積極的に「再フェッチ」し、代わりに削除する必要があるURIのリストを送信できます。

仕組みと設定方法のデモについては、このプレゼンテーションの 22:41-27:05 を参照してください。

recommendation-more-help
experience-cloud-kcs-help-kbarticles