[レポート][API320-R] Amazon EventBridgeを使用して、イベント駆動型アーキテクチャをかつてないほど迅速に構築 #reinvent #API320-R

こんにちは。芳賀です。 AWS re:Invent 2019に参加していますのでレポートします。

このブログは下記セッションについてのレポートです。

Building event-driven architectures faster than ever with Amazon EventBridge Presented by Mike Deck Companies are increasingly opting to build applications using event-driven architectures to improve application scalability and reliability. In this session we’ll review the basics of event-driven architectures, and reveal how new features in Amazon EventBridge can dramatically reduce the time and code required to build applications that react to events. EventBridge can now discover the available events and automatically generate code from their structure and contents. Through use cases and examples, we’ll review how to simplify the process of ingesting, routing, and processing events from your own apps, AWS services, or SaaS apps. With the launch of schema registry, Amazon EventBridge can now discover the available events and automatically generate code from their structure and contents.

re:Invent Event catalog

レポート

event-driven kids

• 父と子供のやり取りをAPIにたとえた
  • 父が子供へ靴が欲しいか？request
  • レスポンスとして200
• もし幼児なら？
  • 父が靴が欲しいか？request
  • 遊んで欲しいよー503レスポンス
  • 父が靴が欲しいか？request
  • 400 bad request errmsg:don't want to

Event-driven Benefits

• スケールと個別の失敗
• 素早い開発デプロイ
• Audit with ease
• コスト低減

Event Router選択

• イベントは提供者から消費者へ
• １対１よりもｎ対ｎの関係性
• Event Routerでやり取りをシンプルに
• そのためのサービスが、Amazon EventBridge

Amazon EventBridge Overview

• EventSourceとしてAWSサービスやSaaSなどがある
• 
• その他のEvent Routers
  • Amazon SNS(Serverless pub/sub)
  • Amazon MQ(Managerd message broker)
  • Amazon Kinesis(Data streaming)
  • Amazon Kafka(Data streaming)

Event-Busの種類

• Default
  • AWS サービス
  • S3やEC2からEvent Bridgeへ
• Custom
  • アプリケーションイベント
  • 独自アプリからのイベントをEvent Bridgeへ
• Partner
  • SaaS events
  • DATADOGなどのSaaSサービスからのイベント

Event の受け方

• 複数のソースから１つのEvent Busへ渡すのが良いでしょうか？
• それともソースごとにEvent Busを分けた方が酔いでしょうか？
• 答えは、ソースが複数でもEvent Busを１つもしくはシンプルにする必要があります
  • 
• Event Busでは１つのメッセージを幾つかの処理へ通知したりします。
• Domainを定義し、サブドメイン単位でEvent Busを分ける事も効果的です

レガシーシステムを移行

• eventに対してフルステートなアプリでは必要以上の情報が返却されます。
• またメッセージの発生元が複数の場合、それぞれを個別に意識する必要があります。
• Eventメッセージの解剖
  • 

Schema Registry and Discovery

• スキーマを共有するための真実の源
• スキーマの明示的に公開および自動検出
• VS CodeとJetBrainsの統合
• Java、Python、またはJavaScriptのバインディング
• 以降、デモでAmazon EventBridgeスキーマレジストリとディスカバリーの紹介に近い内容のことを実施。

デモで構築したアーキテクチャ

• Shopサイトへ評価の書き込み
• 書き込まれた評価点数が一定以下だった場合、Zendeskへ登録する
• 
• 

まとめ

Event bus などを利用する事で、コーディングを少なくし、さまざまなサービス連携を可能となります。 イベントドリブンなアーキテクチャでシステムの連携をし易くしていくことが必要です。

感想

サーバレスでアプリを開発する場合、API-Gateway+Lambdaが鉄板と思っていたが、イベントドリブンでコードをなるべく書かずにアプリ間を連携させ、メッセージもスキーマ管理するサービスがプレビューされたので、今後はEvent busを活用したアーキテクチャで開発した方が開発コストも保守コストも下がりそうなので、とてもおススメできる内容だと感じたセッションでした！！