統合 (インテグレーション) とは

IT の統合 (インテグレーション)、つまりシステム・インテグレーションとは、IT 組織全体のデータ、アプリケーション、API、およびデバイスをより効率的に、生産的に、そしてアジャイルに接続することを指します。統合は、ビジネスの変革、つまり市場の変化に合わせてビジネスの実行方法を根本的に変えることを議論する際に重要となります。統合は IT のすべてを連携させるためのものだからです。統合は単に接続するだけではありません。統合によって異なるシステムの機能が接続され、それにより新しい機能が実現され、価値が付加されます。たとえば Apache Kafka はデータのストリームをアプリケーションと統合できるオープンソース・プラットフォームで、データをリアルタイムで活用できます。

IT 統合は、「継続的インテグレーション (CI)」、つまりコードの作業コピーが共有の中央リポジトリに 1 日に複数回マージされる開発者向けのプラクティスとは異なるコンセプトです。CI の目標は、ビルドと検証を自動化して問題を早期に発見し、迅速な開発につなげることです。

IT システムが時間の経過とともに成長し、発達するにつれて、各システムはそれぞれに無秩序な広がりを見せるようになりました。異なるベンダーのソリューションが通信することはありませんでした。すると「所有者が同じ」という事実以外には何のつながりもないソリューション群からなる IT スタックが生まれるのも、珍しいことではなくなります。そこで、ビジネスロジックを実装している場合は特に、このようにテクノロジーがスパゲッティのように絡み合った状態を整理して、重複箇所を取り除く方法が必要でした。

*注：「物理トポロジー」と「論理トポロジー」、および「アプローチ」と「アーキテクチャ」と「テクノロジー」については、意味論的に議論が分かれるところです。以下の説明は、一般的な概要を示すことを目的としています。

エンタープライズ・アプリケーション統合

異質なものが無秩序に広がった状態を解消できるのが、エンタープライズ・アプリケーション統合 (EAI) でした。これは、アプリケーション間のメッセージベースの統合をリアルタイムで実装するテクノロジーであり、ツールであり、フレームワークです。これらのメッセージは、個々のアプリケーション内に組み込まれた変更またはパラメーターによってトリガーされます。EAI の実現には、ポイントツーポイントとハブアンドスポークの 2 つの方法がありました。

ポイントツーポイント・モデルでは、アプリケーションが他のアプリケーションや IT 内のシステムと通信できるように、各アプリケーションをカスタマイズする必要がありました。このカスタマイズは、IT アセットごと、そして接続先のアセットごとに行われます。これは非常に面倒な作業であり、当然のことながら、エラーが発生しやすくなります。このモデルでは、インフラストラクチャとアプリケーションを更新するにつれて、時間の経過とともに保守が非常に難しくなります。

これを解決するのが、ハブアンドスポーク・モデルです。このモデルでは、アプリケーションとサービスの間の接続がハブと呼ばれる中央ブローカーによって処理されます。ハブをアプリケーションおよびサービスに接続するスポークは、個別に管理することができます。これにより、ハブとスポークを介してすべての統合技術を処理し、アプリケーション自体をより集中させることができます。このアプローチの主なマイナス面は、ハブが一元化されていることです。これは、システムとインフラストラクチャ通信の単一障害点になります。EAI ハブアンドスポーク・モデルによる統合は、設計上、ハブが機能するかどうかに依存しています。

エンタープライズ・サービス・バス

EAI ハブアンドスポーク・アプローチの次に登場したのが、メッセージベースの抽象化とアプリケーション間のサービスのモジュール化を提供するツール、エンタープライズ・サービス・バス (ESB) です。

ESB は、これらのモジュール化されたサービスのすべてを共有し、ルーティングし、組織化し、アプリケーションとデータを相互に接続するための中央ハブとして機能します。これは、EAI ハブアンドスポークよりも優れたソリューションですが、組織は成長してアセットを追加し、すべてのプロパティとソフトウェアリソースでの高速化が必要になるため、究極の解決策とは言えないかもしれません。

ここまでで、ESB はハブアンドスポーク・モデルによく似ていると思ったことでしょう。確かにそうですが、ESB には、機能性の点で一線を画す大きな特長があります。

• それは、ESB はオープンスタンダードを使用したサービスとして提供されるということです。これにより、アプリケーションごとに固有のインタフェースを作成する必要がなくなります。
• 統合サービスは、アプリケーションに最小限の変更を加えるだけでデプロイできます。
• ESB は、業界標準のオープンなプロトコルとインタフェースを利用しており、新たなデプロイメントを容易にします。

ただし一般的な ESB の導入では、ハブアンドスポーク・モデルで説明した明白な理由のために、すべての統合サービスをホストして制御する 1 つの場所、という集中化されたアーキテクチャになってしまうことが多くあります。しかし、集中化された ESB のデプロイメントとアーキテクチャには、厳格な中央ガバナンスが必要です。これは、デジタル・トランスフォーメーションの取り組みの基盤である、より高速で適応性の高いソリューションを提供することには役立ちません。さらに、ESB はしばしばモノリシック・アプリケーションになりがちです。

アジャイル・インテグレーション

これまでは、すべてを連携させる技術としての、統合 (インテグレーション) そのものについて述べてきました。では、アジャイル・インテグレーションとは何でしょうか。簡単に言えば、接続された各種システムの将来を Red Hat がどのように見ているのか、また、変化がより頻繁に起こる中で IT チームが成長のために成し遂げなければならない実際の仕事を Red Hat がどのように支援できるのかということです。

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

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