JPWO2011142227A1 - コンピュータ・システム、方法及びプログラム - Google Patents

Abstract

コンピュータによる動的リソース割当てシステムにおいて、状況に従ってシステム構成を変更する際の、構成変更に伴うシステム停止時間を低減すること。事前処理として、システムが稼動している間のトラヒックデータをある時間に亘って収集する。 そして、収集したトラヒックデータから、典型的ないくつかのパターンを抽出する。次に、それらの典型的なパターン毎に、個々にストリーム・プログラムを作成して、後で参照可能に、保存しておく。次に、異なるストリーム・プログラム間で遷移するための代行タスクのＩＤを保持する。実際のシステムの稼動では、システムは、トラヒックデータを定期的に、あるいは任意の時点で測定し、その結果として得られたパターンを、上記の典型的なパターンと比較し、一番近い典型的なパターンに対応するストリーム・プログラムを、次のフェーズとして選ぶ。今のフェーズのストリーム・プログラムから、次のフェーズに移行する際に、この発明によれば、タスクの切り替えコスト、リソース間のデータ転送コストなどを考慮して、今のフェーズの空きタスクを代理タスクとして次第にフェーズのストリーム・プログラムに移行することにより、プログラムの停止時間が抑制される。

Description

本発明は、コンピュータ・システムにおいて、ネットワーク・トラフィックなどの状態に応じて、動的にリソース（資源とも称する）割当てを行うための技術に関し、より詳細には、リソース割当ての構成を切り替える技術に関する。

従来より、稼動するアプリケーション・プログラムの稼動状況や、ネットワーク・トラフィックの状態などに応じて、コンピュータの処理を最適化するために、リソースの割当てを動的に変更することが行われている。このために、以下のような技術が提案されている。

特開２００５−１７４２０１号公報及び特開２００７−４８３１５号公報は、サーバ、ネットワーク、ストレージを含むリソース表と、これらのリソース上で稼動するアプリケーションの構成要素を示すアプリケーション表と、リソースのアプリケーションへの割り当て表とを保持し、これらの構成情報から性能情報の測定項目を生成する性能測定項目テンプレート、この性能情報の測定項目を性能測定エンジンによって測定する性能測定エンジン、前記構成情報からリソースの割り当て変更に用いるリソース割り当て変更ルールを生成する手段、および前記生成したリソース割り当て変更ルールと構成情報に従って、リソースの割り当て変更を行うことを開示する。リソース割り当て変更ルールは、測定した性能指標に対する閾値を含む。

特開２００８−１９１７３７号公報は、サーバの性能や回線品質に左右されることなく、且つ新たにスペースを確保することなくシステムを安定的に動作させることができるアプリケーション実行システムを提供するために、クライアント端末と、アプリケーション実行装置とを第１のネットワークに接続すると共に、アプリケーション実行装置と、代理サーバとが第２のネットワークに接続されるアプリケーション実行システムにおいて、アプリケーション実行装置は、アプリケーションを実行する実行部と、実行部とは独立して動作し、実行部の状態に応じて、受信した実行要求を実行部または代理サーバに転送する切替部とを備えることを開示する。このとき、代理サーバは、実行要求に基づいて、代理アプリケーションを実行する。

これらの従来技術は、サーバ上で性能を測定し、その結果に応じて、処理能力を向上させるようにシステム構成を変更する技術については開示するが、従来技術においては、システム構成を変更する際に、一旦システムが停止するという問題があった。

昨今、多くの企業が導入しているクラウド・コンピューティングに基づくサービスにおいては、ＳＬＡ（サービス品質保証契約）という概念が採用されており、システムが停止する時間が長いと、サービス・プロバイダは損害を被る。

しかし、上記従来技術は、システム構成の切り替えの際にシステム停止時間を短縮することについては、特に解決策を示唆するものではない。

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

従って、この発明の目的は、コンピュータによる動的リソース割当てシステムにおいて、状況に従ってシステム構成を変更する際の、構成変更に伴うシステム停止時間を低減することにある。

この発明のシステムは先ず、事前処理として、システムが稼動している間のトラヒックデータをある時間に亘って収集する。 そして、収集したトラヒックデータから、典型的ないくつかのパターンを抽出する。

この発明のシステムは次に、それらの典型的なパターン毎に、これには限定されないが、例えば、本出願人に係る特願２００９−２７１３０８号明細書に記載された技術を用いて、個々にストリーム・プログラムを作成して、後で参照可能に、保存しておく。

この発明のシステムは次に、異なるストリーム・プログラム間で遷移するための代行タスクのＩＤを保持する。

こうしておいて、実際のシステムの稼動では、この発明のシステムは、トラヒックデータを定期的に、あるいは任意の時点で測定し、その結果として得られたパターンを、上記の典型的なパターンと比較し、一番近い典型的なパターンに対応するストリーム・プログラムを、次のフェーズとして選ぶ。

その際、今のフェーズのストリーム・プログラムから、次のフェーズに移行する際に、この発明によれば、コンピュータの処理により、タスクの切り替えコスト、リソース間のデータ転送コストなどを考慮して、今のフェーズの空きタスクを代理タスクとして次第にフェーズのストリーム・プログラムに移行することにより、プログラムの停止時間が抑制される。

このとき、代理タスクの選択は、関連するタスクのパイプライン・ピッチ、関連するタスク間の切り替えコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストを予め測定して保存しておき、現在のフェーズと次のフェース、使用資源の移行、実行タスクの移行を考慮して、コストが小さくなるように行われる。

この発明によれば、コンピュータによる動的リソース割当てシステムにおいて、状況に従って、元の構成から次の構成に移行する際に、元の構成から代行タスクを選択して途中の処理をさせることにより、処理の空き時間を減らして、プログラムの停止時間を低減させるという効果が得られる。

本発明を実施するためのハードウェア構成の概要を示す図である。 本発明を実施するための機能ブロック図である。 構成テーブルの例を示す図である。 ストリーム・プログラムの例を示す図である。 事前処理のフローチャートである。 トラヒック情報の時間推移を示す図である。 抽出されたフェーズの例を示す図である。 ストリーム・プログラムの例を示す図である。 ストリーム・プログラムの例を示す図である。 ストリーム・プログラムの例を示す図である。 ＵＤＯＰに計算リソースを割り当てる処理のフローチャートを示す図である。 ストリームグラフと、利用可能なリソースの例を示す図である。 ＵＤＯＰに計算リソースを割り当てた後の要求されたリソースの例を示す図である。 割当て変更処理の例を示す図である。 タスクの代行資源を決定するための処理のフローチャートを示す図である。 資源毎の本タスクと、代行タスクのテーブルを示す図である。 フェーズ切り替え判定のための処理のフローチャートを示す図である。 代行タスクによる実行処理のフローチャートを示す図である。 計算資源のトポロジの例を示す図である。 フェーズの切り替えと、代行タスクによる実行の例を示す図である。 代行手法の実行タスクの遷移サイクルの例を示す図である。

以下、図面に基づき、この発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。尚、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことを理解されたい。

図１は、本発明を実施するためのハードウェア構成を示すブロック図である。本発明は、これには限定されるものではないが、特にこの例は、ＰＲＩＳＭなどのマルチコア・マルチプロセッサ・ルータ・アプライアンス１００を使用する。

図１において、バス１０２には、マルチコア・プロセッサ１０４、マルチコア・プロセッサ１０６、ＲＡＭ１０８、イーサネット・スタック＆イーサネット・ポート１１０、及びフラッシュＲＯＭ１１２が接続されている。

マルチコア・プロセッサ１０４及び１０６としては、これには限定されないが、ネットワーク・プロセッサ、例えば、Intel(R) IXP 425 Network Processorを使用することができる。ネットワーク・プロセッサは、イーサネット(R)ＭＡＣや、暗号処理などの機能を内蔵するものである。

マルチコア・プロセッサ１０４とマルチコア・プロセッサ１０６は、実質的に同一の構成なので、代表的にマルチコア・プロセッサ１０４を説明すると、マルチコア・プロセッサ１０４は、複数のコア１０４ａ、１０４ｂ、１０４ｃ及び１０４ｄを有し、コア１０４ａ、１０４ｂ、１０４ｃ及び１０４ｄは、Ｌ２キャッシュ１０４ｅを介して、バス１０２に結合されている。

コア１０４ａ、１０４ｂ、１０４ｃ及び１０４ｄの各々は、複数のスレッドを走らせることができる。例えば、コア１０４ａ中に、ボックスＳ１及びＳ２が示されているが、これらがそれぞれ、個別のスレッドＳ１及びＳ２である。コア１０４ｂ、１０４ｃ及び１０４ｄにおいても同様であるので、個別の説明は省略する。

この実施例では、図示するように、マルチコア・プロセッサ１０６のコア１０６ｄ上で、本発明に係る主要な機能を実行する管理スレッドＳｎが走っているものとする。

ＲＡＭ１０８は、マルチコア・プロセッサ１０４及びマルチコア・プロセッサ１０６が、処理結果の値を一時保持したり、読み出したりするために使用される。

イーサネット・スタック＆イーサネット・ポート１１０には、図示しないが、他のコンピュータ・システム、ネットワーク接続ストレージ（ＮＡＳ）、ストレージ・エリア・ネットワーク（ＳＡＮ）、及び別のルータなどが接続される。マルチコア・マルチプロセッサ・ルータ・アプライアンス１００は、それらの機器との間で、データを通信する役割を担う。

フラッシュＲＯＭ１１２には、マルチコア・プロセッサ１０４及びマルチコア・プロセッサ１０６をルータとして動作させるためのＪｕｎｉｐｅｒ ＮｅｔｗｏｒｋｓのＪｕｎｏｓ(R)またはＣｉｓｃｏ Ｓｙｓｔｓｍｓ ＩｎｃのＩＯＳなどのネットワークＯＳ 、及び後述する本発明に係る処理モジュールが含まれる。

次に、図２の機能ブロック図を参照して、フラッシュＲＯＭ１１２、ＲＡＭ１０８などに含まれる、本発明に係る処理モジュールを説明する。

図２において、統計情報収集モジュール２０２は、イーサネット・スタック＆イーサネット・ポート１１０に到来するトラヒックを時間毎に収集する機能をもつ。トラヒックを収集するための従来の典型的な方法として、ＳＮＭＰプロトコルによる方法がある。あるいは、tcpdumpというパケット解析コマンドを使用することもできる。さらには、フルーク・ネットワークス社から入手可能な、"NetFlow Tracker"などの商用ツールを使用してもよい。ここで収集される情報とは、メール、ＦＴＰ、動画、ウェブなどのトラヒックの割合である。

統計情報収集モジュール２０２は、典型的には、少なくとも平日丸一日分、休日丸一日分のトラヒック情報を収集して、図示しないコンピュータ・システムのハードディスク・ドライブなどに保存する。

様相パターン抽出モジュール２０４は、ハードディスク・ドライブなどに保存されたトラヒック情報を解析して、典型的な複数のパターンを抽出し、様相パターン群２０６として、典型的には、ＲＡＭ１０８に保存する。様相パターン群２０６は、一定時間毎のトラヒック・パターンの収集、または、Ｋ平均法などを用いたクラスタリングによって決定することができる。

構成テーブル２０８は、様相パターン群２０６の各トラヒック・パターン毎に対応するエントリを有するものであり、例えば、本出願人に係る特願２００９−２７１３０８号明細書に記述された図６に示す表と等価なものであるので、それを図３として、再掲する。

図３において、ＵＤＯＰは、ストリーム・プログラミングにおけるユーザ定義オペレータであり、この実施例では例えば、これには限定されないが、イーサネット（商標）・プロトコル・スタック、ＩＰプロトコル・スタック、ＴＣＰプロトコル・スタック、ＵＤＰプロトコル・スタック、ＳＳＬプロトコル・スタック、ウイルス・スキャン、ＸＭＬアクセラレータなどである。

図３においてカーネルとは、個々のＵＤＯＰに対して用意された、１つまたは複数のモジュールであって、複数ある場合は、パケットの一次元配列のサイズがそれぞれ異っている。

実行パターンとは、例えば、下記の規則に従って表記されたものである。
ループにする(Rolling loop): A+A+A....A => loop(n, A)
ここで、A+A+A....Aは、Aの直列処理であり、loop(n, A)は、Aをn回まわすループのことをあらわす。
ループを解く(Unrolling loop): loop(n, A) => A+A+A....A
ループの直列(Series Rolling): split_join( A, A... A ) => loop(n, A)
これは、並列に走るA, A... Aを、loop(n, A)にすることである。
ループの並列(Pararell unrolling loop): loop(n, A) => split_joing( A, A, A ........A )
これは、loop(n, A)を、並列に走るA, A... Aにすることである。
ループの分割(Loop splitting): loop(n, A) => loop(x, A) + loop(n-x, A)
並列ループ分割(Pararell Loop splitting): loop(n, A) => split_join( loop(x, A), loop(n-x, A) )
ループ融合(Loop fusion): loop(n, A) + loop(n, B) => loop(n, A+B)
ループ融合の直列(Series Loop fusion): split_join( loop(n, A), loop(n, B) ) => loop(n, A+B)
ループ分配(Loop distribution): loop(n, A+B) => loop(n, A) + loop(n, B)
並列ループ分配(Pararell Loop distribution): loop(n, A+B) => split_join( loop(n, A), loop(n, B) )
ノード結合(Node merging): A+B => {A,B}
ノード分割(Node splitting): {A,B} => A+B
ループ置換(Loop replacement): loop(n,A) => X /* X is lower cost */
ノード置換(Node replacement): A => X /* X is lower cost */

図３でピッチとあるのは、パイプライン・ピッチ、すなわち、パイプライン処理の１ステージの処理時間のことである。また、リソースとは、使用するＣＰＵの数である。図３のリソース欄には、この実施例の場合、図１のシステムにおけるスレッドの数が記載される。

構成テーブル２０８のエントリは、イーサネット・スタック＆イーサネット・ポート１１０に接続された、ハードウェア及びソフトウェアを含むシステム環境２０９に基づき、図示しない所定の処理モジュールによって作成される。このことは、ＵＤＯＰ毎に、ＵＤＯＰを実現するカーネル定義を取得し、実行対象のハードウェア・コンフィギュレーションを取得し、使用アーキテクチャを組み合わせて使用リソースの組を用意し、これらについて、実行可能なカーネルを選択し、実行パターンを生成し、パイプライン・ピッチを測定するという処理を、使用リソースの組全てについて実行することによって達成される。このより詳しい処理は、本出願人に係る特願２００９−２７１３０８号明細書の図３と対応する明細書の記述を参照されたい。

コンパイラ２１０は、様相パターン群２０６の各様相パターン毎に、構成テーブル２０８のエントリを参照して、各様相パターン毎に、ストリーム形式コードを作成する。

なお、ストリーム形式コードを記述するためのストリーム・プログラミング言語として、インターナショナル・ビジネス・マシーンズ・コーポレーションのSPADE、マサチューセッツ工科大学ののStreamltがなどが知られている。Streamltによれば、図４に示すストリーム・グラフは、次のようなコードで記述される。
add splitjoin {
split roundrobin();
add pipeline {
add A();
add B();
add C();
add D();
}
add pipeline {
add E();
add F();
}
join roundrobin();
}

Streamltのより詳細な説明については、
http://groups.csail.mit.edu/cag/streamit/
あるいは、http://groups.csail.mit.edu/cag/streamit/papers/streamit-cookbook.pdfを参照されたい。

また、SPADEについては、
http://domino.research.ibm.com/comm/research_projects.nsf/pages/esps.spade.html
を参照されたい。

コンパイラ２１０が、各様相パターンに基づきストリーム形式コードを作成する。より詳しい処理については、後でより詳しく説明する。ストリーム形式コードは、処理を実行するタスクと、そのタスクを実行するハードウェア資源を、グラフ形式で記述する。

こうして、ストリーム形式コードが、各様相パターン毎に生成されると、図示しない特定の処理プログラムが、各様相パターンに対応するストリーム形式コードの間の遷移テーブル２１４を生成する。なお、遷移テーブル２１４の生成は、コンパイラ２１０によって行うようにしてもよい。尚、以下では、ストリーム形式コードの集まりを、ストリーム形式コード群２１２と呼ぶ。

以上述べたのは、事前に様相パターン群２０６、ストリーム形式コード群２１２、遷移テーブル２１４を用意するためのモジュールであったが、次に、実際のルータ・アプライアンス１００の動作の間に動作するモジュール群を説明する。

様相パターン計測モジュール２１６は、ルータ・アプライアンス１００の動作の間に、好適には、統計情報収集モジュール２０２よりも軽量な、ストリーム形式コードの先頭のタスクが処理するデータを種類ごとに数え上げるという処理を用いて、様相パターンを計測する。計測は例えば、ルータ・アプライアンス１００が扱うトラヒックの性質に適切な周期で行われる。

様相パターン比較モジュール２１８は、様相パターン計測モジュール２１６が計測した様相パターンと、様相パターン群２０６の各様相パターンとを比較する機能をもつ。その比較の結果、一番近い様相パターンに対応するストリーム形式コードが、ストリーム形式コード選択モジュール２２０によって、ストリーム形式コード群２１２から選ばれる。

切換モジュール２２２は、今まで実行環境２２４で実行されていたストリーム形式コードから、様相パターン比較モジュール２１８の比較結果に基づき選ばれたストリーム形式コードに切り替えて、実行環境２２４で実行させる機能をもつ。

その際、本発明の特徴によれば、切換モジュール２２２は、現在のストリーム形式コードから、次のストリーム形式コードに切り替える際に、適切な代行タスクを立てることで、プログラム停止時間を減少させる。この処理の詳細は、後でフローチャートなどを使用して説明する。

次に、図５のフローチャートを参照して、統計情報の収集及び事前処理の流れについて説明する。この処理は、例えば、ルータ・アプライアンス１００を本発明の機能に従って動作させる前に、ユーザーの操作により開始される。

ステップ５０２では、統計情報収集モジュール２０２が、イーサネット・スタック＆イーサネット・ポート１１０に到来するトラヒックを時間毎に収集する。統計情報収集モジュール２０２は、ＳＮＭＰプロトコル、tcpdumpというパケット解析コマンドまたは、ルーク・ネットワークス社から入手可能な、"NetFlow Tracker"という商用ツール、などを使用する。ここで収集される情報とは、メール、ＦＴＰ、動画、ウェブなどのトラヒックの割合である。統計情報収集モジュール２０２は、典型的には、少なくとも平日丸一日分、休日丸一日分のトラヒック情報を収集して、図示しないコンピュータ・システムのハードディスク・ドライブなどに保存する。図６に、トラヒック情報が時間とともに変化する様子が模式的に示されている。ここでは、メール、ＦＴＰ、動画及びウェブが例示的に示されているが、これは一例であって、実際はより多様な種類の内容のトラフィックがありえることを理解されたい。

ステップ５０４では、様相パターン抽出モジュール２０４が、統計情報収集モジュール２０２が収集したトラヒック情報から、図７に示すような複数の典型的な様相パターン７０２、７０４・・・７０６を抽出する。

様相パターン７０２、７０４・・・７０６は、一定時間毎に抽出したトラヒック情報のバターンであってもよいし、あるいは、一定時間毎に抽出したトラヒック情報のバターンを複数集めて、例えばＫ平均法によってクラスタリングして得られたクラスタから、代表的なものを取り出してもよい。様相パターン（フェーズ）７０２、７０４・・・７０６は、様相パターン群２０６として、好適にはＲＡＭ１０８に保存される。このようにして生成された様相パターン７０２、７０４・・・７０６にはそれぞれ、固有のフェーズＩＤが付与される。

ステップ５０６では、コンパイラ２１０が、構成テーブル２０８の項目を参照して、様相パターン群２０６の各様相パターン（フェーズ）毎に、ストリーム形式コードを生成する。言い換えると、フェーズ毎に、ストリーム・プロセッシングに基づいたリソース・マッピングを導出する。

図８は、ベースとなるストリーム・プログラムの例であり、図示されているように、イーサネット・プロトコル・スタックに、ＩＰプロトコル・スタックが接続され、そこから、ＴＣＰプロトコル・スタックと、ＵＤＰプロトコル・スタックに分岐し、ＴＣＰプロトコル・スタックと、ＵＤＰプロトコル・スタックは、ウイルス・スキャンに接続されるとともに、ＳＳＬプロトコル・スタックにも接続され、ＳＳＬプロトコル・スタックはウイルス・スキャンに接続され、ウイルス・スキャンは、ＸＭＬアクラセレータに接続される。

図８では、ストリーム・プログラムの各処理要素の負荷は考慮されていないが、図９の様相９０２のように、特定のトラヒック情報の様相に対応して、ストリーム・プログラムの各処理要素にかかる負荷が変化する。すなわち、図９において、各処理要素を囲むボックスの大きさが、負荷をあらわしているものとする。

図１０は、さらに別のトラヒック情報の様相１００２に対して、各処理要素にかかる負荷分散が異なる様子を示す。すなわち、トラヒック情報の様相が変化したとき、ストリーム・プログラムの特定の各処理要素に負荷がかかりすぎて、そこがボトルネックになり、全体の処理速度が低下してしまう。

そこで、ストリーム・プログラムにおいては、リソースマッピングにより、処理の最適化が図られる。そのための方法として、次のようなものがある。
− データ並列化、パイプラインの決定
このとき、タスク並列も利用することで、メモリアクセスのローカリティの向上、通信競合の抑制、通信遅延の隠蔽などの効果が得られる。
− 処理が重いプロトコル・スタックを複数ステージに切り分けたり、軽いプロトコル・スタックを１つのステージに統合したりすることで、資源あたりの負荷とパイプラインピッチのバランスを取る。

このための詳細な処理は、やや複雑なので、後で別途説明する。生成されたストリーム形式コード群２１２は、好適にはＲＡＭ１０８に保存される。

ステップ５０８では、このようにして作成されたストリーム形式コード群２１２のストリーム形式コード間の遷移テーブル２１４が作成される。遷移テーブル２１４は、プロファイルのフェーズ毎に、プロセッサ毎のストリーム形式コードにおける本タスク、及び１つのストリーム形式コードから別のストリーム形式コードに切り替える際の代行タスクを含む。遷移テーブル２１４の内容についても、後で詳細に説明する。

次に、図１１以下を参照して、ストリーム形式コードを生成する処理について説明する。

図１１において、システム環境２０９、すなわちリソース制約（ハードウェア・コンフィギュレーション）、及び構成テーブル２０８が事前に用意されるものとする。機能ブロックＡ，Ｂ，Ｃ．Ｄからなるストリーム・グラフとリソース制約の例を、図１２に示す。ここでいうシステム環境２０９とは、図１のイーサネット・スタック＆イーサネット・ポート１１０に接続されているシステム構成のことである。

コンパイラ２１０は、ステップ１１０２で、フィルタリングを行う。すなわち、与えられたハードウェア・コンフィギュレーションと構成テーブル２０８から実行可能なパターンのみ抽出し、最適化表(A)を作成する。

コンパイラ２１０は、ステップ１１０４で、最適化表(A)を参照して、ストリームグラフ中の各ＵＤＯＰに もっともパイプラインピッチの短い実行パターンを割り当てた実行パターン群(B)を作成する。それを、ストリームグラフの各ブロックに割り当てた様子を示す例を、図１３に示す。

次にステップ１１０６では、コンパイラ２１０は、実行パターン群(B)は与えられたリソース制約を満たしているかどうかを判断する。

ステップ１１０６で、コンパイラ２１０が、実行パターン群(B)が与えられたリソース制約を満たしていると判断すると、この処理は完了する。

ステップ１１０６で、コンパイラ２１０が、実行パターン群(B)が与えられたリソース制約を満たしてないと判断すると、ステップ１１０８に進み、実行パターン群(B)中の実行パターン群をパイプラインピッチ順にソートしたリスト(C)を作成する。

次に、ステップ１１１０に進み、コンパイラ２１０は、リスト(C)から一番パイプラインピッチが短い実行パターンを持つＵＤＯＰ (D)を選択する。

次に、ステップ１１１２に進み、コンパイラ２１０は、ＵＤＯＰ(D)について、消費リソースのより少ない実行パターン（次候補）(E)が最適化表(A)に存在するかを判断する。

もしそうなら、ステップ１１１４に進み、コンパイラ２１０は、ＵＤＯＰ(D)について、実行パターン（次候補）(E)のパイプラインピッチはリスト(C)内の最長値より小さいかどうかを判断する。

もしそうなら、ステップ１１１６に進み、コンパイラ２１０は、実行パターン（次候補）(E)をＵＤＯＰ(D)の新しい実行パターンとして割り当て、実行パターン群(B)を更新する。

ステップ１１１６からは、ステップ１１０６の判断に戻る。

ステップ１１１２での判断が否定的なら、ステップ１１１８に進み、そこで、コンパイラ２１０は、当該ＵＤＯＰを(C)から外す。

次に、ステップ１１２０に進み、そこでコンパイラ２１０は、リスト(C)に要素が存在するかどうかを判断する。もしそうなら、ステップ１１０８に戻る。

ステップ１１２０で、リスト(C)に要素が存在しないと判断されたなら、ステップ１１２２に進み、そこでコンパイラ２１０は、実行パターン群(B)中の実行パターン群を、実行パターン群(B)の最長パイプラインピッチと次候補のパイプラインピッチの差の順にソートしたリスト(F)を作成する。

次に、ステップ１１２４で、コンパイラ２１０は、リスト(F)のうちパイプラインピッチの差が一番短い実行パターン(G)について、それが要求するリソースが、現在注目しているリソースより少ないかどうかを判断する。

もしそうなら、ステップ１１２６に進み、そこでコンパイラ２１０は、実行パターン(G)を新しい実行パターンとして割り当て、実行パターン群(B)を更新し、ステップ８０６に進む。そうでなければ、ステップ１１２８で当該ＵＤＯＰを(F)から外して、ステップ１１２２に戻る。

図１４は、このような実行パターン群の置き換えによる最適化の例を示す図である。図１４では、リソース制約を解くために、D4がD5に置き換えられている。

こうして、リソースの割当てが行われると、その各々のストリーム形式コードは、ストリーム形式コード群２１２として、好適にはＲＡＭ１０８にストアされる。なお、各々のストリーム形式コードの各タスクには、固有のタスクＩＤが付与される。

次に、図１５のフローチャートを参照して、フェーズ切り替え時の代行タスクを選択する処理を説明する。この処理は、プロセッサ１０４またはプロセッサ１０６で走る所定のスレッドによって実行される。

図１５のフローチャートの説明を行う前に、以下で使用する記号または数式の定義を説明しておく。

定義
task(b,r):資源rのフェーズbでのタスク
Pre(t):タスクtの先行タスクの集合
Post(t):タスクtの後続タスクの集合

※1：フェーズbでのタスクtの開始時間
start(b,t) = max{start(b,p):p∈Pre(t)} + pitch
pitch:パイプラインピッチ（各タスクの実行時間）

※２：cost(t,r) = D + C + T
D = max{0,start(a,task(a,r)) - start(b,task(t)}
Dは、代理タスク実行開始までの空き時間を含むコストである。
C = max{delay(i,r),delay(r,j):i∈Deputize(a,b,s),s∈Pre(t),j∈Resource(b,u),u∈Post(t)}
Resource(b,t):フェーズbでタスクtを担当する資源の集合
Deputize(a,b,t):フェーズaからフェーズbへの切り替え時にタスクtを代行する資源の集合
delay(a,b):資源aがデータの送信を開始してから、資源bがデータの受信を完了するまでの時間
T = change(task(a,r),t) + change(t,task(b,r))
change(t1,t2):もしタスクt1がt2と同じなら0、そうでなければTC（タスク切り替え1回あたりのコスト、任意の定数）

図１５のフローチャートに戻って、ステップ１５０２では、資源の集合Rと、フェーズa,bが入力される。このとき、資源の集合Rには資源IDと各資源間の通信遅延が含まれる。また、フェーズa,bにはタスクID、各タスクを担当する資源ID、各タスクの先行＆後続タスクの集合、各タスクの実行時間が含まれる。これは、図５のステップ５０８に対応する。

ステップ１５０４では、フェーズbのタスク（より厳密に言うと、フェーズbに対応するストリーム・グラフにおけるタスク）を、タスク開始時間の昇順にソートしたリストTbが作成される。ここで、タスク開始時間とは、上記※1で定義されるものである。

ステップ１５０６では、tにTbの先頭のタスクが置かれる。

次に、ステップ１５０８から、ステップ１５１０、ステップ１５１２、ステップ１５１４、ステップ１５１６までは、フェーズbでtを担当する各資源rbについての処理である。

ステップ１５１０では、Rに含まれ、且つrbと同じ種類である資源rの中で、cost(t,r)が最も小さいrをrb'とする。ここで、資源の種類とは、汎用プロセッサ、グラフィック・プロセッシング・ユニットであるアクセラレータなどのことである。また、cost(t,r)とは上記※2で定義されるものである。

ステップ１５１２では、rb'の代行タスクがtとされる。次にステップ１５１４では、Rからrb'が削除される。

こうして、ステップ１５０８に戻り、フェーズbでtを担当する資源rbがある限り、ステップ１５１０、ステップ１５１２、ステップ１５１４、ステップ１５１６までが繰り返される。

ステップ１５１８では、Tbから先頭の要素tが削除されて、ステップ２３２０で、Tbが空かどうかが判断される。そうでなければ、処理は、ステップ１５０６に戻る。ステップ１５０６での先頭というのは、ステップ１５１８でTbから先頭の要素tが削除された後の次の要素のことである。

ステップ２３２０で、Tbが空であると判断されると、各タスクの代行資源の集合が得られる。すなわち、ステップ１５１２で、資源rb'の代行タスクtが決定されるので、そのような(rb',t)の集合ということである。

図１５のフローチャートの処理は、互いに異なるフェーズa,bのあらゆる組み合わせについて行われる。その結果、図１６に示すように、ルータ・アプライアンス１００に接続されて、利用可能なすべての資源の各々について、フェーズＩＤと本タスクのＩＤの対応テーブルと、フェーズＩＤと代行タスクのＩＤの対応テーブルが作成される。フェーズＩＤと代行タスクのＩＤの対応テーブルは、双方向の移行をあらわすために、２次元テーブルとして表される。これらの対応テーブルは、図２で遷移テーブル２１４として示すものである。

すなわち、フェーズＩＤと本タスクのＩＤの対応テーブルは、図５のステップ５０６で作成され、フェーズＩＤと代行タスクのＩＤの対応テーブルは、図５のステップ５０８で作成される。

各資源上で実行するプログラムは、タスクＩＤを基にコールする関数をスイッチするようなラッパーを用意し切り替えることができる。

上記は、通常タスク用のテーブルであるが、さらに、監視タスク用のテーブルを用意してもよい。これは、フェーズ切り替え時の判定に用いる閾値を保持するものであって、時間帯毎での切り替えの場合は、時間とフェーズＩＤの組からなり、Ｋ平均法の場合は、重心とフェーズＩＤの組からなる。

図１７は、ストリーム形式コード群２１２と、遷移テーブルが用意された後の、様相パターン計測モジュール２１６と、様相パターン比較モジュール２１８の動作を示すフローチャートである。

図１７において、ステップ１７０２では、様相パターン計測モジュール２１６が、負荷測定、すなわち、イーサネット・スタック＆イーサネット・ポート１１０に到来するトラヒックを収集する。様相パターン比較モジュール２１８は、その計測されたトラヒックの様相（フェーズ）と、現在選ばれているフェーズの距離を計算してステップ１７０２で、フェーズ切り替え判定を行う。すなわち、その距離が、所定の閾値以内であるなら、切り替えないという判定を行って、ステップ１７０２に戻る。また、その距離が、所定の閾値以上であるなら、切り替えるという判定を行って、ステップ１７０６に進む。

尚、図７に示すように、フェーズは、メール、ＦＴＰ、動画、ウェブなどのトラヒックの割合を成分とする特徴ベクトルと考えることができ、すると、その特徴ベクトル同士の間に、ユークリッド距離、マンハッタン距離、内積などの値を定義することができる。そして、このような内積や距離が閾値内にあるかどうかを調べればよい。

ステップ１７０６では、様相パターン比較モジュール２１８が、ストリーム形式コード選択モジュール２２０に対して、グラフ先頭の資源フェーズ切替指示を送信する。そうして処理は、ステップ１７０２に戻る。

図１８は、ストリーム形式コード選択モジュール２２０、切換モジュール２２２及び実行環境２２４の動作のフローチャートを示す図である。

ステップ１８０２では、実行環境２２４が、現在選ばれているストリーム形式コードにおいて、本タスクを実行する。ステップ１８０４では、切換モジュール２２２が、全ての先行資源からフェーズ切替指示を受信したかどうかを判断する。そうでなければ、ステップ１８０２に戻って、実行環境２２４が、本タスクを実行し続ける。

ステップ１８０４で、切換モジュール２２２が、全ての先行資源からフェーズ切替指示を受信すると、ステップ１８０６に進み、そこで、監視タスクによって既に選択されているストリーム形式コードが、後続ストリーム形式コードとする。

そこで、後続ストリーム形式コードのＩＤがフェーズ切り替え指示に含まれているので、ステップ１８０６では、切換モジュール２２２が、全ての後続資源のデータキューの末尾に、フェーズ切替指示を追加する。

次に、ステップ１８０８に進んで、切換モジュール２２２が、後続ストリーム形式コードにおける本タスク開始時刻を過ぎたかどうか判断する。そうでなければ、ステップ１８１０で、実行環境２２４が、フェーズ切替指示のフェーズＩＤでの代行タスクを実行しつつ、ステップ１８０８に戻る。代行タスクは、図１６に示すように、使用中の資源における、直前のフェーズＩＤと、今のフェーズＩＤから決定することができる。

ステップ１８０８で、切換モジュール２２２が、後続ストリーム形式コードにおける本タスク開始時刻を過ぎたと判断すると、ステップ１８１２に進む。

ステップ１８１２では、切換モジュール２２２は、ステップ１８１２で、代行タスクのデータがキューに残っているかどうかを判断する。そうでなければ、処理は、ステップ１８０２の本タスク実行に戻る。

ステップ１８１２で、切換モジュール２２２が、ステップ１８１２で、代行タスクのデータがキューに残っていると判断したなら、処理はステップ１８１４に進み、切換モジュール２２２は、実行環境２２４に代行タスクを実行させ、その出力を、後続のタスクを本来実行する資源に送信する。

以下、代行タスクを用いたフェーズ切り替え動作について、模式的な例によって、より具体的に説明する。先ず、図１９は、ルータ・アプライアンス１００のイーサネット・スタック＆イーサネット・ポート１１０に接続されている計算資源のトポロジである。これは、物理的トポロジであって、ソフトウェア的なものではないので、動的に再構成できない。

図２０は、このような資源１〜資源６からなる物理的トポロジの計算資源に対して、(1)に示すようにフェーズαとしてストリーム形式で資源の割り振りが行われている状態から、(3)に示すようにフェーズβとしてストリーム形式で資源の割り振りが行われている状態に移行する場合に、(2)に示すような代理タスクを使用する経過的な状態を経ることによって、フェーズ切り替えに伴うシステム停止時間を低減するものである。

すなわち、図２０(1)で、資源１がタスクａを、資源２がタスクｃを、資源３がタスクｄを、資源４がタスクｅを、資源５がタスクｆを、資源６がタスクｂを実行しているフェーズαの状態から、図２０(3)で、資源１がタスクＡを、資源２がタスクＢを、資源３がタスクＣを、資源４がタスクＥを、資源５がタスクＤを、資源６がタスクＦを実行しているフェーズβの状態に移行するために、図２０(2)で、ステップ１８１０にあるように、資源３がタスクＤを実行して資源５に送信し、次にステップ１８１４にあるように、資源３がタスクＤを実行して資源６に送信し、図２０(3)に移行して、次にステップ１８０２にあるように、資源３がタスクＣを実行して資源５に送信する。同様に、資源６も、図２０(2)で、タスクＣを代行で実行して、資源４と資源３に送信する。

図２１は、実行タスクの遷移サイクルを示す図である。図において特に、資源６のタスクＣの実行と、資源３のタスクＤの実行が、代行タスクとしての実行である。

すなわち、各フェーズは、パイプライン化されているため、先頭のタスクから順に終わっていく。そこで、本発明の基本的なスキームによれば、先にフェーズαを終えた資源が、フェーズβの前方の資源を代行し、全ての資源がフェーズαのタスクを終えたら、本来のタスクを開始する。

以上、特定の実施例に従い本発明を説明してきたが、示されたハードウェア、ソフトウェア、ネットワーク構成は例示に過ぎず、本発明は、これらと機能的に等価な任意の構成で実現可能であることを理解されたい。

１００ ルータ・アプライアンス
１０２ バス
１０４ マルチコア・プロセッサ
１０６ マルチコア・プロセッサ
１０８ ＲＡＭ
１１０ イーサネット・ポート
１１２ フラッシュＲＯＭ
２０２ 統計情報収集モジュール
２０４ 様相パターン抽出モジュール
２０６ 様相パターン群
２０８ 構成テーブル
２０９ システム環境
２１０ コンパイラ
２１２ ストリーム形式コード群
２１４ 遷移テーブル
２１６ 様相パターン計測モジュール
２１８ 様相パターン比較モジュール
２２０ ストリーム形式コード選択モジュール
２２２ 切換モジュール
２２４ 実行環境
７０２ 様相パターン
７０４ 様相パターン
７０６ 様相パターン

Claims (9)

1. コンピュータの処理により、ネットワーク・トラヒック情報の内容に応じて、処理を適合するように動的に構成を変更するための方法であって、
   ネットワーク・トラヒック情報の異なる複数の内容に対応するフェーズに各々適合するように、タスクと該タスクが実行されるリソース割当てをストリーム形式で指定する情報を予め保存するステップと、
   ネットワーク・トラヒック情報を測定するステップと、
   測定された前記ネットワーク・トラヒック情報に相対的に近いストリーム形式のリソース割当て情報を次のフェーズとして選択するステップと、
   既に選択されている現在のフェーズのストリーム形式のリソース割当てから、前記次のフェーズのストリーム形式のリソース割当てに切り替えるステップであって、現在のフェーズのストリーム形式のリソース割当てにおいて先に処理を終えた前記リソースが、前記次のフェーズのストリーム形式のリソース割当てにおけるタスクを過渡的に代行して実行するようになされる、ステップを有する、
   コンピュータ・システムの制御方法。
2. 利用可能な前記リソース毎に、フェーズ間移行の代理タスクを計算してテーブルとして記憶するステップを有し、前記切り替えるステップは、当該リソースに対応して記憶された前記代理タスクを、現在のフェーズと次のフェーズとから検索して代行して実行する、請求項１に記載の方法。
3. 前記フェーズ間移行の代理タスクは、関連するタスク間の切り替えコスト、代理タスク実行開始までの空き時間を含むコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストが小さくなるように選択される、請求項２に記載の方法。
4. コンピュータの処理により、ネットワーク・トラヒック情報の内容に応じて、処理を適合するように動的に構成を変更するためのシステムであって、
   記憶手段と、
   ネットワーク・トラヒック情報の異なる複数の内容に対応するフェーズに各々適合するように、タスクと該タスクが実行されるリソース割当てをストリーム形式で指定する情報を前記記憶手段に保存する手段と、
   ネットワーク・トラヒック情報を測定する手段と、
   測定された前記ネットワーク・トラヒック情報に相対的に近いストリーム形式のリソース割当て情報を次のフェーズとして選択する手段と、
   既に選択されている現在のフェーズのストリーム形式のリソース割当てから、前記次のフェーズのストリーム形式のリソース割当てに切り替える手段であって、現在のフェーズのストリーム形式のリソース割当てにおいて先に処理を終えた前記リソースが、前記次のフェーズのストリーム形式のリソース割当てにおけるタスクを過渡的に代行して実行するようになされる、手段を有する、
   コンピュータ・システム。
5. 利用可能な前記リソース毎に、フェーズ間移行の代理タスクを計算してテーブルとして記憶する手段を有し、前記切り替える手段は、当該リソースに対応して記憶された前記代理タスクを、現在のフェーズと次のフェーズとから検索して代行して実行する、請求項４に記載のシステム。
6. 前記フェーズ間移行の代理タスクは、関連するタスク間の切り替えコスト、代理タスク実行開始までの空き時間を含むコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストが小さくなるように選択される、請求項５に記載のシステム。
7. コンピュータの処理により、ネットワーク・トラヒック情報の内容に応じて、処理を適合するように動的に構成を変更するためのプログラムであって、
   前記コンピュータをして、
   ネットワーク・トラヒック情報の異なる複数の内容に対応するフェーズに各々適合するように、タスクと該タスクが実行されるリソース割当てをストリーム形式で指定する情報を予め保存するステップと、
   ネットワーク・トラヒック情報を測定するステップと、
   測定された前記ネットワーク・トラヒック情報に相対的に近いストリーム形式のリソース割当て情報を次のフェーズとして選択するステップと、
   既に選択されている現在のフェーズのストリーム形式のリソース割当てから、前記次のフェーズのストリーム形式のリソース割当てに切り替えるステップであって、現在のフェーズのストリーム形式のリソース割当てにおいて先に処理を終えた前記リソースが、前記次のフェーズのストリーム形式のリソース割当てにおけるタスクを過渡的に代行して実行するようになされる、ステップを実行させる、
   コンピュータ・システムの制御プログラム。
8. 利用可能な前記リソース毎に、フェーズ間移行の代理タスクを計算してテーブルとして記憶するステップを有し、前記切り替えるステップは、当該リソースに対応して記憶された前記代理タスクを、現在のフェーズと次のフェーズとから検索して代行して実行する、請求項７に記載のプログラム。
9. 前記フェーズ間移行の代理タスクは、関連するタスク間の切り替えコスト、代理タスク実行開始までの空き時間を含むコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストが小さくなるように選択される、請求項８に記載のプログラム。

Images