CQRS+ES on GCP

copyright Fringe81 Co.,Ltd.
CQRS+ES on GCP
2018.3.27
GCPを活用した戦略的な新サービス開発の裏側@Fringe81

About me (@mtoyoshi)
・サーバーサイドエンジニア
・ScalaとGolang書いてます

共に働く仲間と送り合う
ピアボーナスを実現するサービス
〜サイレントヒーローの発見〜

－－copyright Fringe81 Co.,Ltd.
事業化判
断
2. Fringe81の新規事業の開発フェーズ
事業企画
以下のフェーズを意識して、
実現性検証
プロトタイピン
グ
ローンチ
にむけた
開発
ローンチ
直後の
サポート
フェーズ1 フェーズ2 フェーズ3 フェーズ4 フェーズ5

今回の戦を略す話：
1. アプリケーション開発以外との戦い
2. 美しさ vs 速さの二項対立との戦い
3. 障害やバグの原因究明の時間との戦い

少ないエンジニアリソースでのスタート
アプリケーション開発に集中したい
Google App Engine (PaaS) を採用

GAE選定で悩んだ話はこちらの資料に

理想
ドメイン世界の表現
モデル的/コード的妥当性・美しさ
（メンテナンス性）
パフォーマンス
現実はトレードオフの
関係になりやすい

It is not possible to create an optimal solution
for searching,reporting,and processing transactions
utilizing a single model.
-CQRS documents by Greg Young-

It is not possible to create an optimal solution
for searching,reporting,and processing transactions
utilizing a single model.
-CQRS documents by Greg Young-
２軸を包括するモデルの定義はかなり難しい

２軸を
操作(CRUD)レベルに
落とし込むと

更新系(CUD)の処理

検索系(R)の処理

更新系検索系
アクセス量に
占める割合
少多
スケール性 △ ◎
複雑さの傾向ビジネスロジック
データ量と応答速度
複数切り口での見せ方
(R)DB傾向正規化非正規化（速さ重視）
特性の違い

２軸の違いを素直に受け止め
別々に管理・開発していこう
Command
Query
Responsibility
Segregation
コマンド
クエリ
責務
分離

Command
Adapters
DB
UseCases
Entities(Domains) Repository
RepositoryImpl
Controller
UseCase
Presenter
DDD x CleanArchitecture

Command (GAE flexible)
Adapters
DB
UseCases
Entities(Domains) Repository
RepositoryImpl
Controller
UseCase
Presenter
DDD x CleanArchitecture
GAE flexible x Scala
※ScalaはFringe81のメイン言語で最も使い慣れている

Query
Controller
DAO
DB

Query (GAE standard)
Controller
DAO
DB
GAE standard x Go
※GAE standard x Goの組み合わせは
スケール性能抜群でQ要件にとてもマッチしている

内部のソフトウェアアーキテクチャも
プログラミング言語も
GAEの種類も異なるものとなった
２軸の違いを素直に受け止め
別々に管理・開発していこう

Command
App Engine Flexible
Query
App Engine Standard
Cloud
Pub/Sub
microservice1
microservice2
マイクロサービス群の連携は
ドメインイベントのPublishとSubscribeで実現
Event

Command
App Engine Flexible
Query
App Engine Standard
Cloud
Pub/Sub
microservice1
microservice2
Cloud Datastore
より複雑なクエリへの対応にも
（C側に影響を及ぼすことなく：疎結合）
Cloud SQL
Event
Event
Event

ここでEventについて
もう少し理解しておきたい

Message-driven
vs
Event-driven
The Reactieve ManifestoのGlossary集より
(https://www.reactivemanifesto.org/glossary#Message-Driven)

■定義
Message: 特定の送り先に送られたデータ
Event: ある状態になったコンポーネントが送出するシ
グナル（過去に起きた事象をあらわす: fact）

メッセージ駆動では
受信者はメッセージの到着を待って
メッセージに反応しそれ以外は休眠状態
誰に送るのかに関心

イベント駆動では
イベント発生時に実行できるよう
通知リスナはイベントをアタッチする
　　　何が起きたのかに関心

MessageやEventが伝わる伝送路のことを
一般化してChannel※と呼ぶとすると
※Enterprise Integration Patternsより

EventのChannelがCloudPubSub
（イベントに関心があるものは複数ある）

MessageのChannelがCloudTasks※
（誰に送るのかに関心）
※現在はα版です。TaskQueue

Command
App Engine Flexible
Query
App Engine Standard
Cloud
Pub/Sub
microservice1
microservice2
Cloud Datastore
改めてこの図
Cloud SQL
Event
Event
Event

Command
App Engine Flexible
Query
App Engine Standard
Cloud
Pub/Sub
microservice1
microservice2
Cloud Datastore
Eventは揮発性だと気付く
Cloud SQL
Event
Event
Event

Command
App Engine Flexible
Query
App Engine Standard
Cloud
Pub/Sub
microservice1
microservice2
Cloud Datastore
「後から追加できる」という特徴との
コンフリクトが少なからず存在する
Cloud SQL
Event
Event
Event

どういうことか？

microservice1
Cloud Datastore
Cloud SQL投入時点で過去のデータをもとに
加工したデータを入れておく必要あり
（さも最初からあったかのように振る舞うために）
Cloud SQL

microservice1
Cloud Datastore
出来ないこともある
Cloud SQL

INPUT
Cloud SQL
OUTPUT
Cloud SQLのデータを作るのはSubscriber
OUTPUTを作るにはEventを入れないと

過去に発行されたEvent群がなければ
さも最初からあったかのように振る舞うための
データを満足に作ることは出来ない
Cloud SQL
INPUT
OUTPUT
※もちろん要件によっては必ずしもイベントを INPUTにしなくても
datastoreの現在の状態をもとにしても作れる

Eventに永続性を

Command
App Engine Flexible
Query
App Engine Standard
Cloud
Pub/Sub
microservice1
microservice2
Cloud Datastore
publish対象のEventと同じものを永続化
Event
Event

Got: 3
Got: 6
Lost: 1
①イベント追加
②イベント追加
③イベント追加
イベントが発生するたびに永続化
（ここでは何らかの値を得たり失ったりするイベントが発生）

“Eventは過去の出来事をあらわす”
過去の積み重ねが現在の状態をあらわす

Got: 3
Got: 6
Lost: 1
value = 8
<DB世界> <プログラム世界>
イベント群から状態を復元する
(+3 + 6 -1)

このようにEventを永続化してEventをもとに
アプリケーション状態を表現する方法を
Event Sourcingと呼ぶ

value: 3
value = 8
<DB世界>
<プログラム世界>
① 最初の状態は3
② 9に更新
③ 8に更新
一方、お馴染みのこちらはState Sourcing
value: 9
value: 8

Eventは過去の出来事、事実
Immutable
Stateは変わり続ける
Mutable

Event Sourcingにはどういうメリットが？
参考：CQRS Jornery (https://msdn.microsoft.com/ja-jp/library/jj554200.aspx)

メリット要約
Performance ESにおいては永続化はイベントの append-only。
更新処理のパフォーマンス改善が望める。
Simplification factとしてのイベントを保存するだけ。
O-R間のインピーダンスミスマッチが起きない。
Audit trail システムで何が起きてその状態なのかの追跡が可能となり、監査ログとして使える
Integration with
other subsystems
疎結合を促す。
また、他のサブシステムへ publishした全てのイベントは eventStoreに保存されている。
Deriving additional
business value
from the event
history
将来起こるビジネス要件を予想することは困難だが全てのイベント履歴を持っていることで対処
可能性が高まる。
例：ある時点での状態がどうであったかにこたえられるなど
Production
troubleshooting
本番環境のデータをテスト環境にコピーするなどして状態の再現を簡単にできるためトラブル
シューティングに役立つ
Fixing Errors ESの場合factとしてイベントが保存されているだけなので、コーディングエラーを修正するだけ
でDB値を手動メンテせずにすむ場合がある
Testing テスト容易性が高まる
Flexibility イベント群があればいかなる構造のデータにも変換可能

メリット要約
Integration with
other subsystems
Deriving additional
business value
from the event
history
Production
troubleshooting
イベント群があれば
いかなる構造のデータにも変換可能
（さきほど紹介したもの）

メリット要約
Integration with
other subsystems
Deriving additional
business value
from the event
history
Production
troubleshooting
ESにおいては永続化はイベントのappend-only
更新処理のパフォーマンス改善が望める

メリット要約
Integration with
other subsystems
Deriving additional
business value
from the event
history
Production
troubleshooting
システムで何が起きてその状態なのかの
追跡が可能となり監査ログとして使える

DB内のイベント群と
アプリケーションログ
ミスが疑われた場合
突き合わせができるので
ミスの発見だけでなく
どこがおかしいのか
あたりをつけることもできる
Got: 3
Got: 6
Lost: 1
・
・
・
・
・
・
・
・
・
・・
・

以上が主なEvent Sourcingのメリット

よーし、俺たちも次のプロジェクトから
StateSourcingやめてEventSourcingだ!
...とは多分ならない

頭では分かっても
慣れ親しんできたやり方を捨てる
のは厳しいし新しすぎて不安
私達も同じでした

自分たちの場合はここぞ！
というところからはじめた
ピアボーナスシステムで絶対にミス
してはいけない獲得ボーナス額

DB内のイベント群と
アプリケーションログ
ミスが疑われた場合
突き合わせができるので
ミスの発見だけでなく
どこがおかしいのかあたりをつけ
ることもできる
Got: 3
Got: 6
Lost: 1
・
・
・
・
・
・
・
・
・
・・
・

ちなみに新しい概念と思っていたものの
実は意外と古くからありました

最後にEvent Sourcingの
弱点とその克服を２つほど紹介

Event Sourcingの
弱点その１

Got: 3
Got: 6
Lost: 1
クエリに弱い
Got: 2
ex.値が7以上のもの一覧を取得
select * from table where value >= 7
のようにはいかない厳しさ

value: 8
クエリに対応するためのQ用DBが必要
※CQRSとESが一緒に語られる理由はこれだと思う
value: 2
Q
Got: 3
Got: 6
Lost: 1
Got: 2
C

Event Sourcingの
弱点その２

イベントが積み上がってくると
状態復元のパフォーマンスが悪くなる

イベントが積み上がってくると
状態復元のパフォーマンスが悪くなる
加えてDatastoreの場合は
オペレーション数課金なのでコスト面でも懸念

100Events：約60ms
500Events：約160ms
1,500Events：約420ms
3,000Events：約940ms
やってみた

大量イベントのロードは
StackdriverTrace上で
見ても大変なことに

〜 Snapshot機能〜
任意のタイミングで
Eventレコードをまとめあげた地点をつくり
ロードするレコード数を減らす

Got: 3
Got: 6
Lost: 1
value:8
Snapshotテーブル

value:8
Got: 3
Got: 6
Lost: 1
Got: 10
Lost: 2

value:8
プログラム
③ value = 16
Got: 3
Got: 6
Lost: 1
Got: 10
Lost: 2
①
②

まとめ

1. GAEいいよ！

2. CQRSいいよ！

3. Event Sourcingいいよ！
（EventとアプリログのWチェック）

CQRS+ES on GCP
ありがとうございました

CQRS+ES on GCP

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CQRS+ES on GCP

Similar to CQRS+ES on GCP (20)

More from Masaki Toyoshima

More from Masaki Toyoshima (8)

CQRS+ES on GCP