🥴
イベント駆動型アーキテクチャ 〜 イベントを主役にすることで解決できること 〜
公開
2025-04-13
更新
2025-04-13
文章量
約3558字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
本イベントでは、「イベント駆動型アーキテクチャ」を切り口に、複雑化するシステムにどう立ち向かうかを探りました。ゲストには IDEO PLUS 合同会社 の 加藤潤一 さん（以下、かとじゅんさん）と、 株式会社カケハシ の 木村彰宏 さんをお招きし、リアルな知見を共有していただきました。
各所で注目される CQRS/ES（イベントソーシング） をはじめ、イベントを中心にシステムやデータを扱うことで得られる恩恵や、実装・運用上の気をつけるポイントを、実践事例を交えながら解説いただきました。
はじめに 〜 アーキテクチャと組織の変化 〜
近年、システムの規模拡大やマイクロサービス化の進展に伴い、「イベント駆動型アーキテクチャ」を取り入れる企業が増えています。同期的なAPI連携だけでは故障範囲の拡大や変更容易性の制限が起きやすくなり、サービス全体の柔軟性を損なう場面が少なくありません。その対策として イベント（非同期的なメッセージ） を要に連携し、各システムをゆるやかに結合するアーキテクチャが注目されています。
一方で、イベント駆動型のデータフローをどう定義し、各サービスのドメインモデルと整合を取るか、実装の難しさや学習コストを懸念する声も多くあります。本イベントでは、そうした課題の背景と解決策、さらに CQRS/ES の実践手法やデータ基盤とのシームレスな連携について学ぶ機会となりました。
セッション1：なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題
登壇者
加藤 潤一（かとじゅん）さん IDEO PLUS 合同会社 代表 Scalaやドメイン駆動設計を軸とした大規模システムの開発に長年携わり、CQRS/ES を実務に導入してきた経験を豊富にお持ちです。
複雑系システムの壁
まず、モノリシックなシステムは機能が肥大化すると変更容易性が下がり、デプロイのたびに全体の影響範囲を確認しなければならなくなります。そこで機能やサービスを分割すると今度は同期的なAPI連携による故障範囲の拡大や、いわゆる「分散モノリス」化のリスクが生じます。
加藤さんいわく、真の素結合を目指すには「非同期的なイベント連携」が必須とのこと。もしサービスBが障害を起こしても、サービスAの動作が巻き添えになる状況を避けるためには、イベント駆動のアーキテクチャが適切に機能する必要があります。
CQRS/ESの概要
加藤さんは「CQRS/ES」を例に解説。CQRS は Command Query Responsibility Segregation の略で、書き込み系（コマンド）と読み取り系（クエリ）を分離する設計思想。これと Event Sourcing（イベントソーシング）の組み合わせにより、以下のメリットが得られます。
書き込み用のモデル はドメインロジックに集中し、データの最新状態をイベントとして蓄積
読み取り用のモデル は画面表示や集計に合わせて自由に最適化
イベントを公式の履歴 として管理し、ダブルライト問題を回避
加藤さんは「よくある“データベース更新→イベント送信”の順番だけでは、更新成功後にイベント送信が失敗するリスクが残る」と強調。ダイナモDBなどのCDC（Change Data Capture）を活用し、イベントを一貫性を持って取得する仕組みが鍵だと述べました。
セッション2：データ資産をシームレスに伝達するためのイベント駆動アーキテクチャ
登壇者
木村 彰宏（@kimutyam）さん 株式会社カケハシ 技術戦略室 アーキテクト 広告配信やデータ基盤領域の開発を経て、カケハシでサービスとデータプラットフォームのアーキテクトを担当。
ドメインイベントを「記録」し「伝達」する
カケハシでの事例では、とくに「イベントデータを データ資産 として活用する」ことに重きを置いています。たとえば、ユーザーの操作や組織の所属変更などをイベントとして 完全に記録 しておけば、分析や他サービス連携の可能性が広がります。
一方、「すべてをイベントで扱うと粒度が細かすぎる」という課題があるため、イベントモデル を2種類に分けるという工夫をされているそうです。
デルタイベント（ドメインイベント）
業務上の出来事（例：部署が移動された）を小粒度で記録
命令的（通知や特定トリガーの実行）なシナリオに向く
ファクトイベント（状態転送イベント）
集約された「現在の状態」をまとめて転送
テーブルのスナップショットに近く、用途によっては分析基盤に適している
分析基盤とイベントストリーム
さらに木村さんは「イベントドリブンな手法をデータ基盤にも適用すると、アプリケーションと分析がシームレスに連携 できる」と強調します。たとえば、AWSのダイナモDBのストリームや、キネシス/Kafkaなどを介して、アプリとデータ基盤がイベントを共有すれば、リアルタイムな分析や多段のデータパイプラインが容易に構築できるそうです。
また、イベントブリッジやCDCツール（Debeziumなど）を取り入れることで「データをメッシュ化 しやすくなる」とも指摘。特定の分析要件やドメインに縛られず、必要な時に必要なイベントを取り出すアーキテクチャがカケハシ内で広がっているとのことでした。
Q&A 〜 データの整合性・イベント運用のポイント 〜
Q. イベント駆動でデータ整合性を保つには？
加藤さんは「ダブルライト問題は、イベントをDBに書いてメッセージブローカーにも書くときに起こりがち。CDC を使えばアトミックに対応できる」と説明。いわゆる2コミットを避けるうえで、ダイナモDBやRDBのCDCが有効とのこと。木村さんも「イベントの伝達をシンプルにするならCDCで一元的に拾うのが現実的」と補足されました。
Q. どのような場面でイベント駆動は向いていない？
「小規模・変化が少ないシステムならば、同期APIで十分」（加藤さん）。ただし組織やシステム規模が拡大し、複数サービスの連携が常態化すると「非同期で故障範囲を切り分ける 価値が出てくる」とのこと。木村さんも「軽めの要件ならAPIでも構わないが、後からイベントを足すなら『はじめからイベントありき』でモデリングしたほうがスムーズ」と強調。
Q. イベントが増えすぎると管理が複雑化しないか？
「設計や運用の手間は増えるが、局所的にはむしろ分かりやすくなる」と加藤さん。サービス間の依存が同時に減るため、全体最適的には難しさが移るだけとも言えます。木村さんは「全ドメインをフルCQRS/ESにするより、必要に応じてモジュール単位で取り入れるとよい」とアドバイス。同じくファクトイベントとデルタイベントを使い分けることで、不要なイベント生成を抑える工夫も重要です。
全体を踏まえた感想
イベント駆動型アーキテクチャは、複雑な分散システムの故障範囲切り分けや変更容易性の向上に大きな可能性を秘めていることが改めて示されました。加藤さんの強調する 「ダブルライト問題」 は、導入時に見落とされがちですが、CDCやイベントソーシングの仕組みを正しく使うことでかなり回避しやすくなるとのことです。
また、木村さんが示した 「データ資産としてのイベント」 という視点も印象的です。リアルタイム分析や他ドメインでの利用を見越してイベントを記録・伝達すれば、システム外のデータ基盤とのやり取りもスムーズになり、追加の業務要求に柔軟に対応できる余地が生まれます。
とはいえ、イベント駆動の仕組みは最初からフルに導入せず、まずは小さな単位での検証や、局所的なCDCなどを試してから徐々に範囲を拡大することが望ましいと感じました。まるで「非同期で結合する」という発想そのものが、組織やサービスのスケールに合わせて徐々に適用されていくようです。
二人の登壇は「運用面での学習コストは確かにあるが、それを補って余りあるメリットがある」という点で共通していました。まさしくイベント駆動型アーキテクチャは銀の弾丸ではないが、確かな選択肢だと再確認できるセッションでした。もし今後、マイクロサービスの連携、あるいは分散システムの可用性と拡張性に悩んでいる方がいれば、ぜひイベント駆動の導入を一度検討してみてはいかがでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
