イベント連携基盤の技術選定をした話〜比較・結論編〜

こんにちは、プロダクト開発部の中田です。

今回は、イベント連携基盤の技術選定におけるサービス比較結果のまとめと結論をお伝えします。

技術選定の検討自体にも長くかかりましたが、ブログ記事の執筆も大変でした。最後までお付き合いいただけると幸いです。

本記事の概要

これまでの記事では、イベント連携基盤の検討にいたった背景をはじめ、MessageBrokerとなるサービスの候補として挙げたAmazon EventBridge（以降、EventBridgeと記述）とAmazon Managed Streaming for Apache Kafka（以降、MSKと記述）をさわってみて得た気づきなどを記載してきました。

本記事では、EventBridgeとMSKを使用した構成の比較結果をまとめ、技術選定の結論をお伝えします。

EventBridgeとMSKの比較まとめ

EventBridgeを使用する構成と、MSKおよびAxonを使用する構成について、それぞれ検討を行い、特に差異のあった部分をピックアップして、下記の表にまとめました。各要素の詳細については、これまでの記事をご参照いただければと思います。

結論

上記の比較表をさらにまとめると、以下となります。

比較要素	EventBridge	Axon+MSK
MessageBrokerの保守難易度	低い	高い
MessageBrokerの利用料金	安い	高い
MessageBrokerへのNW接続	public	private
MessageBrokerの順序保証	不可	可
モノリス（PHP）からの利用難易度	少し高い	高い
マイクロサービス（Kotlin/SpringBoot）からの利用難易度	少し高い	低い

EventBridgeの方が、難易度や料金の面で有利です。一方、NW接続がpublicとなる点と順序保証が不可な点に起因して、利用のために追加の対応が必要になったり、順序保証が必須のユースケースで利用が困難になったりする可能性が考えられます。

MSKは難易度の課題さえ克服できれば、幅広く利用できる可能性があります。Axonが利用できるマイクロサービスにおいては、むしろアプリケーション実装の難易度が下がり、将来EventSourcingやストリーム処理などを導入する足掛かりになることも期待できます。

やはり、どちらも一長一短があるので、将来も予想したうえで判断をくだすのはなかなか難しく、どちらを選んでも後々のリスクはあります。

その上で、結論としてはいったんAxon+MSKを選びました。

決め手に欠ける中で判断のポイントになったのは、以下の事情でした。

直近でイベント連携を行いたいのは、Kotlin/SpringBootで実装されているマイクロサービスであり（私自身が所属する機能開発チームの担当機能でもあります）、Axonを使いたい。
別の機能開発チームで、モノリスからのマイクロサービス切り出しのため、Kafka/Debeziumを利用したデータ移行を行いたい。

コドモンにおいて、イベント駆動アーキテクチャの知見がまだ少ない現在において、まずは目の前のニーズに対して使いやすいものを早く使い始め、（失敗も含めて）知見をためることを優先しました。

もしかしたら、MSKの保守が大変で利用継続が厳しいと感じることもあるかもしれません。EventBridgeが、privateなAPIへの送信や順序保証に対応して乗り換えたくなることもあるかもしれません。そのような場合に、方式の変更がしやすいように、利用側のアプリケーションにおいては、方式への依存を抑えた実装（つまりはクリーンアーキテクチャ）を心がけています。 MSKの利用を開始したマイクロサービスでは、もしMSKとAxonを利用したイベント連携に問題があれば、すぐに従来の同期API連携に戻すことができるように保険をかけておきました。