【初心者でも10分で理解】マイクロサービス・アーキテクチャのメリット・デメリットを解説

今回は、こんな疑問に答えていきたいと思います。

この記事を読めば、以下について理解して、誰かに説明ができるようになります。

マイクロサービス・アーキテクチャを理解できれば、現場で使われている技術について理解できますので、ぜひとも最後までお読み下さい。

なぜ、マイクロサービス・アーキテクチャが流行しているのか？

まずは、現状のアプリケーションの課題を理解します。その上で、なぜマイクロサービス・アーキテクチャが誕生したのかを理解します。

モノリシックなアプリケーションの課題

アプリケーションを開発したことがあるなら、以下のような課題を抱えていませんか？

このような悩みを抱えている方は、「モノリシック」なアプリを開発している可能性が高いと思います。

例えば、Ruby on RailsでもLaravelでも、何かしらのWebフレームワークを使って、AmazonのようなECサイトを作るとします。

そこで「ログイン機能」や「決済機能」、「商品管理機能」といった様々なサービスを全て同じプロジェクト内にコーディングして、1つのWebサーバーにデプロイをすることが多いと思います。最初のうちは機能が少ないので、管理がそこまで煩雑ではないかも知れません。

しかし、段々と機能がたくさん実装されていくうちにシステムが膨大になります。すると、何か障害が発生して、コードを修正する際に、影響調査の難易度が上がり、改修工数も段々と大きくなります。

またWebフレームワークのメジャーバージョンが上がったら、全ての機能を一気に対応しなくてはならないので、メンテナンスとても大変です。

更には、何か技術的な課題があったとして、今までRuby on Railsを使っていたけれども、他のフレームワークや言語を使いたいとなった時が大変です。

モノリシックなアプリケーションだと、「全てを書き換える必要があるので、技術的な負債を返済しにくい」という問題があります。

上記のようにモノリシックなアプリケーションには色々な課題や問題があることが分かります。

「何か良い解決策はないの？」と皆が思った時に誕生したのが、今回のテーマである「マイクロサービス・アーキテクチャ」です。

マイクロサービス・アーキテクチャとは何か？

マイクロサービス・アーキテクチャとは、「複数の小さなサービスをAPIとして連携させて、一つのソフトウェアを構成するアーキテクチャ」のことです。

マイクロサービス・アーキテクチャでは、「ログイン機能」や「決済機能」、「商品管理機能」といった機能を一つのWebサーバーに詰め込むのではなく、それぞれを一つの小さなサービスとしてWebサーバーも分けます。

複数の独立した小さなサービスを組み合わせて一つの処理を実現します。

これにより、サービス同士が疎結合となり、互いの影響を受けなくなります。

モノリシックなアプリケーションとマイクロサービス・アーキテクチャのアプリケーションを図にすると以下のようになります。

DBもビジネスロジックに応じて、分けることも可能となります。

マイクロサービス・アーキテクチャの利点

マイクロサービス・アーキテクチャの概要が分かったところで、もっと詳しい内容を見ていきましょう。

マイクロサービス・アーキテクチャのメリットは以下となります。

機能追加・修正による影響が少ない

モノリシックなアプリケーションは機能を追加していく度に複雑度が増していき、どんどんとスパゲッティ・コードになっていきます。

複雑度が増すと、コードを追加・修正する際の影響調査範囲が広くなり、難易度がどんどんと上がっていきます。

マイクロサービス・アーキテクチャは文字通り、小さな機能で一つのアプリケーションが構成され、影響範囲も狭くなるので、モノリシックなアプリケーションと比べると低リスクで機能の追加・修正が可能になります。

低リスクで改修が出来るということは、アプリケーションの成長速度が速くなり、ソフトウェアの価値を上げやすくなります。

異なる技術スタックを積極的に採用出来る

モノリシックなアーキテクチャを採用していると、書き換えの時間とコストが高くなり、アプリケーション全体に影響を及ぼすため、 新しい技術スタックの採用が難しくなります。

しかしマイクロサービス・アーキテクチャであれば、それぞれの機能は独立しているので、それぞれのサービスの特性に合わせて技術スタックを選択することが出来ます。

例えば、商品管理機能はnode.jsで実装しているけれども、レコメンド機能は機械学習を使いたいので、ライブラリが充実しているPythonで実装するみたいにかなり柔軟に技術を選択することが出来ます。

費用対効果の高い機能だけ、とりあえず先にアップデートするということも出来るので、優先度を決めてちょっとずつ対応していくことが可能になります。

単一障害点をなくせる

モノリシックなアプリケーションはどこかに障害が発生すると、アプリケーション全体が停止してしまいます。

しかしマイクロサービス・アーキテクチャであれば、「ある特定のサービスに障害が発生しても、そのサービスを切り離してしまえば、アプリケーション全体は停止せずに稼働させ続けること」が出来ます。

マイクロサービス・アーキテクチャにすることで単一障害点がなくなり、アプリケーションの可用性が上がります。

単一障害点とは、その単一箇所が働かないと、システム全体が障害となるような箇所を指す。

引用元：https://ja.wikipedia.org/wiki/%E5%8D%98%E4%B8%80%E9%9A%9C%E5%AE%B3%E7%82%B9

スケール・冗長化がしやすくなる

例えば、ECサイトにおいてあるキャンペーンを行ったため、「商品管理機能」への負荷が高まったとします。

モノリシックなアプリケーションの場合、特定のサービスだけスケールさせることは非常に難しいです。

しかし、マイクロサービス・アーキテクチャであれば、比較的簡単にスケールさせることができます。

また絶対に停止しては困るサービスについて、冗長化させることも簡単になります。

それを支える技術が、Dockerのコンテナ技術やKubernetesといったコンテナオーケストレーションツールです。

Dockerについて理解するなら、以下がおすすめです。

リリースまでのスピードが速くなる

モノリシックなアプリケーションは全ての機能が開発出来たらリリースとなりますが、マイクロサービス・アーキテクチャであれば必要最低限の機能さえ開発が出来たらリリースが出来ます。

そのため、リリースまでのスピード感が速くなります。

またチーム編成についても、サービス毎に編成されるので、マイクロサービス・アーキテクチャを開発するチームは、少人数のチーム編成になりやすいみたいです。これについてはAmazonの「two pizza rule」が有名です。

マイクロサービス・アーキテクチャのデメリット

ここまでマイクロサービス・アーキテクチャのメリットを紹介してきましたが、デメリットもあります。

以下ではデメリットを紹介します。

サービス分割の境界線が難しい

マイクロサービス・アーキテクチャと言いますが、どこまでの機能を一つのサービスとして実装するかが非常に悩みどころとなります。

大きすぎても、小さすぎてもダメということです。

解決策としては「ドメイン駆動開発(DDD)」が注目されています。

障害解析が高度化することがある

マイクロサービス・アーキテクチャでは、「様々なサービスが連携し合うため、サービス同士の連鎖的なAPI呼び出しが発生」します。そのため、パフォーマンスが劣化しやすいという特徴があります。

「非同期でAPIを呼び出すようにして全体の処理完了を待たずして、クライアントに応答を返すという実装方法」をよく採用すると思います。しかし、非同期処理は、障害解析の難易度が高くなります。

対策としては、適切なログ設計とモニタリング基盤の構築だと思います。

関連記事

スキルレベルの高いメンバーを集める必要がある

マイクロサービス・アーキテクチャでは、各サービス毎に異なる技術スタックを採用できるという点が強みでしたが、それは各メンバーのスキルレベルが高いことが前提となります。

モノリシックなアプリケーションであれば、コーディング担当、DB担当とか技術毎にチームを分けることが可能かも知れません。しかし、マイクロサービス・アーキテクチャは比較的少人数のチームで編成されることが多いため、色々な技術スキルを持っているエンジニアを集める必要があります。

そのため、スキルレベルの高いメンバーを集められない場合、マイクロサービス・アーキテクチャの採用が難しくなります。

まとめ

ここまでモノリシックなアプリケーションと対比して、マイクロサービス・アーキテクチャの特徴、メリット、デメリットをまとめていきました。

メリット	デメリット
機能追加・修正による影響が少ない 異なる技術スタックを積極的に採用出来る 単一障害点をなくせる スケール・冗長化がしやすくなる リリースまでのスピードが速くなる	サービス分割の境界線が難しい 障害解析が高度化することがある スキルレベルの高いメンバーを集める必要がある

やはり、銀の弾丸というものはなくて、マイクロサービス・アーキテクチャを採用する場合も上手く設計をしないと逆に混乱を生じるということが分かりました。

私自身もマイクロサービス・アーキテクチャを実践していますので、良い設計方法があればまだまだ追記していきたいと思います。