エンタープライズ統合について理解する

先進的な企業は、データの共有と無縁でいることはできません。ビッグデータを活用しようとしている大規模企業なら、ビッグデータは統合にとって課題であると認識しているでしょう。統合のためには、ビジネス戦略の中心にあるアプリケーションとデバイスが相互にアクセスできなければなりません。また、そうしたアクセスは往々にして複数のクラウド環境をまたいで行う必要があります。エンタープライズ統合はテクノロジー、プロセス、チーム構造を含むものであり、IT 組織内のどこからでもデータ、アプリケーション、デバイスを接続します。

これまでの年月で、エンタープライズ統合モデルは比較的少数のポイントツーポイント接続から、エンタープライズ・サービス・バス (ESB) で接続された一元化モデル、さらには多数の再利用可能なエンドポイントを持つ分散アーキテクチャへと発展しました。

エンタープライズ統合の対象

まず第一に、エンタープライズ統合とはデータに関する課題です。組織内に存在するデータソースは規模が非常に大きく、種類も多岐にわたるため、それを表すために「ビッグデータ」という用語が使われるようになりました。さまざまな標準化されていない形式で存在する大量のデータには、多大なビジネス価値があるかもしれませんが、価値を引き出すにはまず複数のソースやアプリケーションから統合する必要があります。モノのインターネット (IoT) も、毎日使うデバイスを通じて顧客とつながり、有益なデータを分析する新たなチャンスをもたらしますが、データセンターに送るべき重要なデータをふるい分ける必要があります。それに加えて Web アプリケーションも存在するため、エンタープライズ統合はさらに複雑になります。レガシーアプリケーションをマイクロサービスなどのサービスベースのアーキテクチャで統合する必要がある場合は、なおさら複雑になります。

アプリケーション、デバイス、データを統合する方法

かつては、一元化されたチームが管理する一元化されたエンタープライズ・サービス・バス (ESB) が、環境内のあらゆるエンドポイントを接続できました。しかし、チームとテクノロジーを一元化するアプローチは、分散コンポーネントを統合するためにすばやく簡単な方法を必要とする先進的なシステムにとって、ボトルネックとなりかねません。先進的なアプリケーション開発には、データおよびサービスのニーズに応じて、メッセージング、アプリケーションコネクター、データストリーム、エンタープライズ統合パターン、デプロイの速度と反復性が高いアプリケーション・プログラミング・インタフェース (API) を組み合わせるほうが適しています。

メッセージング

メッセージングは、分散アプリケーション・アーキテクチャ内の各種コンポーネントが通信する方法です。通信の両側にあるコンポーネントが共通メッセージング形式とプロトコルを理解していれば、言語、コンパイラー、オペレーティングシステムが異なっていても、メッセージを送受信できます。

マイクロサービス・アーキテクチャ内でメッセージを送信するために、サービスメッシュが使用されます。

アプリケーション・コネクター

アプリケーション・コネクターは、コンポーネントが相互作用するためのルールをモデル化した、アーキテクチャ上の要素です。特定の API に対してカスタマイズされた標準クラスの接続なので、新しいエンドポイントをすばやく統合するために使用できます。

データストリーム

データストリームは絶えず情報を送信し、アプリケーションはデータの転送に影響されることなく、データソースに情報を追加したりデータソースの情報を使用したりすることができます。たとえば Apache Kafka は分散データストリーミング・プラットフォームで、レコードのストリームをリアルタイムで公開、サブスクライブ、保存、処理できます。

エンタープライズ統合パターン (EIP)

EIP は、共通する統合問題に対するテクノロジーに依存しないソリューションの集合です。パターンには、統合を記述するための、開発者とアプリケーション・アーキテクト向けの共通言語も含まれています。

アプリケーション・プログラミング・インタフェース

API は、アプリケーション・ソフトウェアを構築するための一連のツール、定義、プロトコルです。これにより、製品やサービスは、他の製品やサービスの実装方法を知らなくてもそれらと通信できます。

Red Hat は、一元化されたチームがモノリシックなテクノロジーを管理するという従来の統合アプローチでは、分散アプリケーションの開発と長期的な有用性が阻害されてしまうと考えています。ESB などの従来の統合テクノロジーには、セキュリティの優先順位付けやデータ整合性といったメリットがありますが、エンタープライズ全体のインテグレーションの定義を 1 つのチームに依存しています。

俊敏な DevOps 手法で開発された現在の疎結合されたクラウドネイティブ・アプリケーション・アーキテクチャには、やはり俊敏でスケーラブルな統合アプローチが必要です。Red Hat が考えるアジャイル・インテグレーションとはリソースを接続するアプローチで、統合テクノロジー、アジャイル・デリバリー・テクニック、およびクラウドネイティブ・プラットフォームを組み合わせてソフトウェア提供の速度とセキュリティを向上するものです。具体的に言うと、アジャイル・インテグレーションでは、API のような統合テクノロジーを Linux コンテナにデプロイし、機能横断型チームが統合の役割を担うようになります。

クラウドネイティブ・アプリケーションは、疎結合された小型で独立したマイクロサービスの集合で、Linux コンテナにデプロイされ、API またはメッセージングによって接続されています。各サービスはビジネス機能を実装し、継続的インテグレーションおよび継続的デプロイメント (CI/CD) などの DevOps ワークフローを使用して小規模チームが開発します。これによりサービスの迅速なビルド、自動デプロイ、定期アップデートが可能となり、ウォーターフォール型開発サイクルは不要となります。

クラウドネイティブ・アプリケーションは、ユーザーからのフィードバックを継続的改善に速やかに取り入れる機能など、ビジネス価値の提供を目的に開発されています。つまりクラウドネイティブ・アプリケーション開発とは、新規アプリケーションの構築を迅速化し、既存アプリケーションを最適化して、すべてをつなげる手段です。

クラウドネイティブ・アプリケーションは分散しているため、従来のモノリシックなアプリケーションとは異なる独自の統合の課題を抱えています。アジャイル・インテグレーションによって、クラウドネイティブ開発が可能になります。その理由の一端は、統合のアプリケーション要件とビジネスニーズがまとめられることです。