20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
27th Jan, 2021
Kensuke Shimokawa
今日から始める
イベントドリブンアーキテクチャ
@_kensh
AWS Expert Online JAWS-UG

Who am I?
Name
Kensuke Shimokawa
Company
Amazon Web Services Japan K.K.
Role
Serverless Specialist Solutions Architect
@_kensh

本セッションは
想定される聴講者
• AWSをご利用されている事業者、デベロッパー
• AWSを今後利用したビジネスを考えている方
• イベントドリブンアーキテクチャ構築に興味がある方
ゴール
• システムでのイベントドリブンアーキテクチャの使い所を理解していただく

イノベーションループ
Listen
Idea
Experiment
イノベーション
ループ
傾聴
アイデア
実験

"デリバリー速度"の獲得。
マイクロサービスの最大のメリットはビジネス変化に対応する
"デリバリー速度"の獲得。
でもAPIで作ったサービスは頻繁な変更に対応するのは難しいですよね。
なぜならAPIにはインターフェース契約があるから。
そこで、アイデアとして登場したのが ”疎結合” にマイクロサービスを組み立て
る、イベントドリブンアーキテクチャ。

Table of contents

アーキテクチャのゴールは
"デリバリー速度"の獲得

モノリスからマイクロサービスへ
Monolith
全てを担当
Microservice
一つの責務の組み合わせ

2001年のAmazonでは、、、
monolithic application
+ teams
2001
学び: アジリティのために分散が必要
2002
microservices
+ 2 pizza teams

アーキテクチャの結合度
小さなピースに分けて
ゆるく結合させたい

小さなピースをAPIで結合してみる
API
API

契約による結合
API
API
インターフェース契約
APIにはインターフェースを公開し
利用者に宣言する必要がある
利用者は公開者の宣言にしたがって
送信する義務を負う

互いに依存する
API
API
(API利用者)
契約を守らないと呼び出せない
(API提供者)
契約を破棄できない
不自然な維持、冗長な拡張

仕様と実装の乖離が許されないAPI = 契約
• 契約を記述する手段の進化
• 契約の配布やスキーマレジストリ
管理のマネージド化
• ただし、契約は公開されるが、強制できる
ものではない。
• そして、APIエコノミーへ
• クローズドなAPIからオープンなAPIへ

多様化、複雑化、膨大化する依存関係
API

“デリバリー速度”の獲得？
達成できたか？

同期的なAPIの課題
• 他サービスの障害に影響を受ける
• サービスのIPが変わった場合の発見が難しい
• API自体の数が増加し、クライアントへの統一した体験が提供しにくい
• HTTPリソースやメソッドごとに要件が複雑化

APIにおける様々な改善
• サービスメッシュ
• API ゲートウェイ
• サーキットブレーカー
• 集約ログ
• ポリグロット
• GraphQL
• サービスディスカバリ
(注意)
• 今回のセッションではイベントの理解の
ために、あえてAPIと比較をしています
が、APIとイベントは排他の関係ではな
く、通常は協調して利用します
• APIの管理方法も日々進化していますの
で、APIの課題がそのまま当てはまるわ
けではありません
※本日のセッションではAPIの管理方法の進化については割愛

event
[i-’vent] noun
システムの状態が変化
したことを示す信号

イベントとは
• イベントは状態の変化に関する情報をサービス間で共有するためのメカニズム
• Immutable – イベントは過去に遡っての修正はできない
• イベントには意味的な意図があり、過去形の動詞として表現可能,
• e.g. “customer_created”
• コンテキスト共通のプロパティによって、システムの相関を取っている
• e.g. “customer_id”

Eventは時系列に事実を
伝える手段
Time What
2021 01 21 08 07 06 CustomerCreated
2021 01 21 08 07 09 OrderCreated
2021 01 21 08 07 13 PaymentSuccessful
2021 01 21 08 07 17 CustomerUpdated
. . . . . .
イベントはWhatを伝える時系列データ

イベントは観測するものであり、命令ではない
命令としての command 観測による event

サービスとイベントルーティング機能を切り離す
プロデューサ、コンシューマ
の抽象化
イベントを選択して
フィルタリング可能に
プロデューサコンシューマ
ルーティング
送信イベント受信イベント
フィルタリング

応答性とサービス間依存度の違い
API Event

契約時
• API設計時にサービス間の契約を締結
• 変化のためにはサービス実装の変更
API
API
同期APIと非同期イベント配信の規約設定タイミング
イベント配信時
• 非同期実行による分散
• 障害伝搬リスクの軽減
• 変化のためには配信ルールの変更
Service A Service B
Message
Message
Service A Service B
Event
API Event

結合度を実例で確認 (同期API)
プロデューサ
コンシューマ
😀
受注
サービス
発送
サービス
会計
サービス
• プロデューサとコンシューマ
が密結合
• 複数サービスが障害ポイント
• サービスクオリティの低いも
のが全体のサービス品質を決
定
• 外部への依存度が大きく、拡
張性が乏しい

プロデューサ
コンシューマ
受注
サービス
発送
サービス
会計
サービス
が密結合
定
張性が乏しい
😩
ダウンストリームの
障害に影響を受ける

プロデューサ
コンシューマ
受注
サービス
発送
サービス
会計
サービス
在庫
サービス
が密結合
定
張性が乏しい
😀
新サービス追加
コードの修正が必要

結合度を実例で確認 (非同期Event)
プロデューサ
コンシューマ
😀
受注
サービス
発送
サービス
会計
サービス
が疎結合
• 各サービスは独立
• 品質、可用性管理を独自に実
施可能
• 外部への依存度が低いため、
拡張性が高い
Event

プロデューサ
コンシューマ
😀
受注
サービス
発送
サービス
会計
サービス
が疎結合
施可能
拡張性が高い
Event
ダウンストリームの
障害からの分離

プロデューサ
コンシューマ
😀
受注
サービス
発送
サービス
会計
サービス
が疎結合
施可能
拡張性が高い
Event
在庫
サービス
コードの修正不要
新サービス追加時に
Subscribeするだけ

イベントドリブンアーキテクチャを何で実装するか
プロデューサ
コンシューマ
😀
受注
サービス
発送
サービス
会計
サービス
• 実装の考慮点
• 可用性についての検討
• スケーラビリティにつ
いての検討
• サーバーの運用管理
• コスト見積もり
Event
在庫
サービス
この部分の
イベント管理をどの
ように実装するか

サーバーレスとは？
サーバーがない?
サーバーの存在を意識しない
• ユーザーコントロール可能なサーバーを前提としない
• AWS のフルマネージドな管理

サーバーレスを選択するビジネス価値
インフラのプロビジョニング不要
サーバー管理不要
自動でスケール
価値に対する支払い高可用かつ安全

サーバーレスの効能
＋
利用費の
適正化
作業量の
削減
＋
時間の
短縮

イベントの管理はサーバーレスサービスで
プロデューサ
コンシューマ
😀
受注
サービス
発送
サービス
会計
サービス
• インフラのプロビジョニング
不要、サーバー管理不要
• 自動でスケール
• 価値に対する支払い
• 高可用かつ安全
Event
在庫
サービス
サーバーレス

イベントドリブンのパーツ
非同期イベント
応答性を高め、相互依存性
を低減
イベントルーター
プロデューサとコンシューマを
互いから抽象化
イベントストア
ビジネスロジックのプロセスが
稼働可能になるまでストア可能

AWSのイベント、メッセージングサービス
イベントルーターイベントストア
キューストリームトピックイベントバス
サーバーレス
マネージドOSS
Amazon SQS
Amazon MQ
Amazon SNS
Amazon MQ
Amazon Kinesis
Amazon MSK
Amazon EventBridge

SNS Topic
Data
Amazon Simple Notification Service (SNS)
• Publish / subscribe モデルメッセージング
• 高スループット, 高信頼性メッセージング
• 複数のパブリッシャーに配信
• ファンアウト
• メッセージフィルタリンを利用して配信タ
ーゲットを指定可能
• 非同期Lambda実行

Message
SQS
Queue
SQS はLambda
サービス側で関
数から成功応答
が返った場合に
メッセージ削除
Amazon Simple Queue Service (SQS)
• 大量メッセージ
• メッセージのバッチ処理
• At least once 配信 (標準キュー)
• 複数回受信を防ぐ可視性タイムアウト
• 同期Lambda実行
• Lambdaはロングポーリング

Amazon Kinesis Data Streams
• リアルタイムメッセージング
• At least once 配信(Lambda統合時)
• Lambda関数はバッチ取得可能
• 1メッセージ内に論理バッチも可能
• 同期Lambda実行
Kinesis
Stream
Lambdaサービス
は、メッセージ
が期限切れで削
除されるまで、
ポーリング
Data

各モデルでのイベントハンドリング
イベントストアを
利用しない
(FIFOで順序)
高耐久性の
メッセージ処理
(FIFOで順序)
Amazon SNS
Amazon SQS
Amazon
Kinesis
高耐久性の
メッセージ処理
(順序の保証)

Amazon EventBridge
AWS Cloud
AWS Cloud
AWS Cloud
Amazon
EventBridge
異なるチーム、組織の間でも、Push型での情報連携（イベント通知）を
可能にするイベントバス

AWS Lambdaの非同期実行
Amazon S3
Amazon SNS
Amazon SES
Amazon
EventBridge
Amazon
CloudWatch Logs
AWS Config
Amazon
CloudFormation
AWS CodeCommit
AWS Lambda
Amazon SNS
Amazon SQS
Amazon
EventBridge
Lambda
Function
onSuccess
onFailure

イベントドリブン・ユースケース

ファイルアップロード処理
1. Amazon S3 バケットにファイ
ルをアップロード
2. Lambda関数の非同期実行
• イベントペイロード:
» Bucket name
» Object key
1
2
Lambda + Amazon S3
Amazon S3
Upload
Event
file
Lambda
Function

ファイルアップロード処理
3. Amazon Rekognitionを使用し
た画像解析
4. 画像解析の結果を保存
1
2
イメージ解析、データ永続化
Amazon
Rekognition
Amazon
DynamoDB
3
4
file
Upload
Event
Amazon S3
Lambda
Function

ストリームデータの取り込みと保存
1. LambdaがKinesis Data Streamからメッセージポーリング
2. 関数が同期的にLambdaサービスから呼び出される
3. 関数によるメッセージの保存
1 2
取得、処理、保存
Amazon
Redshift
Amazon
Elasticsearch
Service
3
Kinesis Data Stream Lambda Lambda
Function

ダウンストリームの保護
1. API Gatewayに到達したメッセージをSQSにバッファリング
2. 関数が同期的にLambdaサービスから呼び出される
• 同時実行数設定によるスループット調整
3. オンプレミスデータベースに対する、Lambda関数によるメッセージ
の保存
1 2
スループットの調整
3
Lambda Lambda
Function
Amazon SQS
Amazon API Gateway
オンプレミス
データベース
物理サーバー
低スループット
高スループット
202
accepted
低可用性、ローパフォーマンス

SaaSとのイベント連携
1. API Gatewayでの Webhookや、定期起動Lambdaによるポーリ
ングではなく、EventBridgeのイベントバス経由でイベント連携
2. イベントの種類に応じて各種マイクロサービスを実行
モニタリングアラームの受信
AWS Cloud
Amazon
EventBridge
アラーム

導入への流れ
Journey to event-driven architectures

イベントドリブンアーキテクチャ導入への流れ
STEP 1
ドメインに対する考慮

システムではなく、ビジネスのイベントを考えてみる

イベントをビジネスドメインに紐付ける
販売配送センターサポート

ビジネスプロセスを一旦オーケストレーションで考えてみる
販売
オーケストレーター
決済管理
1
4
6
注文イベント
2
在庫管理
3
5
7

ドメイン境界を越える処理をSubscriptionに置き換える
販売発送センター
注文入ったよ
注文が入ったら教えてね
Subscription
Notification
1
2
非同期Event

イベントドリブンのモデリング
EventStorming

STEP 2
イベントルータの選定

ルーターが必要になるかどうか？

まだ、必要じゃない？

本当に、まだ必要ない？

設計時にルーターを入れて非同期にできるかはまず確認！

STEP 3
イベントストアの選定

イベントストアで復元力とスケーラビリティを向上
ビジネスロジックサービスが処理可能に
なるまでメッセージをバッファリング
Event store

STEP 4
イベントスキーマの考慮

イベントはそのままの生の情報ではない
注文123は、顧客456に
よって午前10時47分に
作成されました。
注文123は、顧客456によっ
て午前10時47分に作成されま
した。現在のステータスは
オープンで、合計は$ 237.51
で、商品は…

必要となる属性を考える
123
456
注文123はどの
ユーザの注文？

Amazon EventBridgeイベントスキーマの例
{
"version": "0",
"id": "adeacade-c34c-ce58-c4a0-74f106398c4e",
"account": "123456789012",
"region": "us-east-1",
"time": "2019-12-02T21:46:19Z",
"source": "order-service",
"detail-type": "New Order",
"resources": [],
"detail": {
"orderId": "cfb2ae566f9b",
"customerId": "C12345",
...
}
}

{
"version": "0",
"id": "adeacade-c34c-ce58-c4a0-74f106398c4e",
"account": "123456789012",
"region": "us-east-1",
"time": "2019-12-02T21:46:19Z",
"source": "order-service",
"detail-type": "New Order",
"resources": [],
"detail": {
"orderId": "cfb2ae566f9b",
"customerId": "C12345",
...
}
}
Amazon EventBridgeイベントスキーマの例

イベントドリブン・デザインパターン

イベントドリブン・デザインパターン
• コレオグラフィ
• 全体の作業を制御する指揮者は存在せず、個々のサービスに予め与
えられた動作条件に従ってサービスを実行
• コマンドクエリ責務分離
• データストアの読み取り操作と更新操作を分離
• イベントソーシングパターン
• データに対して実行された一連のすべてのアクションを記録

コレオグラフィ - Choreography
Streams, Topics, Queues

マイクロサービスの依存関係グラフ
https://www.thoughtworks.com/insights/blog/scaling-microservices-event-stream
Event
APIで結合コレオグラフィー

コレオグラフィーパターンとは
• 必要なすべての情報を含んだ最初のイベントを 1 つのメッセージに保存し
て、最初のトランザクションを完了
• 他のサービスがそのメッセージを非同期的に取得し、それぞれのタスクを
完了させる
• サービスが疎結合になり、直接互いに影響を与えない
• メッセージの保存と取得が非同期の関係になり、スケーラビリティと信頼
性が向上

コレオグラフィーパターン
ユーザー
リクエストサービスリクエストキュー
サービスA
サービスB
サービスC

実装例1: SNS、 SQS、 Lambdaの利用
ユーザー
リクエストサービス Amazon
SNS
Amazon SQS
Amazon SQS
Amazon SQS
AWS Lambda
AWS Lambda
AWS Lambda
ファンアウト

実装例2: Amazon EventBridgeの利用配送
ポイント
プレミアム会員
カート
支払
支払い方法
認証
注文
１分毎に実行
Events
会員
ステータス
支払認証
カートに
入れる
注文完了
Amazon
EventBridge
リクエストサービスイベントバス

コマンドクエリ責務分離
CQRSパターン

コマンドクエリ責務分離パターンとは
• コマンドクエリ責務分離（Command-Query Responsibility Segregation：
CQRS）パターンはデータを更新するコマンドと参照するクエリを分離するこ
とで、ユースケースに応じて個別にスケールすることを可能とするパターン
• データソースを分離することで異なるデータ構造を取ることも可能となり、ク
エリ側はクエリで返すデータ転送オブジェクト（Data Transfer Object : DTO）
に合わせた形のスキーマとすることでオブジェクト関係マッピング（Object
Relational Mapping : ORM）のオーバーヘッドを軽減することも可能になる
• コマンド側とクエリ側が結果整合性を許容する必要がある

コマンドクエリ責務共有パターン
ユーザー
サービス
ドメインモデルドメインモデル
ORM ORM
データ転送
オブジェクト
クエリ
更新

コマンドクエリ責務分離（CQRS）パターン
ユーザー
コマンドサービス
ドメインモデル
データ転送
オブジェクト
クエリ
更新
クエリサービス
データ転送
オブジェクト
非同期
結果整合

実装例１： Kinesis Data StreamsとLambdaを利用
フロントサービス Amazon Kinesis
Data Streams
AWS Lambda
AWS Lambda Amazon Aurora
正規化テーブル
ユーザー
Amazon DynamoDB
非正規化テーブル

実装例２： DynamoDB StreamsとLambdaを利用
ユーザー Amazon DynamoDB
Streams
非正規化テーブル
AWS Lambda Amazon Aurora
正規化テーブル
フロントサービス

イベントソーシング
Event Sourcing

イベントソーシングパターンとは
• データストアを直接更新する代わりに、注文の発注、クレジット照会、出荷中
の注文など、ビジネスロジックに重要なイベントを耐久性のあるイベントログ
に追加
• イベントレコードは個別に保存されるため、すべての更新はアトミック (分割
不可かつ削減不可)
• 保存されたイベントを再度処理するだけで、アプリケーションのいかなる時点
の状態でも再構築可能

イベントソーシングパターン
ユーザー
プロセス
イベントログ
イベント
プロセスプロセス
状態

Kinesis Data Streams (or SQS FIFO)とLambdaによる実装例
ユーザー
Amazon Kinesis
Data Streams
AWS Lambda
イベント
メッセージ
状態
Amazon SQS
FIFO
or

選択における観点
Design Considerations

At-least once 配信
イベントは、ターゲットに複数回配信
されることも。処理されたイベントの
状態を追跡することによって重複イベ
ントを検出するロジックを含める
(冪等性)
配信セマンティクス
Exactly-once 配信*
AWSサービスに重複排除に使用す
る識別子を渡すことで重複排除
* Lambdaでリトライ設定している場合は、At-least
once
• Amazon EventBridge
• Amazon SNS 標準トピック
• Amazon SQS 標準キュー
• Amazon Kinesis
• Amazon SNS FIFO トピック
• Amazon SQS FIFO キュー

順序保証なし
イベント/メッセージが順序保証なしで
配信
順序セマンティクス*
順序保証
イベントは、パーティション、
メッセージグループなどの中で順
番に配信
（グローバルな順序保証はありません）
• Amazon EventBridge
• Amazon SNS 標準トピック
• Amazon SQS 標準キュー
• Amazon Kinesis
• Amazon SNS FIFO トピック
• Amazon SQS FIFO キュー
* 順不同のイベント処理ロジックが受入可能かは、ビジネス要件次第となります。順不動なイベントを処理する
ようにアプリケーションを設計できない場合は、代わりにオーケストレーションも検討

まとめ
マイクロサービスの最大のメリットはビジネス変化に対応する
"デリバリー速度"の獲得
• イベントドリブンアーキテクチャで疎結合にすることでデリバリー速度を高
める。
• AWSのサーバーレスサービスを利用することで、イベントドリブンアーキテ
クチャを素早く導入できる。
• アーキテクチャパターンや導入の道筋を知ることで、システム設計に活かす
ことができる。

Thank you!
@_kensh

Appendix

EventBridgeサービスクオータ（抜粋）
• PutEvents: Depends on region (2400-400), regional
• Invocations: Depends on region (4500-750), regional
• Buses per account/region: 100, hard limit
• Rules per bus: 300
• Targets per rule: 5, hard limit
• Event pattern size: 2048 characters, hard limit
https://docs.aws.amazon.com/eventbridge/latest/userguide/cloudwatch-limits-eventbridge.html

20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13

More Related Content

What's hot (20)

Similar to 20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13 (10)

More from Amazon Web Services Japan (20)

Recently uploaded (20)

20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13