非同期で考えるマイクロサービスのための統合パターン re:Invent2022セッションレポート

ラスベガスで開催されたre:Invent2022での「Thinking asynchronously: Integration patterns for microservices」セッションのレポートです。



# 開催概要
Thinking asynchronously: Integration patterns for microservices
SVS205-R1

> マイクロサービスアーキテクチャを適用する場合、多くの通信がネットワーク上で発生します。耐障害性と柔軟性を高めるには、この通信は非同期かつ疎結合で行われる必要があります。このトークでは、いくつかの基本的な統合と会話のパターンを探求し、実際のユースケース（マイクロサービスだけではありません）に結び付けます。エンドユーザークライアントが同期APIを使用して通信しながら、処理に非同期通信を利用する方法を学びます。

![IMG_4344.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/4ec1cc01-787f-e81f-8121-9c30ba0529d1.jpeg)



# Common serverless pattern

## アプリの構成要素
![IMG_4350.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/dd457c70-555b-31a0-735b-fe1135c08233.jpeg)

通常クラウドでサービスを構築する場合、「API」を持っていてそこから「処理部分(Compute)」に連携し、「ストレージ」にアクセスする。何か問題が起こったとき疑わしいのはどこか？

「処理部分(Compute)」です。なぜか？自分で書いたコードだから(笑うところ)。

コードを書く必要がなければ、本質的にメンテナンスの手間が省け、運用が簡単で、より信頼性が高くなる。
マネージドサービスを組み合わせればコードを書く量が減ります。



![IMG_4352.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/0b14ca71-ad80-b476-8cd1-28c04130752a.jpeg)
ただマネージドサービスを組み合わせたとして、タスクを連続させたい場合はどうすればいいのか？同時進行のタスクが必要ならどうするか？並列タスクは？そういったことは考える必要があります。

# Decoupling your application(依存性を少なくし分離する)


適切な分離のレベルは、エンドポイントに対する制御のレベルによって異なる。
制御すべきことが多い場合は、緊密に同期的な呼び出しをすることが好ましいかもしれません。そうでない場合は分離度を高くし非同期的な呼び出しが好ましい。

![IMG_4353.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/aa80f93d-da8f-42ad-d564-1b3a29c387d7.jpeg)

- 同期 = コマンド
- 非同期 = イベント

![IMG_4354.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/7ebb1f5d-dd8c-1780-5d9f-c376e73e0214.jpeg)


## メッセージ交換

メッセージ交換をパターン別に分類します。

ここからは非同期メッセージングの様々なパターンをみていきます。

### 「一方通行」と「非同期的なリクエストと応答(Conversation pattern)」

![IMG_4359.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/08ec32db-70ab-4933-f876-d5a016994f33.jpeg)

非同期でレスポンスが必要な場合はConversation patternを使います

### 「キュー」と「トピック」

キューは各メッセージを、受信者のいずれかが消費するパターン
トピックはメッセージを各受信者が消費するパターン



![IMG_4360.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/f58365c9-72d7-f071-5a35-8cadfeacf499.jpeg)

### 「デッドレターキュー」

![IMG_4362.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/a428bb7b-ea0d-9188-447e-5d7082d8cb93.jpeg)


デッドレターキューは一過性の障害などで消費できないメッセージを退避させ、繰り返し処理を続けることを回避し、安全な場所で自分たちで分析できるようにします。

### 「ルーター(point to point)」「ルーター(bus)」

メッセージをルーティングする時の話をします。

![IMG_4364.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/ff453366-b976-985e-b73a-ad957b9c333b.jpeg)

送信者が判断し、各受信者のポイントに振り分ける場合、パターンが増えるにつれ送信者のロジックは複雑になります。


ルーティングのルールをbus(具体的なサービスとしてはEventBridge)に任せることでこの問題を回避することができます。
![IMG_4365.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/36a76b46-dd8d-559c-a010-a6ac6724564a.jpeg)


# Event-driven architecture

サービス間のイベントドリブンアーキテクチャを実現するサービス群
![IMG_4371.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/a4b9cb02-f66e-b15e-8f27-7f3bab52d492.jpeg)


サービスの振る舞いを制御する方法として「オーケストレーション」「コレオグラフィ」があり、それぞれ特徴がある
![IMG_4372.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/736a45a8-c729-2165-1c0e-91ffce48b015.jpeg)

## オーケストレーション(代表サービス=StepFunctions)
- １つのコントローラ(=StepFunctions)がサービス間のフローを制御する
- システム全体のend-to-endのモニタリングやタイムアウトを制御するのが容易
- 中央集権的にビジネスロジックを実装する
## コレオグラフィ(代表サービス= EventBridge)
- サービス同士がメッセージをパスしあう
- サービス間のフローは送信イベントにより決定する
- 拡張や変更が容易


## 組み合わせ
「オーケストレーション」と「コレオグラフィ」を組み合わせることも可能

![IMG_4374.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/8a5e0b7d-c1d7-7744-07d8-8e6e875c2b8b.jpeg)


# 終わりに
サーバレスについてさらに学ぶためのコンテンツ紹介で本セッションは締めくくられました。
https://aws.amazon.com/jp/training/learn-about/serverless/

![IMG_4376.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/43631/291f2a5f-c10c-83b7-da98-22ddc43c5c92.jpeg)

私自身もアーキテクチャを検討するとき「サービス間のメッセージを同期にするか非同期にするか」「フロー制御をオーケストレーションでやるかコレオグラフィでやるか」は毎回悩むところです。

今回のre:Invent4日目のキーノートでも非同期アーキテクチャに関する話がありました。
要件や制約、運用設計、プロダクトのフェイズ、チーム体制や習熟度などから適切な方法を採用できればと思います。

今回のレポートは以上です！