はじめに

こんにちは。NTTデータ システム技術本部 クラウド技術部です。
この記事はAWS re:Invent 2022 参加報告レポート第3弾になります。前回の記事「空前絶後の発展を続けるECS。その進化に迫る」ではECSやコンテナ関連の新機能や今後の拡張性に関する紹介をしています。

今回はAmazon CTO 兼 VP のDr. Werner Vogels のKeynoteでも強調されていた「イベント駆動アーキテクチャ」をテーマに、関連するセッションや新サービスの紹介を行います。

イベント駆動アーキテクチャについて

Vogels氏のKeynoteでは「The world is event-driven.」というメッセージが語られました。この世界は有象無象の事象(イベント)がお互い非同期に動作し合う不確実なものであり、こういった不確実性の高いものに対処する方法として、事象(イベント)をトリガーに動作するイベント駆動な仕組みを挙げています。

システムにおいても同様で、たとえば扱うドメイン(ビジネス)やシステム自体の複雑さに対処してシステムを成長させていくためにイベント駆動アーキテクチャのアプローチがあります。 前提としてシステム内のコンポーネントは非同期かつ疎結合となっていることは、コンポーネント間の依存関係が最小化できて、故障が起きても影響をコンポーネント内に限定されるなど、コンポーネントごとに変更追加させていきやすい作りにつながります。

イベント駆動アーキテクチャでは、コンポーネント間で跨って行う必要がある処理をイベント（例「商品が購入された」などの情報）のSubscriptionとして定義して、さらにコンポーネント間にイベントバスなどを挟むことで前述のような非同期かつ疎結合にすることができます。

AWSでのイベント駆動アーキテクチャ

今回のre:Inventのセッションやワークショップでも、AWS上にイベント駆動アーキテクチャを構築する上でのサービス間の連携パターンやプラクティスが紹介されていました。

イベント駆動アーキテクチャに関するセッションのアーカイブは、以下の「AWS re:Invent 2022 - Serverless Compute」の再生リストから紹介されているので是非ご参照ください。

中でも複数のセッションで強調されていたこととして、複数のAWSサービス間で連携させるためのグルーコード(Integration Code)によるコストの課題がありました。

特にイベント駆動アーキテクチャをはじめ、複数のAWSサービスを連携させて構築していく場合、こういったサービス間の連携をするだけのグルーコードが量産されがちです。こうした無駄なグルーコードを実装して運用・メンテナンスし続けるコストによって、本来そのシステムでやりたかった差別化する機能に割けなくなっていってしまいます。

サービス間の連携機能などつい何でもLambdaに頼って自分たちで実装してしまいがちですが、何でもLambdaで解決するのではなくユースケースごとに各AWSサービスが提供する機能を使って解決する方がパフォーマンス、コスト、スケーラビリティも高くなるケースが多いことが強調されていました。

たとえば複数のAWSサービスのオーケストレーションをするようなケースであれば、Lambdaとして関数内に自分で実装するのではなく、AWS Step Functionsでワークフローとして定義して、他サービスとの連携にはAWS Step Functions のAWS SDK統合の機能などのマネージドな仕組みに乗ることで、グルーコードを削減して最終的に本来リソースを割きたいドメインに注力することができます。

新登場のAmazon EventBridge Pipes

また今回のre:Inventで発表されたAmazon EventBridge Pipesも活用することで、前述のようなLambdaなどのグルーコードをなくして複数のAWSサービス間の接続をシンプルにできるサービスです。

たとえば、これまでDynamoDBからAmazon SQSを介して他のデータストアと同期させたいといったユースケースの場合、DynamoDB StreamsからSQSにデータを配信するためDynamoDB StreamsとSQSの間にLambdaでグルーコードを実装する必要がありました。

こうした課題に対して新登場のAmazon EventBridge Pipesでは、UNIXコマンドのPipeのように、ソースサービスとターゲットサービスの間のデータのフィルタリングやエンリッチメントを必要な実装のみに絞って実現できるようになりました。
エンリッチメントでは、Amazon EventBridge のAPI destinationsにも対応しているため、外部のデータを取得してデータを変換することも可能になっています。
またイベントバスを使う場合と比較して、データの順序性も保証されるため様々なユースケースで使い勝手がよいかと思います。

実際にコンソール画面から触ってみたところ、グラフィカルにソースサービスからターゲットサービスへの連携や、イベントのフィルタリングからAWS Lambdaでのデータ変換など簡単に試すことができました。今後の利用については、検証時にエンリッチメントなど各処理の前後のイベントの入出力なども実行履歴として取得できるようになったり、予定されているAWS CDK(L2)のサポートがされたりすると開発者体験としてかなり使いやすくなっていくかと期待しています。

まとめ

本稿ではVogels氏のKeynoteをはじめ、イベント駆動アーキテクチャを扱ったセッションやワークショップを中心に紹介しました。

イベント駆動アーキテクチャに関連したセッションやワークショップでは当日参加者向けの長い列ができる人気のセッションも多かったです。（筆者も当日定員オーバーで参加を逃してしまったセッションもありました。）

イベント駆動アーキテクチャの構築を手助けする今回のAmazon EventBridge Pipesをはじめ、今後も開発のアジリティを上げてくれるサービスアップデートを期待しています。 次回の記事でもre:Inventに現地参加したエンジニアたちのレポートを紹介するのでぜひお楽しみに。

NTTデータの取り組みの詳細はこちら

[PR]提供：NTTデータ