Dispatcher の概要 dispatcher-overview

Dispatcher は、Adobe Experience Manager のキャッシュやロードバランシングツールで、企業向けの web サーバーと組み合わせて使用します。

Dispatcher をデプロイするプロセスは、選択した web サーバーや OS プラットフォームに依存しません。

必要に応じて、次の情報を使用します。

Dispatcher を使用してキャッシュを実装する理由 why-use-dispatcher-to-implement-caching

Web パブリッシングには、次の 2 つの基本的な方法があります。

Dispatcher によって、高速かつ動的な環境を実現できます。Apache のような静的 HTML サーバーの一部として機能し、次の目的を達成します。

つまり、次のようになります。

Dispatcher には、動的サイトのコンテンツに基づいて静的 HTML を生成し、更新するメカニズムが含まれています。静的ファイルとして保存するドキュメントと、常に動的に生成されるドキュメントを詳細に指定できます。

この節では、このプロセスの原則について説明します。

静的 web サーバー static-web-server

Apache や IIS などの静的 web サーバーは、web サイトの訪問者に静的 HTML ファイルを提供します。静的ページは 1 回だけ作成されるので、リクエストごとに同じコンテンツが配信されます。

このプロセスは簡単で効率的です。訪問者が HTML ページなどのファイルをリクエストすると、ファイルはメモリから直接取得され、最悪の場合でもローカルドライブから読み取られます。静的 web サーバーはかなり前から利用されてきました。そのため、管理とセキュリティ管理のための様々なツールが用意されています。これらのツールは、ネットワークインフラストラクチャとよく統合されています。

コンテンツ管理サーバー content-management-servers

AEM などの CMS（コンテンツ管理サーバー）を使用する場合、訪問者からのリクエストは高度なレイアウトエンジンによって処理されます。このエンジンは、リポジトリからコンテンツを読み取り、スタイル、フォーマットおよびアクセス権を組み合わせて、コンテンツを訪問者のニーズや権限に合わせたドキュメントに変換します。

このワークフローによって、豊富で動的なコンテンツを作成でき、web サイトの柔軟性と機能性を高めることができます。ただし、レイアウトエンジンは静的サーバーより多くの処理能力が必要なので、レイアウトエンジンを設定すると、多くの訪問者がシステムを使用した場合に動作が遅くなる可能性があります。

Dispatcher によるキャッシュの実行方法 how-dispatcher-performs-caching

キャッシュディレクトリ：キャッシュ時、Dispatcher モジュールでは web サーバーの静的コンテンツ提供機能を使用します。キャッシュされたドキュメントは、Dispatcher によって web サーバーのルートに配置されます。

キャッシュの方法

Web サイトに変更があったとき、Dispatcher では主に 2 つの方法でキャッシュコンテンツを更新します。

コンテンツの更新

コンテンツの更新時に、1 つ以上の AEM ドキュメントが変更されます。AEM から Dispatcher にシンジケーションのリクエストが送信され、このリクエストに応じて次のようにキャッシュの更新が行われます。

次の点に注意してください。

自動無効化

自動無効化は、キャッシュのパーツを自動的に無効化するもので、ファイル自体の削除は行いません。コンテンツの更新ごとに statfile と呼ばれるファイルに touch するので、statfile のタイムスタンプは最終更新日を示します。

Dispatcher は、自動無効化の対象となるファイルのリストを保持しています。このリストにあるドキュメントが要求されると、Dispatcher はキャッシュされたドキュメントの日付と statfile のタイムスタンプを比較します。

この場合も、注意すべきポイントがいくつかあります。

Dispatcher がドキュメントを返す方法 how-dispatcher-returns-documents

ドキュメントがキャッシュの対象かどうかの判断

どのドキュメントを Dispatcher でキャッシュするかは設定ファイルで定義できます。Dispatcher は、要求とキャッシュ可能なドキュメントのリストを照合します。ドキュメントがこのリストにない場合は、AEM インスタンスにドキュメントを要求します。

以下の場合、Dispatcher は常に AEM インスタンスに直接ドキュメントを要求します。

ドキュメントがキャッシュされているかどうかの判断

Dispatcher はキャッシュされたファイルを、静的 Web サイトに含まれる場合と同様に、Web サーバー上に格納しています。ユーザーがキャッシュ可能なドキュメントを要求すると、Dispatcher はそのドキュメントが web サーバーのファイルシステムに存在するかどうかを確認します。

ドキュメントが最新かどうかの判断

ドキュメントが最新かどうかを判断するために、Dispatcher は次の 2 つの手順を実行します。

ロードバランシングのメリット the-benefits-of-load-balancing

ロードバランシングとは、Web サイトの計算負荷を AEM の複数のインスタンスに分散させることです。

以下のようなメリットがあります。

Dispatcher によるロードバランシングの実行方法 how-the-dispatcher-performs-load-balancing

パフォーマンスの統計

Dispatcher は、AEM の各インスタンスのドキュメント処理速度についての内部統計を保持しています。このデータに基づき、Dispatcher はリクエストに回答する際、応答時間が最も速いインスタンスを予測し、そのインスタンスで必要な計算時間を確保します。

リクエストのタイプによって平均完了時間も変わるので、Dispatcher ではドキュメントのカテゴリを指定できます。これらのカテゴリは、予測時間の計算時に考慮されます。例えば、HTML ページと画像とでは標準的な応答時間が異なることが多いので、この両者を区別することができます。

詳細な検索機能を使用する場合は、検索クエリのカテゴリを作成できます。この方法により、応答の最も速いインスタンスに検索クエリを送信できます。また、他のインスタンスが「低負荷」のリクストを受信している間に、低速のインスタンスがいくつかの「高負荷」の検索クエリを受信して、停止するのを防ぐのにも役立ちます。

個人設定されたコンテンツ（スティッキー接続）

スティッキー接続では、1 人のユーザーに対するドキュメントが、常に AEM の同じインスタンス上で構成されるようにします。この点は、パーソナライズされたページとセッションデータを使用する場合に重要です。データはインスタンスに格納されるので、以降の同じユーザーからの要求は、同じインスタンスに返す必要があります。

スティッキー接続では、Dispatcher でリクエストを最適化する機能が制限されるので、このアプローチはは必要な場合にのみ使用してください。「スティッキー」ドキュメントを保存するフォルダーは指定できるので、そのフォルダー内のすべてのドキュメントをユーザーごとに同じインスタンスに構成できます。

複数の Dispatcher の使用 using-multiple-dispatchers

複雑な設定を行う場合は、複数の Dispatcher を使用できます。例えば、次のように使用できます。

この場合、各要求が経由する Dispatcher は 1 つだけにしてください。別の Dispatcher から渡された要求は処理されません。したがって、どちらの Dispatcher も AEM web サイトに直接アクセスするようにしてください。

CDN での Dispatcher の使用 using-dispatcher-with-a-cdn

Akamai Edge Delivery または Amazon Cloud Front などのコンテンツ配信ネットワーク（CDN）は、エンドユーザーに近い場所からコンテンツを配信します。そのため、以下のことが可能です。

HTTP インフラストラクチャコンポーネントとして、CDN は Dispatcher と同様に機能します。CDN ノードがリクエストを受け取ると、可能な場合（リソースはキャッシュ内にあって有効な場合）はキャッシュからリクエストを提供します。それ以外の場合は、次に近いサーバーに問い合わせてリソースを取得し、適切であれば、今後のリクエストに備えてキャッシュします。

「次に最も近いサーバー」は、特定の設定に応じて異なります。例えば、Akamai の設定では、要求は次のパスをたどることができます。

通常、Dispatcher が次のサーバーとなり、キャッシュからドキュメントを提供し、CDN サーバーに返される応答ヘッダーに影響を与えます。

CDN キャッシュの制御 controlling-a-cdn-cache

CDN が Dispatcher から再取得するまでのリソースのキャッシュ期間を制御するには、いくつかの方法があります。

一般的な AEM 設定では、上記の 1 および 2 の方法で実行できる、拡張子別設定、パス別設定またはその両方の設定を使用して、適切なキャッシング期間を設定できます。これらのキャッシュ期間は、デザイン画像やクライアントライブラリなど、よく使用されるが頻繁には変更されないリソースを対象としています。新しいリリースがデプロイされると、一般的には手動での無効化が必要になります。

キャッシュで管理されているコンテンツに対してこの手法を使用した場合は、コンテンツの変更がエンドユーザーに表示されるのは、設定されているキャッシュ期間の有効期限が切れたときだけです。また、ドキュメントが Dispatcher から再度取得された場合も同様です。

よりきめ細かな制御を行うために、API ベースの無効化を使用して、Dispatcher のキャッシュが無効になったら CDN のキャッシュを無効化することができます。CDN の API に基づいて、独自の ContentBuilder と TransportHandler（API が REST ベースではない場合）を実装し、これらを使用して CDN のキャッシュを無効化するレプリケーションエージェントを設定できます。

オーサリングサーバーでの Dispatcher の使用 using-a-dispatcher-with-an-author-server

/rules
{
/0000
{ /type "deny" /glob "*"}
}

Dispatcher をオーサーインスタンスの前方で使用して、オーサリングのパフォーマンスを向上させることができます。オーサリング Dispatcher を設定するには、次の手順を実行します。