Laravelにはdeleted_atがありますけど？

PHPerTeaNight#33-削除フラグ

Transcript

1. Copyright© M&Aクラウド Laravelには deleted_atがありますけど？ PHPerTeaNight#33「削除フラグ」 kubotak_public/Kenjiro Kubota
2. Copyright© M&Aクラウド Laravelのdeleted_atとは
3. Copyright© M&Aクラウド SoftDelete（論理削除）とは • レコードをDBから物理的に削除せず、deleted_atカラムに削除⽇時を セットすることで「削除済み」とみなす⼿法 • deleted_at IS NULL のレコードだけが通常のクエリ対象になる
4. Copyright© M&Aクラウド Laravelでの使い⽅
5. Copyright© M&Aクラウド Laravelでの使い⽅
6. Copyright© M&Aクラウド withTrashedの注意点 • リレーション先がSoftDelete済みだとnullが返る → withTrashed()を明⽰的に付 ける必要がある
7. Copyright© M&Aクラウド deleted_atの罠
8. Copyright© M&Aクラウド 1. データ抽出でのうっかりミス • LaravelのEloquentは⾃動でWHERE deleted_at IS NULLを付与してくれる • しかし⽣SQL‧バッチ処理‧BIツール‧データ分析ではこの⾃動フィルタが効か ない • 「退会済みユーザーのデータを含めて集計してしまった」事故が起こりうる
9. Copyright© M&Aクラウド 2. 削除の定義が曖昧 • deleted_atは「何らかの理由で無効化された」ことしか表現できない。実際の業 務では削除の理由は多様
10. Copyright© M&Aクラウド 3. DBパフォーマンスの問題 • カーディナリティ = カラム値の「ユニークさ」の度合い • deleted_atは⼤半がNULL（99%以上がアクティブなレコード）→ 極めて低い カーディナリティ • MySQLのオプティマイザは低カーディナリティのインデックスを無視することが ある
11. Copyright© M&Aクラウド 3. DBパフォーマンスの問題 バッファプールの浪費 • InnoDB はよく使うデータページをメモリ 上のバッファプールにキャッシュする • 論理削除されたレコードも物理的にはテー ブルに残るため、同じデータページに削除 済み‧未削除のレコードが混在する • 結果、削除済みレコードまでバッファプー ルに載ってしまい、本当に必要なデータの キャッシュヒット率が低下する
12. Copyright© M&Aクラウド 4. ユニーク制約の問題 • accound_nameやemail_addressカラム等がユニーク制約である場合、削除済み ユーザーのレコードが残っていると新規で登録ができない
13. Copyright© M&Aクラウド ⾮機能要件としての削除
14. Copyright© M&Aクラウド データ復旧の必要性 • 「誤って削除したデータを元に戻したい」→ SoftDeleteの正当なユース ケース ◦ ただし「どのくらいの期間復旧可能にするか」も決めるべき • 無期限に残すとデータが膨らみ続ける
15. Copyright© M&Aクラウド コンプライアンス（GDPR / 個⼈情報保護法） • ⼀般データ保護規則(GDPR) 第17条「忘れられる権利（Right to Erasure）」 で は、個⼈データの削除を請求された場合、不当な遅延なく消去する義務がある • 論理削除（deleted_atをセット）だけではGDPR上の「消去」とみなされない可 能性がある ◦ DBにデータが残っている = 個⼈データを保持している • 対応パターン: ◦ 物理削除 + バックアップからも⼀定期間で消去 ◦ 個⼈データの匿名化（email = 'deleted_xxx@example.com'） ◦ 暗号化キーの破棄による暗号学的消去（Crypto-shredding） https://www.ppc.go.jp/files/pdf/gdpr-provisions-ja.pdf
16. Copyright© M&Aクラウド 関連データの削除 • 物理削除であればCASCADEで関連データを削除やnull対応が⾏える • 論理削除の場合はプログラマブルに対応する必要がある
17. Copyright© M&Aクラウド データ量の問題 • 論理削除は、パージ運⽤（forceDelete等）を設けないとレコードが増 え続ける • 数年運⽤すると「テーブルの多くが削除済みレコード」という状態にな りうる • ALTER TABLEやマイグレーションの実⾏時間にも影響する
18. Copyright© M&Aクラウド じゃあ、どうしたらいいの？
19. Copyright© M&Aクラウド パターン1: アーカイブテーブルへの退避 そーだいさんの「失敗から学ぶRDBの正しい歩き⽅」でも推奨されているアプロー チ。 削除フラグで状態管理するのではなく、別テーブルに移すという考え⽅。
20. Copyright© M&Aクラウド パターン1: アーカイブテーブルへの退避 「退会ユーザー」と「アクティブユーザー」は別の概念であることを意識してテーブ ルを分けることが重要 既存の削除フラグをリファクタリングする際のDouble-Writeパターン（新旧テーブル に同時書き込みしながら段階的に移⾏）が良い https://soudai.hatenablog.com/entry/database-refactoring-double-write https://soudai.hatenablog.com/entry/2018/05/01/204442
21. Copyright© M&Aクラウド パターン1: アーカイブテーブルへの退避 メリット: • 本テーブルのパフォーマンスが劣化しない • 復旧も可能（アーカイブから本テーブルに戻す） • 集計時に削除済みデータが混⼊するリスクがない • ドメインモデルとして「削除済み」が明⽰的に表現される デメリット: • スキーマ変更時にアーカイブテーブルも同期が必要 • 参照整合性の管理が複雑になる
22. Copyright© M&Aクラウド パターン2: 状態カラムの導⼊
23. Copyright© M&Aクラウド パターン2: 状態カラムの導⼊ メリット: • 「なぜ無効化されたか」が明確 • ステータスごとの集計やフィルタリングが容易 • ビジネスロジックとして表現⼒が⾼い デメリット: • LaravelのSoftDeletesの恩恵（⾃動フィルタ等）が使えない • グローバルスコープを⾃前で実装する必要がある • いつステータスが更新されたか、という情報が失われる ◦ status_updated_atとか‧‧‧？？？
24. Copyright© M&Aクラウド パターン3: 物理削除 + 監査ログ
25. Copyright© M&Aクラウド パターン3: 物理削除 + 監査ログ メリット: • 本テーブルはクリーンな状態を維持 • 「誰が‧いつ‧何を削除したか」の追跡が可能 • GDPR対応の設計がしやすい（物理削除 + ログ匿名化/保持期限管理） デメリット: • 復旧がやや⼿間（ログからリストアするロジックが必要） • ログテーブル⾃体のデータ量管理が必要
26. Copyright© M&Aクラウド パターン4: イベントソーシング • すべての状態変更を「イベント」として記録し、現在の状態はイベント の積み重ねで再現する • 削除も「DeletedEvent」として記録される • 任意の時点の状態を再現可能
27. Copyright© M&Aクラウド パターン4: イベントソーシング メリット: • 完全な変更履歴 • 削除の取り消しが⾃然に実現できる デメリット: • 学習コスト‧実装コストが⾼い • 既存システムへの導⼊はハードルが⾼い ◦ そもそもPHPで実装するの？？？^^？？？？
28. Copyright© M&Aクラウド まとめ
29. Copyright© M&Aクラウド 総括 • 論理削除は「とりあえず」で使いがちだが、多くの場合で問題を先送り にしているだけ • 削除の要件を明確にしてから⼿法を選ぶべき ◦ なぜ削除するのか？ ◦ 復旧は必要か？期間は？ ◦ コンプライアンス要件は？ ◦ データ量の⾒通しは？ • LaravelにSoftDeletesがあるからといって、思考停⽌で使わない • 適切な⼿法を選択し、将来のメンテナンスコストを下げよう
30. Copyright© M&Aクラウド 終 おわり