イベントドリブンインテグレーション：今こそインテグレーションをイベント対応にする時

はじめに

インテグレーションの従来の形態は、絶えず変化するエコシステム、より迅速な新しいエクスペリエンスを求める顧客、パーソナライズされたインタラクティブなコミュニケーションの必要性、そして現代技術がもたらす接続性の増大という課題に直面しています。

この記事では、これらの変数が情報の流れにどのような影響を与えるか、そして新しいインテグレーションアーキテクチャがこれらの変化の影響に耐えられるようにするために何をすべきか、アプリケーション開発者が迅速に対応できるようにし、エンタープライズアーキテクトがこれらの変化を計画するための支援について探ります。次に、イベントドリブンインテグレーションがこれらの新しい課題に対するソリューションであり、それらが必要とする成長とスケーリングを可能にする方法を探ります。ご覧のとおり、イベントドリブンインテグレーションは、データパスをクリアにし、処理をイベントドリブンコアのエッジに置くことで、インテグレーションの方法を逆転させます。

これは、インテグレーションにイベントドリブンアプローチを取ることの課題、ソリューション、およびメリットを明確にし説明する一連の記事の第1弾です。

スピードへの要求

「唯一の不変は変化である」という古いことわざがありますが、これはここ数十年のエンタープライズIT空間においても真実です。クラウド、IoT（モノのインターネット）、AIなどの新技術が変化の速度を指数関数的に増加させてきました。私たちの期待と要求は高まる一方で、それらへの対応を待つ忍耐力はほとんど同じ速度で低下しています。

テクノロジーは私たちを互いに、そして周囲の世界に繋げており、テクノロジーが私たちの生活を改善・加速させてきた例は数え切れないほどあります。過去20年間で、デジタルコミュニケーションはメールからソーシャルメディアへ、ショッピングは店舗・オンラインからオムニチャネルへ、予防医療は対面検診からセンサーベースのAI診断へと進化しました。かつては自然のスピードで動いていましたが、今はテクノロジーのスピードで動いています。

私たちが互いに、また購入する企業と持つインタラクションの数も指数関数的に増加しています。一つの単純な行動が複数の結果をもたらし、多くの人々やシステムに影響を与える可能性があります。リアルタイムですべての関連する行動とイベントをより広く把握する必要性、つまり「状況認識」の向上が求められています。例えば、旅行中に移動しているとき、悪天候により飛行機が遅延したとします。現在、このようなイベントは、ゲートクルー、手荷物取扱、予約への通知、そして場合によっては一泊が必要な際に近くのホテルが利用可能かどうかを確認する問い合わせにつながることがあります。

日常生活やエンタープライズにおけるこのようなテクノロジーの普及は、トランザクションのボリューム、複雑性、多様性、および予測不可能性の絶え間ない増大につながっています。ほとんどの大企業は、オンプレミス環境、さまざまなクラウドインフラ、そして店舗、物流センター、工場、コネクテッドビークルなどのIoT/エッジ環境にまたがる1,000以上のアプリケーションを管理する必要があります。このハイパーコネクティビティによるデータ生成は毎年25%以上増加しています。

最後に、データの価値は時間とともに指数関数的に減少します。適切な瞬間に行動しなければ、深刻な結果をもたらすか、少なくとも劣悪なユーザーエクスペリエンスにつながる可能性があります。先述のとおり、リアルタイムでコンテキスト情報を受け取ることへの私たちの期待は劇的に高まっています。

統一された関連コンテキストを達成する際の課題の一つは、現在のエンタープライズデータ環境の多くが多数のサイロにわたって分散しているという事実です。したがって、これらのサイロを解体し、正確な決定を可能にする正確な情報を提供するためにリアルタイムでデータをアクセス可能にすることが最重要になります。適切な時に正確な情報にアクセスできることは、詐欺防止のような深刻なことから、商品の定価を支払うか割引を受けるかといった些細なことまで、大きな違いをもたらす可能性があります！基本的に、コンテキスト内のリアルタイムデータは、機会と脅威を特定し、それらを活かす、または防ぐのに役立ちます。

現代のインテグレーションプラットフォームとアーキテクチャには汎用性と柔軟性が求められ、以下を満たす必要があります。

データフローを最大化する
エンドポイントを疎結合にする
（ほぼ）線形にスケールする
フォールトトレラントである
幅広い接続先（アプリ、システム、デバイス）をサポートする
同期・非同期サービス双方にわたる包括的なガバナンスを持つ
セルフサービスを促進する
アセットの発見と再利用を通じてコンポーザビリティを促進する

インテグレーション環境の課題

インテグレーション戦略における最新トレンド（マイクロサービス指向）は、ドメイン駆動設計とともに、分散ソフトウェアの設計・構築方法に大きな変化をもたらしました。APIおよびマイクロサービスベースアーキテクチャのより魅力的な側面のいくつかは以下のとおりです。

デジタルアセット（API）の発見可能性を通じた再利用
「細粒度」なマイクロサービスから「粗粒度」なマイクロサービスを構成するコンポーザビリティ
コードへの直接インテグレーションではなく、コントラクト/インターフェースへのインテグレーションによる変更の最小化
ガバナンス

セルフサービス方式でデジタルアセット（APIなど）を発見・再利用する能力は、作業の重複を削減し開発を加速させます。それらの再利用可能なアセットを新しい興味深い方法で組み合わせ・構成する能力は、エンタープライズにアジリティをもたらし、価値実現までの時間を短縮します。

したがって、セルフサービスと再利用は、ほとんどの企業を悩ませるアセット提供のギャップを縮小します。提供ギャップとは、限られたリソース、アクセスできない情報、柔軟性のないアーキテクチャなどのために、新しい機能に対するビジネスの需要とITがそのニーズを満たす能力との間のしばしば相当大きなデルタを意味します。

マイクロサービスベースのインテグレーションがもたらした大きなメリットにもかかわらず、実装はアーキテクチャとインフラストラクチャ両方の分野での課題に満ちていることが多いです。例えば、RESTベースアーキテクチャの主要な価値提案の一つは、ユビキタスプロトコルであるHTTPです。すべてのサービスがHTTPを「話す」という事実はインタラクションを簡素化しますが、例えば遵守しなければならない時間的制限（タイムアウトリスク）のために各マイクロサービス/APIでできることに制限があるため、これは高い結合度につながる可能性があります。これは特に以下の場合に当てはまります。

そのマイクロサービスに過剰なロジックを詰め込もうとしている
複数の依存関係がある（つまりAPIコールのシーケンス）
サービスが地理的に分散した他のサービスと相互作用する必要がある

さらに、RESTベースシステムのスケーリングは、ゲートウェイ、ロードバランサー、サーキットブレーカー、スロットリング、レート制限などのポリシーといったコンポーネントを追加する必要があるため、困難になる場合があります。これらはコストと運用上の複雑性の両方にオーバーヘッドを加え、複雑性はシステムをよりもろくする可能性があります。

より簡単に言えば、マイクロサービスベースのインテグレーションは、アーキテクチャの適応性に影響を与えるリジッドな配管の問題を抱えています。これは、実装がインテグレーションプラットフォーム（iPaaSなど）、カスタムコード、またはその組み合わせによって行われるかどうかにかかわらず当てはまります。

リジッドさは以下の形で現れます。

ポイントツーポイントの結合
時間制限のある操作
ルートパスの変更（API A→API BをAPI A→API Cに変更するなど）には介入と再デプロイが必要

例えば、オーケストレーションの主要な課題の一つは、HTTPプロトコルのレスポンスタイム内に収めるために含めることができるステップ数が限られていることです。もう一つの課題は「依存関係ツリー」の深さ（API AがAPI Bを呼び出し、API BがAPI Cを呼び出すなど）です。ツリーが深くなるほど、パフォーマンスへの影響（とタイムアウトのリスク）が高くなり、アーキテクチャはより密結合（したがって脆弱）になります。多くの場合（そしてHTTPの制限により）、地理をまたいでスケーリングする際には、レイテンシを最小化するためにAPI/マイクロサービスインスタンスが異なる地域で複製されます。この複製は、より複雑なバージョン管理とアップグレード手続きにつながり、しばしばグローバルロードバランサーを必要とします。

ほとんどのインテグレーションツール/プラットフォームはあらゆるタイプのインテグレーションを構築できますが、そのインテグレーションプロジェクトに何が組み込まれるかが、全体的なアーキテクチャの柔軟性とアジリティを妨げる可能性があります。あるデータベースからデータを取得し、変換し、別のデータベースに保存するという単純な例では、開発者はしばしば3つのコンポーネント（ソースコネクタ、トランスフォーマー、デスティネーションコネクタ）を同じデプロイ可能なアーティファクトに入れ、高い結合度を生み出します。これは、ツールが3つの個別プロジェクト（プロジェクトごとに1つのコンポーネント）を作成して個別にデプロイできないということではありませんが、開発者はデプロイコストとリソースを節約するためにインテグレーションロジックを1つのデプロイ可能なアーティファクトにまとめることが多く、独立したデプロイ、単一目的、疎結合などのマイクロサービスベースインテグレーションの主要な指導原則の一部に違反します。

要するに、増加するトランザクションボリュームに対応するために、組織は代替策を模索しています。マイクロサービスアーキテクチャの核心的な原則である「スマートエンドポイントとダムパイプ」を「スマートエンドポイントとスマートパイプ」という新しい原則に変換するには、「インテリジェントインフラストラクチャ」の追加が必要になります。

したがって、以下を解決するソリューションを見つける必要があります。

パフォーマンス： データフローを遅くする可能性のある処理コンポーネントがデータパスに存在することによって影響を受けることが多い。適切にスケールできないことも、データボリュームの増加とそのボリュームを処理する能力との間に通常反比例の関係があるため、パフォーマンスに影響を与える可能性があります。新しいソリューションは、不要な処理コンポーネントをデータパスから除去することでデータフローを最大化できる必要があります。
堅牢性： 特定のシステムの回復力、つまりストレスへの対処能力に関係します。データフローには高い揮発性があり、特定のコンシューマーが生成されるスピードでデータを処理できない状況や、逆に特定のデータプロデューサーへの需要が非常に高く生成能力に影響を与える可能性がある状況がしばしば発生します。どちらも特定のシステムコンポーネントをアイドル状態にし、コストのかかるリソースを不必要に消費する可能性があります。新しいソリューションは、アーキテクチャが回復力を持ち、データ損失が発生せず、リソースが最適に使用されることを保証する必要があります。
スケーラビリティ： トランザクションボリュームが増加した際に必要となります。スケールできないことはパフォーマンスに悪影響を与えます。スケーラビリティは、特定の地域でのボリューム増加に対応するためにより多くの処理容量を迅速に追加できないこと（つまり特定のリソースにより多くのコンシューマーを追加する）、地理的に成長して長距離にわたるトラフィックを処理できないこと（つまりNAで生成されたデータはリアルタイムでEMEAとAPACに届く必要がある）、そして接続性の増加（つまりより多くの店舗、工場、倉庫などを追加する）によって影響を受ける可能性があります。新しいソリューションは、両方のスケーラビリティの課題に対応する必要があります。
複雑性： スケーラビリティ、ガバナンス、管理可能性に影響を与える主要な要因の一つです。インテグレーションにおける複雑性は、トランザクションがその目的を果たすために多くのサービスを呼び出す必要がある場合、複数のソースからのデータを1つのメッセージに集約する必要がある場合、イベントが複数のコンシューマーに到達する必要がある場合など、1対多のシナリオを扱う際によく生じます。複雑性のもう一つの側面は、クラウド間またはクラウドとオンプレミス間など、異なる環境にわたって操作する必要がある場合に生じます。新しいソリューションはすべての複雑性モデルに対応する必要があります。
柔軟性： 特定のアーキテクチャが最小限の影響とリスクで変化に耐える能力に関係します。場合によっては、これは「進化可能性」とも呼ばれます。密結合のマイクロサービスは依存度と影響の高さから変更を困難にします。ソフトウェア設計の最も古い原則の一つに従い、サービス内では高い凝集性を持ちながら、サービス間では疎結合である必要があります。サービスが何らかのコントラクト（API仕様）に準拠していれば、コントラクトが変更されない場合にサービス内の変更も容易になり、そのサービスのコンシューマーはサービスへの内部変更の影響を受けません。新しいソリューションは疎結合とコントラクトベースの開発をサポートできる必要があります。
アジリティ： エンタープライズが製品を市場に投入し市場シェアを獲得できるスピードを意味します。アジリティは既存のアセットを発見して新しいビジネスオファリングに「組み立て」、逆に既存のオファリングを分解して新しいものに再構成する能力に基づいています。発見可能性は開発サイクルの短縮、ロジックの重複削減につながり、全体的に高いセルフサービス性と効率性をもたらします。

現在のインテグレーションアプローチは、一般的な分散アーキテクチャの原則に沿っていないことが多く、インテグレーションアーキテクチャの設計では特定のインフラストラクチャの制約が考慮されていないことが多いです。そのため、ほとんどのアーキテクチャはトランザクションボリュームの増加とその速度を適切に処理できず、しばしば障害や劣悪なユーザーエクスペリエンスをもたらし、最終的には収益に影響を与えます。これらのアーキテクチャの柔軟性とアジリティの低さも、エンタープライズの競争上の優位性と時間とともに容易に進化する能力に悪影響を与えます。

次のセクションでは、インテグレーションへの異なるアプローチ、つまりこのセクションで概説したすべてではないにしてもほとんどの課題を解決できるアプローチについて見ていきます。

イベント中心性へのシフト

Gartnerは、特にインテグレーションアーキテクチャに関連する、ITシステムアーキテクチャの進化のトレンドを特定しました。このトレンドは、ITシステムを「データ（中心）の管理者」と見なすマインドセットから、ITシステムをエンタープライズの「神経系」を構成するものと見なすマインドセットへのシフトによって支えられていました。これは意思決定のソースとして「静止したデータ」ではなく「動いているデータ」を重視する見方です。

イベント中心の視点は、私たちが影響を認識する方法を変えます。データ中心モデルは主に現在のデータの状態に焦点を当てていますが、イベント中心モデルは同じことをするだけでなく、イベントが発生するにつれてシステムと人々が反応できるようにし、より正確なリアルタイムの意思決定能力につながります。イベント中心モデルはまた、特定の状態の根本原因、つまり変化の影響を特定して理解できる時系列的・歴史的な次元も追加します。

イベント指向はまた、より柔軟で疎結合な「コア」アーキテクチャを実現します。RESTベースアーキテクチャは静止したデータへのアクセスを管理するという点でデータ中心モデルをサポートしますが、EDA（イベントドリブンアーキテクチャ）は疎結合、回復力、および適応性に重点を置きます。これはどちらのモデルが優れているかという議論ではなく、より俊敏で柔軟かつ回復力のあるアーキテクチャを達成するために2つのモデルをどのように組み合わせるかということが重要です。

インテグレーションを裏返す

物理的なネットワークアーキテクチャの最良の設計に関する研究では、「複雑性はネットワークのエッジに属する」ことが示されています。

IETFの論文RFC-3439、Some Internet Architectural Guidelines and Philosophyを引用すると：「要するに、インターネットの複雑性はエッジに属し、インターネットのIPレイヤーはできる限りシンプルに保たれるべきである。」

では、これはインテグレーションとどのように関係しているのでしょうか？現在のインテグレーションアプローチは、インテグレーションコンポーネントをデータパス、つまりコアに配置してきました。リアルタイムかバッチかを問わず、インテグレーションには接続性と変換が必要です。集中型インテグレーションアプローチの課題は、コネクタ、変換、マッピング、そして潜在的なトランザクションコンテキストを1つのデプロイ可能なアセットに結合し、すべてのデータがそこを流れなければならないことです。そのため、インテグレーションコンポーネントはボトルネックと単一障害点になる可能性があります。データパスにこのようなコンポーネント（オーケストレーション、データエンリッチメントなど）が多く存在するほど、処理が遅くなります。

今日のユースケースは、パフォーマンスを損なうことなくトラフィックバーストや低速/オフラインのコンシューマーを処理でき、コンシューマーとプロデューサー双方の増加を処理するためにスケールでき、一時的に利用できないコンシューマーにもデータ配信を保証できるインテグレーションアーキテクチャを必要とします。また、全体的な設計を損なうことなく処理コンポーネントと配信メカニズムを容易に接続できるアーキテクチャも必要とします。つまり、進化可能なアーキテクチャが必要です！

そのようなアーキテクチャにどのように到達するのでしょうか？まず質問から始めます：インテグレーションを裏返したらどうなるでしょうか？RFC-3439の推奨に従い、コアをシンプルに保ちながらインテグレーションの複雑性をエッジに配置したらどうでしょうか？

疎結合の影響

あるデータベースからデータを取得し、異なる地域の2つのシステムにルーティングするインテグレーションの簡単な例を見てみましょう。従来のインテグレーションプラットフォーム（ESB、iPaaSなど）は通常、データソースコネクタ（JDBCやCDCメカニズムなど）がデータを取得し、それをそれぞれの処理エンドポイントにルーティングするチョイス/ルーターコンポーネントが続くという形で実装します。

ルーティングパスはそれぞれの地域のデータシンクシステムへのコネクタに終端します。基本的に、4つのコンポーネントが1つのデプロイ可能なアーティファクトにバンドルされています。より多くの配信ポイントを追加する必要がある場合は、このインテグレーションを変更し、ルーティングルールを更新し、必要なデスティネーションコネクタを追加する必要があります。これはインテグレーションコンポーネントを重くし、時間とともに維持が困難になります。変更を加えるたびに、コンポーネントをオフラインにし、変更を加え、再デプロイする必要があるため、他のすべての宛先に影響を与えます。

より良いアプローチは、インテグレーションコンポーネントをエッジの個別ユニットに分解し、コアに「Event Mesh」を配置して、組み込みのルーティングとフィルタリング機能で必要な宛先に情報をルーティングさせることです。

このアプローチには以下のメリットがあります。

データパスをクリアにする： インテグレーションコンポーネントをそのパスから除去します。Event Meshにルーティングを委ね、他のすべてのコンポーネントを疎結合にすることで、各インテグレーション「パス」はエンドシステムに基づいて可能な限り高速になり、他のパフォーマンスに影響を与えるシステムに結合されません。
複雑なルーティングルールの記述を不要にする： Event Meshのネイティブ機能を活用します。
エッジでの処理（およびデプロイメント）を委任する： コネクタ（そして必要に応じて変換）がそれぞれの地域のリソースを活用します。
ダウンタイムなしで異なる地域にコンシューマーを追加できる： 既存のインテグレーションアーキテクチャへの変更も不要です。
デプロイされた各ノードの個別スケーリングを可能にする。
ソースからのボリューム増加のショックを吸収する。
パフォーマンスへの影響なしに事実上無限の数のターゲットシステムにスケールする。
他のインテグレーションフローへの障害、エラー、低速または利用不可能なターゲットシステムの影響を排除する。
エッジで異なるインテグレーション技術を使用できる： 従来のESB、iPaaS、クラウドフレームワーク、カスタムコードなど。

このアプローチはiPaaS/ESBが提供する機能を取り除くものではないことに注意することが重要です。むしろ、それらの機能を補完し、より優れたスケーリングとより広範なインテグレーションシナリオの実現を可能にします。

一般的に言えば、このアプローチはデータフローを最適化し、パフォーマンス、信頼性、スケーラビリティを向上させます。より小さなインテグレーションコンポーネントの疎結合化は、市場投入までの時間と開発コストを削減することでアジリティを促進します。

結論

データボリューム、接続性レベル、消費モデル、顧客の期待における地殻変動的な変化が、情報フローのアーキテクト方法を変えています。現在のインテグレーションパラダイムはこのニーズを満たすことができず、新しいアプローチが必要になっています。コアを流動的に保ちながら疎結合のイベントドリブンなデータ移動に焦点を当てつつ、複雑なインテグレーションプロセスをエッジにシフトすることで、インテグレーションはより適応性が高く、スケーラブルで、堅牢になります。

これは、イベントドリブンインテグレーションをより深く掘り下げる一連の記事の第1弾です。今後の記事では、Event Meshを使ってイベントドリブンインテグレーションを実装するために何が必要かを探ります。