図解でなっとく! トラブル知らずのシステム設計 エラー制御・排他制御編

図解でなっとく! トラブル知らずのシステム設計 エラー制御・排他制御編

ロック周りを改めておさらいしている過程で読んだ。 ロック周りの的については後日記事にする予定。

本書の内容と感想

エラーチェックをいつすべきか？

• クライアント 側のチェック
  • ユーザビリティの向上
  • クライアント側でのチェックは書き換え可能なので、業務チェックをしたとしても結果を信用しない（必ずサーバーチェックをする）
• サーバー 側のチェック
  • システム・業務的な整合性の担保

「クライアント側でチェックしている」前提でサーバーチェックしていないAPIがあったことがあるのでめっちゃ分かる。最終的サーバーでのバリデーション担保は大事。クライアントのチェックはあくまで体験を向上させるために使うこと。

DBの機能だけでは一貫性は維持できない

業務要件としての一貫性は、DBのロック機能をただ使うだけでは維持できない。 業務的なトランザクションの範囲を考える。

楽観ロックと悲観ロック

楽観ロック

他者によるデータ更新は頻繁には起きないだろうという（楽観的な）前提に則っている。

• メリット

  • データ更新直前まで、他の人もデータを見ることができる

• デメリット

  • 頻繁にデータ更新がある場合、排他エラーが起こりやすくなる（更新直前にデータを確かめた際に、すでに更新されていてエラーになる確率が上がる）

• バージョン・タイムスタンプ・全列データの情報などを用い、確認した時と、更新直前のデータが同じかを確かめる（ロックキーと呼ぶ）

  • 違っていたら更新できない
  • 同じであれば更新できる

• タイムスタンプをロックキーとして扱うのは避けた方がいい

  • DBに出ないレベルの時間（数ナノとか）差で同時実行された場合は一貫性が維持できないため

タイムスタンプをロックキーとするのを避けるのは感覚的には理解していたが、改めて納得。まぁ被る可能性があるものは基本使うなってことだね。

悲観ロック

最初に排他ロックをかけてしまう方法 他社によるデータ更新が頻繁に起こってしまうという、（悲観的な）前提に則っている

• メリット
  • ロックさえかけてしまえば、更新できることが保証できる（排他制御の面では）
• デメリット
  • 後続処理がロック待ちになる（ボトルネックになりやすい）

トランザクション

• 切り離すことができない処理単位
  • DBトランザクション
    • 整合性を保つための最小範囲
  • 業務的なトランザクション
    • ある業務の整合性を保つための範囲
    • トランザクションは必ずしもDBトランザクションだけを指すわけではない点に注意。ロックについても同様。業務的な観点での範囲に気を配る。

感想

総じて読みやすい本ではある。ロック周りの理解のとっかかりには良いと思う。 実務未経験者はサラッとこの本を読んでおき、実務を少し経験した後改めて読み直すと、色々と気づきも多そう。