第2回 雲勉LT大会 クラウド時代は CRUD ではなく CQRS で考えよう

Transcript

1. 第2回 雲勉LT⼤会 クラウド時代は CRUD ではなく CQRS で考えよう
2. ⾃⼰紹介 2 井上 迪也（いのうえみちや） • あだ名︓みちのすけ • 所属︓アジャイル事業部 • アイレット歴︓2022年度 新卒⼊社（3年⽬） • 趣味︓バイク（予定） • 社内活動︓もくもく会（ブログリレーなど） IPA : 応⽤情報、データベース
3. ⽬次 3 ・CRUD ・CQRS ・AWS で実装 ・メリット / デメリット ・CQRS とクラウドの相性
4. 4 「API のデータベース 何を使う︖」 安くてスケールするのは DynamoDB だけど、 フィルタとか JOIN とか考えると RDS がいいな あ るある な 話題
5. CRUD 5
6. 6 $ SFBUF 3 FBE 6 % QEBUF FMFUF
7. RESTful API 7 $ 3 6 % 1045 QPTU (&5 QPTU (&5 QPTUJE 1"5$) QPTUJE %&-&5& QPTUJE
8. 8 $ SFBUF 3 FBE 6 % QEBUF FMFUF ← 特性が違う
9. 9 R CUD キャッシュ可能 トランザクション・整合性 たくさん叩かれる レスポンスは最⼩限でいい 複雑なフィルターやクエリ 複雑なドメインロジック
10. 10 全く違うことをごちゃ混ぜに考えると、 「パフォーマンスの低下」や「ロジックの複雑化」が発⽣する
11. CQRS 11
12. 12 $ SFBUF 3 FBE 6 % QEBUF FMFUF $PNNBOE 2VFSZ （更新系） （取得系）
13. 13 $234 ʢ$PNNBOE
    2VFSZ
    3FTQPOTJCJMJUZ
    4FHSFHBUJPOʣ コマンド・クエリ責務分離 更新系と取得系を別々に考えるパターン
14. AWS で CQRS を使って実装してみる 14
17. 17 イベントソーシング
18. 18 Insert をトリガー RDS に書き込む
19. 19 DynamoDB の積み重なったイベントをもとに、 現在の状態を導出
22. CQRS の メリット 22
23. CQRS の メリット 23 ・取得系と更新系のパフォーマンスを別々に最適化できる ・ロジックが簡潔になる ・更新系の変更が、取得系に影響を与えない
25. CQRS（というかイベントソーシング） の メリット 25 ・全てのイベントが保存され、デバッグや監査が簡単 ・過去のイベントから現在の状態を導出できるため、 取得系の DB の変更も可能
27. CQRS の デメリット 27
28. CQRS の デメリット 28 ・データは結果整合性 ・Query と Command を個別にマイクロサービス化するようなもの ・構成要素が増える ・デプロイが増える ・トランザクションの複雑化
29. CQRS とクラウドは相性がいい 29
30. CQRS とクラウドは相性がいい 30 ・イベントドリブン ・ユースケースに適したサービスを使うことで、 コストやパフォーマンスを最適化できる → RDS のリードレプリカなどは、AWS が提供してくれている CQRS なソリューションの⼀つ
31. 31 アーキテクチャとして採⽤しなくても 更新系・取得系で切り分けて考えるのは重要 アーキテクチャとして、 CRUD ではなく CQRS という選択肢もある
32. 32 iret.media の「もくもく会ブログリレー」でも公開予定︕ 7 / 14 (⽇)
33. 33 ご清聴ありがとうございました 🙇