目次


進化するハイブリッド統合リファレンス・アーキテクチャー

デジタル化に遅れをとらない統合ランドスケープをどのようにして確実にするか

Comments

時が経つにつれ、統合は必然的に複雑化していきます。複雑さの原因は、インフラストラクチャーとプラットフォームの順列が常に形を変え続ける中、統合に必要となるリソースの多様性が増してくることにあります。さらに、システムの統合に関わる担当者は、1 つの技術チームに集められるのではなく、企業全体、そして企業外にも分散されるようになっています。

同時に、この複雑化に端を発して、統合の単純化および合理化を目標とした競合する動きもあります。Web API は共通のプラットフォームになるまでに成熟し、言語に依存せずにアプリケーションが通信する手段として使用できるようになっています。インフラストラクチャーの仮想化とコンテナー化はさらに進んでいて、ハードウェアやオペレーティング・システムの仕様書からランタイムを解放し、弾性のあるワークロード・オーケストレーションを可能にしています。最近のチームでは、開発スタッフと運用スタッフをより効果的に連携させて、ビルドからデプロイメントまでのプロセスを自動化し、リリース・サイクルを迅速化する方法を学ぶようになってきました。

このような状況で課題となるのは、真のハイブリッド環境を、「ハイブリッド」という言葉が持つさまざまな意味で実現することです。ロケーション、チーム、手法、プラットフォームをはじめとするさまざまな要素がとどまることなく多様化する中、このハイブリッド環境をまたがる統合アーキテクチャーも急速に進化しつつあります。

この記事では、ハイブリッド統合がどのように進化してきたのかを説明するために、まず、クラウドへの移行によって統合のスコープがどのように変わったかという点に目を向け、その上で、ハイブリッド統合機能の大まかな特性を定義します。次に、IT が組織内で中心的役割を担うことが少なくなってきているのはなぜなのかを説明した後、ハイブリッド統合アーキテクチャーの基本的なビルディング・ブロックを取り上げ、API エコノミーによって統合を製品化する方法を説明します。そして最後に、デジタル IT チームのニーズを理解して満たし、ハイブリッド環境全体の一貫性を高めるためにはどのようにするのかを明らかにします。

ハイブリッド統合のサーフェス・エリアの拡大

現在、企業の所有権の境界は、企業という壁を越えて広がり、真のハイブリッド環境全体にわたる IT 資産を包含するまでになっています。このようなアーキテクチャー内では、既存のアプリケーションはクラウド・プロバイダーの IaaS (Infrastructure as a Service) に移され、新しいアプリケーションは PaaS (Platform as a Service) として提供されるクラウド上で構築されるのが通常です。この傾向に沿って、事前ビルドされたクラウド・ベースの SaaS (Software as a Service) の利用も急増しています。

さらに、外部関係者とのやりとりは、相手が顧客であれビジネス・パートナーであれ、ますます自動化されるようになっています。外部関係者とのやりとりがどこまで自動化されているかが、ビジネスの差別化要因となることも珍しくありません。

統合のサーフェス・エリア全体の概要図
統合のサーフェス・エリア全体の概要図

このような状況の中、すべての統合機能では、基本的に、クラウドの境界を越えた接続に対処しなければなりません。さらに、統合によってもたらされるセキュリティーと管理の問題を単純化し、進化し続ける標準をハイブリッド・アーキテクチャー内に取り込む必要もあります。

ハイブリッド統合とは、オンプレミスのシステムとクラウド・システムの統合を可能にすることであると、ごくかいつまんで定義されることがよくあります。けれども、ほとんどの組織にとって、実際のハイブリッド統合にはそれより遥かに多様な側面があります。真のハイブリッド統合アーキテクチャーで考慮されるのは、所有するすべての環境の間での統合です。統合は、オンプレミスからクラウド環境にまで及び、クラウドがローカル環境であるか、あるいは専用クラウドまたはパブリック・クラウドであるかどうかは関係ありません。さらに、統合の範囲は自作の環境からプラットフォーム、SaaS にまでも広がります。しかも、企業がビジネス・パートナーおよび顧客とどのようにつながりを持つかを考える必要もあります。このように非常に広いスコープを持つハイブリッド統合で重要となる課題は、この複雑さをどのように解釈して、問題の単純化に役立つ共通のアーキテクチャー・パターンを見つけるかという点にあります。

ハイブリッド統合のコア機能

全体的に見て、ハイブリッド統合は大掛かりな統合フレームワークです。この統合フレームワークでは、ハイブリッド統合は、環境がデータ・ソースそのものであるか、アプリケーションまたは API であるか関わらず、所有するすべての環境をシームレスに橋渡しして、オンプレミス、IaaS、PaaS、または SaaS のどこにあろうとも、それらの環境に接続できるようにします。

ハイブリッド統合の機能とスコープの概要図
ハイブリッド統合の機能とスコープの概要図

ハイブリッド統合に必要となる接続機能は、最近のクラウド・ベースのアプリケーションだけが対象ではありません。同じく非常に重要な従来型の基幹システム (SOR) も接続しなければならないため、幅広い接続機能が必要になります。また、タスクを単純化し、生産性を促進するためのツール (例えば柔軟で高速のマッピングおよびトランスフォーメーションなど) も必要です。非機能要件の観点からは、エンタープライズ規模およびインターネット規模のスケーラビリティー、セキュリティー、回復力も実現できなければなりません。

ただし、ハイブリッド統合全体を定義するのは重要なこととは言え、統合のニーズがどのように変化しているのかを考慮し、統合に関連する 2 種類の対象集団を認識する必要があります。

業務部門別の IT の選択

ここ数年で、モバイル革命によって特に拍車がかかったことから、中央集中型だった IT は、エンタープライズ IT とデジタル IT とも呼ばれる、少なくとも 2 つの陣営に分岐しました。

エンタープライズ IT は、ビジネス上不可欠なシステムのサービス・レベルを維持すること、そしてビジネスが依存しているコア・システムに当然求められるデータ整合性とセキュアなガバナンスを確保することという極めて重要な役割を担っています。けれども、このように厳しく規制および管理された環境では、急速に変化し続ける市場で新しい提案やイノベーションによって企業が外部に常に新鮮な印象を与えるようにすることを担う事業部門 (LOB) のニーズは満たされません。

LOB は、以下の例に挙げるような要件を、ますます重視するようになっています。

  • アジリティー: LOB は多数のプロトタイプを次から次へと調査して適応し、必要な場合にはいち早く断念して、次のアイデアに移らなければなりません。この手法は、マイクロサービス・アーキテクチャーのように、さまざまな手法を使って細かくコンポーネント化されたアプリケーションを作成することを意味します。また、実装の変更から製品デリバリーまでの期間を最小限にする DevOps 文化を重視することも意味します。
  • スケーラビリティー: プロトタイプから一般販売に切り替える際、LOB では数百人規模の委託ユーザーから公開市場への切り替えにあたって、大々的な開発作業を追加することなく、プロトタイプをスケーリングできなければなりません。また、単純で予測可能なコスト・モデルを使用し (つまり、IaaS または PaaS を使用することを意味します)、本質的にスケーラブルなアプリケーション・アーキテクチャーに基づいてインフラストラクチャーをスケールアップ/スケールダウンできるようにする必要もあります。
  • レイテンシー: 提供するアプリケーションのリアルタイムの応答性についても、LOB にはさまざまなニーズがあります。心を引き付けるモバイル・エクスペリエンスを創出するためには、既存の基幹システムよりも大幅にレイテンシーが低くなければなりません。レイテンシーを低くするには、事前に集約されたデータまたはキャッシュに入れられたデータを使用すると同時に、データ重複や結果整合性に関する難しい問題も考慮に入れた設計が必要になります。また、適切なトラフィック管理によってワークロードに優先順序を付ける必要もあります。
  • 可用性: 主にオンラインで行うビジネスの評判は、タイミングの悪い時にほんのわずかなダウンタイムが発生しただけでも、取り返しがつかないほど損なわれます。実績のある可用性は、差別化要因の 1 つです。LOB には、常に高可用性を維持するように設計されたアプリケーションが必要です。そのようなアプリケーションには、通常、社内アプリケーションに選択するような手法とは別の手法を使用して回復力を確保しなければなりません。

上記の要件を踏まえると、LOB 内で生まれた影の IT 部門が、今や、中央 IT で使用されている手法とは異なる手法を使用して重要な新規プロジェクトに取り組むようになっているのはなぜなのかを理解できるはずです。中央 IT とは異なる手法を使用してプロジェクトに取り組む LOB IT 部門は、瞬く間に影の存在ではなくなり、次世代のアプリケーションを作り出す役割を担うデジタル IT チームとして認識されるようになります。多くの場合、デジタル IT チームの文化およびフォーカスも中央 IT とは異なり、採用するのは技術に未熟なスペシャリストではなく、ビジネス志向であるとともに技術的スキルを持つ人材です。したがって、チームのフォーカスは、迅速なイノベーションによって収益と市場シェアを獲得することに置かれるということです。ただし、デジタル IT チームのメンバーが作成するアプリケーションは企業の対外的な顔を表すため、これらのメンバーには、非機能要件を満たすための確固とした技術的バックボーンも必要です。

エンタープライズ IT チームとデジタル IT チームにはどちらも統合のニーズがあります。いずれのチームにしても、独自の分野内での統合と、チーム間での統合の両方が必要です。全体的に見ると、接続性、トランスフォーメーション、API の公開、コンポジションなどのハイブリッド統合機能は同じように思えますが、それぞれの詳細は大幅に異なります。

バイモーダル分割の間の橋渡し

以下の図の例に示されているように、単純化した統合リファレンス・アーキテクチャー内では、中央 IT チームが統合の大半を担当します。中央 IT チームは基本的に、デジタル IT チームに権限を持たせることによってバイモーダル分割の橋渡しをします。基幹システム (SOR) を中央 API ゲートウェイ上で API およびイベントとして表わすために必要な深い統合を行うのは、中央 IT チームの役目です。

バイモーダル IT 統合の概要図
バイモーダル IT 統合の概要図

この図に示されている、もう 1 つの重要で繊細な要素は、クラウド・アフィニティーです。クラウド・アフィニティーの概念は、このアーキテクチャー上での境界線ではなく、連続体を表すことを意図しています。ハイブリッド統合のサーフェス・エリアについて説明したように、このアーキテクチャーのどの部分をとっても、オンプレミスであることもあれば、完全なクラウド・ベースであることもあります。図の下のほうに示されているコンポーネント (基幹システムなど) はオンプレミスである可能性が高い一方、新しい基幹システムはクラウド・インフラストラクチャーにデプロイされることもあります。さらに、SaaS にデプロイされる可能性さえあります。同様に、図の上のほうに示されているコンポーネントはクラウドをベースとする可能性が高いものの、今でも独自の Systems of Engagement (人と関わりあうシステム) をホストしている組織はたくさんあります。あらゆる組織にとって実際的な統合手法は、オンプレミスとオフプレミスのコンポーネントを混合させることです。そしてオンプレミスまたはオフプレミスのいずれにしても、ハイブリッド統合アーキテクチャーで接続を可能にしなければなりません。

このようなコア・エンタープライズ統合には、以下の主要な懸念に基づく、よく知られた広範な要件があります。

  • 低位レベルの接続性: 現在所有しているか、入手する基幹システムを、使用年数やプラットフォームの多様性に関わらず関与させるために、幅広いデータ・フォーマット、トランスポート、およびプロトコルの全体にわたって接続を可能にする必要があります。
  • データ整合性: トランザクションを使用して、基幹システムが整合性のとれた状態を維持するようにしなければなりません。
  • 技術向け API またはサービスの公開: RESTful API や Web サービスなどの最新の手法を使用している、他のアプリケーションの限られた対象者 (主に組織内の対象者) に、技術向け API またはサービスを (デジタル IT のデータ・ソースを含め) 公開する必要があります。
  • エンタープライズ・メッセージング機能: 多数のプラットフォーム上のシステム間で、極めて重要なビジネス・データが保証付きで配信されるようにするために必要な機能です。

この記事の後半で以上の要件をデジタル IT の要件と比較しますが、まずその前に、これらの要件がサービス指向アーキテクチャーなどの典型的な統合イニシアチブにどのように関連するのかを考えましょう。

サービスまたは API の公開に関する最近のプロトコルが追加されているとは言え、バイモーダル統合図を SOA と同一視する人もいるかもしれません。けれども実際のところ、初期の SOA からの進化にはそれよりも奥深い意味があります。ゲートウェイの精巧さと目的は、大幅に成熟しています。最近の API ゲートウェイは、よりコンシューマーを重視したエクスペリエンスとなっていて、API をブラウズしてサブスクライブするための開発者向けポータルや、API の使用状況に関するアナリティクス、そして API へのアクセスをセキュリティーで保護し、制御するための最近のセキュリティー・モデルおよびトラフィック管理を提供しています。

パブリック API の公開

API のプロビジョニング・メカニズムにおいて進化したリッチさは、企業が API の公開を利用して、API エコノミーに加わるという傾向につながっています。以下の図に示されているアーキテクチャー内では、第 2 の (上位) ゲートウェイによって API が公開されることがわかります。このセクションでは、公開ゲートウェイが内部ゲートウェイと異なる仕組みと理由に目を向けます。

この論理的リファレンス・アーキテクチャーには 2 つの公開スタイルを強調するために 2 つの別個のゲートウェイが示されていますが、シナリオによっては、これらのゲートウェイは同じ物理ゲートウェイによって提供される場合もあります。

パブリック API の公開の概要図
パブリック API の公開の概要図

Systems of Engagement の概念は、一般に、モバイル・アプリやシングル・ページ Web アプリといったユーザー向けアプリケーションを示します。これらのアプリケーションは最近のデジタル・チャネルに対応するために、応答性と魅力的なユーザー・インターフェースという手法を使ってビジネスの新しい収入機会を促進しています。一方、一般公開された API という形で新しいビジネス・チャネルを導入できる機会が次第に増えています。これらのパブリック API は、新しいビジネス・モデルのクラウド・ソーシングによってイノベーションを推進するという目的を持った外部開発者によって作成されます。技術的には内部 API と同様ですが、パブリック API は作成される方法、理由、場所、そして誰が作成するかという点で根本的に異なります。

  • 方法: パブリック API は市場の動向に応じて作成され、市場動向の変化とともに迅速に進化します。そのため、通常は軽量のインフラストラクチャーをベースに、マイクロサービスなどのデザイン・パラダイムに従って作成され、より優れたアジリティー、そしてうまくいけば即時かつ弾性のあるスケーラビリティーを実現します。
  • 理由: パブリック API をより正確に捉えるなら、パブリック API は、さまざまな資金提供モデルを使用した、API エコノミーに含まれる販売用製品です。パブリック API は、包括的な汎用インターフェイスとしてではなく、コンシューマー向けニッチとして設計されることも珍しくありません。
  • 作成者: 多くの場合、パブリック API を作成するのは、ビジネスまたは市場をより重視するデジタル IT チームや、軽量アーキテクチャーを専門とするデジタル IT チームが独立して作成および保守します。
  • 場所: 新しい環境の立ち上げ時間の短縮化、そして弾性のある線形スケーリング・コスト・モデルを利用することを目的に、パブリック API はクラウド上で作成およびデプロイされる傾向があります。

技術的にパブリック API の公開を可能にするには、ゲートウェイ内およびその周辺に幅広い機能が必要になります。例えば、パブリック API がより高度で堅牢なサブスクリプション・ベースのトラフィック管理を使用する場合もあれば、開発者が API を見出してサブスクライブするために利用できるデジタル・ポータルを提供する場合もあります。また、インターネット・セキュリティー・モデル (OAuth など)、さらに突っ込んだ脅威からの保護、マーケティングをより重視したアナリティクス、開発者に直接フィードバックを提供するためのメカニズム (コミュニティーのサポート・フォーラムなど) を使用することも考えられます。

デジタル IT 内での統合のニーズ

魅力的で理解しやすい新しい API をデジタル IT チームが提供するためには、内部 API をそのまま公開するだけでは足りません。企業内外の既存の API を組み合わせて、新しい販売チャネルに正確に対応できる機能を提供する必要があります。エンタープライズ IT が対処する複雑なプロトコルや多様なプラットフォームの統合といった低位レベルの問題について、デジタル IT チームはそれほど大きな重点を置きません。デジタル IT チームが作成するアプリケーションと API は、主に最近よく使われるようになった REST などのプロトコルを使用して通信することから、ほとんど手間をかけずに統合できます。そのため、デジタル IT チームは機能を追加することのほうを重要視します。

最近のモバイル・アプリケーションの成功は、それぞれに 1 秒未満の応答時間を求めるアクティブな同時ユーザーを、どれだけ多くサポートできるかどうかにかかっています。基幹システムは、低レイテンシーと市場の膨大なスケーラビリティーを念頭に設計されているわけではありません。このことから、優れたレイテンシーに対する需要を満たすには、実行時に基幹システムからデータを取得するのではなく、データをできるだけエンタープライズのエッジに近づける必要が生じます。その結果、データ移動パターン、キャッシング、そして場合によっては結果整合性などの複雑なパーシスタンス・パターンが必要になります。

デジタル IT チームは通常、直接的な依存性を軽減させ、回復力とスケーラビリティーを向上させるために、内部では軽量の非同期通信を使用します。また、外部では、例えばモバイル・アプリケーションにプッシュ対プル・モデルを使用するなどして、より非同期の方式を目指します。これらのテクノロジー・パターンを最前線に押し出せるようにするため、そしてアジリティー、スケーラビリティー、回復力を向上させることを目的に、デジタル IT チームがマイクロサービス・アーキテクチャーに切り替えることは多々あります。マイクロサービスと、統合とのその関わりは、この記事で説明するにはあまりにも複雑です。詳しい説明については、このリンク先の記事「Microservices, SOA, and APIs: Friends or enemies?」を参照してください。

下の図を基に、デジタル IT チームの統合のニーズをさらに踏み込んで調べると、API を公開するには単なるゲートウェイを超える機能が必要であることがわかります。これらの新しいアプリケーションや API は、言語ランタイムをそのまま使用して作成することもできますが、コンポジションでは、マッピングや拡充などといった、よく知られた統合パターンが問題の大半を占めています。したがって、単純なツールとフレームワークを使って API の実装を高速化することが理に適っています。

デジタル IT チームの統合要件を追加した図
デジタル IT チームの統合要件を追加した図

API 用の外部ゲートウェイに加え、デジタル IT チームには以下の統合のニーズがあります。

  • API コンポジション: 企業内外の既存の API に対する呼び出しを集約して組み合わせることによって、より高度な API を作成できるようにする必要があります。
  • API およびイベントのディスカバリー: クラウドの境界に関わらず、エンタープライズ IT が公開する機能を可能な限りシームレスに検出して使用できるようにするには、特に API およびイベントのディスカバリー・メカニズムが必要になります。
  • 依存パートナーの管理: 外部依存関係を管理して、サブスクリプション、接続、証明書、資格情報に対処し、必要に応じてそれらの使用状況をモニターする必要があります。
  • アプリケーション中心の軽量なメッセージング: アプリケーション環境内に、弾性のあるスケーラビリティー、低レイテンシー、高いサブスクライバー容量などのインターネット中心の機能だけでなく、エンタープライズ・メッセージング環境に接続するという不可欠の機能を備えた。アプリケーション中心の軽量なメッセージング・メカニズムが必要です。
  • 統合 PaaS: デジタル IT チームの生産性を上げるには、プラットフォームを構築する負担を取り除くことが理想です。統合 PaaS を使用することで、最初から既存のプラットフォームを使用して、アプリケーションや API の機能を重点に取り組めるようになります。

柔軟性のある一貫性の追求

ハイブリッド統合アーキテクチャーは、企業全体にわたり、ぎくしゃくすることのない統合を可能にするものでなければなりません。それには、以下の特性が必要です。

  • 一貫性と単純さ: それぞれのコンテキスト内で必要となる統合要素だけを使用した一貫性のある方法で、アプリケーションの境界を越えた統合を可能にします。
  • ハイブリッド対応: アプリケーションがオンプレミスにあろうと、クラウド・ベースのインフラストラクチャー内やプラットフォーム内にあろうと、あらゆる状況でアプリケーションを統合できるようにします。
  • 大規模なアジリティー: エンタープライズ・グレードおよびインターネット・スケールにステップアップできるような柔軟性を確保して、アジリティーと生産性を向上させます。

概念上、具体的なニーズは各人によって異なるとしても、統合は誰にとっても同じように感じられるものでなければなりません。個人の間での競合する需要を満たすには、どのようにして問題を単純化するのかを見いだす必要があります。

一例として、アーキテクチャーにおける一貫性を達成するためによく使われるのは、繰り返しパターンを見つけ、それらのパターンに従ってアーキテクチャーを単純化するというやり方です。この記事で紹介したアーキテクチャー内で、ハイブリッド統合空間全体にわたって明らかに表れている繰り返しパターンには、以下の 2 つのコア要素があります。

  • 公開: API を公開するゲートウェイが代表的です。
  • 実装: 下位レベルの統合を構成できるランタイムが代表的です。

統合ランドスケープ全体で、これら 2 つの要素がさまざまな程度で繰り返されますが、それぞれの要素に必要とされる複雑さと高度さはシナリオによって異なります。

例えば、下の図中の下位層では、既存の基幹システムと深い関わりがある場合、機能のすべてが揃ったツールボックスが必要になるはずです。下位層でのこの仕組みを図中の上位層と比べてください。上位層内では、既存の内部 API のコンポジションをベースに新しい API を公開するデジタル IT チーム、そし外部パートナーに必要となるのは、ゲートウェイといくつかの比較的軽量のコンポジション機能だけです。新しいアプリケーションを作成するとしても、API を公開するゲートウェイとほとんど変わらないもの、そして公開済みの内部 API へのアクセスが必要になるだけでしょう。

ハイブリッド・ランドスケープ全体にわたる反復型の公開および実装の概要図
ハイブリッド・ランドスケープ全体にわたる反復型の公開および実装の概要図

このようなアーキテクチャーの見解は、極めて幅広い単純化の機会をもたらします。ここに示されているような、一貫性の要素をターゲットにすることで、私たちは共通の、しかも柔軟なパターンを使用した統合を促進するとともに、機能を犠牲にすることなくアーキテクチャーを単純化および合理化しています。今後の developerWorks 記事で、これらの柔軟性を持つ一貫性という分野を掘り下げようと思います。

まとめ

ハイブリッド統合の進化について探るこの記事では、ハイブリッド統合が企業の所有権の境界線をどのようにして押し広げたのかを説明し、ハイブリッド統合のコア機能と事業部門の役割および要件を定義しました。続いて、中央 IT チームがバイモーダル分割の架け橋となってデジタル IT チームに権限を与える仕組み、そしてパブリック API と内部 API の違いを説明しました。最後に、デジタル IT チームのニーズを満たし、ハイブリッド環境における柔軟性のある一貫性を確保することがいかに重要であるかを明らかにしました。

この記事では IBM 製品について触れることを敢えて避けましたが、ご想像のとおり、私たちは IBM 製品に大きな信頼を置いています。2016 年の残りを通して、このリンク先の IBM Integration Developer Center ブログで、リファレンス・アーキテクチャーを IBM オファリングにマッピングする投稿に目を光らせてください。このブログの投稿で、IBM の多くのクライアントがこの広義の統合アーキテクチャーに従って、どのように実際の統合問題に対処しているかを説明する予定です。

謝辞

この記事の情報提供および資料のレビューで協力してくれた、Andy Garratt、Peter Broadhurst、Carsten Bornert、Guy Hochstetler、および Carlo Marcoli に感謝します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, Cloud computing, DevOps
ArticleID=1038540
ArticleTitle=進化するハイブリッド統合リファレンス・アーキテクチャー
publish-date=10202016