バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。
はじめに
テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部のサービスが当初の構想とは違う形で事業が成長した結果、分散モノリス化してきたと同時に、別のドメイン境界が明らかになってきたという経緯があります。
そこで分散モノリス化したサービスを一度モジュラーモノリスに変更し、別のドメイン境界でサービスを切り直すというプロセスを経てマイクロサービスの切り直しを実施しました。
マイクロサービスとモノリス
前提情報として、マイクロサービスとモノリスについて簡単に「マイクロサービスアーキテクチャ」などの情報を元にかいつまみながら説明します。
マイクロサービスとは
ビジネスドメインを中心にモデル化された、独立してリリース可能なサービスです。
マイクロサービスの利点
適切なドメインでサービスを分割することができれば下記のような利点が得られます。
引用元: マイクロサービスの概要 | AWS (amazon.com)
モノリスとは
システムのすべての機能をまとめてデプロイしなければならない場合、それはモノリスといえます。そのため、アプリケーションのプロセスのいずれか 1 つでもスパイクが生じた場合、アーキテクチャ全体をスケールする必要が生じます。モノリスの中でもよく存在するのは下記の3種類です。
単一プロセスモノリス
すべてのコードを「単一プロセス」としてデプロイするシステムです。
モジュラーモノリス
単一プロセスが別々のモジュールで構成されている、単一プロセスのサブセットです。各モジュールで独立して作業できますが、デプロイするにはすべてを結合する必要があります。
分散モノリス
複数のサービスで構成されているものの、何らかの理由でシステム全体が一緒にデプロイされなければならなくなっているシステムのことを指します。分散システムの全ての欠点と単一プロセスモノリスの欠点を持ち、どちらの利点も十分には持たない。とも言われます。
サービス間の依存度が高い状態だと考えられるため、サービスをまたいだ機能開発やサービス間通信が多くなったり、分散トランザクション対応が必要であったりと開発コストや運用コストが高くなります。
テックタッチの場合
これら内容を踏まえてテックタッチのケースを見ていきます。
初期の頃の構成イメージ
テックタッチは初期の頃からマイクロサービスアーキテクチャを採用しています。
マイクロサービス切り直し前
事業の成長とともに環境が変化し、ドメイン境界が初期の思想と変わってきたこともありサービスAとサービスBが疎結合ではなくなってきたという経緯があります。
特徴
- 機能開発時にサービスAとサービスBを横断するケースが多いため開発工数が増える
- サービス間通信が頻繁に発生するためサービスの独立性が担保できない
- サービスの独立性が担保できないため両方デプロイする必要があるケースが多い
- データベースAとデータベースBに同時に書き込みをする分散トランザクションが発生するため、難易度の高い仕組みを利用する必要がある
これらをみるとサービスAとサービスBが分散モノリス化していたことがわかります。そのため、サービスAとサービスBをモジュラーモノリスに変更することとしました。
またその上で「サービスAB-main」「サービスAB-reader」（本記事では便宜上 main、reader とします）といった別のドメイン境界でサービスを切った方がよいことが明らかになってきたため、新たにマイクロサービスの切り直しを実施しました。
さらに、データベースの統合も検討しましたが、この時点ではコストとリスク見合いの観点でこのタイミングでの変更はせず進めながら今後どうするか検討することとしました。
モジュラーモノリス化
サービスA、BをくっつけてモジュールA、Bとしました。
サービスの移行
運用中のサービスであるため、移行過程で「なにかあったときに戻れること」を担保する必要があります。そのため移行期間は旧サーバと新サーバを並行稼働させ、リクエストを少しずつ新サーバに振り分けていきました。
別ドメイン境界でサービス切り直し
モジュラーモノリス化するまででも十分価値がありましたが、明らかな別ドメイン境界が存在したことから「モジュールA、B」から「main」と「reader」へサービスを切り直しました。
イベントストーミング
別のドメイン境界でサービスを切り直しをするにあたり、切り直しの根拠を持つために、ビジネスプロセスやドメインの知識を共有、可視化、理解するためのイベントストーミングを実施しました。
マイクロサービス切り直し後
モジュラーモノリス化後に、新たなドメイン境界でサービスを切り直した結果、サービスの独立性が高まり、マイクロサービスの利点の多くを享受できるようになりました。
一見DB への接続の矢印が増えて複雑化したようにも見えますが、この時点でもサービスを横断した開発がなくなり独立デプロイ可能になったり、サービス間通信を減らす取り組みが開始できたり、サービス間通信を通しての分散トランザクションから、サービス単体での分散トランザクションになるなど改善を実感できました。
DB 統合へ続く
サービスを適切に切り直せた一方で、上記の通りデータベースA、Bは元の構成のまま残っているため分散トランザクションは残ったままですし、1つのサービスが2つのデータベースにアクセスする状況となっているため DB 周りの開発効率が良くありません。これらの状況についてはこの後 DB を統合することで解消しました。DB を統合した話についてはまた別記事で紹介します。
まとめ
テックタッチにおけるマイクロサービス切り直しプロセスを紹介しましたが、実施することは容易ではないですし大きなリスクも伴います。もし同じようなことを検討している方がいたら、まずは自分たちのサービスの特性、ビジネスプロセス、ドメイン境界を明らかにすることからはじめてみてはいかがでしょうか。現在どういう状況であるか、理想とのギャップがどこにあるかなどが明らかにすることでその先の道筋が見えてくるかもしれません。
参考
追記
記事公開後社内で「分散トランザクション」について言及があったので補足します。 分散トランザクションというと 一般的には 2PC を連想しますが、記事上の分散トランザクションは紛らわしいですが「DBが分散している中で整合性をとること」という意味で使っており、 2PC ではないのでご認識ください。
