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

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

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