マイクロサービス（Microservices）

「マイクロサービス（Microservices）」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回はクラウド時代になって注目されている新しいITシステム開発の考え方である「マイクロサービス」について解説し、それを通じてITにもビジネスにも変化の速度が求められる昨今において、ITシステムやビジネスの実現において何を意識すべきかについて考えます。

マイクロサービス（Microservices）とは

「マイクロサービス」（Microservices）ないしは「マイクロサービスアーキテクチャ」とは、ソフトウェア開発技法の一つです。アプリケーションやITシステムを、多数の「小さな独立した部分」として作り、それらの組み合わせによりITシステム全体を実現するソフトウェアアーキテクチャの考え方のことをそう呼びます。
旧来のソフトウェア開発手法が抱える問題を解消するために、2010年代になってから提案された考え方です。アジャイル開発手法の普及や、クラウドサービス上でのクラウドネイティブなシステム開発など、ITをめぐる新しい状況に適した考え方として、ITシステム開発で取り入れられることが増えています。

マイクロサービスは「独立した小さい部分を組み合わせる」考え方

マイクロサービスをごく簡単に説明すると、ITシステムやアプリケーションを、「それぞれが自律性のある小さい部分」を組み合わせたものとして実現する考え方のことです。「疎結合」の考え方（下記リンク参照）での、ITシステムの開発運用を実現する具体的なシステムアーキテクチャの一種でもあります。

⇒ 疎結合｜用語集

以上がごく基本的な説明なのですが、あまりイメージが湧かないし、そのようにする理由をイメージしづらい人の方が多いかなと思います。

従来からの開発手法がうまく行かないことから提案された新しい考え方

マイクロサービスが話題になっているのは、クラウド時代の新しい状況において「従来のシステム開発手法では問題が起こるようになっていた」ためです。つまり、問題が発生していて「それを解決する手段」として支持されるようになったところがあります。

マイクロサービスの長所としてよく語られる特徴には、日々進化する巨大なクラウドサービスをスムーズに開発運用するような「新しい状況でのITシステム開発」において、従来手法が抱えがちだった問題点を解消する提案になっていることがあります。

従来のシステム開発での考え方：「モノリシック」

では、マイクロサービスにより改めることが提案された「従来の考え方」とはどういうものでしょうか。それは、それまでは当然だった「ITシステム全体を一体として開発する考え方」でした。システム全体が「一体となっている」ことから対比して、従来型のシステムアーキテクチャのことを「モノリシック」（Monolithic：一枚岩のような）と呼ぶことがあります。

ちなみに、モノリシックに作ろう、と意図してそうなっていたわけではありません。例えば業務システムを開発するとして、まず自分たちに何が必要か「要求分析」を行って「要件定義」を行い、分析結果からITシステムの「外部設計」を行い、その設計結果に基づいてシステムの内部設計を行って、ソフトウェア開発を実施するような伝統的な手法では、普通に作るとモノリシックなシステムになります。

「全体最適」と言われることや、「ワンチーム」という言葉が好きな人がいるように、世間では「全体を一体」として目的に合わせる考え方が推奨されていることがあります。そういう考え方で何かを作ると、「モノリシックなもの」が出来上がることが多いです。

マイクロサービスの提案は、そのような一般的な考え方に対しても、「新しい時代にあわせた別の考え方がある」ことを提案している側面もあります。

「小さく分ける」とは具体的にはどういうイメージか

「小さく分けてある」イメージが湧かない人もいるかもしれません。物事を部分に分けて整理して考えることは珍しくないことでは？と思う人もいるかもしれません。

例えば、PCでアプリを実行する時には「実行ファイル」をクリックして実行します。ほとんどの場合、「実行ファイルは一つ」のはずで、タスクマネージャーで確認しても多くの場合プロセスは一つです。しかし例えば「仮に」、Excelを起動したら、100以上にも及ぶ多種多様なプロセスが同時実行され（そもそも多数のEXEファイルが実行されたり終了したりを繰り返すなど）、それらが協調して動作する作りだったとしたらどうでしょう、ちょっとびっくりしませんか。

マイクロサービスでは実際に、そのような驚くべきアーキテクチャを採用しています。モノリシックなアーキテクチャに代わって「それぞれ独立して実行されている多数の小さな部分」があり、それらがそれぞれ独立して動作しつつ、全体として協調動作させることでシステム全体を作り上げる考え方です。「従来なかった」感じはお分かりいただけたかと思います。

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

それでは「多数の小さい単位に分けて開発する」とどのようなメリットがあるのでしょうか。

システム開発や改修が迅速になることがある

それぞれの小さい部分ごとに独立しているため、変更作業の影響範囲が小さくなり、（従来手法では大変なことが多かった）変更の影響範囲の確認や調整作業が最小限になります。結果として、機能変更要求や機能追加要求に柔軟かつ迅速に対応できる可能性が高まります。

異なる技術の混在が容易になる

従来手法では容易ではなかった、それぞれの部分で別々の技術（異なるプログラミング言語など）を採用することが可能になります。それぞれの部分の目的に適した手段での開発、例えばそれぞれの部分ごとに最適性を判断して異なるプログラミング言語を採用することすら可能になります（「ポリグロットプログラミング」と呼ぶことがあります）。あるいは、それぞれのチームのスキルに合わせて異なる技術を採用する、あるいは新旧技術の混在なども実現しやすくなります。

高負荷に対応しやすくなる方式

負荷のかかる処理を多数並列起動して負荷分散するようなことも容易になります。

障害に備えやすくなる

全体が一つの実行ファイルであるなら、何かあった時に一気にシステム全体が落ちてしまいかねません。障害で実行が停止した場合の影響を局在化できる可能性があり、耐障害性を高めたい部分だけを二重に起動して備えることも比較的に容易になります。

再利用性の向上

それぞれの部分は独立しているために、マイクロサービス単位での再利用が行いやすくなります。

ソフトウェアのリリース作業の迅速化

小さい部分ごとに独立して開発し、独立してリリース（ソフトウェアを実行可能な状態で提供すること）できるようになります。従来手法でのリリース作業では、その度にシステム全域に及ぶ調整などを経る必要があり大作業になってしまうことがありました。

アジャイル開発手法との親和性

リリース作業が大変ではなくなるので、頻繁にソフトウェアをリリースするアジャイル開発手法がスムーズに行えるようになります。クラウドサービスの開発では、一日に何度もリリース作業が行われることも珍しくありませんが、もしこれを従来型の開発でやっていたなら、あまりにも手間がかかってしまって現実的ではなくなります。

あるいは、そのような猛烈なスピードでのソフトウェアの改良が求められる今の状況に、従来手法では追いつけないためにマイクロサービスが採用されるようになりました。

ソフトウェア開発の効率化

小さい単位でそれぞれ開発作業を進めることが可能になるため、それぞれのチームごとに開発作業・テスト作業・リリース作業を独自のペースで並列に進めることができます。開発で必要なナレッジについても、自分たちが担当する小さい部分を深く理解していればよいので、チーム間での調整や確認など待ち時間が減少して開発が効率化します。

マイクロサービスの問題点

もちろんマイクロサービスアーキテクチャの採用は何もかも良いことばかりではありません。

全体として複雑化することがある

サービスそれぞれは小さくシンプルにできる一方、大量のマイクロサービスの関係が複雑になりがちです。マイクロサービス間の通信・それぞれで平行して行われる処理・マイクロサービスがいつ起動して終了するか、しかもマイクロサービスは大量に起動します。マイクロサービス自体はシンプルにできても、「マイクロサービスの間」に新しい難しさが発生しがちです。

全体を設計する人に高いスキルが必要になることがある

うまく設計しないと全体として複雑になりうるアーキテクチャであるため、全体の構造を設計する人には高度なスキルやノウハウが求められることになります。

運用が難しいことがある

動作が複雑になりうるため、システムの運用がモノリシックなシステムに比べて難しくなることがあります。運用を担当するエンジニアは高度なスキルやノウハウが求められることになります。

障害対応やデバッグが難しいことがある

複数のマイクロサービスにまたがった動作が複雑になりうることにより、システムが障害を起こしてしまったときの原因究明や、開発中においてもマイクロサービス単体での動作確認を超えたテストやデバッグが難しくなることがあります。

性能が落ちることがある

モノリシックなシステムよりも実行時の性能が出ないことがあります。効率的に一つになっているモノリシックなアーキテクチャに比べ、バラバラに実行され、通信のオーバーヘッドもあるためです。

ログの管理が難しいことがある

多数のマイクロサービスに分散されて実行される処理のログを、どうやって取得し管理するかが問題になることがあります。

データの一貫性の確保が難しいことがある

マイクロサービスの難題になることがある問題です。モノリシックなシステムではデータは一か所に集めておけますが、マイクロサービスではその考え方からデータも分散せざるを得ません。その結果、分散したデータの間で、データの整合性や一貫性の確保、あるいはトランザクションの実現などをどうするかの問題が生じやすくなります。

データをいずれかのマイクロサービスに一元管理させると、そこから設計が複雑になることや、そこが障害を起こすと広範囲に影響が出ることがあります。それぞれのマイクロサービスが必要なデータを複製して持てば、設計や実装は自然になっても、複製されたデータ間でデータ不整合が起こりやすくなることがあります。

マイクロサービスは、現実にうまく機能するアイディアか？

話としては分かったけれども、本当に実務で通用するのか？と思われたかもしれません。実際マイクロサービスの採用は容易ではなく問題点もありますが、すでに世界中で実際のプロダクトの開発に取り入れられて久しくなっています。

世界的なクラウドサービスでの実績がすでにある

例えば、Amazonはマイクロサービスで開発されており、Netflixもマイクロサービスで開発されていることが知られるなど、すでに多くの採用例があります、これらクラウドサービスは内部で非常に多数のマイクロサービスが実行されることで動作し、サービスを提供しています。

さらにはAmazonやNetflixはマイクロサービスが流行したから採用したのではありません。自社で巨大クラウドサービスを開発提供するにあたり、従来手法での限界に行き当たり、その解決策として結果的にマイクロサービスに相当する考え方が採用され、先進例となった経緯があります。確かに時代の必要性が生んだ考え方なのです。

状況次第で使い分ける選択肢

もちろん、あらゆる場合にマイクロサービスが適するわけではありません。流行の手法だからといって、自分たちのプロジェクトには適さないケースもあります。

モノリシックなアーキテクチャの方が適する場合もありますし、折衷的な考え方として、プログラミングの段階ではマイクロサービスのように部分に分割して開発を行うが、実環境で動作させる段階ではモノリシックなアプリケーションとしてリリースするような考え方（モジュラーモノリスなど）もあります。多くの場合にはモジュラーモノリスが現実的な最適解ではないかという意見も見られます。

組織構造もマイクロサービスに合わせる必要がある

マイクロサービスでの開発は、それに適した組織構造や組織文化になっていないとうまく機能しないことがあります。サービス単位で開発チームが自分たちの判断で開発を進めて、自分たちの判断で迅速にリリース作業ができる状況ではない場合にはメリットが失われることがあります。

例えば、旧態依然とした企業文化の組織でマイクロサービスを採用してもうまく機能しない可能性があります。デジタル時代の新しい潮流についてゆくためには、組織そのものの抜本的な変化が必要となることがあります。

マイクロサービスアーキテクチャを実現する技術

マイクロサービスアーキテクチャの考え方にはメリットが多くあるものの、実際にITシステムとして実現するにあたっては技術的なハードルもあります。実際のシステム開発においては、以下のような技術が実現手段として用いられています。

コンテナ（独立した小さい部分を実現する）
一般的にマイクロサービスはコンテナ技術を用いて実現されることが多く、それぞれのサービスごとの独立性は、コンテナによる実行環境の分離によって提供されることが多くなっています。マイクロサービスの言葉自体もコンテナ技術の出現と活用から生まれています。
⇒ コンテナ｜用語集
API（マイクロサービスの間の通信）
各サービスがそれぞれ独立した実行環境となっているということは、外部にある他のマイクロサービスとの間の通信は、外部アプリケーションとの連携と同様になるため、一般的にAPIなどを経由して行います。
⇒ API｜用語集
コンテナオーケストレーション（大量のコンテナの管理と運用）
マイクロサービスがコンテナを用いて実現され、多数のマイクロサービスがコンテナとして動作する状況では、旧来のような人手によるIT基盤運用が難しくなることがあります。大量のコンテナの実行状況の把握など全体の状況の把握や、コンテナの死活監視、負荷状況などに応じた起動や終了などを管理運用する手段が必要になることがあります。
⇒ コンテナオーケストレーション｜用語集
API基盤/サービスメッシュ（大量の通信の制御）
多数のマイクロサービス間で行われる通信をうまく行えるようにする基盤技術が必要になることがあります。

ビジネスサイドからのマイクロサービスの価値の考察

ここまではITシステムを「作る側の目線」での話でした。しかし同じ「疎結合」の考え方で、ITを利用する「ビジネス側」からも同様の考え方での取り組みが可能です。ビジネス的な観点で、ITシステムをモノリシックなシステムとせず、小さい部分から構成する考え方でのITの利活用に取り組むことができます。

また以下は、何をマイクロサービスとして切り出すか適切に判断できれば、そのこと自体がビジネス側にも様々なメリットがあることの説明であり、どのような観点で全体を部分に分割すればよいかの例にもなっているはずです。

SOA （Service-Oriented Architecture：サービス指向アーキテクチャ）

一昔前にSOAという考え方が注目されていたことがありました。マイクロサービスと同じようにシステムを小さい部分から構成する考え方ですが、SOAは比較してビジネス側の観点で提案されている取り組みでした。

ITシステムを柔軟性のないモノリシックな巨大システムとして構築するのではなく、業務機能単位でのITの部品である「サービス」として開発、実際の業務を担うシステムはそれらサービス（部品）を組み合わせて実現する考え方です。

いわば自社の業務の機能を部品として整備し、それを資産として必要に応じて組み合わせて業務システムとして利用する考え方です。同じく、再利用性が高まる特徴があり、迅速な開発、柔軟な変更も可能となる考え方でした。

SOAほどではなくても

巨大な業務パッケージソフトウェアではなく、業務領域ごとに（例：経理システム）自社にとってベストなアプリケーションを選んで組み合わせる考え方があります。それぞれの領域でベストなものを選んで組み合わせる考え方は「ベストオブブリード」と呼ばれます。

様々なクラウドサービスを組み合わせて活用するマルチクラウドの考え方や、長年使われてきた旧システムの良いところを残したうえで新技術の新システムを導入する考え方にも、同じように「良い部分」を選んで（各部分の良さに注目して）組み合わせる考え方です。

ビジネス側での同じ考え方を支える技術

マイクロサービスと同じように、その実現を支える技術が存在します。

各システムや各クラウドサービスへの接続機能（外部から「つなぐ」手段）
APIでの連携、所定のフォーマットのファイルでのファイル連携など、何らかの手段でそのシステムに接続する手段が必要になります。
API化する手段（外部から「つなぐ」ことができるようにする手段）
あるいは自分たちで今あるIT資産をサービス化して活用できるようにするため、API化など、リソースとして外部から呼び出せるようにする手段が必要になります。
「つなぐ」技術（多種多様なリソースを自在に組み合わせて利用できる手段）
多種多様な各システムや各クラウドサービスを柔軟かつ迅速に連携させて活用し、自社のIT資産をうまく活用して業務に必要な情報システムを作り出す手段が必要になります。業務の現場主導での利活用が実現できることが望ましく、本格的なプログラミングは不要で利用できることが望まれます。

このような状況でのデータやシステムの連携、APIの実現をうまく実現してくれる手段が既にあります。「EAI」や「ETL」、「iPaaS」などの「つなぐ」技術です。

コードを書くことなく、GUI上でアイコンを配置して各種設定をするだけで多種多様なシステムやデータの連携処理が実現できる
多種多様なITシステムやクラウドサービス、データを効率的に連携させ、あるいは必要な変換処理は連携処理を自動化し、自社のIT資産から業務に必要なITシステムを作りだすことができる。

このように、小さい部分から「疎結合」に全体を組み上げる取り組みは、本格的なIT開発ではなくても、ビジネス側の目線の小さな取り組みからでも始めることができます。そして、適切な観点でシステムを「各部分」から構成し、それらを「つなぐ」ことで利活用する取り組みがなされるなら、ITシステムの開発運用での利便のみならず、ビジネス側にとってもIT利活用の利便性を高めることにつながります。

関係するキーワード（さらに理解するために）

疎結合
- 疎結合とは、システムが構成要素の組みあわせで作られており、それぞれの構成要素同士の依存関係が高くなく、互いに独立性が高い状態のことを言います。ITシステムから組織の構造まで、様々なシステムが「どのようにあることが望ましいか」を考えるにあたって、有用な視点です
EAI
- システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
ETL
- 昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
iPaaS
- 様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのこと。
コンテナ
- コンテナとは、一つのOS実行環境内で、複数の独立したアプリケーションシステムの実行環境を作り出す技術のことです。それまで利用されてきた仮想マシンによるハードウェアレベルの仮想化に対して、OSレベルでの仮想化（OS-level virtualization）を行います。
コンテナオーケストレーション
- コンテナ技術を用いたシステム開発や運用において、多数のコンテナを管理し運用し制御する自動化技術のことです。

「iPaaS」や「つなぐ」技術に興味がありますか？

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるオンラインセミナーも開催しておりますので、ぜひ一度お試しいただけますと幸いです。

無料製品紹介セミナーはこちら

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
データ利活用に向けて進めたいがシステム連携に課題がある
DXの実現に向けてデータ連携基盤の検討をしたい

PoCプログラム | HULFT Square | セゾンテクノロジー