マイクロサービスについて勉強してみた

私はモノリシックなサービス開発ばかりしていて、マイクロサービスの良さがあまり理解できてませんでした...それ故に技術選定で後悔するような選択をしたくないので、これを機会に学びたいと思い記事を書こうと思いました。

後述のサイトを参考に勉強を進めました、サイトに書いてあるメリット・デメリットを閲覧し、私がパッと浮かんだ良さそうなところ・大変そうなところを書いてみたいと思います。

上記サイトを見ると「マイクロサービスとは？」「モノリシックサービスとは？」情報がまとめられてます、もしもマイクロサービスとモノリシックサービスを知らない方は対象項目を見ないと、この記事は見づらいと思われます。

・負荷分散

これは、マイクロサービスなので機能単位でサーバーを分けれるから、負荷分散ができる点は良さそうだと思いました。

まずフロントとバックエンドのサーバーを分けれることができますよね。

他にも細かく分けるなら、バックエンドであれば機能単位で、APIサーバーが分けれますよね。(複雑な例を上げると長くなるので、簡単な例で書いてます。)

例：掲示板アプリのバックエンド

__認証関連APIサーバー

__掲示板CRUD関連APIサーバー

・異なる技術を採用できる

上記の例で出てきた掲示板アプリのバックエンドより、以下のようなことができますね。

仮に掲示板アプリのアサイン者が5名で以下のような配分であった場合のお話になります。

3名はLaravel未経験だがRuby on Rails経験あり

2名はRuby on Rails未経験だがLaravel経験あり

上記の場合は以下のような開発手法が取れそうですよね！

「認証関連APIサーバー」はRuby on Railsで開発(アサイン者：3名使用)

「掲示板CRUD関連APIサーバー」はLaravelで開発(アサイン者：2名使用)

※パッと浮かんだシナリオがこれでした、破綻してたら申し訳ありません。

・設計が大変

私がモノリシックなサービスばかり作っているせいか、実際に機能単位で分けるとしても、どう分けるのか？分けた後に疎結合することまで考えると、パッと良い設計が浮かばず...

(最初に機能単位で分割する設計からスタートすると思うのですが、分割単位を後から変える！というのは簡単にできないように思えますし、設計は大変そうに見えました。)

・統合テストが難しい

確かに機能単位で分けれる反面、統合テストでエラーが出た時に、別チームが制作した機能のAPIドキュメントがしっかり整理されていない場合に遭遇したとき、苦労しそうだなと思ってしまいました。

※以下は、私の勝手な想像になりますが....

APIドキュメントが古くて、なんかリクエストのパラメーターが不足してるんだけどそれが何だかわからない....といった風になると原因特定が大変そうですね。

今回はメリット・デメリットが書いてある記事を閲覧し良さそうなところ・大変そうなところを簡単に書いてみました、「将来的に拡張が多そうだな」「規模が大きなサービスだな」と想定されるケースにはマイクロサービスを採用する価値はあるなと思えました。

今回の勉強を活かすために個人開発でフロントをNuxt.jsでバックエンドはLaravelを利用した開発にチャレンジをしてみたいと思ってます。

また、対象の開発にチャレンジしてみて開発に関する感想をブログの記事にしてみたいと思います。

以上となります、次回の記事で会いましょう。