マイクロサービス

翻訳者から：マーティン・ファウラーと彼の同僚ジェームズ・ルイスのこのタイタニックな作品をすでに読んでいる人もいるでしょうが、私はこの記事を翻訳することにしました。 マイクロサービスのトレンドは、エンタープライズ開発の世界で勢いを増しており、この記事は貴重な知識の源であり、実際に既存の経験を絞り込んでいます。



「マイクロサービスアーキテクチャ」という用語は、独立して展開された一連のサービスとしてアプリケーションを設計する方法を説明するものとして、ここ数年で一般的になりました。 このアーキテクチャスタイルの正確な説明はありませんが、特定の一般的な特性セットがあります：ビジネスニーズ、自動展開、メッセージバスからレシーバー（エンドポイント）へのロジックの転送、および言語とデータの分散制御に関するサービスの編成。



マイクロサービスは、ソフトウェア開発の繁華街での新しい用語です。 そして、私たちは通常、そのようなすべての新製品に非常に警戒していますが、この用語はソフトウェア開発のスタイルを具体的に説明しており、ますます魅力的になっています。 過去数年にわたって、このスタイルを使用する多くのプロジェクトを見てきましたが、これまでのところ非常に良い結果が得られています。 多くの同僚にとって、このスタイルはソフトウェア開発のメインスタイルになります。 残念ながら、マイクロサービスとは何か、それらをどのように適用するかを説明する情報はあまりありません。



要するに、マイクロサービスのアーキテクチャスタイルは、単一のアプリケーションを一連の小さなサービスとして構築し、それぞれが独自のプロセスで動作し、軽量メカニズム（通常はHTTP）を使用して残りと通信するアプローチです。 これらのサービスはビジネスニーズを中心に構築され、完全に自動化された環境を使用して独立して展開されます。 これらのサービスの集中管理の絶対的な最小値があります。 これらのサービスは、それ自体で異なる言語で記述され、異なるストレージテクノロジーを使用できます。



マイクロサービスのスタイルについての話を始めるには、それをモノリシックなスタイル、つまり全体として構築されたアプリケーションと比較するのが最善です。 多くの場合、エンタープライズアプリケーションには、ユーザーインターフェイス（通常はHTMLページとjavascriptで構成される）、データベース（通常はリレーショナルで、多くのテーブルがあります）、およびサーバーの3つの主要部分が含まれます。 サーバーパーツは、HTTPリクエストを処理し、ドメインロジックを実行し、データベース内のデータをリクエストおよび更新し、HTMLページに入力して、クライアントのブラウザーに送信します。 システムの変更は、アプリケーションのサーバー部分の新しいバージョンの再組み立てと展開につながります。



モノリシックサーバーは、このようなシステムを構築するためのかなり明白な方法です。 要求を処理するためのすべてのロジックは単一のプロセスで実行されますが、プログラミング言語の機能を使用して、アプリケーションをクラス、関数、名前空間に分割できます。 開発者のマシンでアプリケーションを実行およびテストし、標準の展開プロセスを使用して変更を確認してから運用環境に配置できます。 ロードバランサーの背後で複数の物理サーバーを実行することにより、モノリシックアプリケーションを水平にスケーリングできます。



モノリシックアプリケーションは成功する可能性がありますが、特にクラウドにデプロイされるアプリケーションが増えているという事実に照らして、ますます多くの人々が失望しています。 どんな小さな変更でも、モノリス全体の再組み立てと展開が必要です。 時間が経つにつれて、適切なモジュール構造を維持することが難しくなり、1つのモジュールのロジックの変更が他のモジュールのコードに影響を与える傾向があります。 このアプリケーションの1つのモジュールにのみ必要な場合でも、アプリケーション全体をスケーリングする必要があります。







これらの不便さは、マイクロサービスのアーキテクチャスタイル、つまりアプリケーションをサービスのセットとして構築することにつながりました。 独立して展開およびスケーリングする機能に加えて、各サービスには明確な物理的境界があり、さまざまなプログラミング言語でさまざまなサービスを作成できます。 また、異なるチームで開発することもできます。



マイクロサービスのスタイルが革新であるとは主張しません。 そのルーツは、少なくともUnixで使用されている設計原則にまで遡ります。 しかし、それにもかかわらず、このスタイルを考慮に入れる人が十分ではなく、多くのアプリケーションがこのスタイルを使用し始めればメリットがあると考えています。

マイクロサービスアーキテクチャのプロパティ

マイクロサービスのスタイルには正式な定義があるとは言えませんが、このスタイルを使用して、アプリケーションの一般的な特性であると考えるものを記述しようとすることはできます。 それらは常に1つのアプリケーションで一度に見つかるわけではありませんが、原則として、各アプリケーションにはこれらの特性のほとんどが含まれています。 私たちは、私たち自身の開発および私たちに知られているチームの開発で見たものを説明しようとします。

サービス共有

業界にいる間、現実の世界とほぼ同じ方法で、さまざまなコンポーネントを接続してシステムを構築したいと考えています。 過去数十年にわたって、ほとんどのプログラミング言語で使用されるライブラリのセットが大きく成長しました。



コンポーネントについて言えば、コンポーネントが何であるかを判断するのが困難になります。 私たちの定義はこれです。コンポーネントは、個別に交換または更新できるソフトウェアです。



マイクロサービスアーキテクチャはライブラリを使用しますが、アプリケーションを分割する主な方法は、ライブラリをサービスに分割することです。 ライブラリは、プログラムに接続し、同じプロセスで呼び出されるコンポーネントとして定義します。一方、サービスは、別のプロセスで実行され、Webリクエストまたはリモートプロシージャコール（RPC）を介して相互に通信するコンポーネントです。



ライブラリの代わりにサービスを使用する主な理由は、独立した展開です。 1つのプロセスで動作する複数のライブラリで構成されるアプリケーションを開発している場合、これらのライブラリを変更すると、アプリケーション全体が再デプロイされます。 ただし、アプリケーションが複数のサービスに分割されている場合、それらのいずれかに影響する変更は、変更されたサービスのみの再デプロイが必要になります。 もちろん、一部の変更はインターフェイスに影響を与えるため、異なるサービス間の調整が必要になりますが、優れたマイクロサービスアーキテクチャの目標は、マイクロサービス間に適切な境界を設定し、サービス契約の進化のメカニズムを設定することにより、そのような調整の必要性を最小限にすることです



コンポーネントとしてサービスを使用することの別の結果は、サービス間のより明示的なインターフェースです。 ほとんどのプログラミング言語には、 Published Interfaceを宣言するための優れたメカニズムがありません。 多くの場合、文書化と規律だけが、コンポーネントのカプセル化の破壊を防ぎます。 サービスは、リモート呼び出しに明示的なメカニズムを使用することでこれを回避できます。



ただし、この方法でサービスを使用すると、欠点があります。 リモート呼び出しは、プロセス内の呼び出しよりも遅いため、APIの詳細度を低くする（粗視化）必要があります。これにより、使用が不便になることがよくあります。 コンポーネント間の責任のセットを変更する必要がある場合、プロセスの境界を越える必要があるため、これを行うのはより困難です。



最初の近似では、サービスはプロセスと1対1で関連していることがわかります。 実際、サービスには、常に一緒に開発およびデプロイされる多くのプロセスを含めることができます。 たとえば、このアプリケーションのみが使用するアプリケーションプロセスとデータベースプロセス。

ビジネスニーズに関する組織

大規模なアプリケーションを複数の部分に分割する場合、管理は多くの場合、テクノロジーに焦点を当て、UIチーム、サーバーチーム、およびデータベースコマンドの形成につながります。 このようにチームを分類すると、チーム間の相互作用が必要なため、小さな変更でも時間がかかります。 これは、チームがアクセスできるレイヤーにロジックを配置するという事実につながります。 アクションのコンウェイの法則。



「システムを設計する（広い意味で）組織は、その組織がこの組織のチームの構造をコピーする設計を受け取ります。」

-メルビン・コンウェイ、1967





アクションのコンウェイの法則



パーティショニングに対するマイクロサービスアプローチには、 ビジネスニーズに応じたサービスへの分解が含まれます。 このようなサービスには、ユーザーインターフェース、データウェアハウス、外部とのやり取りなど、このビジネスニーズに必要なあらゆる技術が含まれます。 これにより、ユーザーエクスペリエンス、データベース、プロジェクト管理など、必要なスキルの完全なセットを備えた機能横断型チームが形成されます。





チームの境界によってサポートされるサービスの境界



このスタイルで組織された企業の1つはwww.comparethemarket.comです。 機能横断型のチームが各製品の構築と運用を担当し、各製品はメッセージバスを介して互いに通信するいくつかの個別のサービスに分割されます。



大規模なモノリシックアプリケーションは、ビジネスニーズに合わせてモジュールに分割することもできますが、これは通常は発生しません。 もちろん、大規模なチームはこの方法でモノリシックアプリケーションを構築することをお勧めします。 ここでの主な問題は、そのようなアプリケーションはあまりにも多くのコンテキストを整理する傾向があるということです。 モノリスが多くのコンテキストをカバーしている場合、個々のチームメンバーはサイズが大きいため、それらを操作するのが難しくなります。 さらに、モノリシックアプリケーションでモジュール式の境界を順守するには、かなりの規律が必要です。 マイクロサービスコンポーネントの明示的に定義された境界は、これらの境界のサポートを簡素化します。

マイクロサービスの大きさは？

マイクロサービスという用語はこのアーキテクチャスタイルの一般的な名前になりましたが、その名前自体は、サービスのサイズと接頭辞「マイクロ」の意味についての議論に過度に焦点を当てています。 ソフトウェアをマイクロサービスに分割することに関与した人たちとの会話の中で、さまざまな規模を見ました。 最大の規模は、「2つのピザチーム」（2つのピザを提供できるチーム）というルールに従った企業でした。 12人以下（ 約transl。：このルールに従って、私はチームに一人でいる必要があります ）。 他の企業では、6人が6つのサービスをサポートするチームを見ました。



これは、1つのサービスで何人の人が作業する必要があるかに大きな違いがあるかどうかという問題につながります。 現時点では、チームを構築するためのこれらのアプローチ（12人に1つのサービスと1人に1つのサービス）の両方がマイクロサービスアーキテクチャの説明に当てはまると考えていますが、将来的に考えが変わるかもしれません。 （ 注意してください：記事の時点から、このトピックを開発した他の多くの記事が登場しました;最も人気のある意見は、コードの行数に関係なく、サービスは完全に「開発者の頭に収まる」ほど大きくなければならないというものです ） 。

プロジェクトではなく製品

私たちが目にするソフトウェア開発会社のほとんどは、機能の一部を開発することを目標とするプロジェクトモデルを使用しており、その機能は完成したと見なされます。 完了後、この部分はサポートチームに移され、プロジェクトチームは解散します。



マイクロサービスの支持者は、このモデルを避け、チームは製品をその寿命を通じて所有しなければならないと主張します。 このアプローチのルーツはAmazonに遡り、会社には「 あなたが開発し、あなたとサポートする 」というルールがあります。このルールでは、開発チームが本番環境のソフトウェアに対して全責任を負います。 これにより、開発者は製品が本番環境でどのように動作するかを定期的に監視し、さらにユーザーと連絡を取り合うという事実につながります。 サポート責任の少なくとも一部を引き受ける必要があります。



製品の観点から考えることは、ビジネスのニーズとのつながりを確立します。 製品は、実装する必要がある一連の機能だけではありません。 これは継続的な関係であり、その目的はユーザーがビジネスチャンスを増やすことを支援することです。



もちろん、これはモノリシックアプリケーションの場合にも実現できますが、サービスの粒度が高いため、サービスの開発者とそのユーザー間の個人的な関係の確立が簡単になります。

スマートレシーバーとダムパイプ（スマートエンドポイントとダムパイプ）

プロセス間の通信を構築する際に、ロジックの大部分がデータ転送メカニズムに配置される方法を何度も目撃しました。 ここでの良い例は、Enterprise Service Bus（ESB）です。 多くの場合、ESB製品には、ビジネスルールの適用だけでなく、メッセージの送信、オーケストレーション、および変換のための高度な機能が含まれています。



マイクロサービスコミュニティは、スマートメッセージ受信機と愚かな伝送チャネルという代替アプローチを好みます。 マイクロサービスアーキテクチャを使用して構築されたアプリケーションは、可能な限り分離され、まとまりがちです。独自のドメインロジックを含み、従来のUnixの意味でフィルターとして機能します。リクエストを受信し、ロジックを適用し、回答を送信します。 WS- *やBPELなどの複雑なプロトコルの代わりに、単純なRESTプロトコルを使用します。



最も一般的に使用される2つのプロトコルは、リソースAPI経由のHTTP要求と軽量メッセージングです。 最初の最高の表現は、 イアン・ロビンソンによって与えられました：「ウェブの後ろではなく、ウェブのこと。」



マイクロサービスアーキテクチャを実践するチームは、World Wide Webが構築されているのと同じ原則とプロトコル（および本質的にUnix）を使用します。 頻繁に使用されるリソースは、開発者やIT管理者のわずかな労力でキャッシュできます。



2番目に一般的に使用される通信ツールは、軽量のメッセージバスです。 このようなインフラストラクチャには通常、ドメインロジックが含まれていません。RabbitMQやZeroMQなどの単純な実装は、非同期ファクトリを提供するだけです。 この場合、ロジックはこのバスの端に存在します-メッセージを送受信するサービスに。



モノリシックアプリケーションでは、コンポーネントは1つのプロセスで動作し、メソッド呼び出しを介して相互に通信します。 モノリスをマイクロサービスに変更する際の最大の問題は、コミュニケーションテンプレートの変更にあります。 1対1の素朴な移植は、あまりうまく機能しないおしゃべりなコミュニケーションにつながります。 代わりに、モジュール間の通信の数を減らす必要があります。

分散管理

集中管理の結果の1つは、使用するプラットフォームを標準化する傾向です。 経験から、このようなアプローチでは選択が制限されすぎていることがわかります。すべての問題が釘であるわけではなく、すべての解決策がハンマーであるわけでもありません。 特定のジョブごとに適切なツールを使用することを好みます。 また、場合によってはモノリシックアプリケーションを異なる言語を使用して作成することもできますが、これは標準的な方法ではありません。



モノリスをサービスに分割する場合、各サービスを構築する方法を選択できます。 簡単なレポートページにNode.jsを使用したいですか？ お願いします。 リアルタイムアプリケーション用のC ++ 素晴らしい。 データベースをコンポーネントの読み取り操作により適したものに置き換えますか？ 神のために。



もちろん、あなたが何かをすることができるからといって、あなたがそれをするべきという意味ではありません。 ただし、この方法でシステムをパーティション分割すると、選択肢が与えられます。



マイクロサービスチームは、別の標準化アプローチも好みます。 誰かが書いた一連の定義済みの標準を使用する代わりに、他の開発者が同様の問題を解決するために使用できる便利なツールを構築するというアイデアを好みます。 これらのツールは通常、プロジェクトの1つのコードから抽出され、異なるチーム間で共有されます。内部のオープンソースモデルを使用することもあります。 gitとgithubが事実上の標準バージョン管理システムになった今、オープンソースのプラクティスは社内プロジェクトでますます一般的になっています。



Netflixは、この哲学に従う組織の良い例です。 バトルサーバーで有用な、さらにライブラリでテストされたコードを共有することで、他の開発者が同様の問題を同様の方法で解決し、必要に応じて別のアプローチを選択できるようになります。 共有ライブラリは、データストレージ、プロセス間通信、インフラストラクチャの自動化に関連する一般的な問題に焦点を合わせる傾向があります。



マイクロサービスコミュニティはサービスコントラクトを重視していますが、オーバーヘッドを好まないため、さまざまな方法でこれらのコントラクトを管理します。 Tolerant ReaderやConsumer-Driven Contractsなどのテンプレートは、多くの場合、マイクロサービスで使用され、独立して進化させることができます。 ビルドの一部として消費者主導の契約を確認することで、サービスが正しく機能することに対する信頼が高まります。 このアプローチを使用して契約を検証するオーストラリアのチームを知っています。 これはアセンブリプロセスの一部になりました。サービスは、契約の要件を満たす瞬間までしか収集されません。これは、YAGNIジレンマを回避するエレガントな方法です。



おそらく、分散管理の実践における最高点は、Amazonで普及している方法でしょう。 チームは、24時間365日のサポートを含む、開発するソフトウェアのすべての側面に責任を負います。 このような責任レベルの逸脱は間違いなく標準ではありませんが、ますます多くの企業が責任を開発チームに移管していることがわかります。 Netflixはこれを実践している別の会社です。 午前3時に目覚めることは、記述されたコードの品質に大きな注意を払うための非常に強力なインセンティブです。

マイクロサービスとSOA

マイクロサービスについて話すとき、通常、これが10年前に見た通常のサービス指向アーキテクチャ（SOA）であるかどうかについて疑問が生じます。 この問題には音があります マイクロサービススタイルは、SOAの支持者が推進しているものと非常に似ています。 ただし、問題は、 SOAという用語の意味が多すぎることであり、原則として、人々が「SOA」と呼ぶものは、通常、統合に使用されるESBに過度に焦点を当てているため、ここで説明するスタイルとは大きく異なりますモノリシックアプリケーション。



特に、失敗したSOA実装が非常に多く見られました（ESBの背後に複雑さを隠す傾向から始まり、数年続いて失敗したイニシアチブで終わり、数百万ドルの費用がかかり、何の利益ももたらされませんでした）。



もちろん、マイクロサービスで使用されるプラクティスの多くは、大規模な組織でサービスを統合した経験に基づいています。 トレラントリーダーテンプレートはその一例です。 別の例-シンプルなプロトコルの使用-は、一元化された標準に対する反応として生まれました。その複雑さは息をのむようなものです。



これらのSOAの問題により、一部のマイクロサービスの支持者は「SOA」という用語を放棄しましたが、他の人はマイクロサービスをSOAの形式、またはおそらくSOAの正しい実装と見なしています。 いずれにせよ、SOAの意味が異なるということは、このアーキテクチャスタイルを別の用語で表すことが有用であることを意味します。

多くの言語、多くの可能性。

JVMプラットフォームの成長は、単一のプラットフォームで言語を混合する最新の例の1つです。 高レベルの抽象化の使用を利用するために高レベルの言語に切り替えることは、何十年もの間一般的な慣行でした。 高性能コードを記述するためのハードウェアへの移行と同じです。



ただし、多くのモノリシックアプリケーションでは、このレベルのパフォーマンス最適化とDSLに似た言語の高レベルの機能は必要ありません。 代わりに、モノリスは通常単一の言語を使用し、使用されるテクノロジーの量を制限する傾向があります。

分散データ管理

分散データ管理はさまざまな方法で表示されます。 最も抽象的な意味では、これは異なるシステムの世界の概念モデルが異なることを意味します。 これは、大規模なエンタープライズアプリケーションのさまざまな部分を統合するときに発生する一般的な問題です。営業担当者間の「顧客」の概念に対する視点は、テクニカルサポートチームの視点とは異なります。 「クライアント」の一部の属性は、営業担当者のコンテキストに存在する場合がありますが、技術サポートのコンテキストにはない場合があります。 さらに、同じ名前の属性には異なる意味があります。



この問題は、異なるアプリケーションだけでなく、特にこのアプリケーションが個別のコンポーネントに分割されている場合に、単一のアプリケーションのフレームワーク内でも発生します。 Domain-Driven Design（DDD）のBounded Contextは 、この問題をうまく解決します。 DDDは、複雑なサブジェクト領域をいくつかのコンテキストに分割し、それらの間の関係を構築することを提案しています。 このプロセスは、モノリシックアーキテクチャとマイクロサービスアーキテクチャの両方に役立ちますが、コンテキストの境界を明確にして維持するのに役立つサービスとコンテキストの間には自然なつながりがあります。



ドメインモデリングに関する意思決定の分散化に加えて、マイクロサービスはデータストレージメソッドの分散化にも貢献します。 モノリシックアプリケーションはデータを格納するために単一のデータベースを使用する傾向がありますが、企業は多くの場合、アプリケーションのセット全体に対して単一のデータベースを使用することを好みます。 このような決定は、通常、データベースライセンスモデルによってトリガーされます。 マイクロサービスは、各サービスが独自のデータベースを管理できるようにすることを好みます。つまり、会社の共通DBMSの個別のインスタンスを作成し、非標準タイプのデータベースを使用する方法です。 このアプローチはPolyglot Persistenceと呼ばれます。 モノリシックアプリケーションでPolyglot Persistenceを使用することもできますが、このアプローチはマイクロサービスでより一般的です。







マイクロサービス間のデータ責任の分散化は、そのデータの変更方法に影響を与えます。 データを変更する一般的なアプローチは、トランザクションを使用して、複数のリソース間でデータを変更するときに一貫性を確保することです。 このアプローチは、モノリシックアプリケーションでよく使用されます。



このようなトランザクションの使用は一貫性を保証しますが、重要な時間的結合をもたらし、その結果、多くのサービスを操作する際に問題を引き起こします。 分散トランザクションの実装は非常に困難であり、その結果、マイクロサービスアーキテクチャは、 トランザクションを使用せずにサービス間の調整を特に重視します。一貫性は最終的な一貫性のみであり、発生する問題は補償操作によって解決されることを明示的に示します。



この方法で不整合を管理することは、多くの開発チームにとって新たな課題ですが、これは多くの場合、ビジネスプラクティスと一致しています。 多くの場合、企業はユーザーのアクションに可能な限り迅速に対応しようとし、エラーが発生した場合にユーザーのアクションをキャンセルできるプロセスを用意しています。 一貫性を保証するシナリオを使用する場合、エラーを修正するコストがビジネスを失うコストよりも少ない限り、妥協は価値があります。

標準、戦闘で実証済み、対標準

マイクロサービスアーキテクチャを使用するチームは、システムアーキテクトのチームによって設定される厳格な標準を避ける傾向があります。 また、HTTPやATOMなどのオープンスタンダードを使用し、推進する傾向もあります。



主な違いは、これらの標準の開発方法と実装方法です。 IETFのようなグループが管理する標準は、成功したオープンソースプロジェクトにいくつかの実装がある場合にのみ標準になります。



これは、実際の開発の経験がほとんどないか、ベンダーからの影響が大きすぎる人々のグループによって開発されることが多い企業世界の標準とは異なります。

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

インフラストラクチャ自動化技術は、過去数年間で大きく進化しました。 クラウド全般、特にAWSの進化により、マイクロサービスの構築、展開、運用の運用上の複雑さが軽減されました。



マイクロサービスアーキテクチャを使用する多くの製品とシステムは、 継続的デリバリーと継続的インテグレーションの豊富な経験を持つチームによって構築されています。 この方法でアプリケーションを構築するチームは、インフラストラクチャ自動化技術を幅広く利用しています。 これを下の図に示します。







この記事は継続的配信に関するものではないため、重要な点にのみ注意を払います。 アプリケーションが機能していることをできる限り信頼したいので、多くの自動テストを実行します。自動テストの各ステップを完了するために、アプリケーションは、自動展開を使用する個別の環境に展開されます。



モノリスの展開プロセスの自動化に時間とお金を費やした後、アプリケーション（サービス）をより多く展開するのはそれほど難しくありません。継続的デリバリーの目標の1つはデプロイメントを退屈にすることであるため、1つまたは3つのアプリケーションは実際には重要ではないことを思い出してください。



チームが集中的なインフラストラクチャの自動化を使用する別の領域は、実稼働環境でのマイクロサービスの管理です。前述のように、モノリシックアプリケーションでの展開プロセスとマイクロサービスのプロセスとの違いはほとんどありませんが、その展開方法は大きく異なります。







展開プロセスの自動化の副作用の1つは、開発者と管理者（運用担当者）を支援する便利なツールの作成です。コードの管理、シンプルなサービスの展開、監視、ログ記録のためのツールは現在非常に一般的です。おそらくネット上で見つけることができる最良の例は、Netflixのオープンソースツールのセットですが、Dropwizardのような他のツールもあります かなり集中的に使用します。

失敗の設計

サービスをコンポーネントとして使用することの結果は、個々のサービスが失敗したときに動作できるようにアプリケーションを設計する必要があります。利用できないため、サービスへのアクセスが機能しない場合があります。クライアントは可能な限り寛容に応答する必要があります。これは、モノリスと比較してマイクロサービスの欠点です。なぜなら、これにより、アプリケーションがさらに複雑になります。その結果、マイクロサービスチームは、サービスにアクセスできないことがユーザーエクスペリエンスにどのように影響するかを常に考えています。NetflixのSimian Armyは、稼働中のサービスやデータセンターの障害を人工的に（シミュレートして）アプリケーションと監視サービスのフォールトトレランスをテストします。



このタイプの実稼働環境での自動テストにより、管理者にかかるストレスをシミュレートでき、週末に仕事につながることがよくあります。モノリシックなアプリケーション向けに洗練された監視システムを開発することはできませんが、これはあまり一般的ではないということは言いたくありません。



サービスはいつでも失敗する可能性があるため、問題を迅速に検出し、可能であればサービスを自動的に復元できることが非常に重要です。マイクロサービスアーキテクチャは、アプリケーションのリアルタイム監視、技術要素（データベースが受信する1秒あたりのリクエスト数など）とビジネスメトリック（アプリケーションが1分あたりに受信する注文数など）の両方の検証に重点を置いています。セマンティックモニタリングは、問題の状況に対する早期警告システムを提供し、開発チームが早期に問題の調査に関与できるようにします。



これは、マイクロサービスアーキテクチャの場合に特に重要です。個別のプロセスに分割し、イベントを介して通信する予期しない動作につながります。監視は、この動作の不要なケースを検出して迅速に解決するために重要です。



モノリスは、マイクロサービスと同じ方法で構築できます。実際、それがどのように構築されるべきかです。違いは、異なるプロセスで実行されているサービスが相互に正しく相互作用しなくなったときを知ることがはるかに重要であることです。同じプロセスにあるライブラリの場合、この種の透過性はあまり有用ではありません。



通常、マイクロサービスチームは、個々のサービスごとに高度な監視およびログシステムを作成します。例は、サービスのステータス（オンライン/オフライン）とさまざまな技術的およびビジネスメトリックを示すコンソールです：現在の帯域幅、リクエスト処理時間など。

同期呼び出しは危険と見なされます

サービス間で同期呼び出しのセットがあるたびに、ダウンタイムの乗算の影響に直面します。システムのダウンタイムは、個々のシステムコンポーネントのダウンタイムの積になります。選択肢は、呼び出しを非同期にするか、ダウンタイムを我慢するかです。たとえば、www.guardian.co.ukで、開発者は単純なルールを導入しました-ユーザー要求ごとに1つの同期呼び出し。Netflixでは、一般に、すべてのAPIは非同期です。

進化的デザイン

マイクロサービスアーキテクチャを実践している人は、通常、進化的な設計で多くの作業を行い、開発プロセス自体を遅くすることなく、開発者がアプリケーションの変更（リファクタリング）を制御できるさらなる機会としてサービスの分解を見ています。変更を制御することは、必ずしも変更を減らすことを意味しません。正しいアプローチとツールセットを使用すると、頻繁に、迅速に、適切に制御された変更を行うことができます。



アプリケーションをコンポーネントに分割しようとするたびに、アプリケーションの分割方法を決定する必要があります。アプリケーションを最適に「チョップ」する方法を示す原則はありますか？コンポーネントの重要な特性は、その置換または更新の独立性です。これは、コンポーネントと対話するコンポーネントに影響を与えることなく、ゼロから書き直すことができる状況が存在することを意味します。多くの開発チームはさらに先へ進みます。長期的には多くのサービスは進化せず、単に埋め立て地に投入されることを明確に計画しています。



Guardian Webサイトは、モノリスとして設計および構築されたアプリケーションの良い例ですが、その後マイクロサービスに進化しました。サイトのコアはまだモノリスですが、モノリスAPIを使用するマイクロサービスを構築することにより、新しい機能が追加されています。このアプローチは、基本的に一時的な機能に特に役立ちます。そのような機能の例は、スポーツイベントをカバーするための専用ページです。サイトのこのような部分は、高速プログラミング言語を使用して迅速に組み立て、イベントが終了するとすぐに削除できます。金融システムでも同様のアプローチが見られました。新しいサービスが開かれた市場機会に追加され、作成後数か月または数週間で削除されました。



このような互換性の強調は、モジュール設計のより一般的な原則の特殊なケースであり、モジュール性は機能の変化率によって決定されるという事実から成ります。一緒に変化するものは、1つのモジュールに保存する必要があります。めったに変更されないシステムの部分は、急速に進化するサービスでは検出されません。 2つのサービスを定期的に一緒に変更する場合は、それらを結合する可能性について考えてください。



コンポーネントをサービスに入れると、詳細なリリース計画の可能性が追加されます。モノリスでは、すべての変更にはアプリケーション全体の再構築とデプロイが必要です。マイクロサービスでは、変更されたサービスのみをデプロイ（再デプロイ）する必要があります。これにより、リリースプロセスが簡素化および高速化されます。このアプローチの欠点は、1つのサービスの変更により、アクセスしているサービスが中断されるという事実を心配する必要があることです。統合に対する従来のアプローチは、バージョニングを通じてそのような問題を解決することですが、マイクロサービスは絶対に必要な場合にのみバージョニングを使用することを好みます。可能な限り隣接サービスへの変更を許容するようにサービスを設計することにより、バージョン管理を回避できます。

マイクロサービスは未来ですか？

この記事を書くときの主な目標は、マイクロサービスアーキテクチャの基本的な考え方と原理を説明することでした。マイクロサービススタイルは、エンタープライズアプリケーションで考慮する価値のある重要なアイデアであると考えています。少し前まで、このスタイルを使用していくつかのシステムを開発し、このアプローチを使用している他のいくつかのチームを知っています。



私たちが知っているこのアーキテクチャスタイルの先駆者は、Amazon、Netflix、The Guardian、英国政府デジタルサービス、realestate.com.au、Forward、comparethemarket.comなどの企業です。 2013年の会議には、Travis CIなど、マイクロサービスとして分類できる方向に進む企業の例がたくさんありました。さらに、マイクロサービスと呼ばれるものを長い間使用しているが、この名前を使用していない多くの組織があります。 （多くの場合、これはSOAと呼ばれますが、既に述べたように、SOAは多くの異なる、しばしば矛盾する形式で提供されます。）



このようなポジティブな経験にもかかわらず、マイクロサービスがソフトウェア設計の未来であるとは主張していません。そして、モノリシックアーキテクチャを使用した経験と比較して、私たちの経験は依然として非常に肯定的ですが、そのような判断を下すのに十分な時間が経過していないという事実に意識的にアプローチします。



多くの場合、アーキテクチャ上の決定の実際の結果は、それらを作成してからわずか数年後に目に見えるようになります。モジュール化を強く望んでいる優秀なチームが、数年後に完全に「腐敗」するモノリシックアプリケーションを開発したプロジェクトを見ました。多くの人々は、マイクロサービスの場合、そのような結果はあまり起こりそうにないと考えています。サービス間の境界は物理的であり、破ることが困難です。ただし、このアプローチを使用して十分な数の実績のあるシステムを確認するまで、マイクロサービスアーキテクチャの成熟度を確認することはできません。



誰かがマイクロサービスアーキテクチャを十分に成熟していないと考える理由は間違いなくあります。コンポーネントシステムを構築する試みが成功するかどうかは、コンポーネントがアプリケーションにどの程度適合するかによって異なります。コンポーネントの境界がどこにあるべきかを正確に理解することは困難です。進化的設計は、正しい境界線を描くことの難しさと、それらを簡単に変更することの重要性を認識しています。コンポーネントがリモートで相互に通信するサービスである場合、リファクタリングは同じプロセスで動作するライブラリよりもはるかに困難です。サービスの境界間でコードを移動し、変化するインターフェースを異なるチーム間で調整する必要があります。下位互換性をサポートするには、レイヤーを追加する必要があります。これはすべて、テストプロセスを複雑にします。



別の問題は、コンポーネントが十分にきれいに選択されていない場合、コンポーネントからコンポーネント間の接続に複雑さが移るということです。個々のコンポーネントが単純であるという誤った感覚が生まれますが、すべての複雑さは制御がより困難な場所にあります。



チームレベルの要因もあります。一般に、新しい技術はより強力なチームに受け入れられますが、より強力なチームにとってより効果的な技術は、必ずしも力の弱い開発チーム向けの技術ではありません。弱いチームが複雑で失敗したモノリシックアプリケーションアーキテクチャを開発した多くのケースを見てきましたが、マイクロサービスアーキテクチャの場合にこれがどのように終わるかを見るまでには時間がかかります。弱いチームは常に弱いシステムを作成します。マイクロサービスがこの状況を改善するのか悪化させるのかを言うのは難しいです。



私たちが聞いた合理的な議論の1つは、マイクロサービスアーキテクチャで開発を開始すべきではないということです。モノリスから始めて、モジュール化して、モノリスが問題になったらマイクロサービスに分割します。 （それでも、このアドバイスは理想的ではありません。プロセス内の通信のための優れたインターフェースは、サービス間メッセージの場合はそうではありません。）



したがって、合理的な楽観でこれを書きます。この時点で、これが価値のある開発パスであることを認識するのに十分なマイクロサービススタイルの例を見てきました。これがどこにつながるのかを確実に言うことはできませんが、ソフトウェア開発の特徴の1つは、現時点でアクセスできることが多い不完全な情報に基づいて決定を下す必要があることです。



元の記事へのリンク：Microservices