🚧
データベースの楽観ロックと悲観ロックを理解する

2025/03/08に公開
254
126
 はじめに現代のアプリケーション開発において、複数のユーザーが同時にデータにアクセスする状況は日常的です。ショッピングサイトで同じ商品を複数の顧客が同時に注文したり、チケット予約システムで同じ座席を複数の人が確保しようとしたりする場面を想像してみてください。このような状況で、データの整合性を保ちながら効率的に処理を行うことは重要な課題です。
本記事では、データベースにおける並行制御の基本概念から、トランザクションの性質、そして楽観ロックと悲観ロックという二つの主要なロック戦略について解説します。これらの知識は、スケーラブルで信頼性の高いアプリケーションを構築する上で不可欠です。
この記事は、Web アプリケーションやモバイルアプリケーションの開発者、特にデータベースを利用したバックエンド開発に携わるエンジニアを対象としています。SQL やデータベースの基本的な知識があることを前提としていますが、難解な理論や高度な実装詳細には踏み込まず、実務で活用できる知識の提供を目指しています。

 並行制御の基本
 トランザクションとは何かトランザクションとは、データベース上で実行される一連の操作をひとまとまりの処理単位として扱うメカニズムです。例えば、銀行での送金処理を考えてみましょう。送金処理は「送金元の口座から金額を引き落とす」と「送金先の口座に金額を入金する」という 2 つの操作から成り立ちます。これらの操作は必ず両方とも成功するか、あるいは両方とも実行されないかのどちらかでなければなりません。片方だけが実行されると、お金が消失したり重複したりする問題が発生します。
トランザクションは「全て成功するか、全て失敗するか」という原則で動作し、データの整合性を保護します。例えば、送金処理の途中でシステムに障害が起きた場合、トランザクションは自動的に取り消され（ロールバック）、データベースは処理前の状態に戻ります。

 並行制御が必要な理由現代のアプリケーションでは、多くの場合、複数のユーザーが同時にデータベースにアクセスします。例えば、EC サイトでは多数の顧客が同時に商品を閲覧し購入する可能性があります。このような並行アクセスがある環境では、データの整合性を保ちながら効率的に処理を行う仕組みが必要になります。
並行制御とは、複数のトランザクションが同時に実行される際に、データの整合性と一貫性を保つための仕組みです。適切な並行制御がなければ、同時に実行されるトランザクション間で予期しない干渉が起き、データ不整合が発生する可能性があります。

 並行制御がないときに起こる問題（衝突とは）並行制御なしでは、複数のトランザクションが同じデータに同時にアクセスしたときに次のような問題が発生します。
ダーティリード（Dirty Read）: あるトランザクションが変更したがまだコミット（確定）していないデータを別のトランザクションが読み取ってしまう問題。最初のトランザクションがロールバックした場合、2 番目のトランザクションは実際には存在しないデータを使って処理を続行することになります。
非リピータブルリード（Non-repeatable Read）: あるトランザクション内で同じデータを 2 回読み取った際に、その間に別のトランザクションがそのデータを変更したため、2 回の読み取り結果が異なる問題。
ファントムリード（Phantom Read）: あるトランザクション内で同じ条件で 2 回クエリを実行した際に、その間に別のトランザクションが条件に合致する新しいデータを追加したため、2 回のクエリ結果が異なる問題。
更新の消失（Lost Update）: 2 つのトランザクションが同じデータを読み取り、それぞれが更新を行う場合、後から更新したトランザクションが先の更新を上書きしてしまう問題。
これらの問題に対処するために、データベースシステムは主に「楽観ロック」と「悲観ロック」という 2 つのアプローチを提供しています。これらのロック戦略によって、トランザクション間の干渉を制御し、データの整合性を保つことができます。

 トランザクションの重要な性質
 ACID 特性の解説トランザクションが信頼性の高いデータ処理を保証するために満たすべき性質として、ACID 特性があります。これは以下の 4 つの頭文字を取ったものです。
原子性（Atomicity）: トランザクションに含まれる操作は、全て実行されるか全く実行されないかのどちらかでなければなりません。例えば、銀行振込処理では、引き落としと入金が必ず両方成功するか、両方とも行われないかのどちらかです。中途半端な状態は許されません。
一貫性（Consistency）: トランザクションの前後で、データベースは一貫した状態を保たなければなりません。すべての制約、参照整合性、ビジネスルールが満たされている状態です。トランザクション実行中に一時的に不整合が生じても、完了時には整合性が保たれます。
独立性（Isolation）: 複数のトランザクションが同時に実行される場合でも、各トランザクションは他のトランザクションの影響を受けずに実行されるように見えなければなりません。これにより、同時実行されるトランザクション間の干渉を防ぎます。
永続性（Durability）: 一度コミットされたトランザクションの結果は、システム障害が発生しても失われることなく永続的に保存されなければなりません。これはデータベースがディスクなどの永続メディアに確実に書き込むことで実現されます。

 トランザクション分離レベル並行してトランザクションを実行する際、独立性のレベルを調整できるよう、SQL 標準では 4 つの分離レベルが定義されています。
READ UNCOMMITTED（未コミット読み取り）: 最も低い分離レベルです。他のトランザクションがコミットしていない変更も読み取れます。
READ COMMITTED（コミット済み読み取り）: 他のトランザクションがコミットした変更のみを読み取れます。
REPEATABLE READ（反復可能読み取り）: トランザクション中に同じデータを複数回読み取っても、結果が変わりません。
SERIALIZABLE（直列化可能）: 最も厳格な分離レベルです。同時実行されるトランザクションが、順番に一つずつ実行されたかのような結果になります。

 分離レベルと発生しうる問題の関係分離レベルによって、許容される並行処理の問題が異なります。


分離レベル
ダーティリード
非リピータブルリード
ファントムリード


READ UNCOMMITTED
発生する
発生する
発生する

READ COMMITTED
発生しない
発生する
発生する

REPEATABLE READ
発生しない
発生しない
発生する

SERIALIZABLE
発生しない
発生しない
発生しない

分離レベルを高くするほど、データの整合性は向上しますが、ロックが増えるためパフォーマンスは低下する傾向があります。アプリケーションの要件に応じて適切な分離レベルを選択することが重要です。例えば、高いスループットが必要な読み取り中心のアプリケーションでは READ COMMITTED を、金融取引のような厳密な整合性が必要なアプリケーションでは SERIALIZABLE を選択するといった判断が必要です。

 楽観ロックの仕組み
 楽観ロックの基本概念とメンタルモデル楽観ロック（Optimistic Locking）は、その名の通り「楽観的」なアプローチでデータの整合性を管理します。このアプローチでは、データ競合が発生する確率は低いという前提に立ち、事前にデータをロックせずに処理を進めます。
楽観ロックのメンタルモデルは、EC サイトでの買い物に似ています。あなたがオンラインショップで商品を閲覧するとき、その商品を「予約」したり「確保」したりはしません。商品ページを見るだけでは、他の人がその商品を購入するのを防ぐ仕組みはありません。あなたは「おそらくこの商品はすぐには売り切れないだろう」と楽観的に考えてショッピングを続けます。
そして最終的に購入ボタンを押したときに初めて、「この商品はまだ在庫があるか？」を確認します。在庫があれば購入成功、もし他の誰かがあなたよりも先に最後の 1 個を買っていれば「在庫切れ」というメッセージが表示されます。この場合は別の対応（他の商品を選ぶ、入荷待ちにするなど）を検討することになります。
楽観ロックもこれと同様に、データを読み取る時点ではロックをかけず、最終的な更新時に「他の誰かが変更していないか」を確認するアプローチです。

 楽観ロックの実装方法楽観ロックの典型的な実装方法には以下のようなものがあります。
バージョン番号の使用：データにバージョン番号（または更新回数）を付与し、更新のたびにインクリメントします。更新時には、読み取った時点のバージョン番号と現在のバージョン番号を比較し、一致しなければ競合と判断します。
タイムスタンプの使用：更新日時をデータに格納し、更新時には読み取った時点の更新日時と現在の更新日時を比較します。
ハッシュ値の使用：データの内容からハッシュ値を計算し、更新時には現在のデータから計算したハッシュ値と比較します。
元の値の比較：更新対象のすべてのフィールドについて、読み取った時点の値と現在の値を比較します。これは追加のカラムを必要としない方法ですが、比較する項目が多い場合は処理が複雑になります。
楽観ロックの典型的な処理の流れは以下の通りです。
データを読み取る（ロックは取得しない）
クライアントがデータを処理する
更新時に、読み取った時点からデータが変更されていないことを確認する
変更がなければ更新し、変更があれば競合解決処理を行う

 楽観ロックのメリットとデメリット
 メリット
高い並行性：ロックを取得しないため、多数のユーザーが同時にデータを読み取ることができます。

デッドロックの回避：物理的なロックを使用しないため、デッドロックが発生しません。

スケーラビリティ：ロックの管理オーバーヘッドが少ないため、大規模システムでも効率よく動作します。

長時間処理への適合：データを読み取ってから更新するまでの時間が長くても、他のトランザクションをブロックしません。

 デメリット
競合処理の複雑さ：競合が検出された場合の処理（リトライやマージなど）をアプリケーション側で実装する必要があります。

パフォーマンスへの影響：競合が頻繁に発生する環境では、リトライが多発し、かえってパフォーマンスが低下する可能性があります。

実装の複雑さ：バージョニングのメカニズムをスキーマに追加し、アプリケーションコードでチェックロジックを実装する必要があります。

競合検出の粒度：通常はレコード単位での競合検出となるため、特定のフィールドだけが変更された場合も競合とみなされます。
楽観ロックは、読み取りが多く書き込みが少ないシステムや、データ競合が稀な環境で特に効果を発揮します。Web アプリケーションなど、多数のユーザーが同時にアクセスするシステムで広く採用されています。

 悲観ロックの仕組み
 悲観ロックの基本概念とメンタルモデル悲観ロック（Pessimistic Locking）は、その名の通り「悲観的」なアプローチでデータの整合性を保護します。このアプローチでは、複数のユーザーが同じデータに対して同時に変更を試みることを前提としています。つまり、データ競合は避けられないという悲観的な見方に基づいています。
悲観ロックのメンタルモデルは、「先に予約する」という概念に似ています。例えば会議室を使用する場合、誰かが使用している間は他の人は使えないよう、事前に予約して専有状態にします。同様に、悲観ロックでは、データを変更しようとするトランザクションが、そのデータに対して事前にロックを取得し、処理が完了するまでロックを保持します。
これにより、他のトランザクションが同じデータにアクセスする場合は、先行トランザクションがロックを解放するまで待機するか、あるいはエラーとして処理を中断することになります。

 悲観ロックの実装方法悲観ロックの実装には、主に以下のレベルがあります。
データベースレベルのロック：SQL の SELECT ... FOR UPDATE や SELECT ... FOR SHARE などの構文を使用します。これによりデータベースエンジン自体がロックを管理します。
テーブルロック：テーブル全体をロックする方法です。更新頻度が低く、テーブル全体を対象とする処理に適しています。
行ロック：特定の行（レコード）だけをロックする方法です。他のレコードへのアクセスは制限されないため、より細かい粒度での並行処理が可能になります。
ページロック：データベースの物理的なストレージ単位である「ページ」単位でロックする方法です。テーブルロックよりも細かく、行ロックよりも粗い粒度のロックです。
また、ロックのタイプには主に「読み取りロック」と「書き込みロック」があります。

読み取りロック：他のトランザクションによる読み取りは許可しますが、更新や削除は禁止します。

書き込みロック：他のトランザクションによる読み取り、更新、削除をすべて禁止します。

 悲観ロックのメリットとデメリット
 メリット
確実なデータ保護：ロックによって競合を事前に防ぐため、データの整合性が高いレベルで保証されます。

実装が比較的単純：多くのデータベースシステムで標準的にサポートされており、実装が容易です。

リトライの必要性が低い：ロックを取得できればその後の処理は保証されるため、アプリケーション側でのリトライ処理が少なくて済みます。

 デメリット
スケーラビリティの制限：ロックを取得したトランザクションが処理を完了するまで、他のトランザクションは待機する必要があるため、同時実行性が制限されます。

デッドロック：複数のトランザクションが互いに相手が保持するリソースを待っている状態（デッドロック）が発生する可能性があります。

パフォーマンスへの影響：特に負荷の高いシステムでは、ロックの取得と解放のオーバーヘッドがパフォーマンスに影響します。

長時間トランザクション：処理時間が長いトランザクションがロックを保持すると、他のトランザクションの待機時間が長くなり、システム全体のスループットが低下します。
悲観ロックは、データ競合が頻繁に発生する環境や、データの整合性が非常に重要なアプリケーション（例：金融取引）に適していますが、高い並行処理が求められるシステムでは制約となる可能性があります。

 ロック戦略の選択方法
 アプリケーションの特性と適切なロック戦略ロック戦略の選択は、アプリケーションの特性に大きく依存します。以下のような要素を考慮して適切な戦略を選びましょう。
読み取り/書き込みの比率：読み取りが主体のアプリケーション（例：分析ダッシュボード）では楽観ロックが適しています。一方、書き込みが頻繁に発生するアプリケーション（例：在庫管理システム）では悲観ロックが効果的な場合があります。
トランザクションの処理時間：短時間で完了するトランザクションは悲観ロックでも問題が少ないですが、ユーザーの入力を待つなど長時間のトランザクションでは、リソースを長時間ロックする悲観ロックは不向きです。
ビジネスの重要度：金融取引や予約システムなど、データの正確性が最優先されるアプリケーションでは、確実な競合防止を提供する悲観ロックが選ばれることがあります。
データアクセスパターン：特定のレコードに対して多くのユーザーが同時に更新する可能性が高いケースでは悲観ロック、特定のレコードに対する同時更新が稀なケースでは楽観ロックが適しています。

 並行ユーザー数とデータ競合の頻度による選択並行ユーザー数とデータ競合の発生頻度は、ロック戦略選択の重要な判断材料となります。
少数ユーザー・競合少：ユーザー数が少なく競合も稀な場合は、どちらの戦略も有効ですが、シンプルな実装の楽観ロックが適している場合が多いです。
多数ユーザー・競合少：ユーザー数は多いが、異なるデータにアクセスするため競合が少ない場合（例：SNS の個人プロフィール編集）は、楽観ロックが高いスループットを実現します。
少数ユーザー・競合多：少数のユーザーが同じデータに頻繁にアクセスする場合（例：小規模チームでの共同編集）は、悲観ロックでリトライの手間を省けます。
多数ユーザー・競合多：ユーザー数が多く競合も頻繁に発生する場合は難しい選択ですが、スケーラビリティの観点から楽観ロックを選び、アプリケーションレベルで競合解決戦略を実装するアプローチが一般的です。

 パフォーマンス要件と整合性要件のバランス最適なロック戦略を選ぶためには、パフォーマンスとデータ整合性のトレードオフを慎重に検討する必要があります。
高パフォーマンス優先：スループットやレスポンス時間が最重要の場合（例：高トラフィックの EC サイト）、楽観ロックによる高い並行性が有利です。ただし、競合発生時の処理を適切に設計する必要があります。
データ整合性優先：データの正確性が絶対条件となる場合（例：会計システム）、悲観ロックにより確実に競合を防止できます。ただし、スケーラビリティの制約を受け入れる必要があります。
ハイブリッドアプローチ：特定の重要なリソースにのみ悲観ロックを適用し、それ以外には楽観ロックを使用するという折衷案も検討価値があります。例えば、在庫管理システムで在庫数の更新には悲観ロックを、商品情報の更新には楽観ロックを使用するといった使い分けが可能です。
最終的には、アプリケーションの特性、ユーザー数、データアクセスパターン、ビジネス要件を総合的に判断し、適切なロック戦略を選択することが重要です。また、パフォーマンステストを実施して、選択した戦略が要件を満たすことを確認しましょう。

 実装例：楽観ロック
 バージョン番号を使った楽観ロックの実装楽観ロックの最も一般的な実装方法は、バージョン番号を使用する方法です。具体的な実装手順は以下のとおりです。
データベーススキーマの準備：テーブルにバージョン番号を保存するためのカラムを追加します。一般的には整数型の version や lock_version というカラム名が使われます。
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10, 2),
    stock INT,
    version INT DEFAULT 0
);
データ取得：データ取得時に、バージョン番号も一緒に読み取ります。
SELECT id, name, price, stock, version FROM products WHERE id = 1;
データ更新：更新時には、WHERE 句に現在のバージョン番号を条件として含め、新しいバージョン番号に更新します。
UPDATE products
SET name = '新商品名',
    price = 1500,
    stock = 100,
    version = version + 1
WHERE id = 1 AND version = 0;
このクエリは、バージョン番号が変更されていなければ更新に成功し、影響行数は 1 になります。もし別のトランザクションがすでに更新していた場合、バージョン番号が変わっているため影響行数は 0 となり、更新が失敗したことがわかります。

 楽観ロックの例外処理楽観ロックによる競合が検出された場合、アプリケーションは適切に対応する必要があります。主な対応方法は以下のとおりです。
エラー通知：ユーザーに競合が発生したことを通知し、操作をやり直すよう促します。
自動リトライ：バックグラウンドプロセスなど、ユーザー操作を伴わない処理の場合は、自動的にデータを再取得して処理をリトライします。
マージ処理：データの変更内容をマージして競合を解決します。例えば、元のデータと現在のデータを比較し、異なるフィールドのみを更新するといった方法があります。
最新データの表示：競合が発生した場合、最新のデータを表示し、ユーザーに変更箇所を確認してもらいます。
例えば、Active Record のような ORM を使用している場合、以下のようなコードで例外処理を実装できます。
begin
  product = Product.find(1)
  product.price = 1500
  product.save!
rescue ActiveRecord::StaleObjectError
  # 最新のデータを再取得
  fresh_product = Product.find(1)
  # ユーザーに通知
  puts "他のユーザーが商品を更新しました。最新の価格: #{fresh_product.price}"
end

 楽観ロック実装時の注意点楽観ロックを実装する際には、いくつかの重要な注意点があります。
部分更新の扱い：特定のフィールドだけを更新する場合でも、バージョン番号は必ず更新してください。そうしないと、他のフィールドの変更を検出できなくなります。
バッチ処理での注意：大量のデータを処理するバッチジョブでは、競合が頻発する可能性があります。そのような場合は悲観ロックの検討や、バッチ専用の処理時間帯を設定するなどの対策を考慮してください。
バージョン番号の初期化：新規レコード作成時にはバージョン番号を適切に初期化（通常は 0）することを忘れないようにしましょう。
競合解決戦略：競合が発生した場合の解決戦略をあらかじめ設計しておくことが重要です。ビジネスロジックに応じて、単純なリトライで良いケースと、手動での競合解決が必要なケースを区別しましょう。
テスト：楽観ロックが正しく機能することを確認するテストは不可欠です。特に、競合が発生した場合の動作を検証するテストケースを用意しましょう。
楽観ロックは、適切に実装すれば高いスループットと良好なユーザー体験を実現できますが、競合検出とその解決のロジックをしっかりと設計することが成功の鍵となります。

 実装例：悲観ロック
 データベースレベルでの悲観ロックの実装悲観ロックは多くの場合、データベース固有の機能を使って実装します。最も一般的な方法は、SELECT 文に特殊な句を追加してロックを取得する方法です。主要なデータベースでは以下のような構文が提供されています。
-- 読み取り用ロック（他のトランザクションによる読み取りは許可するが、更新は禁止）
SELECT * FROM products WHERE id = 1 FOR SHARE;

-- 更新用ロック（他のトランザクションによる読み取りも更新も禁止）
SELECT * FROM products WHERE id = 1 FOR UPDATE;
これらの構文を使用すると、トランザクション中に対象レコードがロックされ、他のトランザクションがロックを取得しようとした場合は、先行トランザクションが終了するまで待機するか、タイムアウトエラーが発生します。
悲観ロックを使った一般的なトランザクションの流れは以下のようになります。
データベース製品によっては、ロックのタイムアウト時間や競合時の動作（待機かエラー）を指定するオプションも提供しています。

 悲観ロックとデッドロック悲観ロックを使用する際に注意すべき最大の問題はデッドロックです。デッドロックとは、2 つ以上のトランザクションが互いに相手が保持するリソースを待ち合い、どのトランザクションも進行できなくなる状態を指します。
例えば、以下のようなシナリオを考えてみましょう。
トランザクション A が商品 X をロック
トランザクション B が商品 Y をロック
トランザクション A が商品 Y をロックしようとする（待機）
トランザクション B が商品 X をロックしようとする（待機）
この状況では、互いに相手のロック解放を待っているため、どちらのトランザクションも進行できません。

多くのデータベースシステムにはデッドロック検出機能があり、検出された場合は一方のトランザクションを強制的にロールバックします。
アプリケーション側でもデッドロックの可能性を最小限に抑える工夫が必要です。以下に例を示します。

ロックの取得順序を一貫させる：複数のリソースをロックする場合、常に同じ順序でロックを取得します。

タイムアウトの設定：長時間のロック待機を防ぐため、適切なタイムアウト値を設定します。

一度に取得するロック数を最小化：必要最小限のリソースだけをロックします。

 悲観ロック実装時の注意点悲観ロックを実装する際には、以下の点に注意しましょう。
トランザクションの範囲と時間：悲観ロックはトランザクションが終了するまで保持されるため、トランザクションを短く保つことが重要です。特に、ユーザーの入力待ちや外部システムへの通信などの時間がかかる処理は、ロック取得前に完了させておくべきです。
ロックの粒度：必要以上に広範囲のデータをロックすると、並行性が低下します。例えば、テーブル全体をロックするのではなく、必要な行だけをロックするようにしましょう。
エスカレーション：一部のデータベースでは、多数の行ロックが取得されると、自動的にテーブルロックにエスカレーションする場合があります。これによって予期しない競合が発生する可能性があるため、ロック対象の範囲に注意が必要です。
例外処理：デッドロックやタイムアウトなどの例外は適切に処理する必要があります。多くの場合、リトライのロジックを実装することで一時的な問題を回避できます。
success = false
retry_count = 0
max_retries = 3  # MAX_RETRIESの定義
retry_wait_time = 0.5  # 秒単位での待機時間

while !success && retry_count < max_retries
  begin
    ActiveRecord::Base.transaction do
    # 悲観ロックの取得
    # 例: product = Product.lock.find(product_id)

    # 更新処理
    # 例: product.update!(stock: product.stock - 1)

    # トランザクションの最後まで来たら成功
    end
    success = true
  rescue ActiveRecord::Deadlocked => e
    retry_count += 1
    # エラーログ出力
    Rails.logger.warn "デッドロックが発生しました。リトライ #{retry_count}/#{max_retries}"
    # 少し待機してからリトライ
    sleep(retry_wait_time)
  end
end

# リトライ回数を超えた場合のエラー処理
unless success
  Rails.logger.error "最大リトライ回数を超えました。処理に失敗しました。"
  # 追加のエラーハンドリング
end
テスト：悲観ロックの動作を適切にテストするには、複数のトランザクションを同時に実行するテストケースを用意する必要があります。特に負荷が高い状況でのデッドロックの発生可能性をテストすることが重要です。
悲観ロックは確実なデータ保護を提供しますが、その代償としてシステムの並行性が制限される点を常に意識して実装する必要があります。

 おわりに本記事では、データベースにおける並行制御のための楽観ロックと悲観ロックについて解説しました。並行制御の基本概念から始まり、トランザクションの ACID 特性、各ロック戦略の仕組みと実装方法まで、アプリケーション開発者が実務で活用できる知識を提供しました。
実際のプロジェクトでは、アプリケーションの特性や要件に応じた適切なロック戦略の選択が重要です。トラフィックの多い Web サイトでは楽観ロックが有効ですが、金融系システムでは悲観ロックの確実性が求められることもあります。どちらの戦略も、適切に実装しなければパフォーマンス問題や整合性の問題を引き起こす可能性があるため、本記事で解説した実装時の注意点を参考にしてください。
分離レベル	ダーティリード	非リピータブルリード	ファントムリード
READ UNCOMMITTED	発生する	発生する	発生する
READ COMMITTED	発生しない	発生する	発生する
REPEATABLE READ	発生しない	発生しない	発生する
SERIALIZABLE	発生しない	発生しない	発生しない
Discussion

ログインするとコメントできます