デフォルトのパブリッシュに関する問題のトラブルシューティング


概要

この記事では、デフォルトのパブリッシュ メカニズム特有の問題のトラブルシューティングに焦点を当てて説明します。この記事の情報の多くはSitecore Publishing ServiceやExperience Edge Connectorには適用されませんのでご注意ください。

もしSitecore Publishing ServiceやExperience Edge Connectorに関連する問題が発生している場合は、Sitecoreサポート ポータルを使用してSitecoreサポートにご連絡ください。
詳細につきましては、Sitecoreサポート ポータルの使用方法の記事をご参照ください。

デフォルトのパブリッシュに関する問題をトラブルシューティングするには、以下の手順に従ってください。

手順1： 基本を確認する

第一段階は、パブリッシュ操作が開始できることを確認することです。一度に実行できるパブリッシュ操作は一つだけです。パブリッシュのメカニズムは、複数の同時パブリッシュ操作が開始されないように保護されています。しかし、誤った構成によって一つの操作のみというルールが破られる可能性があります。

  1. パブリッシュのインスタンスを識別する
    パブリッシュの操作を実施できるインスタンスは、環境ごとに一つのみ存在できます。デフォルトのSitecoreインストール トポロジーには、パブリッシュ インスタンスとして機能するインスタンスが厳密に一つだけ含まれています。すなわち、「Standalone」もしくは「ContentMangement」ロールを持つインスタンスです。
    「Publishing.PublishingInstance」設定は、デフォルトでは空になっており、これは操作を開始するのに使用されたインスタンスと同じインスタンスで操作が実行される必要があることを示しています。もし環境でパブリッシュ操作を開始するのに使用できるインスタンスが複数ある場合（例えば、「ContentMangement」ロールのインスタンスが複数ある場合など）、「Publishing.PublishingInstance」設定でパブリッシュ インスタンスの名前を指定する必要があります。このシナリオでは、各インスタンスは「InstanceName」設定で一意の値を設定する必要があり、かつ「Publishing.PublishingInstance」設定でインスタンス名のいずれか一つを使用するよう設定する必要があります。詳細につきましては、複数のContent Managementインスタンスを設定するをご参照ください。
    複数のアプリケーション インスタンス間でSitecore構成を共有する環境、例えばスケールアウトされたAzure Web AppもしくはAKS内の複数のpodのレプリカなどでは、「InstanceName」設定は空のままにしておく必要があります。この場合、インスタンス名は「Environment.MachineName」および「HostingEnvironment.SiteName」をもとに割り当てられます。なお、パブリッシュ インスタンスはスケールアウトすることはできません。
  2. データベースが環境を跨いで共有されていないことを確認する
    まれな状況として、同じパブリッシュ ターゲット データベース（例：web）が複数の環境で跨いで使用されるケースがあります。しかし、そうした構成はサポートされておらず、またパブリッシュの問題を含む非常に多くの問題を生じさせる可能性があるため、推奨されません。
  3. 実行中・またはキューイングされたパブリッシュ操作がないことを確認する
    • パブリッシュ インスタンスで「<貴社サイト>/sitecore/admin/jobs.aspx」ページを開き、実行中およびキューイングされたジョブを確認します。
    • 「Running jobs」リストに「Publish」ジョブが含まれている場合、新しいパブリッシュ操作は開始できません。
    • パブリッシュ操作が開始されると、その都度ジョブのキューに追加され、「Queued jobs」リストに表示されます。

    ジョブがキューイングされるのは通常のことです。ジョブは（同じ名前の）前のジョブが完了次第一つずつ処理されます。しかし、新しいパブリッシュ操作がキューイングされたジョブが処理されるより早く作成されると、操作が開始されてから更新されたコンテンツが表示されるまでの遅延が増大し続けることとなります。
    既存のジョブを中止するメカニズムは備わっていません。もし変更を緊急にパブリッシュしなければならない場合、アプリケーションを再起動してジョブ キューをクリアし、現在のパブリッシュ操作と全てのキューイングされた操作を中止する必要があります。新しいパブリッシュ操作はアプリケーションの再起動後に開始できます。
    長期的な解決策は、パブリッシュ操作の頻度を削減することに重点を置くこと、および個別の操作の実行時間を最適化することです。この詳細につきましては、以下に後述します。

手順2： パブリッシュのオプションを検証する

第二段階は、意図した変更をパブリッシュする適切なオプションを指定して、確実にパブリッシュの操作を開始することです。

パブリッシュ操作の結果は、（選択した）パブリッシュのオプションに依存します。パブリッシュのオプションはSitecore Publishingログに以下のように記録されます。

INFO [PublishOptions]: root:null, language:en, targets:Internet, database:web, mode:Incremental, smart:True children:False, related:True

パブリッシュのモードは四種類あります。

パブリッシュ中に処理されるアイテムの選択プロセスをトラブルシューティングする、もしくはパブリッシュ中に実施される必要のあるアクション（skip|update|create|delete）を決定するプロセスをトラブルシューティングするには、traceToLog機能を有効化することをご検討ください。詳細につきましては、以下をご参照ください。
https://doc.sitecore.com/xp/en/users/104/sitecore-experience-platform/publish-an-item-to-your-website.html#logging

重要な注意事項： デフォルトでは全てのアイテムがパブリッシュ可能な状態です。コンテンツが意図せず通常より早くパブリッシュされないよう防止するには、ワークフロー機能、プレビュー パブリッシュ ターゲット、およびパブリッシュ制限を使用してください。

手順3： イベント キュー

パブリッシュ操作が開始されたこと、およびスケジュールされた変更が処理されたことを確認したら、変更がリモート インスタンスに反映されていることを確認します。

  1. イベント キュー機能が有効化していることを確認します。
    <setting name="EnableEventQueues" value="true" />
  2. イベント キューが処理されていることを確認します。
    パブリッシュ ターゲット データベース（例えばweb）のEvent Queueテーブルの最後のエントリーを確認します。
    SELECT MAX(Stamp) FROM EventQueue
    これを、同じデータベースのPropertiesテーブルの「EQStamp」プロパティの値と比較します。
    SELECT * FROM Properties WHERE [Key] like '%EQStamp_%'
    複数のプロパティがクエリにヒットする可能性がある点にご留意ください。データベースを使用するアクティブなSitecoreインスタンスごとにエントリーが一つ存在するはずです。古くなったエントリーは削除することができます。エントリーが存在しない場合は、より詳しい調査が必要となります。
    • 値が同じである場合は、全てのエントリーがすでに処理されています。
    • ２つ目の値が１つ目の値よりも高い場合、イベントの処理が意図した通りに動作していません。問題のあるエントリーをPropertiesテーブルから削除し、問題が発生しているSitecoreインスタンスを再起動します。
    • １つ目の値が２つ目の値よりも高い場合、Sitecoreインスタンスがイベントの頻度に追いつけていない状態であることを意味します。

以下のテクニックを使用して、イベントの処理を改善することができます。

  1. キャッシュ キー インデックス機能。この機能は、部分的なキャッシュ キーにより古くなったキャッシュ エントリーの削除の処理をスピード アップする、追加のキャッシュ インデックスを導入します。
  2. 「EventQueue.SavedItemRemote.SerializeAllFields」設定。この設定値をfalseに変更することで、イベント キューを通じて送信される情報の量を著しく減らすことができます。この変更は、特定のアイテム フィールドへの変更に依存するカスタムの「item:saved:remote」イベント ハンドラーを使用している場合、注意して適用する必要があります。

timingLevel機能は、イベント処理の速度を遅くしているイベント ハンドラーを特定するのに使用することができます。
例：

<events timingLevel="high">

この機能が有効化されている場合、アプリケーションは個別のイベント ハンドラーの実行時間を含む、各イベントの処理時間を計測して記録します。この機能は診断目的でのみ使用する必要があります。

手順4： キャッシュ

この段階で、変更がリモート インスタンスに反映されるはずです。

もし変更が反映されない場合、キャッシング レイヤーの一つによって問題が発生している可能性があります。この可能性を検証する（および、問題の影響を緩和する）最も早い方法は、例えばアプリケーションを再起動するなどして、全てのキャッシュをクリアすることです。

再起動によって問題が解決する場合、問題はアプリケーションのキャッシュ（すなわちアプリケーション メモリのどこかに保存されるキャッシュされた結果）によって発生している事がわかります。この問題をトラブルシューティングするには、キャッシュされた結果を提供するプロセスのメモリ ダンプをキャプチャします。

Windows debugger (WinDbg)をSOSEXデバッグ用拡張機能と共に使用し、キャッシュされた値を探します。
例：

!strings /m:"*cached text*"

一致した各エントリーについて、メモリに何を保持しているか確認します。
例：

!mroot <address_of_the_string>

再起動によって問題が解決しない場合、例えばCDNキャッシュやブラウザ キャッシュなどのクライアント側に変更がキャッシュされている可能性があります。

アプリケーション キャッシュのクリアによって問題が解決しない場合、データベースのコンテンツを直接確認して変更がパブリッシュされていることを確認します。ただし、前述の手順2でSitecoreログ ファイルを確認した際に全てのパブリッシュの問題は捕捉できるはずであるため、このシナリオに至る可能性は低いと考えられます。

手順5： Sitecoreサポートに連絡する

上記のご提案した手順を実施しても問題が解決できない場合、Sitecoreサポートにご連絡いただき、より詳しい調査に必要な情報をご共有ください。パブリッシュの問題に関する診断情報を収集する方法の詳細につきましては、KB1003463をご参照ください。