【ITニュース解説】The Lookup That Lies: Why Your Agent’s Retry Logic Has a Hidden Race Condition

今回のITニュース記事は、システム開発における「リトライロジック」の思わぬ落とし穴について詳しく解説している。システムエンジニアを目指すなら、このような繊細な問題への理解は非常に重要だ。

アプリケーションが外部サービスに対して何らかの処理（例えば、商品の注文やイベントの予約など）を依頼し、その処理が正しく行われたかを確認する場面を想像してみよう。多くの場合、処理を依頼した直後に、その結果を確認するための問い合わせを行う。もし「見つからない」という返事が返ってきたら、アプリケーションは「処理が失敗した」と判断し、同じ処理をもう一度試みようとする。これが「リトライロジック」の基本的な考え方だ。

しかし、記事では、この素朴なリトライロジックが「重複処理」という深刻な問題を引き起こす可能性があると指摘する。本来は一度成功しているにもかかわらず、システムがそれを失敗と誤認し、同じ処理を二度実行してしまうのだ。

なぜこのような問題が起こるのか。その根源は、「書き込み成功」と「読み込み可能」が必ずしも同時に起こるわけではない、という分散システムの特性にある。多くの外部サービス、特に大規模なものは、「結果整合性（Eventually Consistent）」というモデルを採用している。これは、あるデータの変更（書き込み）が成功しても、その変更がシステム全体、特に読み込みを担当する部分にすぐに反映されるとは限らない、という考え方だ。

具体的には、データを書き込んだサーバーと、そのデータを読み出すためのサーバーが物理的に異なる場合がある。データが書き込まれると、その情報は他の読み取り用サーバーにコピー（レプリケーション）されるが、このコピー作業にはわずかながら時間がかかる。この時間差を「レプリケーションラグ」と呼ぶ。このラグは、システムの負荷やネットワーク状況によって、ミリ秒単位から数十秒、あるいはそれ以上に及ぶこともある。

つまり、アクションをディスパッチした直後に確認のための問い合わせを行うと、アクションは正しく実行されていても、その結果が読み取り用サーバーにはまだ反映されていない、という状況が起こりうる。この場合、問い合わせに対する返事は「見つからない」となる。これは、本当にアクションが失敗して何も書き込まれなかった場合と同じ返事だ。

ここで問題になるのは、アプリケーションがこの二つの状況を区別できないことだ。

1. ケースA: アクションが本当に失敗し、何も書き込まれなかった。
2. ケースB: アクションは成功したが、読み取りサーバーにまだ反映されていない。

どちらの場合も、アプリケーションは「見つからない」という応答を受け取る。素朴なリトライロジックは、この「見つからない」を常にケースAとみなし、「失敗したから再試行しよう」と判断してしまう。しかし、ケースBの場合は、すでに成功している処理を再度実行することになり、結果として重複処理が発生してしまうわけだ。

この問題を解決するために記事が提案するのは、「最小経過時間ゲート（Minimum Age Gate）」という考え方だ。これは、「整合性ウィンドウ（Consistency Window）」と呼ばれる一定の待機期間を設けることで実現する。整合性ウィンドウとは、アクションが実行されてから、その結果が確実に読み取り可能になるまでに必要だと考えられる時間の長さだ。

具体的な実装としては、各アクションの実行レコードに「このアクションの確認が可能になる時刻」を記録するフィールドを追加する。この時刻は、「アクションが実行された時刻」に「整合性ウィンドウの長さ」を加算したものだ。そして、確認処理（reconciliation）を行う際には、まず現在時刻がこの「確認可能になる時刻」を過ぎているかを確認する。もし、まだ整合性ウィンドウ内であれば、たとえ「見つからない」という返事が返ってきても、それを「失敗」とは断定せず、単に「まだ確認するには早すぎる」と判断して、そのアクションの確認を先送りする。

この仕組みにより、「整合性ウィンドウを過ぎた後でも見つからない」場合にのみ、「本当に失敗した」と判断し、リトライ処理に進むことができるようになる。つまり、誤って成功した処理を失敗とみなし、重複させてしまうリスクを大幅に減らせるわけだ。

整合性ウィンドウの具体的な期間は、外部サービスごとに異なる。最も理想的なのは、サービス提供者がその「レプリケーションラグ」や「整合性保証」の情報をドキュメントで公開している場合だ。その情報を基に、適切な期間を設定する。しかし、多くのサービスではこのような情報が明確に示されていないことも多い。その場合は、実際にテストを行い、何度かアクションを実行して、その結果が読み取り可能になるまでの平均的な時間や最大時間を計測し、安全側に倒した期間を設定する必要がある。例えば、テストでほとんどの場合5秒以内に反映されるとしても、負荷が高い状況を考慮して10秒や30秒といった長めの期間を設定するのが賢明だ。

また、記事は「遅延確認の競合（Late Confirmation Race）」という関連する問題にも触れている。これは、アプリケーションがアクションを「失敗」と判断し、代替のアクションをキューに入れた後に、当初のアクションが実は成功していたという遅延した通知が届くケースだ。このような状況では、代替アクションを実行する直前に、現在の状態を再度確認するステップが不可欠となる。もし、すでに元の処理が成功していたことが確認されていれば、代替アクションの実行をキャンセルしなければならない。代替アクションを「スケジュールした時点」での状態だけでなく、「実際に実行する時点」での状態を確認することが重要だ。

これらの考慮事項を盛り込んだ状態遷移モデルでは、「PENDING（処理中）」の状態に加えて、「DENIED_UNRESOLVED（まだ解決できない不確実な失敗）」という状態が導入される。これは、整合性ウィンドウ内での「見つからない」はまだ「失敗」と断定できないことを示し、ウィンドウが閉じた後に再度確認が必要であることを意味する。

結論として、システムが外部サービスと連携する際には、時間の概念、特に「処理が完了した時刻」と「その結果がシステム全体で利用可能になる時刻」との間のギャップを常に意識することが極めて重要だ。この「整合性ウィンドウ」という概念をコード内に明示的に定義し、システム設計の一部として組み込むことで、見えない仮定に起因する重複処理のようなバグを防ぐことができる。異なるシステム間における「時間の流れ」の違いを理解し、適切に同期させることが、堅牢なシステムを構築するための鍵となるのだ。