マイクロサービス開発とは？メリット、注意点、事例の紹介

新規事業

2020年03月11日（水）掲載

■マイクロサービスとは
■マイクロサービス開発のメリット
■マイクロサービス開発にデメリットはあるのか？
■マイクロサービスの設計時の留意点
■マイクロサービス開発の事例
■まとめ

マイクロサービスとは

マイクロサービス・アーキテクチャと呼ばれ、システムをそれぞれ複数の独立した機能で構成し、機能同士を連携してサービスを実現させるアーキテクチャです。
それぞれ異なるマシン上で稼働し、APIなどの軽量な手段で連携します。

「モノリシック・アーキテクチャ」との違い

マイクロサービスは、従来利用されてきた、「モノリシック・アーキテクチャ」と比べると理解しやすいです。

より具体的に、見ていきましょう。
一般的なWebサービスやアプリを実現するシステムであれば、三層構造（ユーザーインターフェース、ビジネスロジック、データ）のように役割によって分かれた構造になっています。
ユーザーインターフェースを指すものがブラウザ、ビジネスロジックはアプリケーション、データがデータストアとなります。

モノリシック・アーキテクチャでは、ユーザーインターフェースからくるリクエストに対して、一つのマシン内で機能が統合された大きなアプリケーションを動かして処理を行います。
アプリケーションの内部では、機能ごとにプログラムが組まれていますが、同一マシン上で実装されているため、分割はできません。そのため、機能改修や追加を行う際には、影響範囲がシステム全体に及ぶ可能性があるため、調査や多くのテストが必要になります。

マイクロサービス・アーキテクチャでは、各機能が別のマシン上で実装されており、ネットワークプロトコルを介した通信とAPIによって連携し、サービスを実現します。
そのため、機能単位で独立しての改修や機能追加を行い反映させることができます。

マイクロサービス開発は古くて新しい？

また、マイクロサービスは、古くて新しいとされていますが、単なるバズワードではなくしっかりした考え方です。
モダンな開発方式として上記のようにバズワードとして紹介されるマイクロサービスですが、「大きなものは管理が難しいので、小さいものに分けて管理して、全体として機能させる」という考え方はソフトウェア業界では常識的です。よって、ただのブームとしてではなく、今後も十分に残っていく開発スタイルだと考えています。

例えば、Mike Gancarzの「UNIXという考え方」という古典的名著でも同じような考え方が下記のように言及されています。

‘’’1. Small is beautiful. 小さいものは美しい
小さいものは、大きい物にない利点がいくつもある。小さいもの同士なら簡単に独特の便利な方法で組み合わせることができる’’’
‘’’2. Make each program do one thing well. 1つのプログラムには1つのことをうまくやらせる
一つのことに集中することでプログラムに不要な部分をなくせる。
不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かない。’’’

上記はプログラムに対する言及ですが、これをアプリケーションと置き換えたものがマイクロサービスと述べても大きなズレはないでしょう。

POINT

・マイクロサービスとは、システム内の機能をそれぞれ独立させ、そこから機能同士を連携させていくサービスである。
・従来のモノリシック・アーキテクチャでは、機能の修正や追加はシステム全体を通して行わなければならなかったが、マイクロサービスでは、それぞれの機能ごとにスポットを当てて機能の修正や追加を行うことができるので、効率的である。

マイクロサービス開発のメリット

開発者が目指していることは、質の良いサービスやシステムをより迅速に提供することです。
その前提で、マイクロサービスは変化に強いシステムを作ることが可能と言えます。

サービスごとに異なる技術を採用できる

マイクロサービス開発は、それぞれ独立的に構築していくので、サービスごとに異なる技術を活用できます。既存のコード規約やレギュレーションの影響を受けることなく、0から設計できるので、異なる技術で自由に設計できます。

障害耐性・保守性が高い

マイクロサービスは、独立性が担保されているので、他の障害の影響を受けることがありません。従来のモノリシック・アーキテクチャにおいては、1 つのアプリケーションでコンフリクトなどの障害が発生してしまうと、アプリケーション全体で弊害が起きる場合がありました。
しかし、マイクロサービス開発で、全てを独立させておけば、一緒に障害を引き起こしてしまうことはなくなります。また、システムトラブルが起きたり、ハッキングされたりしたとしても被害を最小限にとどめ、保守性の高いつくりにできます。

スケール・冗長化が容易である

マイクロサービスでは、個々のサービスを独立してデプロイすることが多くなります。このため、作業する部分だけのロールバックや差し替え、新技術のテストなどもやりやすくなります。

開発チームを小さくできる

「モノリシック・アーキテクチャ」の場合は、一枚岩でできていたため、単発の機能改修などはできず、全ての業務を横断して行う必要があり、それに従い部隊は大きくなっていました。
開発チームの規模が大きくなり、統率が取りづらくなったり、チームの把握がしづらくなったりしていました。

サービス一つ一つが小さいため把握が容易

マイクロサービス開発では、一個一個の機能・サービスが小さいため、タスクも少なく必要な人員もすくなく、全てが小さくなり、把握が容易です。

サービスの再利用性が高くなる

機能を細分化しておくと、必要な機能だけを取り出すことも可能です。例えば、予約管理システムだけを独立して機能にしている場合、別のサービスで予約管理システムを使いたい場合、そこだけ取り出すのみで再利用ができます。

他のシステムと入り組んでいたり、共通コードがある場合、スポットで取り出すなどは不可能です。マイクロサービス開発だからこそ生み出せる業です。

開発時間が短くなる

マイクロサービス開発では、小規模で独立した複数のチーム編成で行うことが多くなります。このため、メンバーは、自主的に動くことを強いられ、結果的に、開発が完了するまでの時間が短くなる傾向が高いです。
一人一人に任される業務の大きくなるので、従業員の成長なども見込めます。

POINT

・マイクロサービス開発は、
✔サービスごとに異なる技術を採用でき、開発しやすい。
✔障害耐性・保守性が高いので安心できる。
✔スケールしやすく、個別にデプロイすることができる。
✔開発チームを小さくし、サービス一つ一つの把握を簡単にする。
✔サービスや機能の再利用性が高く、転用しやすい。
✔開発時間が短くなり、メンバーの育成にも役立つ。
などのメリットがある。

マイクロサービス開発にデメリットはあるのか？

マイクロサービス開発は便利に用いられており、今後を塗り替える開発スタイルになりそうな勢いですが、デメリットはあるのでしょうか。

技術理解が必要

マイクロサービスの開発では、技術的に自由で、エンジニアに裁量権がある分、さまざまな言語で書かれてしまうことも事実です。このため、部門を統括する管理者や役職にとってはかなり高度なことが求められます。
例えば、サービス紹介システムは○○の言語であるのに、予約管理システムは△△の言語で書かれているので、二種類の技術に関して理解しないといけない、などと言ったことが起こり得るのです。
このため、マネジメント層や部門管理者にとっては、技術面で負担となるでしょう。

POINT

・マイクロサービス開発においてはさまざまな言語が使われる分、管理や統括をする立場の人には、技術的な知識が問われる。

技術経営や、技術者のマネジメントについては以下のコラムでも解説しています。

人気の関連コラムを読む

MOTとは？技術経営の必要性　～イノベーションの手段としての例、人材育成など～

VPoEの役割～エンジニア組織のマネジメントと採用戦略～

マイクロサービスの設計時の留意点

マイクロサービスを採用して設計を行う場合には、求められる機能をどの粒度で分割するかが重要となります。

なぜなら、各機能を細かく分割しすぎると、コストやパフォーマンスに影響するようなオーバーヘッドが発生しやすくなります。
逆に、分割粒度が大きいとマイクロサービスのメリットが少なくなってしまうためです。
また、運用時の課題として監視対象が増えることによりサービスの死活監視やデータログの管理が煩雑になるといった問題も挙げられます。

データベースについても検討が必要です。
機能ごとにデータベースを管理し、各データベースは1つの機能のみからアクセスできるようにする必要があります。
このように設計することで、独立性が向上し、ロックやトランザクションなどにまつわるトラブルやパフォーマンス低下などを防ぐことが期待できます。

そして、機能同士の連携については同期的な手法と非同期的な手法の2種類があり、通信方法の選定もマイクロサービス・アーキテクチャを利用するに当たって重要なポイントとなります。
同期的なメッセージ通信の実現手法として一般的なのが、HTTPベースでやりとりを行う「REST」と「RPC（RPC over HTTP）」という手法があり、よく使われています。

マイクロサービスを選択する場合、このような問題を認識した上で、設計時には十分な検討が必要と言えます。

POINT

・マイクロサービスを利用する際の注意点としては、効率良く機能が働くための最適な分割粒度を模索する必要があるということだ。
・また、それぞれの機能の独立性を損なわせないために、一つの機能ごとに一つのデータベースのみからアクセスができるように設定しておくこくことが必要である。

マイクロサービス開発の事例

マイクロサービス開発は多くの先進的企業も導入しています。ここでは実際に活用している企業を紹介します。

事例1.　クックパッド株式会社の事例
クックパッドの中核サービスであるレシピサービスのアーキテクチャ改善プロジェクトにて、全面的にマイクロサービス化しています。
これによって、独立性の高いチームが比較的小さなサービスを素早く開発し、ユーザーにスピード感をもって価値を届けるという体制を作ることができたそうです。

事例2.　Amazon.comの事例
Amazon.comではマイクロサービスという言葉が出てくる前から、現在でいうマイクロサービスを採用しています。当時、モノリシック・アーキテクチャの限界を感じたファウンダーのジェフ・ベゾスが、肥大したシステムをマイクロサービス化し、各システムはHTTPSのAPIだけで連携させるように全社に向けて発信しました。
しかもAPIには、当時はまだ主流ではなかったREST APIを採用しました。
これを徹底するために、正当な許可なくマイクロサービス以外のシステム、API以外で他サービスと連携するシステムを作ったエンジニアはクビにするとまで言い切ったそうです。

事例3.　株式会社メルカリの事例
価値の高いものを生み出していくために、一人ひとりのエンジニアが「こうしたい」と思ったことを実現できる環境づくりに力を入れるため、マイクロサービス化したそうです。
マイクロサービス移行プロジェクトは2018年頭ごろに本格的にスタートしました。

事例4.　LINE株式会社の事例
Amazon.comと同様、当時は、マイクロサービスという言葉はありませんでしたが、独自にLINE流マイクロサービスを採用していたそうです。
メッセージングサービスの核になる「Talk-server」が中心にあり、個々の機能をサービスとして開発し、すべてAPIでつながっています。
また、各サービスは開発言語もバラバラで、独立して開発されています。
そのため、全体としてはシンプルで、効率よく開発できると言われています。

事例5.　Netflix株式会社の事例
マイクロサービスと継続的デリバリ（アプリケーションの新しいバージョンを低コストで迅速かつ簡単に、自信を持って展開できるようにするためのソフトウェア開発プラクティス）を組み合わせることで、新しいアイデアを素早くテストし、顧客エクスペリエンスを継続的に改善しています。

POINT

・マイクロサービス開発は多くの企業が取り入れている。
・マイクロサービス開発は様々な価値を生み出しており、チームの独立性を高めアップデートを早めたり、ひとりひとりのエンジニアの責任範囲を高めモチベーションを向上したり、新しいアイデアを素早く継続的にテストできるようにしたりしている。

まとめ

有名企業の多くがマイクロサービス化に移行中、または検討しています。
変化の激しいこの時代で、世の中のニーズに対して柔軟に素早く対応することが可能となるマイクロサービスを採用するメリットは大いにあると言えます。

ただし、マイクロサービスはメリットも多くありますが、設計時の注意点もあります。
各機能の規模は小さくなりますが、開発にあたるエンジニアはビジネスロジックの構築はもちろんのこと、同期・非同期通信やDB、インフラまで幅広い知識が求められます。
そして、機能の分割粒度に関しては特に十分な検討が必要です。

HiPro Bizでは、専門知識や業界の知見の深いプロ人材を紹介することができます。
マイクロサービスの導入は自社のみで行うのは大変かもしれません。なぜかと言うと、経験がないために予測し得るトラブル自体が想定できなかったり、専門知識がないために回り道をしてしまったりするおそれがあるからです。
また、いきなり導入すると言っても、最初のスタートの仕方、すなわち既存アプリケーションの分割方法がわからない方も多いでしょう。

HiPro Bizに登録しているプロ人材に依頼すれば、それらで迷うことはありません。実績や経験から基づく戦略設計が可能であり、また、プロ人材に実際にプロジェクトメンバーにも入ってもらい実働支援を受けることができます。
プロ人材は経営層とプロジェクトを繋ぐメンバーになりえるため、経営戦略からもブレずにプロジェクト推進が可能です。HiPro Bizの登録プロ人材がお力になりますので、どうぞお気軽にお問い合わせください。