はじめに

こんにちは、AI事業本部の伊藤(@tsutsun17)です。先日、ラスベガスで開催されたAWS re:invent 2022に現地参加してきました。

AI事業本部では例年、エンジニア数人が現地参加して熱量と学びを得ることができる環境がありました。直近2年は世の情勢もあり現地参加を控えていましたが、今年は現地参加できました。今回は、参加したセッションの中で特に面白かったセッションの一部について、考察や開発しているプロダクトのお話も含めながらご紹介したいと思います。

セッションの概要

まずは、セッションの概要についてご紹介します。

Building next-gen applications with event-driven architectures

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.

イベント駆動アーキテクチャを使用したサービスの分割方法やサービス同士の接続方法について語られていました。内容は以下となっております。

Couplingについて
サービス間の同期、非同期通信のパターンについて
Event Driven Architectureについて
Event Driven Architectureにおける冪等性について（AWSのサービスだとどうなっている？）

この中でも、Event Driven ArchitectureのChoreography、Orchestrationについて興味を持ったので、これらについて調査してみました。

Event-Driven Architectureとは

このセクションの根幹であるEvent-Driven Architecture（以下、EDAとする）とは何でしょうか？ここで、AWS 様が発表されているEDAについての説明文を見てみましょう。

https://aws.amazon.com/event-driven-architecture/

An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices.

システム間の通信をイベントをトリガーにしておこなうアーキテクチャのこと。つまり、”event”が肝であるアーキテクチャであることがわかりました。

イベントとは

システムの状態が変化した信号
過去に起こった出来事
イミュータブル
重要な情報（key data）だけを載せることでCouplingを減少させている

つまり、イベントをもらうことで、それに応じた何らかのサービスが応答する。

Something happens and we respond.

まさに、この一言でEDAのほとんどを説明できてしまいます。

Choreography & Orchestration

さて、セッションの中でChoreography、Orchestrationという単語が出てきました。それぞれについて調査をしていると、MicroServicesの文脈で使用されていることが非常に多いと感じました。EDAの文脈と必ずしも一致しませんが、これらを比較してみましょう。

Choreography

複数サービスが関わるワークフローにおいて、各サービスが与えられたものに対して適切な処理を各々が選択して動作する方式

図を使用して説明してみます。

AサービスはEvent1をMessage Streamにpublishする
B、CサービスはMessage StreamからEvent1を取り出して、それぞれの処理を行う
処理が終わったBサービスはEvent2をMessage Streamにpublishする
DサービスはMessage StreamからEvent2を取り出して、処理を行う

となります。

これをみてみると、各サービスはEventを取り出してEventをMessage Streamにpublishする（しないものもあるが）ということだけを行い、サービス間の直接的な結合はなくなっています。あるサービスは自分がSubscribeしているEventのみに関心があり、そのEventに対応した処理だけをすれば良いという構造になっています。サービスが疎結合でもEventを介して繋がることで大きな処理を再現できるようになっています。

ここで、このChoreographyの利点・欠点を見てみましょう。

利点

それぞれが独立したサービスであるため、スケールアップ、スケールダウンが容易である
あるサービスの障害が他のサービスに伝播しない
- そのサービスに依存しないビジネスフローに影響がない

欠点

サービス同士は疎結合だがEventには依存しているため、途中のフローの変更時にSubscribe・PublishするStreamの変更などが必要となり、Event Messageの消失などの予期せぬ事象が起こる可能性がある
一連のフローがどのサービスで対応しているかを十分に理解できていないと、監視や観測が非常に難しい

これらをみてみると、

ワークフローロジックの変更頻度が高い
ワークフローに関連するサービス数が多い

上記の特徴を持ったワークフローには不向きではあるが、小さなフローや変更頻度が低いワークフローには向いていると考えられます。

Orchestration

複数サービスが関わるワークフローにおいて、全体の流れを制御するサービスが存在し、そのサービスを介してサービス間のやり取りを行う方式

ここでも図を用いて説明してみます。

Orchestration Serviceがワークフロー全体を管理する
Orchestration ServiceがA サービスにイベントを送り、Orchestration Serviceにイベントを返す
A サービスからの応答に基づいて、Orchestration Serviceが次のステップを決定する（ここでは、B、C サービスにイベントを送り、イベントをもらう）
B、C サービスからの応答に基づいて、Orchestration Serviceが次のステップを決定する（ここでは、Dサービスにイベントを送り、イベントをもらう）

ここでのイベントの受け渡しは、Choreographyと異なり同期・非同期で行うことが可能です。

Orchestrationの場合は、一連のフローをマネジメント、管理するサービス（Orchestration Service）が存在し、そのサービスがイベントを介して各サービスをつなげていきます。そのため、Choreographyと同じで各サービスが独立なのは変わらないが、一連のフローがどのようにつながっているかをOrchestration Serviceで確認、管理することができます。

ここで、このOrchestrationの利点・欠点を見てみましょう。

利点

一連のフローの管理や監視がしやすい
- 一連のフローを意味のある単位で切り分けることによる管理
- フローの進行状況や障害発生箇所の把握の容易さ
- 監視や観測をOrchestration Serviceに入れ込むことで一連のフロー全体で監視や観測を行うことができる
フローの変更容易性
- Orchestration Serviceを介してのサービス間のやり取りしかないため、事前に必要なサービスやStreamを用意して最後にOrchestration Serviceだけを変更することで予期せぬ事象を起こさずにフローの変更をすることが可能
トランザクションとロールバックが可能
- フローがどのサービスから始まってどのサービスを経由してどのサービスで終わるのかを全て把握できるため、トランザクションをはってロールバック可能なフローを作り上げることが可能

欠点

あるワークフローのOrchestration Serviceが障害となったら、そのフローは何もできなくなる
Orchestration Serviceの管理対象が増えすぎると、視認性が悪くなったり実装が複雑になる

これらをみてみると、

管理・監視、障害発生場所の把握容易性
フロー内のトランザクション・ロールバック

の特徴を持つことから、ある一つのビジネスフローに注力したワークフローに向いていると考えられます。

これまで二つの方式をみてきましたが、これらはどのように使用すればいいの？という疑問が生じてきます。この答えの一例をEricは示してくれました。

ChoreographyとOrchestrationの使い分け

Choreography

Choreographyは、Subscriptionを使用したドメイン間のやり取りで使用できると説明がありました。

処理対象者の領域が異なる場面やビジネスフローを考えたときに管理範囲外となる領域とのやり取りでは、Choreographyの方式でのやり取りをするのが良いのではないでしょうか。

Orchestration

Orchestrationは、ドメイン内のビジネスプロセスで使用され、Eventをpublishすると説明がありました。

ある領域における一連のフロー内では、Orchestratorを設置し管理するといったOrchestrationの方式でのやり取りをするのが良いのではないでしょうか。

AWSではStep FunctionsがOrchestration Serviceの役目を果たしているとのことでした。

Orchestration + Choreography

さらに、それぞれを組み合わせて使用するのが良いと説明がありました。Orchestrationはドメイン内で使用する、ドメイン間ではChoreographyを使用することでそれぞれの特性をうまく活用したEDAを構築することができます。

実際のプロダクトで考えてみる

では、実際に私のチームにおいてEDAをどのように使用しているのか、どのように構築できそうかを考えてみたいと思います。

私が所属するチーム（ミライネージ）ではデジタルサイネージを開発しており、コンテンツ配信や全国各地に散らばる端末の管理・運用をしています。端末情報取得やcsvファイルからの配信コンテンツ作成などでEDAが採用されています。基本的に処理開始元が同期的に処理結果が分からなくても大丈夫な処理の時にEDAが採用されています。

端末情報取得では、

端末側で各種情報取得の処理
AWS IoT Core経由でEvent をpublish
SubscribeしているサービスがEventに応じた処理を行う

となっています。

csvからの配信コンテンツ作成では、

管理画面を用いて、csvファイルのアップロード
ファイルを読み込んでDBにデータを登録する処理
配信をするための要素データが登録されたEventをpublish
Subscribeしているサービスが作成したデータからコンテンツを作成する処理
コンテンツが作成されたEventをpublish
Subscribeしているサービスが作成されたコンテンツの情報をDBに登録する処理

となっています。

端末情報取得はドメイン間、csvファイルからの配信コンテンツ作成はドメイン内で動作するものです。これをみてみると、ドメイン間、ドメイン内の両方でChoreographyが採用されています。端末情報取得はドメイン間の処理と表現している通り責務や領域が異なるため、まとめて管理しても旨味がない部分だと考えており、Choreographyが妥当だと考えます。ドメイン内処理に関しては、複雑な処理を行っていないこと、この処理が何をしていてどういう流れなのかの把握がチームメンバー内で共有されているためChoreographyで良いと考えています。それぞれのPub/Subを実現するコンピュートサービスとしてAWS Lambdaを用いている場合、機能の増加によって「このLambdaってどのLambdaに影響するの？」といった疑問がすぐに解消できなくなる規模になる前にStep Functionsを使用してOrchestrationを取り入れていき、Workflowの可視化や管理できるアーキテクチャを実現することがより良いと考えています。

おわりに

今回は、セッションの中で気になったEDAのChoreographyとOrchestrationについて取り上げ、実際のプロダクトにおいてEDAがどこで活用されているか、Choreography、Orchestrationがどこに当てはまるのか等を考察してみました。近年のサーバーレスの普及に伴い、EDAの採用事例も非常に増えていると思います。ただ単にAmazon SQSやAmazon Event BridgeでLambdaを繋げるという思考だけではなく、今回触れたChoreographyやOrchestrationの概念や組み合わせ方について十分に考慮した設計をすべきだと思います。この設計は、視認性や管理容易性、運用容易性をより良い状態にすることができるので、普段から意識しながら開発をしていきたいと思います。

今回、AWS re:Inventに参加するという貴重な機会をいただけたこと、この場を借りて深く御礼申し上げます。ありがとうございました。