マイクロサービスとは、システムを機能ごとに分けて構築・運用する設計の考え方です。
変化の早いビジネス環境に対応するため、柔軟でスピーディな開発手法として注目されています。
マイクロサービスは一部機能だけを個別に更新・拡張できるメリットがある一方で、デメリットや注意点もいくつか存在します。
本記事では、マイクロサービスの導入前に知っておくべき事前知識をわかりやすく解説しますので、ぜひ最後までご覧ください。
マイクロサービスとは？
マイクロサービスとは、ソフトウェア開発の手法およびアーキテクチャの1つで、システムを機能・目的に合わせて小さく分割した独立プロセスの集合体として構築するものです。
ここではマイクロサービスの基本構成や特徴、類似の手法との違いを解説します。
マイクロサービスの基本構成と特徴
マイクロサービスは、小さなサービスが互いに連携して1つのシステムとして機能します。
各サービスは、REST APIやgRPCなどを使ってデータをやり取りすることで独立して動作し、ユーザーに機能を提供する仕組みです。
例えば、「ECサイトで商品を検索してカートに入れ、購入する」といった一連の操作は、マイクロサービスによって構築が可能です。
- 商品情報をため込むカタログサービス
- 商品情報を検索する検索サービス
- 商品をカートに入れるカートサービス
- 決済処理を行う決済サービス
- 決済完了を通知するメールサービス
このように、マイクロサービス・アーキテクチャでECサイトシステムを構築すると、責任範囲が明確になります。
各サービスは独立しているため、障害発生時の原因切り分けが容易なだけでなく、負荷の高いサービスだけを個別にスケールするなど柔軟な運用にもつながります。
モノリシックアーキテクチャとの違い
マイクロサービスが登場するまでは「モノリシックアーキテクチャ」が主流でした。
モノリシックとは「一枚岩の」「頑丈な」といった意味を持つ単語です。つまり、ひとつの塊として設計・実装されるシステムを指します。
モノリシックアーキテクチャは、システムが密結合してしまっているがゆえに一部の変更影響が全体に及ぶ可能性がある点や、システムが巨大化するとビルドに時間がかかりすぎてしまい、開発効率が落ちる点などに課題がありました。
マイクロサービスとの大きな違いは、各機能が単独サービスとして成立するかどうかです。
例えば、マイクロサービスで構築したECサイトを複数運用している場合、決済サービスをECサイトAとECサイトBで共有が可能です。
一方で、モノリシックアーキテクチャは決済サービスを共有できません。
なぜなら、決済サービスがシステムに密結合していて個別に切り出すのが難しいためです。
モノリシックアーキテクチャとマイクロサービスの違いを下表にまとめました。マイクロサービスの方が、より柔軟な開発・運用ができると言えます。
| 比較項目 | マイクロサービス | モノリシックアーキテクチャ |
|---|---|---|
| 構成の考え方 | 機能ごとに分けた小さなサービスを独立して構築・運用する | すべての機能を一体化した1つの大きなアプリケーション |
| 連携方法 | 各サービスがAPIなどを通じて通信しながら連携 | アプリケーション内で直接連携 |
| 独立性・柔軟性 | 各サービスが独立しており、変更・更新・開発が柔軟にできる | 全体が密接に結びついており、一部の変更が全体に影響 |
| スケーラビリティ | 必要なサービスだけ個別にスケール可能 | 全体をまとめてスケールする必要がある |
| 障害時の影響範囲 | 一部のサービスに障害が起きても他の機能に影響しにくい | 一部の不具合が全体に波及しやすく、復旧も困難 |
SOAとの違いと関係性
マイクロサービスと類似した開発手法にSOA（Service Oriented Architecture：サービス指向・アーキテクチャ）があります。
両者の違いは「サービスの構成」です。
マイクロサービスは、サービスが独立した構成となっており、それぞれのサービス内にサーバーやデータベースなどのリソースを備えています。
一方、SOAは組織内の複数のシステムを「サービス」とみなし、それらの間でサーバーなどのリソースを共有して連携します。
例えばSOAでは、人事システムの従業員データを、給与システムや勤怠システムと共有することで、組織全体の業務効率を高めることが可能です。
このとき、データの受け渡しには、ESB（Enterprise Service Bus） と呼ばれる「共通の連携基盤」が利用されます。
このようにSOAはESBを介して業務データを共有・運用するため、万が一ESBに障害が発生すると組織全体に影響が出るリスクがあります。
これに対して、マイクロサービスはサービス同士が直接APIでつながっているため、障害が発生しても部分的な影響にとどまり、システム全体への波及を抑えやすいことが特徴です。
マイクロサービスが注目される背景とビジネスへの影響
マイクロサービスは近年注目度が高まり、導入する企業も増えています。
ここではその背景やビジネスへの影響を解説します。
顧客ニーズへの対応スピードの改善が必要に
近年の急速な技術進歩によって、顧客ニーズへの即応の重要性が増し、開発サイクルの高速化が求められるようになりました。
従来の手法（モノリシックアーキテクチャ）では対応として充分でないケースもあることから、マイクロサービスが注目されているのです。
IMARC Groupの調査によれば、マイクロサービス市場は、2033年までに131億米ドル規模にまで成長すると予測されています。
2024年の市場規模は42億米ドルのため、今後も大きく成長していくと言えます。
アジャイル開発やDevOpsとの親和性が高く、運用しやすい
マイクロサービスは各サービスが独立しているため、機能を個別にアジャイル開発およびDevOpsに連携するのに向いています。
また、複数チームでの開発もしやすく、各サービス単位での開発チームの配置、同時進行が可能です。
マイクロサービスを導入することで、早いサイクルで市場にアプローチできるようになります。
マイクロサービスを支える技術
マイクロサービスの導入・開発・運用には、APIをはじめ、コンテナやサービスメッシュ、アジャイル・DevOpsなど、さまざまな技術やインフラが必要です。
それぞれの詳細を解説します。
API (Application Programming Interface)
APIは「データ連携の窓口」です。マイクロサービスではサービス同士がAPIを介して1 つの「機能」を提供します。
主流な通信方式として、シンプルな構造の「REST API」、堅牢で高速な「gRPC」、必要な項目だけ取得できる「GraphQL」などがあります。
APIを管理するうえで重要なのは認可・レート制限・監視です。
これらをおろそかにすると、運用効率が落ちてシステム全体の信頼性が低下します。
コンテナ
コンテナとは、アプリケーションの実行環境を仮想化する技術です。コンテナがあればアプリケーションに必要な各種ライブラリやOSS（Open Source Software）などの依存関係を容易に再現・構築できます。また、起動が早く動作も軽いため、本番環境だけでなく開発環境の構築も効率よく進められます。
コンテナについては、下記の記事で詳しく解説しています。ぜひあわせてご覧ください。
サービスメッシュ
サービスメッシュとは、サービス間の通信を外側から管理する仕組みのことです。
各サービスに「サイドカー」と呼ばれるプロキシを配置すると、すべての通信がサイドカー経由で行われます。
この結果、サービス自身が通信ロジックを持たずに、ネットワークトラフィックの負荷分散や、暗号化されたセキュアな通信を実現できます。
アジャイル・DevOpsなどの開発手法
マイクロサービスは開発だけでなく運用面もスコープに入れないと成功させにくいものです。
開発手法の観点で、マイクロサービスは柔軟性と迅速性を重視するアジャイル開発と親和性が高くなっています。
またDevOps（Development and Operations）は、開発と運用を密に連携させてアプリケーションを成功に導くためのメソッドです。
CI/CDで自動テスト→自動デプロイを回しやすく、運用と開発が協調するDevOpsが実践を後押しできます。
アジャイル開発・DevOpsについては、下記の記事で詳しく解説しています。ぜひあわせてご覧ください。
マイクロサービスのメリット
マイクロサービスは開発と運用で大きなメリットを得られます。
代表的なメリットは以下の3つです。
迅速な開発を可能にし、開発期間を短縮できる
マイクロサービスは機能（サービス）を小さい単位で開発できるため、開発チームが単独で開発・テスト・リリースを行えます。
レビューや検証範囲が限定されることから、開発しやすい点もポイントです。
結果的にリリースまでのサイクルが短縮され、市場ニーズのキャッチアップも容易になります。
柔軟なスケーラビリティ（拡張性）と構築自由度
運用中に負荷が高くなると、スケールしてシステムを安定稼働させなければなりませんが、マイクロサービスは個々のサービス単位で必要なだけ拡張・実装できます。
システム全体を必要以上にスケールすることなくコスト最適化を実現しやすいでしょう。
さらに、機能（サービス）ごとに最適な開発言語やフレームワークを選択できるので開発効率も高まります。
高い障害耐性とリスク軽減
マイクロサービスは高い障害耐性を持ちます。機能（サービス）が独立しているため、一部機能が止まっても他は動き続けられるからです。
異常を検知した際も、影響範囲を限定し、障害発生箇所だけを修正するなど、無停止で修正パッチを当てられます。
また、機能アップデートでのリリースにおいても、段階的リリースで問題があった場合はすぐに切り戻せます。
ここで言う段階的リリースとは、新しい機能を一部のユーザーにだけリリースし、問題がなければ全体にリリースする「カナリアリリース」や、現在稼働中の環境（ブルー）と、新しい機能を用意した環境（グリーン）を用意し、準備ができたらグリーン環境にトラフィックを切り替える「ブルーグリーン・デプロイメント」などのことです。
これにより、リリースリスクを大幅に軽減することが可能です。
マイクロサービスのデメリットと注意点
マイクロサービスは開発・管理時などにデメリットや注意点があります。
ここでは4つの注意点を解説しますので、対応策とともに把握しておきましょう。
設計・管理の複雑さと高度なスキルの必要性
マイクロサービスは機能（サービス）が増えるほど、設計や全体像の把握・管理が難しくなり、開発チームや外部システムとの連携のハードルも高まります。
設計者の高いスキルだけでなく、プロジェクトマネージャーにもさまざまな知識が求められます。
個々の機能（サービス）が小さくても、システム全体で横断的なルール（設計・監視・権限・リリース規約等）が必要です。
データ一貫性とAPI通信の課題
機能（サービス）ごとにDBが分かれていると、データの不整合が発生しやすくなります。
さらに、APIによるネットワーク通信は遅延・失敗・コストの増加を招く恐れもあるでしょう。
そのため、非同期処理やリトライなど使って「最終的にデータが一致する」設計が不可欠となります。
統合テストとデバッグの難易度
システムが大きくなると、機能（サービス）同士の依存関係が複雑化して結合テストやデバッグの難易度が上がります。
そのため、依存関係の明確化や自動テストなどを活用して工数を削減する工夫が必要です。
また、システムが大きくなることで検証環境構築や本番リリース手順も高度になっていきます。
コンテナ技術を活用して構築の自動化を図りましょう。
小規模システムへの導入には不向き
そもそも小規模なシステムの場合、機能を分割して開発するメリットと比べて、分散化によって運用負荷が増大するデメリットが上回ります。
小規模なシステムならファーストリリースではモノリシックな構成で作成し、あとからボトルネックになりやすい機能を段階的に切り出すのが現実的と言えます。
マイクロサービス導入の判断基準と成功のポイント
以下のケースでは、マイクロサービスの導入が適しています。
ケース1：大規模なシステム開発を進めるケース
大人数・複数チームでの開発の場合、モノリシックアーキテクチャではコードベースが肥大化し、変更の影響範囲が広くなります。
マイクロサービスであれば機能ごとに独立したサービス単位に分けられるため、チームごとに並行開発が可能になり、開発効率や開発スピードの向上が期待できます。
ケース2：アプリケーションが多機能、複雑なケース
多機能アプリケーションをモノリシックアーキテクチャで構築すると、一部の機能変更がシステム全体のビルドやデプロイに影響してしまいます。
そのため、マイクロサービスに分割すれば、機能単位での独立した改修・デプロイが容易になり、リリースサイクルの短縮が期待できます。
ケース3：システムの無停止時間が厳格なケース
モノリシックアーキテクチャでは一部機能の更新でもシステム全体を停止させる必要がありますが、マイクロサービスではサービス単位でデプロイできるため、全体を止めずに部分的な更新や障害対応が可能です。
さらに、サービスごとにスケールアウトや冗長性を担保しつつ、可用性も確保できます。
マイクロサービスの導入前には、管理業務の負荷や技術的な制約の有無など含めて、上記のポイントを確認しながら必要性を慎重に検討しましょう。
また、導入の目的を明確にしておくことも重要です。
例えば、「今後はアジャイル的に開発を進めたいのか」「開発リソースを機能単位で独立して運用したいのか」「CI/CDの開発基盤を整えられるのか」などの目的が挙げられます。
あわせて自社のサービスの特性や開発リソース、さらには運用するだけのスキル・知識があるのかという点もマイクロサービス検討時に確認しておきましょう。
マイクロサービス導入の向き・不向きや、運用に失敗しないためのポイントについては下記の記事もあわせてご覧ください。
まとめ
マイクロサービスは、各機能をサービスに分割して組み合わせることで1つのシステムとして動作します。機能を分割することで、開発・運用面が効率化できるというメリットがあるだけでなく、市場のニーズを素早くキャッチアップできるのが特徴です。
開発・運用を効率化したい、ビジネススピードを上げたいとお考えの方は、ぜひマイクロサービスの導入をご検討ください。
マイクロサービスを本格的に活用するには？
マイクロサービスを本格的に活用するには、クラウドサービスプロバイダーとの組み合わせが有効です。
各種フレームワークやマネージドインフラを利用することで、開発者は環境構築や運用から解放され、アプリケーションの開発・改良に専念できます。
TD SYNNEXでは、マイクロサービスの導入に役立つ3大クラウドサービスの、導入から運用までの包括的な支援が可能です。
AWS（Amazon Web Services）
Amazonが提供するクラウドサービスです。
サーバーやストレージなどのインフラストラクチャーをはじめ、機械学習やAIなどの最新のテクノロジーを活用できます。
Microsoft Azure
Microsoftのパブリック クラウド プラットフォームです。
サーバーやネットワーク環境などの「IaaS（Infrastructure as a Service）」と、アプリケーションの開発環境「PaaS（Platform as a Service）」が提供されています。
Google Cloud
ストレージやビッグデータ解析などが提供される、Googleのクラウドサービスです。
Google製品との相性が良く、AIにも強みがあります。
導入を検討する際は、開発予定のサービスの要件や、既存システムとの親和性などを踏まえて、最適なクラウドサービスプロバイダーを選択することが重要です。
TD SYNNEXではお客様のご状況に沿った導入支援をさせていただきますので、ぜひお気軽にお問い合わせください。
［筆者プロフィール］
Y.Kuroda
MLエンジニア＆Web開発者＆ITライター。MLエンジニアとして働きながらとSEOの知見を活かした記事を執筆しています。ライター業務を効率化するWebサービス『MOJI-KA』を開発・運用中です。
