AdobeManaged Services Dispatcher のフラッシュ

説明 description

環境
Experience Manager

問題/症状
このドキュメントでは、フラッシュの発生方法に関するガイダンスを提供し、キャッシュのフラッシュと無効化を実行するメカニズムについて説明します。

仕組み
操作の順序

一般的なワークフローは、コンテンツ作成者がページをアクティベートする際に最適です。パブリッシャーは、新しいコンテンツを受け取る際に、次の図に示すように、Dispatcher に対してフラッシュリクエストをトリガーします。

この一連のイベントは、新規または変更されたアイテムのみをフラッシュすることを強調します。  これにより、変更がパブリッシャーから取得される前にフラッシュが発生する競合状態を避けるために、キャッシュをクリアする前にパブリッシャーがコンテンツを受け取るようになります。

レプリケーションエージェント

オーサー環境には、何かがアクティブ化されると、そのファイルとそのすべての依存関係をパブリッシャーに送信するトリガーが発行者を指すように設定されたレプリケーションエージェントがあります。

パブリッシャーはファイルを受け取ると、受信時イベントにトリガーを置くように Dispatcher を指すように設定されたレプリケーションエージェントを持ちます。  次に、フラッシュリクエストがシリアル化され、Dispatcher に送信されます。

オーサーレプリケーションエージェント

次に、設定済みの標準レプリケーションエージェントのスクリーンショットの例を示します

通常、作成者に対して、コンテンツのレプリケート先のパブリッシャーごとに 1 つまたは 2 つのレプリケーションエージェントが設定されます。

1 つ目は、コンテンツのアクティベーションをプッシュする標準レプリケーションエージェントです。

2 つ目はリバースエージェントです。  これはオプションで、各パブリッシャーのアウトボックスで、リバースレプリケーションアクティビティとしてオーサーに取り込む新しいコンテンツがあるかどうかを確認するために設定されます

パブリッシャーレプリケーションエージェント

次に、設定済みの標準フラッシュレプリケーションエージェントのスクリーンショットの例を示します

仮想ホストを受け取る DISPATCHER フラッシュレプリケーション

Dispatcher モジュールは、特定のヘッダーを探して、POSTリクエストがAEMレンダーに渡すものか、またはフラッシュリクエストとしてシリアル化され、Dispatcher ハンドラー自体で処理する必要があるかを知ります。  次に、これらの値を示す設定ページのスクリーンショットを示します。

デフォルト設定ページには、  シリアル化の種類  as  Dispatcher フラッシュ  エラーレベルを設定します。

トランスポートタブでは、フラッシュリクエストを受信する Dispatcher の IP アドレスを示すように URI が設定されているのがわかります。  パス/dispatcher/invalidate.cacheは、モジュールがフラッシュであるかどうかを判別する方法ではありません。フラッシュリクエストであることを知るために、アクセスログに表示される明白なエンドポイントに過ぎません。  「拡張」タブで、Dispatcher モジュールに対するフラッシュリクエストであると見なすために、存在する項目を調べます。

フラッシュリクエストの HTTP メソッドは、次に示す特別なリクエストヘッダーを持つGETリクエストに過ぎません。

「トリガー」タブで、使用する切り替え済みのトリガーと、その内容をメモします。

次に、一般的なフラッシュリクエストが curl コマンドの形式でどのように表示されるかを見てみましょう

このフラッシュの例では、/content/dam パスをフラッシュして、そのディレクトリ内の.stat ファイルを更新します。

.stat ファイル

フラッシュメカニズムは本質的にシンプルで、  .stat  キャッシュファイルが作成されるドキュメントルートに生成されるファイル。

.vhost ファイルと_farm.any ファイル内で、ドキュメントルートディレクティブを設定して、キャッシュの場所と、エンドユーザーからの要求が来たときのファイルの保存場所/提供場所を指定します。

Dispatcher サーバーで次のコマンドを実行する場合は、.stat ファイルの検索を開始します。

キャッシュに項目があり、Dispatcher モジュールによってフラッシュリクエストが送信されて処理された場合、このファイル構造はどのように見えるかを図で示します

STAT ファイルのレベル

各ディレクトリには.stat ファイルが存在することに注意してください。これは、フラッシュが発生したことを示すインジケーターです。  上記の例では、  statfilelevel  設定が次のように設定されています：  3  対応するファーム設定ファイル内にあります。

statfilelevel 設定は、モジュールが.stat ファイルをトラバースして更新するフォルダーの深さを示します。  .stat ファイルが空の場合は、データスタンプを含むファイル名に過ぎず、手動で作成することもできますが、Dispatcher サーバーのコマンドラインで touch コマンドを実行します。

stat ファイルレベルの設定が高すぎると、各フラッシュリクエストが stat ファイルにタッチしているディレクトリツリーをトラバースします。  これは、大きなキャッシュツリーで大きなパフォーマンスヒットになる可能性があり、Dispatcher の全体的なパフォーマンスに影響を与える可能性があります。

このファイルレベルの設定が低すぎると、フラッシュリクエストが意図した以上にクリアされる可能性があります。これにより、キャッシュから提供されるリクエストが少なくなり、キャッシュがより頻繁にチャーンし、パフォーマンスの問題が発生する可能性があります。

メモ：

statfilelevel を適切なレベルに設定します。フォルダー構造を見て、多くのディレクトリをトラバースする必要がなく、簡潔なフラッシュができるように設定されていることを確認します。システムのパフォーマンステスト中にテストして、ニーズに合っていることを確認します。

言語をサポートしているサイトが良い例です。一般的なコンテンツツリーには、次のディレクトリがあります。

/content/brand1/en/us/

この例では、stat ファイルレベル設定の 4 を使用します。  これにより、  us  フォルダー内の言語フォルダーもフラッシュされません。

STAT ファイルのタイムスタンプハンドシェイク

コンテンツのリクエストが同じルーチンで発生した場合

キャッシュハンドシェイク — 例 1

上記の例では、コンテンツ/content/index.htmlのリクエストを実行します。

index.html ファイルの時刻は2019-11-01 @ 6:21PM です。

最も近い.stat ファイルの時刻は2019-11-01 @ 12:22PM です。

上記の内容を理解すると、インデックスファイルが.stat ファイルより新しく、要求したエンドユーザーにキャッシュから提供されることがわかります。

キャッシュハンドシェイク — 例 2

上記の例では、コンテンツ/content/dam/logo.jpgのリクエストを実行します。

logo.jpg ファイルの時刻は2019-10-31 @ 1:13PM です。

最も近い.stat ファイルの時刻は2019-11-01 @ 12:22PM です。

この例に示すように、ファイルは.stat ファイルより古く、削除され、AEMから新しく取り出されてキャッシュ内に置き換えられ、要求したエンドユーザーに提供されます。

ファームファイル設定

設定オプションの完全なセットについては、ドキュメントを参照してください。 https://docs.adobe.com/content/help/ja-JP/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#configuring-dispatcher_configuring-the-dispatcher-cache-cache

キャッシュのフラッシュに関係する、いくつかの要素を強調したいと思います

ドキュメントルート

この設定エントリは、ファームファイルの次のセクションにあります。

Dispatcher を設定し、キャッシュディレクトリとして管理するディレクトリを指定します。

メモ：

このディレクトリは、Web サーバーが使用するように設定されているドメインの Apache ドキュメントのルート設定と一致する必要があります。

Apache ドキュメントルートのサブフォルダーにある各ファームごとにネストされた docroot フォルダーを持つことは、多くの理由で非常に困難な考えです。

Stat Files Level

この設定エントリは、ファームファイルの次のセクションにあります。

この設定は、フラッシュリクエストが発生したときに.stat ファイルを生成する必要がある深さを測定します。

/statfileslevel が次の番号に設定され、ドキュメントのルートが/var/www/html/の場合、/content/dam/brand1/en/us/logo.jpgをフラッシュすると次の結果が得られます。

メモ：

タイムスタンプのハンドシェイクが発生すると、最も近い.stat ファイルが検索されることに注意してください。

.stat ファイルのレベルが 0 で、stat ファイルが/var/www/html/.stat にある場合は、/var/www/html/content/dam/brand1/en/us/の下にあるコンテンツは、最も近い.stat ファイルを探し、5 つ上のフォルダを探して、レベル 0 に存在する唯一の.stat ファイルを見つけ、それと日付を比較します。つまり、この高いレベルで 1 回フラッシュすると、キャッシュされたすべてのアイテムが基本的に無効化されます。

無効化を許可

この設定エントリは、ファームファイルの次のセクションにあります。

この設定内に、フラッシュリクエストを送信できる IP アドレスのリストを配置します。  フラッシュ要求が Dispatcher に含まれる場合、信頼された IP からの要求が必要です。  この誤った設定が行われているか、信頼されていない IP アドレスからフラッシュリクエストを送信した場合は、ログファイルに次のエラーが表示されます。

無効化ルール

この設定エントリは、ファームファイルの次のセクションにあります。

これらのルールは通常、フラッシュリクエストで無効化できるファイルを示します。

ページのアクティベーションによって重要なファイルが無効化されるのを防ぐために、無効化できるファイルと手動で無効化する必要のあるファイルを指定するルールを適用できます。  次に、html ファイルの無効化のみを許可する設定のサンプルセットを示します。

解決策 resolution

テスト/トラブルシューティング

ページをアクティベートし、ページのアクティベートが成功したことを示す緑色の光が表示されたら、アクティベートしたコンテンツがキャッシュからもフラッシュされます。

ページを更新すると、古いものが表示され、緑の光が点灯します。

フラッシュプロセスを手動でいくつか実行し、何が間違っているのかを確認してみましょう。パブリッシャーのシェルから、curl を使用して次のフラッシュリクエストを実行します。

テストフラッシュリクエストの例

Dispatcher に対するリクエストコマンドを実行したら、ログでの処理と.stat ファイルでの処理を確認します。  ログファイルの末尾に、次のエントリが表示され、フラッシュリクエストが Dispatcher モジュールにヒットしたことを確認できます

モジュールが取得され、フラッシュリクエストを確認したので、モジュールが.stat ファイルにどのような影響を与えたかを確認する必要があります。  次のコマンドを実行し、別のフラッシュを実行する際にタイムスタンプの更新を確認します。

| $ watch -n 3 "find /mnt/var/www/html/ -type f -name " .stat " | xargs ls -la $1" |
| — |

コマンド出力からわかるように、現在の.stat ファイルのタイムスタンプが表示されます。

フラッシュを再度実行した場合は、タイムスタンプの更新を確認してください。

コンテンツのタイムスタンプを.stat ファイルのタイムスタンプと比較してみましょう

タイムスタンプのいずれかを見ると、コンテンツは.stat ファイルより新しい時刻を持っていることに気が付くでしょう。これは、 .stat ファイルより新しいので、キャッシュからファイルを提供するようモジュールに指示します。

明らかに、このファイルのタイムスタンプは更新されており、「フラッシュ」または置き換えの条件を満たしていません。