skillup

技術ブログ

プログラミング全般

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

投稿日:2020年8月22日 更新日:

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

参考文献

Software Design 「2020年1月」

マイクロサービスとは?

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

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

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

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

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

具体例

フロントエンドとバックエンド

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

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

非同期的なキューがらみの処理

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

マイクロサービス化しやすいもの

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

  • 設計上分離がしやすいもの(フロントとサーバーサイド)
  • 非同期的な処理のもの
  • 処理の独立性が高いもの(理想を言えばDBなども独立しているものの方が良いようです)
  • その他、業務上の独立性が高いもの

マイクロサービスで使われやすい技術群

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

  • RESTAPI
  • Faas(AWS Lambdaなど)
  • メッセージ処理(AWS SNSなど)
  • キュー処理全般(AWS SQSなど)
  • 仮想化技術全般

メリット

各サービスが疎結合になる

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

サービス単位の拡張や修正がしやすい

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

テストがしやすい

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

開発を独立して進められる

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

別の技術に交換可能

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

デメリット

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

サービス自体が増えることで管理が煩雑になる

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

共通のメソッドを結果的に複数のサービスに書くことになる

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

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

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

各サービスのルール、統一化などが煩雑

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

別サービスの開発遅延などの影響を受ける

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

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …

no image

テストコードの考え方

一般的なプログラマにとって日々の業務で何がいやかというと、 理不尽な納期 むちゃくちゃな仕様変更 頻発するバグ・不具合 であることは異論がないでしょう。仕様変更や納期などは自分で何とかしがたい部分もあ …

no image

webの仕組み その1 Webの基本的なイメージ

Webの仕組みについて基礎からちょっと勉強しようかと。自分用なのでまとまってません(爆) Contents1 Webの基本的なイメージ2 HTTPメソッド Webの基本的なイメージ ネットワーク上のリ …

no image

画面テストのツールに関して

Unitテストに関してはxUnit一択だと思いますが、UI系のテストツールについて。 IDE(コードを書かずにすむマクロ系)に関して全てChromeで動くことを確認しています。 Contents1 ツ …

no image

テストプロセスに関して

日々是テスト。 プログラマになってから数年がたちますが難点はずっと同じでテストですね(汗) 以前にかいたエントリーなどは下記参照。 参考 データベースによるテストデータ作成 Excelによるテストデー …