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

システム開発において、異なるシステム間で情報交換を行う際に利用されるのがAPI（Application Programming Interface）である。APIを通じて、私たちは他のシステムが提供する様々な機能を利用できる。しかし、ネットワークの不安定さや相手方システムの不調など、APIの利用中にエラーが発生することは避けられない。このような場合、システムの安定性を保つために「リトライ（再試行）」という仕組みが導入されることが多い。これは、エラーが一時的なものであると判断し、一定時間をおいてから再度同じ処理を試みることで、成功に導くことを目的としている。

しかし、今回紹介する事例は、このリトライ処理が意図せず、システムに無駄な負荷をかけ、コストを増大させてしまったケースである。とあるシステムでは、大量の在庫アイテム情報を外部のカタログAPIに登録する処理を行っていた。その中で、特定のアイテム、例えば「A-9931」の登録を試みた際に、APIサーバーから「404 Not Found」というエラー応答が返ってきた。これは「指定されたリソース（アイテムA-9931）が見つかりません」という意味である。

通常、システムがエラーを受け取った際、そのエラーが一時的なものであれば、少し待ってから再試行することで解決する可能性がある。このシステムも、エラーが発生すると自動的にリトライする設定になっていた。しかし、その結果は次の通りだった。ログには、最初にPUTリクエストを送信して「404」を受け取った後、さらに3回のリトライが実行され、合計4回の同じリクエストがすべて「404 Not Found」を返していた。最終的にシステムは、そのアイテムの処理を諦め、次のアイテムへと進んだ。

この一連の動きは、システムが受け取った「404 Not Found」という情報を正しく解釈できていなかったことを示している。なぜなら、「404 Not Found」というエラーは、指定されたリソースが存在しないことを意味し、これは通常、時間経過によって自然に解決する性質のものではないからだ。例えば、すでに廃盤になった商品や、データが完全に削除されたアイテムであれば、いくら時間を置いたり、何度リクエストを試みたりしても、そのアイテムが存在するようになることはない。

このシステムでは、4,800個もの在庫アイテムを処理していたが、そのほとんどは問題なく登録できた。しかし、一部のアイテムについてはエラーが発生した。これらのエラーは大きく二種類に分類できる。一つは「4xx系」と呼ばれるエラーで、これはクライアント（リクエストを送信したシステム）側に原因があるか、サーバー側のリソースの状態が永続的に変わらないことを示すものだ。具体的には、404（アイテムが存在しない、削除された）や400（リクエストの形式や内容が不正）などがこれに当たる。これらのエラーは、リクエスト内容や対象リソースが根本的に変わらない限り、何度試しても結果は同じとなる。もう一つは「5xx系」と呼ばれるエラーで、これはサーバー側に一時的な問題が発生していることを示すものだ。例えば、サーバーが一時的にダウンしていたり、データベースへの接続に失敗したりといったケースである。また、APIの利用制限（クォータ）を超過した際に返される「スロットリングエラー」も、一定の時間経過によって状況が改善する可能性がある。

問題は、このシステム全体が「HTTPステータスコードが200番台（成功）以外であれば、すべて一時的な問題とみなし、決められた回数だけリトライする」という一律のポリシーで設計されていたことにある。このため、A-9931のような、もはや存在しないアイテムに対しても、最初の1回のリクエストに加えて3回のリトライが無駄に実行され、合計4回のリクエストが浪費された。

APIの利用には、多くの場合「クォータ」と呼ばれる利用上限が設定されている。これは、一定時間内に実行できるリクエストの数を制限するもので、この上限を超えると、追加のリクエストは受け付けられなくなるか、追加料金が発生することがある。今回のケースでは、存在しないアイテムに対して繰り返された無駄なリトライが、この貴重なAPIクォータを消費し続けていた。

この問題は、APIクォータの使用状況を示すダッシュボードで異常な消費ペースが観測されたことで発覚した。実際の作業量と比較して、クォータの消費があまりにも速く、最終的には高額な請求書が問題を浮き彫りにしたのである。

このインシデントから得られた重要な教訓は、「リトライは未来への主張である」という点だ。つまり、リトライするということは「今回の失敗は一時的なもので、次回は成功する可能性がある」と予測することに他ならない。

例えば、500番台のエラーであれば、サーバーが再起動したり、一時的な高負荷が解消されたりすれば、次に試したときに成功する可能性は十分にある。スロットリングエラーも、一定時間待てば利用制限がリセットされ、再度リクエストが通るようになるだろう。これらのケースでは、リトライは有効な戦略である。

しかし、404エラーの場合、リトライは「倉庫が自動的に在庫を補充してくれる」と主張しているようなものである。また、400エラーの場合には「リクエストの内容が自動的に修正される」と主張していることになる。これらは現実的にはありえない。アイテムが削除されたのであれば、存在しないことに変わりはないし、リクエストのデータ形式が間違っていれば、同じリクエストを何度送っても正しくなることはない。このようなエラーに対するリトライは、何も得られることなく、ただAPIクォータを消費するだけの無駄な行為である。

この問題への対処として、開発チームは「分類器（classifier）」を導入することを決定した。これは、APIから返されるHTTPステータスコードの種類を分析し、そのエラーが自己回復する可能性のある一時的なものなのか、それとも永続的なものでリトライしても無駄なのかを判断する仕組みである。

最初の改良では、5xx系のエラー、つまりサーバー側に起因する一時的なエラーのみをリトライの対象とし、それ以外のエラー（主に4xx系）についてはリトライをせずにすぐに処理を中断するように変更された。これにより、無駄なリクエストが大幅に削減され、APIクォータの浪費が防がれるようになった。

この事例は、システム設計において、エラー処理、特にリトライポリシーを深く考慮することの重要性を示している。一見、システムの堅牢性を高めるためのシンプルな設定に見えても、その背後にあるエラーの種類や性質を理解せずに適用すると、かえって無駄なリソース消費やコスト増大につながる可能性があるのだ。システムエンジニアを目指す上では、このようにエラーの種類とその意味を正確に理解し、状況に応じた適切な処理を設計する能力が求められる。単に「エラーだからリトライ」と安易に考えるのではなく、エラーの「質」を見極める視点を持つことが、効率的で信頼性の高いシステム構築につながるのである。