マイクロサービスについて

マイクロサービスについて勉強したので少しメモを。

参考文献

Contents

マイクロサービスとは？

ものすごくざっくりいうと一つのアプリケーションを細かく分割することで、各機能を疎結合にし、保守性を向上させようという設計思想だと思います。

一般のアプリでもクラスを設計する際に、このような考え方(疎結合や分離)などをするかと思いますが、マイクロサービスとはアプリ自体を分割してしまうことですね。

Webアプリって基本的には機能がどんどん追加されるので、何も考えずにおくと機能がとんでもなく膨らんじゃうんですよね・・・

で、気付いた時には依存度が高くて、修正が行えなかったり、使わなくなっている機能とかが山のようにあったりします。

そのような場合にこのような設計思想があるとサービスの企画・開発・運用などをよりスピーディーに行うことができるようになります。

一番わかりやすいのはフロントとバックエンド(サーバーサイド)の分離ですかね。昨年ぐらいの現場でよくあったのですが、サーバーサイドは基本的に全てRESTAPIをJSONで返し、フロントはそれをレンダリングするというパターンですね。

これも通常のMVCパターンで密結合なものを切り分けているという点でサービスの分離と言えるでしょう。このようにしておけば、バックエンド自体は別のサービスにも使えるので。

直近の現場でよく使っていた技術がこれです。後述しますが、非同期的なものというのはマイクロサービス化しやすい特徴があるかと思います。同期的なものでなければ非同期化することにより、サービスの結合度を弱めやすいという特徴があります。

一般的には下記のような特徴を持つものがマイクロサービス化しやすいかと思われます。

下記のような技術がよく使われているかとおもいます。

もともとは１つのサービスのデメリット(結合度が高い)ことを減らせるのが一番大きなメリットかと思います。この疎結合というだけでいろんなメリットがあり、以下にあげるような部分に影響が出てきます。

他の部分への影響が少なくなるので、マイクロサービス自体の拡張などは楽になり、容易に修正ができるようになります。

分離されている分、マイクロサービス自体で完結してますのて、テストがしやすくなります。

仕様が決まっていることが当然ですが、ある部分が作られていないから開発できない・・・ということがなく、それ単独でのサービスの開発が可能になります。

例えばベースのWEBアプリはLaravelで作って、キュー的な処理を行うにはAWS Lambdaとかですね。新しい技術を試す場合、別サービスに切り分けているので簡単に別の技術を試すことが可能です。

まあ、当然いいことばっかりじゃないですね。自分が携わった点であげられるデメリット(と対策)などを。

AWS関連とかだとインフラ管理でコード化することはできます。他のものも手の管理は難しいので、なるべくコード化する必要がありますね・・

DBのアクセスとかロガーとかユーティリティー系ですね・・細かく分けると何度も同じものを書くことになります。

共通処理がある時点でマイクロサービスにするのが間違っているのかもしれませんが、現実的にはDB自体を分離するというのはかなり難しくなると思いますので、共通のものを使わざるをえないということが多いでしょう。

samとか使えば複数のLambdaを管理することができるので、他のソースの変更とかを取り込めるのでは・・・と妄想

似たようなLambdaを複数配置すると書く人によってバラバラになったりするんですよね・・・
対策は静的解析ツール、レビューをしっかりやる？などかな・・・

開発上、一番ネックになるのはこれかもしれません。理想論としてはインターフェイスをしっかり決めておき(これがなかなか難しいですが・・)、完成するまでダミーデータなど(RESTだったらJSONのサンプル)でなんとか凌ぐしかないですね・・・