【ITニュース解説】I Replaced Redis Locks with Database Atomicity and You Should Too

この記事では、システムにおけるタスクの重複実行を防ぐためのロック処理について、Redisを用いた方法からデータベースの原子性を利用する方法への移行事例が解説されている。

ある自動テストプラットフォームでは、開発者がAPI仕様をアップロードすると、バックグラウンドでテストが自動生成される。当初、複数のジョブがタスクを奪い合うことでテストスイートが重複生成される問題が発生し、Redisによるユーザーレベルのロックが導入された。しかし、このRedisロックにはいくつかの問題があった。ジョブのクラッシュによってロックが解放されずに残る「ゴーストロック問題」や、複数のジョブが同時にロック獲得を試みる「競合状態」が発生し、重複処理を防ぐことができなかった。

そこで、データベースが持つ原子性に着目し、タスクの状態を更新するSQLクエリを利用した解決策が採用された。具体的には、UPDATE文を用いてタスクの状態を「pending（保留）」から「processing（処理中）」に変更する際、WHERE句で状態が「pending」であることを条件に加えることで、同時に複数のジョブが同じタスクを処理するのを防ぐ。この方法では、最初にUPDATEを実行したジョブのみが状態を更新でき、後続のジョブは状態が一致しないため更新に失敗する。データベースが持つACID特性（原子性、一貫性、独立性、耐久性）により、データの整合性が保証される。

しかし、この単純な解決策には、特定ユーザーのタスクがリソースを独占してしまうという新たな問題が発生した。そこで、各ユーザーが同時に実行できるタスク数を制限することで、公平性を確保する仕組みが導入された。具体的には、タスクを処理する前に、ユーザーが実行中のタスク数を確認し、上限を超えている場合はタスクの処理をスキップする。

さらに、公平性を保つための別の方法として、SQLクエリ内でユーザーごとのタスク実行数を考慮してタスクを割り当てる方法や、実行中のタスク数が少ないユーザーのタスクを優先的に処理する方法も紹介されている。

この記事から得られる教訓は、データベースは想定以上に賢く、 concurrency制御の仕組みがすでに備わっている場合があるということだ。データベースのACID特性を理解し、活用することで、複雑な分散ロックシステムを構築せずに、よりシンプルで信頼性の高いシステムを構築できる場合がある。また、システム設計においては、公平性の確保も重要な検討事項であり、初期段階から考慮する必要がある。最初はシンプルな実装から始め、問題が発生した場合に最適化していくアプローチが推奨される。最後に、Redisによる分散ロックとデータベースの原子性のどちらを選ぶかは、タスクの性質やシステムの要件によって異なり、それぞれのトレードオフを理解した上で適切な選択をすることが重要だ。