分散ロックの実装
- RedisのWebサイトでRedlockアルゴリズムを見つけ、このアルゴリズムがRedis上で耐障害性のある分散ロックを実装すると主張している。
- Redlockにはすでに複数の独立した実装が存在し、このアルゴリズムに依存している人がいるかもしれないため、筆者のノートを共有することにした。
- Redisは一時的で急速に変化するデータをサーバ間で共有する際には有用だが、強い一貫性と永続性が求められるデータ管理領域へ拡張することには懸念がある。
ロックの目的
- ロックは複数のノードのうち1つだけが特定の作業を実行することを保証する役割を持つ。
- 効率性のためにロックを使う場合は、単一のRedisインスタンスを使う方がよいかもしれない。
- 正確性のためにロックを使う場合、Redlockは適していない。
リソースをロックで保護する
- 分散システムにおけるロックは、マルチスレッドアプリケーションのミューテックスとは異なる。
- クライアントがファイルを読み取り、変更して再び書き込む間、別のクライアントが同じ作業を行えないように防ぐ。
フェンシングによる安全なロックの実装
- フェンシングトークンを使って書き込みリクエストに含めることで、安全なロックを実装できる。
- Redlockにはフェンシングトークンを生成する機能がないため、安全ではない。
合意のための時間利用
- Redlockは非同期モデルにおけるアルゴリズムとは異なり、時間に関する前提に大きく依存している。
- システムクロックが異常に動作すると、キーの有効期限が予想より早くなったり遅くなったりする可能性がある。
Redlockの時間前提を崩す
- Redlockは同期システムモデルを前提としており、ネットワーク遅延、プロセスの一時停止、時計の誤差が限定的な場合にのみ正しく動作する。
- GitHubの90秒パケット遅延事件のような事例は、Redlockの安全性を脅かす可能性がある。
結論
- Redlockは効率性最適化のためのロックには不必要に重く、正確性が求められる状況では十分に安全ではない。
- 正確性のためにロックが必要な場合は、ZooKeeperのような適切な合意システムを使うのがよい。
GN⁺のまとめ
- Redlockアルゴリズムは、分散システムにおけるロック実装について重要な議論を提供する。
- この記事は、分散システムにおける時間前提と安全性の問題を強調し、正しいロック実装の重要性を説明している。
- ZooKeeperのような代替システムを推奨しており、分散システムの複雑さを理解する助けになる。
1件のコメント
Hacker Newsの意見