【開発者ブログ】今さら聞けない？マイクロサービスのメリットとデメリット

遅くなりましたが、あけましておめでとうございます。フロントエンドエンジニアの小原です。

去年のブログで「次回の今さら聞けない？シリーズはマイクロサービス」と宣言しましたが、2ヶ月もあいてしまいましたね。そんな訳で今回の話題はモダンなシステムを開発するうえで避けて通れない話題「マイクロサービス」についてです。

マイクロサービスってなに？

マイクロサービスとは、アプリケーションを疎結合サービスの集合体として構築するサービス指向アーキテクチャ（SOA）スタイルの変種である。マイクロサービスアーキテクチャでは、サービスは細かく、プロトコルは軽量でなければならない。アプリケーションを細かいサービスに分割する利点は、モジュール性が向上し、アプリケーションの理解、開発、テストが容易になる。また、小規模自律チームがそれぞれのサービスを個別に開発、展開、拡張できるようにすることで、開発を並列化する。また、個々のサービスのアーキテクチャが継続的なリファクタリングを通じて出現することを可能にする。マイクロサービスベースのアーキテクチャにより、継続的な配信と展開が可能である。

英語版ウィキペディアより抄訳

これだけだと何のことか分かりにくいので具体的な例を上げてみましょう。

ECサイトの場合
例えばECサイトの場合、以下のような機能が考えられます。

トップページ
商品ページ
商品検索
買い物かご
会員機能（マイページなど）
問合せフォーム
決済機能
商品管理
画像管理
在庫管理
配送管理
注文管理
顧客管理
特集ページなどのメディア機能
レコメンド
メール機能
メールマガジン配信
広告出稿

マイクロサービスではないモノリシックなシステムの場合、下記のようになります。

一つのシステムの中に、必要な機能が入って稼働しています。機能が少ないうちはこの方が開発コストも運用コストも少なくすみますが、運用していくうちに「あの機能が欲しい」「あの機能を改修したい」「このサービスを追加したい」など、機能が追加されていきます。すると、こんな感じに。

この状態を密結合状態といい、保守や新規開発がしにくい状態となります。例えば「ログインページのフォームの色を変えたのに、何故か検索フォームの色が変わった」。「メール配信のバグを修正したらメルマガが配信できなくなった」。「レコメンドエンジンを追加したらデータベースに異様な負荷がかかるようになった」。「リリースしたら障害が発生し、原因を突き止めるのに時間がかかった」なんてこともおきたりします。

そこで、各機能を切り離してAPIで繋いでしまおう、というのがマイクロサービスです。

例えば上記ではそれぞれ「ECサイトのC向け機能」「ECサイトのB向け機能」「会員認証機能」「マーケティング」にそれぞれサービスを分けて、別のサーバで稼働しています。これをオンプレミス（サーバを自前で立てる）で構築するとコストと手間が莫大にかかるので、AWSなどクラウドを使うのが一般的です（エンタープライズ向けですとオンプレミスもありますが）。図ではざっくりとした分け方ですが、本当にコンポーネントごと一個一個分割する場合もあります。やりすぎると大変になりますが。

メリット

マイクロサービスには以下のようなメリットがあります。

既存のサービスへの最小限に抑えられるので、新機能・新サービスの開発がやりやすくなります。また、スピーディな開発が可能となります。

メンテナンス性が向上する
サービスを切り離し、疎結合な状態にすることによってメンテナンスがしやすくなります。

障害に対して強くなる
サービスが疎結合な状態なので、システム全体への障害の連鎖がしにくくなります。

新しい技術の導入が容易になる
アプリケーションが疎結合になっているので、新しい技術の導入が用意になります。例えば元々はPHPのフレームワークで作っていたものを、新しくNode.jsやRailsで開発するなど。これはフロントエンドでも同じことがいえます。

デメリット

一見いい事ずくめにみえますが、デメリットもあります。

運用管理コストが上がる
単純に複数サーバで運用するので運用管理コストは増大します。サーバの費用もそうですが、環境構築や監視、メンテナンスなどサーバが増えるのでそれも運用コストとなります。

データの整合性
データベースも複数運用となると、データの整合性の問題も出てきます。また、既存サービスをデータ分割するとなると難易度が上がります。

結合テストが難しくなる
アプリケーションが複数のサーバ、インスタンスにまたがった構成になるので結合テストが難解になります。

ちょうどいいマイクロサービス化

サービスをスケールしながら運用保守し、かつインフラコストも増大させないということを考えると「ちょうどいいマイクロサービス化」という結論になります。モノリシックはプロダクトが大規模になってくると、開発速度が下がりますし、かと言って極端にコンポーネント単位でマイクロサービス化すると保守が大変になります。この辺はアーキーテクトとビジネスの兼ね合いもありますが。