M Hideki

Redis分散ロックは、 同時実行による競合を防ぐ仕組みとしてよく使われます。 ただ、現場で見てきた限り、 「Redisを入れたから安全」という判断は成立しません。 PoCでは問題なく動いても、本番で別の種類の事故が起きるケースがあります。 今回、予約システムのPoCを題材に、 Redis分散ロックがどこまで守れて、どこから守れないのかを QA観点で整理しました。 結論から言うと、 Redis分散ロックは データ整合性を保証する仕組みではなく、処理順序を制御する仕組みです。 TTL設計、プロセス異常終了、Redis再起動、 ネットワーク分断といった条件をQAで洗っていくと、 Redisだけでは防げない領域がはっきり見えてきます。 重要なのは 「Redisを使うかどうか」ではなく、 「どこまでRedisに任せてよいかを判断すること」。 この判断を誤ると、 PoCは通るが、本番で二重実行や整合性崩れが起きます。 今回のPoCでは、 QAシナリオ・判断ガイド・チェックリストとして 実務で使える形に整理しました。 Redis分散ロックの設計判断に迷っている方には、 実装PoCをもとにしたQA設計・判断ガイドを共有できます。 「この構成で本番に出してよいか？」 「Redisに任せすぎていないか？」 そんな観点での壁打ちが必要な場合は、 WantedlyのDMからお気軽に声をかけてください。