【要約】「接続できている」と「値が来ている」は別物 — ヘルスチェックを2状態から3状態にした話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が外部データ取得アプリの監視機能を実装した際、エラーログが出ないにもかかわらず、特定の時間帯に「不通」と誤表示される問題に直面した。原因は、接続判定のロジックがドメインの性質を捉えきれていなかったことにある。
- ・判定条件に
value > 0を使用したため、値が0であることが正常なケースを「接続不可」と誤認した。 - ・「接続の成否」と「データの有無」という異なる概念を、単一の真偽値に集約してしまった。
- ・これにより、正常な稼働状態が障害として報告される事態を招いた。
// Approach
開発者は、接続状態とデータの有無を分離し、状態を3つに定義する設計へと変更した。これにより、接続は維持されているがデータがまだ届いていない状態を明示的に扱えるようにした。
- ・状態を
ready（受信中）、waiting（接続済み・待機中）、down（不通）の3段階に定義した。 - ・接続の証拠として、当日の値ではなく、必ず存在する「前日値（baseline）」などのメタ情報を参照した。
- ・状態の不整合を防ぐため、
Readingクラスを用いて1回の取得で全情報を取得する設計とした。 - ・
time.monotonic()を用いたキャッシュデコレータにより、監視負荷を抑制した。
// Result
判定ロジックの改善により、値が0となる正常な時間帯でも誤検知が発生しなくなった。運用面と実装面の両方で具体的な改善が見られる。
- ・ユーザーに対し、「接続は生きているがデータ待ちである」ことを
waiting状態として正確に提示可能になった。 - ・
Literal型の活用により、呼び出し側での誤った2値判定を型レベルで防止した。 - ・キャッシュ導入により、外部プロセスへの問い合わせ頻度を低減し、システム負荷を抑えた。
Senior Engineer Insight
> 監視設計における「意味論的な誤り」を突いた良記事である。単なるエラーハンドリングではなく、ドメイン知識を型と状態遷移に落とし込んでいる点が実戦的だ。特に、
waiting という中間状態を設けることで、運用者の心理的負荷を軽減している。スケーラビリティの観点でも、キャッシュによる負荷抑制が考慮されており、即戦力の知見と言える。