マイクロサービスとは

マイクロサービス（マイクロサービス・アーキテクチャー）は、単一のアプリケーションを、疎結合で独立してデプロイできる多数の小さなコンポーネントまたはサービスで構成される、クラウドネイティブのアーキテクチャー・アプローチです。

マイクロサービスには通常、次の特徴があります。

データベースとデータ管理モデルを含む独自のテクノロジー・スタックを備えている。
Representational State Transfer（REST）API、イベント・ストリーミング、メッセージ・ブローカーを組み合わせて相互に通信する。
部門ごとに編成されており、業務を区切るサービスは境界づけられたコンテキスト（Bounded Context）と呼ばれます。

マイクロサービスに関する議論の多くはアーキテクチャーの定義と特性を中心に展開されていますが、その価値は、次のようなかなり単純なビジネスおよび組織上の利点でより一般的に理解されます。

コードの更新がより簡単になり、アプリケーション全体に触れることなく新しい機能や特性を追加できます。
チームは、コンポーネントごとに、異なるスタックやプログラミング言語を使用できます。
コンポーネントは互いに独立してスケーリングできるため、単一の機能に過度の負荷がかかる可能性があるという理由でアプリケーション全体をスケーリングする必要がある場合に発生する無駄とコストが削減されます。

マイクロサービスではないもの

マイクロサービスは、モノリシック・アーキテクチャーとサービス指向アーキテクチャー（SOA）という2つの先行アプリケーション・アーキテクチャーと対比して理解することもできます。

マイクロサービスとモノリシック・アーキテクチャーの違いは、大規模で密結合されたアプリケーションのモノリシック・アプローチとは対照的に、マイクロサービスは多数の小規模で疎結合されたサービスから単一のアプリケーションを構成する点です。

一方、マイクロサービスとSOAの違いは、少しわかりにくいかもしれません。マイクロサービスとSOAの間には、特にエンタープライズ・サービス・バスの役割に関して技術的な対比が見られますが、その違いを範囲の違いとして捉えると簡単です。SOAは、組織内のすべての Web サービスが相互に通信および統合する方法を標準化するための企業全体の取り組みである一方で、マイクロサービス・アーキテクチャーはアプリケーション固有のものです。

DaaSで柔軟な職場を実現する

Desktop as a Service（DaaS）を利用して、企業がオンプレミスでアプリケーションを展開するのと同等のパフォーマンスとセキュリティーを達成できる方法をご覧ください。

関連コンテンツ

登録してアプリのモダナイゼーションに関するガイドを受け取る

マイクロサービスが組織にもたらすメリット

マイクロサービスは、少なく見積もっても、開発者や経営陣、プロジェクト・リーダーに好まれるでしょう。これはマイクロサービスの珍しい特徴の1つです。アーキテクチャーに対する関心は通常、ソフトウェア開発チームにとどまるからです。マイクロサービスが人気の理由は、これが、多くのビジネスリーダーがチームと開発プロセスを構築および実行したい方法をより適切に一致しているからです。

別の言い方をすれば、マイクロサービスは望ましい運用モデルをより容易にするアーキテクチャー・モデルです。1,200人を超える開発者とIT幹部を対象とした2021年のIBMの調査では、マイクロサービス・ユーザーの87％が、マイクロサービスの採用は費用と労力に見合う価値があると回答しています。

マイクロサービスが企業にもたらすメリットをいくつかご紹介します。

独立してデプロイ可能

おそらく、マイクロサービスの最も重要な特徴は、サービスがより小さく、独立してデプロイ可能であるため、コードを一行変更したり、アプリケーションに新しい機能を追加したりするために面倒な手続きを必要としないことです。

マイクロサービスは、小さな変更に膨大な時間がかかることに伴う本能的なフラストレーションに対する回避策を組織に提供します。スピードと俊敏性を促進するアプローチの価値を理解したり見極めたりするため、コンピューター・サイエンスに精通している必要ありません。

しかし、このようにサービスを設計するメリットは手軽さだけではありません。新しい組織モデルでは、ビジネス上の問題、サービス、または製品に関して部門横断的に取り組むことが一般的になっていますマイクロサービス・モデルは、組織が1つのサービスまたは複数のサービスに対して少人数の部門横断型チームを作成し、それらをアジャイルな方法で運用できるため、このトレンドにぴったり適合しています。

マイクロサービスは緩やかに結びついているため、アプリケーションに障害がある場合に切り離すことができ、優れたレジリエンスがあります。また、サービスの規模が小さく、境界とコミュニケーション・パターンが明確であるため、新しいチーム・メンバーが比較的簡単にコード・ベースを理解し、すぐに貢献できるようになります。これは、作業速度と従業員の士気の両面で明らかなメリットです。

業務に最適なツール

n層ある従来型アーキテクチャー・パターンでは、アプリケーションは通常、共通のスタックを共有し、大規模なリレーショナル・データベースによってアプリケーション全体がサポートされます。このアプローチには明らかな欠点がいくつかあります。特に重大な欠点は、特定の要素に対して、その作業に適したより優れたツールが明確に存在する場合でも、アプリケーションのすべてのコンポーネントが共通のスタック、データ・モデル、およびデータベースを共有する必要があることです。それは望ましくないアーキテクチャーとなるため、より良い、より効率的な方法でこれらのコンポーネントを構築することを常に意識している開発者をイライラさせるでしょう。

対照的に、マイクロサービス・モデルでは、コンポーネントは独立してデプロイされ、REST、イベント・ストリーミング、メッセージ・ブローカーの組み合わせを介して通信するため、個々のサービスのスタックをそのサービスに合わせて最適化することが可能です。テクノロジーは常に変化しており、複数の小規模なサービスで構成されたアプリケーションは、より望ましいテクノロジーが利用可能になったときに、それに合わせて進化させる方がはるかに簡単かつ低コストです。

正確なスケーリング

マイクロサービスを使用すると、個々のサービスを個別にデプロイできるだけでなく、個別にスケーリングすることもできます。結果として得られる利点は明らかです。適切に実行すれば、マイクロサービスではモノリシック・アプリケーションの場合のようにアプリケーション全体をスケーリングする代わりに、必要なコンポーネントのみを正確にスケーリングできるため、モノリシック・アプリケーションよりもインフラストラクチャーが少なくて済みます。

マイクロサービスには次のような課題もあります。

マイクロサービスの大きな利点には、大きな課題が伴います。モノリスからマイクロサービスに移行すると、管理が大幅に複雑になります。つまり、より多くのサービスが、より多くのチームによって作成され、より多くの場所にデプロイされることになります。また、あるサービスの問題が他のサービスの問題を引き起こしたり、他のサービスの問題によって引き起こされたりすることもあります。さらに、ログ・データ（監視と問題解決に使用）の量が多くなり、サービス間の一貫性が失われる可能性があります。また、新しいバージョンでは下位互換性の問題が発生する可能性があります。アプリケーションにはより多くのネットワーク接続が関係するため、遅延や接続の問題が発生する可能性も高くなります。DevOpsアプローチはこれらの問題の多くに対処できますが、DevOpsの導入にはそれ自体の課題があります。

それにもかかわらず、これらの課題は、マイクロサービスの新規採用や、採用者によるマイクロサービスへの取り組みの深掘りを妨げません。前述のIBMの調査データによると、現在マイクロサービスを使用していないユーザーの56％が今後2年以内にマイクロサービスを導入する可能性が高いか、非常に高いと考えており、現在既にマイクロサービスを使用しているユーザーの78％がマイクロサービスに投資した時間、お金、労力を今以上に増やす可能性が高いと回答しています。

マイクロサービスはDevOpsを可能にし、必要とする

マイクロサービス・アーキテクチャーは、DevOpsや継続的インテグレーションまたは継続的デリバリー向けに最適化されているとよく言われますが、頻繁にデプロイできる小規模なサービスであることを考えれば、その理由は簡単に理解できるでしょう。

しかし、マイクロサービスとDevOpsの関係を別の観点から見ると、マイクロサービス・アーキテクチャーを成功させるには実際にはDevOpsが必要であると言えます。モノリシック・アプリケーションには、この記事の前半で説明したさまざまな欠点がありますが、複数の可動部分と独立した技術スタックを持つ複雑な分散型システムではないというメリットがあります。対照的に、マイクロサービスに伴う複雑さ、可動部分、依存関係の大幅な増加を考慮すると、デプロイ、監視、ライフサイクルのオートメーションに多大な投資をせずにマイクロサービスに取り組むのは賢明ではありません。

Rosalind Radcliffeが動画でDevOpsについて詳しく説明しています。

主要な実現ツールとテクノロジー

マイクロサービス・アーキテクチャーでは、ほぼすべての最新ツールや言語を使用できますが、マイクロサービスに不可欠でかつ、マイクロサービスに含めるべきかどうかが不明確なコア・ツールがいくつかあります。

コンテナ、Docker、Kubernetes

マイクロサービスの重要な要素のひとつは、一般的にサイズがかなり小さいという点です。マイクロサービスであるかどうかを決定する任意の量のコードはありませんが、名前に「マイクロ」が含まれています。

2013年にDockerが現代のコンテナ時代の幕開けを告げたとき、マイクロサービスと最も密接に関連するコンピューティング・モデルも導入されました。個々のコンテナには独自のオペレーティング・システムにより発生する諸経費がないため、従来の仮想マシンよりも小型で軽量であり、より迅速に起動および停止できるため、マイクロサービス・アーキテクチャー内の小型で軽量なサービスに最適です。

サービスとコンテナの急増により、大規模なコンテナ・グループのオーケストレーションと管理が急速に重要な課題の 1 つになりました。オープンソースのコンテナ・オーケストレーション・プラットフォームであるKubernetesは、その役割を非常にうまく果たす、最も人気のあるオーケストレーション・ソリューションの1つとして登場しました。

APIゲートウェイ

マイクロサービスは、特に最初に状態を確立するときに、APIを介して通信することがよくあります。クライアントとサービスが直接通信できることは事実ですが、特にアプリケーション内のサービスの数が時間の経過とともに増加するにつれて、API Gatewayは便利な中間層となることがよくあります。API Gatewayは、リクエストをルーティングし、複数のサービスにリクエストを分散して追加のセキュリティと認証を提供することで、クライアントのリバース・プロキシーとして機能します。

API Gatewayの実装に使用できるテクノロジーには、API管理プラットフォームなど複数ありますが、マイクロサービス・アーキテクチャーがコンテナとKubernetesを使用して実装されている場合、ゲートウェイは通常、Ingressまたは最近ではIstioを使用して実装されます。

メッセージングとイベント・ストリーミング

ベストプラクティスとしてはステートレスなサービスを設計することが考えられますが、それでも状態は存在し、サービスはそれを認識する必要があります。API呼び出しは、特定のサービスの状態を最初に確立する効果的な方法であることが多いですが、最新の状態を維持する方法としては特に効果的ではありません。サービスを最新の状態に保つために、「もう到着したのか」と頻繁にポーリングするアプローチは、現実的ではありません。

代わりに、状態を確立するAPI呼び出しをメッセージングまたはイベント・ストリーミングと組み合わせるとよいでしょう。これにより、サービスが状態の変更をブロードキャストし、他の関係者がそれらの変更をリスニングしてそれに応じて調整できるようになります。このジョブは汎用メッセージ・ブローカーに最適ですが、Apache Kafkaなどのイベント・ストリーミング・プラットフォームが適している場合もあります。また、マイクロサービスとイベント駆動型アーキテクチャーを組み合わせることで、開発者は、大量のイベントや情報をリアルタイムで消費および処理できる、分散型で、スケーラブルかつフォールト・トレランスに優れた拡張性があるシステムを構築できます。

サーバーレス

サーバーレス・アーキテクチャーは、コアとなるクラウドとマイクロサービスのパターンの一部に論理的帰結を与えています。サーバーレスの場合、実行単位は単なる小さなサービスではなく、関数であり、多くの場合、数行のコードを実行するだけで済みます。サーバーレス関数とマイクロサービスを分ける境界線は曖昧ですが、関数はマイクロサービスよりもさらに小さいと一般的に理解されています。

サーバーレス・アーキテクチャーとFunctions as a Serviceプラットフォームのマイクロサービスとの共通点は、どちらもより小さなデプロイメント単位を作成し、需要に応じて正確にスケーリングすることに重点を置いている点です。

マイクロサービスとクラウド・サービス

マイクロサービスは必ずしもクラウド・コンピューティングにのみ関連しているわけではありませんが、これらが頻繁に一緒に使用されるのにはいくつかの重要な理由があります。その理由は、マイクロサービスが新しいアプリケーションの一般的なアーキテクチャー・スタイルであることや、クラウドが新しいアプリケーションの一般的なホスティング先であることだけではありません。

マイクロサービス・アーキテクチャーの主なメリットの1つは、コンポーネントを個別にデプロイおよびスケーリングすることに関連する使用率とコストです。こうしたメリットはオンプレミスのインフラストラクチャーにもある程度は存在しますが、小規模で独立して拡張可能なコンポーネントと、オンデマンドの従量制のインフラストラクチャーを組み合わせることで、真のコストの最適化を図ることができます。

2つ目の、そしておそらくもっと重要なメリットは、個々のコンポーネントがそれぞれの特定のジョブに最適なスタックを採用できることです。スタックの増殖は、自分で管理する場合に深刻な複雑さとコスト増につながる可能性があります。しかし、サポート・スタックをクラウド・サービスとして使用することで、管理上の課題を大幅に最小限に抑えることができます。言い換えれば、独自のマイクロサービス・インフラストラクチャーを構築することは不可能ではありませんが、まだ経験が浅いうちはお勧めできません。

共通のパターン

マイクロサービス・アーキテクチャーには、次のような共通の課題や機会に対処するのに役立つ、一般的で便利な設計、通信、統合のパターンが多数あります。

Backend-for-frontend（BFF）プラットフォーム

このパターンは、ユーザー・エクスペリエンスとそれが必要とするリソースの間にレイヤーを挿入します。例えば、デスクトップで使用されるアプリでは、画面サイズ、表示、パフォーマンスの制限がモバイル・デバイスとは異なります。BFFパターンを使用すると、開発者は、どのインターフェースでも機能するがフロントエンドのパフォーマンスに悪影響を与える可能性のある汎用バックエンドをサポートするのではなく、そのインターフェースに最適なオプションを使用して、ユーザー・インターフェースごとに 1 つのバックエンド・タイプを作成してサポートできます。

エンティティーおよび集合体のパターン

エンティティーとは、そのIDによって区別されるオブジェクトのことです。例えば、電子商取引サイトでは、製品オブジェクトは製品名、タイプ、および価格で区別される場合があります。集合体とは、1つの単位として扱うべき関連エンティティーの集まりです。つまり、eコマース・サイトの場合、注文は購入者が注文した商品（エンティティー）の集まり（集合体）になります。これらのパターンは、データを意味のある方法で分類するために使用されます。

サービス検出パターン

これらは、アプリケーションとサービスが互いを見つけるのに役立ちます。マイクロサービス・アーキテクチャーでは、スケーリング、アップグレード、サービス障害、さらにはサービスの終了により、サービス・インスタンスが動的に変更されます。これらのパターンは、この過渡性に対処するための検出メカニズムを提供します。負荷分散では、ヘルスチェックとサービス障害をトリガーとしてトラフィックの再分散を行うことで、サービス検出パターンを使用する場合があります。

アダプターのマイクロサービス・パターン

アダプターのパターンは、海外に旅行するときに使用しなければならないプラグ・アダプターの種類のようなものだと考えることができます。アダプター・パターンの目的は、他の方法では互換性のないクラスまたはオブジェクト間の関係を変換しやすくすることです。サード・パーティーのAPIに依存するアプリケーションでは、アプリケーションとAPIが通信できるようにするために、アダプター・パターンを使用しなければならなくなる場合があります。

ストラングラー・アプリケーション・パターン

これらのパターンは、モノリシック・アプリケーションのマイクロサービス・アプリケーションへのリファクタリングを管理するのに役立ちます。「絞殺魔」を意味するストラングラーという名前は、ブドウの木（マイクロサービス）がゆっくりと時間をかけて一本の木（モノリシック・アプリケーション）を飲み込んで絞め殺すことを表しています。

アンチパターン

マイクロサービスをうまく実行するためのパターンが数多くある一方で、開発チームを困難に直面する状況に陥らせるパターンも同様に数多く存在します。このような、マイクロサービスで開発チームがすべきではないことは次のとおりです。

マイクロサービスを開発しようとしない

もっと正確に言えば、マイクロサービスの開発から着手しようとしないでください。マイクロサービスは、アプリケーションが大きくなりすぎて扱いにくくなり、更新や保守が難しくなった場合に、複雑さを管理する1つの方法です。モノリスでは扱いが複雑になってきていると感じた段階でのみ、そのアプリケーションをより小さなサービスにリファクタリングする方法を検討することには価値があります。こうした困難を感じていない間は、モノリスをリファクタリングする必要性はありません。

DevOpsまたはクラウド・サービスなしでマイクロサービスを実行しない

マイクロサービスを開発するということは、分散型システムを開発するということです。分散型システムは開発するのが難しく、選択内容によっては、さらに困難となるでしょう。適切なデプロイメントと監視のオートメーション、または現在拡大途中にある、異種インフラストラクチャーをサポートするマネージド・クラウド・サービスなしでマイクロサービスを実行しようとすると、多くの不要なトラブルを招くことになります。面倒な手間を省いて、状態について心配する時間を費やす必要がないようにしましょう。

マイクロサービスを小さくしすぎて、作りすぎないように注意する

マイクロサービスにおける「マイクロ」を追求しすぎると、マイクロサービス・アーキテクチャーの全体的なメリットを上回る諸経費と複雑さが簡単に生じてしまう可能性があります。最初は大規模なサービスに集中し、マイクロサービスが解決できる特性が現れ始めたときにのみサービスを分割することをお勧めします。具体的には、変更のデプロイが困難かつ時間がかかるようになった、共通のデータ・モデルが過度に複雑になった、サービスのさまざまな部分に異なる負荷やスケール要件があるなどです。

マイクロサービスをSOAにしない

マイクロサービスとSOAは、最も基本的なレベルでは、他のアプリケーションで使用できる再利用可能な個々のコンポーネントを構築することに関心があるため、しばしば混同されます。マイクロサービスとSOAの違いは、マイクロサービス・プロジェクトでは通常、管理しやすいようにアプリケーションをリファクタリングするのに対し、SOAでは企業全体でITサービスの動作方法を変更することに重点が置かれていることです。SOAプロジェクトにシフトするマイクロサービス・プロジェクトは、その重みに耐え切れず失敗する可能性が高くなります。

Netflixを目指さない

Netflixは、インターネット・トラフィック全体の3分の1を占めるアプリケーションを構築して管理する際に、マイクロサービス・アーキテクチャーを早期に導入した先駆者の1つでした。これは、平均的なアプリケーションに不要なカスタム・コードとサービスを大量に構築する必要があり、ある種最悪の状況でした。自分が処理できるペースで始め、複雑さを避け、市販のツールをできるだけ多く活用する方がはるかに良いでしょう。

チュートリアル：マイクロサービスのスキルを構築する

マイクロサービスの使用方法についてさらに詳しく学習する場合、またはマイクロサービスのスキルを構築する必要がある場合は、次のいずれかのチュートリアルをお試しください。