🗽

【re:Invent 2022】イベント駆動型アーキテクチャによる次世代アプリケーションの構築-Session Report

2022/12/02に公開

AWS

AWS re:Invent 2022で行われた、「Building next-gen applications with event-driven architectures」のセッションレポートです。

この記事は、要点・見どころ・ポイントについてまとめます。

セッション概要

Title

Building next-gen applications with event-driven architectures

イベント駆動型アーキテクチャによる次世代アプリケーションの構築

Overview

Event-driven architectures can solve many difficult problems in modern enterprise workloads. For example, it can be challenging to work with large amounts of data in different data stores and locations. Teams building microservices architecture often find that integration with other applications and external services can make their workloads more monolithic and tightly coupled. In this chalk talk, learn how to use event-based architecture to decouple and decentralize application components. Discover how you can use AWS messaging services to connect microservices and coordinate data flow using minimal custom code.
イベントドリブンアーキテクチャは、現代の企業ワークロードにおける多くの困難な問題を解決することができます。例えば、異なるデータストアやロケーションにある大量のデータを扱うことは困難な場合があります。マイクロサービスアーキテクチャを構築するチームは、他のアプリケーションや外部サービスとの統合により、ワークロードがよりモノリシックで密結合になることにしばしば気づきます。このトークセッションでは、イベントベースアーキテクチャを使用して、アプリケーションコンポーネントを切り離し、分散化する方法について学びます。AWSメッセージングサービスを使用して、マイクロサービスを接続し、最小限のカスタムコードでデータフローを調整する方法を発見してください。

Services

AWS Cloud Development Kit, Amazon EventBridge, AWS Step Functions

Session type

Breakout Session

Speakers

Eric Johnson, Principal Developer Advocate, AWS

Youtube

セッション動画が公開されてます

Report

ブレイクアウトセッションは主要開発支持者Yasser Alsaied氏が登壇
自己紹介からスタートして、彼がジョーク好きなようで会場は爆笑する場面が多くありました

参加者数は150名程度

エンタープライズ統合パターン

結合 ~統合の魔法の言葉~

結合は、接続されたシステム間の独立した変動性の尺度となる
結合の量はトレードオフの問題がある
デカップリングには、設計とランタイムにコストがかかる (複雑さとレイテンシが増加する)
ロケーションの結合として、IP (結合) と DNS (分離)を考慮する
同期と非同期の相互作用スタイルの依存関係がある
結合の適切なレベルは、エンドポイントに対する制御のレベルによって異なる

分散アプリケーションを構築するときに考慮事項を以下記載します。

同期リクエストレスポンスモデル

利点

低遅延
単純
早く失敗する

短所

故障前後(受信機の故障など)
バックエンドのエラーは送信者にプッシュされる
バックオフ、再試行などが必要となる
負荷が高すぎると、レシーバーがスロットルされる可能性があるので注意

非同期ポイント間 (queue)

同期・非同期処理で、ここから推奨するパターンが説明されました。
ここではSQSの説明です。

利点

物事は同時に起こっていないので一時的な結合を減らすこと
送信者に影響を与えないように受信機の障害に対する回復力が必要
受信者は消費率を制御すること
デッドレターキュー(DLQ)の活用
- DLQの使用を十分に検討すること
各メッセージを消費できる受信者は1つだけ

短所

応答相関
- リクエストの結果を判断する方法
- 送信者がリッスンしている別のキューで読み取りまたは書き込みが可能な相関IDを使用できる
バックログの回復時間
- コンシューマーがオフラインになった場合、バックログを処理する方法を理解する必要がある
マルチテナントシステムの公平性
- イベントがキューに配置される前に調整可能

非同期ポイント間 (router)

ロケーション結合を増加させる
送信者はルーティングロジックを維持する
アプリケーションを追加するたびに複雑になってくる

非同期メッセージルーターモデル (event bus)

EventBridgeを活用する手法を説明

利点

ロケーション結合を低減

例えばEventBridgeを利用する場合、パータンマッチングのルール設定だけで簡単に処理が可能になる
このルール設定を使えば、余計なロジックを使って動かす作業が減ります。

EventBridgeには多くのターゲットがあるので上手く活用することが可能になります。

イベント駆動型アーキテクチャ

ここから「イベント駆動型アーキテクチャ」の話です。
まず、「すべてのイベント駆動型アーキテクチャがサーバーレスではないが、すべてのサーバーレスがベンダー駆動型アーキテクチャである。つまりこれがイベント駆動型アーキテクチャだ。」と主張しました。

イベント駆動型アーキテクチャとは

「何か問題が起こったとする」

そうすると

「私達は返答する」

つまり
「何かをする時にイベントが発生する、それに反応して返答する」
このような流れをAWSサービス　EventBridgeで可能となります。

EventBridgeではルールを取得するトピックにサブスクライブします。

イベントが全て同じではない
メタデータはイベントに関する項目であり、イベントのデータとなる
システムの状態が変わったときにDynamoDBへのデータ書き込みや、S３にPutすることができる

ここでYasser Alsaied氏は、自身がIoTボタンを手に入れて、Lambdaを使ってプログラミングをしたそうです。
プログラムの動作は、クリックするたびに妻に「愛してる」のテキストメッセージを送信する機能でした。
(会場爆笑)

同じ内容のイベントを処理することであっても、イベントの極端に増加した場合はどうなるでしょうか。

より多くのものが増えるにたびに、イベント処理に計算するコストも高くなります。

Step Functionについて学ぶことも主張しました。
例えば注文システムをLambda関数を使って多くのコードを書いているかもしれませんが、それは最善な方法ではないです。
そんな時、Step Functionはドラッグアンドドロップしてビルドできるので簡単に始められるでしょう。

ある状態からある状態へ遷移させるようにステートマシンを実行して状態遷移できます。
ワークフローを視覚化して実行を行い、監視します。その各ループを監視することが可能です。
これは並列処理を行うのに役立ちます。

最適化した直接的統合とAWS SDK統合があるが、Step FunctionsでSDK統合が対応されたのは理由がありました。
SDKを使ってサービスと通信するLambdaを呼び出すのではなく、StepFunctionsがサービスと直接通信することができるようにするためだと主張しました。

締め

「ここで止まるな。より多く学んでください。次世代アプリケーションを構築する際に大いに役立つことを信じてます」で終わりました

次世代アプリケーションのイベント駆動型アーキテクチャをより知りたい方は↓を参考にしてください。

まとめ

イベント駆動型アーキテクチャは非同期処理が可能かどうか判断することから始めていくことが重要です。
SQSのFIFOキュー説明があったときに、今まで「フィフォ」として読んでましたが「ファイフォ」と説明してたことが印象に残っています。
re:Inventならではですが、英語圏だとAWSサービスの発音も日本と違うので良い気づきになりました。

以上