JP2012099062A - サービス連携システムおよび情報処理システム - Google Patents

Abstract

【課題】複数のサービスを連携させるサービス連携システムにおいて，リクエスト増加に対するシステム全体の自動スケーリング追従性を高める。
【解決手段】中間サービスを実行するクラウドは、出力レート予測部４０２によって、前段サービスの出力予測４０７とクラウド管理サーバ４０１からの情報収集応答４０４等を受け、出力レートを予測し、後段サービスに予測４０８を出力する。スケーリング制御部４０３は、前段サービスの出力予測４０７と情報収集応答４０５を受け、中間サービスに割り当てる資源を決定し、スケーリング要求４０６をクラウド管理サーバ４０１と出力レート予測部４０２出力する。
【選択図】図４Ａ

Description

ネットワークを介して、種々のサービスの提供を行うシステムに係り、特に複数の情報処理システムが連携してサービスの提供を行うサービス連携システム、及びその情報処理システムに関する。

情報処理システムの一形態として，クラウド（Cloud）が普及しつつある。非特許文献１では，クラウドコンピューティング（Cloud Computing）を「Cloud computing is a model for enabling convenient， on-demand network access to a shared pool of configurable computing resources （e.g.， networks， servers， storage， applications， and services） that can be rapidly provisioned and released with minimal management effort or service provider interaction.」と定義しており，このクラウドコンピューティングを実現する情報処理システムがクラウドである。また，用途・品質・コストなどに応じて複数のクラウドを使い分けながら，それらを連携させて単一のサービスを実現するクラウドの連携利用が台頭し、企業ICT（Information and Communication Technology）投資のROI（Return On Investment）を高めるソリューションとして，今後の益々の普及拡大が見込まれている。

このようなクラウドとして、例えば、非特許文献２などに開示された、Amazon EC2（Elastic Compute Cloud）では，その提供機能により，負荷状況に応じた自動スケーリングを実現可能である。そして、”Amazon CloudWatch”でEC2上のインスタンスごとにＣＰＵ（Central Processing Unit）ロード値やディスクＩ／Ｏ（Input/Output），ネットワークＩ／Ｏといったパフォーマンスを監視し，収集した値をもとに”Auto Scaling”でスケールアウトのポリシーを設定できる。その際，ロードバランサ，”Elastic Load Balancing”を利用して，トラフィックを分散させることが可能である。更に、複数の独立したロケーション（Availability Zone）で連携した”Auto Scaling”にも対応できる。

なお、このような自動スケーリングに関する特許として、例えば、特許文献１、２がある。

特開２００７−１２８３８２号公報 特開平１１−２８２６９５号公報

NIST Definition of Cloud Computing v15，http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc http://awsdocs.s3.amazonaws.com/EC2/2010-06-15/ec2-dg-2010-06-15.pdf

しかし、Amazon EC2の例は，あくまで単独クラウドによる自動スケーリングであり、複数クラウドを連携させて単一のサービス、すなわち連携サービスを実現する場合において，各クラウドに上記の自動スケーリングを適用すると仮定した場合には，クライアントから連携サービスへのリクエストが増加した際に，第一階層クラウドへのリクエスト増大に伴い、第一階層クラウドの割当て資源が増強され、第二階層クラウドへのリクエスト増大が起こり、更に第二階層クラウドの割当資源が増強されるという形で、順次スケーリングが連鎖していくことになる。

そのため、モニタリング間隔による遅延，新規VM（Virtual Machine）起動などによる遅延により、各クラウドの自動スケーリングに時間を要する上，各クラウドに順番に伝搬していくため，リクエスト増大に対するシステム全体の追従性が低いという問題が存在すると考えられる。

このような問題は、クラウドに限らない一般の情報処理システムを複数連携させて連携サービスを実現する場合にも、同様に発生し得る。すなわち、連携サービスを実現する各情報処理システムに対して上述した特許文献１、２のような自動スケーリング技術を適用すると仮定した場合、クライアントから連携サービスへのリクエストが増加した際に、第一階層情報処理システムへのリクエスト増大に伴い、第一階層情報処理システムの割当て資源が増強され、第二階層情報処理システムへのリクエスト増大が起こり、更に第二階層情報処理システムの割当資源が増強されるという形で、順次スケーリングが連鎖していくことになる。この場合にも、モニタリング間隔による遅延や資源割当て処理による遅延により、各情報処理システムの自動スケーリングに時間を要する上、各情報処理システムに順番に伝搬していくため、リクエスト増大に対するシステム全体の追従性が低くなる。

上述した特許文献１、２は、単一クラスタにおける自動スケーリング技術に関するものであり、上述したクラウドやクラウドに限らない情処処理システムを複数連携させて単一のサービス、すなわち連携サービスを実現する際の問題についての検討はなされていない。

本発明の目的は、上記の問題点を解決し、リクエスト増加に対して，後段の自動スケーリング開始タイミングを早めることで，自動スケーリングの追従性が高いサービス連携システムおよびその情報処理システムを提供することに有る。

上記の目的を達成するため、本発明においては、ひとつ以上の情報処理システムで実行される複数のサービスを連携させるサービス連携システムであって，複数のサービス中の第一のサービスの処理性能を予測した結果を用いて，第一のサービスの後段の第二のサービスに割り当てる資源を決定する構成のサービス連携システムを提供する。

また、上記の目的を達成するため、本発明においては、上記のサービス連携システムにおける情報処理システムは、第一のサービスの処理性能を予測した結果が入力され、当該予測結果に基づき第二のサービスの処理性能を予測する性能予測部と，第二のサービスに割り当てる資源を決定する資源割当て制御部とを有する構成のサービス連携システムを提供する。

更に、上記の目的を達成するため、本発明においては、ネットワークを介して接続される他の情報処理システムと連携して、複数のサービスを提供する情報処理システムであって、管理部と、管理部と接続され、管理部によって管理される複数のサーバとを含み、サーバは、仮想サーバプログラムを記憶する記憶部と、仮想サーバプログラムを実行して仮想サーバを実現する処理部とを備え、処理部は、複数のサービス中の第一のサービスの処理性能を予測した結果を用いて，第一のサービスの後段の第二のサービスに割り当てる資源を決定して割当てる構成の情報処理システムを提供する。

複数情報処理システムを用いるサービス連携システムにおいて、予測性能を後段の情報処理システムに伝搬できるので、サービス要求の変動に応じて各情報処理システムの資源割当てを素早く適応することができる。

第１の実施例のサービス連携システムの全体構成を示す図である。 第１の実施例に係る、サーバの一構成例を示す図である。 第１の実施例に係る、クラウド管理サーバの一構成例を示す図である。 第１の実施例に係る、出力レート予測部およびスケーリング制御部の一例を示す図である。 第１の実施例に係る、出力レート予測部およびスケーリング制御部の他の例を示す図である。 第１の実施例に係る、スケーリング制御部の他の例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションを示す図である。 第１の実施例に係る、スケーリング制御部のバリエーションを示す図である。 第１の実施例に係る、クラウドに対する出力レート予測部およびスケーリング制御部の組合せを示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの一例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの他の例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの他の例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの他の例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの他の例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの他の例を示す図である。 第１の実施例に係る、出力レート予測部のバリエーションの他の例を示す図である。 第１の実施例に係る、サービス連携システムにおけるワークフローを示す図である。 第１の実施例に係る、図９のワークフローのサービスごとの出力レート予測部およびスケーリング制御部の関係を示す図である。 第１の実施例に係る、クラウド管理サーバがクラウド利用者に提供するＡＰＩ（Application Program Interface）種別を示す図である。 第１の実施例に係る、スケーリング制御部Ａの処理フローの一例を示す図である。 第１の実施例に係る、スケーリング制御部Ｂの処理フローの一例を示す図である。 第１の実施例に係る、出力レート予測部Ａの処理の一例を示す図である。 第１の実施例に係る、出力レート予測部Ｅの処理の一例を示す図である。 第１の実施例に係る、出力レート予測部Ｄの処理の一例を示す図である。 第１の実施例に係る、出力レート予測部Ｄで用いる関数ｆ（ｘ）の一例を示す図である。

以下、本発明を実施するための形態である実施例を図面に従い説明する。なお、本明細書において、ネットワークを介して種々のサービスの提供を行う、クラウドで代表されるシステムを情報処理システムと呼び、複数の情報処理システムが連携して種々のサービスの提供を行うシステムを、サービス連携システムと呼ぶこととする。

図１は、第１の実施例のサービス連携システムの全体構成を示す図である。

同図において、１０１−１、１０１−２‐‐‐、１０１−Ｎはクラウド１、２、‐‐‐、Ｎを示す。１０２は広域網を例示したネットワーク、１０３は複数のクライアント端末である。各々のクラウド１０１は、ネットワーク１０２に接続されるファイアウォール１０４とファイアウォール１０４に接続される負荷分散装置１０５、負荷分散装置１０５に接続されるネットワークスイッチ１０６、複数のサーバ１０７、複数のサーバ１０７に接続されたネットワークスイッチ１０８、ネットワークスイッチ１０８に接続された、クラウド管理部として機能するクラウド管理サーバ１０９とから構成される。

図２、図３は、それぞれ本実施例におけるサーバ１０７、クラウド管理サーバ１０９の一構成例を示す図である。図２に示すようにサーバ１０７は、通常のコンピュータ構成を有し、それぞれネットワークスイッチ１０６、１０８に接続されるネットワークインタフェース２０１、２０８と、これらに接続された内部バス２０４、この内部バス２０４に接続された処理部を構成するCPUなどのプロセッサ２０２、記憶部となるディスク２０３、メモリ２０５から構成される。メモリ２０５上には、プロセッサ２０２で実行される仮想サーバ管理プログラム２０６と仮想サーバ管理プログラム２０７が記憶されている。複数のサーバ１０７各々は、所望の機能やサービスを実現する複数の仮想サーバプログラム２０６を実行することで、所望の機能やサービスを実現する複数の仮想サーバを構築することができる。

同様に、図３に示す、クラウド管理部であるクラウド管理サーバ１０９は、ネットワークスイッチ１０８に接続されたネットワークインタフェース３０１に接続される内部バス３０４に接続されたプロセッサ３０２、ディスク３０３、及びメモリ３０５で構成され、メモリ３０５にはプロセッサ３０２で実行されるクラウド管理プログラム３０６が記憶されている。クラウド管理サーバ１０９は、プロセッサ３０２でクラウド管理プログラム３０６を実行することにより、情報処理システムであるクラウド１０１内の複数のサーバ１０７を管理する管理部として機能する。

図４Ａ、図４Ｂ、図４Ｃは、第１の実施例に係るサービス連携システムのクラウド内に形成される性能予測部として機能する出力レート予測部と、資源割当て制御部として機能するスケーリング制御部とからなるフルセットの具体例を示す図である。図４Ａ、図４Ｂ、図４Ｃは、複数の情報処理システムが連携して種々のサービスの提供を行うサービス連携システムのワークフロー上の、中間サービス、始点サービス、終点サービスにそれぞれ対応している。

なお、図４Ａ、図４Ｂ、図４Ｃにおける出力レート予測部４０２およびスケーリング制御部４０３は、図１に示した、情報処理システムである各クラウド内の複数のサーバや、それらのサーバに形成される複数の仮想サーバ上のプログラム処理で実現できる。

図４Ａは、ワークフロー上の中間サービスに対応する例であり、性能予測部である出力レート予測部４０２と資源割当て制御部であるスケーリング制御部４０３で構成される。図１のクラウド１０１中のクラウド管理サーバ１０９に対応するクラウド管理サーバ４０１は、出力レート予測部４０２とスケーリング制御部４０３との間で、情報収集要求・情報収集応答４０４、４０５を行う。同図に示した中間サービスの場合、一つ以上の前段サービスからの出力レート予測４０７を受け、出力レート予測部４０２とスケーリング制御部４０３に入力する。出力レート予測部４０２は、この出力レート予測４０７や情報収集応答４０４等に基づき、当該サービスに対する出力レートを予測し、その予測結果を出力レート予測４０８として、一つ以上の後段サービスへ送る。なお、これら前段のサービス、中間サービス、後段のサービスを含む複数のサービスを連携させるサービス連携システムにおいて、前段のサービスを第一のサービスとすると、中段のサービスは第二のサービス、後段のサービスは第三のサービスと呼ぶことができる。

スケーリング制御部４０３は同様に、一つ以上の前段サービスからの出力レート予測４０７や、情報収集応答４０５を受け、スケーリング要求４０６を出力し、クラウド管理サーバ４０１や出力レート予測部４０２に送る。

図４Ｂは、始点サービスに対応する例であり、図４Ａ同様、出力レート予測部４０２とスケーリング制御部４０３で構成される。クラウド管理サーバ４０１は、出力レート予測部４０２とスケーリング制御部４０３それぞれとの間で、情報収集要求・情報収集応答４０４、４０５を行う。同図に示した始点サービスの場合、出力レート予測部４０２は、クラウド管理サーバ４０１からの情報収集応答４０４とスケーリング制御部４０３からのスケーリング要求４０６に基づき、出力レート予測を行い、一つ以上の後段サービスへ出力レート予測４０８を送る。スケーリング制御部４０３は、クラウド管理サーバ４０１からの情報収集応答４０５に基づき、スケーリング要求４０６を出力し、クラウド管理サーバ４０１や出力レート予測部４０２に送る。

図４Ｃは、終点サービスに対応する例であり、出力制御部は無く、スケーリング制御部４０３のみで構成されている。このスケーリング制御部４０３は後で説明するスケーリング制御部Ａに対応する。同図の構成の場合、一つ以上の前段サービスから出力レート予測４０７と情報収集応答４０５を受けたスケーリング制御部４０３は、クラウド管理サーバ４０１にスケーリング要求４０６を出力する。

続いて、図５、６それぞれに、本実施例のサービス連携システムにおける、出力レート予測部とスケーリング制御部のバリエーションを、図７に本実施例のクラウドに対する出力レート予測部およびスケーリング制御部のバリエーションの組合せを示す。

図５のバリエーションテーブル５０１において、前段サービスからの出力レート予測を入力５０２、スケーリング制御部からのスケーリング要求を入力５０３、クラウド管理サーバからの情報収集応答を入力５０４の項目に、それぞれ有り（○）、無し（×）、対応なし（−）を示した。５０５は出力レート予測部の利用箇所が後で説明するワークフロー上の始点、中間、終点かを示している。

図６のバリエーションテーブル６０１において、６０２に前段からの出力レート予測を入力の有無を、６０３にはスケーリング制御部の利用箇所、すなわち後で説明するワークフロー上の始点、中間、終点を示した。

図７の組合せテーブル７０１において、組合せ番号７０２に対応し、利用箇所７０３、出力レート予測部７０４、スケーリング制御部７０５を示した。なお、出力レート予測部とスケーリング予測部は，当該クラウド中の別々のサーバ、仮想サーバで動作させてもよいし，両方をまとめてひとつのサーバ、仮想サーバで動作させてもよい。更に、一方または両方を，当該クラウド外のサーバや仮想サーバで動作させてもよい。なお、組合せ番号１６の「出力レート予測部なし，スケーリング制御部Ｂ」が、ワークフローの全段に渡っている場合の構成は、従来の構成に相当する。

図８Ａ〜図８Ｇを用いて、図５のバリエーションに示したスケーリング予測部Ａ〜Ｇの接続構成について説明する。なお、図８Ａ〜図８Ｇにおいて、クラウド管理サーバ４０１とスケーリング制御部４０３の入出力は、出力レート予測部４０２に関係するもののみを図示し、後は省略した。なお、数番は図４Ａ〜Ｃに示した数番と対応するものとなっている。

まず、図８Ａに、図５のテーブル中の出力レート予測部Ａを図示した。図８Ａの出力レート予測部４０２は、図４Ａの構成と動作に対応しているため、ここでは説明は省略する。なお、出力レート予測部Ａの処理内容については後で図１３Ａを用いて説明する。

図８Ｂに、図５のテーブル５０１中の出力レート予測部Ｂの構成の一例を示す。出力レート予測部４０２は、図５に示すように、クラウド管理サーバ４０１からの情報収集応答が入力されないので、一つ以上の前段サービスからの出力レート予測４０７とスケーリング制御部４０１からのスケーリング要求４０５を受けて予測を行い、出力レート予測４０８を出力する。利用箇所は、図５のテーブルに示したように中間サービスとなる。

図８Ｃは、図５のテーブル中の出力レート予測部Ｃの構成の一例を示す。出力レート予測部４０２は、一つ以上の前段サービスからの出力レート予測４０７とクラウド管理サーバ４０１からの情報収集応答４０４を受けて予測を行い、出力レート予測４０８を出力する。出力レート予測部４０２には、図５に示すように、スケーリング制御部４０１からのスケーリング要求４０５が入力されない。利用箇所は中間サービスとなる。

図８Ｄは、図５のテーブル中の出力レート予測部Ｄの構成の一例を示す。図５に示したように、出力レート予測部Ｄには、一つ以上の前段サービスからの出力レート予測４０７のみが入力され、出力レート予測４０７に基づく予測を行って、出力レート予測４０８を出力する。この出力レート予測部Ｄの処理内容については後で説明する。

図８Ｅは、図５のテーブル中の出力レート予測部Ｅの構成の一例を示す。図５に示したように、出力レート予測部Ｅには、利用箇所は始点であり、一つ以上の前段サービスからの出力レート予測は入力されず、クラウド管理サーバ４０１からの情報収集応答４０４と、スケーリング制御部４０１からのスケーリング要求４０５とに基づき予測を行い、出力レート予測４０８を１つ以上の後段サービスへ出力する。この出力レート予測部Ｅの処理内容については後で説明する。

図８Ｆは、出力レート予測部Ｆの構成の一例を示す。図５のテーブル５０１に示したように、出力レート予測部Ｆは、スケーリング制御部４０１からのスケーリング要求４０５のみに基づき予測を行い、出力レート予測４０８を１つ以上の後段サービスへ出力する。利用箇所は、始点サービスとなる。

図８Ｇは、出力レート予測部Ｇの構成の一例を示す。図５のテーブル５０１に示したように、出力レート予測部Ｇは、クラウド管理サーバ４０１からの情報収集応答４０４のみを受けて予測を行い、出力レート予測４０８を１つ以上の後段サービスへ出力する。

図９、図１０に、それぞれ本実施例のサービス連携システムのワークフローと、対応するサービス毎の出力レート予測部およびスケーリング制御部の関係を示した。図９に見るように、本実施例のサービス連携システムは、クライアント端末９０１からのサービス構築指示に従い、対応する処理を実行する。なお、クライアント端末９０１は、図１における複数のクライアント端末１０３に対応するものとする。

図９において、まずクライアント端末９０１から、クラウド１上のサービスＡの構築の指示、またクライアント端末９０１からクラウド５上のサービスＥの構築指示がなされる。同様に、クライアント端末９０１から、クラウド２上のサービスＢの構築指示がなされる。このサービスＢには、前段のクラウド１上のサービスＡ、クラウド５上のサービスＥの処理結果である出力が入力される。すなわち、サービスＢはサービスＡ或いはサービスＥの処理結果を用いてその処理を行う。

更に、クライアント端末９０１から、クラウド３上のサービスＣの構築指示と、クラウド５上のサービスＦの構築指示、クラウド４上のサービスＤの構築指示がなされる。なお、図９に示すように、クラウド２上のサービスＢは、その処理結果によって次段としてクラウド３上のサービスＣ、またはクラウド５上のサービスＦの何れかに分岐する。また、クラウド４上のサービスＤはクラウド３上のサービスＣの処理結果である出力を用いて処理を行う。

図１０は、上述の通り、図９に示した本実施例のワークフローの一例に対応する、サービス毎の出力レート予測部４０２とスケーリング制御部４０３の関係を示す図である。同図において、１００１は、図９のクラウド１上のサービスＡ９０１に対応する出力レート予測部とスケーリング制御部を示し、それぞれ出力レート予測部Ｅとスケーリング制御部Ｂとなる。同様に、１００２〜１００６は、図９における各サービス９０２〜９０６に対応する出力レート予測部とスケーリング制御部を示している。

なお、クラウド３は，クラウド利用者に対して情報収集要求やスケーリング要求のインタフェースを提供していないＳａａＳ（Software as a Service）である。そのため、クラウド３上のサービスＣ向けの出力レート予測部Ｄは，クラウド３の外，例えばクラウド４内の仮想サーバを用いて実現するものとする。一方、クラウド１，クラウド２，クラウド４，クラウド５は，クラウド利用者に対して情報収集要求やスケーリング要求のインタフェースを提供するＩａａＳ（Infrastructure as a Service）であり、これらの出力レート予測部やスケーリング制御部は，各クラウド内の仮想サーバを用いて実現することができる。

同図から明らかなように、クラウド１上のサービスＡ向け１００１及びクラウド５上のサービスＥ向け１００５は始点として、クラウド２上のサービスＢ向け１００２、クラウド３上のサービスＣ向け１００３は中間として、クラウド４のサービスＤ向け１００４とクラウド５上のサービスＦ向け１００６は終点として機能する。

図１１に本実施例の複数のクラウドに対応したクラウド管理サーバ１０９が各クラウド利用者に提供するＡＰＩ（Application Program Interface）の一欄を示す図である。図９に示したワークフローに対応し、サービス連携システムを構成する５つのクラウド１〜５の内、上述の通り、クラウド１、２、４、５がＩａａＳ（Infrastructure as a Service）として機能する場合の提供ＡＰＩである。なお、クラウド３は、上述の通り、ＳａａＳ（Software as a Service）としてのみ機能する。

図１１に見るように、ＡＰＩ種別１１０１として、仮想サーバ作成、仮想サーバ廃棄、負荷分散装置設定、ファイアウォール設定、情報収集、スケーリングが有り、それぞれ機能１１０２を有する。仮想サーバ作成は、ＣＰＵ性能・メモリ量・ディスク量の異なる仮想サーバタイプを指定して一つ以上の仮想サーバを作成した上で、仮想サーバ上で指定したプログラムを実行する機能を有する。仮想サーバ廃棄は、指定した仮想サーバを停止し，削除する機能を提供する。

また、負荷分散装置設定は、クラウド外からクラウド内への通信の通信フロー（送信元アドレス，送信先アドレス，リクエスト種別など）を指定し，指定した仮想サーバ群にその通信を振り分けるよう設定する機能を持つ。ファイアウォール設定は、通信フロー（送信元アドレス，送信先アドレス，リクエスト種別など）を指定し，クラウドの中と外での通信を許可または拒絶するよう設定を行う機能を有する。

情報収集は、起動している仮想サーバや通信トラフィックに関する各種情報の収集、例えば仮想サーバ数，各仮想サーバのタイプ，各仮想サーバのＣＰＵ負荷率・メモリ使用量・ディスクＩ／Ｏ量・通信量，単位時間あたりの入力要求数（入力レート），単位時間あたりの出力結果数（出力レート）などの収集を行う機能である。最後に、スケーリングは、仮想サーバ群によって実現しているサービスに対して，仮想サーバ作成または仮想サーバ廃棄と，それに応じた負荷分散装置設定機能である。

一方、クラウド３には、上述の通りＳａａＳであり、このようなＡＰＩは無く、クラウド全体として、図９に示したサービスＣを実行するインタフェースのみをクラウド利用者に提供する。クラウド内部でのスケーリングなどの各種設定は、クラウド３の運用事業者が適宜行っており、クラウド利用者に提示することはない。

続いて、図９、図１０、図１１等を参照しながら、本実施例の図９に例示されたワークフローにおける、各クラウドへのサービス配備による連携サービス構築手順について説明する。

クライアント端末１０３は、クラウド１のクラウド管理サーバ１０９に対して，サービスＡを構築するよう指示する。その具体的には以下の手順となる。

（１）図１１の仮想サーバ作成ＡＰＩを用いて，サービスＡを実現するプログラムを実行する仮想サーバをいくつか（例えば３個）作成するよう指示する。ここで仮想サーバタイプは１種類に統一する。

（２）負荷分散装置設定ＡＰＩを用いて，外部からのサービス実行要求を，作成した仮想サーバ群に負荷分散するよう指示する。

（３）仮想サーバ作成ＡＰＩを用いて，図４Ｂの始点サービスに対応し、出力レート予測部Ｅを実現するプログラムを実行する仮想サーバ，スケーリング制御部Ｂを実現するプログラムを実行する仮想サーバを作成するよう指示する。

（４）ファイアウォール設定ＡＰＩを用いて，サービスＡの実行要求や出力結果，出力レート予測を，クラウド外と通信できるよう指示する。

同様に、クライアント端末１０３からクラウド５のクラウド管理サーバ１０９に対して，サービスＥを構築するよう指示する。この指示に基づくサービスＥの構築手順は、上述したクラウド１へのサービスＡ構築の手順と同様であり、説明は省略する。

同様に、クライアント端末１０３から、クラウド２のクラウド管理サーバ１０９に対して，サービスＢを構築するよう指示する。具体的には以下の手順が実行される。

（１）仮想サーバ作成ＡＰＩを用いて，サービスＢを実現するプログラムを実行する仮想サーバをいくつか（例えば３個）作成するよう指示する。ここで仮想サーバタイプは１種類に統一する。

（２）負荷分散装置設定ＡＰＩを用いて，外部からのサービスＢ実行要求を作成した仮想サーバ群に負荷分散するよう指示する。

（３）仮想サーバ作成ＡＰＩを用いて，図４Ａに示した出力レート予測部Ａを実現するプログラムを実行する仮想サーバ，スケーリング制御部Ａを実現するプログラムを実行する仮想サーバを作成するよう指示する。

（４）ファイアウォール設定ＡＰＩを用いて，サービスＢの実行要求や出力結果，出力レート予測や他クラウドからの出力レート予測を，クラウド外と通信できるよう指示する。

同様に、クライアント端末１０３からクラウド４のクラウド管理サーバ１０９に対して，サービスＤを構築するよう指示する。具体的には以下の手順となる。

（１）仮想サーバ作成ＡＰＩを用いて，サービスＤを実現するプログラムを実行する仮想サーバをいくつか（例えば３個）作成するよう指示する。仮想サーバタイプは１種類に統一する。

（２）負荷分散装置設定ＡＰＩを用いて，外部からのサービスＤ実行要求を作成した仮想サーバ群に負荷分散するよう指示する。

（３）仮想サーバ作成ＡＰＩを用いて，スケーリング制御部Ａを実現するプログラムを実行する仮想サーバ，クラウド３上のサービスＣ向けの出力レート予測部Ｄを実現するプログラムを実行する仮想サーバを作成するよう指示する。後者は、先に説明した通り、ＳａａＳであるクラウド３上のサービスＣ向けの出力レート予測部Ｄを実現するための仮想サーバを作成するためである。

（４）ファイアウォール設定ＡＰＩを用いて，サービスＤの実行要求や出力結果，他クラウドからの出力レート予測を，クラウド外と通信できるよう指示する。

同様に、クライアント端末１０３からクラウド５のクラウド管理サーバ１０９に対して，サービスＦを構築するよう指示する。具体的には同様に、以下の手順となる。

（１）仮想サーバ作成ＡＰＩを用いて，サービスＦを実現するプログラムを実行する仮想サーバをいくつか（例えば３個）作成するよう指示する。仮想サーバタイプは1種類に統一する。

（２）負荷分散装置設定ＡＰＩを用いて，外部からのサービスＦ実行要求を作成した仮想サーバ群に負荷分散するよう指示する。

（３）仮想サーバ作成ＡＰＩを用いて，スケーリング制御部Ａを実現するプログラムを実行する仮想サーバを作成するよう指示する。

（４）ファイアウォール設定ＡＰＩを用いて，サービスＦの実行要求や出力結果，他クラウドからの出力レート予測を，クラウド外と通信できるよう指示する。

続いて、本実施例のサービス連携システムにおける、各クラウドによって実現される出力レート予測部４０２とスケーリング制御部４０３のバリエーションの具体的な機能構成例を図１２Ａ、図１２Ｂ、図１３Ａ、図１３Ｂ、図１３Ｃを用いて説明する。

図１２Ａは、図６のテーブル中のスケーリング制御部Ａの処理フローの一例を示す図である。先に述べたように、出力レート予測部やスケーリング制御部は、サーバや仮想サーバにおいて実行されるプログラムで実現できる。以下の他の機能構成例においても同様である。図１２Ａにおいて、スケーリング制御部Ａの処理が開始（ステップ１２００、以下カッコ内ステップ省略）されると、クラウド管理サーバ４０１に対して情報収集要求４０５を発行し，本サービスに関連する「現在の入力レート」、「仮想サーバごとのＣＰＵ負荷率」、「現在の仮想サーバ台数（ＰＶＳ）」を情報収集応答４０５として取得する（１２０１）。

続いて、スケーリング処理部Ａは、同図のステップ１２０２に示すように、（少なくも一つの前段サービスから本サービスへの出力レート予測）の総和をＸＩＲ（Expected Input Rate）とし、ｍａｘ（１， ＸＩＲ ÷ 「現在の入力レート」）をＩＲＶ（Input Rate Variation rate）とし、「仮想サーバごとのＣＰＵ負荷率」の相加平均をＡＣＬ（Average CPU Load）とする。そして、ステップ１２０３において、最大仮想サーバ台数（３０台）より「現在の仮想サーバ台数（ＰＶＳ）」が小さく、かつ相加平均（ＡＣＬ） ×ＩＲＶ ≧ ６０％かを判定する。

判定の結果がＹＥＳの場合、ステップ１２０４に進み、ステップ１２０４に示す二つの値の内、何れか小さい値をＶＭＰ（Virtual Machine， Plus）に設定する。そして、ステップ１２０５において、スケーリングＡＰＩを用いてＶＭＰ台の仮想サーバ作成を要求し、ステップ１２０１に戻る。

一方、ステップ１２０３における判定結果がＮＯの場合、ステップ１２０６に進み、「現在の仮想サーバ台数（ＰＶＳ）」が最小仮想サーバ台数（３台）より大きく、かつ相加平均（ＡＣＬ） ×ＩＲＶ ≦ ４０％かを判定する。判定の結果がＹＥＳの場合、ステップ１２０７に進み、スケーリングＡＰＩを用いて1台の仮想サーバ削除を要求する。その後、ステップ１２０１に戻る。判定の結果がＮＯの場合も同様に、ステップ１２０１に戻る。

同様に、図１２Ｂは、図６のテーブル６０１中の前段サービスから出力レート予測がないスケーリング制御部Ｂの処理フローの一例を示す図である。図１２Ａと同様、ステップ１２１０で処理が開始されると、クラウド管理サーバ４０１に対して情報収集要求４０５を発行し，本サービスに関連する「仮想サーバごとのＣＰＵ負荷率」、「現在の仮想サーバ台数（ＰＶＳ）」を取得する（１２１１）。
そして、「仮想サーバごとのＣＰＵ負荷率」の相加平均をＡＣＬとする（１２１２）。そして、ステップ１２１３において、最大仮想サーバ台数（３０台）より「現在の仮想サーバ台数（ＰＶＳ）」が小さく、かつ相加平均（ＡＣＬ）≧ ６０％かを判定する。

判定の結果がＹＥＳの場合、ステップ１２１４に進み、ステップ１２１４に示す二つの値の内、何れか小さい値をＶＭＰに設定する。そして、ステップ１２１５において、スケーリングＡＰＩを用いてＶＭＰ台の仮想サーバ作成を要求し、ステップ１２１１に戻る。

一方、ステップ１２１３における判定結果がＮＯの場合、ステップ１２１６に進み、「現在の仮想サーバ台数（ＰＶＳ）」が最小仮想サーバ台数（３台）より大きく、かつ相加平均（ＡＣＬ）≦ ４０％かを判定する。判定の結果がＹＥＳの場合、ステップ１２１７に進み、スケーリングＡＰＩを用いて1台の仮想サーバ削除を要求する。その後、ステップ１２１１に戻る。判定の結果がＮＯの場合も同様に、ステップ１２１１に戻る。

以上説明した、本実施例のスケーリング制御部により、前段サービスからの出力レート予測の有る場合と無い場合に、スケーリング制御を実行することができる。

図１３Ａは本実施例における出力レート予測部Ａの処理の一例を示す図である。処理が開始されると（１３００）、図８Ａで説明したように、出力レート予測部Ａは、クラウド管理サーバ４０１に対して情報収集要求４０４を発行し，本サービスに関連する「現在の入力レート」、「仮想サーバごとのＣＰＵ負荷率」、「現在の仮想サーバ台数」を情報収集応答４０４として取得する（１３０１）。
（少なくとも一つの前段サービスから本サービスへの出力レート予測）の総和をＸＩＲ，（「仮想サーバごとのＣＰＵ負荷率」の総和 ÷ （「現在の仮想サーバ台数」 ＋ スケーリング制御部で要求している仮想サーバ作成台数 − スケーリング制御部で要求している仮想サーバ削除台数）をＸＡＣＬ（Expected Average CPU Load）とする（１３０２）。また、本サービス出力の宛先となるサービス群を”Ｑ”とする（１３０３）。そして、ステップ１３０４において、サービス群Ｑが空集合か否かをチェックし、空集合の場合には最初に戻る。

空集合で無い場合、Ｑの一要素を選択し、ＤＤとし、ＱからＤＤを取り除く（１３０５）。クラウド管理サーバ４０１に対して情報収集要求４０４を発行し，本サービスに関連する「ＤＤへの現在の出力レート」を取得（１３０６）、「ＤＤへの現在の出力レート」 × ＸＩＲ ÷ 「現在の入力レート」 × ｍｉｎ（１，６０％ ÷ ＸＡＣＬ）を「ＤＤへの出力レート予測」とし（１３０７）、この「ＤＤへの出力レート予測」を、ＤＤ向けの出力レート予測部やスケーリング制御部に通知する（１３０８）。

図１３Ｂに，利用箇所が始点に位置する出力レート予測部Ｅの処理の一例を示す。図１３Ａと同様に処理が開始されると（１３１０）、図８Ｅで説明したように、出力レート予測部Ｅは、クラウド管理サーバ４０１に対して情報収集要求４０４を発行し，本サービスに関連する「仮想サーバごとのＣＰＵ負荷率」、「現在の仮想サーバ台数」を取得する（１３１１）。そして、（「仮想サーバごとのＣＰＵ負荷率」の総和 ÷ （「現在の仮想サーバ台数」 ＋ スケーリング制御部で要求している仮想サーバ作成台数 − スケーリング制御部で要求している仮想サーバ削除台数）をＸＡＣＬとする（１３１２）。また、本サービス出力の宛先となるサービス群をＱとする（１３１３）。そして、ステップ１３１４において、サービス群Ｑが空集合か否かをチェックし、空集合の場合には最初に戻る。

空集合で無い場合、Ｑの一要素を選択し、ＤＤとし、ＱからＤＤを取り除く（
１３１５）。クラウド管理サーバ４０１に対して情報収集要求４０４を発行し，本サービスに関連する「ＤＤへの現在の出力レート」を取得（１３１６）、「ＤＤへの現在の出力レート」× ｍｉｎ（１，６０％ ÷ ＸＡＣＬ）を「ＤＤへの出力レート予測」とし（１３１７）、この「ＤＤへの出力レート予測」を、ＤＤ向けの出力レート予測部やスケーリング制御部に通知する（１３１８）。

同様に、図１３Ｃにクラウド３上のサービスＣ向けの出力レート予測部Ｄの処理の一例を示した。処理が開始されると（１３２０）、（少なくとも一つの前段サービスから本サービスへの出力レート予測）の総和をＸＩＲとし（１３２１）、
図１４に定義するｆ（ＸＩＲ）を「クラウド４上のサービスＤへの出力レート予測」とし（ステップ１３２２）、「クラウド４上のサービスＤへの出力レート予測」をクラウド４上のサービスＤ向けのスケーリング制御部に通知する（１３２３）。

図１４の１４０１、１４０２に示すように、ｆ（ｘ）は“ｘ”の値により変化するが、このｆ（ｘ）は入力レートに対する出力レートの関係を予め測定し、関数化したものである。

以上、本発明の一実施例を詳述したが、本発明は上記の実施例の構成に限定されるものでないことは言うまでもない。サービス連携システムを構成する複数の情報処理システムとして例示した複数のクラウドは、同一の事業者が提供する場合であっても、異なる事業者が提供する場合であっても本発明を実現できることは言うまでもない。提供され、連携する複数のサービスは、異なるクラウドで実現される場合のみならず、一部或いは全てのサービスが同一のクラウドで実現される場合であっても、本発明を実施することができる。

ネットワークを介して、種々のサービスの提供を行うシステム、特に複数の情報処理システムが連携してサービスの提供を行うサービス連携システム、及びその情報処理システムとして有用である。

１０１…クラウド
１０２…広域網等のネットワーク
１０３…クライアント端末
１０４…ファイアウォール
１０５…負荷分散装置
１０６、１０８…ネットワークスイッチ
１０７…サーバ
１０９、４０１…クラウド管理サーバ
２０１、２０８、３０１…ネットワークインタフェース
２０２、３０２…プロセッサ
２０３、３０３…ディスク
２０４、３０４…内部バス
２０５、３０５…メモリ
２０６…仮想サーバプログラム
２０７…仮想サーバ管理プログラム
３０６…クラウド管理プログラム
４０２…出力レート予測部
４０３…スケーリング制御部
４０４、４０５…情報収集要求
４０６…スケーリング要求
４０７、４０８…出力レート予測
５０１、６０１…バリエーションテーブル
７０１…組合せテーブル。

Claims (20)

1. ひとつ以上の情報処理システムで実行される複数のサービスを連携させるサービス連携システムであって，
   前記複数のサービス中の第一のサービスの処理性能を予測した結果を用いて，前記複数のサービス中の第二のサービスに割り当てる資源を決定する、
   ことを特徴とするサービス連携システム。
2. 請求項１に記載のサービス連携システムであって、
   前記第一のサービス処理性能を予測した結果を用いて、前記第二のサービスの処理性能を予測する、
   ことを特徴とするサービス連携システム。
3. 請求項１に記載のサービス連携システムであって，
   前記第二のサービスに割り当てる資源の決定を，前記第二のサービスを実行する前記情報処理システムで行う、
   ことを特徴とするサービス連携システム。
4. 請求項１に記載のサービス連携システムであって，
   前記第一のサービスの処理性能の予測を、前記第一のサービスを実行する前記情報処理システムで行う、
   ことを特徴とするサービス連携システム。
5. 請求項１に記載のサービス連携システムであって，
   前記第二のサービスは、前記第一のサービスの処理結果を用いて処理を行う、
   ことを特徴とするサービス連携システム。
6. 請求項１に記載のサービス連携システムであって，
   第一のサービスの処理性能を予測する第一の性能予測部と，第二のサービスの処理性能を予測する第二の性能予測部とを備え、
   前記第一の性能予測部による前記第一のサービスの処理性能の予測結果を用いて，前記第二の性能予測部が前記第二のサービスの処理性能を予測する、
   ことを特徴とするサービス連携システム。
7. 請求項１に記載のサービス連携システムであって，
   前記第一のサービスと前記第二のサービスが異なる前記情報処理システムで実行される、
   ことを特徴とするサービス連携システム。
8. 請求項１に記載のサービス連携システムであって、前記第一のサービスの処理性能を予測した結果が入力され、当該予測結果に基づき前記第二のサービスの処理性能を予測する性能予測部と，前記第二のサービスに割り当てる資源を決定する資源割当て制御部とを有する、
   ことを特徴とするサービス連携システム。
9. 請求項８に記載のサービス連携システムであって、
   前記資源割当て制御部は、前記第一のサービスの処理性能の予測結果を用いて，前記第二のサービスに割り当てる資源を決定する、
   ことを特徴とするサービス連携システム。
10. 請求項８に記載のサービス連携システムであって，
    前記性能予測部は、前記資源割当て制御部が決定した前記第一のサービスに割り当てる資源の情報を用いて，前記第一のサービスの処理性能を予測する、
    ことを特徴とするサービス連携システム。
11. ネットワークを介して接続される他の情報処理システムと連携して複数のサービスを提供する情報処理システムであって、
    管理部と、前記管理部と接続され、前記管理部によって管理される複数のサーバとを含み、前記サーバは、プログラムを記憶する記憶部と、前記プログラムを実行する処理部とを備え、
    前記処理部は、
    前記複数のサービス中の第一のサービスの処理性能を予測した結果を用いて，前記複数のサービス中の第二のサービスに割り当てる資源を決定して割当てる、
    ことを特徴とする情報処理システム。
12. 請求項１１に記載の情報処理システムであって、
    前記処理部は、
    前記第一のサービス処理性能を予測した結果を用いて、前記第二のサービスの処理性能を予測する、
    ことを特徴とする情報処理システム。
13. 請求項１２に記載の情報処理システムであって、
    処理性能の予測を行った前記第二のサービスの処理を実行する、
    ことを特徴とする情報処理システム。
14. 請求項１２に記載の情報処理システムであって、
    前記処理部は、前記第一のサービスの処理結果を用いて、前記第二のサービスの処理を行う、
    ことを特徴とする情報処理システム。
15. 請求項１２に記載の情報処理システムであって、
    前記処理部は、
    前記第一のサービスの処理性能を予測した結果が入力され、当該予測結果に基づき前記第二のサービスの処理性能を予測する性能予測部と，前記第二のサービスに割り当てる資源を決定する資源割当て制御部とを備える、
    ことを特徴とする情報処理システム。
16. ネットワークを介して接続される他の情報処理システムと連携して複数のサービスを提供する情報処理システムであって、
    管理部と、前記管理部と接続され、前記管理部によって管理される複数のサーバとを含み、前記サーバは、プログラムを記憶する記憶部と、前記プログラムを実行する処理部とを備え、
    前記処理部は、
    前記複数のサービス中の第一のサービスの処理性能を予測した結果を用いて，前記複数のサービス中の第二のサービスの処理性能を予測する、
    ことを特徴とする情報処理システム。
17. 請求項１６に記載の情報処理システムであって、
    前記処理部は、
    前記第一のサービス処理性能を予測した結果を用いて、前記第二のサービスの処理性能を予測する、
    ことを特徴とする情報処理システム。
18. 請求項１６に記載の情報処理システムであって、
    処理性能の予測を行った前記第二のサービスの処理を実行する、
    ことを特徴とする情報処理システム。
19. 請求項１６に記載の情報処理システムであって、
    前記処理部は、前記第一のサービスの処理結果を用いて、前記第二のサービスの処理を行う、
    ことを特徴とする情報処理システム。
20. 請求項１６に記載の情報処理システムであって、
    前記処理部は、
    前記第一のサービスの処理性能を予測した結果が入力され、当該予測結果に基づき前記第二のサービスの処理性能を予測する性能予測部と，前記第二のサービスに割り当てる資源を決定する資源割当て制御部とを備える、
    ことを特徴とする情報処理システム。

Images