【ITニュース解説】I Built a Frozen-Scan Detector. A Week Later It Fires Daily — and Nothing Consumes It

システムエンジニアの仕事の一つに、大量のデータを自動的に処理し、新しい情報を生成する「データパイプライン」の構築と運用がある。データパイプラインとは、例えば株価データや商品の販売データなどを毎日自動で集め、分析し、その結果をレポートやレコメンデーションとして出力する一連の処理の流れのことだ。このパイプラインが常に最新の正確なデータを生成し続けることは、ビジネスにおいて非常に重要となる。しかし、今回紹介する事例は、このデータパイプラインが実は密かに機能不全に陥っていたという問題と、その解決策について深く考察したものだ。

ある日、とあるデータパイプラインで異常事態が発生した。このパイプラインは、毎日過去の株価データなど（記事中では「パネル」と呼ぶ）を読み込み、それに基づいて特定の技術パターンを分類し、その日の推奨銘柄などを記録するファイル（recommendations/signal_history.jsonl）に追記するというものだった。そして、翌日には前日の推奨銘柄が正しかったかを検証するログ（signal_verify_log.jsonl）も生成していた。このジョブは毎日決まった時間に実行され、ログには「exit code 0」、つまり『正常終了』が記録され続けていたため、担当者は問題なく稼働していると考えていた。しかし、実際にはシステムが提供するデータは数週間も更新されていなかったのだ。このパイプラインは、データソースである『パネル』が更新されなくなると、最新のデータがないために過去のデータを使って分析を続けてしまう。そのため、毎日同じ過去のデータを分析し、あたかも新しい結果であるかのように同じ内容をファイルに追記し続けていたのである。つまり、システム自体はエラーを吐かず正常に動作しているように見えても、出力される情報は完全に古く、凍結された（フローズン）状態だったのだ。これは、システムが動いていることと、システムが正しい情報を提供していることの間には大きな隔たりがあるということを示している。

この問題の根本は、パイプラインの『成功』を測る指標が不適切だったことにある。『ジョブが実行されたか』『正常終了したか』『何行処理されたか』『実行に要した時間』といった活動に関する指標は、データがフリーズしていても『正常』に見せてしまう。本当に測るべきは、『出力された内容そのものが変化したか』という点だ。そこで、データがフリーズしている状態を検知するためのツールが開発された。このツールの核心は、出力されるデータの『フィンガープリント』を作成することにある。フィンガープリントとは、簡単に言えばデータの特定の要素から生成されるユニークな識別子のことだ。具体的には、出力データの中から、本質的な意味を持つ部分（例えば、推奨銘柄の分類結果やピックされた銘柄など）だけを抽出し、それらの内容からハッシュ値と呼ばれる短い文字列を生成する。このハッシュ値は、元のデータが少しでも変われば全く異なる値になるため、データの変化を正確に捉えることができる。重要なのは、このフィンガープリントを生成する際に、データの生成日時や実行IDなど、内容とは関係なく実行ごとに変化するような情報は意図的に除外することだ。例えば、出力ファイルに記録される日付は毎日更新されても、その内容が常に同じであれば、それはフリーズ状態である。フィンガープリントは、そうした表面的な変化に惑わされず、データの『実質』が変化したかどうかを判断するのに役立つ。

このフリーズ検知器は、主に三つの観点からデータの異常をチェックする。一つ目は『panel_stale』、これはデータソースであるパネルのデータがいつまでのものであるかをチェックし、期待される最新の日付と比べて大幅に遅れていないかを確認する。例えば、本日が10月19日なのにパネルの最新データが9月28日のままであれば、データソースが古すぎると判断する。二つ目は『trailing_repeat』で、連続して生成された出力のフィンガープリントが何回繰り返されたかをチェックする。通常、データ分析の結果は日によって多少なりとも変化するはずなので、何日も同じフィンガープリントが続くのは異常と判断できる。記事の事例では、15回連続で同じフィンガープリントが検出されたという。三つ目は『verify_frozen』、これは検証ログの記録をチェックするもので、検証対象の日付（target_date）は進んでいるのに、検証結果の詳細が全く変わっていない場合に異常と判断する。つまり、日付は進んでいるのに、再評価しているデータが凍結されている状態を検知するのだ。これらのチェックを組み合わせることで、システムが単に動いているだけでなく、その出力内容が本当に新しく、意味のあるものであるかを多角的に判断することが可能になる。

フリーズ検知器は非常に優れたツールだが、それを導入しただけでは問題は解決しなかったという皮肉な結果が待っていた。開発者はこのツールを作り、それが毎日『FROZEN』という正しい警告を出していることを確認していた。しかし、この検知器の判定結果は、元のデータ生成パイプラインの実行に影響を与えるように組み込まれていなかったのだ。つまり、検知器は毎日『データがフリーズしている！』と叫び続けていたが、その叫びを聞いてデータ生成を止める者はいなかったのである。結果として、データ生成パイプラインはフリーズしたデータを毎日生成し続け、その横で検知器は毎日『フリーズしている』と報告し続けた。これは、警告をログに書き出すだけの『ダッシュボード』のようなものであり、実際に問題を防ぐ『事前条件（プリコンディション）』にはなっていなかった。この状況は、緑色のランプが点灯し続けるダッシュボードが、実は問題があることを隠しているよりも悪いと筆者は指摘する。真の解決策は単純明快だ。データ生成パイプラインがデータをファイルに書き込む前に、このフリーズ検知器を実行し、その結果をチェックする。もし検知器が『FROZEN』と判定したら、その日のデータ生成とファイルへの追記を完全に停止させるのだ。これにより、古くて無意味なデータがシステムに蓄積されることを未然に防ぎ、開発者は強制的に問題に気づかされることになる。

この一連の経験から、システム開発者が信頼性の高いデータ分析システムを構築・運用するために役立つ、いくつかの重要な教訓が得られた。まず、『グリーンは証拠ではない』ということだ。ジョブが正常終了しても、それが意味のある新しいデータを出力した証拠にはならない。ジョブが失敗した場合と成功した場合で、出力のどこがどう変わるのかを明確にしておく必要がある。次に、『ジョブが密かにフリーズしていたらどうなるか』という問いを常に自分に投げかけるべきだ。このシンプルな問いに答えることで、多くの信頼性に関わるバグを発見できる。三つ目は、『答えをフィンガープリントし、時刻情報を除外する』こと。データの本質的な部分だけをハッシュ化し、タイムスタンプや実行IDといった、内容とは関係なく変わる情報を排除することで、本当にデータが変わったのかを正確に判断できる。四つ目は、『入力がない場合は特別な終了コードを用意する』こと。何もチェックするデータがない場合に『正常』と報告するのは不適切で、入力不足を示す専用のエラーコードを返すことで、より健全なシステムの振る舞いを促せる。五つ目は、『同じ状態が続くことの許容範囲を明確にする』ことだ。例えば、二日連続で同じフィンガープリントが検出されるのは許容範囲内でも、十五日連続は異常と判断するなど、具体的な閾値を設けてシステムの振る舞いを監視すべきである。最後に最も重要なのは、『報告するだけでなく、ゲートする』という原則だ。警告を出すだけでなく、その警告に基づいて問題のある処理を実際に阻止する仕組みを組み込むべきである。誰も参照しない警告は無意味であり、チェックは必ずデータ生成の事前条件として機能させる必要がある。