マイクロサービスアーキテクチャのためのアプリケーション統合：サービスメッシュはESBではない

原文(投稿日：2019/05/15)へのリンク

API、サービス、データ、システムの統合は、エンタープライズソフトウェアアプリケーション開発において最も困難でありながら最も重要な要件の1つです。

以前は異種のアプリケーションをすべてポイントツーポイント形式で統合していましたが、後になってサービス指向アーキテクチャ（SOA）と共にエンタープライズサービスバス（ESB）に置き換えられました。

しかし、現代のマイクロサービスやクラウドネイティブアーキテクチャでは、アプリケーション統合についてはもうほとんど話されていません。現代のこれらのアーキテクチャが、エンタープライズアプリケーション統合のすべての課題のすべてを解決したわけではありません。

アプリケーション統合の課題はほとんど変わっていませんが、解決方法が変わりました。

ESBからスマートエンドポイントおよびダムパイプまで

SOAを採用したほとんどの企業は、ESBを中央バスとして使用して、すべての異種のAPI、サービス、データ、システムを接続し統合していました。

特定のビジネスユースケースで組織内のさまざまなエンティティと対話する必要がある場合、これらすべてのエンティティを統合して複合機能を作成するのがESBの仕事でした。

したがって、ESBソリューションは通常、異種のシステムやAPIへのコネクタ、メッセージのルーティング、変換、回復力のある通信、永続性、トランザクションなど、すべての組み込み統合機能の原動力です。

[画像をクリックすると拡大します]

図1: 統合のためのESBの使用

ただし、マイクロサービスアーキテクチャでは、ESBをスマートエンドポイントとダムパイプの構築に置き換えます。つまり、マイクロサービスはすべてのアプリケーション統合を考慮する必要があります。

スマートESBの分散化による明らかなトレードオフは、サービスのビジネスロジックに加えてこれらのアプリケーション統合に対応する必要があるため、マイクロサービスのコードの複雑さが劇的に増大することです。たとえば、図2は、スマートエンドポイントとして機能するいくつかのマイクロサービス（B、F、G）を示しています。これには、他の複数のサービス間の通信構造のロジックとビジネスロジックの両方が含まれます。

[画像をクリックすると拡大します]

図2: マイクロサービスのサービス間通信と構成

マイクロサービスアーキテクチャに関するその他の課題の1つは、回復力のある通信、トランスポートレベルセキュリティ、統計の公開、監視ツールでのデータのトレースなど、サービスのビジネスロジックの一部ではない便利機能の構築方法です。それらのサービス自体はサービスロジックの一部としてそのような便利機能をサポートしなければなりません。各マイクロサービスにこれらすべてを実装するのは非常に複雑で、マイクロサービスが複数の（ポリグロット）言語で書かれている場合、必要な作業量は大幅に増加します。サービスメッシュはこの問題を解決することができます。

[画像をクリックすると拡大します]

図3: A service mesh in action

サービスメッシュの重要な概念は、すべてのビジネスロジックコードをサービスの一部として保持し、その一方で、ネットワーク通信ロジックをサービス間通信インフラストラクチャにオフロードすることです。サービスメッシュを使用している場合、特定のマイクロサービスが他のマイクロサービスと直接通信することはできません。そうではなく、すべてのサービス間通信は、サービスメッシュプロキシまたはサイドカープロキシと呼ばれる、プロセス外で実行される追加のソフトウェアコンポーネントを介して行われます。サイドカープロセスは、同じ仮想マシン（VM）またはポッド（Kubernetes）内のサービスと同じ場所に配置されます。サイドカープロキシレイヤはデータプレーンとして知られています。これらすべてのサイドカープロキシは、コントロールプレーンを介して制御されます。これが、サービス間通信に関連するすべての設定が適用される場所です。

サービスメッシュはアプリケーション統合のためのものではない

サービスメッシュはESBの一部であるいくつかの機能を提供するので、それがアプリケーション統合も行う分散型ESBであるという誤解があります。それは正しくありません。サービスメッシュは、サービス間の通信のためのインフラストラクチャとしての使用のみを目的としており、その内部にビジネスロジックを構築するべきではありません。X、Y、Zと呼ばれる3つのマイクロサービスがあり、ビジネス機能を実装するために、XがYとZの両方と対話するリクエスト/レスポンススタイルで通信しているとします（図4を参照）。コンポジションビジネスロジックはマイクロサービスXのコードの一部である必要があり、サービスメッシュサイドカーにはそのコンポジションロジックに関連するものが含まれていてはいけません。

[画像をクリックすると拡大します]

図4: サービスコンポジションロジックとサービスメッシュ

同様に、イベント駆動型通信を使用するサービスでは、サービスコードがすべてのビジネスロジックの詳細を処理する必要があります（サービスメッシュの実装はまだイベント駆動型アーキテクチャを完全にはサポートしていません）。そのため、マイクロサービスやクラウドネイティブアプリケーションをサービスメッシュ上で実行しても、それらのサービスやアプリケーションの統合は依然として不可欠です。アプリケーションの統合は、現代のマイクロサービスおよびクラウドネイティブアーキテクチャの時代において最も重要でありながら、ほとんど隠れていた要件の1つです。

マイクロサービスとクラウドネイティブアプリケーションの統合

マイクロサービスとクラウドネイティブアプリケーションのコンテキストでは、アプリケーションの統合またはスマートエンドポイントの構築はすべて、マイクロサービス、API、データ、システムの統合に関するものです。これらの統合要件は、いくつかのマイクロサービスの統合から、モノリシックサブシステムとの統合による不正防止レイヤの作成にまで及びます。マイクロサービスとクラウドネイティブアプリケーションのアプリケーション統合要件を詳しく見ると、アプリケーション統合フレームワークに必要な次の主要機能が明らかになっています。

• 統合ランタイムはクラウドネイティブでなければならず、Docker/Kubernetes内でスムーズに実行でき、クラウドネイティブエコシステムとのシームレスな統合を提供できます。
• 特定のサービスに、ビジネス機能を構成するために他の複数のサービスを呼び出すロジックが含まれるようにするには、サービスオーケストレーション/アクティブなコンポジションが必要です。
• サービス間のコミュニケーションが同期的なイベント駆動型のコミュニケーションを介して行われるようにサービスのコレオグラフィ/リアクティブな構成が必要であり、セントラルサービスにはサービスインタラクションのロジックが含まれていません。
• 幅広いメッセージングプロトコル（HTTP、gRPC、GraphQL、Kafka、NATS、AMQP、FTP、SFTP、WebSocket、TCP）の組み込みの抽象化が必要です。
• メッセージやサービスコールのフォーク、ジョイン、分割、ループ、集約をサポートする必要があります。
• 保存と転送、持続的な配信、そして冪等のメッセージング技術が必要です。
• メッセージタイプのマッピングと変換が必要です。
• SaaS（Salesforceなど）、プロプライエタリ（SAPなど）、レガシーシステムを統合する必要があります。
• ビジネスロジック指向のメッセージルーティングがあるべきです。
• 補償付きの分散トランザクションをサポートする必要があります。
• 長期にわたるワークフローが必要です。
• 不正防止レイヤは、マイクロサービスとモノリシックサブシステムをつなぐものでなければなりません。

これらの機能はすべてマイクロサービスやクラウドネイティブアプリケーションに共通していますが、最初からそれらを構築するのは大変な作業です。マイクロサービスやクラウドネイティブアプリケーションを構築する際にこれらの統合機能を慎重に分析し、統合要件に基づいて適切なテクノロジまたはフレームワークを選択することが非常に重要である理由はここにあります。たとえば、複雑なオーケストレーションロジックを持つサービスを構築する必要がある場合は、そのような種類の構成を簡単に記述できるようにする統合フレームワークまたはテクノロジを選択する必要があります。長期的で補償機能を備えたサービスを構築したい場合は、ワークフローと報酬に対するサポートを内蔵したフレームワークを選択する必要があります（InfoQの記事「イベント、フロー、長期サービス：ワークフロー自動化への最新のアプローチで, Martin Schimak氏とBernd Rücker氏がクラウドネイティブアーキテクチャのワークフローテクノロジの現状について詳しく説明しています。）

アプリケーションの統合はほとんどのマイクロサービスの専門家に大部分が無視されてきましたが、Christian Posta氏（Red Hatの元チーフアーキテクト、Solo.ioのCTO）のような作者は、Postaのブログ投稿「アプリケーションの安全性と正確性をIstioや他のサービスメッシュにオフロードすることはできません」などで、アプリケーション統合の重要性を強調しています。Bilgin Ibryam氏は、「ポストKubernetes時代のマイクロサービス」というInfoQの記事で、アプリケーション統合アーキテクチャがSOAからクラウドネイティブアーキテクチャにどのように進化したかについて書いています。そこでは、クラウドネイティブアーキテクチャとのアプリケーション統合の分散化と、サービスメッシュ上でのアプリケーション統合の構築方法が強調されています。

CNCFランドスケープでの開発と統合

Cloud Native Computing Foundation（CNCF）は、マイクロサービスとクラウドネイティブアプリケーションの構築の最前線にあります。そして、持続可能なエコシステムを構築し、その一環としてマイクロサービスアーキテクチャの一部としてコンテナを編成する高品質プロジェクト群の周りにコミュニティを育成することを目指します。CNCFは、マイクロサービスまたはクラウドネイティブアーキテクチャのさまざまな側面を実装できるオープンソーステクノロジとフレームワークで構成されるプロジェクトをホストしています。これらのアプリケーション統合テクノロジがテクノロジスタックのどこに当てはまるかを見るのは興味深いことです。

CNCFが推奨するクラウドネイティブランドスケープのパスには、App Definition and Developmentセクションがありますが、アプリケーション統合や統合に特化したカテゴリはありません。アプリケーション統合の重要性を考えれば、将来的にはそれがCNCFの世界に広がることが予想されます。図5に、App Definition and Developmentの下のアプリケーション統合テクノロジを示します。

[画像をクリックすると拡大します]

図5: 将来のCNCFランドスケープにおけるアプリケーション統合

アプリケーション統合のための技術

多くのモノリシックなアプリケーション統合テクノロジが利用できるが、そのほとんどはクラウドネイティブアーキテクチャやマイクロサービスアーキテクチャには適していません。自社の製品やツールのクラウドネイティブなバージョンを実装しているのは、ごく少数の既存の統合プロバイダーだけです。

アプリケーション統合分野で一般的な統合パターンをすべて手助けする専用の統合フレームワークがあります。通常、これらのテクノロジのほとんどは従来のESBベースの統合から継承されていますが、変更されてネイティブのクラウドネイティブアーキテクチャに統合されています。

• Apache Camel/Camel-Kは一般的なオープンソース統合フレームワークの1つであり、Camel-KプロジェクトはシームレスなCamelランタイムの上にあるKubernetesエコシステムのサポートを提供しています。
• WSO2 Micro Integratorは、オープンソースのWSO2 Enterprise Integratorプラットフォームのクラウドネイティブ版です。Micro Integratorは、Kubernetesエコシステムでネイティブに機能する軽量の統合ランタイムを提供します。
• Spring IntegrationにはKubernetesで作業するための専用のランタイムはありませんが、クラウドネイティブアーキテクチャでアプリケーション統合を構築するのに適しています。

アプリケーション開発フレームワークの中には、アプリケーション統合の要件を満たすものもあります。

• Spring Bootは本質的に統合フレームワークではありませんが、アプリケーション統合に必要な多くの機能があります。
• Vert.xはリアクティブクラウドネイティブアプリケーションを構築するためのツールキットです。これはアプリケーションの統合にも使用できます。
• Micronautは、モジュール式で簡単にテスト可能なマイクロサービスおよびサーバーレスアプリケーションを構築するための、最新のJVMベースのフルスタックフレームワークです。フレームワークにはかなりの数の統合抽象化が組み込まれており、Springなどの従来のフレームワークの複雑さを回避できます。
• Go、JavaScript/Node.jsなどのプログラミング言語などには、特定のアプリケーション統合機能が組み込まれているか、ライブラリとして利用できます。Ballerinaなど、言語の一部として統合の抽象化を提供する新しい言語が新たに登場しています。
• Quarkusは、最高のJavaライブラリとJava標準から組み立てられた、GraalVMとOpenJDK HotSpot用に調整された、新しいKubernetesネイティブのJavaスタックです。それはRESTeasy、Camel、Nettyなど、複数のアプリケーション開発ライブラリを組み合わせたものです。

まとめ

モノリシックアプリケーションをマイクロサービスアプリケーションとクラウドネイティブアプリケーションに分離することで、これらのアプリケーションを接続するという要件はますます困難になっています。サービスとアプリケーションはネットワーク全体に分散しており、異種の通信構造を介して接続されます。あらゆるビジネスユースケースを実現するには、サービス実装ロジックの一部として実行する必要があるマイクロサービスの統合が必要です。その結果、クラウドとネイティブのアプリケーション統合は、マイクロサービスとクラウドのネイティブアーキテクチャーの現代において最も重要でありながら多くが隠された要件の1つです。

サービスメッシュパターンは、マイクロサービスを統合する際のいくつかの課題をクリアしますが、サービスのビジネスロジックから独立した、サービス間通信のコモディティ機能のみを提供します。したがってビジネスユースケースに関連するアプリケーション統合ロジックは、各サービスレベルで引き続き実装する必要があります。したがって、統合に対応したサービスを構築するための最も適切な開発テクノロジを選択し、サービスを組み上げるために必要な開発時間を最小限に抑えることが重要です。クラウド固有のランドスケープでこれらのアプリケーション統合のニーズを満たすために、いくつかのフレームワークとテクノロジが登場しています。それぞれの特定のユースケースに対して評価する必要があります。

著者について

Kasun Indrasiri氏は、WSO2の統合アーキテクチャーのディレクターであり、マイクロサービスアーキテクチャーおよびエンタープライズ統合アーキテクチャーの著者/エバンジェリストです。彼は企業向けマイクロサービス (Apress) とBeginning WSO2 ESB (Apress)いう本を執筆しました。彼はApacheのコミッターであり、プロダクトマネージャーおよびWSO2 Enterprise Integratorのアーキテクトとして働いてきました。彼はO'Reilly Software Architecture Conference, GOTO Chicago 2019、およびほとんどのWSO2会議で発表しました。彼はサンフランシスコのベイエリアのマイクロサービス集会のほとんどに出席しています。彼はベイエリアで、ベンダーに依存しないマイクロサービスの集会であるSilicon Valley Microservice, APIs, and Integration集会を設立しました。