【ServiceNow】イベント処理について知りたかった５つのこと

この記事は ServiceNow アドベントカレンダー 2024 の12月10日分の記事として執筆しています。

はじめに

普段 ServiceNow ベースのアプリケーションを管理しているのですが、今年はどういうわけか ServiceNow の処理遅延について調べる機会が多くありました。
調査の過程で知りたい情報を探すのに苦労したので、得られた知見を共有します。

おことわり

• 本記事では ServiceNow のシステムイベントについて説明します。ITOM の文脈における「イベント」の話ではないのでご注意ください。
• ServiceNow の内部仕様はブラックボックスのため、製品ドキュメントや Community の情報、動作確認結果を基に憶測を交えて記載しています。指摘事項があればぜひコメントをお願いします。
• 対象バージョンは Washington D.C. です。Xanadu では一部仕様が異なっています。

イベント処理について知りたかった５つのこと

① イベントとキュー

システムイベント（以下、イベント）は、ServiceNowプラットフォームで発生するさまざまなアクションや状態変化に対応する内部的な通知メカニズムです。これらはイベント [sysevent] テーブルに記録され、特定のアクション（通知の送信、スクリプトの実行など）をトリガーするために使用されます。

システムの負荷分散のため、イベントは生成されたら即実行ではなく、一旦キューに格納されます。特定の用途向けに事前定義されたキューもありますが、多くのイベントはデフォルトキューで処理されます。

ビジネスルールなどからイベントを呼び出す際に使用する gs.eventQueue() メソッドも通常はデフォルトキューを使用しますが、第五引数でキューを指定することも可能です。
普段あまり使う機会はありませんが、デフォルトキューで滞留を引き起こすおそれのあるイベントは、カスタムキューを作成¹してそちらで処理させることができます。

② イベント処理の同時実行数

デフォルトキューで待機状態のイベントは、イベント委任者 (Event Delegator) とイベントプロセッサー(Event Processor) という２種類のジョブによって処理されます。

ジョブ名	説明
イベント委任者	10秒間隔でデフォルトキューをチェックし、準備完了(ready)状態のイベントをイベントプロセッサーに割り当てます。 アクティブノードのいずれか１つで実行されます。
イベントプロセッサー	委任者に割り当てられたイベントを処理するジョブです。 インスタンスのアクティブノードでそれぞれ１つずつ実行されます。

例えば合計４ノード（Failover構成）の場合、デフォルトキューのイベントプロセッサー数＝同時実行数は２となります。
すべてのプロセッサーが時間のかかるイベントを掴んでしまったり、一度に処理できる数²を大幅に上回るイベントが生成された場合、デフォルトキューで滞留が起こり、遅延が発生します。

イベント委任者およびプロセッサーの実態は、名前が 「events process」で始まる Scheduled Job です。
バージョンWashington D.C.³でスケジュール [sys_trigger] テーブルを検索すると、通常複数のレコードが見つかります。親フィールドが空のレコードがイベント委任者、委任者が入っているレコードがプロセッサーです。

バージョンアップのタイミングなどで、稀にイベントプロセッサーが消えることがあるようです。対処方法のナレッジ⁴も存在しますが、サポートに問い合わせたところ復旧してもらえました。

デフォルトキュー以外のプロセッサー数は、イベントプロセッサー [sys_event_processor] テーブルで確認できます。flow_engine キューなどは多少優遇されているようです。

③ sysevent テーブルの読み方

一部のフィールドは製品マニュアル⁵に説明がありますが、それ以外にもシステム管理者の観点で押さえておきたいフィールドを紹介します。

フィールド名	説明	(参考) 日本語ラベル
Queue	イベントの処理に使用するキュー。 デフォルトキューの場合は(空)。	キュー
State	現在のイベントの状態。	ステータス
Claimed by	イベントを割り当てられたイベントプロセッサー名。	要求元
Process on	イベント処理の開始予定日時。	処理日時
Processed	イベント処理を実際に開始した日時。	処理済み
Processing duration	イベントの処理にかかった時間(ミリ秒)。	処理期間

Process on（開始予定日時）と Processed（実際の開始日時）に乖離のあるレコードが複数ある場合、そのキューで処理の遅延が発生しているということになります。

イベントの処理遅延が起きている場合、キューの滞留を引き起こしているイベントを調査し、「ボトルネックを特定して処理を改善する」「カスタムキューで捌く」などの対応が必要になります。

イベント処理のステータス遷移

イベントテーブルにおける代表的な State フィールドの値は以下のとおりですが、queued.<イベントプロセッサーのSys ID>（イベントがキューから取り出され、プロセッサーに処理されている状態？）など、内部で定義されているステータスが他にもいくつかあるようです。

ステータス	説明
ready	イベントが作成され、処理待ちとなっている状態。
processed	イベントが正常に実行された状態。
error	イベント処理中にエラーが発生した状態。
transferred	イベントが別のシャードにコピー済みとなった状態。

イベントテーブルにはイベント処理の終了日時を格納するフィールドはありませんが、以下のどちらかによりおおよその終了日時を求めることが可能です。

• Processed + (Processing Duration / 1,000)
• Updated （※State が processed または error に更新済みの場合）

transferred ステータスとは？
イベントテーブルは、24時間ごとに切り替わる７つのシャード（物理テーブル）で構成されるローテーションテーブル⁶です。ServiceNow では時間ベースのポインタを使用して、現在アクセスするシャードを絞り込むことで処理効率化を図っています。

シャードの切り替え時、古いシャードに残っている未処理のイベントにはそれ以降アクセスできなくなるため、すべての未処理イベントを新しいシャードにコピーします。この際、コピーされた古いシャードのイベントは「transferred（転送済み）」ステータスに変更されます。⁷⁸。

④ 異常にどう気付くか

イベントアラートの構成テーブル

デフォルトで５種類のイベント監視用アラートが イベントアラートの構成 [sysevent_alert_configuration] テーブル に用意されており、条件を変更して利用することが可能です（新規での登録は不可）。

ウォッチリストを登録すると、以下のようなシステム通知を受信することもできます。

通知の仕組みとしては、

1. 15分毎にイベントアラートの構成テーブルの条件をチェック
2. 条件に合致したら、イベントアラート [sysevent_alert] テーブルにレコードを挿入
3. レコードの挿入をきっかけに通知

となっているので、3 の代わりにメール通知などを定義することもできそうです。

System Event Processing ダッシュボード

ServiceNow ではプラットフォーム上のイベントとキューに関する状態や傾向などの情報を把握できる System Event Processing ダッシュボードが提供されており、[すべて] > [システム診断] > [統計] > [システムイベントおよびジョブダッシュボード] からアクセスすることができます。
ここまでで説明した①～④の内容を理解することで、ダッシュボードの項目をおおよそ読み解けるようになるはずです。

⑤ もっと分かりやすいツールないの？

Application Insights というものがあるらしいが……

Application Insights はアプリケーションのパフォーマンスや健全性を監視し、可視化するためのツールで、System Event Processing ダッシュボードよりも詳細な情報を参照できるようです。

（参考：https://www.youtube.com/watch?v=P72zNA9C0Ik ）

以前は ServiceNow Store から入手可能でしたが、バージョン Zurich で廃止予定⁹のため、現在はインストールできない状態になっています。

イベント処理を可視化するダッシュボードを作ってみた

遅延が発生したときに「どのプロセッサーがどのイベントを処理していたか」を可視化する手段が欲しいと思い、サンプルのダッシュボードを作ってみました。ServiceNow Share よりダウンロードできます。

• 期間およびキューを指定して、処理されたイベントを時系列順に表示できます
• イベントプロセッサーごとに異なる色でイベントをプロットできます
• システムプロパティにより、プロットするイベント数の上限を設定できます（デフォルト10,000件）

本ダッシュボードは個人が独自に開発したものであり、所属する企業・団体とは一切関係ありません。プログラムの動作やその影響について保証するものではありませんのでご了承ください。

参考

• ServiceNow 製品ドキュメント『システムイベントダッシュボードについて』
• ServiceNow Community『Improved events processing on the ServiceNow platform』

1. ServiceNow 製品ドキュメント『カスタムキューを使用してイベントを処理する』 ↩

2. デフォルトでは、各プロセッサーへ一度に割り当てられるイベント数は3,000が上限とのこと。 ↩

3. バージョン Xanadu の場合、プロセッサーは新規に追加された キューレジストリ [sysevent_queue] というテーブルで管理されるようになった（？）模様。 ↩

4. ServiceNow Support 『High Priority Event Processing -- Event Queue Has Very High Number of Queued Events』 ↩

5. ServiceNow 製品ドキュメント 『システムイベント』 ↩

6. テーブルローテーションの仕組みについては [ServiceNow]主にログテーブルで使われるテーブルローテーションの仕組み が大変参考になりました。 ↩

7. ServiceNow Community『When does an event EXACTLY go to the 'Transferred' state?』 ↩

8. ServiceNow Community『Demystifying table rotation, extension, and table cleaner』 ↩

9. ServiceNow 製品ドキュメント『Xanadu リリースにおけるプラグインの変更』 ↩