/yuta25/Rails におけるレースコンディション

generated at 2/17/2025, 3:59:07 AM
Rails におけるレースコンディション
原文 Race Conditions on Rails

あなたがECシステムの支払い処理システムを実装していて、複数の顧客が全く同じ注文に対して二重に請求されていることを発見したと想像してみてください。...それは悪夢のようです。そして次の日には、ユーザーがクレジットカードを使わずに特別なクレジットを使って支払うことができたクレジットシステムに何かが正しくないことに気がつきました。そして、さらに最悪なことに、あなたが追加した一意性のバリデーションが全く機能していないことが判明し、今では同じメールアドレスを持つ3人のユーザーがいることが判明しました！

うまくいけば、このような悲惨な現実が避けられないわけではありません。このような厄介な問題を回避するためには、潜在的なレースコンディションに注意を払い、それが起こりうる状況を理解し、どのような防御策を講じることができるのかを理解する必要があります。

レースコンディションってなんですか

レースコンディションとは、コードの並列実行が、それらを直列実行する場合と比べて負の結果が引き起こされる望ましくない状況のことです。スレッドの扱いに慣れていると、レースコンディションは日常茶飯事のように聞こえるかもしれません。しかし、同じアプリケーションの複数のプロセスを実行しているときにも、レースコンディションは起こりやすいのです。一見すると直感的ではないように思えるかもしれませんが、ほとんどの場合、プロセス間で共有されているコンポーネントがあることを覚えておいてください。Ruby on Railsアプリケーションでは、ほとんどの場合、それはデータベースになるでしょう。

ここでは、いくつかの一般的なレースコンディションのシナリオとそれに対する防御策を見てみましょう。

マルチスレッドサーバーとグローバル変数

グローバル変数は良いアイデアではないという言説は、いたってありふれてるものです。しかし、マルチスレッド環境で運用する場合、グローバル変数の問題はかなり深刻になります。Railsアプリの注目すべき例としては、Puma Webサーバが挙げられます。デフォルトでは、すべてのPumaインスタンスは最大5スレッドを使用します。このアプローチには確かに大きなメリットがあります。一方で、注意を怠るとグローバル変数を使ったレースコンディションに簡単にさらされる可能性があります。

カレントユーザのIPを入れるグローバル変数というアンチパターンを見てみましょう。このパターンを実装する「創造的な」方法の一つは、クラスレベルの属性リーダとライタに  User.current_ip  と  User.current_ip=  メソッドを持たせることです。

rbclass User < ApplicationRecord
  @@current_ip = nil

  def self.current_ip
    @@current_ip
  end

  def self.current_ip=(ip)
    @@current_ip ||= ip
  end
end

 User.current_ip  がコントローラのアクションごとに  ApplicationController  に設定されていて、後から書き込みアクションを行う際に保持されるとしましょう。

監査ログを作成するという当初の考えは良いものでしたが、もしこのような実装を採用することになった場合、 間違った IP アドレスが保持されてしまっても驚かないようにしましょう。しかし、実際の問題は何でしょうか？

クラス変数としてのグローバル変数は、同じプロセス内のすべてのスレッドで共有されます。5 つのスレッドを持つ単一の Puma ワーカーがあり、ほぼ同時に 2 つのリクエストがあったと想像してみてください。ユーザーAがパスワードを変更することにしました。新しいパスワードを入力して save ボタンをクリックした。仮説的な  UsersController#update  アクションが実行され、適切な IP が設定されました。ほぼ同時期に、ユーザーBがあるページにアクセスし、再びIPアドレスが設定されます。パスワードの変更は、`User.current_ip= とともに保持されます。

このような場合、ユーザBがユーザAのIPアドレスを変更したように見えますが、その変更のために保存されるのは彼ら2人のIPアドレスかもしれません。これは、グローバル変数を使用する場合に起こりやすい典型的なレースコンディションです。

レースコンディションのリスクなしにグローバル変数を使用することはできないということでしょうか？

もし本当にグローバル変数が唯一の方法であるならば（ヒント: 普通はそんなことありません）、スレッドローカル変数を使用することができます。これは、値を読み込んだり設定したりするためのハッシュのようなメソッドを公開しているので、とても便利に使えます。

rbclass User < ApplicationRecord
  def self.current_ip
    Thread.current[:current_ip]
  end

  def self.current_ip=(ip)
    Thread.current[:current_ip] = ip
  end
end

こうすれば、グローバル変数を使ってもレースコンディションを防ぐことができます（醜いコード防ぐことはできませんが）。

データベースの制約が足りない

典型的な例として、サインアッププロセスを見てみましょう。ユーザーにメール、パスワード、パスワードの確認を求め、 sign up  ボタンをクリックしてサインアップさせます。同じメールアドレスで複数のユーザーレコードを持つことは避けたいので、一意性のバリデーションを追加します。

rbclass User < ApplicationRecord
  validates :email, uniqueness: true
end

あるユーザーが連続して3回ボタンを素早くクリックした場合に何が起こるか心当たりはありませんか？3つのレコードが作成される可能性が高く、一意性のバリデーションはなんの仕事もしません。

ここで理解しておくべき重要なことは、一意性のバリデーションは一意性を保証するものではなく、どちらかというとレースコンディションがない場合に有用なバリデーションエラーを表示するためのものであるということです。ボタンを素早く3回連続でクリックすると、次のようなシナリオが発生する可能性が高いです。

リクエスト1 - ユーザーが存在するかどうかをチェックし、そのメールアドレスを持つユーザーが見つからないので、次に進みます。
リクエスト2 - ユーザーが存在するかどうかをチェックし、そのメールアドレスを持つユーザーが見つからないので、次に進みます。
リクエスト3 - ユーザーが存在するかどうかをチェックし、そのメールアドレスを持つユーザーが見つからないので、次に進みます。
リクエスト1 - データベースにデータを挿入するコードに到達します。新しいユーザーレコードが作成されます。
リクエスト 2 - データベースにデータを挿入するコードを確認します。新しいユーザーレコードが作成されます。
リクエスト 3 - データベースにデータを挿入するコードに到達します。新しいユーザーレコードが作成されます。

すべてのシナリオでこの種のレースコンディションから身を守る唯一の方法は、データベースレベルで一意のインデックスを追加することです。あるいは、勧告的ロックを使用してコードの同時実行を防ぐこともできます (これについては記事の後半で説明します)。

この問題のもう一つのバリエーションは、レースコンディションによって引き起こされる可能性があると同時に、適切なデータベース制約の欠如が問題となっています。旅行者Aが2021年6月3日から2021年6月10日までの間の滞在を予約したいとし、旅行者Bが2021年6月2日から2021年6月7日までの間の滞在を予約したいとし、ほぼ同時に予約を作成した場合を想像してみてください - 日付が利用可能かどうかをチェックするバリデーションは、データの整合性の限りでは無意味です。

この問題を解決するには、データベースレベルで処理する必要があります。この特定の例では、PostgreSQLの  tsrange  を利用することができます。日付範囲の一意性を保証する典型的な例は以下のようになります。

sqlALTER TABLE reservations ADD CONSTRAINT no_overlapping_reservations EXCLUDE  USING gist(property_id WITH =, tsrange(start_at, end_at, '[)') WITH &&);

悲観的ロック

記事の冒頭の例に戻りましょう。あなたのECシステムでは、クレジットカードで支払うか、ユーザーが追加できるプリペイドクレジットで支払うことができると想像してみてください。ある仮想的なユーザーが100クレジットを持っていて、合計価格が25ドルと75ドルの2つの注文の支払いにちょうど十分な金額です。興味深いことに、このユーザーはソフトウェア開発について何かを知っており、システムがいくつかの厄介なエッジケースを処理できるかどうかを確認したいと考え、ちょっとした実験をすることにしました：これらの2つの注文の支払いをほぼ同時に行い、何が起こるかを確認します。2つの注文の支払いをほぼ同時に行い、どうなるかを確認してみました。

うわ、かなりやばそうですね？コードを見てみましょう。

rbdef charge_user_for_order(user_id, order_id)
  user = User.find(user_id)
  order = Order.find(order_id)
  ActiveRecord::Base.transaction do
    user.credits -= order.price
    user.save!
    order.paid!
  end
end

ユーザーと注文を見つけて、ユーザーからクレジットを差し引き、変更を持続させ、注文を支払い済みにする方法があります。これは私たちが期待していたものですが、何か問題があるのでしょうか？

ここでの問題は、 -=  操作の結果です。両方の注文の支払い後に0になると予想していたかもしれませんが、コードを同時に実行すると、次のようなシナリオが起こる可能性が高いです。

リクエストA: ユーザーと注文をロード
リクエストB: ユーザと注文をロード
リクエストA: ユーザーのクレジットを100 - 75に設定し、変更を継続します。
リクエストB: ユーザーのクレジットを100 - 25に設定し、変更を継続します。

そして、それはまさに注文が支払われ、75クレジットが利用可能な状態で終わることになります。

幸いなことに、これを回避するのは簡単です: ActiveRecord の悲観的ロック機能とその lock！ メソッドを使用して charge_user_for_order  メソッド内で行レベルのロックを取得する必要があります。

rbdef charge_user_for_order(user_id, order_id)
  user = User.find(user_id)
  order = Order.find(order_id)
  ActiveRecord::Base.transaction do
    user.lock! # do not forget about this!
    user.credits -= order.price
    user.save!
    order.paid!
  end
end

この場合、ActiveRecord は  SELECT FOR UPDATE  クエリを実行し、他のトランザクション内でのそのレコードの変更を防止します (または、そのトランザクション内でロックされている限り、並行トランザクションが終了するまで待ちます)。また、それは内部的に（ reload メソッドで）レコードをリロードします。その方法によって、我々は確実に最新のデータを操作することができます。

勧告的ロック

コードの同時実行を防ぐ必要があることはよくありますが、ロックする必要があるのはデータベーステーブルやデータベース行ではありません。その代わりに、コードが順次実行されるように、同じプロセス内のスレッドだけでなく、複数のプロセスに適用できるRuby  Mutex のようなものが必要です。

幸いなことに、PostgresSQLは正確にこの目的のための素晴らしい機能を提供しています - 勧告的ロック。さらに、勧告的ロックの使用を簡単にするwith_advisory_lock gemがあります。

では、勧告的ロックが役に立つのはどのような場合でしょうか？Amazon S3からファイルを取得し、その内容を変更して、変更後にアップロードしなおす必要がある場合を想像してみてください。より正確には、バックグラウンドでこのロジックを処理するSidekiqワーカーがいて、コードは以下のようになっています。

rbclass S3Worker
  include Sidekiq::Worker

  def perform(*args)
    fetch_file
    modify_file
    upload_file
  end
end

このコードを5人のワーカーが同時に実行するとどうなるのでしょうか？ファイルのフェッチとアップロードがいつ行われるかによって、非常に異なる結果を得ることができますが、最終的には大きな矛盾が生じることは間違いありません。また、ジョブを1つずつ実行するのと比較して、結果は非常に異なるものになるでしょう。

このコードを5人のワーカーが同時に実行するとどうなるのでしょうか？ファイルのフェッチとアップロードがいつ行われるかによって、非常に異なる結果を得ることができますが、最終的には大きな矛盾が生じることは間違いありません。また、ジョブを1つずつ実行するのと比較して、結果は大きく異なるものになるでしょう。

これは重大な潜在的な問題のように聞こえますが、幸いなことに、勧告的ロックはコードの同時実行を簡単に防ぐことができます。with_advisory_lock gemを使うと、このようなコードになります。

rbclass S3Worker
  include Sidekiq::Worker

  def perform(*args)
    ActiveRecord::Base.with_advisory_lock("S3Worker-Lock") do
      fetch_file
      modify_file
      upload_file
     end
  end
end

 S3Worker-Lock というロックが取得されると、同じロックを取得しようとするすべてのプロセスは、既存のロックが解放されるまで待つ必要があります。このようにして、複数のプロセスを持つことによる並列性と同時に、ジョブの直列実行を保証することができます。

さらに興味深いのは、悲観的ロックを勧告的なロックに置き換えることができるということです。例えば、異なるトランザクション内で同じ行の更新が頻繁に発生し、かなりの時間がかかり、それぞれが終了を待つことが必須で、それぞれの更新は共通の更新をなにも持っていない場合があります。

これは、先ほどのクレジットの例でも当てはまるかもしれません。このようにして、行レベルのロックの代わりに勧告的ロックを使用するようにコードを書き換えることができます。

rbdef charge_user_for_order(user_id, order_id)
  ActiveRecord::Base.transaction do
    ActiveRecord::Base.with_advisory_lock("charge_user_for_order_#{user_id}_#{order_id}") do
      user = User.find(user_id)
      order = Order.find(order_id)
      user.credits -= order.price
      user.save!
      order.paid!
    end
  end
end

他のトランザクションで同じ属性を変更しない限り、悲観的ロックを使用しなくても問題ありません。しかし、 user や order の同じ属性が他の場所でも変更されていた場合、デッドロックが発生する可能性があります。

悲観的ロックの代わりに勧告的なロックを使用する際に注意すべき重要なことが一つあります - レコードを読み込む際には、コード内でレコードの reload がないので注意してください! これは、当初悲観的ロックで修正しようとしていたのと同じ問題を引き起こす可能性があります。例えば、勧告的なロックはここではほとんど意味がありません。

rbdef charge_user_for_order(user_id, order_id)
  user = User.find(user_id)
  order = Order.find(order_id)
  ActiveRecord::Base.transaction do
    ActiveRecord::Base.with_advisory_lock("charge_user_for_order_#{user_id}_#{order_id}") do
      user.credits -= order.price
      user.save!
      order.paid!
    end
  end
end

 order も user も勧告的ロックを取得する前に読み込まれているので、コードの同時実行をブロックしても、古いレコードデータに対して操作を実行してしまう可能性があります。そのため、一部のロジックだけではなく、全体のロジックの実行を勧告的ロック内でラップする必要があります。

Redlock

PostgreSQLを使わなくても、S3の操作のようなユースケースで分散ロック/ミューテックスが必要な場合はどうでしょうか？Redisを使用しているのであれば、それは問題ではありません。Redlock - 分散ロックを実装したアルゴリズム - によるソリューションを使うことができます。

redlock-rbは、Railsアプリで簡単に使えるようにしてくれるので、自分で考える必要がありません。ただし、これは少し使い方を変える必要があるので、勧告的ロックの代わりにはなりません。以下の例をチェックしてみてください。

rbredlock = Redlock::Client.new(["redis://localhost:6379"])
expiration_time_in_milliseconds = 60_000

first_lock = lock_manager.lock("S3Worker-Lock", expiration_time_in_milliseconds)
# => almost immediately returns a hash containing data about the lock
second_lock = lock_manager.lock("S3Worker-Lock", expiration_time_in_milliseconds)
# => almost immediately returns `false`

勧告的ロックを使用した場合（少なくとも  with_advisory_lock  メソッドを経由した場合、少し動作が異なる  with_advisory_lock_result  メソッドもあります）、2 番目のジョブは 1 番目のロックが解放されるまで待ってからロジックを実行することになります。Redlock の場合、2 番目のジョブはロジックを実行せずにすぐに戻ってきます。同じことを 2 回実行する必要がないので、実際にはこれが望ましい動作かもしれません。それでも、元の例と同じ動作をしたいのであれば、後でジョブを再試行するなどして、自分たちで対処する必要があります。

楽観的ロック

システムで複数のユーザーが同じレコードを操作できるようにすると、重大な問題が発生する可能性があります。例えば、誰かが決定行動をするたびに、最新のデータに基づいて行われることを保証したい場合があります。例えば、顧客への返金を行うことで、その顧客に後から購入に使用できる特別なクレジットを付与することができます。複数の人がそれを行い、ほぼ同時に返金があることを知った場合、クレジットが二重に付与されるという不幸なシナリオが発生する可能性があります。このようなケースでは、2回目の操作を許可しないことが望まれますが、これは楽観的ロックに帰着します。

これはRailsで実現するには非常に簡単なことで、モデルのテーブルに lock_version カラムを追加するだけで済み、余分な設定を追加する必要はありません。ActiveRecordは更新のたびにそれをインクリメントしてくれます。このようにして、ActiveRecord は、特定のレコードの  lock_version  が変更された場合、 ActiveRecord::StaleObjectError  を発生させてレコードの更新を阻止します。

rbuser_1_a = User.find(1)

user_1_b = User.find(1)

user_1_a.credits += 100
user_1_a.save!
# => works just fine

user_1_b.credits += 100
user_1_b.save!
# => raises ActiveRecord::StaleObjectError

まとめ

レースコンディションは、マルチスレッドコードの外であっても、それが起こる前に防がなければ、非常に恐ろしい結果を招く可能性があります。幸いなことに、いくつかの可能性のあるシナリオとそれを緩和する方法を理解することで、この種の問題を簡単に回避することができます。


#deepl