MicroservicesVsSOA/Comparing Architecture Capabilities

アーキテクチャ能力の比較(Comparing Architecture Capabilities) †

要約 †

詳細 †

最後の章では、アーキテクチャパターンが、どのように基本的なアーキテクチャ特性を定義することができるのかを示した。この章では、同じようなアプローチを取るが、アーキテクチャの特性の代わりに、パターンによって記述されるアーキテクチャの能力に焦点を当てる。アーキテクチャパターンをみることによって、アプリケーションが、スケーラブル性、メンテナンス性、拡張性、そして相対的に開発、テストそして開発が容易かどうかをいえる。この章では、私は三つの主要なアーキテクチャ能力である、サポートするアプリケーションのサイズ、統合することができるシステムやコンポーネントの種類、そして契約による分離をサポートするため能力、に着目してmicroservicesとSOAを比較する。

アプリケーションスコープ(Application Scope) †

アプリケーションスコープは、アーキテクチャパターンがサポートできるアプリケーション全体のサイズを示す。例えば、マイクロカーネルやパイプラインアーキテクチャなどのアーキテクチャパターンは、小規模なアプリケーションまたはサブシステムに適している。一方で、イベント駆動型アーキテクチャなどの他のパターンは、より大規模で複雑なアプリケーションのために適している。それならmicroservicesとSOA pattermsは、このスペクトルに沿うならどこに適合するのだろうか？

SOAは、多くの異種のアプリケーションやサービスへの統合を必要とする、大規模で複雑な、企業全体のシステムに適している。また、多くの共有コンポーネントを持つアプリケーション、特に企業全体で共有されているコンポーネントに適している。このようにSOAは、異種のシステム環境や共通サービス、顧客、権利、ポリシーといった、複数のアプリケーションやシステムによる、大規模な保険会社に良く適合する傾向がある。しかし、明確に定義された処理フローとそれほど多くない共有コンポーネント（有価証券売買など）のワークフローベースのアプリケーションでは、SOAのアーキテクチャパターンを使った実装は困難だ。小規模なWebベースのアプリケーションもSOAに適していない。なぜなら、多方面へのサービスの分類、抽象化レイヤ、およびメッセージング・ミドルウェア・コンポーネントを必要としないためだ。
microservicesパターンは、大規模な企業規模のシステムにではなく、小さく、仕切られたウェブベースのシステムに適している。メディエータ（メッセージング・ミドルウェア）の欠如は、大規模複雑なビジネスアプリケーション環境にとっては、不適切なものにさせる要因の一つだ。microservicesアーキテクチャパターンに適したアプリケーションの他の例は、ほとんど共有コンポーネントを持たず、非常に小さいの別個の動作に分けることができるものだ。
いくつかの例では、ビジネスの初期段階ではmicroservicesパターンが良好な初期アーキテクチャの選択であると思われるかもしれない。しかし、ビジネスの成長と成熟につれて、複雑なリクエスト変換、複雑なオーケストレーションおよび異種システムの統合などの機能が必要と思われるようになるかもしれない。そのような状況で、おそらく最初のmicroservicesアーキテクチャを置き換えて、SOAパターンに変更したくなるだろう。もちろん反対のこともある。大規模、複雑なSOAアーキテクチャで初めた後に、これらの強力な機能のすべてを必要としなかったことがわかることがある。この場合、アーキテクチャを簡素化するためにmicroservicesにSOAアーキテクチャかへ移行する可能性が高い。

異種間の相互運用性(Heterogeneous Interoperability) †

異種間の相互運用性は、異なるプログラミング言語やプラットフォームで実装されたシステムを統合する能力を指す。たとえば単一の複雑なビジネス要求は、単一の要求を処理するために、Javaベースのアプリケーション、.NETアプリケーション、顧客情報管理システム（CICS）COBOLプログラムの調整を必要とする状況があるかもしれない。また他の例としては、株式取引上のコンプライアンスチェックを実行するために、AS400にアクセスする必要がある.NETプラットフォームに実装取引アプリケーションがあり、また大規模なサードパーティの.NET倉庫システムと統合する必要があるJavaベースの小売店がある。
これらの例は、ほとんどの大企業のいたるところに見られる。多くの銀行や保険システムは、近代的なウェブベースのプラットフォームからアクセスされなければならない主要なCOBOLのメインフレーム・アプリケーションのバックエンドのコア処理を持っている。複数の異種のシステムやサービスとの統合能力は、microservicesアーキテクチャがSOAに遅れをとる数少ない領域の一つだ。
microservicesアーキテクチャスタイルは、サービス統合のための選択肢を減らすことによって、アーキテクチャパターンとそれに対応する実装を簡素化しようとする。RESTとシンプルなメッセージングは最も使用されている一般的なリモートアクセスプロトコルのうちの2つだ。SOAは上限はなく、そのメッセージング・ミドルウェア・コンポーネントを介して、複数の異種プロトコルの増殖を促進する。
microservicesアーキテクチャスタイルは、プロトコルを意識した異種の相互運用性をサポートする。プロトコルを意識した異種の相互運用性によって、リモートアクセスプロトコルの複数のタイプをサポートすることができる。しかし、特定のサービスの消費者と、それが対応した呼び出し先サービス間の通信（例えば、REST）と同じでなければならない。図4-1に示すように、サービス消費者とサービスとの間のリモートアクセスプロトコルが意識されているという事実は、必ずしも実装が既知のまたは同じでなければならないことを意味しない。RESTでは、例えば、サービスはJavaで実装することができ、一方サービス利用者は、簡単に.NETとC＃で実装することができる。しかしながらマイクロサービスでは、プロトコルを変換する中央ミドルウェアコンポーネントが存在しないため、サービスとサービス利用者間のプロトコルは同じでなければならない。

図4-1。プロトコルを意識した異種の相互運用性

SOAもまたプロトコル対応の異種の相互運用性をサポートしているが、プロトコルにとらわれない異種の相互運用性をサポートすることによって、さらに一歩すすんだコンセプトを持っている。プロトコルに依存しない異種の相互運用性で、サービス消費者は、サービスの実装だけでなく、サービスがリッスンしているプロトコルもまた気がつかない。たとえば、図4-2に示すように、.NETプラットフォーム上でのC＃で書かれたある特定のサービスの消費者は、RESTを使用して、対応するサービスを呼び出すことができるが、EJB3 BeanのサービスRMIを使用して通信することができるだけだ。プロトコル変換として知られているサービスプロトコルから利用者のプロトコルへの変換は、メッセージング・ミドルウェア・コンポーネントを使用することによってサポートさされる。microservicesアーキテクチャは、メッセージング・ミドルウェア・コンポーネントの概念がないので、プロトコルに依存しない異種の相互運用性の概念をサポートしていない。

図4-2　プロトコルに依存しない異種の相互運用性

もしもいくつかのタイプの異なるプロトコルを使用するシステムやサービスを統合することが必要な異種環境なら、microservicesではなくSOAに目を向ける必要がある。しかし、あなたのすべてのサービスが同一のリモート・アクセス・プロトコル（例えば、REST）を介してアクセスされる場合は、microservicesが正しい選択だ。いずれにしても、これはアーキテクチャパターンを選択する前に知っておく必要がある、相互運用性の要件の1つの領域だ。

契約による分離(Contract Decoupling) †

契約による分離は、抽象化の聖杯だ。サービスが期待しているものとは異なるメッセージフォーマットで、異なるデータを使用したサービスと通信することができることを想像してほしい。これが契約による分離の本質である。
契約による分離は、サービス利用者とサービス間の分離の最高レベルを提供する非常に強力な機能だ。この能力は、サービスとサービス利用者がそれらの間の契約を維持しながら、互いに独立して進化することができる。またこれは、サービス利用者に契約変更をできる能力を与えることができ、それによって、サービスとサービス利用者の間でより多くの協力関係を作成することができる。
契約による分離には二つの主要な形式がある。メッセージ変換とメッセージ拡張だ。メッセージ変換は実際のメッセージではなく、要求データのフォーマットにのみ配慮している。例えば、サービスはその入力フォーマットとしてXMLを必要とするかもしれないが、サービス利用者は代わりにJSONペイロードを送信することを決定するとする。これは、Apache Camel、Mule、そしてSpringの統合を含む、オープンソースの統合ハブのほとんどが非常にうまく処理される単純な変換タスクだ。サービス利用者によって送信されたデータは、対応するサービスが期待するデータと異なるときには、物事はもう少し複雑な傾向がある。実際の契約データにおけるこのインピーダンスミスマッチは、メッセージ拡張能力によって解決される。メッセージ変換は、要求のフォーマットに関心を持っているのに対し、メッセージ拡張が要求データに関心を持っている。この能力は、コンポーネント（通常ミドルウェアコンポーネント）にリクエストデータの追加や変更を許し、それでサービス消費者によって送信されたデータは、サービス（またはその逆）の予想するデータと一致する。
単純な株式取引のためのJSONオブジェクトとしていくつかのデータをサービス利用者が送信するシナリオを考えてみよう。この例では、サービス利用者はサービスを、顧客ID、取引される株式を識別するCUSIP番号、取引されるべき株式数、そしてMM / DD / YY形式の取引日を送信して呼び出す。

   {"trade": {
     "cust_id": "12345",
     "cusip": "037833100",
     "shares": "1000",
     "trade_dt": "10/12/15"
 }}

サービスは他方で、口座番号、銘柄記号（株式取引を想定）、共有取引されるべき、とYYYY.MM.DD形式の約定日からなるXML形式のデータを期待している：

   <trade>
     <acct>321109</acct>
     <symbol>AAPL</symbol>
     <shares>1000</shares>
     <date>2015-10-12</date>
   </trade>

サービスコンシューマとサービスとの間の契約の形式で違いが発生した時、異なる契約が一緒に動作させるために必要なデータ変換とデータ検索機能を実行するメッセージングミドルウェア・コンポーネントまたはカスタムクライアントアダプタが一般的だ。図4-3の図は、この例を示している。データベースまたはキャッシュルックアップが、CUSIP番号に基づく顧客IDと、シンボルに基づく口座番号を取得するために処理される。日付も別の形式に変換され、そのフィールドは、任意の変換を必要としないので、株式は新しいフォーマットにコピーされる。契約の変更が行われた場合、メッセージング・ミドルウェアを介して抽象化することができるように、サービス利用者が、サービスから別の契約を持つことができる。図4-3　契約による分離

契約による分離ためにいくつかの実用上の制限は明らかにあります。サービスに必要なデータが、他のソースに由来するか、またはサービスの消費者によって提供されたデータを用いて計算することができない場合、サービス契約が成立ないのでサービス呼び出しは失敗する。幸いなことに、ルックアップ能力と（日付、時刻、数値フィールドなど）の基本的な変換は、通常、サービスコンシューマとサービスの間でほとんどの契約の差異を修正することができる。
IT業界の継続的な苦労は、ビジネスに技術（IT部門）が引きづられることをどのように守るのかを知ることだ。あなたが大規模なサブシステムの主要なソフトウェアバージョンのアップグレードを実行したり会計や顧客管理システムを交換するかどうかは、契約による分離を介してインタフェースと契約を抽象化することによって、企業全体のビジネスアプリケーションに影響を与えることなく技術の変更を行うことをIT部門に許す。前述した株式取引のシナリオは、この良い例だ。 CUSIP番号を使用した取引プラットフォームをSEDOL番号を必要とするものにスワップアウトすることは、企業全体のすべてのビジネス・アプリケーションがSEDOL番号に変更することを必要とすべきではない。
残念ながら、microservicesは再びこのアーキテクチャの機能に関してもSOAに遅れを取っている。契約による分離は、SOA内で提供主要な機能の一つであるのに対し、Microservicesアーキテクチャは契約による分離をサポートしていない。アーキテクチャでこのレベルの抽象化が必要な場合は、microservicesソリューションではなく、SOAに目を向ける必要がある。

MicroservicesVsSOA / Comparing Architecture Capabilities

Menu

最新の20件