Adobe Managed Services ディスパッチャーのフラッシング

このドキュメントでは、フラッシングがどのように発生するかに関する情報を提供し、キャッシュフラッシングと無効化が実行されるメカニズムについて説明します。

動作の仕組み

操作の順序

一般的なワークフローを最もよく説明できるのは、コンテンツのオーサーがページをアクティブ化し、パブリッシャーが新しいコンテンツを受信してディスパッチャーへのフラッシュリクエストをトリガーする場合です。これは以下の図に示されています。

オーサーはコンテンツをアクティブ化し、パブリッシャーがディスパッチャーにフラッシュするリクエストを送信するようトリガーします

この一連のイベントは、フラッシュされるのが新しいアイテムまたは変更されたアイテムのみであることを強調しています。  キャッシュをクリアする前にパブリッシャーがコンテンツを受信することが保証されるので、パブリッシャーから変更を取得する前にフラッシュが発生するという競合状態が発生する可能性を回避できます。

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

オーサーは、パブリッシャーを指すように構成されたレプリケーションエージェントを所有します。何かがアクティブ化されると、ファイルとそのすべての依存関係のパブリッシャーへの送信がトリガーされます。

パブリッシャーは、ディスパッチャーを指すように構成されたレプリケーションエージェントを所有します。これは、ファイルを受信すると、「On Receive」イベントでトリガーされ、  フラッシュリクエストをシリアル化し、ディスパッチャーに送信します。

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

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

AEM webページ /etc/replication.html からの標準レプリケーションエージェントのスクリーンショット

通常、オーサーには、コンテンツをレプリケーションする各パブリッシャーごとに 1 つまたは 2 つのレプリケーションエージェントが構成されています。

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

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

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

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

AEM webページ /etc/replication.html からの標準フラッシュレプリケーションエージェントのスクリーンショット

仮想ホストを受信するディスパッチャーフラッシュレプリケーション

ディスパッチャーモジュールは、特定のヘッダーを探して、POST リクエストが AEM レンダリングに渡すものであるのか、またはフラッシュリクエストとしてシリアル化され、ディスパッチャーハンドラー自体で処理する必要があるのかを識別します。  以下はこれらの値を示す構成ページのスクリーンショットです。

メインの構成画面の設定タブの画像。シリアル化の種類はディスパッチャーフラッシュとして表示されています

デフォルト設定ページでは、シリアル化の種類ディスパッチャーフラッシュとして表示し、エラーレベルを設定します

レプリケーションエージェントの「トランスポート」タブのスクリーンショット。フラッシュリクエストを送信する URI は /dispatcher/invalidate.cache として示されています。

「トランスポート」タブでは、フラッシュリクエストを受信するディスパッチャーの IP アドレスを指定している URI を確認できます。  パス「/dispatcher/invalidate.cache」は、モジュールがフラッシュであるかどうかを特定する方法ではありません。代わりに、これは、フラッシュリクエストであることを知るためにアクセスログで確認できる明らかなエンドポイントです。  「拡張」タブでは、これがディスパッチャモジュールへのフラッシュリクエストであることを特定する内容を確認します。

レプリケーションエージェントの「拡張」タブのスクリーンショット。ディスパッチャーにフラッシュを指示するために送信された POST リクエストで送信されるヘッダーに注意してください

フラッシュリクエストの HTTP メソッドは普通の GET リクエストですが、いくつかの特別なリクエストヘッダーを持ちます。

  • CQ-Action
    • リクエストに基づいて AEM 変数を使用します。値は通常、activate または delete
      です。
  • CQ-Handle
    • リクエストに基づいて AEM 変数を使用します。値は通常、フラッシュされたアイテムへのフルパスです(例:/content/dam/logo.jpg
  • CQ-Path
    • リクエストに基づいて AEM 変数を使用します。値は通常、フラッシュされたアイテムへのフルパスです(例:/content/dam
  • Host
    • これは、ディスパッチャー Apache web サーバーで構成されている特定の<VirtualHost>をターゲットとするために、ホストヘッダーがスプーフィングされる場所です(/etc/httpd/conf.d/enabled_vhosts/aem_flush.vhost)。  値はハードコードされていて、aem_flush.vhost ファイルの ServerName または ServerAlias エントリと一致します。
コンテンツを公開しているオーサーからのレプリケーションイベントから新しいアイテムが受信されると、レプリケーションエージェントが反応してトリガーすることを示す標準レプリケーションエージェントのスクリーンショット

「トリガー」タブでは、使用するトグルされたトリガーとそれらが何であるかに気を付けます

  • Ignore Default
    • レプリケーションエージェントがページのアクティベーション時にトリガーされないように有効にされます。  これは、オーサーインスタンスがページに変更を加えたときにフラッシュをトリガーするものです。  これはパブリッシャーであるため、この種類のイベントはトリガーしません。
  • On Receive
    • 新しいファイルを受信したら、フラッシュをトリガーします。  そのため、オーサーが更新されたファイルを送信すると、トリガーしてディスパッチャーにフラッシュリクエストを送信します。
  • No Versioning
    • 新しいファイルが受信されたことによってパブリッシャーが新しいバージョンを生成しないようにするために有効にします。  持っているファイルを置換するだけで、パブリッシャーではなくオーサーに依存してバージョンを追跡します

ここで、典型的なフラッシュリクエストが curl コマンドの形式ではどのようなものなのかを見てみます。

$ curl \ 
-H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/dam/logo.jpg" \ 
-H "CQ-Path: /content/dam/" \ 
-H "Content-Length: 0" \  
-H "Content-Type: application/octect-stream" \ 
-H "Host: flush" \ 
http://10.43.0.32:80/dispatcher/invalidate.cache

このフラッシュの例では、/content/dam path にある「.stat」ファイルを更新することによって、このディレクトリをフラッシュします。

「.stat」ファイル

フラッシュメカニズムは本質的にシンプルです。ここでは、キャッシュファイルが作成されるドキュメントルートで生成される .stat ファイルの重要性を説明したいと思います。

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

ディスパッチャーサーバーで次のコマンドを実行すると、「.stat」ファイルの検索が開始されます

 

$ find /mnt/var/www/html/ -type f -name ".stat"

キャッシュにアイテムがあり、ディスパッチャーモジュールによってフラッシュリクエストが送信および処理された場合に、このファイル構造がどのように見えるかを示す図を次に示します。

コンテンツと日付が混在した「.stat」ファイルと「.stat」ファイルレベル

「.stat」ファイルレベル

各ディレクトリに「.stat」ファイルが存在することに注意してください。  これは、フラッシュが発生したことを示します。  上の例では、対応するファーム構成ファイル内の statfileslevel 設定は 3 です。

「statfileslevel」の設定は、モジュールが「.stat」ファイルを走査して更新するフォルダーの深さを示します。  「.stat」ファイルは空で、タイムスタンプ付きのファイル名にすぎません。ディスパッチャーサーバーのコマンドラインで touch コマンドを実行して手動で作成することもできます。

「statfileslevel」の設定値が高すぎる場合、各フラッシュリクエストがディレクトリツリーを走査して「.stat」ファイルに触れます。  大きなキャッシュツリーではこれには大きな負荷が余分にかかり、ディスパッチャーの全体的なパフォーマンスに影響を与える可能性があります。

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

注意:

statfileslevel は適切なレベルに設定してください。  フォルダー構造を見て、あまり多くのディレクトリを走査することなく簡潔なフラッシュを許可するようにレベルが設定されていることを確認してください。   システムのパフォーマンステスト中に設定をてすとして、ニーズに合っていることを確認してください。

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

/content/brand1/en/us/

この例では、statfileslevelを「4」に設定します。  これによって、us フォルダー内のコンテンツをフラッシュするときに、言語フォルダーがフラッシュされないことを保証できます。

「.stat」ファイルタイムスタンプハンドシェイク

コンテンツのリクエストが同じルーチンで発生した場合、以下が起こります。

  1. 「.stat」ファイルのタイムスタンプが、リクエストされたファイルのタイムスタンプと比較されます
  2. 「.stat」ファイルがリクエストされたファイルよりも新しい場合、キャッシュされたコンテンツを削除し、AEM から新しいコンテンツを取得してキャッシュします。  その後、コンテンツを提供します
  3. 「.stat」ファイルがリクエストされたファイルよりも古い場合、ファイルが新しく、コンテンツを提供できることがわかります。

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

上記の例でコンテンツ /content/index.html をリクエスト

index.html ファイルのタイムスタンプ:2019-11-01 @ 6:21PM

一番近い「.stat」ファイルのタイムスタンプ:2019-11-01 @ 12:22PM

上記の説明から、index.html ファイルが「.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で参照できます。

ここで、キャッシュフラッシングに関連するいくつかのことを強調したいと思います

ドキュメントルート

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

/myfarm { 
    /cache { 
        /docroot

ディスパッチャーにキャッシュディレクトリとして入力および管理させるディレクトリを指定します。

注意:

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

Apache ドキュメントルートのサブフォルダーにある各ファームごとに docroot フォルダーをネストするのは、多くの理由で良い考えではありません。

「.stat」ファイルレベル

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

/myfarm { 
    /cache { 
        /statfileslevel

この設定は、フラッシュリクエストを受け取ったときに「.stat」ファイルを生成する必要があるフォルダー階層数を評価します。

以下では、ドキュメントルートが「/var/www/html/」の場合に「/content/dam/brand1/en/us/logo.jpg」をフラッシュするときの動作を「/statfileslevel」の設定値ごとに見てみます。

  • 0 - 次の「.stat」ファイルが作成されます
    • /var/www/html/.stat
  • 1 - 次の「.stat」ファイルが作成されます
    • /var/www/html/.stat
    • /var/www/html/content/.stat
  • 2 - 次の「.stat」ファイルが作成されます
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
  • 3 - 次の「.stat」ファイルが作成されます
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
  • 4 - 次の「.stat」ファイルが作成されます
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
    • /var/www/html/content/dam/brand1/en/.stat
  • 5 - 次の「.stat」ファイルが作成されます
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
    • /var/www/html/content/damn/brand1/en/.stat
    • /var/www/html/content/damn/brand1/en/us/.stat

 

注意:

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

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

無効化の許可

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

/myfarm { 
    /cache { 
        /allowedClients {

フラッシュリクエストを送信できる IP アドレスのリストをここに配置します。  ディスパッチャーが受信するフラッシュリクエストは、信頼できる IP から発信される必要があります。  このエントリが正しく構成されていない、または、信頼できない IP アドレスからフラッシュリクエストが送信されると、ログファイルに以下のエラーが記録されます。

[Mon Nov 11 22:43:05 2019] [W] [pid 3079 (tid 139859875088128)] Flushing rejected from 10.43.0.57

無効化ルール

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

/myfarm { 
    /cache { 
        /invalidate {

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

重要なファイルがページのアクティベーションで無効にされないようにするには、無効にできるファイルと手動で無効にする必要があるファイルを指定するルールを設定します。  以下は、HTML ファイルの無効化のみを許可する構成のサンプルセットです。

/invalidate { 
   /0000 { /glob "*" /type "deny" } 
   /0001 { /glob "*.html" /type "allow" } 
}

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

ページをアクティブ化して、アクティベーションが成功したことを示す緑色のライトが表示されたなら、アクティブ化したコンテンツもキャッシュからフラッシュされるはずです。

しかし、ページを更新すると、古いコンテンツが表示されています。緑色のライトも表示されたのに、何が起こったのでしょうか。

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

 

$ curl -H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/<PATH TO ITEM TO FLUSH>" \ 
-H "CQ-Path: /content/<PATH TO ITEM TO FLUSH>" \ 
-H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ 
-H "Host: flush" \ 
http://<DISPATCHER IP ADDRESS>/dispatcher/invalidate.cache

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

$ curl -H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/customer/en-us" \ 
-H "CQ-Path: /content/customer/en-us" \ 
-H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ 
-H "Host: flush" \ 
http://169.254.196.222/dispatcher/invalidate.cache

ディスパッチャーへのリクエストコマンドを実行したら、何が起こったかのかをログで確認し、「.stat」ファイルで何が発生したかを確認します。  ログファイルで「taiil」コマンドを実行すると、次のエントリが表示されるので、ディスパッチャーモジュールにフラッシュリクエストが到達したことは確認できます。

[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Activation detected: action=Activate [/content/dam/logo.jpg] 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/content/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/content/dam/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] "GET /dispatcher/invalidate.cache" 200 purge [publishfarm/-] 0ms

モジュールが正常に動作し、フラッシュリクエストを認識したことはわかったので、これが「.stat」ファイルにどのように影響したかを確認します。  次のコマンドを使用してフラッシュを実行し、タイムスタンプが更新されるのを確認します:

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

コマンド出力から、現在の「.stat」ファイルのタイムスタンプがわかります

-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/dam/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/.stat

フラッシュを再度実行すると、タイムスタンプが更新されます

-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/dam/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/.stat

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

$ stat /mnt/var/www/html/content/customer/en-us/.stat 
  File: `.stat' 
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file 
Device: ca90h/51856d    Inode: 17154125    Links: 1 
Access: (0644/-rw-r--r--)  Uid: (   48/  apache)   Gid: (   48/  apache) 
Access: 2019-11-13 16:22:31.000000000 -0400 
Modify: 2019-11-13 16:22:31.000000000 -0400 
Change: 2019-11-13 16:22:31.000000000 -0400 
 
$ stat /mnt/var/www/html/content/customer/en-us/logo.jpg 
File: `logo.jpg' 
  Size: 15856           Blocks: 32          IO Block: 4096   regular file 
Device: ca90h/51856d    Inode: 9175290    Links: 1 
Access: (0644/-rw-r--r--)  Uid: (   48/  apache)   Gid: (   48/  apache) 
Access: 2019-11-11 22:41:59.642450601 +0000 
Modify: 2019-11-11 22:41:59.642450601 +0000 
Change: 2019-11-11 22:41:59.642450601 +0000

タイムスタンプのいずれかを見ると、コンテンツが「.stat」ファイルよりも新しいことが分かります。つまり、モジュールは、より新しいキャッシュからファイルを提供するよう指示されているわけです。

簡単に言えば、何かがこのファイルのタイムスタンプを更新したために、ファイルが「フラッシュ」または置き換えの対象とならなかったわけです。

次 ➡ バニティ URL

アドビのロゴ

アカウントにログイン