AWS re:Invent とは？

re:Inventとは、Amazon Web Services（以下、AWS）が主催するAWSに関するセッションや展示ブース、試験準備のためのブートキャンプやゲーム化された演習などを通じて、参加者が主体的に学習できるAWS最大のイベントです。

昨年も今年同様でラスベガスとオンラインにて開催されており、85以上の新サービスや新機能が発表されました。昨年の参加人数はオンサイト参加者2万人以上、バーチャル参加者は60万人以上になります。

Breakout Sessionの現地レポート（Day1、Dirk Fröhner）

1回目のBreakout Sessionレポートとなる今回は、11/28(月)10:00～11:00に開催されたApplication integration patterns for microservicesに関する講演をリポートします。

公式サイトによるセッション紹介を日本語訳すると、以下のような内容になります。

“事実上、すべての統合アプローチにはトレードオフがつきものです。しかし、疎結合の統合は、個別に開発・運用できる独立したシステムを設計するのに役立ち、また、特に非同期通信を使用することによって、システム全体の景観の可用性と信頼性を高めることができます。

統合や会話のシナリオには多くのアプローチがありますが、どのアプローチが特定の状況にとって最適であるかは必ずしも明らかではありません。このセッションでは、疎結合と非同期通信に重点を置いた統合と通信のシナリオのための基本的なパターンについて学びます。

また、クラウドネイティブサービスやサーバーレスサービスで構築された実際のユースケースを紹介し、統合技術の選択に関するガイダンスを提供します。”

登壇者

登壇者はこちらの方です。

会社名	登壇者	役職
Amazon Web Services	Dirk Fröhner	Principal Solutions Architect

セッションの構成

・APIs(API Gateway)
・Message Channels
　・queue(Amazon SQS)
　・topic(Amazon SNS)
　・message bus
・Streaming

まず、上記の機能に対して一般的な説明とメリット、デメリットを述べていました。各機能の横にある()内はセッションで紹介された関連するAWSサービスを一部表記しています。

次に、それぞれの機能を組み合わせたサービスの構成を簡単に設計できるAWSサービスを紹介していました。特に非同期通信を使用することによって、システム全体の景観の可用性と信頼性を高めることができるという主張から、Message Channelsに関して深くまで説明がありました。

最後に、実際のソリューションに適した設計をするにはどの機能を使うのが良いかという具体例が示されました。

設計パターンの紹介

基本の設計パターンの説明は割愛させていただきまして、これらの機能を組み合わせた設計パターンの説明があったのでいくつか紹介します。

Pipe and filters

これはPipe and filtersといって、ある処理(この図ではfilter)をパイプのようにつなげて連鎖させる構成図です。

この構成を実装する場合はAWS EventBridgeを使うと実装が簡単になると説明がありました。

Saga

次はSagaという設計パターンについてでした。Saga orchestrationはSagaを調整する方法で、複雑なワークフローの設計に適しています。

ただ多くのワークフローを一点で調整するOrchestrationの処理が複雑になってしまいますが、AWS Step Functionsを使用することで簡単に実装できるようです。

これらのどの設計パターンを使用したとしても、得意な動作がある一方で得意ではない動作も存在します。

このトレードオフの関係を考えてどのサービスを組み合わせるのがいいか考える必要があるでしょう。

予約サイトの設計例

ある企業の予約ができるサイトの設計を例にして説明がありました。

私は予約システムの構築経験がないため特に興味深いと感じたことは、いつの予約であるか、その緊急度に応じて必要な設計が異なるということです。

今週の予約

画像1枚目は、緊急度の低い今週の予約が必要な場合の設計です。

顧客から予約リクエストが来ると、APIはリクエストを受け付けたと顧客に返答し、裏側で実際に予約するためにQueueに入れます。

今日の予約

画像2枚目は、今日の予約という1枚目よりは緊急度の高い場合の設計です。

先ほどのQueueに加えてデータを統合するためのサービスに送るQueueを用意しています。

ちょうど今の予約

画像3枚目は、ちょうど今の予約という最も緊急度の高い場合の設計です。

多くのリクエストがほぼ同時に来ることも予想されるため、それを正しく対処する構成が必要でしょう。

2枚目の構成と異なり、Prebooking submission queueがAPI GatewayとPrebooking preprocessing resourceの間に挿入されています。

このように「いつの予約のためのシステムであるか」，という条件によっても必要な設計が異なることがあるそうです。

他にもtopicとqueueを使い分けた設計の具体例などについて説明がありました。

もっと学びたい方へ

最後にサーバーレスなアプリケーションの構成についてより詳しく学びたい方のためのスライドも用意されていました！

サーバーレスのサービスの仕組みについて知らない方には少し難しい内容のセッションだったと思います。

私はそれぞれの独立した機能については使用したこともあり多少の理解はありましたが、ユースケースに合わせて機能を組み合わせたりする知識がなかったので、日本に帰ったら読んでみようと思います！

まとめ

疎結合なサービスを統合するときそれを組み合わせることで様々なユースケースに対応できるというところまで知ることができ、とてもためになるセッションでした。特に予約システムのようにUI上は同じ挙動のように見えても、予約日時によってシステムに求められる厳格さが異なることでシステムの構成も変わるというところが面白いと思いました。

これを機にサーバーレスアプリケーションの統合の設計について学んでみてはいかがでしょうか。