レースコンディション(競合状態)とは?同時アクセスが引き起こす、見えないバグ

レースコンディションとは何か

レースコンディション(競合状態)とは、複数の処理が、同じデータやリソースにほぼ同時にアクセスした際、実行される順序によって結果が変わってしまう現象のことです。「レース(競争)」という名前の通り、どちらの処理が先にゴールするかによって、最終的な結果が変わってしまうイメージです。

図で見る、典型的な発生パターン

言葉だけでは分かりにくいので、よく紹介される銀行口座の例で確認してみましょう。

残高が1万円しかない口座から、2つの出金処理がほぼ同時に実行されたとします。それぞれの処理は「残高を確認 → 問題なければ出金する」という手順を踏みますが、片方の処理が残高を確認した直後、まだ出金を完了する前に、もう片方の処理も同じ残高を確認してしまうと、両方とも「まだ1万円ある」と判断して出金を実行してしまいます。結果として、実際には1万円しかないはずの口座から、合計2万円が引き出されてしまうことになります。

なぜテストでは見つかりにくいのか

レースコンディションが厄介なのは、問題が表面化するために、非常に狭いタイミングの一致が必要だという点です。開発中の環境では、複数の処理が同時に集中する状況が起こりにくく、たまたま順番通りに動いてしまうため、バグが存在していても気づかれずに残ってしまいます。本番環境でアクセスが増え、同時に処理が走る頻度が上がって初めて、稀に不可解な不具合として表面化する、というパターンが典型的です。

「確認」と「実行」の間に隙がある:TOCTOU

先ほどの銀行口座の例のように、「何かを確認した時点」と「実際にそれをもとに操作を実行する時点」の間に状況が変わってしまう現象は、特に「TOCTOU(Time of Check to Time of Use)」と呼ばれる代表的なパターンです。OWASP(セキュリティに関する国際的な非営利団体)の資料でも、この種の問題が取り上げられており、悪用されるとシステムの想定外の挙動を引き起こす、セキュリティ上のリスクにもなり得るとされています。

実務で起こりやすい場面

• 在庫管理:同じ商品に対して、複数の注文がほぼ同時に入り、在庫数以上の注文を受け付けてしまう
• 予約システム:同じ座席や枠に対して、複数の利用者がほぼ同時に予約を確定させてしまう
• クーポンやポイントの利用:同じクーポンコードが、同時に複数回使用されてしまう

いずれも、「確認してから実行するまでの、ごくわずかな時間差」を突かれることで起こります。

基本的な対策の考え方

• ロック(排他制御)をかける:ある処理がデータを操作している間、他の処理が同じデータに触れられないようにする、最も基本的な対策です
• 一連の操作をひとまとまりとして扱う:確認から実行までを、途中で他の処理に割り込まれない「ひとかたまりの操作」として扱う仕組み(データベースのトランザクションなど)を活用します
• 最終的な整合性をシステム側でチェックする:念のため、操作の最後に矛盾がないかを再確認する仕組みを設けておくことも、有効な保険になります

まとめると

レースコンディションは、複数の処理が同時に動く場面で静かに潜んでいる、見えにくいバグです。開発中に再現しないからといって「存在しない」とは限らない、という点を意識しておくだけでも、設計時の注意深さが変わってきます。在庫・予約・決済など、「同時に複数人が操作しうる」機能を作る際は、特に意識しておきたい考え方です。

参考

OWASP Top 10:2021 - Next Steps(OWASP)