コマンドとリード間の連携に対する脅威分析フレームワーク

Transcript

1. コマンドとリード 間の連携に対する 脅威分析フレーム ワーク ちゅらデータ データビジネスコンサル 工藤 由美
2. 前提となる基本原則 皆さん、当たり前にしておいてほしい原則 2026/1/14
3. YAGINI原則 「今、本当に必要な機能だけを実装せよ」 （You Ain't Gonna Need It ＝ それはきっと必要にならない） 未来の予測はたいてい外れるため、作り置きは「時間の無駄（実装・維持コスト）」や 「バグの温床」になるから。 2026/1/14
4. KISS原則 「シンプルにしとけ、半人前が～ オーマイガー！ 」 ほとんどのシステムは、複雑にするよりもシンプルに保つ方がうまく機能する。 真の意味：「Simple」は「Easy」ではない ほかの原則を満たした結果、このKISSになるって感じ。 2026/1/14
5. 今日話さないこと アーキテクチャ仮説の検証データとなるメトリクスのお話とかはしません。 アーキテクチャメトリクスなどの本があるので、そっち見てちょうだい。 細かい品質特性、副特性の話は、ISO25010とかの規格をごらんあれ。 2026/1/14
6. 今回の背景と問い 2026/1/14
7. 今回のLTの背景 「メッセージの順序がばらばらのまま処理したり、重複して処理したりすると、読み取 りモデルのデータの一貫性を保証できません。 非同期投影は、新しい投影の追加や既存の投影の再生成が難しくなります。 これらの理由から、常に同期投影を実装し、オプションとして非同期投影を追加するこ とをおすすめします。」(ドメイン駆動設計をはじめようより引用) 、、、、、ホンマか？？疑 今一度、同期・非同期のリスクの違いを確認しよう。 2026/1/14
8. 今日の最大の問い そのコマンドとリードの連携は本当に問題ないと言えるのか？ われわれ「DDD本の同期連携がシンプルで分かりやすい」 という言葉を鵜吞みにしていないだろうか？？ 2026/1/14
9. アジェンダ ① 仮説キャンバスによる論点整理と主張 ② 同期と非同期連携の特徴 ③ CQRS Linkage Threat Matrix の紹介 ④ まとめと紹介 2026/1/14
10. 仮説キャンバスによる論点整理と主張 市谷聡啓さんの仮説キャンバスを用いて、本日の目的などを 整理してみた。 2026/1/14
11. 2026/1/14
12. 今日の最大の主張 「机上の設計モデルに対して脅威分析をせよ！」 完成、デプロイしてからじゃ遅い！！ 机上で考えられるものをなぜ後回しにするの？ (なぜベストを尽くさないのか？ 略：なぜベス) 2026/1/14
13. 例えば、こんな感じ なぜベスのアプローチ わらわのアプローチ 2026/1/14
14. おまえは何者だ？ 現在所属：今月より、ちゅらデータ データビジネスコンサル タイミーの広報のK氏からは、ハンコックと呼ばれている 特技：モデリング、仮説検証、抽象化、プロセス改善、パンダ 所属コミュニティ：DAMAデータ分科会、脅威モデリング東京(運営) 経験：ある案件の人命のかかわるドメインは業務監査ログの仕組みがマストだった。 やってきた役割：  ビジネスアーキテクト(業務オペレーション設計改善、運用)  要求モデリングとスクラム回す 2026/1/14
15. 同期と非同期連携の特徴 コマンドとリード間の連携の仕方の違い 2026/1/14
16. 同期連携のメリット 物理DBは共有するスタイル。 • 結果整合とかなくてシンプル • 整合性（Consistency） これにより、 ユーザー体験（UX）の圧倒的勝利 例)自分の書き込みがすぐ読めるor 失敗したら即時エラー。 アプリケーション設計のシンプルさ インフラストラクチャー上の設計・ 運用における恩恵は、 ① コンポーネントが少ない ブローカーの構築とか不要 ② トラブルシューティングの容易さ （可観測性） ③ 「キュー詰まり」の概念がない 2026/1/14
17. 同期連携のデメリット- 爆発半径 2026/1/14 ※サーキットブレーカーがどうのとかは今日は無視
18. クリーンアーキの図で表現すると、、、 2026/1/14
19. リードが複数ある時の同期連携は地獄 図のように、3つのリードモデルと同期連携で あったとする。 この時、全体の稼働率は、 0.99×0.9×0.9×0.8=64.152% コマンドサービスを叩いた結果は、 約3回に1回以上の確率でエラーになります。 そして、これがコマンドの可用性となる。 (必ずボトルネックに縛られる) 2026/1/14
20. 非同期連携(イベント駆動)のメリット 物理DBもコマンド・リードで別スタイル。 UX：システムが止まらない快適さ アプリ：疎結合なので、片方のみスケール インフラ： 爆発半径の完全な遮断（Fault Isolation） 例)図の一番上のリードとのみ同期連携なら 0.99×0.9=89.1%が全体稼働率 2026/1/14
21. 非同期連携のデメリット • UX：データが反映されてない、エラー通知遅れ • アプリ：非同期特有の複雑さ • インフラ：管理すべきコンポーネント増加するので運用・監視の泥 同期連携よりは、確実にKISSを満たせていないって言える構造でシュ 2026/1/14
22. CAP定理 ３つの特性からなるもの。 2つまで満たせるが、すべてを満たすことは絶対に できないというもの。 同期：AとPを捨てCに振り切っている 非同期：C捨ててP&Aに振り切っている 2026/1/14
23. そもそも論さ あなた達、実装前に机上で考えた設計モデルに対して、脅威分析してる？ • 保守の観点では？←まさかこの観点だけで意思決定してないでしょうね？ • セキュリティの観点では？ • パフォーマンス観点では？ • 可用性の観点では？ • データの品質の観点では？(リードに反映されてないとかetc) 2026/1/14
24. 設計モデルを批判的に多角評価せよ • レーダーチャートの図を再利用 • 期待値計算でスコアリング 2026/1/14
25. 評価軸を毎回探すのは大変、、、 この多角評価軸を毎回議論するのって、大変だと思いません？ そこで、今回Geminiとめっちゃ壁打ちしてきて、 文脈に依存しない汎用性の高いCQRS用の脅威分析フレームワークを持ってきました。 2026/1/14
26. CQRS LINKAGE THREAT MATRIX CQRS用の脅威分析フレームワーク 2026/1/14
27. CLTM～8つの観点で分析 • 結合度と爆発半径 • データ整合性 • セキュリティ • 容量 • 互換性 • 可観測性 • コンプライアンス • 副作用と再実行 2026/1/14
28. 具体的なFWの活用手順 ① モデル上でコマンドとリード間に連携線を引く ② フレームワークの８つの問いかけを行う その赤線の上で、「ここが切れたら？」「ここから漏れたら？」「ここが詰まった ら？」と批判的に自問する。 ③ リスクのスコアリング ④ 同期・非同期比較してユーザーストーリー観点で意思決定 2026/1/14
29. こんな感じ～収まりきらないので一部 2026/1/14
30. ①結合度と爆発半径 「片方が死んだら道連れになるか？」 同期通信 連鎖障害 リードの高負荷・ダウンが、コネク ションプールを枯渇させ、コマンド （書き込み）も全停止させる。 非同期通信 部分機能不全 部分機能不全と複雑化道連れは防げる が、QueueやBrokerなど管理すべきイ ンフラ部品が増え、システム全体の故 障発生率は上がる。 2026/1/14
31. ②データ整合性(CONSISTENCY)と順序 「データは嘘をついていないか？」 同期通信 【脅威なし (Safe)】 ACID特性により強力に保護される。 書き込んだ瞬間、誰もが最新データを 見れる。 非同期通信 【結果整合許容】 「書き込み直後にデータがない」「更 新順序が逆転する」などの事象が発生 し、アプリ側でのハンドリング漏れが バグになる。 2026/1/14
32. ③データ漏洩と権限(セキュリティ) 「複製されたデータは誰が見れるか？」 同期通信 一点突破！！ DBさえ守れば安全だが、破られれば全 漏洩。 非同期通信 攻撃対象の拡大 ログ、イベントバス、DLQ（死信 キュー）、検索エンジンなど、データ が分散・複製されるため、暗号化漏れ やアクセス権設定ミスが多発する。 2026/1/14
33. ④容量と飽和 「パイプが詰まったらどうなるか？」 同期通信 【リソース競合 】 複雑な検索クエリがCPUを占有し、重 要な注文処理を遅延させる。 (単一DBの性能限界) 非同期通信 【詰まりと破裂】 処理速度の差によりキューが無限に溢 れたり、PostgreSQLのWAL（ログ）が 肥大化してディスクを食い潰しマス ターDB停止、、、。 (バッファ管理の難しさ) 2026/1/14
34. ⑤バージョン管理と互換性 「データの形の変更で読み手が壊れないか？」 同期通信 【脅威なし (Safe)】 アトミックなデプロイにより、DBとア プリの整合性は常に保たれる。 非同期通信 【ポイズンピル 】 スキーマ変更（項目のリネーム等）を 含むイベントが流れた瞬間、対応して いないConsumerが一斉にクラッシュし て死に続ける。 (契約不履行による破壊) 2026/1/14
35. ⑥可観測性 「イベントがどこで消えたか、即座に特定できるか？ 同期通信 【脅威なし (Safe)】 スタックトレースを見れば原因が即座 にわかる。 非同期通信 【迷宮入り】 「どこでイベントが消えたか？」を追 うために、高度な分散トレーシングが 必要。ログが分断され、原因究明に数 日かかることもある。 (ブラックボックス化) 2026/1/14
36. ⑦コンプライアンス 「データを完全に消してと言われたら、全てのコピーを消せるか？」 同期通信 【脅威なし (Safe)】 DELETE文で物理削除が完結する。 非同期通信 【データゾンビ】 ユーザー削除依頼があっても、エラー キューやリプレイ用ログの中に平文の 個人情報が亡霊のように残り続け、法 規制（GDPR等）に違反する。 (完全削除の困難さ) 2026/1/14
37. ⑧副作用と再実行 「過去のイベントを再処理時、外部への影響(メール/決済)は防げる？」 同期通信 【脅威なし (Safe)】 ロールバックすれば、メール送信など もキャンセルしやすい。 非同期通信 【リプレイストーム 】 障害復旧でイベントを再処理した際、 メール再送信や二重決済などの副作用 が暴発し、顧客に被害を与える （冪等性の欠如）。 2026/1/14
38. ※脅威とリスクは違う リスク＝脅威にスコアリングしたもの 2026/1/14
39. リスクスコアリング 脅威を特定したら、モデル見ながら • 発生頻度 • 影響度の大きさ を仮説でいいので、 各観点でリスクスコアを出してみる。 ※あくまで主観が入るので正確性には欠 けるが、やらんよりはマシ。 2026/1/14
40. トータルのスコアをレーダーチャートで出す 図の８角形にプロットして、 • 同期連携 • 非同期連携 の比較を定量的に行う。 同期から非同期に変えたら、これだ けリスクが増えるよと認知するのだ けでも大事！！ 2026/1/14
41. 段階的に進化させよう いうても、一番最初から非同期なんて、危険すぎるから ① Start Simple：最初は「同期・物理共有」で始める（YAGNI）。 運用業務(復旧作業)の設計を事前におおわくでもいいからモデルベースで考えておく。 ② Analyze First：移行検討時は、コードを書く前に脅威分析（CLTM）を行う。 全8項目の複数観点で行う。 ③ Trade-off：アーキテクチャ変更による「メリット」だけでなく、「新たな脅威」 を受け入れられるか判断する。 学習効果高めるため、１ステップで１つの変化という、単一責務を意識しましょう。 2026/1/14
42. 今日のまとめ CQRS Linkage Threat Matrix 2026/1/14
43. 図描く→脅威特定→リスク評価 前提：特殊な場合除いて、基本は同期から始めるYAGNI戦略で行きましょ。 ① モデル上で脅威分析しましょう。その際にCLTMのフレームワークに沿って脅威を特定 しましょう。 ② その後に発生頻度×影響度の2軸で評価して、各観点のリスクポイント出す。 ③ レーダーチャートで、トータルリスクスコアを出す。 ④ 同期から非同期にする際に、どの程度リスクが増えるのか認知してから意思決定。 このときに、UX向けにユーザーストーリーマップで顧客に説明しましょう。 2026/1/14
44. ※最後に - FW自体を疑え 今回紹介したフレームワークの観点は、あくまでも汎用的なものにすぎません。 個々の文脈に応じて、不要な観点もあれば、追加すべき観点もあります。 何がデータの品質、アプリやインフラの品質の評価軸として不明な場合に、 初手として使い、使う中で不要な軸は削除するなど守破離してください。 それでこそ、フレームワークはより洗練されます。 守破離→守破離→守破離→守破離の反復！！！ 2026/1/14