Dispatcher のバージョンは AEM とは無関係です。以前のバージョンの AEM のドキュメントに組み込まれている Dispatcher のドキュメントへのリンクをたどると、このページにリダイレクトされる可能性があります。
Dispatcher は、Adobe Experience Manager のキャッシュや負荷分散を利用するツールで、エンタープライズクラスの web サーバーと組み合わせて使用できます。
Dispatcher をデプロイするプロセスは、選択した Web サーバーや OS プラットフォームとは独立しています。
Dispatcher とAEMの連携の仕組みをより深く理解するには:
必要に応じて、次の情報を使用します。
Dispatcher の最も一般的な使用法は、AEM パブリッシュインスタンスからの応答をキャッシュして、外部に公開されている Web サイトの応答性とセキュリティを高めることです。したがって、大部分の説明ではこのケースを想定しています。
しかし、Dispatcher はオーサーインスタンスの応答性を高めるために使用することもできます。特に、多数のユーザーが Web サイトを編集および更新する場合には効果的です。このケースについて詳しくは、以下のオーサリングサーバーでの Dispatcher の使用を参照してください。
Web パブリッシングには、次の 2 つの基本的な手段があります。
Dispatcher によって、高速かつ動的な環境を実現できます。Dispatcher は、Apache のような静的 HTML サーバーの一部として機能し、以下の目的を達成します。
つまり、以下のようになります。
静的コンテンツを、静的 Web サーバーとまったく同様に、高速で簡単に操作できます。また、静的 Web サーバーで使用できる管理ツールおよびセキュリティツールを使用できます。
必要に応じて動的コンテンツを生成できます。このとき、システムの動作が必要以上に遅くなることはありません。
Dispatcher には、動的サイトのコンテンツに基づいて静的 HTML を生成および更新するメカニズムが含まれています。静的ファイルとして保存するドキュメントと、常に動的に生成するドキュメントを詳細に指定できます。
この節では、この機能の基本原理について説明します。
Apache や IIS などの静的 Web サーバーは、Web サイトの訪問者に静的 HTML ファイルを提供します。静的ページの作成は 1 回だけなので、要求ごとに同じコンテンツが配信されます。
このプロセスはごく単純なので、非常に効率的です。訪問者がファイル(HTML ページなど)を要求すると、ファイルは通常メモリから直接取得され、最悪の場合でもローカルドライブから読み取られます。静的 Web サーバーは長い間使用されてきたので、様々な管理およびセキュリティ管理ツールがあり、ネットワークのインフラストラクチャーにも適切に統合できます。
AEM などのコンテンツ管理サーバーを使用する場合、訪問者からの要求は高度なレイアウトエンジンによって処理されます。このエンジンは、リポジトリからコンテンツを読み取り、スタイル、フォーマットおよびアクセス権を組み合わせて、コンテンツを訪問者のニーズや権限に合わせたドキュメントに変換します。
このエンジンによって、豊富で動的なコンテンツを作成でき、Web サイトの柔軟性と機能性を高めることができます。ただし、レイアウトエンジンは静的サーバーより多くの処理能力が必要なので、レイアウトエンジンを設定すると、多くの訪問者がシステムを使用した場合に動作が遅くなる可能性があります。
キャッシュディレクトリ:キャッシュ時、Dispatcher モジュールでは Web サーバーの静的コンテンツ提供機能を使用します。キャッシュされたドキュメントは、Dispatcher によって Web サーバーのドキュメントルートに配置されます。
HTTP ヘッダーキャッシュの設定がない場合、Dispatcher は、ページの HTML コードのみを保存します。この場合、HTTP ヘッダーは保存されません。Web サイト内で異なるエンコーディングを使用している場合、これらの HTTP ヘッダーが失われる可能性があるので、このことが問題になる可能性があります。HTTP ヘッダーキャッシュを有効にするには、 Dispatcher キャッシュの設定
Web サーバーのドキュメントルートをネットワーク接続ストレージ(NAS)上に配置すると、パフォーマンスが低下します。また、NAS 上に配置されたドキュメントルートを複数の Web サーバーで共有すると、レプリケーションアクションの実行時に断続的なロックが発生することがあります。
Dispatcher は、キャッシュされたドキュメントを要求された URL と等しい構造に保存します。
URL に多数のセレクターが含まれる場合など、ファイル名の長さには OS レベルでの制限がある場合があります。
Web サイトに変更があったとき、Dispatcher では主に 2 つの方法でキャッシュコンテンツを更新します。
コンテンツの更新では、1 つまたは複数の AEM ドキュメントが変更されます。AEM から Dispatcher にシンジケーション要求が送信され、この要求に応じて次のようにキャッシュの更新がおこなわれます。
次のポイントに注意する必要があります。
自動無効化は、キャッシュのパーツを自動的に無効化するもので、ファイル自体の削除は行いません。コンテンツの更新ごとに statfile と呼ばれるファイルに touch するので、statfile のタイムスタンプは最終更新日を示します。
Dispatcher は、自動無効化の対象となるファイルのリストを保持しています。このリストにあるドキュメントが要求されると、Dispatcher はキャッシュされたドキュメントの日付と statfile のタイムスタンプを比較します。
この場合も、注意すべきポイントがいくつかあります。
以下が可能です。 設定ファイルで Dispatcher がキャッシュするドキュメントを定義する. Dispatcher は、要求とキャッシュ可能なドキュメントのリストを照合します。ドキュメントがこのリストにない場合は、AEM インスタンスにドキュメントを要求します。
以下の場合、Dispatcher は常に AEM インスタンスに直接ドキュメントを要求します。
(HTTP ヘッダー用の)GET または HEAD メソッドは、Dispatcher によってキャッシュ可能です。応答ヘッダーのキャッシュについて詳しくは、HTTP 応答ヘッダーのキャッシュセクションを参照してください。
Dispatcher はキャッシュされたファイルを、静的 Web サイトに含まれる場合と同様に、Web サーバー上に格納しています。ユーザーがキャッシュ可能なドキュメントを要求すると、Dispatcher はそのドキュメントが Web サーバーのファイルシステムに存在するかどうかをチェックします。
ドキュメントが最新かどうかを判断するために、Dispatcher は次の 2 つの手順を実行します。
自動無効化の対象でないドキュメントは、Web サイト上でコンテンツの更新などによって物理的に削除されるまでキャッシュに残ります。
ロードバランシングとは、Web サイトの計算負荷を AEM の複数のインスタンスに分散させることです。
以下のようなメリットがあります。
処理能力の向上ロードバランシングを実行すると、Dispatcher と AEM の複数のインスタンスでドキュメント要求が共有されます。各インスタンスで処理するドキュメントの数が少なくなるので、応答時間を短縮できます。Dispatcher はドキュメントカテゴリごとに内部統計を保持するので、負荷を予測してクエリを効率的に分散させることができます。
フェイルセーフ対象の拡大
インスタンスからの応答が受信されない場合、Dispatcher は自動的に要求を他のいずれかのインスタンスにリレーします。したがって、1 つのインスタンスが無効になった場合の影響は、計算能力の低下と比例してサイトの処理が遅くなることだけです。サービスはすべて続行します。
同じ静的 Web サーバー上で異なる Web サイトを管理することもできます。
ロードバランシングによって負荷を効率的に分散させる一方、キャッシュによって負荷を減らすことができます。したがって、ロードバランシングを設定する前に、キャッシュを最適化して全体の負荷を減らしてみてください。キャッシュを最適化することで、ロードバランサーのパフォーマンスを向上させたり、ロードバランシングを不要にしたりできます。
通常は、単一の Dispatcher だけで使用可能なパブリッシュインスタンスの容量を満たすことができますが、一部のアプリケーションでは、2 つの Dispatcher インスタンス間でもロードバランシングをおこなうとよい場合が稀にあります。Dispatcher を追加すると、使用可能なパブリッシュインスタンスの負荷が大きくなり、ほとんどのアプリケーションでパフォーマンスが低下しやすくなるので、複数の Dispatcher の設定は慎重に考慮する必要があります。
Dispatcher は、AEM の各インスタンスのドキュメント処理速度についての内部統計を保持しています。このデータに基づき、要求に対する応答時間が最も速いインスタンスを予測し、そのインスタンスで必要な計算時間をリザーブします。
要求のタイプによって完了までの時間の平均が変わるので、Dispatcher ではドキュメントのカテゴリを指定できます。指定したカテゴリは、予測時間の計算時に考慮されます。例えば、HTML ページと画像とでは標準的な応答時間が異なることが多いので、この両者を区別することができます。
詳細検索機能を使用する場合、検索クエリに新しいカテゴリを作成できます。カテゴリを使用すれば、応答の最も速いインスタンスに検索クエリを送信できます。これによって、複数の「高負荷」の検索クエリを受信した場合に、低速になったインスタンスが停止するのを防ぎつつ、他のインスタンスに「低負荷」の要求を渡します。
スティッキー接続によって、1 人のユーザーに対するドキュメントが、常に AEM の同じインスタンス上で構成されます。これは、パーソナライズされたページとセッションデータを使用する場合に重要です。データはインスタンスに格納されるので、以降の同じユーザーからの要求は、同じインスタンスに返す必要があります。
スティッキー接続をおこなうと、Dispatcher で要求を最適化する機能が制限されるので、スティッキー接続は必要な場合にのみ使用してください。「スティッキー」ドキュメントを保存するフォルダーは指定できるので、そのフォルダー内のすべてのドキュメントをユーザーごとに同じインスタンス上で構成できます。
スティッキー接続を使用するページでは、ほとんどの場合、キャッシュをオフにする必要があります。オフにしないと、セッション内容に関わらず、ページがすべてのユーザーに同じように表示されます。
一部のアプリケーションで、スティッキー接続とキャッシュの併用が可能な場合があります。例えば、セッションにデータを書き込むためのフォームを表示する場合です。
複雑な設定をおこなう場合は、複数の Dispatcher を使用できます。例えば、次のように使用できます。
この場合、各要求が経由する Dispatcher は 1 つだけにしてください。別の Dispatcher から渡された要求は処理されません。したがって、どちらの Dispatcher も AEM Web サイトに直接アクセスするようにしてください。
Akamai Edge Delivery または Amazon Cloud Front などのコンテンツ配信ネットワーク(CDN)は、エンドユーザーに近い場所からコンテンツを配信します。そのため、以下のことが可能です。
HTTP インフラストラクチャの構成要素として、CDN は Dispatcher とほとんど同じ働きをします。CDN ノードが要求を受信すると、可能であれば(リソースがキャッシュ内にあって有効な場合)、キャッシュから要求に応えます。それ以外の場合は、次に最も近いサーバーに問い合わせてリソースを取得し、適切であれば、今後の要求に備えてキャッシュします。
「次に最も近いサーバー」は、固有の設定によって異なります。例えば、Akamai の設定では、要求は次のパスをたどることができます。
ほとんどの場合は、Dispatcher が次のサーバーとなり、キャッシュからドキュメントを提供し、CDN サーバーに返される応答ヘッダーに影響を与えます。
CDN が Dispatcher からリソースを再取得するまでのキャッシュ期間を制御するには、様々な方法があります。
明確な設定
MIME タイプ、拡張子、要求タイプなどに応じて、特定のリソースを CDN のキャッシュに保持する期間を設定します。
有効期限およびキャッシュ制御ヘッダー
有効期限およびキャッシュ制御ヘッダー
ほとんどの CDN は、アップストリームサーバーによって送信される場合に、HTTP ヘッダー Expires:
および Cache-Control:
を保持します。これらのヘッダーは、Apache モジュール mod_expires を使用するなどの方法で保持できます。
手動での無効化
CDN では、Web インターフェイスを使用してリソースをキャッシュから削除できます。
API ベースの無効化
ほとんどの CDN には、リソースをキャッシュから削除できる REST または SOAP API も用意されています。
典型的な AEM 設定では、上記の 1 および 2 の方法で実行できる、拡張子やパス別の設定を使用して、デザイン画像やクライアントライブラリなど、頻繁には変更されず、よく使用されるリソースに対して妥当なキャッシュ期間を設定できます。新しいリリースがデプロイされると、一般的には手動での無効化が必要になります。
キャッシュで管理されているコンテンツに対してこの手法を使用した場合は、コンテンツの変更がエンドユーザーに表示されるのは、設定されているキャッシュ期間の有効期限が切れて、ドキュメントを再度 Dispatcher から取得したときだけです。
よりきめ細かな制御をおこなうために、API ベースの無効化を使用して、Dispatcher のキャッシュが無効になったら CDN のキャッシュを無効化することができます。CDN の API に基づいて、独自の ContentBuilder と TransportHandler(API が REST ベースではない場合)を実装し、これらを使用して CDN のキャッシュを無効化するレプリケーションエージェントを設定できます。
AEM(CQ)Dispatcher Security and CDN+Browser Caching および Dispatcher のキャッシュに関する録画済みのプレゼンテーションも参照してください。
を使用している場合は、 タッチ UI を使用したAEM 以下を実行します。 not オーサーインスタンスのコンテンツをキャッシュします。 オーサーインスタンスに対してキャッシュが有効になっている場合、それを無効にしてキャッシュディレクトリの内容を削除する必要があります。キャッシュを無効にするには、author_dispatcher.any
ファイルを編集し、/cache
セクションの /rule
プロパティを次のように変更します。
/rules
{
/0000
{ /type "deny" /glob "*"}
}
Dispatcher をオーサーインスタンスの前方で使用して、オーサリングのパフォーマンスを向上させることができます。オーサリング Dispatcher を設定するには、次の手順を実行します。
Web サーバー(Apache または IIS Web サーバー。Dispatcher のインストールを参照)に Dispatcher をインストールします。
新しくインストールした Dispatcher を動作中の AEM パブリッシュインスタンスに対してテストし、基礎となる正しいインストールが実行されたことを確認します。
今度は、Dispatcher が TCP/IP を使用してオーサーインスタンスに接続できることを確認します。
Dispatcher のサンプルの dispatcher.any ファイルを、Dispatcher ダウンロードで示されている author_dispatcher.any ファイルで置き換えます。
author_dispatcher.any
をテキストエディターで開き、以下の変更をおこないます。
/renders
セクションの /hostname
と /port
がオーサーインスタンスを指すように変更します。/docroot
セクションの /cache
がキャッシュディレクトリを指すように変更します。を使用している場合 タッチ UI を使用したAEMに設定する場合は、上記の警告を参照してください。上記で設定した /cache
//docroot
ディレクトリ内にあるすべての既存ファイルを削除します。
Web サーバーを再起動します。
示されている author_dispatcher.any
設定を使用して /libs
または /apps
の下のすべてのコンテンツに影響を与える CQ5 機能パック、ホットフィックスまたはアプリケーションコードパッケージをインストールする場合は、Dispatcher のキャッシュ内のこれらのディレクトリの下にキャッシュされているファイルを削除して、次回要求されたときに、キャッシュされている古いファイルではなく、新たにアップグレードされたファイルが取得されるようにする必要があります。
以前設定したオーサリング Dispatcher を使用し、Dispatcher のフラッシュエージェントを有効にしている場合は、以下を実行してください。