AmazonもLINEもメルカリも採用。マイクロサービスアーキテクチャって何?

どうも、ITコンサルタントのShoheiです。

こたつの季節がやってきましたね。今日はこたつからの更新です。

さて今日は、マイクロサービスアーキテクチャについて簡単に説明をしていきたいと思います。

マイクロサービスアーキテクチャとは

早速ですが、マイクロサービスアーキテクチャって聞いたことありますか？

僕は勉強するまで知らなかったのですが、多数の大手Webサービス提供会社が採用している有名なアーキテクチャです。タイトルに書いた企業の他にも、Netflix、クックパッド、Gunosy、ウォールマート、Twitterなども採用を公表しています。

これが何かを超絶端的に言ってしまうと、「多数機能を実現する大規模なサービスからシステムを作るのではなく、多数の独立したサービスの集合体からシステムを構成させるアーキテクチャ」のことです。イメージは下の絵です。

f:id:go-mount:20181127205747p:plain

もう少し説明するよ

もう少しだけ、ざっくりですが説明しましょう。

サービスを分離する指針は？

基本的なサービス指針としては、以下のようなものが挙げられます。

サービスの境界をビジネスの境界に合わせる。 (独立・重複なし、１サービス１ビジネス機能)
一つのサービスを複数の組織で開発しない
他のサービスの変更をせずに、単独でサービスの変更やデプロイが行えるようにする
各サービスのコード数の規模感は「２週間で書き直せるもの」程度にとどめる

サービス同士はどうやり取りする？

いくつかやり方があるのですが、例えばREST APIなどを利用することで、他サービスから情報を得たり、他情報に情報を与えたりしています。

重要なことは、下の図のようにあるサービスが他サービスの内部事情を知る必要がない仕組みにしておくことです。

f:id:go-mount:20181127213512p:plain

主なメリット

では、このアーキテクチャを導入するメリットを説明しましょう。

実装技術が異なっても良い

例えば、サービスAは実装にjavaを使うが、サービスBにはrubyを使うだとか。

サービスごとに独立をしているので、技術も異なって問題ありません。

また、何か新しい技術が出た時、全体を置き換えるにはリスクがある、といった場合にも、あるサービスに閉じて導入ができるので、迅速に最新技術の導入が進められるというのもメリットです。

独立してスケーリングできる

以下のようなケースの場合にスケールアップ考える場合、モノシリックシステムでは、ボトルネックとなっているサービス以外も一緒にスケールさせていく必要があります。

サービスAの利用数がかなり増えてきた
土日だけサービスBの利用者量が増える

一方でマイクロサービスアーキテクチャでは、リソースが逼迫しているサービスだけインスタンスを拡張するなどといった局所的スケーリングが可能となります。

機能追加にかかるタスクを小さくできる

モノシリックシステムでは、特定の部分に小さな変更を加えたとしても、他の様々な部分に影響を与えてしまう可能性があります。そのためテストを入念に実施する必要が出てきたり、それがゆえに各機能でまとめてリリース作業をしたりします。しかしそれではスピード感が損なわれる上、まとめてのリリースは変更差分が大きくなるのでリスキーです。

その点マイクロサービスアーキテクチャでは、他サービスとのやり取りに使うAPI仕様などを変更しない限りはあるサービスに閉じた変更が可能なので、スピーディーな変更に対応ができます。