「 BigData　第4回　ビッグデータ時代の情報連携基盤 」

　本稿は、財団法人経済産業調査会発行 「特許ニュース」 No.13448 （2013 年5 月8 日発行）への寄稿記事です。

1. はじめに

　昨今、爆発的な勢いでその数を増やしているSaaS (Software as a Service)群。その勢いに伴って、SaaS間の連携ニーズもまた、同じように爆発的に増加しています。今回は、その爆発的に増加するSaaS間連携をどのように行えばいいのか。そのための情報連携基盤とは、どのようなものなのかを、SaaS間連携のビッグデータとの関連性を踏まえながらご説明していきます。

2. ビッグデータとクラウド

2.1. ビッグデータとクラウドを支える仮想化技術

　今回はビッグデータ時代の情報連携基盤が主題ですが、まず、その背景となるビッグデータとクラウドというテーマから始めたいと思います。
　「第１回 ビッグデータとは何か」[1]で述べたとおり、「ビッグデータ」と言うトレンドは、日々生み出される膨大なデータからの、帰納的推論による近似モデルの構築可能性への期待とも言われています。その証拠に、高速インターネット網の普及、コンピュータ性能向上、ストレージの廉価化など「ビッグデータ」環境整備の向上に伴って、25年前頃に活発に研究されたAI(人工知能)や機械学習といった研究成果が、地球環境、医療、ライフサイエンスや生物科学といった幅広い分野で活用されてきています。そこでまず、「ビッグデータ」と呼ばれるデータの特徴(3つのV)を第１回より再掲します。

• 容量(Volume)
  　ビッグデータの特徴はその容量の巨大さです。企業内外にはデータが溢れており、数テラバイトから数ペタバイトにもおよびます。またデータが増大することによる計算量も非常に膨大となってしまいます。
• 種類(Variety)
  　ビッグデータは企業システムで通常扱っている構造化データとは限りません。テキスト、音声、ビデオ、クリックストリーム、ログファイル等の様々な種類の非構造化データも存在し、これらのデータをビジネスに活用する動きが世界中で広がってきています。
• 頻度、スピード(Velocity)
  今この瞬間にも、ものすごい頻度でICタグやセンサーからデータが生成されています。昨今の変化の著しい市場環境ではこれらのデータによりリアルタイムに対応することが求められてきています。　

　このようなビッグデータを扱うシステムに必要とされる性質とは何でしょうか。それは「スケーラビリティ」という性質です。システムのスケーラビリティとは、一般的には、システムへの要求量の増大に適用できる能力のことです。また一方で、規模透過性と呼ばれることもあります。これは、システムへの負荷の増減にともなって、システムが利用している資源(コンピュータ、ストレージ、ネットワークなど)プールを伸縮させることで、システム利用者に対してシステム規模を透過的にし、システムのスループットを適切に調整する能力のことです。
　スケーラビリティ向上の一般的な手法には大きく分けて2つあります。一つはスケールアップ、もう一つはスケールアウトです。スケールアップとは、システムを構成する単一のコンピュータ自体の能力を引き上げる手法で、CPUやメモリ、ストレージの強化等がスケールアップ手法の代表例です。
　スケールアウトとは、システムにコンピュータを追加し、並列分散コンピューティング技術を活用することで、システムのスループットを引き上げる手法です。「第2回 ビッグデータの利活用とその環境」[2]で紹介したHadoop はまさにこのスケールアウトを活用したビッグデータ基盤と言えます。
　このスケーラビリティを発揮するために活用されている技術に仮想化技術があります。仮想化とは、一般的には、コンピューティング資源(コンピュータ、ネットワーク、ストレージなど)を抽象化することであり、仮想化の対象によって次のように分類されています。

• サーバ仮想化
  　主にサーバの位置透過性を提供することです。例えば、単一の物理サーバを複数の論理サーバに見せかけたり、逆に、複数の物理サーバを単一のサーバに見せかけたりすることです。
• ストレージ仮想化
  　サーバと同様に、ストレージの位置透過性を提供することです。単一の物理ストレージを複数のストレージに見せかけたり、逆に、複数の物理ストレージを単一のストレージに見せかけたりすることです。
• ネットワーク仮想化
  　ネットワークの仮想化は上記2つと比べると少し異色ですが、物理ネットワーク上に仮想的なネットワークを複数構成することです。従来であれば地理的に離れた複数のネットワークを跨いでセキュアなネットワークを構成する技術としてVPN(Virtual Private Network)が主流でした。一方、ネットワーク仮想化においては、ネットワーク回線、ネットワーク機器などを仮想化することによって、物理ネットワーク上に論理的なネットワークを構成します。

　この3つの仮想化の中でも、特にスケーラビリティに関連が深いのがサーバ仮想化です。サーバ仮想化技術は、近年非常に成熟してきており、サーバ仮想化製品も数多くのベンダによって販売されています(例: VMWare， Citrix)。中にはオープンソースのサーバ仮想化ソフトウェアなどもあります(例: VirtualBox)。
　では、このサーバ仮想化が、どのようにシステムのスケーラビリティに寄与しているのかを見てみましょう。サーバ仮想化技術の元では、基本的にサーバはひとつのプログラムとして動作するため、

• サーバの能力の動的な変更 (スケールアップ)
• サーバ自体の追加 (スケールアウト)

　が比較的短時間(数分程度)でできるという特徴があります。これまでの物理サーバのスペック増強や、サーバ追加の時間的コストを考えれば劇的な改善であることは明らかでしょう。
　多くのクラウドサービスでは近年、モバイルデバイスなどの普及、次に述べるIaaS利用の増大にともなって、大量のリクエストに対応するために、この仮想化技術によるスケーラビリティを活用して、刻一刻と量が変動するユーザからの大量リクエストに耐えるスケーラブルなシステムをインターネットサービスとして提供しているのです。この刻一刻と量が変化するユーザからのリクエストは、ビッグデータの3つVの内の容量(Volume)とスピード(Velocity)が巨大であると捉えることができるため、一種のビッグデータと捉えられます。また、ユーザからのリクエストはユーザの情報を大量に含んでおり、ECサイトにおけるクリックストリーム等(ユーザがホームページでどこをいつクリックしたか等のクリック履歴情報)はECサイトの構築への良いフィードバックにもなっていることからも、非常に活用価値のあるデータであると言えるのではないでしょうか。
　このように、現在のクラウドサービスは、ビッグデータと隣合わせにあり、それを仮想化技術によるスケーラビリティという性質が支えているのです。

2.2. 国内企業におけるクラウド採用トレンド

　ここで、国内企業におけるクラウドサービスの採用トレンドを見てみましょう。次の図は、IDC Japanが2012年7月に発表したデータ[3]で、SaaS、パブリッククラウド、プライベートクラウドなどの分類別に、2011年と2012年の利用状況、検討状況を比較調査したものです。

図１　国内企業におけるクラウド採用動向」
(出典:IDC Japan[3]、グラフはデータを元に著者作成)

　どの分類においても、2011年から2012年は増加傾向を示しており、爆発的というわけではないですが、着実に導入が進んでいるということが言えます。興味深いのは、右から２番目の回答で「検討したが利用しないことに決定」した企業が2011年から2012年にかけて大幅に増加しています。これは、企業においてクラウドの調査が進み、現段階の判断として利用しないこととした企業が相当数あると考えられます。今後、この数字がどのように進む不明ですが、「利用しないことに決定」した理由をクラウドベンダー側が把握し、払拭していくことができれば、採用数はさらに増加することが予想されます。
　また、クラウド関連市場の規模ついて見てみましょう。次の図はノークリサーチが2012年9月に発表した日本国内のクラウド関連市場の推移[4]です。2012年の規模はおよそ800億円の市場ですが、2016年には1931.2億円の市場になると予測されています(年平均23.8％成長)。

図２　日本国内クラウド関連市場の伸び
（出典:ノークリサーチ[4]、グラフはデータを元に著者作成）

　また、2015年から2016年にかけて市場規模の伸びが鈍化していますが、これはクラウドのプロバイダ増加によって競争が激化し、サービスの低価格化が進むことによるものと報告されています。
　以上、２つのグラフを取り上げましたが、クラウドの利用状況や市場規模に関する調査は、さまざまな調査会社が実施しており、細かい数字は調査毎に異なるのですが、今後も継続的に伸びていくという見解はどの調査も一致しています。従って企業におけるクラウドへの感心が高まっていることは確かなようです。

3. クラウドの３分類

　では、クラウドサービスにはどのようなものが有るのでしょうか。クラウドサービスは用途に応じてSaaS、PaaS、IaaSに大別されます[5]。これらそれぞれの詳細はこの後で述べますが、概要はそれぞれ次のとおりです。

• Infrastructure as a Service (IaaS)
  サーバ、CPU、ストレージなどのコンピュータインフラをサービスとして提供する
• Platform as a Service (PaaS)
  アプリケーションを稼働させるための基盤(プラットフォーム)をサービスとして提供する
• Software as a Service (SaaS)
  特定の機能をもったアプリケーション(ソフトウェア)をサービスとして提供する

図３　クラウドサービスの3分類

　次節よりそれぞれについて、少し詳しく説明していきます。

3.1. Infrastructure as a Service (IaaS)

　IaaSとは、サーバ、CPU、ストレージなどのコンピュータインフラを提供するサービスです。この種類のサービスはAmazon EC2によって非常に有名になりました。このモデルは、クラウド上に仮想マシンを起動し、それをサービスとして利用するというモデルです。基本的にはLinuxやWindowsなどのOSだけがインストールされた仮想マシンが提供されるので、ユーザはその上で自由にアプリケーションを構築していくことになります。
　パブリッククラウド上のIaaSにおいては、非常に多くのプロバイダの参入が続いています。2011年3月にAmazonは東京にデータセンタを開設しました[6]、楽天の通信系子会社であるフュージョンコミュニケーションも2012年の春にパブリッククラウドにおけるIaaSサービスに参入しました[7]。また「成功するクラウド選び2012年度版」[8]では、「IaaSサービス完全ガイド」として、日本国内で利用可能な40サービスの調査、比較記事を掲載しています。
　一方、プライベートクラウドIaaSでは、仮想化技術の市場拡大にともない、さらに、「自動化」がキーワードとなってきています。パブリッククラウド上のIaaSに劣らないスピード感で社内に向けたIaaSを提供するケースが増えてきています。このようなパブリッククラウドIaaSに引けをとらない環境を構築するために注目されているのが、クラウド基盤ソフトで、Eucalyptus、OpenStack、CloudStackなどのクラウド基盤ソフトが登場してきています。
　クラウド基盤ソフトでは、ただ単に仮想化技術を提供するだけではなく、物理的なリソースを統合管理する機能を持ちます。これによってボタンを幾つかクリックするだけで、仮想マシンのプロビジョニング(生成・削除・設定など)を行うことができたり、予め標準の環境を設定した仮想マシンを仮想マシンイメージとして管理しておくなど、パブリッククラウドIaaSで提供されているような機能をプライベート環境にも構築することができます。実際、クラウド基盤ソフトはパブリッククラウドIaaSの構築にも活用されており、CloudStackは、インドのTata Communicationsや韓国のKorean Telecomが採用していたり、OpenStackはRackspaceが採用していたりします。

　このように、パブリック、プライベートともに利便性が向上している中、この2つを組み合わせたハイブリッドクラウドへの流れも加速しています。理由の一つには、事業継続計画(Business Continuity Plan)や災害対策(Disaster Recovery/Survivability)のために、システムやデータを遠隔地にも用意しておくということがあります。ただ、それだけでなく、自社のシステムをより効率よく運用するために、プライベートも含め複数のクラウドサービスを使い分けたり、システムをクラウド間で行き来させたりするような柔軟な利用例も出てきています。

3.2. Software as a Service (SaaS)

　SaaSはベンダー側がアプリケーションまでサービスとして提供するモデルで、Salesforce.com(SFDC)のCRMや Gmailなど、サービスにもよりますが、個人向けであれば申し込めばすぐに使えるというのが特徴です。企業におけるSaaS適用ではSFDCが有名ですが、ここ数年、SFDC以外のSaaSの導入も進み、人事管理や経費精算といった分野にまで、適用業務がさらに広がっています。
　また、SaaSを使うスタイルも増えてきています。単にWebブラウザから使うだけでなく、 社外からスマートフォンやタブレットなどのモバイル端末のアプリケーションを利用してアクセスしたり、他のアプリケーションの中に組み込まれたりする、いわゆるマッシュアップ型で利用するケースです。このような場合には、ブラウザの画面のユーザインタフェースを使うのではなく、API、特に最近はWeb APIと呼ばれる、プログラミングインタフェースを使ってアクセスします。最近では、このようなAPI経由での利用が大きく増加してきています。

3.3. Platform as a Service (PaaS)

　IaaSはインフラより上の層はユーザが管理する必要があり、SaaSはすべてをベンダー側が管理、提供するモデルです。一方で、企業には多くのカスタムアプリケーションが存在し、この開発運用をどのようにクラウド時代に適応させていくかという課題があります。そこで最近導入が進んでいるのがPaaSです。PaaSは、IaaSに加えて、ミドルウェアやフレームワークをサービスとし提供します。アプリケーションの基盤をあらかじめ用意してくれるため、アプリケーションの開発コストを小さくすることができ、ミドルウェアなどの部分の維持管理コストも削減できます。
　PaaSには大きく分けて2種類の流れがあります。1つはプロプライエタリ(Proprietary) PaaSと呼ばれているもの、もう1つがオープン(Open) PaaSと呼ばれているものです。
　プロプライエタリPaaSの代表例はSalesforce.comのForce.comやGoogle App Engineなどで、ベンダーがインフラ層からプラットフォーム層までまとめて提供してくれているタイプのPaaSです。プロバイダによって提供されているフレームワークを利用することで、非常に高い生産性を得ることが出来、インフラもプロバイダが管理してくれるためユーザは心配不要というメリットがあります。
　オープンPaaSはCloud FoundryやOpen Shift、Herokuといった、いわゆるオープンソースのPaaSです。これらのPaaSは、開発環境、動作環境、ソースコードなどが公開されています。すべてのPaaSがすべてを公開しているわけではないですが、いずれかの点でユーザに選択肢を提供しているものをオープンPaaSと呼んでいます。そのため、オープンPaaSの場合は、ユーザは自由度の高さを得られる一方で、選択したものをどのように使っていくかは、ユーザに任される部分も多く、責任範囲も大きくなる傾向にあります。メリットとしては、従来のJava等による既存試算の有効活用、つまり既存アプリのクラウド化が可能であったり、開発する際のデプロイ先をパブリッククラウドにするのか、プライベートクラウドにするのかを意識しないで良かったりする点があげられます。

図４　プロプライエタリPaaSとOpen PaaS

4. ビッグデータ時代の情報連携基盤

　本章では、この記事の主題である、ビッグデータ時代の情報連携基盤について説明していきます。

4.1. Web APIの台頭とそのメリット

　3.2節で述べたように、最近多くのSaaSベンダーが他のアプリケーションと連携し、いわゆるマッシュアップ型で利用するためにWeb APIと呼ばれるプログラミングインタフェースを公開しています。
　Programmableweb.comというWeb APIの情報を集めているサイトに登録されたWebAPIの数の遷移を示したのが次の図です。このグラフによれば、2006，7年頃には1，000未満だったWebAPI数が、2012年には6，000に達し、2012年8月には7，000を超えたと発表されています。
　最近では、Web APIを提供するサービスの種類も、Facebookや、Twitterなどのソーシャル系のSaaSはもちろん、決済サービス等を提供するクレジットカード会社や、電話のWeb APIを提供しているTwilioなど、これまではあまりインターネットに関係無かった分野にまでに広がりを見せており、電話機能をはじめ、これまでアプリケーションへの組み込みに専門知識が必要だった機能が、提供されているWeb APIを利用することで非常に容易に実現できるようになってきています。

図５　Web API数の増加
(出典: ProgrammableWeb.com[9]、グラフは著者作成)

　このWeb APIによるアプリケーションやシステム間の連携は、ここ10年ほど普及が進んできたSOA(Service Oriented Architecture)と類似点があります。SOAでは、論理的に独立した個々のサービスを組み合わせて、新たなサービス、もしくはアプリケーションを設計、構築します。WebAPIによる連携においては、公開されている個々のWebAPIを組み合わせて新しいサービスやアプリケーションを作るという点で非常に似ているのです。また、個々のWebAPIを、SOAにおけるサービスと考えれば、WebAPIによる連携を用いたアーキテクチャは、グローバルな規模でのSOAと呼べるのではないでしょうか。このように捉えることで、Web APIによるクラウドサービス間連携にも、SOAにおけるサービス連携を進める際のリスクが内在していることが解ります。それは、アプリケーションが依存するサービスが増えれば増えるほど、サービス間の連携がスパゲッティのように複雑になってしまうというリスクです。

図６　社内システムのサービス連携のスパゲッティ(イメージ)

　この課題を解決するのがESB (Enterprise Service Bus)という情報連携基盤です。ESBは、サービス間連携という責務を一手に担い、サービス連携に必要となる、プロトコル変換、メッセージ変換、フォーマット変換などを実現し、サービス間連携のスパゲッティを解消できるのです。

図７　ESBによるサービス連携スパゲッティの解消

　では、このSaaS時代の情報連携プラットフォームはなんでしょうか。それを次節から説明していきます。

4.2. iPaaS (Integration Platform as a Service)

4.2.1. iPaaSとは

　現在市場には、数多くのPaaSがありますが、ガートナーによる2011年2月発表のレポート[10]によれば、そのサービスとして提供されるプラットフォームの用途に応じて、少なくとも2種類のPaaSが台頭してくるだろうと報告されています。

• aPaaS (Application Platform as a Service)
  現在市場にあるほとんどのaPaaSはこのタイプで、3.3で説明したとおり、アプリケーション開発・運用に必要なミドルウェアやフレームワークおよび実行環境といったプラットフォームをサービスとして提供します。
• iPaaS (Integration Platform as a Service)
  その一方で、クラウドサービス間の連携に特化したプラットフォームをサービスとして提供するのがiPaaSです。もちろん連携に必要となる、プロトコル、メッセージ、データ等の変換サービスなどを提供します。

　このiPaaSという概念は、SOAにおけるESBと非常に良く似ています。機能的には、ちょうどESBのクラウドサービス版とも捉えることができます。一方、大きな相違点としては、iPaaSはグローバル規模のクラウドサービス連携を対象にしていることです。このクラウドサービス連携を対象にしているという点によって、企業内のSOAでは現れてこなかった性質がiPaaSには必要になってきます。それが、以下のビッグデータの3つのVの特徴です。

• 種類(Variety)
  図 5で紹介したようにWeb APIの数は近年爆発的に増加しており、その連携パターンは単純に考えると、その２乗に比例する勢いで増加することになります。各Web APIがそれぞれのデータを扱っていると考えれば、データ変換のパターン数はそれと同様に膨大になります。iPaaSには、そのような連携パターンの内、少しでも多くの連携パターンをサポートしている、もしくは、ユーザが変換ロジックを定義、カスタマイズできる機能をサポートしていることが必要です。
• 容量(Volume)、頻度、スピード(Velocity)
  クラウドサービスは基本的の多くはコンシューマ向けのものが多く、連携自体はサービスのバックエンドの処理だとしても、そのトラフィックはクライアント数に依存し、昨今のモバイルデバイスの増加等に伴って、サービスへのリクエスト量は膨大かつ、非常に頻度の高いものになることが予想されます。よって、iPaaSは、そのようなクライアントからのリクエストによって引き起こされる連携を適切に処理すること期待されます。また、リクエスト量は時間帯や時期によって大きく変動する場合もあります。このことから、iPaaSにはスケーラビリティが必要です。このスケーラビリティによって、膨大なリクエストが引き起こす連携を適切に処理し、スループットを低下させずにサービスを提供し続けることができるのです。

　このような意味で、iPaaSは、ビッグデータの3つのVを満たすクラウドサービス連携を担うことが期待される、ビッグデータ時代の情報連携基盤といえるのではないでしょうか。

図８　iPaaS (Integration Platform as a Service)

　既に、国内外でiPaaSを提供する企業が出てきています。国内で言えば、フュージョン・コミュニケーションズ株式会社と株式会社オージス総研が2012年10月に発表したFUSION iPaaS[12]では、楽天市場を含む様々なECモールとのシームレスな連携を実現のために、楽天市場店舗運営システムRMS(在庫・受注・決裁用のシステム)とのWeb API連携を提供するサービスを提供しています。このサービスでは、店舗の運営するECシステムがFusion iPaaSの公開しているWeb APIを利用することで、楽天の公開しているRMS APIへ連携でき、RMS APIの仕様変更などに左右されないシステムを構築することが可能になっています。

図９　FUSION iPaaSのサービスイメージ[12]

　FUSION iPaaSでは、連携プラットフォームサービスだけではなく、ECサイト事業者向けのSaaS連携ニーズをターゲットにした、ECモール向けWebAPI連携サービスも併せて提供しています。増大するSaaS連携需要に対する基盤ソリューションとしてのiPaaSですが、このように、ユーザの連携ニーズに応えた連携サービスを組み合わせたiPaaSを提供するというのも、ユーザに非常に受け入れられやすくなる一つの手法ではないかと思われます。

4.2.2. iPaaSのメリット

　iPaaSをESBのクラウド版と考えると、そのメリットも自ずと見えてきます。
　1つは、サービス間の複雑な連携スパゲッティを解消できるという点。2つめは、単一プラットフォームで連携を担っているのでガバナンスが行い易いという点が上げられます。
　3つめは、サービスとしての利点です。サービスのビジネスモデルにもよりますが、エンタープライズプラットフォームのように年間サブスクリプション(年間定額)ではなく、従量課金であれば、必要なときに必要な分だけサービスを購入して利用するというようなことが可能になりコストダウンも期待できます。例えば、データのマイグレーションを行いたい場合、これまでであればミドルウェアを購入する必要がありましたが、iPaaSであれば、マイグレーションを行う時期だけ利用し、その利用分に応じた料金を払うという事が可能になります。また、クラウドサービスとして提供されることによって、利用企業では、ESBなどのミドルウェアを自社で維持管理する必要がないというメリットもあります。
　4つめは、「スケーラビリティ」による、スループット低下のリスク軽減が期待できるという点です。オンプレミスの連携基盤であれば最悪システムダウンしてしまうようなリクエスト量であっても、iPaaSのスケーラビリティによって、iPaaSの処理能力が適切に伸縮され、安定した連携処理が継続されることが期待出来るのです。

4.2.3. iPaaSのアーキテクチャ

　筆者の考えるiPaaSのアーキテクチャを簡単に示したのが図10です。

図１０　iPaaSのアーキテクチャ概要

　左側が社内のシステムやモバイル端末、右側にクラウドサービスが存在します。 iPaaSはこの中間に位置し、連携のためのさまざまな機能を提供します。
　iPaaSの中核に位置するのが、ESBに相当する部分でプロトコル変換やフォーマット変換、メッセージのルーティングなどを処理します。単なるESB と違うのは、さまざまなクラウドサービスと接続するためのクラウドコネクタが用意されていること、連携のためのロジックを開発、管理するためのツール群が提供されていること、そしてスケーラビリティを備えていることです。そして、このiPaaSの上に個別のクラウド連携のロジックである連携アプリケーションが配備され、処理が行われるのです。

5. 終わりに

　今回は「ビッグデータ時代の情報連携基盤」と題して、昨今爆発的に増加しているWeb APIによるSaaS 連携基盤としてのiPaaS (Integration Platform as a Service)を取り上げました。今後もSaaSの数、及び、Web API連携パターンの増大は確実と見られ、ビッグデータの特徴である3つのV (Volume， Velocity， Variety)を満たすSaaS連携を担うiPaaSは、まさにビッグデータ時代の情報連携基盤と呼ぶにふさわしいサービスだと筆者は考えています。是非、SaaS連携等の実現する際には、SaaS同士を直接連携させてしまうのではなく、iPaaSを利用することを考えてみてはいかがでしょうか。

（※）オージス総研はお客様の環境や諸条件を考慮した上で、独立かつ中立的な立場としてハードウェアやソフトウェアを選択し、SI のご提案を行っております。本文での製品名などはその一部のご紹介です。

（参考文献）

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

• 「マザー工場システムに学ぼう！　グローバルITガバナンスの構築　その２」 前の記事へ
• 「業務棚卸しのススメ」 次の記事へ

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

• お問い合わせ

同一テーマ　記事一覧

• さらに見る