第 1 章 - Dispatcher の概念、パターン、アンチパターン

最終更新日： 2024年10月16日
  • 適用対象：
  • Experience Manager 6.4
  • Experience Manager 6.5

作成対象：

  • 初心者
  • 開発者

概要

この章では、Dispatcher の歴史と仕組みを簡単に紹介し、これが AEM 開発者のコンポーネントの設計方法にどのように影響するかについて説明します。

開発者がインフラストラクチャを重視すべき理由

Dispatcher は、ほぼすべての AEM インストールに不可欠な要素です。Dispatcher の設定方法とヒントやテクニックを説明するオンライン記事が多数あります。

しかし、これらの細かい情報は常に非常に技術的なレベルから始まります。自分のしたいことを既に把握できている前提で、それを実現する方法の詳細のみを説明しているのです。Dispatcher でできることとできないことに関して言えば、その​ 内容と理由 ​を説明している概念的なドキュメントは見つかりませんでした。

アンチパターン：付け足しとしての Dispatcher

このような基本情報の欠如は、数々の AEM プロジェクトで見てきた多数のアンチパターンにつながります。

  1. Dispatcher は Apache web サーバーにインストールされるので、その設定は「Unix の神様」のようなプロジェクトメンバーの仕事です。「下界の Java 開発者」は、それを気にかける必要はありません。

  2. Java 開発者は、自分のコードを確実に動作させる必要があります。Dispatcher は後からそれを魔法のように高速化します。Dispatcher は常に付け足しです。ただし、これでは使えません。開発者は、Dispatcher を念頭に置いてコードを設計し、。 そのための基本的な概念を理解しておく必要があります。

「まず動くようにしてから高速化する」が常に正しいとは限らない

プログラミングに関し、「まず動くようにしてから高速化する」。 ​といったアドバイスを耳にしたことがある方もいるでしょう。完全に間違っているわけではありません。ただし、コンテキストが正しくないと、誤って解釈され、正しく適用されない傾向があります。

このアドバイスを受けて、開発者は、これは、実行されない、またはほとんど実行されないコードを早めに最適化しないようにする必要があります。ので、最適化にかかった労力を正当化するための十分な影響が、最適化によって得られないためです。さらに、最適化によって、コードがより複雑になり、バグを引き起こす可能性があります。したがって、開発者の方は、コードの各行を細かく最適化することに時間をかけすぎないでください。適切なデータ構造、アルゴリズム、ライブラリを選択し、プロファイラーによるホットスポット分析を待ち、より綿密な最適化が全体的なパフォーマンスを向上させる場所を確認するだけです。

アーキテクチャの決定とアーティファクト

しかし、「アーキテクチャの」決定に関しては、「まず動作させて、そして高速化する」というアドバイスは完全に間違っています。アーキテクチャの決定とは何ですか？簡単に言えば、コストがかかり、難しく、後で変更できない決定です。「コストがかかる」イコール「不可能」、となることもあります。例えば、プロジェクトの予算が足りなくなった場合、コストがかかる変更は実装できません。インフラの変更は、ほとんどの人が頭に思い浮かべる、そのカテゴリの最初の変化です。しかし、非常に変更が面倒な、別の種類の「アーキテクチャの」アーティファクトもあります。

  1. アプリケーションの「中央」にあり、他の多くの部分が依存するコードです。これらを変更するには、すべての依存関係を一度に変更し、再テストする必要があります。

  2. アーティファクトは、非同期の、タイミングに左右されるシナリオに関係し、入力や、システム動作は非常にランダムに変化する可能性があります。変更は予測できない影響を及ぼし、テストが困難になる場合があります。

  3. システムのあらゆる部分で使用され、何度も繰り返し使用されるソフトウェアパターン。ソフトウェアパターンが最適でないと判断された場合は、そのパターンを使用するすべてのアーティファクトのコーディングをしなおす必要があります。

次のことに留意してください。このページのトップで、Dispatcher は AEM アプリケーションの重要な部分であると述べました。Web アプリケーションへのアクセスは非常にランダムです。ユーザーは予測不可能な時間にアクセスします。最後に、すべてのコンテンツが Dispatcher にキャッシュされます（または必要です）。細心の注意を払っていた方であれば、キャッシュは「アーキテクチャの」アーティファクトと見なされ、開発者、管理者などのチームの全メンバーが同様に理解する必要があるとお気づきでしょう。

開発者が実際に Dispatcher を設定する必要があると言っているわけではありません。また、Dispatcher でコードを活用できるように、ユーザーは概念（特に境界）を把握しておく必要があります。

Dispatcher は、コーディングの速度を魔法のように向上させるものではありません。開発者は、Dispatcher を考慮してコンポーネントを作成する必要があります。したがって、開発者はその仕組みを知っておく必要があります。

Dispatcher のキャッシュ - 基本原則

Http のキャッシュとしての Dispatcher - ロードバランサー

Dispatcher とは何ですか？まず、なぜ「Dispatcher」と呼ばれるのですか？

Dispatcher では、

  • 最初にキャッシュが表示されます。

  • リバースプロキシ

  • Apache https Web サーバー用のモジュールで、Apache の汎用性に AEM 関連の機能を追加し、他のすべての Apache モジュールとスムーズに連携します（後で説明するように、SSL や SSI などを含みます）。

Web の初期の頃は、サイトの訪問者数は数百人になると予想されていました。1 つの Dispatcher を「ディスパッチ」するか、複数の AEM パブリッシュサーバーに対するリクエストの負荷を分散させる設定で、通常はこれで十分でした。これが、「Dispatcher」の名前の由来です。しかし、今では、この設定はあまり頻繁には使用されていません。

この記事の後半で、Dispatcher とパブリッシュシステムを設定するさまざまな方法について説明します。まず、http キャッシュの基本を紹介します。

Dispatcher キャッシュの基本機能

Dispatcher キャッシュの基本機能

Dispatcher の基本について、ここで説明します。Dispatcher は、HTTP リクエストを受信および作成できる、単純なキャッシュリバースプロキシです。通常のリクエストおよびレスポンスのサイクルは次のようになります。

  1. ユーザーがページをリクエストします。
  2. Dispatcher は、そのページのレンダリングされたバージョンが既に存在する場合にチェックします。これがこのページに対する最初のリクエストであり、Dispatcher がキャッシュされたローカルコピーを見つけられないと仮定します。
  3. Dispatcher がパブリッシュシステムにページをリクエストします。
  4. パブリッシュシステムで、ページが JSP または HTL テンプレートでレンダリングされます。
  5. ページが Dispatcher に返されます。
  6. Dispatcher がページをキャッシュします。
  7. Dispatcher がページをブラウザーに返します。
  8. 同じページが 2 回目に要求された場合、パブリッシュインスタンスで再レンダリングしなくても、Dispatcher キャッシュから直接提供できます。これにより、ユーザーの待ち時間を短縮し、パブリッシュインスタンスでの CPU サイクルを節約できます。

最後の節では「ページ」の話をしました。しかし、同じスキームは、画像、CSS ファイル、PDF ダウンロードなど、他のリソースにも当てはまります。

データのキャッシュ方法

Dispatcher モジュールは、ホスト側の Apache サーバーが提供する機能を利用します。HTML ページ、ダウンロード、画像などのリソースは、単純なファイルとして Apache ファイルシステムに保存されます。非常にシンプルです。

ファイル名は、要求されたリソースの URL に基づいて生成されます。ファイル /foo/bar.html をリクエストすると、/var/cache/docroot/foo/bar.html などに格納されます。

原則として、すべてのファイルがキャッシュされ、Dispatcher で静的に保存される場合は、Publish システムのプラグを取り込むと、Dispatcher は単純な web サーバーとして機能します。しかし、これは原理を説明することが目的です。現実はより複雑です。すべてをキャッシュすることはできません。また、レンダリングプロセスの動的性質により、リソースの数が無限になる可能性があるので、キャッシュが完全に「いっぱい」になることはありません。静的ファイルシステムのモデルは、Dispatcher の機能の概要を生成するのに役立ちます。また、Dispatcher の制限事項についても説明します。

AEM URL 構造とファイルシステムマッピング

Dispatcher について詳しく理解するために、単純なサンプル URL の構造を再度参照してみましょう。次の例を見てみましょう。

http://domain.com/path/to/resource/pagename.selectors.html/path/suffix.ext?parameter=value&otherparameter=value#fragment

  • http はプロトコルを示します。

  • domain.com はドメイン名です。

  • path/to/resource は、リソースが CRX に保存され、その後 Apache サーバーのファイルシステムに保存されるパスです。

ここからは、AEM ファイルシステムと Apache ファイルシステムでは少し異なります。

AEM では、次のようになります。

  • pagename はリソースラベルです。

  • selectors は、リソースのレンダリング方法を決定するために Sling で使用される多数のセレクターを表します。1 つの URL に任意の数のセレクターを含めることができます。区切り文字はピリオドです。セレクターセクションは、例えば、「french.mobile.fancy」のようになります。セレクターには、文字、数字、ダッシュのみを含める必要があります。

  • 「セレクター」の最後の html は、拡張子と呼ばれます。AEM/Sling では、レンダリングスクリプトも部分的に決定します。

  • path/suffix.ext は、URL のサフィックスを指定できるパスに似た式です。リソースのレンダリング方法をさらに制御するために、AEM スクリプトで使用できます。この部分については後の節で説明します。現時点では、追加のパラメーターとして使用できることを知っていれば十分です。サフィックスには拡張子が必要です。

  • ?parameter=value&otherparameter=value は、URL のクエリセクションです。任意のパラメーターを AEM に渡すために使用されます。パラメーターを持つ URL はキャッシュできないので、パラメーターは、絶対に必要な場合に限定する必要があります。

  • #fragment URL のフラグメント部分は AEM には渡されず、ブラウザーでのみ使用されます。JavaScript フレームワークで「ルーティングパラメーター」として使用するか、ページ上の特定の部分にジャンプします。

Apache（以下の図を参照）では、

  • pagename.selectors.html は、キャッシュのファイルシステムでファイル名として使用されます。

URL にサフィックス path/suffix.ext が付いている場合、

  • pagename.selectors.html はフォルダーとして作成されます

  • path は pagename.selectors.html フォルダー内のフォルダーです。

  • suffix.ext は path フォルダー内のファイルです。メモ：サフィックスに拡張子がない場合、ファイルはキャッシュされません。

Dispatcher から URL を取得した後のファイルシステムのレイアウト

Dispatcher から URL を取得した後のファイルシステムのレイアウト

基本的な制限事項

URL、リソース、ファイル名のマッピングは非常に簡単です。

ただし、お気づきかもしれませんが、いくつかの罠があります。

  1. URL が非常に長くなる場合があります。ローカルファイルシステム上で /docroot の「パス」部分を追加すると、一部のファイルシステムの制限を簡単に超えてしまう可能性があります。Windows 上の NTFS で Dispatcher を実行することは、困難な作業になる場合があります。Linux では安全です。

  2. URL には、特殊文字やウムラウトを含めることができます。これは、通常、Dispatcher で問題にはなりません。ただし、URL はアプリケーションの様々な場所で解釈されることに留意してください。アプリケーションの奇妙な動作について調べた結果、ごくまれに使用される（カスタム）コードの一部で、特殊文字に対するテストが十分に行われていなかったと判明するケースがしばしば見られます。できれば特殊文字の使用を避けてください。避けられない場合は、徹底的なテストを計画してください。

  3. CRX では、リソースにはサブリソースが含まれます。例えば、あるページに多数のサブページが含まれるとします。これを 1 つのファイルシステム内で一致させることはできません。ファイルシステムには、ファイルまたはフォルダーのいずれかが含まれるからです。

拡張子のない URL はキャッシュされない

URL には常に拡張子が必要です。AEM では拡張子のない URL を提供できますが、。 このような URL は Dispatcher でキャッシュされません。

例

http://domain.com/home.html は​ キャッシュ可能

http://domain.com/home は​ キャッシュ不可能

URL にサフィックスが含まれている場合も、同じルールが適用されます。キャッシュ可能なサフィックスには拡張子が必要です。

例

http://domain.com/home.html/path/suffix.html は​ キャッシュ可能

http://domain.com/home.html/path/suffix は​ キャッシュ不可能

リソース部分に拡張子がなく、サフィックスに拡張子がある場合はどうでしょうか。この場合、URL にサフィックスはありません。次の例を見てみましょう。

例

http://domain.com/home/path/suffix.ext

/home/path/suffix はリソースへのパスなので、URL にサフィックスはありません。

まとめ

常に、パスとサフィックスの両方に拡張子を追加します。SEO に詳しい人たちは、これが検索結果でのランクを下げていると主張することがあります。しかし、キャッシュされていないページは非常に遅くなり、さらに低いランクになります。

競合するサフィックス URL

2 つの有効な URL があるとします。

http://domain.com/home.html

および

http://domain.com/home.html/suffix.html

これらは、AEM では間違いなく有効です。（Dispatcher なしの）ローカル開発マシンでは、問題は発生しません。ほとんどの場合、UAT や負荷テストでも問題が発生することはありません。AEM で発生する問題は非常に微妙で、ほとんどのテストをすり抜けてしまいます。これらは、ピーク時になって、その問題に対処する時間が限られていて、おそらくサーバーへのアクセス権も、修正するためのリソースもないようなときに、大きな問題となります。私たちはこのような状況を経験してきました。

では、何が問題なのでしょうか。

ファイルシステムの home.html には、ファイルまたはフォルダーのどちらかを指定できます。AEM のように、両方を同時に指定することはできません。

最初に home.html をリクエストした場合、それはファイルとして作成されます。

その後の home.html/suffix.html へのリクエストでは有効な結果が返されますが、ファイル home.html がファイルシステム内の位置を「ブロック」しているので、home.html は 2 回目はフォルダーとして作成できず、home.html/suffix.html はキャッシュされません。

ファイルシステム内のファイルブロック位置により、サブリソースがキャッシュされない

ファイルシステム内のファイルブロック位置により、サブリソースがキャッシュされない

逆に、最初に home.html/suffix.html をリクエストすると、suffix.html はまずフォルダー /home.html にキャッシュされます。しかし、その後 home.html をリソースとしてリクエストすると、このフォルダーは削除され、ファイル home.html に置き換えられます。

親がリソースとして取得されたときにパス構造を削除する

親がリソースとして取得されたときにパス構造を削除する

したがって、キャッシュされる結果は完全にランダムで、受け取るリクエストの順序に応じて異なります。さらに難しいのは、通常は Dispatcher が複数あるということです。また、パフォーマンス、キャッシュのヒット率および動作は、Dispatcher によって異なる場合があります。Web サイトが応答しない理由を調べたい場合は、キャッシュ順序に問題があるが、正しい Dispatcher をチェックするようにしてください。もし、調べている Dispatcher が適切なリクエストパターンを使用したものであった場合、問題の特定に行き詰まるでしょう。