ロストアップデートとは？その処理方法を解説

データベースは、ウェブサイトやソフトウェア、そして他の多くのシステムにとって欠かせない要素です。データを安全に、失われることなく保持することは、システム構築において非常に重要です。

しかし、大勢のユーザーがシステムにアクセスし、同時にデータを変更すると、アップデート中にデータが失われることがあります。これは「ロストアップデート」という問題です。

このような状況を防ぐために、データをどのように管理すべきかは開発者にとって大きな課題です。

Rabilooブログのこの記事では、「ロストアップデート」という問題と、その処理の方法について取り上げたいと思います。

ロストアップデートとは

「ロストアップデート」とは、「失われた更新」つまり、複数のユーザーが同時にアクセスしたときに起こる、更新したはずのデータが「失われてしまう」つまり、更新が反映されていない現象のことをいいます。データベースや情報システムにおける一般的な問題で、同時に複数のユーザーやプロセスが同じデータを更新しようとする際に発生します。具体的には、以下のような状況で起こり得ます。

複数のアクセス: 二人以上のユーザーが同時に同じデータにアクセスし、そのデータを変更しようとします。

不完全な更新: 最初のユーザーによる変更が完了する前に、二番目のユーザーがデータを更新し始めると、最初のユーザーの変更が上書きされ、結果的に「失われる」ことになります。この問題は、データの整合性を維持する上で大きな問題となります。

データベース管理システムでは、通常、ロック機構やトランザクション管理を通じてこの問題に対処します。これにより、一度に一つのプロセスだけが特定のデータにアクセスし、変更することができるようになり、ロストアップデートのリスクを減らすことができます。

ロストアップデートの例

上記の例では、AliceとBobがトランザクション処理をしてデータベースにアクセスしています。

AliceがデータのQty＝2に更新した後、彼女はQty＝9に変更されていることに気付きます。この変更はBobによるもので、Aliceの後にQtyを9に更新したため、システムはBobの更新したデータを表示しています。

しかし、AliceはBobが同時にデータを更新していたことを知らず、システムに何らかの問題があると考えてしまいます。

ロストアップデートを適切に処理しない場合、以下のような問題が発生します：

システムエラー：これは最悪の場合、ユーザー体験を著しく損なうことになります。
データ損失：システムの規模が大きくなるほど、損失されるデータの量も増加します。
予約システムなどの場合、売上に深刻な影響を与える可能性があります。

関連記事: Amazon RDSとは？クラウドストレージサービスの概要

ロストアップデートの処理方法

ロストアップデートを防ぐための対策として、ロック（排他制御）が用いられます。ロックは、複数のユーザーが同時にデータベースを更新する際に矛盾を防ぐための仕組みです。

ここでは、最も一般的な２つの処理方法として楽観ロックと悲観ロックを取り上げます。

楽観ロック (Optimistic Locking)

Spring data JPAで楽観ロックを有効にする

楽観ロックとは、同時アクセスはあまり起きないだろうという楽観的なロックのことです。

この手法は、データの同時更新に関して「楽観的」なアプローチを採ります。具体的には以下のようなプロセスで動作します。

バージョン管理: 楽観ロックでは、各データレコードにバージョン番号やタイムスタンプが付与されます。これにより、データがいつ更新されたかを追跡することができます。
更新時のチェック: ユーザーがデータを更新しようとするとき、システムは保存されているデータのバージョンとユーザーが最初に読み込んだデータのバージョンを比較します。
競合の検出: もしユーザーがデータを読み込んでから更新しようとする間に他のユーザーがそのデータを更新してバージョンが変わっていれば、競合があったと見なされます。
競合時の対応: 競合が検出された場合、通常、更新は拒否され、ユーザーは最新のデータに基づいて再度更新処理を行う必要があります。

楽観ロックでは、どのユーザーもデータの読み込みと更新が可能です。しかし、もし複数のユーザーが同時に同じデータを更新しようとすると、最初に更新操作を完了したユーザーの変更のみが受け入れられます。

その他のユーザーは、データが既に使用中であることを通知され、その時点での更新は行えず、後ほど再試行することになります。この手法は、例えばECサイトなどで利用されています。

楽観ロックの利点は、データベースに対するロック（データへのアクセス制限）を必要としないため、システムのスループットが向上することです。データが更新されたときのみ、例外処理が行われます。

一方で、この方法の欠点は、更新が失敗した際に、ユーザーがページを何度も更新したり再読み込みしたりしなければならないことです。これにより、ユーザーエクスペリエンスが損なわれる可能性があります。競合が頻繁に発生する環境では、再試行の必要が増え、効率が低下する可能性があります。

悲観ロック (Pessimistic locking)

Spring data JPAで悲観ロックを有効にする

悲観ロックとは、逆に同時アクセスが頻繁に起きるだろうという「悲観的に」予測し、そのデータに対して排他的なアクセス制御を行う手法です。具体的には、以下のような特徴を持ちます。

ロックの確立: ユーザーがデータにアクセスすると、そのデータは他のユーザーからのアクセスができないようにロックされます。これにより、データの同時更新を防ぎます。
更新までの継続: そのロックは、ユーザーがデータの更新を完了するまで継続します。つまり、一度データにロックがかかると、他のユーザーはそのデータを読み込んだり更新したりすることができません。
データの保護: 悲観ロックはデータの整合性を保護するために使用され、特に競合が頻繁に発生する可能性が高い場合や、データの安全性が非常に重要な状況で有効です。

この方式を採用すると、あるユーザーがデータにアクセスして更新処理を行っている間、そのデータはロックされます。このロック状態の間、他のユーザーはそのデータにアクセスできません。

悲観ロックの利点としては、データの整合性と安全性が強化されることによりシステムのパフォーマンスが向上することがあります。

しかし欠点としては、ロックによってシステム全体のスループットが低下する可能性があります。特にECサイトのように多くのユーザーが同時にデータにアクセスするシステムでは、この方法の大規模な実装には向いていません。

楽観ロックか悲観ロックか

楽観ロックと悲観ロックの選択は、アプリケーションの要件、データの使用パターン、およびシステムのパフォーマンス要求に基づいて行うべきです。以下の指針を参考にして選択を行うことができます。

楽観ロックの適用シナリオ

低競合環境: データの同時更新が稀な場合、楽観ロックは効果的です。
スケーラビリティ重視: システムのスループットと応答性を最大化する必要がある場合、楽観ロックが適しています。
短期間のトランザクション: トランザクションが短期間で完了し、競合の可能性が低い場合に適しています。
読み取り多重: 読み取り操作が多く、書き込み操作が比較的少ない場合に適しています。

例：SNSプラットフォームなど。ユーザーが投稿やコメントを編集する際、投稿の編集は比較的頻繁ではないため、ユーザーが投稿を編集しようとする際には楽観ロックを使用。編集の衝突が発生した場合、ユーザーに通知し、最新の内容に基づいて再編集を促す。

悲観ロックの適用シナリオ

高競合環境: 同じデータに対する同時更新の可能性が高い場合、悲観ロックが適しています。
データ整合性重視: データの整合性が非常に重要で、競合によるリスクを最小限に抑えたい場合に適しています。
長期間のトランザクション: トランザクションが長期間にわたる場合、悲観ロックでデータを保護することが望ましいです。
書き込み多重: 書き込み操作が頻繁に行われる場合に適しています。

例：銀行の口座システム。顧客の口座間での資金移動が頻繁に行われる場合。口座の残高を更新する際には悲観ロックを用いて、資金移動処理中は他のトランザクションが同時に口座にアクセスできないようにする。これにより、同時に複数のトランザクションが口座の残高に影響を与えることを防ぎ、データの整合性を保つ。

総合的な判断

アプリケーションの性質：ユーザーの行動パターンやデータアクセスの特性を考慮する必要があります。
パフォーマンスと整合性のバランス：より高いパフォーマンスを求める場合は楽観ロック、より堅牢なデータ整合性を求める場合は悲観ロックを選択します。
テストと評価：実際のユーザーの使用パターンに基づいて、どちらのロックが最適かを評価することが重要です。

最終的には、アプリケーションの具体的な要件と実際の動作環境を考慮して、どちらのロック方式が最も適しているかを決定する必要があります。場合によっては、楽観ロックと悲観ロックの組み合わせを用いることも一つの解決策となりえます。

まとめ

この記事では、「ロストアップデート」とその処理方法について解説しました。

ロストアップデートは複数のユーザーが同じデータを更新することで発生します。

対策として二つの方法があります。

楽観ロック：全ユーザーがデータを読み書きできる一方で、競合が発生する可能性があり
悲観ロック：更新中のデータをロックする方法ですが、大規模なシステムでは実装が難しい

Rabilooでは、これらの問題に対処し、セキュリティやデータ整合性を確保するweb開発サービスを提供しています。

開発のご相談は下記フォームよりお寄せください。