マイクロサービスとは?基礎から事例までわかりやすく解説
マイクロサービスは複数の小さなサービスをAPIによって連携させるアーキテクチャのことです。
単位ごとの修正や変更が容易でスピーディな運用がメリットで、AmazonやLINE、グノシーなどの大企業が導入していることで注目が集まっています。
マイクロサービスは、大規模なシステム構築でもアジャイル開発(細かい修正を繰り返す手法)で進めることがある昨今において、システムを切り分けて管理しやすくするなどの目的で使われています。
今回はマイクロサービスの基礎知識や、メリット・デメリットを解説し、事例までご紹介いたします。
【目次】
この記事では、サービスをどのように分割しているか、メリット、デメリットなどをご紹介します。
また事例として、すでにマイクロサービスを導入している企業も掲載しています。
ソフトウェアのエンジニアであるマーチン・ファウラー氏らによって書かれた2014年の記事「Microservices」に登場して以来、一種のバズワードとして知られるようになりました。
そのためマイクロサービスは小さなソフトウェアの集合体であり、そのソフトウェアをつなげる接着剤の役割がAPIなのです。
そのメリットとデメリットはどのようなものなのでしょうか。
1プロセスで1サービスというマイクロサービスの特性は、サービス同士の依存関係が薄く、特異性、独自性を一定程度保持できます。
そのため、障害が起きても局所にとどめて影響を少なくでき、なおかつ新たな技術を取り入れたい場合、一部分の変更をしたい場合も身軽に動けます。
そもそもサービスをどのように分割するべきかという問題については、慎重に検討がなされるべきです。
自社だけでの検討が不安ということであれば、外部のコンサルタントに相談するなどして、全体の細分化および設計について熟慮することをオススメします。
2つめの運用業務については、1つのシステムを個々のサービスに分けるというマイクロサービスは、サービスごとの管理業務が必要になるということです。
統合的に管理するシステムづくりによって、新たにコストが発生する可能性もあります。
サービス同士はAPIによって最小限の連携をもつのみで、基本的にはそれぞれ独立しています。
そのため、設計にあたってはそれぞれのサービスに特化した手法をとれます。
また、障害が起きた時は1つのサービスごとに影響をチェック可能です。
しかし、マイクロサービス化は大まかに以下の手順で進めるため、業務として優先度が高いかどうかはよく検討する必要があります。
また、システムとして最適かどうかとユーザー(顧客)にとって最適かどうかが、必ずしも一致しているわけではありません。
多くのユーザーが使っているシステムほど、移行での影響は大きくなりがちなので、マイクロサービス化のさいはユーザーの利便性を第一に考える必要があります。
API(Application Programming Interface)は、プログラムとプログラムの呼出仕様のことです。
サービス同士が物理的に離れた場所にあっても、それらを連携させて大きなサービスとして運用することができるなど、実用的な特徴があります。
これは、マイクロサービスの特定のグループに対して単一のエントリポイントを提供するというサービスです。BFF(backend for frontend)と呼ばれる場合もあります。
つまり、ニーズを考えながらビルドするためにクライアントアプリとマイクロサービスの間を取り持つ役割を果たしています。
コンテナは、仮想化技術の一つで、OS上にそれぞれのアプリケーションの専用区画を作成します。
そしてプロセスごとにコンテナが用意され、プロセス間の連携をAPIでおこなっていくイメージです。
コンテナ単位での入れ替えができるので、機能変更もスピーディにできるというメリットがあります。
Dockerは、2013年にオープンソースのプロジェクトとして公開されました。
導入や運用の手軽さや豊富なプレビルドイメージの提供により、さまざまなシーンで普及しています。
クラスタのどこにコンテナを配置するかをスケジューリングしてくれる上、CPUやメモリの足りない場合もノード(再配布ポイント)を増やすだけで拡張することができます。
Dockerは、ホストの外とのやりとりや連携が煩雑になるという課題がありました。「Kubernetes」は、それを解決するためのツールといえます。
マイクロサービスのデータベースにおいて課題となるのがトランザクションで、複数のデータベースにまたがる分散トランザクションなどは、管理が困難になる問題点の1つとしてよく知られています。
全体を1つのシステム構造とするモノリシックアーキテクチャでは容易ですが、細分化された個々が連携しているマイクロサービスにおいては、共有や結合といった関係性が弱いため、こうした課題がうまれます。
もっともこの課題は、一連の処理を1つのワークフローとして再実装すると解決できます。
Laravelがベースとなっているため、Laravelにコードをコンバート可能です。
アプリケーションやAPIを描きやすいシンプルなフレームワークとして定評があります。
ネーミングはスウェーデン語で「十分な」を意味しています。
シンプルで軽いことを特徴としています。
これにともなってクックパッドはソフトウェアアーキテクチャを見直し、拡大した事業を運営しやすいかたちに転換をはかりました。
モノリシックアーキテクチャからマイクロサービスへの転換によって、独立性の高い個々のチームがスピーディに「価値」を創出し、ユーザーへ届けることによって成長を遂げています。
Amazonには開発当時「Two-pizza teams」、2枚のピザで満腹にならないような規模のチームは作るな、というルールがうまれたといわれています。
エラー発生時に全体に影響が及ばないようにすることで、ユーザーの信頼を損なわないシステム運営が可能になっています。
そのため、乗客の管理機能や経路管理機能などをクラウドでのマイクロサービスにそれぞれ切り出し、API連携によって接続する手法に転換しました。
これにより、新規開発を機能ごとに実施でき、開発スピードや品質管理、機能拡張などのスピードが向上しました。
そもそも自社のシステムをモノリシックアーキテクチャからマイクロサービスへ転換する必要があるかなどは、外部への相談も含め、慎重な検討が必要といえるでしょう。
単位ごとの修正や変更が容易でスピーディな運用がメリットで、AmazonやLINE、グノシーなどの大企業が導入していることで注目が集まっています。
マイクロサービスは、大規模なシステム構築でもアジャイル開発(細かい修正を繰り返す手法)で進めることがある昨今において、システムを切り分けて管理しやすくするなどの目的で使われています。
今回はマイクロサービスの基礎知識や、メリット・デメリットを解説し、事例までご紹介いたします。
【目次】
- マイクロサービスとは?
- マイクロサービスのメリットとデメリット
- マイクロサービスを設計するやり方は?
- モノリス(モノリシック)からマイクロサービス化する手順は?
- マイクロサービス関連知識「API」
- マイクロサービス関連知識「コンテナ」
- マイクロサービス関連知識「フレームワーク」
- マイクロサービスの事例5選
マイクロサービスとは?
マイクロサービスとは、小さなサービス単位を互いに連携させるアーキテクチャ(構造)を作る手法のことです。この記事では、サービスをどのように分割しているか、メリット、デメリットなどをご紹介します。
また事例として、すでにマイクロサービスを導入している企業も掲載しています。
マイクロサービスアーキテクチャとは
マイクロサービスアーキテクチャは、個々に開発された複数の小さな(マイクロ)サービスを連携させて管理、運営をおこなっていくソフトウェアの構造です。ソフトウェアのエンジニアであるマーチン・ファウラー氏らによって書かれた2014年の記事「Microservices」に登場して以来、一種のバズワードとして知られるようになりました。
・Microservices – James Lewis, Martin Fowler
https://martinfowler.com/articles/microservices.html
マイクロサービスとAPIの違いは?
マイクロサービスは、小さなサービス単位をHTTP経由のAPIといった軽量な通信で連携することで、従来ネックとされていた処理速度の向上を実現しています。そのためマイクロサービスは小さなソフトウェアの集合体であり、そのソフトウェアをつなげる接着剤の役割がAPIなのです。
マイクロサービスのメリットとデメリット
モノリシックアーキテクチャと大きく異なるマイクロサービス。そのメリットとデメリットはどのようなものなのでしょうか。
マイクロサービスのメリット
マイクロサービスのメリットには、- リソースを有効活用できる
- 局所化によって障害や影響の与えるリスクを抑えられる
- 新技術の採用が容易である
- 新規機能の追加、高頻度の軽微な変更が容易
- 更改が容易
1プロセスで1サービスというマイクロサービスの特性は、サービス同士の依存関係が薄く、特異性、独自性を一定程度保持できます。
そのため、障害が起きても局所にとどめて影響を少なくでき、なおかつ新たな技術を取り入れたい場合、一部分の変更をしたい場合も身軽に動けます。
マイクロサービスのデメリット
マイクロサービスのデメリットには、- サービスを的確に分割して設計するのが難しい
- 一貫性に欠けるため、運用業務の負担が増加する
そもそもサービスをどのように分割するべきかという問題については、慎重に検討がなされるべきです。
自社だけでの検討が不安ということであれば、外部のコンサルタントに相談するなどして、全体の細分化および設計について熟慮することをオススメします。
2つめの運用業務については、1つのシステムを個々のサービスに分けるというマイクロサービスは、サービスごとの管理業務が必要になるということです。
統合的に管理するシステムづくりによって、新たにコストが発生する可能性もあります。
マイクロサービスを設計するやり方は?
マイクロサービスは、1サービスを1プロセスとして稼働させる仕組みをとっています。サービス同士はAPIによって最小限の連携をもつのみで、基本的にはそれぞれ独立しています。
そのため、設計にあたってはそれぞれのサービスに特化した手法をとれます。
また、障害が起きた時は1つのサービスごとに影響をチェック可能です。
モノリス(モノリシック)からマイクロサービス化する手順は?
ここまでお読みになって「じゃあうちのソフトもマイクロサービスにできないかな…」と思うかもしれません。しかし、マイクロサービス化は大まかに以下の手順で進めるため、業務として優先度が高いかどうかはよく検討する必要があります。
- マイクロサービス化で実現したいこと(ビジョン)を掲げる
- 既存サービスから切り出すソフトウェアを洗い出す
- 外部連携サービスやサーバーなども含め、移行していく
また、システムとして最適かどうかとユーザー(顧客)にとって最適かどうかが、必ずしも一致しているわけではありません。
多くのユーザーが使っているシステムほど、移行での影響は大きくなりがちなので、マイクロサービス化のさいはユーザーの利便性を第一に考える必要があります。
マイクロサービス関連知識「API」
マイクロサービスを理解する上で知っておきたい知識に、まず「API」があります。API(Application Programming Interface)は、プログラムとプログラムの呼出仕様のことです。
REST API:クラウド上で利用できる
クラウド環境上のマイクロサービスに適したものとして知られるのが「REST API」で、そのシンプルさから多くの場面で用いられています。サービス同士が物理的に離れた場所にあっても、それらを連携させて大きなサービスとして運用することができるなど、実用的な特徴があります。
Gateway(ゲートウェイ):認証情報を保持する
APIのひとつにAPI Gatewayというものがあります。これは、マイクロサービスの特定のグループに対して単一のエントリポイントを提供するというサービスです。BFF(backend for frontend)と呼ばれる場合もあります。
つまり、ニーズを考えながらビルドするためにクライアントアプリとマイクロサービスの間を取り持つ役割を果たしています。
- 認証
- SSL終了
- キャッシュ
マイクロサービス関連知識「コンテナ」
仮想化技術の1つであり、プロセスの区画整備をするのがコンテナです。マイクロサービスの基盤技術「コンテナ」
クラウド環境で稼働するマイクロサービスの基盤的な技術として主流になりつつあるのが「コンテナ」です。コンテナは、仮想化技術の一つで、OS上にそれぞれのアプリケーションの専用区画を作成します。
そしてプロセスごとにコンテナが用意され、プロセス間の連携をAPIでおこなっていくイメージです。
コンテナ単位での入れ替えができるので、機能変更もスピーディにできるというメリットがあります。
コンテナの主流「Docker」
現在コンテナの技術で主流となっているのは、Linux由来であるDocker(ドッカー)です。Dockerは、2013年にオープンソースのプロジェクトとして公開されました。
導入や運用の手軽さや豊富なプレビルドイメージの提供により、さまざまなシーンで普及しています。
Dockerコンテナの運用ツール「Kubernetes」
Kubernetes(クバネティス)は、複数台のホストによって構成される実行環境を1台のように取り扱うことができるDockerコンテナの運用ツールの1つです。クラスタのどこにコンテナを配置するかをスケジューリングしてくれる上、CPUやメモリの足りない場合もノード(再配布ポイント)を増やすだけで拡張することができます。
Dockerは、ホストの外とのやりとりや連携が煩雑になるという課題がありました。「Kubernetes」は、それを解決するためのツールといえます。
マイクロサービス関連知識「トランザクション」
トランザクションは、システムにおける永続的なデータへの不可分処理のことです。マイクロサービスのデータベースにおいて課題となるのがトランザクションで、複数のデータベースにまたがる分散トランザクションなどは、管理が困難になる問題点の1つとしてよく知られています。
全体を1つのシステム構造とするモノリシックアーキテクチャでは容易ですが、細分化された個々が連携しているマイクロサービスにおいては、共有や結合といった関係性が弱いため、こうした課題がうまれます。
もっともこの課題は、一連の処理を1つのワークフローとして再実装すると解決できます。
マイクロサービス関連知識「フレームワーク」
マイクロサービスフレームワークは、マイクロサービスの開発に利用できるフレームワークです。アーキテクチャを支える文字通り「骨組み」、「枠組み」であり、各言語に存在します。マイクロサービスフレームワーク「Lumen」
PHPのマイクロフレームワークが「Lumen」です。Laravelがベースとなっているため、Laravelにコードをコンバート可能です。
マイクロサービスフレームワーク「Slim」
「Slim」もPHPのマイクロサービスフレームワークです。アプリケーションやAPIを描きやすいシンプルなフレームワークとして定評があります。
マイクロサービスフレームワーク「Lagom」
Javaのマイクロサービスフレームワーク「Lagom」は、「マイクロ(小さな)」という言葉にこだわらず「適切なサイズ」のサービス作成を念頭においています。ネーミングはスウェーデン語で「十分な」を意味しています。
マイクロサービスフレームワーク「Bottle」
「Bottle」は、Pythonのフレームワークです。単一ファイルモジュールとして配布されました。シンプルで軽いことを特徴としています。
マイクロサービスフレームワーク「Pyramid」
Pythonのマイクロサービスフレームワーク「Pyramid」は、「小さく、早く、堅実」がキャッチフレーズ。簡単なセットアップが可能なので、サンプルスクリプトの確認も容易です。マイクロサービスの事例5選
では、ここで企業の導入例をみてみましょう。例1. クックパッド
クックパッドは当初の「レシピ投稿・検索」から事業領域を広げ、「食を中心とした生活のインフラ」としてさまざまなサービスを提供しています。これにともなってクックパッドはソフトウェアアーキテクチャを見直し、拡大した事業を運営しやすいかたちに転換をはかりました。
モノリシックアーキテクチャからマイクロサービスへの転換によって、独立性の高い個々のチームがスピーディに「価値」を創出し、ユーザーへ届けることによって成長を遂げています。
例2. Amazon
巨大化したモノリシックアーキテクチャに限界を感じたAmazonは、早いうちからHTTPSのAPIのみで連携させるシステム作りに大きく舵を切っています。Amazonには開発当時「Two-pizza teams」、2枚のピザで満腹にならないような規模のチームは作るな、というルールがうまれたといわれています。
例3. LINE
LINEは、Twitter社が開発したオープンソース「Zipkin(分散トレーシングシステム)」を活用して、リクエスト単位でAPIのコールパスを可視化して分析。マイクロサービス導入時のリスクとして考えられる、パフォーマンスの低下に対して対策しています。例4. Netflix
AWSの先進ユーザーとしても知られる米国のストリーミング配信事業会社Netflix(ネットフリックス)は、数千のマイクロサービスから構成されたシステムを開発して、機能変更の期間を大幅に短縮することに成功しています。エラー発生時に全体に影響が及ばないようにすることで、ユーザーの信頼を損なわないシステム運営が可能になっています。
例5. Uber
Uberは初期サービスのライドシェアが急拡大する中で、新機能の開発からリリース、バグの修正などを効率的に行う必要がありましたが、既存のモノリシックアーキテクチャではシステムをアップデートするだけでも多大な労力を要しました。そのため、乗客の管理機能や経路管理機能などをクラウドでのマイクロサービスにそれぞれ切り出し、API連携によって接続する手法に転換しました。
これにより、新規開発を機能ごとに実施でき、開発スピードや品質管理、機能拡張などのスピードが向上しました。
まずはマイクロサービス化が自社にあっているかどうかの検討を!
マイクロサービスは、小回りの効いた設計によって日々スピードを増すデジタルテクノロジーに対応しています。 とはいえ、どのようにサービスを分割するかについては専門的な知識やノウハウが不可欠です。そもそも自社のシステムをモノリシックアーキテクチャからマイクロサービスへ転換する必要があるかなどは、外部への相談も含め、慎重な検討が必要といえるでしょう。