MicroservicesVsSOA
Comparing Architecture Characteristics †
序文 †
- コンポーネントとはよく定義されたインタフェースを持つソフトウェアの単位やよく定義されたロールや責務のセットを意味する。
- コンポーネントはアーキテクチャのブロックを形成する。
- サービスベースのアーキテクチャでは、それらの構成ブロックは通常サービス（またはサービスコンポーネント）として参照される。
- 開発者コンポーネントにつけたラベルに関係なく、アーキテクチャを作成する際にコンポーネントがどう共有され、どう通信し、どう特定のビジネス要件を満たすか、そして、リモートのサービスコンシューマからどうアクセスされるか、開発者は定義する必要が出てくるだろう。
- これらすべてを定義することはいつでも簡単なタスクではない。
- これはアーキテクチャパターンがどこから来るかに関係している。
- それぞれのアーキテクチャパターンは、コンポーネントの関連や、通信、ビジネス要件を満たすためにそれぞれがどう動作する、といった形状や一般的な特徴が定義されたユニークなトポロジーを持っている。
- アーキテクチャパターンのトポロジーを解析することで、開発者はパターンが開発者にとって適切な選択肢の場合は良いデザインができるだろう。
- この章では、マイクロサービスとSOAの全体的なアーキテクチャとアーキテクチャパターンの特徴の違いについて記載する。
- 特に筆者は、2つのパターンのサービスコンポーネントの共有、サービスコンポーネントの通信、そしてどうリモートサービスコンポーネントが一般的にアクセスされるかという点について注意を払おうと思う。
- 筆者はまたSOAアーキテクチャに見られるメッセージングのミドルウェアとマイクロサービスアーキテクチャパターンに見られるAPIレイヤーの違いについて考えることにする。
Component Sharing †
- マイクロサービスとSOAはコンポーネントの共有の点でもともと異なっている。
- SOAは「なるべく可能なら共有しよう」というコンセプトで構成されているのに対し、マイクロサービスは「なるべく可能なら共有しないようにしよう」というコンセプトで構成されている。
- このセクションではマイクロサービスとSOAが参照する2つのコンセプトの違いについて説明する。
- コンポーネントの共有はSOAの核となる特徴の一つでもある。
- 事実、コンポーネントの共有はエンタープライズサービスではそれが全てとなる。
- 例として、大規模な小売企業を考えてみると、図3-1のようになり、多くのアプリケーショがOrderの処理に関連づけられている。顧客管理システム、ウェアハウス管理システム、注文出荷システムなどがそれに該当する。
- それらすべてのシステムがそれらのOrderサービスのバージョンを持っている。
- この例では、Orderを更新するための処理に特別なビジネスロジックが必要とされていると仮定してみよう。
- これが意味するのは、特別な処理ロジックはエンタープライズ環境化では様々なアプリケーションから複製される必要があり、それらのアプリケーションの間で追加的な確認と調整が必要ということだ。
- 図3-1が知らせてくれるその他の事項としてはこの例のそれぞれのシステムが自分自身のデータベースを持つので、それぞれのシステムは完全に異なるOrderの実装を持っていることだ。
- SOAはこの問題に対して、エンタープライズレベルの共有サービス（エンタープライズサービス）を通して、解決しようとする。
- 筆者が提示した小売業の例を続けると、図3-2に表せるように、中央に共有されるOrderエンタープライズサービスが作成されると、すべてのアプリケーションはOrderを更新するのに関連する同じ処理ロジックを共有することができる。
- 図3-2が知らせてくれる事項として、Orderサービスは今共有されているが、まだ3つの異なるデータベース（それが関連づけられたそれぞれのシステム）にアクセスをしている。
- これはSOAでは非常に重要なコンセプトで、「なるべく可能なら共有しよう」というアーキテクチャスタイルで使用される。
- Orderサービスはそれぞれのシステムのための注文データを取得や更新をするデータベースがどれか賢く知っているのだ。
- 言い換えれば、注文は一つのデータベースで表現されるのではなく、3つのデータベースの組み合わせによって表現される。
- 「なるべく可能なら共有しよう」というアーキテクチャのコンセプトはビジネス機能の複製に関連づけて問題を解決するが、それは大抵コンポーネントの密結合と変更に関連する全体的なリスクを増大させる傾向がある。
- 例として、図3-2のOrderサービスを変更しようとしたとしよう。
- Orderサービスはエンタープライズサービスで会社全体からアクセスされるので、全体のサービスが利用する可能性があるテストの実施や、変更が他のエンタープライズ領域に影響しないことを確認することが困難だ。
- マイクロサービスアーキテクチャは「なるべく可能なら共有しないようにしよう」というコンセプトで構成されていて、コンセプトはドメイン駆動設計のBounded Contextの影響を受けている。
- アーキテクチャとして、Bounded Contextはコンポーネント（またはサービス）の結合を参照し、それは最小の依存関係の一つの単位としてのデータと関連づけられている。
- サービスコンポーネントは根本的に自分自身を含み、よく定義されたインタフェースとコントラクトを表す方法によってデザインされている。
- 現実的には、マイクロサービスアーキテクチャでも共有されるサービスはあるのだが、（例として、インフラストラクチャサービス）
- それでもSOAがコンポーネントの共有を最大化しようとするのに対し、マイクロサービスアーキテクチャはBounded Contextによって共有を最小化しようと試みる。
- Bounded Contextや依存関係の最小化を成し遂げるひとつの方法の最たる例が、DRY法則の侵害や、トータルの独立を図るためにサービスの共通の機能を複製がそれにあたる。
- 他の点では、比較的静的なモジュールをサービスコンポーネントがコンパイル時もしくは実行時に使用可能となるように共有ライブラリとしてコンパイルすることがあたる。
- 筆者の友人・同僚のNeal Fordはこの違いについてマイクロサービスアーキテクチャは2つを除いて無共有アーキテクチャだと言う。サービスをどう他と統合するという点とエンジニアリングの一貫性を保証するためのインフラストラクチャの点を除いて。
- 多くのアドバンテージがBounded Contextコンセプトに影響されている。
- サービスのメンテナンスはもっと楽になる。なぜなら依存するモジュールがなく、サービスは変更や他のサービスとの独立を進めることができるから。
- デプロイもまた簡単になる。なぜなら小さなコードのデプロイで済み、一つのモジュールかサービスの変更がアプリケーションのほかの部分に影響するリスクを減らせるから。
- これはサービス変更に基づく影響を抑えたもっと堅牢なアプリケーションを作成することになる。
Service Orchestration and Choreography †
- サービスオーケストレーションとサービスコレオグラフィーの違いはいつも明確ではなかったりする。
- このセクションではオーケストレーションとコレオグラフィーの違いとマイクロサービスとSOAの両方でサービス間通信がどう利用されるか述べようと思う。
- サービスオーケストレーションは複数のサービスの調整に中央主権的な仲介者をサービスコンシューマかインテグレーションハブ（Mule, Camel, Spring Integration）を通すことを意味する。
- この仕組みは図3-3のように表され、サービスオーケストレーションのコンセプトを表している。
- サービスオーケストレーションのことを簡単に表すなら、オーケストラを考えてみると良い。
- 異なる楽器を異なるタイミングで演奏する音楽家達がいるが、彼らは中央にいる人物を通して全てを調整されている、そう指揮者だ。
- 同じく、サービスオーケストレーション上の中央集権的な仲介者のコンポーネントがオーケストラの指揮者のように振る舞い、ビジネストランザクションを完了するために、必要なサービスを呼び出すことの全てを調整する。
- サービスコレオグラフィーは複数のサービスの呼び出しを中央の仲介者なしに調整する。
- サービス間の通信はサービスコレオグラフィーの結合とともに利用されることもある。
- サービスコレオグラフィーでは、一つのサービスが他のサービスを呼び出し、呼び出された他のサービスがさらに他のサービスを呼び出すこともある。この動作をサービスチェインイングとも言う。このコンセプトは図3-4のように表せる。
- サービスコレオグラフィーを考える一つの方法として、ステージ上でのダンス集団を考えてみると良い。
- 全てのダンサーは他と同期を取りながら動き、誰もダンサーにどう動くか指示したりしない。
- ダンスは独立したダンサーが他と連携しながら、演技され、コンサートのように一人の指揮者で指揮されることは無い。
- マイクロサービスアーキテクチャはサービスオーケストレーションよりもサービスコレオグラフィーを支持する。
- 第一になぜならアーキテクチャのトポロジーは中央のミドルウェアコンポーネントを必要としないからだ。
- 図3-5が示すのはアーキテクチャ全体のトポロジが2つメジャーなコンポーネントでのみ成り立っていることだ。サービスコンポーネントと補助的なあまりインテリジェントでないAPI レイヤー。（筆者はAPI レイヤーとそのロールについて次のセクションで述べる）
- 実装面での観点から、読者は他のコンポーネント、例えばサービスレジストレーションや、探索コンポーネントやサービスモニタリングコンポーネントやデプロイマネージャーを持つこともあるだろうが、アーキテクチャとしてはそれらのコンポーネントはマイクロサービスアーキテクチャパターンのサービスの一部としてインフラストラクチャとして考えることになるだろう。
- なぜなら、マイクロサービスアーキテクチャは「可能ならなるべく共有しないようにしよう」アーキテクチャで、開発者はアーキテクチャ上のサービスのコレオグラフィーの量を最小化しようと試みるべきで、機能となるサービスとインフラストラクチャサービスの連携を制限することになる。
- 筆者が前章で述べた通り、もし機能サービス間でサービスのコレオグラフィーが多く必要とされる場合には、サービスの粒度がきめ細かすぎるのだ。
- マイクロサービスアーキテクチャ上のあまりに過剰なサービスのコレオグラフィーは高い遠心性の結合になることが多く、それは一つのビジネスリクエストを完了するために、一つのコンポーネントが他のコンポーネントに依存することになる。
- 例として図3-6を考えてみよう、これはOrderリクエストの処理に3つのサービスが必要となっていることを示している。validate order、 place orderとnotify customer。
- アーキテクチャとして、このビジネスリクエストは高い遠心性の結合を持っていて、アーキテクトは多くのマイクロサービスアーキテクチャ上で最小化するのに苦労することだろう。
- このタイプのサービスコレオグラフィー内のサービスの結合はパフォーマンスの低下とアプリケーションの堅牢さを奪う。
- 筆者が前章で述べた通り、サービスはマイクロサービスアーキテクチャ上で一般的にはリモートにあるので、それぞれのサービスはリモートアクセスプロトコルの通信と転送時間が原因でサービスコレオグラフィーを用いたサービスの調整しながら呼び出されるので、リクエストの対するレスポンスタイムが追加されるだろう。
- さらに一つのビジネスリクエストを複数のサービスを調整することで、コールチェーンの特定のサービスが利用不可能もしくはレスポンス不可能かもしれず、信頼性の低下と堅牢性を奪う可能性を増大させる。
- マイクロサービスアーキテクチャ内の機能的なサービス間のサービスコレオグラフィーの問題を解決する一つの策が、きめの細かいサービスを荒い粒度のサービスへ変えることだ。
- もしきめの細かいサービスが複数のサービス間で共有されていた場合は、これを分離したサービスのままにするか、サイズと機能の本質に依存させることになるだろう。
- DRYの法則の侵害やそれぞれの荒い粒度のサービスに共通の機能を追加することになるだろう。
- 図3-7は3つのきめの細かいサービスから荒い粒度のサービスへどう必要なサービスコレオグラフィーを取り除き、それによってサービスコレオグラフィーの3つの問題をどう解決するか描いている。
- 最初にこれはパフォーマンス全体を向上させる。なぜなら必要なリモートコールは少なくなるからだ。
- 第二に、これは全体の堅牢性を向上させる。なぜなら少ないサービスの可用性の問題しか起きないからだ。
- 最後に、これは全体の開発とメンテナンスを必要とされるリモートサービスコントラクトを減らすことで単純化する。
- SOAは「可能ならなるべく共有しよう」というアーキテクチャなので、ビジネスリクエストの処理にサービスオーケストレーションとサービスコレオグラフィーの両方に依存する。
- 図3-8で描いたようにSOAのメッセージングミドルウェアコンポーネントは一つのビジネスサービスリクエストに基づく複数のエンタープライズサービスを呼ぶことでサービスオーケストラレーションを管理している。
- これはエンタープライズサービスなので、サービスコレオグラフィーは特定のビジネスリクエストを達成するためにアプリケーションサービスやインフラストラクチャサービスを呼ぶことになるだろう。
- 図3-8はまたSOA内で起こるサービスコレオグラフィーのバリエーションを表している。
- 例として、エンタープライズサービスはアプリケーションサービスをコールする必要があるかもしれず、アプリケーションサービスはビジネス処理のためにインフラストラクチャサービスを呼び出す必要があるかもしれない。
- または、エンタープライズサービスはアプリケーションサービスかインフラストラクチャサービスを直接呼び出すのみか、ビジネスロジックはエンタープライズサービスに組み込まれていて、サービスコレオグラフィーを必要としないかもしれない。
- サービスオーケストレーションとサービスコレオグラフィーについてSOAとマイクロサービスの間の違いはパフォーマンスや開発、テスト、デプロイを含むアーキテクチャの特徴上の2つのパターン間の多くの差異について強調している。
- なぜならSOAは一般的に複数のサービス（またはサービスタイプ）に依存しひとつのビジネスリクエストを完了し、SOAで組まれたシステムはマイクロサービスよりも遅い傾向があり、開発・デプロイ・維持に労力がかかる。
- 事実、これらの要素はアーキテクトがSOAからもっとシンプルで能率的なマイクロサービスアーキテクチャパターンに移行する原因にもなっている。
担当者のつぶやき †
みんなの突っ込み †
