Spring Bootを利用した高負荷在庫管理システムにおけるトランザクション分離レベルと排他制御の最適化
概要
ユーザー数1,000名/分を想定した在庫管理システムにおいて、在庫テーブルと決済テーブルの整合性を保ちつつ高スループットを実現するためには、トランザクション分離レベルと排他制御の適切な組み合わせが不可欠です。本稿では、Spring Boot環境での実装例を交えながら、以下の観点で詳細に解説します。
- トランザクション分離レベルの選択基準
- 悲観的ロックと楽観的ロックの使い分け
- デッドロック回避戦略
- Spring Data JPAを活用した実装パターン
- パフォーマンスチューニングのポイント
トランザクション分離レベルの選定基準
各分離レベルの特性比較
| 分離レベル | ダーティリード | ノンリピータブルリード | ファントムリード | スループット | 適用ケース |
|---|---|---|---|---|---|
| READ UNCOMMITTED | 発生 | 発生 | 発生 | 最高 | 集計処理等の非クリティカル処理 |
| READ COMMITTED | 防止 | 発生 | 発生 | 高 | デフォルト推奨 |
| REPEATABLE READ | 防止 | 防止 | 発生* | 中 | 財務関連トランザクション |
| SERIALIZABLE | 防止 | 防止 | 防止 | 低 | 厳密な一貫性が求められる処理 |
※MySQLのInnoDBはREPEATABLE READでもファントムリードを防止[33]
推奨構成
// 在庫更新処理
@Transactional(isolation = Isolation.READ_COMMITTED)
public void updateInventory(Long productId, int quantity) {
// 在庫更新ロジック
}
// 決済処理
@Transactional(isolation = Isolation.REPEATABLE_READ)
public void processPayment(PaymentRequest request) {
// 決済処理ロジック
}
選定理由:
- 在庫更新: 高スループットを実現しつつダーティリードを防止[1][2]
- 決済処理: 金額計算の再現性を保証[12][13]
排他制御戦略
悲観的ロック vs 楽観的ロック
| 方式 | ロック取得タイミング | 競合検出タイミング | スループット | 適用ケース |
|---|---|---|---|---|
| 悲観的ロック | データ取得時 | 即時 | 中 | 高競合率（例: 人気商品） |
| 楽観的ロック | 更新時 | コミット時 | 高 | 低競合率（通常商品） |
実装例
悲観的ロック（行ロック）
public interface InventoryRepository extends JpaRepository<Inventory, Long> {
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT i FROM Inventory i WHERE i.productId = :productId")
Inventory findByProductIdForUpdate(@Param("productId") Long productId);
}
// 在庫更新処理
public void updateStock(Long productId, int quantity) {
Inventory inventory = inventoryRepository.findByProductIdForUpdate(productId);
if (inventory.getStock() >= quantity) {
inventory.setStock(inventory.getStock() - quantity);
} else {
throw new InsufficientStockException();
}
}
楽観的ロック（バージョン管理）
@Entity
public class Inventory {
@Id
private Long productId;
@Column(nullable = false)
private Integer stock;
@Version
private Long version;
}
// 更新処理
@Transactional
public void updateStockOptimistic(Long productId, int quantity) {
Inventory inventory = inventoryRepository.findById(productId)
.orElseThrow(ProductNotFoundException::new);
if (inventory.getStock() < quantity) {
throw new InsufficientStockException();
}
inventory.setStock(inventory.getStock() - quantity);
inventoryRepository.save(inventory); // バージョンチェック自動実行
}
デッドロック回避策
発生要因と対策
-
ロック順序の不整合
- 解決策: テーブル/行へのアクセス順序を統一[19][22]
-
ロック粒度の不適切
- 解決策: 行ロックを基本とし、インデックス設計を最適化[1][6]
-
トランザクション時間の長期化
- 解決策: タイムアウト設定の導入
@Transactional(timeout = 5) // 5秒タイムアウト public void processOrder(Order order) { // 処理ロジック }
高負荷環境でのチューニング
接続プール設定（HikariCP推奨）
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 10
connection-timeout: 30000
max-lifetime: 1800000
最適化ポイント:
- コネクションプールサイズ = (コア数 * 2) + スピンドル数[25]
- 監視指標: プール使用率、待機時間、タイムアウト率
バッチ処理最適化
@Scheduled(fixedDelay = 5000)
@SchedulerLock(name = "InventorySync", lockAtMostFor = "10m")
public void syncInventory() {
// 分散ロックを利用したバッチ処理
}
ShedLockによる分散ロックの活用[27]
実装パターン比較表
| シナリオ | 方式 | 分離レベル | ロック種別 | 想定スループット |
|---|---|---|---|---|
| 通常商品在庫更新 | 楽観的ロック | READ COMMITTED | 行ロック | 500 TPS |
| 人気商品在庫更新 | 悲観的ロック | REPEATABLE READ | 行ロック | 200 TPS |
| 決済処理 | 悲観的ロック | SERIALIZABLE | テーブルロック | 100 TPS |
| 在庫集計 | 非ロック | READ UNCOMMITTED | N/A | 1,000 TPS |
障害発生時の挙動設計
リトライメカニズム
@Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100))
public void updateStockWithRetry(Long productId, int quantity) {
try {
updateStock(productId, quantity);
} catch (ObjectOptimisticLockingFailureException e) {
log.warn("Optimistic lock conflict detected, retrying...");
throw e;
}
}
監視指標
- デッドロック発生率（目標: <0.1%）
- ロック待ち時間（P95 < 50ms）
- トランザクションタイムアウト率（<0.5%）
- 楽観ロック競合率（<5%）