イベント・ソーシングを知る

5,522 views

Published on

0 Comments
22 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,522
On SlideShare
0
From Embeds
0
Number of Embeds
1,363
Actions
Shares
0
Downloads
19
Comments
0
Likes
22
Embeds 0
No embeds

No notes for slide

イベント・ソーシングを知る

  1. 1. イベント・ソーシングを知る より価値の高いソフトウェア開発 のために
  2. 2. なんのはなし?• ソフトウェアの設計的な話• ソフトウェアの情報をどのように永続化 して扱うか(ソーシング, Sourcing)• いつもと少し違うアプローチを紹介しま す
  3. 3. 例: 本のレンタルサービス1. ユーザが本を登録する2. 本はユーザなら誰でも借りられる3. 本を借りた人が本を返す4. 本がまた借りられるようになる(2に戻る)
  4. 4. 「フツーに」考える
  5. 5. たぶんこうなる 本テーブル的なものタイトル 貸し出しONE PIECENARUTO
  6. 6. たぶんこうなる1. スタンが「HUNTER×HUNTER」を登録 タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  7. 7. たぶんこうなる1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER カイルが借り出し中
  8. 8. たぶんこうなる1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  9. 9. たぶんこうなる1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  10. 10. 状態を中心に考えるステート・ソーシング
  11. 11. ステート・ソーシング• 従来の一般的な考え方• ステート=状態• 状態中心のソフトウェア設計• あらゆる情報は状態が永続化される• 最新の状態を常に記憶しておくのが一般 的
  12. 12. フツーですね
  13. 13. 見落とされがちな問題• 現在の状態はわかるが…• 状態が変化した理由や経緯が全て失われ る• ソフトウェアにとって非常に価値の高い 情報• 履歴やログで記録をとるのは限界がある
  14. 14. ステート・ソーシングの問題を解決するためにイベント・ソーシングとは
  15. 15. イベント中心に捉える• 様々な出来事(イベント)の結果、状態が変 化する• 「状態」はイベントの結果に過ぎず、本 質ではないのではないか(という考え方)
  16. 16. イベントを記録する• ソフトウェアで起こる全てのイベントを 記録する• 記録されたイベントは変更や削除をしな い• 「状態」は記録しません!• 何が起きたかだけを淡々と記録します
  17. 17. ほんとにそのまま記録します1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる このままです タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  18. 18. いやいや、でも状態は必要で しょ?
  19. 19. イベントを再生する• 記録されたイベントを順に再生すること で、現在の状態を導出できる• 1つずつイベントを辿れば必ず今の状態に たどり着きます
  20. 20. イベントを再生する順番に辿ります1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる 記録されているイベン タイトル 貸し出し ト ONE PIECE NARUTO
  21. 21. イベントを再生する1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  22. 22. イベントを再生する1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER カイルが借り出し中
  23. 23. イベントを再生する1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  24. 24. イベントを再生する1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  25. 25. イベントを再生する1. スタンが「HUNTER×HUNTER」を登録2. カイルが「HUNTER×HUNTER」を借りる3. カイルが「HUNTER×HUNTER」を返す4. ケニーが「HUNTER×HUNTER」を借りる 最新の状態が再現 タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  26. 26. イベント・ソーシングのすごいと ころ• ソフトウェアの完全な履歴が手に入る• ソフトウェアの任意の部分あるいは全体 を「ある時点」に簡単に再現できる• 有用な設計と相性が良い – ドメイン駆動設計(DDD) – コマンドクエリ責務分離(CQRS)
  27. 27. イベント・ソーシングすごい!
  28. 28. 残念ながら問題点も
  29. 29. パフォーマンス• 「最新の状態」を得るために、毎回膨大 な量のイベントをリプレイしていたら大 変• 大量のイベントを捌かなければならない• ストレージ容量を多く使用する可能性
  30. 30. バージョニング• 仕様変更が起こったら、過去のイベント をどう処理するか• 最新の状態のみ影響を考えればよいス テート・ソーシングと違って、大量の過 去のイベントにも影響が出る
  31. 31. 実装が複雑• イベントを記録してリプレイする機構を 実装しないといけない• 様々な問題に対処するために、様々な仕 組みを導入する必要があり、さらに複雑 さに輪をかける – キャッシング – イベントのアップデータ – 参照系の処理への対処
  32. 32. 最後に• ステート・ソーシングの問題を認識する – 当たり前すぎて気づかなかったり• イベント・ソーシングの可能性 – いろいろ問題はありますが、ステート・ソー シングでは成し得ない価値の提供ができるの では?
  33. 33. 参考• Greg Young流CQRS - Mark Nijhof• Why Event Sourcing?• Event Sourcing and CQRS, Lets use it.• state ソーシング、 event ソーシング 【ス タイルの選択肢】• event とメッセージング 【きっと、良い パターン】

×