🔒

なぜ常にUserにロックをかけるのか?

2021/04/14に公開

[前提]

  • データベースへのアクセスには 排他制御が必要
    • 1つのメインとなるDBに各所(Web API、スケジュールタスク、非同期ジョブ、admin等)から同時多発的にアクセスが発生しうる。
  • 原則、デッドロックは許容しない
    • 多方面からあらゆるエンドポイントに絶え間ないアクセスが猛烈に来てもデッドロックが起こらないように。
    • 将来的に、パフォーマンス観点で妥協して箇所を限定して許容する可能性はある

[課題感]

排他制御は 難しい、大変、精神力使う、深い業務知識が求められる

→ミスる、エラー出る、ユーザー影響に迷惑かける、信頼減る、原因調査に時間かかるetc...

  • 「このリソースA、Bに更新かけようとしているけど…他に触っている所はないかな?A→Bの順番?B→Aの順番?」を常に気にしないといけない。大変。
  • ある箇所をいじるときに、他のコードを気にしないといけない(密結合)。
  • ソースコード広範に関する深い理解が必要。新メンバーにとって地雷になりがち。
  • 対応が完璧に出来ておらず、本番でデッドロックが発生した際の調査が大変。
  • 未来に誰かがリファクタリングのつもりでトランザクション内の更新順番を変えた→デッドロック発生→障害→影響範囲の洗い出し→きつい、みたいな未来も見える。

[解決法]

「更新対象のリソース群の親となるリソースに無条件でロックを掛ける」 というシンプルなルール

例)ユーザー関連の更新ならUser、リクルーター関連の更新ならRecruiterTeam、投稿関連の更新ならPost等

課題感で上げたものが全て解決される。排他制御のためのロック。

Discussion