はじめに

こんにちは、長時間フライトにビビっていたけど案外余裕だったヤマダ(北野)です。

この記事は「Orchestration meets choreography: Building event-driven architectures [REPEAT] (ARC401-R)」のセッションレポートです。セッション時間に対してハンズオン内容は3時間で全然完走できなかったことが悔しいです。ハンズオン自体は完走していないので、セッション講師の方の解説をベースにレポートを記述します。

ちなみに前回の反省を活かして写真や画像はしっかり確保しました！えらい！

セッション概要

Master advanced patterns for building hybrid orchestration-choreography architectures from the ground up. Implement orchestration collectors using EventBridge and Step Functions for coordinated workflows, while creating choreographed microservices with Lambda and SQS for autonomous operations. Build sophisticated event-driven systems that intelligently balance centralized control with distributed autonomy. Gain expert-level insights into pattern selection, implementation strategies, and debugging techniques for complex distributed systems.

ハイブリッドなオーケストレーション・コレオグラフィアーキテクチャをゼロから構築するための高度なパターンを習得します。協調的なワークフローを実現するオーケストレーションコレクターをEventBridgeとStep Functionsで実装し、自律的な運用を実現するコレオグラフィー対応マイクロサービスをLambdaとSQSで構築します。

まずは説明文が普通に難しすぎました。「これおぐらふぃーってなんなん？」です。

コレオグラフィーとは（choreography）

主にコンピュータ間のシステム連携やサービス間のやり取りを、 balletのような振付けのように計画し、実行する手法や構成を指します。特に「ダンスを記譜する」という語源のように、各サービスがどのように連携して全体として一つの「踊り（機能）」を表現するかを設計するイメージです。

なんでまだ全然難しいのか。これを元にAIに説明を求めましたが、コレオグラフィーは「誰が何をすべきか」を気にせず、「何が起こったか」に反応して動く、非常に柔軟でスケーラブルなシステム連携のパターンらしいです。

コレオグラフィーはイベント駆動アーキテクチャの設計論などでよく登場します。これはコレオグラフィーが中央の制御主体を持たず、サービスがイベントに自律的に反応することで高い疎結合性を実現するパターンだからです。

セッション内容でも説明が出てきますが、物足りなく感じたため調べました🙇‍♂️

セッション内容

セッション概要等の説明

講師Sam Burton氏:
今日は、コレオグラフィーとオーケストレーション、この二つのアーキテクチャパターンの違い、そしてそれらをハイブリッドアーキテクチャとして組み合わせる方法、いつ両方を使うことを検討すべきか、そしてAWSでどのように使うかについて話します。

セッション時間は1時間だったため、時間内にフォーカスを当てる部分の解説がありました。このハンズオンでは以下の3つの主要なアーキテクチャパターンについて、AWSでどのように実装すべきかを学べるようです。

  • コレオグラフィー（Choreography）
  • オーケストレーション（Orchestration）
  • ハイブリッドアーキテクチャ（Hybrid）

コレオグラフィーパターンについて

講師Sam Burton氏:
コレオグラフィーは、フロアにいる大勢のダンサーを想像してもらえればいいでしょう。誰も他の人の指示を聴いているわけではなく、みんなが独立して行動しているだけです。これはイベント駆動型であり、AWSではEventBridgeを経由することを意味します。

注文サービスはイベントをEventBridgeに発行し、もうそれで終わりです。関与しません。インベントリサービスはそれをリッスンし、自分のタスクを終えたらまた立ち去ります。各サービスは互いに独立して行動しています。

これはもちろん非常に疎結合です。新しいサービスを追加することが極めて容易になり、非常にスケーラブルになります。しかし、何か問題が発生した場合に可視性やモニタリングが少し難しくなるという欠点があります。

コレオグラフィーは「独立したダンサー」のように動くため、高い疎結合性とスケーラビリティが得られることはよく分かりました。しかし、各々が勝手に動くので問題発生時にフローの全体像を把握しにくい（可視性が低い）という点が運用上の課題のようです。

オーケストレーション・パターンについて

講師 Sam Burton氏（発言抜粋）：
オーケストレーターがいます。もちろん、全てが中央のエンティティによって管理されます。著しく厳格で、非同期で起こることはなく、その中央エンジンが全体のフローを調整します。これはStep Functionsを使用します。

Step Functionsのフローの途中で何か失敗すると、全体が壊れてしまいます。すべてが非常に密に結合されています。

金融サービス、決済、バンキングなど、ACID要件が必要な場合に真価を発揮します。デバッグが容易、明確な可視性、中央制御、優れたエラーハンドリングが得られますが、密に結合されており、単一障害点でもあります。

オーケストレーションは、金融系基幹業務に合っているようです。ですが密結合と単一障害点のリスクがトレードオフとして常に存在しするため、設計においてこの全体停止リスクをどう許容するかについても詳しく聞いてみたく思いました。

その場で聞けよって思うかもですが、自分は文字起こしした文章を翻訳しながら必死についていっていたので余裕で無理でした。

ハイブリッドパターンについて

講師 Sam Burton氏（発言抜粋）：
ハイブリッドアーキテクチャは、必要に応じてそれぞれの強みを使って、二つを組み合わせる場合です。

注文作成、在庫チェック、支払い処理など、順序を制御し、確実に起こるようにする必要があるものは、厳格な要件として順次発生させる必要があります。

通知サービスのような外部にある可能性のあるものは、バックグラウンドで非同期で発生しても構いません。（通知サービスは）発行して忘れる（publish it and forget it）ことができます。

この二つを組み合わせることで、必要に応じて両方の強みを利用できる柔軟なアーキテクチャを持つことができます。

ハイブリッド戦略は、実務における最適な解決策だと感じました。

厳格なクリティカルパスはオーケストレーションで制御し、柔軟な周辺処理はコレオグラフィーに任せるという明確な使い分けで信頼性とパフォーマンスのバランスを高められることがよく分かりました。

質疑応答

他の参加者の方が講師の方に質問をしていたので、その内容をまとめます。

質疑応答①

Q：
可視性についてですが、コレオグラフィーではハイ（高）になっていますが、これはどういう特定の問題を解決しているのでしょうか？

A：
これは興味深い点です。あなたが今日取り組むアーキテクチャには可視性が組み込まれているため、比較サマリーではコレオグラフィーがハイ（高）になっています。しかし、一般的に言って、疎結合なアーキテクチャには組み込みの可視性はありません。高い可視性を実現するには、CloudWatchやCloudTrail、あるいはサードパーティのモニタリングサービスが必要となります。Step Functionsを使用するオーケストレーションは、ツールが組み込まれているため、一般的に高い可視性を持っています。コレオグラフィーの可視性は、一般的に疎結合な性質上、サードパーティのモニタリングサービスが必要になるという点がポイントです。

可視性の実現について、何が要因で高くできていると言い切っているかの詳細な説明が聞けました。

質疑応答②

Q：
オーケストレーションについて、問題が発生した場合のブラストゾーン（影響範囲）や、オーケストレーター（Step Functionsフロー）が単一障害点になることについてどう言えますか？

A：
その通りです。非常に密に結合しているため、Step Functionsには単一障害点があります。物事がうまくいかなかったときに処理できるように、独自のデッドレターキュー（DLQ）を組み込む必要があります。しかし、監視はしやすい単一のポイントです。

ブラストゾーンって英語になってるだけでしょうか。“影響範囲”なら聞き馴染んでいるのでいいのですが、新しいカタカナ単語が出てきたかと思いました。単一障害点があるものの、DLQの実装などによって監視自体はしやすいらしいです。

最後に

アーキテクチャの選択はトレードオフであることを再認識しました。特にオーケストレーションは「デバッグの容易さ」「中央制御」といった利点と引き換えに「単一障害点」「密結合」というリスクもあります。質問にもあったように、オーケストレーターが停止した場合に処理中のトランザクション全体が停止する可能性もあります。

今回のワークショップを通じてイベント駆動型アーキテクチャの設計ではビジネス要件に応じて、戦略的にパターンを選択する必要があることが分かりました。

とは言ったものの、まだまだ理解も浅いので実例に触れつつしっかりと学んでいきます👊