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

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

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

今回ご紹介するセッションは、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に何らかの情報(アイテムの追加、変更、削除)が発生したら、それに伴い税金が料金の計算を行うというものです。

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

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

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

Guaranteed delivery
Processing events in order
Replaying past events

■ Guaranteed deliveryについて

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

■ Processing events in orderについて

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

■ Replaying past eventsについて

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

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

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

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

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

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

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

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

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

About 武井宜行 269 Articles

Microsoft MVP for Azure🌟「最新の技術を楽しくわかりやすく」をモットーにブログtech-lab.sios.jp)で情報を発信🎤得意分野はAzureによるクラウドネイティブな開発(Javaなど)💻「世界一わかりみの深いクラウドネイティブ on Azure」の動画を配信中📹 https://t.co/OMaJYb3pRN