マイクロサービス

menu icon

マイクロサービス

マイクロサービス・アーキテクチャーのアプローチでは、独立して導入可能な、疎結合された多数の小さなサービスで1つのアプリケーションが構成されています。

マイクロサービスとは

マイクロサービス(またはマイクロサービス・アーキテクチャー)は、クラウドネイティブ・アーキテクチャー・アプローチであり、独立して導入可能な、疎結合された多数の小さなコンポーネントまたはサービスで1つのアプリケーションが構成されています。 このサービスには通常、次のような特徴があります。

  • データベースとデータ管理モデルを包含する独自のテクノロジー・スタックを持つ。
  • REST API、イベント・ストリーミング、メッセージ・ブローカーを組み合わせて相互に通信する。
  • ビジネス・ケイパビリティー別に編成されている。各サービスを区切る線は一般的に境界コンテキストと呼ばれる。

マイクロサービスに関する多くの議論は、アーキテクチャーの定義や特性を中心としていますが、その価値は、次に挙げる比較的単純なビジネスや組織のメリットから、より一般的に理解されています。

  • コードの更新が簡単 - アプリケーション全体に触れることなく、新機能を追加できる。
  • チームは、さまざまなコンポーネントに異なるスタックやプログラミング言語を使用できる。
  • 各コンポーネントは互いに独立してスケーリングできる。単一のフィーチャーが過負荷に直面しているという理由でアプリケーション全体を拡大する必要があった際の無駄とコストが削減される。

マイクロサービスは、それが「何ではないか」によって理解される場合もあります。 マイクロサービス・アーキテクチャーに関して最も頻繁に比較されるのは、モノリシック・アーキテクチャーとサービス指向アーキテクチャー(SOA)の2つです。

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

マイクロサービスとモノリシック・アーキテクチャーの違いについての詳細は、こちらの動画をご覧ください(6:37)。

 

マイクロサービスとSOAの違いは、あまり明確ではありません。 特にエンタープライズ・サービス・バス(ESB)の役割について、マイクロサービスとSOAの間でテクニカルな対比は可能ですが、その違いはスコープの1つとみなす方が簡単です。 SOAは、組織内ですべてのWebサービスが相互に通信するあるいは統合する方法を標準化するための企業規模の取り組みでした。一方、マイクロサービス・アーキテクチャーはアプリケーション固有のものです。

SOAとマイクロサービス:その相違点とは?」の投稿で詳細が説明されています。

マイクロサービスが組織に与えるメリット

マイクロサービスは、少なくとも開発者と同じくらいに、経営幹部やプロジェクト・リーダーの間で人気がありそうです。 ソフトウェア開発チームの人しかアーキテクチャーへの熱意を持っていないことが多いので、この人気はマイクロサービスの特異な特徴の1つです。 その理由は、多くのビジネス・リーダーがチームを編成して稼働させ、開発プロセスを構築して実行したいと考えている方法を、マイクロサービスがよく反映しているためです。

言い換えれば、マイクロサービスは、必要な運用モデルをより適切に促進するアーキテクチャー・モデルなのです。 1,200人以上の開発者とITエグゼクティブを対象とした最近のIBMの調査では、マイクロサービス・ユーザーの87%が、マイクロサービスの採用は費用と労力に値するということに同意しています。 以下の対話式ツールを使用すると、マイクロサービスのメリットと課題について、より多くの視点を探ることができます。

(出典: 「企業におけるマイクロサービス2021:挑戦する価値のある真のメリット実現」

ここでは、マイクロサービスによる企業へのメリットの一部を紹介します。

独立してデプロイ可能

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

マイクロサービスは、組織での、小さな変更に膨大な時間がかかるという深いフラストレーションを解消します。 スピードと俊敏性を向上させるアプローチの価値は、コンピューター・サイエンスの博士号がなくても理解できます。

しかし、この方法でサービスを設計する価値はスピード以外にもあります。 一般的な新興組織のモデルは、ビジネス上の問題、サービス、製品を中心とした機能横断的チームをまとめるというものです。 マイクロサービス・モデルは、この傾向にうまく適合します。組織が1つのサービス、またはサービスの集合を中心に小規模な機能横断的チームを編成し、アジャイルな方法で運用することができるためです。

また、疎結合されたマイクロサービスは、アプリケーション内である程度障害を分離し、レジリエンシーを向上させます。 小規模のサービスを明確な境界や通信パターンと組み合わせることで、新しいチーム・メンバーがコード・ベースを理解しやすくなり、迅速にチームに貢献できるようになります。これは、スピードと従業員の士気の両方において明確なメリットと言えます。

ジョブに対する適切なツール

従来型のn層アーキテクチャー・パターンでは、アプリケーションは通常、アプリケーション全体をサポートする大規模なリレーショナル・データベースを備えた共通スタックを共有します。 このアプローチにはいくつかの明らかな欠点があります。最も顕著なのは、特定のエレメントのジョブに対してより良い確実なツールが存在する場合でも、アプリケーションのすべてのコンポーネントが、共通スタック、データ・モデル、データベースを共有する必要があるという点です。 これは、不適切なアーキテクチャーにつながります。また、このようなコンポーネントをより適切かつ効率的に構築する方法が存在することを常に認識している開発者には不満の元となります。

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

正確なスケーリング

マイクロサービスでは、個々のサービスは個別にデプロイできるだけでなく、個別にスケーリングすることもできます。 得られるメリットは明らかです。 適切に実行されれば、マイクロサービスにはモノリシック・アプリケーションと比較して、必要なインフラストラクチャーが少なくてすみます。モノリシック・アプリケーションではアプリケーション全体をスケーリングする必要があるのに対し、マイクロサービスでは、スケーリングを必要とするコンポーネントのみを正確にスケーリングできるためです。

マイクロサービスの課題

マイクロサービスの大きなメリットには大きな課題が伴います。 モノリシックからマイクロサービスへ移行することで、管理の複雑さが増大します。 移行前より多くの場所に、多くのチームによって、多くのサービスがデプロイされるためです。 1つのサービスの問題は、他のサービスにおける問題の原因となる可能性があります。 ロギング・データ(モニターと問題解決に使用される)は、膨大な量となり、サービス間で不整合が発生する可能性があります。 新しいバージョンが後方互換性の問題を引き起こす可能性があります。 アプリケーションには、より多くのネットワーク接続が含まれるため、レイテンシーと接続性の問題が発生しやすくなります。 DevOpsアプローチ(下記参照)は、これらの問題の多くに対処できますが、DevOpsの採用には独自の課題があります。

それでも、こういった課題が、マイクロサービスを新規に採用するユーザーを妨げることはありません。 また、すでにマイクロサービスを採用しているユーザーによる一層の利用を妨げることもありません。新しいIBMの調査データは、現在の非ユーザーの56%が今後2年以内にマイクロサービスを採用する可能性がある、または採用する可能性が高いことを示しています。また、現在のマイクロサービス・ユーザーの78%が、マイクロサービスに投資した時間、お金、労力を増やす可能性が高いことを示しています(図 1 参照)。

56パーセント、78パーセント、59パーセントを示す3つの円グラフ

図 1:定着するマイクロサービス。今後2年以内に、非ユーザーの56%がマイクロサービスを採用する可能性があり、ユーザーの78%がマイクロサービスへの投資を増やし、59%のアプリケーションがマイクロサービスを使用して作成されます。(出典: 「企業におけるマイクロサービス2021:挑戦する価値のある真のメリット実現」

DevOpsを実現し、必要とするマイクロサービス

マイクロサービス・アーキテクチャーは、DevOps向けに、また継続的統合と継続的デリバリー(CI/CD)のために最適化される、とよく説明されます。また、頻繁に導入される小規模なサービスのコンテキストでは、その理由が簡単に理解できます。

しかし、マイクロサービスとDevOpsとの関係の別の見方としては、マイクロサービスのアーキテクチャーが成功するには、実際にはDevOpsを必要とする、というものです。 モノリシック・アプリケーションには、この記事で既に説明されているさまざまな欠点がありますが、複数の可動パーツと独立した技術スタックを持つ複雑な分散システムではないというメリットがあります。 一方、マイクロサービスに伴う複雑さ、可動部分や依存性が大幅に増大することを考慮すると、導入、監視、ライフサイクルの自動化に大きな投資を行うことなく、マイクロサービスにアプローチするのは賢明ではありません。

Andrea Crawfordが、以下の動画でDevOpsについて詳細に説明しています。

主要なイネーブリング・テクノロジーとツール

マイクロサービス・アーキテクチャーでは、最新のツールや言語がほぼ使用できますが、マイクロサービスにとって不可欠で境界線の定義となっているコア・ツールが次のようにいくつか存在します。

コンテナ、Docker、Kubernetes

マイクロサービスの重要な要素の1つは、一般的には非常に小さいということです。(マイクロサービスであるかどうかを決めるコード量はありませんが、名前には極小を意味する「マイクロ」が含まれています。)

Dockerが2013年に新しいコンテナ時代を先導したとき、マイクロサービスに最も密接に関連することになるコンピュート・モデルももたらしました。 個々のコンテナには、独自のオペレーティング・システムのオーバーヘッドがないため、従来の仮想マシンより小さく軽量であり、より迅速にスピンアップとスピンダウンをすることができます。そのため、これらのコンテナは、マイクロサービス・アーキテクチャー内のより小規模で軽量のサービスに完全に適合します。

サービスやコンテナの急増に伴い、大規模なコンテナ群を統合して管理することは、すぐに重要な課題の1つとなりました。 Kubernetesは、オープン・ソースのコンテナ・オーケストレーションプラットフォームです。これは、最も評判の良いオーケストレーション・ソリューションの1つとして登場しました。そのジョブを非常にうまく実行するためです。

「Kubernetesの説明」の動画で、Sai VennamがKubernetesのすべてについて総合的な見解を伝えています。

 

APIゲートウェイ

マイクロサービスは、特に最初に状態を確立するときにAPI経由で通信します。 クライアントとサービスが相互に直接通信できることは事実ですが、APIゲートウェイは、特にアプリケーション内のサービス数が経時的に増加する際に便利な中間レイヤーとなることが多くあります。 APIゲートウェイは、クライアントのリバース・プロキシーとして機能します。そのために、要求をルーティングし、複数のサービスにわたって要求を展開し、追加のセキュリティーと認証を提供します。

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

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

ベスト・プラクティスはステートレス・サービスを設計することですが、それでも状態は存在するため、サービスが状態を認識する必要があります。 API呼び出しは、多くの場合、ある特定のサービスの状態を最初に確立するための有効な手段ですが、最新の状態を維持するために特に効果的な方法というわけではありません。 サービスを最新に保つために、絶え間ないポーリングで「状態に変更はないか?」を確認するアプローチは単に現実的ではありません。

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

サーバーレス

サーバーレス・アーキテクチャーは、コア・クラウドとマイクロサービスのパターンの一部を論理的な結論に導きます。 サーバーレスの場合、実行単位は単なる小さなサービスではなく関数ですが、これは数行のコードに過ぎません。 マイクロサービスとサーバーレスの関数との境界線は明確ではありませんが、関数は一般的に、マイクロサービスよりも小さいと理解されています。

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

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

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

マイクロサービス・アーキテクチャーの主なメリットに、コンポーネントを個別にデプロイしスケーリングする際の使用率とコストのメリットがあります。 このメリットは、オンプレミス・インフラストラクチャーにもある程度存在しますが、個別に拡張可能な小さいコンポーネントをオンデマンドの従量課金制インフラストラクチャーと組み合わせることにより、真のコスト最適化が実現します。

マイクロサービスのさらに重要なもう1つの主なメリットとして、個々のコンポーネントが、その特定のジョブに最も適したスタックを採用できることが挙げられます。 スタックの急増は、自分で管理すると、相当の複雑さとオーバーヘッドを招く可能性がありますが、サポート・スタックをクラウド・サービスとして消費することで、管理に関する課題が激減します。 すなわち、独自のマイクロサービスの基盤を展開することは不可能ではありませんが、特に始めたばかりの場合はお勧めできません。

共通パターン

マイクロサービス・アーキテクチャー内には、以下のような、一般的な課題と機会の一部の解決に役立つ、一般的で有用な数多くの設計、コミュニケーション、統合のパターンがあります。

  • フロントエンドのためのバックエンド(BFF)パターン:このパターンは、ユーザー・エクスペリエンスとエクスペリエンスが要求するリソースとの間にレイヤーを挿入します。 例えば、デスクトップ上で使用されるアプリケーションには、モバイル・デバイスとは異なる画面サイズ、表示画面、パフォーマンスの制限があります。 BFFパターンを使用すると、開発者は、任意のインターフェースで動作するが、フロントエンドのパフォーマンスに悪影響を与える可能性のある汎用バックエンドをサポートするのではなく、そのインターフェースに最適なオプションを利用して、ユーザー・インターフェースごとに1つのバックエンド・タイプを作成してサポートすることができます。
  • エンティティーと集約のパターン:エンティティーは、その識別子によって識別されるオブジェクトです。 例えば、e-コマース・サイトでは、製品オブジェクトは、製品名、製品タイプ、価格によって識別される場合があります。 e-コマース・サイトの場合、オーダーは、購入者によって注文された製品(エンティティー)の集合(集約)です。 このため、eコマース・サイトの場合、オーダーは、購入者によって注文された商品(エンティティー)のコレクション(集合)です。 これらのパターンは、データを意味のある方法で分類するのに使用されます。
  • サービス検出パターン:アプリケーションとサービスが互いを検出するのに役立ちます。 マイクロサービス・アーキテクチャーでは、サービス・インスタンスは、スケーリング、アップグレード、サービス障害によって、またサービス終了によっても動的に変化します。 これらのパターンは、この推移に対応する検出メカニズムを提供します。 ロード・バランシングは、正常性チェックやサービス障害をトリガーとして、サービス検出パターンを使用し、トラフィックのリバランスを実行できます。
  • アダプター・マイクロサービスのパターン:アダプター・パターンは、国外に出張するときに使用するプラグ・アダプターと同じように考えます。 アダプター・パターンの目的は、他の方法では互換性のないクラス間またはオブジェクト間の関係変換を支援することです。 サード・パーティーのAPIに依存するアプリケーションは、アダプター・パターンを使用して、アプリケーションとAPIが通信できるようにする必要がある場合があります。
  • Stranglerアプリケーション・パターン:モノリシック・アプリケーションをマイクロサービス・アプリケーションにリファクタリングするのに役立ちます。 特徴的な名前は、つる植物(マイクロサービス)が、ゆっくりと長い時間をかけて、巻き付いた木(モノリシック・アプリケーション)を圧倒して抑えつける様子を表しています。

これらのパターンについての詳細は、「マイクロサービスを使用した開発パターンの使用方法(パート4)」でご覧いただけます。 またIBM Developerでも、その他のマイクロサービスのコード・パターンの詳細について多くの情報を提供しています。

アンチパターン

マイクロサービスをうまく実行するためのパターンは数多くありますが、開発チームでの問題が発生しやすい可能性のあるパターンも同程度に存在します。 言い換えるとマイクロサービスで「してはいけないこと」の一部は、次のとおりです。

  • マイクロサービスの最初のルール「マイクロサービスを構築してはいけない」:より正確に述べるならば、開始時からマイクロサービスを使用してはいけない、です。 マイクロサービスは、アプリケーションが大きくなりすぎて、更新と保守が容易にできなくなった場合に、複雑さを管理するための方法の1つです。 忍び寄るモノリシック・アプリケーションの複雑さに煩わしさを感じ始めた時だけ、そのアプリケーションをより小さなサービスにリファクタリングする方法を検討することに価値があります。 その煩わしさがないのであれば、リファクタリングを必要とするモノリシック・アプリケーションなどないことになります。
  • DevOpsやクラウド・サービスを使用せずマイクロサービスを実行しない:マイクロサービスの構築とは、分散システムの構築を意味します。分散システムの構築は難しいものです(特に、一層難しくなるような選択をすると、構築は困難を極めます)。 次の事柄を欠いてマイクロサービスを実行しようとすると、不必要なトラブルを招きます。a)適切なデプロイメントとモニタリングの自動化。 b)現在拡大している異種インフラストラクチャーをサポートするためのマネージド・クラウド・サービス。 問題は排除して、状態に注意する時間が取れるようにしてください。
  • マイクロサービスを小さくしすぎて数多く作りすぎない:マイクロサービスの小型化を追及しすぎると、マイクロサービス・アーキテクチャーの全体的なメリットを上回るオーバーヘッドと複雑さにたやすく陥ってしまうことがあります。 比較的大きなサービスを作り、そのサービスにマイクロサービスが解決できる特性が表れ始めた場合にのみ分解することをお勧めします。特性とは、変更をデプロイするのが難しくスピードが落ちた、共通データ・モデルが過剰に複雑になりつつある、サービスの部分ごとに異なる負荷やスケール要件がある、などです。
  • マイクロサービスをSOAに変換しない:マイクロサービスとサービス指向アーキテクチャー(SOA)は同一のものとして扱われることが多くあります。どちらも、最も基本的なレベルでは、他のアプリケーションが消費できる再使用可能な個別コンポーネントの構築に関心があると仮定されています。 マイクロサービスとSOAの違いは、マイクロサービス・プロジェクトでは通常、管理を容易にするためにアプリケーションのリファクタリングを行うのに対し、SOAは全社的にITサービスが機能する方法を変える、という点にあります。 SOAプロジェクトに形を変えるマイクロサービス・プロジェクトは、それ自体の重みに耐えられない可能性があります。
  • Netflixを目指してはいけない:Netflixは、すべてのインターネット・トラフィックの3分の1を占めるアプリケーションを構築・管理する際の、マイクロサービス・アーキテクチャーの初期パイオニアの1つでした。そのときの状況は、平均的なアプリケーションでは不要なカスタム・コードやサービスを多数作成する必要があるという困難を極めるものでした。 複雑さを回避し、できるだけ多くの既製のツールを使用して、処理できるペースから始める方がはるかにうまくいきます。

チュートリアル: マイクロサービス・スキルの構築

マイクロサービスの使用方法の詳細を見ようとしている場合、またはマイクロサービス・スキルを習得する必要がある場合は、以下のチュートリアルのいずれかをお試しください。

マイクロサービスとIBM Cloud

マイクロサービスは、現代のビジネス・スピードで革新的な開発を可能にします。 独立したマイクロサービスをクラウド環境にデプロイしてクラウドのスケーラビリティーと柔軟性を活用する方法を説明します。 IBMの支援を得たアプリケーションのモダナイズはどのようなものになるかをご覧ください。

詳細情報はこちら:

  • IBMのクラウド・ネイティブ開発ツールによる支援で反復作業を自動化し、開発チームを解放します。
  • Red Hat OpenShift on IBM Cloud、またはIBM Cloud Kubernetes Serviceを使って使用を開始するマネージドKubernetesの詳細をご覧ください。 また、サーバーレス・コンピューティングの詳細については、IBM Cloud Code Engineを参照してください。
  • マイクロサービスは、テクノロジーと同程度にチームのプロセスと組織に重要なものです。 IBM DevOpsの支援を得て、DevOpsアプローチの戦略的計画を策定します。

今すぐIBM Cloudアカウントを使用して開始しましょう。