見出し画像

モノリシックなサービスからマイクロサービス化へ進む際の注意点

モノリシックなサービスをマイクロサービス化する際の注意点のメモです。

どのような分割をするか?

単純化すると「機能」で分けるか「責務」で分けるかとなります。これを決めておくことで関数をどこに用意するか、データをどちらで持つべきかなどの議論の土台になります。
個人的には品質に関わるテスト設計の観点からも、まずは「責務」で分けるのがいいと思っています。(テスト設計の際には責務のことを業務と言うかもです)

業務の一連の中には「機能」が含まれていて、複数の業務に存在する同一の「機能」もあります。(この辺りもまた別のnoteで書ければなと思います)

メトリクス(パフォーマンス)監視を構築する

単一のAPIとDBの組み合わせでさえ、パフォーマンス問題が出た際の原因特定にメトリクスを見ながら改善やチューニングをします。
それに加えてマイクロサービスとすることで一つのリクエストに対する処理レイヤーが増えると、何かパフォーマンス問題が発生した際にどこがボトルネックとなっているか分からないと対処がとても遅くなります。
また、手前のレイヤーのパフォーマンス問題を解消する(プロセスやノードを増やしたりなど)と後のレイヤーへの負荷が増えて、次の問題が発生するかもしれません。

そのため、メトリクス監視、閾値の設定、通知(Slackなど)設定は必ずしておくべきです。
APMなどを入れているとより良いと思います。

ログを集約する

同じく何か問題が発生した場合に、各ログファイルを参照しにそれぞれのサーバーやコンテナにアクセスしているとそれだけで大変です。
ログの集約と検索性を高めておくことが問題解消への早道になります。

CI/CD(DevOps)の構築

モノリシックなサービスよりも手間が増えると感じることもあるかもしれません。(どちらかというとモノリシックな方がもろもろの負荷が高いと考えてますが)
たとえマイクロサービス化しても手間が増えたと感じさせないようにCI/CDの構築は最初に行い、回転が上がったことをより知ってもらうのがいいと思います。

その他

他にも言語をどうするか、インターフェースはどうするか、コンテナサービスをどうするか、などなどあるかと思いますがその辺りは既存のスキルセットを踏まえた上で決めればいいかなと思っています。
個人的には処理に適した言語、gRPCなどで定義の一元化と配布などを考えたりします。

この記事が気に入ったらサポートをしてみませんか?