テクノロジー・リーダーシップ

デジタル変革を加速する――アジャイル・インテグレーション

2020年1月9日

記事をシェアする:

著者：川嶋眞弓
日本IBM ソフトウェア＆システム開発研究所、Integration SWサービス部長

IBM MQやIBM Integration Bus（IIB）など、旧WebSphere製品のスペシャリストとして、業種を問わず数多くのシステム連携プロジェクトを担当。現在も引き続きSWサービスのマネージャーとして、Integration ミドルウェアを活用したシステム間連携やAPIエコノミーを推進中。

新規事業創出のための異業種間提携や企業の吸収合併、業界再編に伴い、個々のシステム同士の連携はますます重要になっています。システム間連携はデータ連携基盤やESB（エンタープライズ・サービス・バス）にて実現されており、今では企業内の共通基盤として重厚長大なシステムになっています。

今後のデジタル変革（DX）の時代にはアジリティー（俊敏性)、スケーラビリティー（拡張性）、レジリエンス（回復力）が求められ、アジャルな開発と同様にアジャイルなシステム連携が不可欠です。このブログでは、アジャイル・インテグレーションとIBMの取り組みについて、ご紹介します。

システム連携の現状と課題

サービス志向アーキテクチャー（SOA）が全盛だった頃、再利用可能なサービスを連携する重要な役割としてESBが位置づけられました。ESBはこれまでの1対1型（ポイント to ポイント）接続ではなく、その名の通り企業内のシステムを横断的に連携するバス型（ハブ・アンド・スポーク）で容易なシステム連携を実現します。

各システムを1対1型でつなぐと接続数はメッシュ上に増大しますが、バス型の接続は各システムがESBにだけ接続すればよいので、システム管理者の手間が省けます。また、周辺システムのアプリケーションで実装していた宛先システムに合わせたフォーマット変換、プロトコル変換などのメディエーション機能とルーティング機能をESBが提供することで、開発生産性の向上が見込まれます。

SOAは、業務処理を行うアプリケーションをサービス化して疎結合で連携することで、アプリケーションの再利用性を高めるアーキテクチャーで、主な実装技術はWebサービスです。メインフレーム等で稼働している既存アプリケーションは簡単にSOAP/HTTP対応できないため、既存インターフェースはそのままで、新規フロントアプリケーションからWebサービス呼び出し出来るように、ESBがメディエーションを実施します。

このように、ESBはそこに接続すればすべてのシステムに容易に連携できる「魔法の箱」であり、システム管理者とアプリケーション開発者のどちらにとっても有用なハブとして、多くの企業で利用されてきました。

しかし共通基盤として構築・運用されてきたESBは、現在大きな課題を抱えています。
初期の段階はハードウェアやソフトウェアを共用でき、インテグレーション開発作業のスキルを持つ専任チームで運用が可能でしたが、連携先が増えるにつれて、稼働するメディエーション・モジュールは数十から数百まで増加し、スケールアウト時は全てのサーバーにモジュールが配置され、ESBは重く巨大化しました。少しの変更でも全体に影響し、迅速な開発・運用ができません。業務チームが新たな連携を追加したくても、ESBを管理する基盤チームにメディエーションのデプロイを申請し、基盤チームが稼働中の連携への影響度を検討、テストしてデプロイするまでに数週間以上かかることもあります。

インテグレーションの増加でESBがボトルネックになると、業種を超えたデータ連携にスピードが要求されるデジタル変革の時代に乗り遅れてしまいます。今、システム連携に求められているのは、データ、アプリケーション、サービスがエンドポイントを意識せずに柔軟に素早くつながる事であり、それを実現するのが「アジャイル・インテグレーション」です。

アジャイルなシステム連携とは？

アジャイルなシステム連携は、その名の通り、俊敏にシステムを接続することで、アジャイル・アプリケーション開発と密接に関係しています。デジタル変革を推進するアジャイル開発は、アプリケーションをマイクロサービス化することから始まります。マイクロサービス化は、アプリケーションを構造化するためのアプローチです。同一サーバー上ですべてのコードが実行される大きなアプリケーションをサイロ状に作るのではなく、コンポーネントを完全に独立して実行する小さな集まりとして設計します。細分化されたサービスは分散化されたサーバー上で稼働し、自由に組み合わせ、再利用できるようになります。これにより、大きなアジリティー、柔軟なスケーラビリティー、レジリエンスのメリットを享受できます。

アプリケーションを細分化して開発するというマイクロサービスの考え方をインテグレーションに取り入れたのが、アジャイル・インテグレーションです。連携機能もアプリケーション同様に小さなコンポーネントとして分割することで管理と変更が容易になります。アジャイル・インテグレーションは、アプリケーションのマイクロサービス化を組み合わせる事で、開発者がすばやく自由に連携機能を付加できるという点でその効力を発揮します。

アジャイル・インテグレーションとは、マイクロサービスの利点を享受した上でシステムをインテグレーションするためのアプローチなのです。

インテグレーションに求められる機能は多様化しています。今までも企業内のシステム間連携だけでなく、SAPやSalesForceなどのERP/CRMシステムとの接続はありましたが、経費精算、勤怠管理、福利厚生などSaaSによる外部アプリケーション・サービス・プロバイダ（ASP）の活用が進んでいます。また、企業のデータやサービスをAPI化して外部へ公開するAPIエコノミーにより、新たなビジネスチャンスも生まれています。銀行が預金者の口座情報をAPI公開することで、Fintech企業にユーザーID/パスワードを預けることなくOAuth認証を利用して、安全にスマートフォンの家計簿アプリから残高照会が可能になっています。これらすべての連携を１つのESB基盤で実現するのではなく、アジャイル・インテグレーションにより、連携パターン毎にモジュールを細分化して稼働させることで、多種多様な連携が独立して実現できます。例えばWebサービスをAPI化するHTTP/SOAPからRest/JSON変換モジュールへ、CRMシステムから顧客データを取り込むためのXMLからCSV変換モジュールへといった具合です。

アジャイル・インテグレーションを実現するために

アジャイル・インテグレーションを実現するためには、次の3つが重要です。

1.インテグレーション・デプロイの細分化
集中型のESBは、複数の連携モジュールが共通の実行環境で稼働するため、1つの連携の追加/変更が全体に影響を与えます。1つの部門システムがミドルウェアの新機能を使いたくても容易にバージョンアップすることはできません。デプロイ先のESBランタイムを管理しやすいサイズに細分化することで、既存の連携を気にすることなく独自に拡張/修正が可能となり、アジリティーが向上します。トランザクション数が増加した場合も小さなランタイム単位で稼働数をスケールアップできますし、ランタイムをコンテナで稼働させればメモリー、CPUなどのリソース競合も発生せずレジリエンスも向上します。

2.インテグレーション・オーナーシップの分散化
一般にESBの管理は、企業内のすべての連携を扱う横断的な基盤チームが担当します。このチームはアプリケーション連携のための技術は詳しくても、連携するアプリケーション自体は理解していないため、業務チームの連携要件をすべて満たすものを提供できていないのが実状です。全体最適のためには、標準化が必須であり各組織の要望をきめ細かく聞き入れることはできません。連携基盤を分散化してオーナーシップの一部を業務チームに委任することで、業務チームの開発自由度を上げることができます。

3.クラウド・ネイティブなインテグレーション基盤の整備
システム連携のためのミドルウェア・ランタイムは急激に変化しています。とても軽量なコンテナ基盤で稼働し、クラウド・ネイティブで使用できます。クラウド基盤を使用すれば、今までのクラスター管理、拡張化、可用性の管理が不要になります。これはただ単にミドルウェアをコンテナ環境で稼働させるだけでなく、Kubernetesなどのクラウド標準のオーケストレーション能力を有効活用できる、コンポーネント構成でなければいけません。

IBMは数年前からミドルウェアのコンテナ化に取り組んできました。2019年秋にはCloud Paksシリーズとして、OpenShiftをベースにコンテナ化されたミドルウェア群をパッケージした製品を発表しました。Cloud Paksは6種類あり、Cloud Pak for Integrationにアジャイル・インテグレーションを実現するソフトウェアが含まれています。メディエーション・モジュールを開発・実行するApp Connect Enterprise（旧IIB）、RESTfull API公開のためのAPI Connect、非同期メッセージングの事実上の標準であるMQ、イベントデータ収集のEvent Streamsなどで、すべてオープンなコンテナ管理基盤のOpenShift上で稼働し、マルチクラウド環境でも対応可能です。