Dispatcher の概要

Dispatcher は、Adobe Experience Manager のキャッシュや負荷分散を利用するツールで、エンタープライズクラスの web サーバーと組み合わせて使用できます。

Dispatcher をデプロイするプロセスは、選択した Web サーバーや OS プラットフォームとは独立しています。

1. Dispatcher について学習します（このページ）。Dispatcher に関するよくある質問も参照してください。
2. のインストール サポート対象の web サーバー web サーバーのドキュメントに従って。
3. Web サーバーに Dispatcher モジュールをインストールし、このモジュールに合わせて Web サーバーを設定します。
4. Dispatcher を設定します（dispatcher.any ファイル）。
5. コンテンツの更新によってキャッシュが無効化されるように AEM を設定します。

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

• Dispatcher のセキュリティチェックリスト
• Dispatcher のナレッジベース
• Web サイトのキャッシュパフォーマンスの最適化
• 複数ドメインでの Dispatcher の使用
• Dispatcher での SSL の使用
• 権限に影響を受けるキャッシュの実装
• Dispatcher に関する問題のトラブルシューティング
• Dispatcher に関する主な問題とよくある質問

Dispatcher を使用してキャッシュを実装する理由

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

• 静的 Web サーバー：Apache や IIS など、非常にシンプルですが処理の速い Web サーバーです。
• コンテンツ管理サーバー：動的で、リアルタイムの、インテリジェントなコンテンツですが、必要とする計算時間などのリソースがはるかに多くなります。

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

• できるだけ多くのサイトコンテンツを、静的 Web サイトの形式で格納（キャッシュ）します。
• レイアウトエンジンへのアクセスをできるだけ少なくします。

つまり、以下のようになります。

• 静的コンテンツ​を、静的 Web サーバーとまったく同様に、高速で簡単に操作できます。また、静的 Web サーバーで使用できる管理ツールおよびセキュリティツールを使用できます。

• 必要に応じて​動的コンテンツ​を生成できます。このとき、システムの動作が必要以上に遅くなることはありません。

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

この節では、この機能の基本原理について説明します。

静的 Web サーバー

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

このプロセスはごく単純なので、非常に効率的です。訪問者がファイル（HTML ページなど）を要求すると、ファイルは通常メモリから直接取得され、最悪の場合でもローカルドライブから読み取られます。静的 Web サーバーは長い間使用されてきたので、様々な管理およびセキュリティ管理ツールがあり、ネットワークのインフラストラクチャーにも適切に統合できます。

コンテンツ管理サーバー

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

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

Dispatcher によるキャッシュの実行方法

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

キャッシュの方法

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

• コンテンツの更新​によって、変更されたページ、およびそのページに直接関連付けられたファイルを削除します。
• 自動無効化​によって、キャッシュで変更があった部分を自動的に無効化し、更新後に期限切れとします。つまり、関連するページに期限切れのフラグを付けるだけで、削除はおこないません。

コンテンツの更新

コンテンツの更新では、1 つまたは複数の AEM ドキュメントが変更されます。AEM から Dispatcher にシンジケーション要求が送信され、この要求に応じて次のようにキャッシュの更新がおこなわれます。

1. 変更されたファイルを、キャッシュから削除します。
2. 同じハンドルで始まるすべてのファイルを、キャッシュから削除します。たとえば、ファイル /jp/index.html が更新された場合、/jp/index で始まるすべてのファイルは削除されます。このメカニズムによって、特に画像ナビゲーションに関して、キャッシュを効率的に使用するサイトをデザインできます。
3. statfile と呼ばれるファイルに touch します。touchすると、statfile のタイムスタンプが最終変更日に更新されます。

次のポイントに注意する必要があります。

• コンテンツの更新は、通常、置き換える必要のあるコンテンツを「把握している」作成システムと組み合わせて使用します。
• コンテンツの更新が適用されたファイルは削除されますが、すぐに置き換えられるわけではありません。このファイルが次回要求されたとき、Dispatcher は AEM インスタンスから新しいファイルを取得し、キャッシュに配置します。これで、古いコンテンツを上書きしたことになります。
• 通常、ページのテキストを取り込んで自動生成された画像は、同じハンドルで始まる画像ファイルに格納されます。したがって、ページと画像ファイルは関連があり、削除の対象となります。例えば、mypage.html というページのタイトルテキストを、mypage.titlePicture.gif ファイルとして同じフォルダーに格納できます。したがって、ページの更新ごとにキャッシュにある画像が自動的に削除されるので、画像のバージョンを常にページの現在のバージョンと合わせることができます。
• statfile は複数持つことができます。例えば、言語フォルダーごとに 1 つずつ持つことができます。ページが更新されると、AEM は statfile を含む次の親フォルダーを探し、そのファイルに touch します。

自動無効化

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

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

• キャッシュされたドキュメントのほうが新しい場合、そのドキュメントを返します。
• キャッシュされたドキュメントのほうが古い場合、Dispatcher は AEM インスタンスから現在のバージョンを取得します。

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

• 自動無効化は通常、HTML ページなど内部関係が複雑な場合に使用します。このようなページには、リンクやナビゲーションエントリが含まれるので、通常はコンテンツの更新後にこれらのリンクなどを更新する必要があります。自動生成される PDF や画像ファイルがある場合も、これらのファイルに対して自動無効化を選択できます。
• 自動無効化の機能は、statfile に touch する以外は、更新時の Dispatcher の動作に関与しません。ただし、statfile への touch によって、キャッシュコンテンツは自動的に古いものとされます。キャッシュ自体は削除されません。

Dispatcher がドキュメントを返す方法

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

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

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

• 要求 URI に疑問符（「?」）が含まれている場合。疑問符は通常、キャッシュの必要がない、検索結果などの動的ページを指します。
• ファイル拡張子が不明の場合。Web サーバーでドキュメントのタイプ（MIME タイプ）を判別するために、拡張子が必要です。
• 認証ヘッダー（設定可）が設定されている場合。

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

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

• ドキュメントがキャッシュされている場合、Dispatcher はキャッシュされているファイルを返します。
• ドキュメントがキャッシュされていない場合、Dispatcher は AEM インスタンスにドキュメントを要求します。

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

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

1. ドキュメントが自動無効化の対象であるかどうかチェックします。対象でない場合、ドキュメントは最新であると認識されます。
2. ドキュメントが自動無効化の対象として設定されている場合、Dispatcher は最新の変更情報と比べてドキュメントが古いかどうかチェックします。ドキュメントが古い場合、Dispatcher は AEM インスタンスに最新バージョンを要求し、キャッシュ内のバージョンを置き換えます。

ロードバランシングのメリット

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

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

• 処理能力の向上​ロードバランシングを実行すると、Dispatcher と AEM の複数のインスタンスでドキュメント要求が共有されます。各インスタンスで処理するドキュメントの数が少なくなるので、応答時間を短縮できます。Dispatcher はドキュメントカテゴリごとに内部統計を保持するので、負荷を予測してクエリを効率的に分散させることができます。

• フェイルセーフ対象の拡大
  インスタンスからの応答が受信されない場合、Dispatcher は自動的に要求を他のいずれかのインスタンスにリレーします。したがって、1 つのインスタンスが無効になった場合の影響は、計算能力の低下と比例してサイトの処理が遅くなることだけです。サービスはすべて続行します。

• 同じ静的 Web サーバー上で異なる Web サイトを管理することもできます。

Dispatcher によるロードバランシングの実行方法

パフォーマンスの統計

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

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

詳細検索機能を使用する場合、検索クエリに新しいカテゴリを作成できます。カテゴリを使用すれば、応答の最も速いインスタンスに検索クエリを送信できます。これによって、複数の「高負荷」の検索クエリを受信した場合に、低速になったインスタンスが停止するのを防ぎつつ、他のインスタンスに「低負荷」の要求を渡します。

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

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

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

複数の Dispatcher の使用

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

• 1 つ目の Dispatcher を、イントラネット上での Web サイトの公開に使用
• 2 つ目の Dispatcher を、異なるアドレスと異なるセキュリティ設定で、インターネット上での同じコンテンツの公開に使用

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

CDN での Dispatcher の使用

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

• エンドユーザーに対する応答時間をスピードアップする
• サーバーから負荷を取り除く

HTTP インフラストラクチャの構成要素として、CDN は Dispatcher とほとんど同じ働きをします。CDN ノードが要求を受信すると、可能であれば（リソースがキャッシュ内にあって有効な場合）、キャッシュから要求に応えます。それ以外の場合は、次に最も近いサーバーに問い合わせてリソースを取得し、適切であれば、今後の要求に備えてキャッシュします。

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

• Akamai Edge Node
• Akamai Midgres Layer
• ファイアウォール
• ロードバランサー
• Dispatcher
• AEM

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

CDN キャッシュの制御

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

1. 明確な設定
   MIME タイプ、拡張子、要求タイプなどに応じて、特定のリソースを CDN のキャッシュに保持する期間を設定します。

2. 有効期限およびキャッシュ制御ヘッダー
   有効期限およびキャッシュ制御ヘッダー
   ほとんどの CDN は、アップストリームサーバーによって送信される場合に、HTTP ヘッダー Expires: および Cache-Control: を保持します。これらのヘッダーは、Apache モジュール mod_expires を使用するなどの方法で保持できます。

3. 手動での無効化
   CDN では、Web インターフェイスを使用してリソースをキャッシュから削除できます。

4. API ベースの無効化
   ほとんどの CDN には、リソースをキャッシュから削除できる REST または SOAP API も用意されています。

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

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

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

オーサリングサーバーでの Dispatcher の使用

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

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

1. Web サーバー（Apache または IIS Web サーバー。Dispatcher のインストールを参照）に Dispatcher をインストールします。

2. 新しくインストールした Dispatcher を動作中の AEM パブリッシュインスタンスに対してテストし、基礎となる正しいインストールが実行されたことを確認します。

3. 今度は、Dispatcher が TCP/IP を使用してオーサーインスタンスに接続できることを確認します。

4. Dispatcher のサンプルの dispatcher.any ファイルを、Dispatcher ダウンロードで示されている author_dispatcher.any ファイルで置き換えます。

5. author_dispatcher.any をテキストエディターで開き、以下の変更をおこないます。

   1. /renders セクションの /hostname と /port がオーサーインスタンスを指すように変更します。
   2. /docroot セクションの /cache がキャッシュディレクトリを指すように変更します。を使用している場合 タッチ UI を使用したAEMに設定する場合は、上記の警告を参照してください。
   3. 変更内容を保存します。

6. 上記で設定した /cache／/docroot ディレクトリ内にあるすべての既存ファイルを削除します。

7. Web サーバーを再起動します。

1. AEM オーサーインスタンス上の​オーサリング Dispatcher のフラッシュエージェントを削除または無効にします。
2. 上記の新しい説明に従って、オーサリング Dispatcher の設定をやり直します。