WebアプリをDockerやKubernetes上にデプロイすると、Podをスケールアウトして同時に複数ユーザーを処理できるようになります。
しかしここでよくある疑問が、

「もしPod AとPod Bが同じデータベースの同じレコードを同時に更新したらどうなるの？」

という問題です。今回はこの仕組みについて解説します。

1. 誰が競合を解決するのか？

結論から言うと、最終的に競合を処理するのはデータベースです。

2. データベースの仕組み

データベースには、複数のクライアント（Podなど）が同時に書き込みをしても矛盾が生じないようにするための仕組みがあります。

代表的なものは次の通りです（PostgreSQL/MySQL）。

Rails（ActiveRecord）には、DBが返すエラーをうまく処理する仕組みがあります。

「どうせ競合するなら最初からロックしてしまえ」という考え方。

user = User.lock.find(1) # SELECT ... FOR UPDATE が発行される
user.update!(balance: user.balance - 100)

この場合、他のPodが同じユーザーを更新しようとすると、処理が終わるまで待たされます。

「そんなに頻繁に競合しないはず。競合したらその時考えよう」という考え方。

ActiveRecordに lock_version カラムを追加すると、自動的に楽観的ロックが有効になります。

user = User.find(1)
user.update!(balance: user.balance - 100)

もし別のPodが先に同じ行を更新していた場合、Railsは ActiveRecord::StaleObjectError を発生させます。
これを捕まえてリトライ処理を入れるのが一般的です。

競合エラーが発生した場合に「もう一度やり直す」仕組みを入れておくと安定します。

begin
  user = User.find(1)
  user.update!(balance: user.balance - 100)
rescue ActiveRecord::StaleObjectError
  retry
end

KubernetesでPodを増やすとアプリはスケーラブルになりますが、データの整合性はDBに任せるのが大原則です。
その上で、Railsアプリは 「競合が起きたときにどう振る舞うか」 を設計する必要があります。

つまり、

この役割分担を理解しておくと、Kubernetesでのアプリ運用がぐっと安心になります。