【ITニュース解説】Excluding Cross‑Property Devices from Metrics and Adding Live Scan Tracking in monitor‑parches‑uhpcm

システム開発の現場では、ユーザーが日々利用するダッシュボードやアプリケーションの挙動は非常に重要である。特に、システムの状態を監視したり、何らかの操作をトリガーしたりするツールでは、表示される情報が正確であること、そしてユーザーの操作が正しく反映されていることをリアルタイムで伝えられることが求められる。今回紹介する事例は、まさにそうした課題に直面し、それをどのように解決したかを示す、システムエンジニアの卵たちにとっても非常に学びの多い内容だ。

このプロジェクトでは、内部のパッチ監視ダッシュボードが抱えていた二つの大きな問題点の解決が求められた。一つは「データ漏洩」による誤った情報の表示、もう一つはユーザーの操作に対する「状態伝播の欠如」によるUIの無反応である。

まず「データ漏洩」について説明する。このダッシュボードは、複数の物理的な場所（「プロパティ」と呼ばれる拠点）から集められたデバイスデータを集計していた。しかし、ユーザーが特定のプロパティを選んでデータを表示しようとしても、実際には選択されていない他のプロパティに属するデバイスのデータまでがダッシュボードの合計値に含められてしまっていたのだ。その結果、「パッチ不足」のデバイス数などの重要な指標が実際よりも多く表示され、オペレーターが誤った判断を下す原因となっていた。これは、データフィルタリング（必要なデータだけを選び出す処理）が、重い分析処理がすべて終わった後、つまりデータを画面に表示する直前の「表示層」（フロントエンドとも呼ばれる、ユーザーが見る部分）でしか行われていなかったために発生していた問題だった。本来、分析の初期段階で不要なデータを除外すべきなのに、最後まで全データで処理してしまっていたのである。

次に「状態伝播の欠如」についてだ。技術者（オペレーター）がダッシュボードからデバイスに対して「強制スキャン」を指示した場合、そのスキャンがバックエンド（ユーザーから見えない裏側の処理部分）で実際にキューに入れられ、処理が開始されたにもかかわらず、ユーザーインターフェース（UI、画面）上には何も変化がなかった。これでは、ユーザーは本当にスキャンが実行されたのか不安になり、何度も「強制スキャン」ボタンをクリックしてしまう。結果として、バックエンドでは同じスキャンリクエストが何度も処理されようとし、システムに余計な負荷をかける可能性もあった。この問題は、スキャンが開始されたという「状態」がバックエンドでのみ管理され、それがリアルタイムでフロントエンドに伝達されていなかったことが原因だった。

これらの問題を解決するため、開発者は最初にいくつかの簡単な方法を試みた。データ漏洩の問題に対しては、UI側でデータをテーブルに表示する直前に、選択されたプロパティに一致するデバイスだけをフィルタリングするという方法だ。しかし、これでは画面上の表示は正しくなったものの、合計値を計算するような重要なロジックは依然としてフィルタリングされていない全データに対して実行されていたため、計算結果は相変わらず間違ったままだった。さらに、何千ものデータを二度処理することになり、ダッシュボードの表示に遅延が生じるというパフォーマンスの問題も発生した。

スキャン状態の問題については、スキャンを要求する通信（HTTP POSTリクエスト）を送った直後に、数秒間の遅延（setTimeout）を設けてからUI上のアイコンを「スキャン処理中」に切り替えるという方法を試した。しかし、これもネットワークの速度やバックエンドの処理時間によって遅延のタイミングが不安定になり、スキャンが実際に始まる前にUIが完了したように見えてしまうなど、信頼性に欠ける「その場しのぎ」の対応に過ぎなかった。

これら初期のアプローチが失敗した理由は、どちらも問題の「症状」を、根本的な原因が存在する場所とは異なる「レイヤー」（システム内の役割分担された部分）で対処しようとしていたからだ。システムエンジニアにとって、問題が発生している場所の根本原因を見極め、適切なレイヤーで解決策を講じることの重要性を教えてくれる事例と言えるだろう。

最終的に採用された解決策は、根本原因に直接アプローチするものだった。

一つ目のデータ漏洩の問題に対しては、「分析層」でのフィルタリングが導入された。分析層とは、生のデバイスレポートデータを受け取り、それを意味のある指標やグループに変換する、システムの核となる部分である。開発者は、この分析層のコア設定ファイル(lib/analysis.mjs)に、許可するプロパティのリスト（propertyWhitelist）と、デバイスがそのリストに含まれるかをチェックする関数を追加した。そして、メインの分析関数がデバイスデータをループ処理する際に、この新しいチェックを早い段階で実行するように変更した。これにより、リストに含まれない、つまり対象外のプロパティに属するデバイスは、それ以降の重いグループ化処理や集計処理に進むことなく、すぐにスキップされるようになった。この変更によって、下流のすべての集計ロジックは、最初から「クリーンで正しい」データセットに対して動作するようになり、ダッシュボードの合計値が誤っていた問題は、UI側で何も追加の変更をすることなく完全に修正されたのである。

二つ目のスキャン状態伝播の問題に対しては、「リアルタイムな状態管理と伝播メカニズム」が導入された。バックエンドのスキャン処理を行う部分(lib/service.mjs)に、現在スキャンが保留中であるデバイスIDとそのスキャンを起動したユーザー、時刻を記録する一時的なメモリ上のデータ構造（activeScansマップ）が追加された。デバイスのスキャン要求を受け付けた際には、まずこのマップにデバイス情報を登録し、その後に実際のスキャン処理を外部システムに依頼するようにした。さらに、このactiveScansマップの内容をJSON形式で返す新しいAPIエンドポイント（/api/scan/status）が作成された。APIとは、異なるソフトウェア同士が情報をやり取りするための窓口のようなものだ。

フロントエンド(public/app.js)では、5秒ごとにこの新しいAPIエンドポイントを定期的に呼び出して（「ポーリング」と呼ばれる手法）、最新のアクティブスキャン情報を取得する処理が実装された。取得した情報に基づき、UIの各デバイス行のアイコン（scanokクラスを持つ要素）が更新され、スキャンがアクティブであればアイコンが点灯し、ツールチップとしてスキャンを起動したユーザー名が表示されるようになった。これにより、ユーザーはスキャンをトリガーした瞬間に、UI上でその操作がシステムに受け付けられたことを明確に確認できるようになり、安心して次の作業に進めるようになったのである。

また、ユーザー体験をさらに向上させるためのUIの微調整も行われた。すべての保留中のスキャンが完了したときに表示される、トースト形式の通知（「ローディングバブル」）が追加されたのだ。これは、単に機能が正しく動作するだけでなく、ユーザーがシステムの状態を直感的に理解し、ストレスなく利用できるような配慮の重要性を示している。

今回の改善は、システムの根幹に関わるデータ処理の層、そしてバックエンドとフロントエンド間の状態伝達という、システムエンジニアが頻繁に直面する課題を具体的な実装をもって解決した好例だ。これにより、ダッシュボードのデータは正確になり、ユーザーは自信を持って意思決定できるようになり、操作のリアルタイムフィードバックはユーザーのストレスを軽減し、運用効率も向上した。適切なレイヤーで問題を捉え、根本的な解決策を講じることの重要性を改めて教えてくれるプロジェクトと言えるだろう。