マイクロサービス（またはマイクロサービス・アーキテクチャー）は、クラウドネイティブのアーキテクチャー・アプローチであり、単一のアプリケーションが、疎結合かつ独立してデプロイ可能な多数の小さなコンポーネントまたはサービスで構成されています。 このサービスには通常、次のような特徴があります。
- データベースとデータ管理モデルを包含する独自のテクノロジー・スタックを持つ。
- REST API、イベント・ストリーミング、メッセージ・ブローカーを組み合わせて相互に通信する。
- ビジネス・ケイパビリティー別に編成されている、各サービスを区切る線は一般的に境界コンテキストと呼ばれる。
マイクロサービスに関する多くの議論は、アーキテクチャーの定義や特性を中心としていますが、その価値は、次に挙げる比較的単純なビジネスや組織のメリットから、より一般的に理解されています。
- コードの更新が簡単－アプリケーション全体に触れることなく、新たな特徴または機能を追加できる
- チームは、さまざまなコンポーネントに異なるスタックやプログラミング言語を使用できる。
- 各コンポーネントは互いに独立してスケーリングできる。1つのフィーチャーが過負荷に直面する場合に、アプリケーション全体を拡大しなければならなくなる無駄とコストが削減される。
マイクロサービス以外のアーキテクチャーとの違い
マイクロサービスは、2つの先行するアプリケーション・アーキテクチャー、モノリシック・アーキテクチャーとサービス指向アーキテクチャー（SOA）との比較によって理解される場合もあります。
マイクロサービスとモノリシック・アーキテクチャーの違いは、マイクロサービスが疎結合された多数の小さなサービスで構成される1つのアプリケーションであり、モノリシック・アプローチは対照的に、密結合の大規模なアプリケーションである点です。
マイクロサービスとSOAの違いは、これほど明確ではありません。 マイクロサービスとSOAの間では、特にエンタープライズ・サービス・バス（ESB）の役割を中心とした、テクニカルな対比が可能ですが、両者の違いは対象範囲にあると考える方が簡単です。 SOAは、組織 内のすべてのWebサービスが相互に対話し、統合する方法を標準化するための全社的な取り組みである一方で、マイクロサービス・アーキテクチャーはアプリケーション固有のものなのです。
「SOAとマイクロサービス：その相違点とは？」（英語）でさらに詳しく説明しています。
マイクロサービスとモノリシック・アーキテクチャーの違いについての詳細は、こちらの動画をご覧ください。
マイクロサービスは、少なくとも開発者と同じくらいに、経営幹部やプロジェクト・リーダーの間で人気がありそうです。 ソフトウェア開発チームの人しかアーキテクチャーへの熱意を持っていないことが多いので、この人気はマイクロサービスの特異な特徴の1つです。 その理由は、多くのビジネス・リーダーがチームを編成して稼働させ、開発プロセスを構築して実行したいと考えている方法を、マイクロサービスがよく反映しているためです。
言い換えれば、マイクロサービスは、望ましい運用モデルをより適切に促進するためのアーキテクチャー・モデルなのです。 1,200人以上の開発者とITエグゼクティブを対象とした最近のIBMの調査では、マイクロサービス・ユーザーの87%が、マイクロサービスの採用は費用と労力に値するということに同意しています。
ここでは、マイクロサービスによる企業へのメリットの一部を紹介します。
独立してデプロイ可能
おそらく、マイクロサービスの最も重要な特徴は、サービスが小さく、独立してデプロイできるため、1行のコード変更やアプリケーションへの新機能の追加のために、大げさな手続きが必要ないことです。
マイクロサービスは、組織での、小さな変更に膨大な時間がかかるという深いフラストレーションを解消します。 スピードと俊敏性を向上させるアプローチの価値は、コンピューター・サイエンスの博士号がなくても理解できます。
しかし、この方法でサービスを設計する価値はスピード以外にもあります。 一般的な新興組織のモデルは、ビジネス上の問題、サービス、製品を中心とした機能横断的チームをまとめるというものです。 マイクロサービス・モデルは、この傾向にうまく適合します。組織が1つのサービス、またはサービスの集合を中心に小規模な機能横断的チームを編成し、アジャイルな方法で運用することができるためです。
また、疎結合されたマイクロサービスは、アプリケーション内である程度障害を分離し、レジリエンシーを向上させます。 小規模なサービスを明確な境界や通信パターンと組み合わせることで、新しいチーム・メンバーがコード・ベースを理解しやすくなり、迅速にチームに貢献することが容易になります。これは、スピードと従業員の士気という両面で明確なメリットです。
ジョブに対する適切なツール
従来型のn層アーキテクチャー・パターンでは、アプリケーションは通常、アプリケーション全体をサポートする大規模な リレーショナル・データベース を備えた共通スタックを共有します。 このアプローチにはいくつかの明らかな欠点があります。最も顕著なのは、特定のエレメントのジョブに対してより良い確実なツールが存在する場合でも、アプリケーションのすべてのコンポーネントが、共通スタック、データ・モデル、データベースを共有する必要があるという点です。 これは、不適切なアーキテクチャーの原因となり、これらのコンポーネントをより適切かつ効率的に構築する方法が存在することを常に認識している開発者にとっては不満の元となります。
一方、マイクロサービス・モデルでは、コンポーネントは独立してデプロイされ、REST、イベント・ストリーミングおよびメッセージ・ブローカーを組み合わせて通信が行われます。このため、個々のサービスのスタックすべてを、そのサービス向けに最適化することが可能です。 テクノロジーは常に変化しているため、複数の小規模なサービスで構成されているアプリケーションは、さらに望ましいテクノロジーが使用できるようになったときに、より簡単に低コストで進化させることができます。
正確なスケーリング
マイクロサービスでは、個々のサービスは個別にデプロイできるだけでなく、個別にスケーリングすることもできます。 得られるメリットは明らかです。適切に実行されれば、マイクロサービスにはモノリシック・アプリケーションと比較して、必要なインフラストラクチャーが少なくてすみます。モノリシック・アプリケーションではアプリケーション全体をスケーリングする必要があるのに対し、マイクロサービスは、スケーリングを必要とするコンポーネントのみを正確にスケーリングできるためです。
マイクロサービスの課題
マイクロサービスの大きなメリットには大きな課題が伴います。 モノリシックからマイクロサービスに移行することで、管理がはるかに複雑になります。移行前よりも多くの場所に、多くのチームによって、多くのサービスがデプロイされるためです。 1つのサービスの問題は、他のサービスにおける問題の原因となる可能性があります。 ロギング・データ（モニターと問題解決に使用される）は、膨大な量となり、サービス間で不整合が発生する可能性があります。 新しいバージョンが後方互換性の問題を引き起こす可能性があります。 アプリケーションには、より多くのネットワーク接続が含まれるため、レイテンシーと接続性の問題が発生しやすくなります。 DevOpsアプローチ（下記参照）は、これらの問題の多くに対処できますが、DevOpsの採用には独自の課題があります。
それでも、これらの課題は、マイクロサービスをまだ導入していない人がこのサービスを新たに導入すること、または既に導入している人がマイクロサービスの利用を深めることを妨げるものではありません。 最近の IBMの調査データ によると、現在の非ユーザーの56％が今後2年以内にマイクロサービスを採用する可能性が高いか、非常に高いと答えており、現在のマイクロサービス・ユーザーの78％が、マイクロサービスに投資している時間、費用、労力を増やす可能性があると答えています。
マイクロサービス・アーキテクチャーは、DevOps向けに、また継続的統合と継続的デリバリー（CI/CD）のために最適化される、とよく説明されます。また、頻繁に導入される小規模なサービスのコンテキストでは、その理由が簡単に理解できます。
しかし、マイクロサービスとDevOpsとの関係の別の見方としては、マイクロサービス・アーキテクチャーが成功するには、実際にはDevOpsが必要 であるということがあります。 モノリシック・アプリケーションには、この記事で既に説明されているさまざまな欠点がありますが、複数の可動パーツと独立した技術スタックを持つ複雑な分散システムではないというメリットがあります。 一方、マイクロサービスに伴う複雑さ、可動部分や依存性が大幅に増大することを考慮すると、デプロイメント、監視、ライフサイクルの自動化に大きな投資を行うことなく、マイクロサービスにアプローチするのは賢明ではありません。
Andrea Crawfordが、以下の動画でDevOpsについて詳しく説明しています。
マイクロサービス・アーキテクチャーでは、最新ツールや言語がほぼ使用できますが、マイクロサービスにとって不可欠で境界線の定義となっているコア・ツールが次のようにいくつか存在します。
コンテナ、Docker、Kubernetes
マイクロサービスの重要な要素の1つは、一般的にかなり小さいことです。 （マイクロサービスであるかどうかを決定する任意の量のコードはありませんが、「極小」を意味する「マイクロ」という言葉が名称の中に含まれています。）
Docker が2013年に新しいコンテナ時代を先導したとき、マイクロサービスに最も密接に関連することになるコンピュート・モデルももたらしました。 個々の コンテナ には、独自のオペレーティング・システムのオーバーヘッドがないため、従来の 仮想マシン より小さく軽量であり、より迅速にスピンアップとスピンダウンをすることができます。そのため、これらのコンテナは、マイクロサービス・アーキテクチャー内のより小規模で軽量のサービスに完全に適合します。
サービスやコンテナの急増に伴い、大規模なコンテナ群を統合して管理することは、すぐに重要な課題の1つとなりました。 Kubernetesは、オープン・ソースの コンテナ・オーケストレーション（英語） ・プラットフォームです。これは、最も評判の良いオーケストレーション・ソリューションの1つとして登場しました。そのジョブを非常にうまく実行するためです。
APIゲートウェイ
マイクロサービスは、特に最初に状態を確立するときにAPI経由で通信します。 クライアントとサービスが相互に直接通信できることは事実ですが、APIゲートウェイは、特にアプリケーション内のサービス数が経時的に増加する際に便利な中間レイヤーとなることが多くあります。 APIゲートウェイは、クライアントのリバース・プロキシーとして機能します。そのために、要求をルーティングし、複数のサービスにわたって要求を展開し、追加のセキュリティーと認証を提供します。
API管理プラットフォームなど、APIゲートウェイを実装するために使用できる複数のテクノロジーがありますが、コンテナとKubernetesを使用してマイクロサービス・アーキテクチャーが実装されている場合は、ゲートウェイは通常、Ingress、また最近では、 Istioを使って実装されています。
メッセージングとイベント・ストリーミング
ベスト・プラクティスはステートレス・サービスを設計することですが、それでもステートは存在するため、サービスがステートを認識する必要があります。 API呼び出しは、多くの場合、ある特定のサービスの状態を最初に確立するための有効な手段ですが、最新の状態を維持するために特に効果的な方法というわけではありません。 「状態に変更はないか？」という絶え間ないポーリングによる アプローチでサービスを最新の状態に保つのは、まったく実用的ではありません。
その代わりに、サービスがステートの変化をブロードキャストし、他の関係者がそれらの変化を聴取して、それに応じて調整できるように、状態を確立するAPI呼び出しをメッセージングまたはイベント・ストリーミングと組み合わせる必要があります。 このジョブは汎用メッセージ・ブローカーに最適である可能性がありますが、 Apache Kafkaなどのイベント・ストリーミング・プラットフォームが適している場合もあります。 また、マイクロサービスを イベント駆動型アーキテクチャー と組み合わせることにより、 開発者は、非常に大量のイベントや情報をリアルタイムで取り込み、処理できる、分散型で拡張性が高く、フォールト・トレラントで拡張可能なシステムを構築できます。
サーバーレス
サーバーレス （英語）・アーキテクチャーは、コア・クラウドとマイクロサービスのパターンの一部を論理的な結論に導きます。 サーバーレスの場合、実行単位は単なる小さなサービスではなく関数ですが、これは数行のコードに過ぎません。 マイクロサービスとサーバーレスの関数との境界線は明確ではありませんが、関数は一般的に、マイクロサービスよりも小さいと理解されています。
サーバーレス・アーキテクチャーと Functions-as-a-Service（FaaS） プラットフォームがマイクロサービスと類似性を共有するのは、どちらも、より小さなデプロイメント単位を作成して、需要に応じて正確にスケーリングすることに関わっている点です。
マイクロサービスは必ずしもクラウド・コンピューティングのみに関連しているわけではありませんが、これらが頻繁に一緒になる重要な理由がいくつかあります。マイクロサービスが新しいアプリケーションのための一般的なアーキテクチャー・スタイルであり、クラウドが新しいアプリケーションのために人気のあるホスティング先になっている、ということにとどまらない理由です。
マイクロサービス・アーキテクチャーの主なメリットに、コンポーネントを個別にデプロイしスケーリングする際の使用率とコストのメリットがあります。 このメリットは、オンプレミス・インフラストラクチャーにもある程度存在しますが、個別に拡張可能な小さいコンポーネントをオンデマンドの従量課金制インフラストラクチャーと組み合わせることにより、真のコスト最適化が実現します。
マイクロサービスのさらに重要なもう1つの主なメリットとして、個々のコンポーネントが、その特定のジョブに最も適したスタックを採用できることが挙げられます。 スタックの急増は、自分で管理すると、相当の複雑さとオーバーヘッドを招く可能性がありますが、サポート・スタックをクラウド・サービスとして消費することで、管理に関する課題が激減します。 すなわち、独自のマイクロサービスのインフラストラクチャーを作成することは不可能ではありませんが、特に始めたばかりの場合はお勧めできません。
マイクロサービス・アーキテクチャー内には、以下のような、一般的な課題と機会の一部の解決に役立つ、一般的で有用な数多くの設計、コミュニケーション、統合のパターンがあります。
フロントエンド用バックエンド（BFF）のパターン。 このパターンは、ユーザー体験と体験が要求するリソースとの間にレイヤーを挿入します。 例えば、デスクトップ上で使用されるアプリケーションには、モバイル・デバイスとは異なる画面サイズ、表示画面、パフォーマンスの制限があります。 BFFパターンを使用すると、開発者は、任意のインターフェースで動作するが、フロントエンドのパフォーマンスに悪影響を与える可能性のある汎用バックエンドをサポートするのではなく、そのインターフェースに最適なオプションを利用して、ユーザー・インターフェースごとに1つのバックエンド・タイプを作成してサポートすることができます。
エンティティーと集約のパターン。 エンティティーは、その識別子によって識別されるオブジェクトです。 例えば、e-コマース・サイトでは、製品オブジェクトは、製品名、製品タイプ、価格によって識別される場合があります。 集約とは、1つの単位として扱う必要がある関連したエンティティーの集合です。 このため、e-コマース・サイトの場合、オーダーは、購入者によって注文された商品（エンティティー）のコレクション（集合）です。 これらのパターンは、データを意味のある方法で分類するのに使用されます。
サービス検出パターン。 アプリケーションとサービスが互いを検出するのに役立ちます。 マイクロサービス・アーキテクチャーでは、サービス・インスタンスは、スケーリング、アップグレード、サービス障害によって、またサービス終了によっても動的に変化します。 これらのパターンは、この推移に対応する検出メカニズムを提供します。 ロード・バランシング（英語）は、正常性チェックやサービス障害をトリガーとして、サービス検出パターンを使用し、トラフィックのリバランスを実行できます。
アダプター・マイクロサービスのパターン。 アダプター・パターンは、国外に出張するときに使用するプラグ・アダプターと同じように考えます。 アダプター・パターンの目的は、他の方法では互換性のないクラス間またはオブジェクト間の関係変換を支援することです。 サード・パーティーのAPIに依存するアプリケーションは、アダプター・パターンを使用して、アプリケーションとAPIが通信できるようにする必要がある場合があります。
Stranglerアプリケーション・パターン。 モノリシック・アプリケーションをマイクロサービス・アプリケーションにリファクタリングするのに役立ちます。 この特徴的な名前は、つる植物（マイクロサービス）が、ゆっくりと長い時間をかけて、巻き付いた木（モノリシック・アプリケーション）を圧倒して抑えつける様子を表しています。
これらのパターンについての詳細は、「マイクロサービスを使用した開発パターンの使用方法（パート4）」（英語）でご覧いただけます。またIBM Developerでもその他のマイクロサービスのコード・パターンの詳細（英語）について多くの情報を提供しています。
マイクロサービスをうまく実行するためのパターンは数多くありますが、開発チームでの問題が発生しやすい可能性のあるパターンも同程度に存在します。 言い換えるとマイクロサービスで「してはいけないこと」の一部は、次のとおりです。
マイクロサービスの最初のルール：マイクロサービスを構築してはいけない。 より正確に述べるならば、開始時からマイクロサービスを使用してはいけない、ということです。 マイクロサービスは、アプリケーションが大きくなりすぎて、更新と保守が容易にできなくなった場合に、複雑さを管理するための方法の1つです。 忍び寄るモノリシック・アプリケーションの複雑さに煩わしさを感じ始めた時だけ、そのアプリケーションをより小さなサービスにリファクタリングする方法を検討することに価値があります。 その煩わしさがないのであれば、リファクタリングを必要とするモノリシック・アプリケーションなどないことになります。
DevOpsやクラウド・サービスを使用せずマイクロサービスを実行しない。 マイクロサービスの構築とは、分散システムの構築を意味します。分散システムの構築は難しいものです（特に、一層難しくなるような選択をすると、構築は困難を極めます）。 次の事柄を欠いてマイクロサービスを実行しようとすると、不必要なトラブルを招きます。a）適切なデプロイメントとモニタリングの自動化。 b）現在拡大している異種インフラストラクチャーをサポートするためのマネージド・クラウド・サービス。 問題は排除して、状態に注意する時間が取れるようにしてください。
マイクロサービスを小さくし過ぎることで数多く作り過ぎない。 マイクロサービスの小型化を追及しすぎると、マイクロサービス・アーキテクチャーの全体的なメリットを上回るオーバーヘッドと複雑さにたやすく陥ってしまうことがあります。 比較的大きなサービスを作り、そのサービスにマイクロサービスが解決できる特性が表れ始めた場合にのみ分解することをお勧めします。特性とは、変更をデプロイするのが難しくスピードが落ちた、共通データ・モデルが過剰に複雑になりつつある、サービスの部分ごとに異なる負荷やスケール要件がある、などです。
マイクロサービスをSOAに変換しない。 マイクロサービスとサービス指向アーキテクチャー（SOA）は同一のものとして扱われることが多くあります。どちらも、最も基本的なレベルでは、他のアプリケーションが消費できる再使用可能な個別コンポーネントの構築に関わっているためです。 マイクロサービスとSOAの違いは、マイクロサービス・プロジェクトでは通常、管理を容易にするためにアプリケーションのリファクタリングを行うのに対し、SOAは全社的にITサービスが機能する方法を変える、という点にあります。 SOAプロジェクトに形を変えるマイクロサービス・プロジェクトは、それ自体の重みに耐えられない可能性があります。
Netflixを目指してはいけない。 Netflixは、すべてのインターネット・トラフィックの3分の1を占めるアプリケーションを構築・管理する際の、マイクロサービス・アーキテクチャーの初期パイオニアの1つでした。そのときの状況は、平均的なアプリケーションでは不要なカスタム・コードやサービスを多数作成する必要があるという困難を極めるものでした。 複雑さを回避し、できるだけ多くの既製のツールを使用して、処理できるペースから始める方がはるかにうまくいきます。
マイクロサービスの使用方法の詳細を見たい場合、またはマイクロサービス・スキルを習得する必要がある場合は、以下のチュートリアルのいずれかをお試しください。
可用性の高いフル・マネージドのKubernetesクラスターを、お客様のコンテナ化されたアプリケーションに、ワンクリックで導入できます。
コンテナ化されたアプリケーションをあらゆるベンダーのオンプレミス、エッジコンピューティング、パブリッククラウドの環境すべてにわたって一貫してデプロイ、管理します。
コンテナ・イメージ、バッチ・ジョブ、またソースコードをサーバーレス・ワークロードとして実行します。サイジング、デプロイ、ネットワーキング、スケーリングは不要です。