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

開催概要

Thinking asynchronously: Integration patterns for microservices
SVS205-R1

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

IMG_4344.jpg

Common serverless pattern

アプリの構成要素

IMG_4350.jpg

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

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

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

IMG_4352.jpg

ただマネージドサービスを組み合わせたとして、タスクを連続させたい場合はどうすればいいのか? 同時進行のタスクが必要ならどうするか? 並列タスクは? そういったことは考える必要があります。

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

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

IMG_4353.jpg

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

IMG_4354.jpg

メッセージ交換

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

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

IMG_4359.jpg

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

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

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

IMG_4360.jpg

「デッドレターキュー」

IMG_4362.jpg

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

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

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

IMG_4364.jpg

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

ルーティングのルールを bus(具体的なサービスとしてはEventBridge)に任せることで、この問題を回避することができます。

IMG_4365.jpg

Event-driven architecture

サービス間のイベントドリブンアーキテクチャを実現するサービス群。
IMG_4371.jpg

サービスの振る舞いを制御する方法として「オーケストレーション」「コレオグラフィ」があり、それぞれ特徴がある。

IMG_4372.jpg

オーケストレーション(代表サービス=StepFunctions)

  • 1つのコントローラ(=StepFunctions)がサービス間のフローを制御する
  • システム全体の end-to-end のモニタリングやタイムアウトを制御するのが容易
  • 中央集権的にビジネスロジックを実装する

コレオグラフィ(代表サービス= EventBridge)

  • サービス同士がメッセージをパスしあう
  • サービス間のフローは送信イベントにより決定する
  • 拡張や変更が容易

組み合わせ

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

IMG_4374.jpg

終わりに

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

IMG_4376.jpg

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

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

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

 

アイレットなら、AWS で稼働するサーバーを対象とした監視・運用・保守における煩わしい作業をすべて一括して対応し、経験豊富なプロフェッショナルが最適なシステム環境を実現いたします。AWS プレミアティアサービスパートナーであるアイレットに、ぜひお任せください。

AWS 運用・保守サービスページ

その他のサービスについてのお問合せ、お見積り依頼は下記フォームよりお気軽にご相談ください。
https://www.iret.co.jp/contact/service/form/