月: 2023年2月

マイクロサービスにおけるCDCについて色々腑に落ちてきたのでちょっと整理しておきます。 マイクロサービスにおけるE2Eの問題 マイクロサービス化したアプリケーションにおいていくつものAPIなどが作られるかと思いますが、それぞれのマイクロサービスのモジュールE2Eを実行する際に、関連するマイクロサービスを立ち上げてテストをすることになるかと思います。 その場合、関連するAPIやDBなどを起動する必要があり、重くて時間がかかったり、そのマイクロサービスをテストしている間は他のmicroserviceをテストすることができないなどデメリットが出てきます。 そこで、関連する他のマイクロサービスをwiremockにすることで、作業がシンプルかつ軽くなり素早いテストが実現できます。 ただその場合だと、マイクロサービスの仕様が変わった場合、変更による影響を検知できなくなる可能性があります。つまり、テストで通ったのにいざ本場にデプロイしたら落ちるといったことが起こります。 これまでの話をまとめると、以下のようになります。 関連するマイクロサービスを全て起動してテストする 起動の手間や時間がかかるなどあるが、確実にテストすることができます。 関連するマイクロサービスをWiremockにしてテストする 手間がかからず素早く実行できるが、仕様の変更の影響などによりテストの挙動が担保することができない場合があります。 それぞれのメリット・デメリットがあるなかで一つの解決策としてCDCがあります。 CDC(Consumer Driven Contract testing)とは CDCとはAPIやマイクロサービスの開発において、サービス間の契約を定義し、各サービスが契約に従って動作することを保証するための手法のことです。 サービス間の契約を明確にし、各サービスが互いに依存していることを考慮することで、サービスの信頼性を向上させることができます。 例えば、A社のあるAPIの口にリクエストしたら、こういったレスポンスを返して欲しい場合、A社にそのAPIの口のinputとoutputのテストを書いてもらい、その挙動を担保してもらうといったイメージかと思います。 先程の例だと、テスト対象のマイクロサービスと関連するマイクロサービスにCDCを結び、関連したマイクロサービスにinputとoutputのテストをしっかり書き、その挙動を担保します。 それぞれのマイクロサービスにCDCを結んでおくことで、モジュールE2Eを実行する際に関連するマイクロサービスをWiremockとすることができます。 図のイメージだとこんな感じです。 それぞれのマイクロサービスにCDCを結ぶ手間はありますが、テストがしやすくなりました。 ここまで書いて思ったのですが、それぞれのマイクロサービスでちゃんとモジュールE2Eを書いていれば、自然とCDCが結べていることになるのかとも思いましたが、CDCを結ぶという観点を持ってテストを書くと書かないとでは意味合いが違うような気もします。 CDCを結ぶことになると、変更をしたマイクロサービスはCDCを結んでいるマイクロサービスとの契約を守る必要があるため、影響範囲に気付くことになるのかなと思いました。