【ITニュース解説】Propagating Deadlines from VIN Form Submit to NHTSA Proxy Without Orphaned Work

VINフォームとは、車両識別番号（VIN）を入力するウェブ上の入力欄のことだ。ユーザーがこのVINを入力して送信すると、そのVINに対応する車の詳細情報を取得するため、NHTSA（米国道路交通安全局）のような外部のデータベースへ問い合わせが行われる。この問い合わせは直接ではなく、「BFF（Backend for Frontend）」と呼ばれる中間サーバーや、「プロキシ（代理）」サーバーを介して行われることが多い。BFFは、フロントエンドからのリクエストを受け取り、複数のバックエンドサービスに問い合わせを行い、その結果をフロントエンドにまとめて返す役割を担う。プロキシは、特定の外部サービスへの通信を代理する役割を持つ。

本記事の主なテーマは、「デッドライン（期限）の伝播」という考え方を用いて、「孤立した作業」という問題を防ぐ方法を解説している。孤立した作業とは、ユーザーがウェブサイト上で何らかの操作を中止したり、新しい操作を開始したりしたにもかかわらず、裏側で、もはやユーザーには不要な処理がシステム内で実行され続けてしまう状況を指す。具体的には、VINフォームにVINを入力して送信した後、ユーザーが別のページに移動してしまったり、ウェブブラウザ側でタイムアウトが発生してしまったり、あるいは新しいVINを入力して再送信してしまったりするケースがこれに該当する。このような場合、ユーザーは最初のVIN検索結果を必要としていないが、サーバー側のプロキシは、クライアントからのリクエストが中断されたことを知らずに、NHTSAへの問い合わせを続け、応答を待ち続けてしまうことがある。

この孤立した作業は、いくつかの問題を引き起こす。最も直接的なのは、無駄なリソース消費だ。NHTSAのような外部サービスへのAPIコールには、しばしば利用回数や速度の制限（クォータ）が設けられている。ユーザーが結果を必要としていないのに問い合わせが続くと、貴重なクォータが無駄に消費されてしまう。これはコスト増につながるだけでなく、本当に必要なユーザーのリクエストを処理するためのリソース不足を招く。また、不必要な処理がバックエンドで走り続けることは、サーバーの負荷を不必要に高め、システムの応答性や安定性にも悪影響を及ぼす可能性がある。

この孤立した作業を防ぐ解決策は、「デッドラインの伝播」と、JavaScriptのAbortSignalという技術的な仕組みを利用することだ。デッドラインの伝播とは、ユーザーがリクエストを送信した時点で、「このリクエストに対する処理は〇秒以内に完了しなければならない」という期限を定め、その期限情報、または期限が過ぎたときに処理を中止する合図を、システムの各層（フロントエンド、BFF、プロキシ）にわたって伝達していくことを意味する。

具体的な仕組みは次のようになる。まず、フロントエンド（ウェブブラウザ）でユーザーがVINフォームを送信した際に、その処理に対する「期限」を設定し、同時にAbortControllerというオブジェクトを作成する。このAbortControllerは、関連する処理を途中で中止するための信号（AbortSignal）を生成する役割を果たす。例えば、「このVIN検索は8秒以内に終わらなければならない」という期限を設定し、8秒経ったらAbortControllerを通じて処理中止の信号を発行するようにタイマーを設定する。また、ユーザーがページを離れたり、新しいVINを送信して前のリクエストが不要になったりした場合も、このAbortControllerを使って処理中止の信号を発行する。この中止信号は、フロントエンドからBFFへのHTTPリクエストに含めて送られる。

次に、BFFは、クライアントから受け取った中止信号を「信頼できる」情報として扱う。つまり、クライアントがもう結果を求めていないと分かったら、それ以上先の処理を進めるべきではないと判断する。BFFは、クライアントからの信号に加えて、BFF自身が動作しているサーバーレス環境での「残り時間」（予算）も考慮に入れる。サーバーレス関数には実行時間の制限がある場合が多く、その残り時間が少なくなった場合も処理を中止する必要があるためだ。BFFは、クライアントからの信号と、サーバーレス環境の残り時間に関する信号を結合し、どちらか一方でも処理を中止すべき状況になったら、結合された信号が中止を指示するようにする。この結合された中止信号は、BFFからNHTSAプロキシへの問い合わせリクエストに含めて送られる。

最後に、NHTSAプロキシは、BFFから受け取った結合された中止信号を監視しながらNHTSAへの問い合わせ処理を実行する。もし中止信号が発せられたら、プロキシは即座にNHTSAへの問い合わせを中止し、エラーを返す。このように、フロントエンドで生まれた「この処理はもう不要だ」という意思が、BFFを経て、最終的な外部サービスへの問い合わせまで「伝播」していくことで、孤立した作業の発生を根本から防ぐことができるのだ。

このデッドラインの伝播は、運用面でも重要な意味を持つ。まず、外部APIの利用クォータを無駄に消費せずに済むため、コスト削減に直結する。次に、不要なバックエンド処理を早期に中断することで、サーバーやデータベースへの負荷を軽減し、システムの安定性とスケーラビリティを高める。また、ログや監視において、「ユーザーによってキャンセルされたリクエスト」「デッドラインを超過したリクエスト」「新しいリクエストに置き換えられたリクエスト」といった具体的な中止理由を記録できるようになる。これにより、システムのパフォーマンスやユーザーの行動パターンをより正確に分析し、改善につなげることが可能になる。例えば、キャンセル率が高い場合は、UIの応答性を改善したり、デッドラインの設定を見直したりする必要があるといった洞察が得られる。

開発者が陥りがちな誤解や、避けるべき「禁断のアップグレード」についても触れられている。例えば、「クライアントがキャンセルしても、分析のためにバックエンドで最後まで処理を続ける」という要求は避けるべきだ。これは、正確なデータを得られないだけでなく、リソースの無駄遣いになる。また、キャンセル後に部分的なデータを返してあたかも成功したかのように見せかけることや、キャンセルを理由に自動的にリトライを誘発することも適切ではない。これらは問題の本質を隠蔽し、不正確なメトリクスを生み出し、システムの健全性を損なう可能性があるからだ。

むしろ、システムの運用においては、「ユーザーによるキャンセル」「デッドライン超過」「新しいリクエストへの置き換え」といった明確な理由ごとに測定値を分離し、ログに記録することが推奨される。これにより、システムが現在どのような状況にあるのか、正直かつ正確に把握できる。例えば、中止されたにもかかわらずバックエンドで処理が続いているような状態が増加した場合に、新しいリクエストの受け付けを停止するような機能（キルスイッチ）を設けることも、システムの安定性を保つ上で有効な手段となる。

このデッドラインの伝播の仕組みは、システムの可用性や信頼性を高める他の技術とは目的が異なる。デッドラインの伝播は、「ユーザーが結果を必要としなくなったときに、不要な作業を速やかに中止させる」という明確な目標に特化している。

まとめると、デッドラインの伝播は、フロントエンドでのユーザー操作によるキャンセルを、NHTSAへのプロキシコールを含むバックエンドの処理全体にわたって有効にする強力なメカニズムだ。これにより、クライアント側のタイムアウトや、新しいリクエストによる古いリクエストの置き換えが発生しても、不要な処理が実行されることを防ぎ、限られたリソースの無駄な消費を抑えることができる。AbortControllerをリクエストの起点で作成し、その信号をBFF経由でプロキシに渡し、サーバーレス環境の予算信号と結合することで、ユーザーが関心を失った瞬間に、バックエンドでの不要な作業を停止させることが可能になる。