【コレオグラフィ】
コレオグラフィ とは？
最終更新:
💡 イベントを受けて、各サービスが次の仕事を判断する
中央の進行役にすべてを指示させず、各サービスがイベントなどに応じて連携する方式。メッセージ基盤、重複・失敗対応、Sagaとの関係を解説します。
📌 このページのポイント
- 業務の進行を、各サービスの判断と連携で実現する
- メッセージ基盤があっても、業務の指揮役とは役割が違う
- 重複・遅延・順序・失敗の扱いをあらかじめ設計する
- 全体の状態を追うため、関連IDやログ・トレースが重要
ひよこ コレオグラフィは、サービスが勝手に動くこと？
ペンギン先生 イベントなどに応じて、自分の担当処理を判断する方式だよ。ただし勝手に何でもしてよいのではない。どんな出来事に反応し、何を通知するかという約束を、あらかじめ決めておくんだ。
ひよこ 例えば、注文の処理なら？
ペンギン先生 注文サービスが「注文が作成された」と通知し、在庫サービスが受けて在庫を確保する。さらに「在庫が確保された」を受けて決済が進む、といった例がある。各サービスの処理をイベントでつなぐよ。
ひよこ メッセージブローカーがあれば、中央の指揮者では？
ペンギン先生 ブローカーは主にメッセージを受けて届ける基盤だよ。業務の次の手順をすべて判断するオーケストレーターとは役割が違う。中央の業務指揮役がなくても、基盤や個々のサービスの障害対策は必要になる。
ひよこ 同じ注文イベントが二回届いたら？
ペンギン先生 二重に請求しないなど、重複して処理しても結果が困らない設計が必要だ。関連する注文IDやイベントIDを使って状態を確認する。順序の入れ替わり、遅延、再試行やタイムアウトも考えよう。
ひよこ オーケストレーションより、いつも簡単？
ペンギン先生 全体の流れが分散するので、追跡や失敗対応が難しくなることもある。参加サービスや依存が増えたら、関連ID、ログ、トレースで進行を見えるようにする。業務の複雑さや運用に合わせて、中央で進行を管理する方式とも比べよう。
もっと詳しく知りたい人へ
Sagaとコレオグラフィは同じ？
Sagaは、複数サービスのローカルトランザクションと、失敗時に埋め合わせる処理などで整合性を扱う考え方です。コレオグラフィはその進め方の一つで、Sagaはオーケストレーションでも実装できます。補償処理を使っても、単一DBのトランザクションと同じ隔離性を自動で得るわけではありません。
DBの更新後にイベントを送れば十分？
二つを別々に行うと、DB更新は成功したのに通知だけ失敗する場合があります。Transactional Outboxのように、状態変更と送るイベントを一緒に保存してから配信する方法があります。配信側の再試行と、受信側の重複対応も合わせて設計します。
まとめ：ざっくりこれだけ覚えればOK！
「コレオグラフィ」って出てきたら「イベントなどに応じて、各サービスが連携する進め方」と思えばだいたいOK！
📖 おまけ：英語の意味
「Choreography」 ＝ 振り付け
💬 各ダンサーが振り付けに沿って動くことにたとえた言葉です。ITでは、中央の業務オーケストレーターにすべてを指示させず、各サービスが連携する方式を指します。