【ITニュース解説】pkg-topic-detective-noir-推理链的黑箱拆解-1786976029-1

あるシステムでAPI（アプリケーションプログラミングインターフェース）を呼び出す際に、想定外のトラブルが発生した。具体的には、APIの利用量を示すクォータが予想以上に早く消費されてしまったのである。この問題の原因は、プログラムがエラー発生時に自動的に再試行（リトライ）する機能に隠されていた。

事の発端は、商品の在庫情報をカタログAPIに同期する処理で生じた。システムが4800個の在庫アイテムをAPIに送信する際、ほとんどのアイテムは正常に処理され、ステータスコード200（成功）が返された。しかし、一部のアイテムについてはエラーが発生した。

特に問題となったのは、ログに次のような記録が残っていたケースである。 14:03:12] sync start target=inventory, items=4800 [14:03:12] PUT /items/A-9931 → 404 [14:03:12] retry 1/3 [14:03:12] PUT /items/A-9931 → 404 [14:03:12] retry 2/3 [14:03:12] PUT /items/A-9931 → 404 [14:03:12] retry 3/3 [14:03:12] PUT /items/A-9931 → 404 [14:03:13] give up, next item

このログは、システムが「A-9931」というアイテムを登録しようとPUTリクエストを送信したが、APIサーバーから404エラー（Not Found、つまりそのアイテムが見つからない）が返されたことを示している。システムはエラーを受け取ると、設定された回数（ここでは3回）だけ自動的にリトライを繰り返した。しかし、3回の再試行すべてで同じく404エラーが返され、結局システムはそのアイテムの処理を諦め、次のアイテムへと進んだ。

この一連の動作には大きな問題が潜んでいた。404エラーは「指定されたリソースが存在しない」ことを意味する。これは通常、一時的な問題ではなく、永続的な状態を示す。例えば、廃盤になった商品や、データが削除された商品など、存在しないものを何度リクエストしても、結果が変わることはない。にもかかわらず、システムは同じエラーに対して合計4回（初回と3回のリトライ）もAPIを呼び出してしまったのだ。これにより、APIの利用クォータが無駄に消費され続けた。

エラーの種類は大きく二つに分けられる。一つは、404（リソースなし）や400（不正なリクエスト）のように、クライアント側のデータやリクエスト内容に問題があり、時間をおいても状況が変わらないエラーである。もう一つは、5xx系（サーバー内部エラー）やAPIのスロットル（利用制限超過）のように、サーバー側の一時的な問題や混雑によるエラーで、時間をおけば解決する可能性があるエラーである。本来、リトライは後者のような一時的なエラーに対して行われるべき処理だ。データベースの再起動、負荷分散装置の回復、ネットワークの一時的な問題など、サーバー側の問題は時間とともに解決することが多い。また、APIのスロットルも、一定時間待てば利用制限がリセットされるため、リトライに意味がある。

しかし、このシステムでは「非2xxステータスコードであればすべて一時的なエラーとみなし、リトライする」という画一的なポリシーが適用されていた。これは一見するとシステムの堅牢性を高めるように思えるが、実際には問題の本質を見落としていた。404エラーや400エラーに対してリトライをすることは、「存在しないものが突然現れる」とか、「不正なデータが勝手に正しい形に変わる」といった、現実にはありえない未来を主張していることになる。このような無意味なリトライは、APIクォータを浪費するだけでなく、システムリソースや時間も無駄にする。

今回のインシデントは、APIクォータの消費率が実際の作業量と一致しないことに担当者が気づいたことで発覚した。請求書がアラート代わりとなり、その日のうちに修正作業が始まった。

この問題の根本的な解決策は、リトライの判断基準をより賢くすることだった。単純に「エラーであればリトライ」ではなく、「このエラーは時間とともに解決する可能性があるか？」という問いを立て、ステータスコードの種類によってリトライするか否かを分類する仕組みを導入したのである。

具体的には、最初に実装された修正案では、5xx系のサーバーエラーに対してのみリトライを行い、それ以外のエラー（特に4xx系）については即座にリトライをスキップするという方針が取られた。これにより、永続的なエラーに対する無駄なAPIコールを防ぎ、クォータの浪費を大幅に削減することが可能になる。システムが賢くエラーの種類を判断し、適切な対応を取ることで、より効率的で安定した運用が実現できるようになったのだ。