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