マイクロサービスとモノリシックなサービス

こんにちわ。ぽん太です。

今日はマイクロサービスとモノリシックなサービスについて触れていきたいと思います。

サービス指向アーキテクチャとかその時代ごとに流行りがありますね。 SI出身の私は、あまりその時の流行り物を導入することを推奨していません。

同じシステムを10年以上運用することを考えると、流行り廃りのないものを導入してもらうほうが、ずっとサポートが受けられたり、使っているライブラリのメンテナンスも継続されてパッチが当てられたりと長年使うには良いと思うからです。

流行り廃りがあってその中で、これからの主流になるなと思うものを取り入れていくのは良いことだと思います。

そういった観点で、今回は解説してみたいと思います。 ※入門用であり、参考程度にお願いします！

モノリシックなサービスとは

うーん。まさにモノリス。 これらの機能が、1つのインスタンスの中で動作し、お互いに密結合で動作しあう。

メリットを考えるとこんな感じかな。 　・通信のコストがなく、コンピューターリソースが適正であればマイクロサービスと比較したら早い。

　・お互いの機能が参照しあえる

　・機能間でデータも簡単にやり取りできる。

　・同一サーバー内で動くので、旧来のインフラで動かせる。

　・開発のプロジェクト（Git)の単位も1個でOK

　・開発チームも1チームとかモノリシックな感じで運用できる。

　・複数のサーバーやコンテナが不要

デメリット 　・密結合なので、1つを止めるのには全部を止める必要がある。 　・機能間でデータの参照をモジュールの独立性を考えておかないとぐちゃぐちゃに。 　・ソースコードが肥大化。 　・開発チームも大きくなるとみんなで1つのGitプロジェクトにマージするのが大変。

基本的によく使っているサービスはこれが多いんじゃないかなと思います。

データベースとWebやバッチなどをある程度分離して、負荷のかかる個所をスケールアップかスケールアウトしていけば、 データベースの限界までスケールしていきますしね。

分散コンピューティングという観点で見ると並列処理化できるところと出来ないところがあるのでそこがネックになってしまうかも。

マイクロサービス

これまた複雑。機能単位などで独立したサービスを開発する。 そしてサービス間の連携は、同期であればHTTPを、非同期であればAMQPなどのプロトコルを利用して、 通信し合うことで処理を実行していきます。

見るからに複雑化するんですよね。全体が。 その代わり作る単位を考えれば1つ1つは、簡単になるしその単位で運用していけるメリットがありそうですね。

メリットを考える

・1つ1つが独立して動作するので、1つが落ちても依存関係のない機能は動き続けることができる。

・うまく機能を維持すれば、1つ1つのサービスではシンプルにできそう。

・ソースコードも1つのまとまりが小さくて簡単になりそう。

・各機能の単位で、拡張できるので、細かくスケールアウトが設定していける。

・非同期のプロトコルなどをうまく使えば、必ずしも遅いわけではなさそう。

デメリット ・通信が発生するのでその分モノリシックなサービスよりコストがかかる。

・お互いを参照するにはインターフェイスを作って通信しないと見れない。

・複数の機能が独立して動作するので、クラスターが必要になる。k8sとか。

・開発プロジェクトの単位は当然、サービス単位ですよね。

・サービスのまとまりを維持しようとすると、サービスがどんどん増えそう。

・開発チームを複数作るほうが効率が良さそうだが、コミュニケーションが大変そう。

マイクロサービスはもちろん利点もいっぱいあるのですが、マイクロサービスゆえの難しさ、課題が発生すると思っています。 実はモノリスでよかったのに。となった時に、利点が消えてしまう可能性も。 (自分で言ってて保守的だなぁ)

特に受託開発などでは結構厄介になりそうな気がして、挑戦できる環境でいと採用する気が起こらないですね。 心配なのは障害が起きたときの原因特定や、ログの調査が通信ログを追っていくのが大変そうに見えます。

不具合起きて迷宮入りでもまあいいよいいよ、と言ってくれる環境なら積極的に使ってみたいかも。

クラスターなどの導入を考えるので、一時の流行りで数年後にサポートが切れたら・・・とか。 そういうことを先立って考えてしまうのは良くない癖でしょうか？ 自信をもってユーザーに勧められないとどうも提案しずらいです。

まとめ

これは私がマイクロサービスを運用しているチームをみて感じたことなので、参考程度に読んでいただくのがいいかなと思います。 下記に書いているのは、一般的な分散コンピューティングのメリットデメリットのようです。

` 高信頼 故障部分以外は稼動可能 ` 
`  安価 グロッシュの法則（コンピュータの能力 ∝ コスト2）が破れ、ハードウェアとソフトウェアのコストが逆転。`

` レスリー・ランポートは、「分散システムは、そんな障害があるとは思ってもみなかった障害によって利用不能になるシステムである」と述べている `  
` 分散システムにおけるトラブルシューティングや診断はますます困難になりつつある。問題の原因を突き止めようとすれば、遠隔ノードへの接続が必要であり、ノード間の通信内容を調べる必要がある。 ` 
` 分散環境に適さない計算の種類も多い。特に通信量が多くなるものや同期が必要なものは適さない。`

ご自身で採用される場合は、一時の流行りなのかそれともこれからの主流なのか。

作ろうとしているものは、どの構成が向いていてどれが向いていないのかなどをよく吟味して採用すべきだと思います。 古いとか新しいとかはあまり関係なくて、最適なものというものを探してそれを導入していくという努力をしていくことが大切だと私は思うのです。

発注頂いたお客様であったり、自社の社内向けであったとしても、自分のチームと利用者にどんなメリットが与えられるかという観点で、 最適解を探していきましょう。

以上。ぽん太でした。