マイクロサービス

サービスによるコンポーネント化

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

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

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

コンポーネントとしてサービス（ライブラリではなく）を使用する主な理由の1つは、サービスが独立してデプロイ可能であることです。単一プロセス内の複数のライブラリで構成されるアプリケーション[4]がある場合、単一コンポーネントへの変更を行うと、アプリケーション全体を再デプロイする必要があります。ただし、そのアプリケーションが複数のサービスに分割されている場合、多くの単一サービスの変更では、そのサービスのみを再デプロイするだけで済みます。それは絶対的なものではなく、一部の変更はサービスインターフェースを変更するため、ある程度の調整が必要になりますが、優れたマイクロサービスアーキテクチャの目的は、凝集性の高いサービス境界とサービスコントラクトの進化メカニズムを通じてこれらを最小限に抑えることです。

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

このようにサービスを使用することには欠点があります。リモートコールはインプロセス קול よりもコストがかかり、そのためリモートAPIはより粗粒度である必要があり、多くの場合、使用するのがより面倒です。コンポーネント間の責務の割り当てを変更する必要がある場合、プロセス境界を越えていると、そのような動作の移動はより困難になります。

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

ビジネス機能を中心とした組織化

大規模なアプリケーションを部分に分割する場合、多くの場合、管理はテクノロジーレイヤーに焦点を当て、UIチーム、サーバー側ロジックチーム、およびデータベースチームにつながります。チームがこのように分離されている場合、単純な変更でさえ、チーム間のプロジェクトに時間と予算の承認が必要になる可能性があります。賢いチームはこれを最適化し、2つの悪のうち小さい方を選びます。つまり、ロジックをアクセスできるアプリケーションに強制的に適用します。言い換えれば、どこにでもロジックがあります。これは、コンウェイの法則が実際に機能している例です。

システム（広く定義されている）を設計する組織は、その構造が組織のコミュニケーション構造のコピーである設計を生み出します。

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

図2：コンウェイの法則の実践

マイクロサービスの分割アプローチは異なり、ビジネス機能を中心に組織化されたサービスに分割されます。このようなサービスは、ユーザーインターフェース、永続ストレージ、および外部のコラボレーションを含む、そのビジネス分野のソフトウェアのブロードスタック実装を採用しています。その結果、チームは、ユーザーエクスペリエンス、データベース、プロジェクト管理など、開発に必要なすべてのスキルを含む、機能横断型になります。

図3: チーム境界によって強化されたサービス境界

このような組織構成をとっている企業の一例として、www.comparethemarket.comがあります。クロスファンクショナルチームが各製品の構築と運用を担当し、各製品はメッセージバスを介して通信する複数の個別のサービスに分割されています。

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

プロジェクトではなくプロダクト

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

マイクロサービスの支持者はこのモデルを避け、チームが製品のライフサイクル全体を所有するという考え方を好みます。この考え方の一般的なインスピレーションは、Amazonの「あなたが構築し、あなたが運用する」という考え方で、開発チームが本番環境でのソフトウェアの動作に全責任を負います。これにより、開発者はソフトウェアの本番環境での動作を日々把握し、ユーザーとの接触を増やすことができます。なぜなら、少なくともサポート負担の一部を負わなければならないからです。

製品中心の考え方は、ビジネス機能との関連付けと結びついています。ソフトウェアを完成させるべき機能の集合体と見なすのではなく、ソフトウェアがユーザーのビジネス機能の強化をどのように支援できるかという継続的な関係があります。

モノリシックアプリケーションでも同じアプローチをとれない理由はありませんが、サービスの粒度が小さければ、サービス開発者とユーザーとの個人的な関係を築きやすくなります。

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

異なるプロセス間の通信構造を構築する際に、通信メカニズム自体に高度な機能を持たせることを重視した製品やアプローチを数多く見てきました。その好例がエンタープライズサービスバス（ESB）です。ESB製品には、メッセージルーティング、コレオグラフィー、変換、ビジネスルールの適用のための高度な機能が搭載されていることがよくあります。

マイクロサービスコミュニティは、別のアプローチを支持しています。それは、スマートエンドポイントとダムパイプです。マイクロサービスから構築されたアプリケーションは、可能な限り疎結合で凝集性が高くなることを目指しています。独自のドメインロジックを所有し、従来のUnixのようにフィルターとして機能します。リクエストを受信し、必要に応じてロジックを適用して、レスポンスを生成します。これらは、WS-ChoreographyやBPELなどの複雑なプロトコルではなく、単純なRESTishプロトコルを使用して、または中央ツールによるオーケストレーションではなく、コレオグラフィーされます。

最も一般的に使用される2つのプロトコルは、リソースAPIを使用したHTTPリクエストレスポンスと軽量メッセージング[7]です。最初のものの最良の表現は

Webの一部であれ、Webの背後ではない

-- Ian Robinson

マイクロサービスチームは、ワールドワイドウェブ（そして、大部分はUnix）が構築されている原則とプロトコルを使用します。よく使用されるリソースは、開発者や運用担当者の労力をほとんどかけずにキャッシュできます。

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

モノリスでは、コンポーネントはインプロセスで実行され、それらの間の通信はメソッド呼び出しまたは関数呼び出しを介して行われます。モノリスをマイクロサービスに変更する際の最大の問題は、通信パターンの変更にあります。インメモリメソッド呼び出しからRPCへの単純な変換は、パフォーマンスの低いチャットのような通信につながります。代わりに、きめ細かい通信を、より粗いアプローチに置き換える必要があります。

分散ガバナンス

中央集権的なガバナンスの結果の1つは、単一のテクノロジープラットフォームで標準化される傾向です。経験から、このアプローチは制約的であることがわかっています。すべての問題が釘ではなく、すべてのソリューションがハンマーではありません。私たちは、仕事に適したツールを使用することを好みます。モノリシックアプリケーションはある程度異なる言語を利用できますが、それはそれほど一般的ではありません。

モノリスのコンポーネントをサービスに分割すると、それぞれを構築する際に選択肢が生まれます。Node.jsを使用してシンプルなレポートページを作成したいですか？どうぞ。特に厄介なニアリアルタイムコンポーネントにC ++を使用しますか？結構です。1つのコンポーネントの読み取り動作により適した異なる種類のデータベースに交換したいですか？彼を再構築する技術があります。

もちろん、できるからといって、すべきとは限りません。しかし、このようにシステムを分割することで、選択肢が生まれます。

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

Netflixはこの哲学に従っている組織の良い例です。便利で、とりわけ、実証済みのコードをライブラリとして共有することで、他の開発者は同様の問題を同様の方法で解決することを奨励しますが、必要に応じて異なるアプローチを選択することもできます。共有ライブラリは、データストレージ、プロセス間通信、そして以下で詳しく説明するように、インフラストラクチャの自動化という共通の問題に焦点を当てる傾向があります。

マイクロサービスコミュニティにとって、オーバーヘッドは特に魅力的ではありません。それは、コミュニティがサービス契約を重視していないということではありません。まったく逆で、サービス契約が多いためです。彼らがそれらの契約を管理する異なる方法を探しているだけです。寛容なリーダーやコンシューマ主導契約のようなパターンは、マイクロサービスによく適用されます。これらは、サービス契約が独立して進化するのを助けます。ビルドの一部としてコンシューマ主導契約を実行すると、信頼性が高まり、サービスが機能しているかどうかに関する迅速なフィードバックが得られます。実際、オーストラリアのチームは、コンシューマ主導契約で新しいサービスの構築を推進していることを知っています。彼らは、サービスの契約を定義できるシンプルなツールを使用しています。これは、新しいサービスのコードが記述される前でさえ、自動ビルドの一部になります。サービスは、契約を満たすところまでしか構築されません。これは、新しいソフトウェアを構築する際の「YAGNI」[8]のジレンマを回避するための洗練されたアプローチです。これらのテクニックと、それらを取り巻くツールは、サービス間の時間的結合を減らすことによって、中央契約管理の必要性を制限します。

分散ガバナンスの頂点と言えるのは、Amazonで広まった「構築と運用」の精神でしょう。チームは、ソフトウェアの24時間365日の運用を含む、構築するソフトウェアのあらゆる側面に責任を負います。このレベルの責任の委譲は、決して一般的ではありませんが、開発チームに責任を押し付ける企業がますます増えています。Netflixもこの精神を採用した組織の1つです[10]。毎晩午前3時にページャーで起こされることは、コードを書く際に品質に集中するための強力な動機となります。これらのアイデアは、従来の中央集権的なガバナンスモデルとは、正反対のものです。

分散データ管理

データ管理の分散化は、さまざまな形で現れます。最も抽象的なレベルでは、それは世界の概念モデルがシステム間で異なることを意味します。これは、大企業全体を統合する際に共通の問題であり、顧客に対する営業部門の視点とサポート部門の視点は異なります。営業部門の視点では顧客と呼ばれるものが、サポート部門の視点では全く表示されない場合があります。表示される場合でも、属性が異なったり、（さらに悪いことに）共通の属性が微妙に異なる意味を持つ場合があります。

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

マイクロサービスは、概念モデルに関する意思決定を分散化するだけでなく、データストレージの意思決定も分散化します。モノリシックアプリケーションは永続データに単一の論理データベースを好む一方で、企業は多くの場合、さまざまなアプリケーションにわたって単一のデータベースを好みます。これらの決定の多くは、ベンダーのライセンスに関する商用モデルによって推進されています。マイクロサービスは、各サービスが独自のデータベース（同じデータベーステクノロジの異なるインスタンス、またはまったく異なるデータベースシステム）を管理できるようにすることを好みます。これは多言語永続化と呼ばれるアプローチです。モノリスで多言語永続性を使用することもできますが、マイクロサービスではより頻繁に使用されます。

マイクロサービス全体でデータの責任を分散化すると、更新の管理に影響が及びます。更新を処理するための一般的なアプローチは、トランザクションを使用して、複数のリソースを更新する際の一貫性を保証することでした。このアプローチは、モノリス内でよく使用されます。

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

このように不整合を管理することを選択することは、多くの開発チームにとって新たな課題ですが、ビジネス慣行と一致することがよくあります。多くの場合、企業は需要に迅速に対応するために、ある程度の不整合を許容し、間違いに対処するためにある種の取り消しプロセスを備えています。ミスを修正するコストが、より高い一貫性の下でビジネスを失うコストよりも低い限り、トレードオフはそれだけの価値があります。

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

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

マイクロサービスで構築されている多くの製品やシステムは、継続的デリバリーとその前身である継続的インテグレーションの豊富な経験を持つチームによって構築されています。このようにソフトウェアを構築するチームは、インフラストラクチャの自動化技術を幅広く活用しています。これは、以下に示すビルドパイプラインに示されています。

図5：基本的なビルドパイプライン

これは継続的デリバリーに関する記事ではないため、ここでは重要な機能をいくつか紹介します。ソフトウェアが機能しているという確信をできるだけ高めるために、多くの自動テストを実行します。動作するソフトウェアをパイプラインの「上」にプロモートするということは、新しい環境ごとに展開を自動化することを意味します。

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

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

図6：モジュールの展開はしばしば異なります

障害を前提とした設計

サービスをコンポーネントとして使用することの帰結は、サービスの障害を許容できるようにアプリケーションを設計する必要があるということです。サプライヤが利用できないためにサービスコールが失敗する可能性があり、クライアントはできるだけ適切に対応する必要があります。これは、処理するための追加の複雑さが生じるため、モノリシック設計と比較して不利な点です。その結果、マイクロサービスチームは、サービスの障害がユーザーエクスペリエンスにどのように影響するかを常に考えています。NetflixのSimian Armyは、勤務時間中にサービスやデータセンターの障害を誘発し、アプリケーションの回復力と監視の両方をテストします。

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

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

マイクロサービスアーキテクチャでは、振り付けとイベントコラボレーションが優先されるため、創発的な動作が発生するため、これは特に重要です。多くの専門家が予期せぬ創発の価値を賞賛していますが、真実は、創発的な行動が時として悪いことでありうるということです。悪い創発的行動を迅速に発見して修正できるように、監視が不可欠です。

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

マイクロサービスチームは、稼働状況とさまざまな運用およびビジネス関連のメトリックを示すダッシュボードなど、個々のサービスごとに高度な監視とログ記録のセットアップを期待します。サーキットブレーカーのステータス、現在のスループット、レイテンシに関する詳細は、私たちが現場でよく遭遇する他の例です。

進化型設計

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

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

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

この交換可能性の重視は、より一般的なモジュール設計の原則の特殊なケースであり、変更のパターンを通じてモジュール性を推進することです[13]。同時に変更されるものは同じモジュールにまとめておく必要があります。めったに変更されないシステム部分は、現在多くの変更が行われているサービスとは別のサービスに配置する必要があります。 2つのサービスを繰り返し一緒に変更していることに気付いた場合は、それらをマージする必要があるという兆候です。

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