マイクロサービス 9つの特徴 - Opensourcetechブログ

以下の記事の翻訳です。
https://martinfowler.com/articles/microservices.html

マイクロサービス
この新しい建築用語の定義は

「マイクロサービスアーキテクチャ」という用語は、独立してデプロイ可能なサービスのスイートとしてソフトウェアアプリケーションを設計する特定の方法を説明するために、ここ数年で生まれました。このアーキテクチャスタイルの正確な定義はありませんが、ビジネス機能、自動デプロイ、エンドポイントのインテリジェンス、および言語とデータの分散制御に関する組織には、特定の共通の特徴があります。

「マイクロサービス」-ソフトウェアアーキテクチャの混雑した通りにあるもう1つの新しい用語です。私たちの自然な傾向は、軽蔑的な視線でそのようなものを通過させることですが、このちょっとした用語は、私たちがますます魅力的に感じているソフトウェアシステムのスタイルを記述しています。ここ数年、多くのプロジェクトがこのスタイルを使用しているのを見てきましたが、これまでの結果は肯定的であり、多くの同僚にとって、これはエンタープライズアプリケーションを構築するためのデフォルトスタイルになりつつあります。しかし残念なことに、マイクロサービススタイルとは何か、その方法を概説する情報はあまりありません。

簡単に言えば、マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを小さなサービスのスイートとして開発するためのアプローチであり、各サービスは独自のプロセスで実行され、軽量なメカニズム(多くの場合、HTTPリソースAPI)と通信します。これらのサービスはビジネス機能を中心に構築され、完全に自動化されたデプロイメントマシンによって独立してデプロイできます。これらのサービスは、異なるプログラミング言語で記述され、異なるデータストレージ技術を使用する可能性があり、最小限の集中管理があります。

マイクロサービススタイルの説明を始めるには、モノリシックスタイル、つまり単一のユニットとして構築されたモノリシックアプリケーションと比較すると便利です。エンタープライズアプリケーションは、多くの場合、クライアントサイドのユーザインターフェイス(ユーザのマシン上のブラウザで実行されるHTMLページとjavascriptで構成される)、データベース(一般的で通常はリレーショナルなデータベース管理システムに挿入される多くのテーブルで構成される)、およびサーバサイドアプリケーションの3つの主要部分で構築されます。サーバサイドアプリケーションは、HTTPリクエストの処理、ドメインロジックの実行、データベースからのデータの取得と更新、およびブラウザに送信されるHTMLビューの選択と入力を行います。このサーバサイドアプリケーションは、単一の論理実行可能ファイルであるモノリスです。システムへの変更には、新しいバージョンのサーバサイドアプリケーションの構築とデプロイが含まれます。

このようなモノリシックなサーバは、このようなシステムを構築するための自然な方法である。リクエストを処理するためのすべてのロジックは単一のプロセスで実行されるため、言語の基本的な機能を使用してアプリケーションをクラス、関数、名前空間に分割することができる。多少の注意を払えば、開発者のラップトップでアプリケーションを実行してテストし、デプロイメントパイプラインを使用して、変更が適切にテストされ、本番環境にデプロイされることを確認できる。ロードバランサの背後で多くのインスタンスを実行することで、モノリスを水平にスケールすることができる。

モノリシックなアプリケーションは成功する可能性がありますが、特により多くのアプリケーションがクラウドにデプロイされるにつれて、ますます多くの人々がそれらに不満を感じています。変更サイクルは互いに結びついています-アプリケーションの小さな部分に加えられた変更は、モノリス全体を再構築してデプロイする必要があります。時間の経過とともに、優れたモジュール構造を維持することが困難になることが多く、そのモジュール内の1つのモジュールにのみ影響を与えるべき変更を維持することが困難になります。スケーリングには、より多くのリソースを必要とするアプリケーションの一部ではなく、アプリケーション全体のスケーリングが必要です。

これらの不満は、アプリケーションをサービススイートとして構築するというマイクロサービスアーキテクチャスタイルにつながっている。サービスが独立してデプロイ可能でスケーラブルであるという事実に加えて、各サービスは強固なモジュール境界を提供し、異なるサービスを異なるプログラミング言語で記述することさえ可能にする。また、異なるチームで管理することもできる。

マイクロサービススタイルが斬新で革新的であると主張するのではなく、そのルーツは少なくともUnixの設計原則にまでさかのぼる。しかし、マイクロサービスアーキテクチャを検討している人は十分ではなく、多くのソフトウェア開発はそれを使用した方が良いと考えている。

マイクロサービスアーキテクチャの特徴

マイクロサービスアーキテクチャスタイルの正式な定義があるとは言えませんが、ラベルに適合するアーキテクチャの共通の特徴として見られるものを説明しようとすることはできます。共通の特徴を概説する他の定義と同様に、すべてのマイクロサービスアーキテクチャがすべての特徴を持っているわけではありませんが、ほとんどのマイクロサービスアーキテクチャがほとんどの特徴を示すことを期待しています。私たちの著者はこのかなり緩やかなコミュニティの積極的なメンバーですが、私たちの意図は、私たち自身の作業や、私たちが知っているチームによる同様の取り組みで見られるものの説明を試みることです。特に、私たちは準拠する定義を定めていません。

1.サービスを介したコンポーネント化

私たちがソフトウェア業界に関わっている限り、物理的な世界で物が作られるのと同じように、コンポーネントをつなぎ合わせてシステムを構築したいという願望がありました。過去数十年の間に、ほとんどの言語プラットフォームの一部である共通ライブラリの大規模な概要について、かなりの進歩が見られました。

コンポーネントについて話すとき、私たちはコンポーネントを構成するものの難しい定義に直面します。私たちの定義では、コンポーネントは独立して交換可能でアップグレード可能なソフトウェアの単位です。

マイクロサービスアーキテクチャはライブラリを使用しますが、独自のソフトウェアをコンポーネント化する主な方法は、サービスに分解することです。ライブラリは、プログラムにリンクされ、インメモリ関数呼び出しを使用して呼び出されるコンポーネントとして定義されます。一方、サービスは、Webサービスリクエストやリモートプロシージャコールなどのメカニズムと通信するプロセス外コンポーネントです(これは、多くのOOプログラムにおけるサービスオブジェクトの概念とは異なります)。

サービスを(ライブラリではなく)コンポーネントとして使用する主な理由の1つは、サービスが独立してデプロイ可能であることです。単一プロセス内の複数のライブラリで構成されるアプリケーションがある場合、単一のコンポーネントを変更すると、アプリケーション全体を再デプロイする必要があります。しかし、そのアプリケーションが複数のサービスに分解されると、多くの単一のサービス変更が、そのサービスの再デプロイのみを必要とすることが予想されます。これは絶対的なものではなく、いくつかの変更はサービスインターフェイスを変更し、何らかの調整をもたらすが、優れたマイクロサービスアーキテクチャの目的は、サービス契約におけるまとまりのあるサービス境界と進化メカニズムを通じて、これらを最小限に抑えることである。

サービスをコンポーネントとして使用することのもう1つの結果は、より明示的なコンポーネントインターフェイスです。ほとんどの言語には、明示的な公開インターフェイスを定義するための優れたメカニズムがありません。多くの場合、クライアントがコンポーネントのカプセル化を破壊し、コンポーネント間の過度の密結合につながるのを防ぐのは、ドキュメントと規律だけです。サービスは、明示的なリモートコールメカニズムを使用することによって、これを簡単に回避できるようにします。

このようなサービスを使用することには、マイナス面があります。リモート呼び出しはインプロセス呼び出しよりも高価であるため、リモートAPIは粒度を粗くする必要があり、これは多くの場合、使いにくいものです。コンポーネント間の責任の割り当てを変更する必要がある場合、プロセスの境界を越えているときにこのような動作の移動を行うのは困難です。

一次近似では、サービスがランタイムプロセスにマッピングされることがわかりますが、これは一次近似にすぎません。サービスは、そのサービスによってのみ使用されるアプリケーションプロセスやデータベースなど、常に一緒に開発およびデプロイされる複数のプロセスで構成される場合があります。

2.ビジネス機能を中心に構成

大規模なアプリケーションを複数の部分に分割しようとする場合、多くの場合、管理者はテクノロジレイヤに焦点を当て、UIチーム、サーバサイドロジックチーム、およびデータベースチームにつながります。これらの線に沿ってチームが分離されている場合、単純な変更であっても、チーム間のプロジェクトに時間と予算の承認が必要になる可能性があります。スマートなチームは、この点を最適化し、2つの悪のうち小さい方に対応します-アクセスできるアプリケーションにロジックを強制するだけです。言い換えれば、ロジックはどこにでもあります。これはConwayの生ける法の一例です。

(広義に定義された)システムを設計する組織は、その構造が組織のコミュニケーション構造のコピーである設計を作成する。

--メルヴィン・コンウェイ、1968年

分割に対するマイクロサービスのアプローチは異なり、ビジネス機能を中心に編成されたサービスに分割されます。このようなサービスは、ユーザー・インタフェース、永続ストレージ、外部コラボレーションなど、そのビジネス領域のソフトウェアの幅広いスタック実装を必要とします。その結果、チームは、開発に必要なすべてのスキル(ユーザー・エクスペリエンス、データベース、プロジェクト管理)を含む部門横断的です。

この方法で組織された企業の1つがwww.comparethemarket.comです。クロス・ファンクショナルチームは各製品の構築と運用を担当し、各製品はメッセージバスを介して通信する多数の個々のサービスに分割されます。

大規模なモノリシックアプリケーションは、ビジネス機能を中心に常にモジュール化することができますが、これは一般的なケースではありません。モノリシックアプリケーションを構築する大規模なチームには、ビジネスラインに沿って自らを分割することを強く求めます。ここで見てきた主な問題は、それらがあまりにも多くのコンテキストを中心に編成される傾向があることです。モノリスがこれらのモジュール境界の多くにまたがる場合、チームの個々のメンバーがそれらを短期記憶に適合させることは困難になる可能性があります。さらに、モジュールラインは強制するために多くの規律を必要とすることがわかります。サービスコンポーネントによって必要とされる必然的により明確な分離は、チームの境界を明確に保つことを容易にします。

3.プロジェクトではない製品

私たちが目にするほとんどのアプリケーション開発作業は、プロジェクトモデルを使用しています。プロジェクトモデルでは、目的は、完成したと見なされるソフトウェアの一部を提供することです。完成したソフトウェアはメンテナンス組織に引き渡され、それを構築したプロジェクトチームは解散します。

マイクロサービスの支持者は、このモデルを避ける傾向があり、代わりにチームが製品の全寿命にわたって製品を所有すべきであるという概念を好む傾向がある。これに対する一般的なインスピレーションは、開発チームが本番環境のソフトウェアに対して完全な責任を負うというAmazonの「構築すれば実行する」という概念である。これにより、開発者は本番環境でのソフトウェアの動作に日常的に接触するようになり、サポート負担の少なくとも一部を引き受けなければならないため、ユーザとの接触が増加する。

製品のメンタリティーは、ビジネス能力とのつながりと結びついています。ソフトウェアを完成すべき一連の機能として見るのではなく、ソフトウェアがビジネス能力を強化するためにユーザーをどのように支援できるかという問題が進行中の関係があります。

モノリシックなアプリケーションで同じアプローチを採用できない理由はありませんが、サービスの粒度が小さいため、サービス開発者とそのユーザーとの間に個人的な関係を構築することが容易になります。

4.スマートエンドポイントとダムパイプ

異なるプロセス間の通信構造を構築する場合、通信メカニズム自体に重要なインテリジェンスを組み込むことを強調する多くの製品やアプローチを見てきました。この好例がエンタープライズ・サービス・バス(ESB)で、ESB製品にはメッセージ・ルーティング、コレオグラフィー、変換、ビジネス・ルールの適用のための高度な機能が含まれていることがよくあります。マイクロサービスとSOA

私たちがマイクロサービスについて話したとき、一般的な疑問は、これが10年前に見たサービス指向アーキテクチャ(SOA)だけなのかということです。マイクロサービススタイルは、SOAの一部の支持者が支持してきたものと非常に似ているため、この点にはメリットがあります。しかし問題は、SOAはあまりにも多くの異なることを意味し、「SOA」と呼ばれるものに遭遇するほとんどの場合、ここで説明しているスタイルとは大きく異なり、通常はモノリシックアプリケーションを統合するために使用されるESBに焦点を当てていることです。

特に、ESBの複雑さを隠す傾向[5]から、数百万ドルのコストがかかり、価値を提供しない失敗した複数年のイニシアチブ、積極的に変更を抑制する集中化されたガバナンスモデルまで、サービス指向の実装の失敗を数多く見てきましたが、これらの問題を見過ごすことは困難な場合があります。

確かに、マイクロサービスコミュニティで使用されている技術の多くは、開発者が大規模な組織にサービスを統合した経験から成長しています。Tolerant Readerパターンはその一例です。Webを使用する努力が貢献しており、単純なプロトコルを使用することは、これらの経験から派生した別のアプローチであり、率直に言って息をのむような複雑さに達した中心的な標準から離れた反応です。(オントロジーを管理するためにオントロジーが必要な場合はいつでも、深刻な問題に直面していることがわかります。)

このSOAの一般的な表現により、一部のマイクロサービス支持者はSOAラベルを完全に拒否するようになりましたが、マイクロサービスはSOAの1つの形式[6]であり、おそらくサービス指向が適切であると考える人もいます。いずれにしても、SOAがこのような異なる意味を持つという事実は、このアーキテクチャスタイルをより明確に定義する用語を持つことが価値があることを意味します。

マイクロサービスコミュニティは、スマートエンドポイントとダムパイプという代替アプローチを支持している。マイクロサービスから構築されたアプリケーションは、可能な限り分離され、結合されることを目的としている-独自のドメインロジックを所有し、古典的なUnixの意味でのフィルタとして機能し、要求を受け取り、必要に応じてロジックを適用し、応答を生成する。これらは、WS-ChoreographyやBPELなどの複雑なプロトコルや、中央ツールによるオーケストレーションではなく、単純なRESTishプロトコルを使用して振り付けされる。

最も一般的に使用されている2つのプロトコルは、リソースAPIを使用したHTTP要求-応答と軽量メッセージングである。1つ目の最良の表現は

ウェブの背後ではなく、ウェブのものであること

--Ian Robinson氏

マイクロサービスチームは、World Wide Web(および大部分はUnix)が構築されている原則とプロトコルを使用します。多くの場合、使用されるリソースは、開発者や運用担当者のごくわずかな労力でキャッシュできます。

一般的に使用されている2番目のアプローチは、軽量なメッセージバスを介したメッセージングである。選択されたインフラストラクチャは、一般的にダム(メッセージルータとしてのみ機能するダム)である-RabbitMQやZeroMQなどの単純な実装は、信頼性の高い非同期ファブリックを提供するだけである-スマートは、メッセージを生成および消費するエンドポイント、つまりサービスにまだ存在している。

モノリスでは、コンポーネントはインプロセスで実行され、コンポーネント間の通信はメソッド呼び出しまたはファンクションコールを介して行われる。モノリスをマイクロサービスに変更する際の最大の問題は、コミュニケーションパターンを変更することにある。インメモリメソッド呼び出しからRPCへの単純な変換は、うまく機能しないおしゃべりな通信につながる。代わりに、細かい粒度の通信を粗い粒度のアプローチに置き換える必要がある。

5.分散型ガバナンス

一元化されたガバナンスの結果の1つは、単一の技術プラットフォームで標準化する傾向があることである。経験によれば、このアプローチは窮屈であり、すべての問題が釘であるわけではなく、すべてのソリューションがハンマーであるわけでもない。私たちはジョブに適したツールを使用することを好み、モノリシックなアプリケーションはさまざまな言語をある程度活用できますが、それほど一般的ではありません。

モノリスのコンポーネントをサービスに分割するには、それぞれを構築するときに選択肢があります。Node.jsを使って簡単なレポートページを立ち上げたいですか?やってみてください。特にぎこちない準リアルタイムコンポーネントのためのC++ですか?いいですね。1つのコンポーネントの読み取り動作により適した別のフレーバーのデータベースにスワップしたいですか?私たちは彼を再構築する技術を持っています。

もちろん、何かをすることができるからといって、そうすべきだというわけではありません。しかし、この方法でシステムを分割することは、選択肢があることを意味します。

マイクロサービスを構築するチームも、標準に対して異なるアプローチを好む。彼らは、紙のどこかに書かれた定義された標準のセットを使用するのではなく、他の開発者が直面している問題と同様の問題を解決するために使用できる有用なツールを作成するというアイデアを好む。これらのツールは通常、実装から収集され、より広範なグループと共有されるが、内部のオープンソースモデルを使用する場合もある。gitとgithubが事実上のバージョン管理システムとして選択されるようになった今、オープンソースプラクティスは社内でますます一般的になりつつある。

Netflixは、この哲学に従う組織の好例である。有用で、何よりも戦闘でテストされたコードをライブラリとして共有することは、他の開発者が同様の問題を同様の方法で解決することを奨励するが、必要に応じて別のアプローチを選択する余地を残す。共有ライブラリは、データストレージ、プロセス間通信、および以下でさらに説明するように、インフラストラクチャの自動化という一般的な問題に焦点を当てる傾向がある。

マイクロサービスコミュニティにとって、オーバーヘッドは特に魅力的ではありません。コミュニティがサービス契約を評価していないと言っているわけではありません。サービス契約はより多く存在する傾向があるため、まったく逆です。単に、それらの契約を管理するさまざまな方法を検討しているだけです。Tolerant ReaderやConsumer-Driven Contractsなどのパターンは、マイクロサービスに適用されることがよくあります。これらは、サービス契約が独立して進化するのを支援します。ビルドの一部としてコンシューマ主導の契約を実行することで、信頼性が向上し、サービスが機能しているかどうかについて迅速なフィードバックが提供されます。実際、私たちは、コンシューマ主導の契約で新しいサービスのビルドを推進するオーストラリアのチームを知っています。彼らは、サービスの契約を定義できる単純なツールを使用します。これは、新しいサービスのコードが記述される前に、自動化されたビルドの一部になります。サービスは、契約を満たすポイントまでのみビルドされます。これは、新しいソフトウェアを構築するときの「YAGNI」のジレンマを回避するためのエレガントなアプローチです。これらの技術とそれらを中心に成長するツールは、サービス間の時間的結合を減らすことによって、中央契約管理の必要性を制限します。

おそらく、分散化されたガバナンスの頂点は、Amazonによって普及したbuild it/run itの精神である。チームは、ソフトウェアを24/7で運用することを含め、構築するソフトウェアのすべての側面に責任を負う。このレベルの責任の委譲は明らかに標準ではありませんが、開発チームに責任を押し付ける企業がますます増えています。Netflixもこの精神を採用している組織です。毎晩午前3時にポケットベルで起こされることは、コードを書くときに品質に集中するための強力なインセンティブです。これらのアイデアは、従来の集中型ガバナンスモデルとは可能な限りかけ離れています。

6.分散データ管理

データ管理の分散化には、さまざまな方法があります。最も抽象的なレベルでは、世界の概念モデルがシステム間で異なることを意味します。これは、大企業全体で統合する場合の一般的な問題であり、顧客の販売ビューはサポート・ビューと異なります。販売ビューで顧客と呼ばれるものの中には、サポート・ビューにまったく表示されないものもあります。表示されるものは、異なる属性と、(さらに悪いことに)微妙に異なるセマンティクスを持つ共通属性を持つ場合があります。

この問題はアプリケーション間でよく発生しますが、アプリケーション内、特にアプリケーションが個別のコンポーネントに分割されている場合にも発生する可能性があります。これについての有用な考え方は、有界コンテキストのドメイン駆動設計の概念です。DDDは、複雑なドメインを複数の有界コンテキストに分割し、それらの間の関係をマッピングします。このプロセスは、モノリシックアーキテクチャとマイクロサービスアーキテクチャの両方で有用ですが、サービスとコンテキストの境界の間には、明確にするのに役立つ自然な相関関係があり、ビジネス機能のセクションで説明するように、分離を強化します。

概念モデルに関する決定を分散化するだけでなく、マイクロサービスはデータストレージに関する決定も分散化する。モノリシックなアプリケーションは永続的なデータに対して単一の論理データベースを好むが、企業は多くの場合、さまざまなアプリケーションにわたって単一のデータベースを好む-これらの決定の多くは、ライセンスに関するベンダーの商用モデルを通じて行われる。マイクロサービスは、同じデータベーステクノロジの異なるインスタンス、または完全に異なるデータベースシステムのいずれかで、各サービスが独自のデータベースを管理できるようにすることを好む-Polyglot Persistenceと呼ばれるアプローチ。モノリスでは多言語永続性を使用できるが、マイクロサービスではより頻繁に使用される。マイクロサービス間でデータの責任を分散することは、更新の管理に影響を与える。更新を処理するための一般的なアプローチは、複数のリソースを更新するときにトランザクションを使用して一貫性を保証することであった。このアプローチは、モノリス内でよく使用される。

このようなトランザクションを使用することは、一貫性には役立つが、複数のサービスにわたって問題となる重大な時間的結合を課す。分散トランザクションは実装が困難であることで知られており、その結果、マイクロサービスアーキテクチャは、一貫性は最終的な一貫性のみである可能性があり、問題は補償操作によって処理されるという明確な認識とともに、サービス間のtransactionless調整を強調する。

この方法で不整合を管理することを選択することは、多くの開発チームにとって新たな課題ですが、ビジネスプラクティスと一致することがよくあります。多くの場合、企業は需要に迅速に対応するためにある程度の不整合を処理し、一方で、ミスに対処するための何らかの反転プロセスを持っています。ミスを修正するコストが、より高い一貫性の下でビジネスを失うコストよりも小さい限り、このトレードオフは価値があります。

7.インフラストラクチャの自動化

インフラストラクチャの自動化技術は、ここ数年で大きく進化した-特にクラウドとAWSの進化により、マイクロサービスの構築、デプロイ、運用の運用上の複雑さが軽減された。

マイクロサービスで構築されている製品やシステムの多くは、継続的デリバリとその前身である継続的インテグレーションの広範な経験を持つチームによって構築されています。この方法でソフトウェアを構築するチームは、インフラストラクチャ自動化技術を広範に使用します。これは、以下に示すビルドパイプラインに示されています。これは継続的デリバリに関する記事ではないので、ここではいくつかの重要な機能に注意を喚起します。ソフトウェアが動作していることをできるだけ信頼したいので、多くの自動テストを実行します。パイプライン上で動作するソフトウェアの促進は、新しい環境へのデプロイを自動化することを意味します。

モノリシックなアプリケーションは、これらの環境で構築、テスト、およびプッシュされます。モノリスの本番環境へのパスを自動化することに投資すれば、より多くのアプリケーションをデプロイすることは、もはやそれほど恐ろしいことではないことがわかります。CDの目的の1つは、デプロイを退屈なものにすることであることを覚えておいてください。そのため、アプリケーションが1つであっても3つであっても、それが退屈である限りは問題ではありません。

広範なインフラストラクチャ自動化を使用しているチームが見られるもう1つの領域は、本番環境でマイクロサービスを管理する場合です。デプロイが退屈である限り、モノリスとマイクロサービスの間に大きな違いはないという上記の主張とは対照的に、それぞれの運用環境は著しく異なる可能性があります。

8.失敗に対する設計

サービスをコンポーネントとして使用することの結果として、アプリケーションはサービスの障害を許容できるように設計する必要がある。サプライヤが利用できないためにサービスコールが失敗する可能性があるため、クライアントはこれに対して可能な限り優雅に応答する必要がある。これは、モノリシック設計と比較して、それを処理するための追加の複雑さを導入するという欠点である。その結果、マイクロサービスチームは、サービス障害がユーザ体験にどのように影響するかを常に熟考することになる。NetflixのSimian Armyは、アプリケーションの耐障害性と監視の両方をテストするために、営業日にサービスやデータセンターの障害を引き起こす。

この種の本番環境での自動テストは、ほとんどの運用グループに対して、通常は1週間の仕事の休みの前にあるような震えを与えるのに十分です。これは、モノリシックなアーキテクチャスタイルが高度な監視設定ができないと言っているのではなく、私たちの経験ではあまり一般的ではないだけです。

サービスはいつでも失敗する可能性があるため、障害を迅速に検出し、可能であれば自動的にサービスを復元できることが重要である。マイクロサービスアプリケーションは、アプリケーションのリアルタイム監視に重点を置いており、アーキテクチャ要素(データベースが1秒あたりに受信するリクエスト数)とビジネス関連のメトリック(1分あたりに受信する注文数など)の両方をチェックする。セマンティック監視は、開発チームがフォローアップと調査を行うきっかけとなる、何か問題が発生した場合の早期警告システムを提供することができる。

これはマイクロサービスアーキテクチャにとって特に重要です。なぜなら、コレオグラフィーとイベントコラボレーションに対するマイクロサービスの好みは、創発的な動作につながるからです。多くの専門家が偶然の創発の価値を称賛していますが、実際には、創発的な動作は時に悪いものになる可能性があります。監視は、悪い創発的な動作を迅速に発見して修正するために不可欠です。

モノリスはマイクロサービスと同じように透過的に構築することができます-実際、そうあるべきです。違いは、異なるプロセスで実行されているサービスが切断されたときには、絶対に知っておく必要があるということです。同じプロセス内のライブラリでは、この種の透過性はあまり有用ではありません。

マイクロサービスチームは、アップ/ダウンステータスを表示するダッシュボードや、運用およびビジネスに関連するさまざまなメトリックなど、個々のサービスの高度な監視とロギングの設定を期待するだろう。サーキットブレーカのステータス、現在のスループット、レイテンシの詳細は、実際によく見られる他の例である。

9.発展的設計

マイクロサービスの実践者は、通常、進化的な設計のバックグラウンドを持ち、サービス分解を、アプリケーション開発者が変更を遅らせることなくアプリケーションの変更を制御できるようにするためのさらなるツールと見なしています。変更管理は必ずしも変更の削減を意味するわけではありません。適切な姿勢とツールを使用して、ソフトウェアに対して頻繁に、迅速に、適切に管理された変更を行うことができます。

ソフトウェアシステムをコンポーネントに分割しようとするたびに、分割方法の決定に直面する-アプリケーションを分割することを決定する原則は何か?コンポーネントの重要な特性は、独立した置き換えとアップグレード可能性の概念であり、これは、協力者に影響を与えることなくコンポーネントを書き直すことを想像できるポイントを探すことを意味する。実際、多くのマイクロサービスグループは、多くのサービスが長期的に進化するのではなく、廃棄されることを明示的に期待することによって、これをさらに進めている。

Guardian Webサイトは、モノリスとして設計および構築されたアプリケーションの好例ですが、マイクロサービスの方向に進化しています。モノリスは依然としてWebサイトのコアですが、彼らはモノリスのAPIを使用するマイクロサービスを構築することによって新しい機能を追加することを好みます。このアプローチは、スポーツイベントを処理するための特殊なページなど、本質的に一時的な機能に特に便利です。Webサイトのこのような部分は、効率的開発言語を使用して迅速にまとめることができ、イベントが終了すると削除されます。市場機会のために新しいサービスが追加され、数ヶ月または数週間後に破棄される金融機関で同様のアプローチを見てきました。

この置換可能性の強調は、モジュール設計のより一般的な原則の特別なケースであり、変更のパターンを通じてモジュール性を推進することである[13]。同じモジュール内で同時に変更されるものを保持する必要があります。めったに変更されないシステムの部分は、現在多くのチャーンを経験しているサービスとは異なるサービスにあるべきです。2つのサービスを一緒に繰り返し変更することに気付いた場合、それはそれらがマージされるべきであることを示しています。

コンポーネントをサービスに配置することで、より詳細なリリース計画の機会が追加されます。モノリスでは、変更にはアプリケーション全体の完全なビルドとデプロイが必要です。ただし、マイクロサービスでは、変更したサービスを再デプロイするだけで済みます。これにより、リリースプロセスが簡素化され、高速化されます。マイナス面は、1つのサービスへの変更がそのコンシューマを破壊することを心配しなければならないことです。従来の統合アプローチでは、バージョン管理を使用してこの問題に対処しようとしますが、マイクロサービスの世界では、最後の手段としてバージョン管理のみを使用することが好まれています。サプライヤの変更に対して可能な限り耐性を持つようにサービスを設計することで、多くのバージョン管理を回避できます。

マイクロサービスは未来か?

この記事を書く主な目的は、マイクロサービスの主要なアイデアと原則を説明することである。時間をかけてこれを行うことで、マイクロサービスアーキテクチャスタイルは重要なアイデアであり、エンタープライズアプリケーションで真剣に検討する価値があると明確に考えている。私たちは最近、このスタイルを使用していくつかのシステムを構築しており、このアプローチを使用して支持している他のシステムを知っている。

私たちが知っているアーキテクチャスタイルのパイオニアには、Amazon、Netflix、The Guardian、英国政府デジタルサービス、realestate.com. au、Forward、comparethemarket.comなどがあります。2013年のカンファレンスサーキットには、Travis CIなど、マイクロサービスとしてクラス分けされるものに移行しつつある企業の例がたくさんありました。さらに、マイクロサービスとしてクラス分けされるものを長い間行ってきたが、その名前を使用していない組織もたくさんあります。(これはSOAと呼ばれることが多いですが、前述したように、SOAには多くの矛盾した形式があります。[14])

しかし、これらの肯定的な経験にもかかわらず、マイクロサービスがソフトウェアアーキテクチャの将来の方向性であると確信していると主張しているわけではありません。これまでの経験はモノリシックアプリケーションと比較して肯定的ですが、完全な判断を下すのに十分な時間が経過していないという事実を意識しています。

多くの場合、アーキテクチャの決定の真の結果は、それを行ってから数年後になって初めて明らかになります。モジュール性への強い願望を持つ優れたチームが、長年にわたって衰退してきたモノリシックアーキテクチャを構築したプロジェクトを見てきました。多くの人は、サービス境界が明示的であり、パッチを当てるのが難しいため、マイクロサービスではそのような衰退の可能性は低いと考えています。しかし、十分な年数のある十分なシステムを見るまでは、マイクロサービスアーキテクチャがどのように成熟するかを真に評価することはできません。

マイクロサービスが十分に成熟しないと予想される理由は確かにあります。コンポーネント化のいかなる取り組みにおいても、成功はソフトウェアがコンポーネントにどの程度適合するかにかかっています。コンポーネントの境界がどこにあるべきかを正確に理解するのは困難です。進化的設計は、境界を正しくすることの難しさを認識しており、したがって、それらを簡単にリファクタリングすることの重要性を認識しています。しかし、コンポーネントがリモート通信を使用するサービスである場合、リファクタリングはインプロセスライブラリよりもはるかに困難です。サービス境界を越えてコードを移動することは困難であり、インターフェイスの変更は参加者間で調整する必要があり、後方互換性のレイヤを追加する必要があり、テストはより複雑になります。

もう1つの問題は、コンポーネントがきれいに構成されていない場合、あなたがしていることは、コンポーネントの内部からコンポーネント間の接続に複雑さをシフトすることだけです。これは単に複雑さを移動させるだけでなく、あまり明確でなく制御しにくい場所に移動させます。小さくて単純なコンポーネントの内部を見ているときに、サービス間の乱雑な接続を見逃していると、物事がより良いと考えるのは簡単です。

最後に、チームスキルの要素があります。新しいテクニックは、より熟練したチームによって採用される傾向があります。しかし、より熟練したチームに対してより効果的なテクニックが、必ずしも熟練していないチームにも有効であるとは限りません。あまり熟練していないチームが乱雑なモノリシックアーキテクチャを構築している多くの事例を見てきましたが、この種の混乱がマイクロサービスで発生した場合に何が起こるかを見るには時間がかかります。貧弱なチームは常に貧弱なシステムを作成します-マイクロサービスがこの場合の混乱を軽減するのか、悪化させるのかを判断するのは非常に困難です。

私たちが耳にした合理的な議論の1つは、マイクロサービスアーキテクチャから始めるべきではないということです。代わりに、モノリスから始めて、それをモジュラーに保ち、モノリスが問題になったらマイクロサービスに分割します。(ただし、優れたインプロセスインターフェイスは通常、優れたサービスインターフェイスではないため、このアドバイスは理想的ではありません。)

そこで、私たちは慎重な楽観主義を持ってこれを書いています。これまでのところ、マイクロサービススタイルについて十分に見てきたので、それは歩く価値のある道になり得ると感じています。私たちがどこにたどり着くかは定かではありませんが、ソフトウェア開発の課題の1つは、現在手元にある不完全な情報に基づいてのみ決定を下すことができるということです。