50回目の外部通信がHEADの失敗確認に当たったら、次回も同じURLをHEADから調べるべきでしょうか。
公開されたWebサーバ監視botを読んだとき、私が注目したのは、この境界で止まっても監視を飛ばさない仕組みでした。
このBotは1日1回程度の生存確認に絞り、Cloudflare Workers Freeの範囲で新しいDOWNだけをDiscordへ通知します。
予算0円と平常時の消費最小化を先に決めると、構成と状態はどこまで減らせるのでしょうか。
一つのAlarmへ監視を集める
DiscordのコマンドはGatewayの常時接続ではなく、HTTP Interactionsで受けます。
Discordの公式資料でも両方式は排他的で、HTTP方式には接続を維持するプロセスが要りません。
登録情報と定期処理は、固定名globalから得る一つのSQLite-backed Durable Objectへ集約します。
Durable Object Alarmは一つのObjectにつき一度に一つだけ設定でき、保存した予定を処理して次回を予約できます。
この用途では、監視先ごとのCronも定期処理を分配するQueuesも要りません。
D1を別に置かずObject内のSQLiteへ寄せるため、コマンドとAlarmが同じ状態を扱えます。
履歴集計も並列配送も求めないので、その役割を持つサービスを構成へ入れません。
監視先がゼロならAlarmも削除され、定期処理自体がなくなります。
外部通信の回数で区切る
Workers Freeの現行上限では、外部subrequestは1回のinvocationにつき50です。
実装は監視先を固定件数で分けず、fetchの直前にbudgetを一つずつ消費します。
正常なURLはHEADだけなので1 requestです。
HEADが失敗した候補だけRange付きGETで確認するため2 requestsになり、両方が失敗した新しいDOWNだけDiscord通知を加えて3 requestsになります。
redirectをmanualにするのは、自動redirectも上限へ数えられ、コード上のfetch回数と実消費がずれるためです。
50件すべてが正常なら、一つのAlarmで終わります。
49件の正常確認後に50回目のHEADが失敗すると、対象IDとconfirmを保存し、次回はGETから再開します。
48件の後でHEADとGETが失敗し、通知前に上限へ達した場合はnotifyから再開します。
消費済みの段階を繰り返さないため、監視を飛ばさず50 requestsを使い切れます。
正常履歴を持たない状態遷移
監視tableが障害について持つ状態はdown_notifiedだけです。
0は未通知、1は通知済みを表します。
正常で0なら書き込みません。
HEADとGETが失敗し、通知に成功したときだけ1へ変えます。
DOWNが続く間は再通知せず、正常応答を確認したときだけ0へ戻すため、復旧後の再DOWNは新しい通知になります。
この構成では成功率、応答時間、障害履歴を集計できません。
しかし、このBotが保存する必要のある答えは「現在のDOWNを一度知らせたか」です。
平常時の観測ではなく、その答えを変える一つのフラグだけを残します。
外部入力と再試行の境界
通信を減らしても、公開endpointと任意URLへのfetchの検査は削れません。
実装はDiscordのtimestampとraw bodyをEd25519署名で検証し、利用者とBotの権限を確認します。
通知ではmentionを無効にし、monitor名をescapeします。
Discord通知にはmonitor ID由来のnonceとenforce_nonceを付けます。
429ではDiscordのRate Limits資料に従ってRetry-Afterを読み、notifyを保持してAlarmを予約し直します。
登録URLはHTTPまたはHTTPSに限り、credential、localhost、literal private address、link-local、multicastなどを拒否します。
ただし、DNS解決後のprivate address判定はないため、完全なSSRF防御とは呼べません。
資格情報はリポジトリへ置かず、deploy後にCloudflare secretとして設定します。
私は2026年8月19日に現行commitでnpm run checkを実行し、型検査と45 testsが通ることを確認しました。
Workers Vitest integrationでSQLite-backed Durable ObjectとAlarmを動かし、50件と51件、confirmとnotify、DOWNから復旧して再DOWNする遷移、429、署名、権限、URL制限を検査しています。
平常時に不要な通信と状態を持たず、失敗候補が現れた瞬間だけGET、通知、継続状態を増やす。
その限定を受け入れられる低頻度監視では、予算0円という制約が、残す状態と再開位置まで決めています。
コメント