Microsoft Build 2019レポート 〜 【セッション】Building event driven apps with Azure Functions and Azure Cosmos DB change feed 〜

build2019_entrance

こんにちは。サイオステクノロジー技術部 武井です。

今回ご紹介するセッションは、Event Sourcingパターンのアプリケーションを、Cosmos DBのchange feedをトリガーにしたAzure Functionsで実現しようという内容です。

本日までに聞いた数あるセッションの中で最も実践的な内容でした。

Event Sourcingパターンについては、詳細は以下に記載されています。

https://docs.microsoft.com/ja-jp/azure/architecture/patterns/event-sourcing

Event Sourcingというのは理論としては知っていましたが、どのように実践すればいいかといのは疑問符がついたままでした。しかし、このセッションを受講することによってクリアになりました。

Azure FunctionsとAzure Cosmos DB change feeを利用したEvent Sourcingの実現方法は以下の通りです(私の認識が間違っていなければ)。まず事前に以下のスライドのようなアーキテクチャを考えてみます。Cosmos DBに何らかの情報(アイテムの追加、変更、削除)が発生したら、それに伴い税金が料金の計算を行うというものです。

IMG_9311

  1. Change Feedを用いて、Cosmos DBの変更履歴をトリガーにしてAzureFunctionsを起動する。
  2. Azure Functionsで税金や料金の計算を行う。
  3. Azure Functionsで処理した結果を適宜別のデータストア(集計結果など)に保存する。

 

なるほど、Change Feedは簡単にCosmos DBへの変更履歴が取得できますし、Azure Functionsであれば、Cosmos DBのトリガーをサポートしているので簡単にEvent Sourcingが実現できますね。

ただし、本セッションではChange Feed + Azure FunctionsでEvent Sourcingを行う上で以下の3つの問題提起をしています。

  1. Guaranteed delivery
  2. Processing events in order
  3. Replaying past events

■ Guaranteed deliveryについて

きちんともれなくデータを処理できるかということを示します。これに対する解決策は、グローバルな分散機構や、SLA99.999%にカバーするとのことでした。

IMG_9314

■ Processing events in orderについて

商品の追加、削除、変更などをきちんと発生した順番に処理できるかということを示します。これは当然ですね。Event Sourcingにおいて、この順番が狂うと、結果の整合性を維持できなくなります。これについては、注文IDをパーティションキーにしてコンテナーごとに分散保存して対応するとしています。Change Feedへのクエリは、コンテナをまたがってできないためです。

IMG_9315

■ Replaying past eventsについて

過去のイベントに遡って処理できるかということを示します。例えば何からの理由でAzure Functionsが正常に動作しなかった場合、その間に発生したイベントは処理できません。そこで、本セッションでは、イベントの取得開始時間を手動で調整することによって、過去のイベントも取得できるとのことでした。

IMG_9317

 

上記の3つの問題の他にも、もう一つのユースケースについても問題定期がなされていました。それは、集計結果の取得についてです。

この件についてもEvent Sourcingあるあるですが、例えば、購入した商品の合計金額は、追加のイベントを全て合計しなければなりません。これは非常に手間です。今までのCRUDの概念をもとにしたState Sourcingであれば、SQL一発ですが、Event Sourcingではそうはいかないのです。

このセッションでは、これに対する解決策も提起されており、Materialized Viewを使うというものでした。

イベントが発生するごとに、つまりAzure Functionsが起動するごとに、集計データ用のドキュメントも合わせて作成しておくというものです。

本セッションでは、ピンボールゲームの例が挙げられておりました。

例えば、タケイさんが「1点入った」というイベントが発生したら、タケイさんようの集計結果格納用ドキュメントに1を足し、もう一度同じイベントが発生したら、また1を足して、今度は合計が2になります。タケイさんの取得した合計の点数が知りたい場合には、このドキュメントを取得すればよいのです。わざわざ、過去の「点数が入った」というイベントを全て取得して合計する必要はありません。

IMG_9329

 

かなり感激しました。これは、実際に構築してみて、また「多分わかりやすい」シリーズに加えたいなーと思いました。Event Sourcingどんと来いです。

なるほどー。これでEvent Sourcingは怖くない!!さぁ、案件に適用だー。

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメント投稿

メールアドレスは表示されません。


*