"コンピュータの処理により、ネットワークトラヒック情報の内容に応じて、処理を適合するように動的に構成を変更するための方法であって、ネットワークトラヒック情報の異なる複数の内容に対応するフェーズに各々適合するように、タスクと該タスクが実行されるリソース割当てをストリーム形式で指定する情報を予め保存するステップと、ネットワークトラヒック情報を測定するステップと、測定された前記ネットワークトラヒック情報に相対的に近いストリーム形式のリソース割当て情報を次のフェーズとして選択するステップと、既に選択されている現在のフェーズのストリーム形式のリソース割当てから、前記次のフェーズのストリーム形式のリソース割当てに切り替えるステップであって、現在のフェーズのストリーム形式のリソース割当てにおいて先に処理を終えた前記リソースが、前記次のフェーズのストリーム形式のリソース割当てにおけるタスクを過渡的に代行して実行するようになされる、ステップを有する、コンピュータシステムの制御方法。利用可能な前記リソース毎に、フェーズ間移行の代理タスクを計算してテーブルとして記憶するステップを有し、前記切り替えるステップは、当該リソースに対応して記憶された前記代理タスクを、現在のフェーズと次のフェーズとから検索して代行して実行する、請求項1に記載の方法。前記フェーズ間移行の代理タスクは、関連するタスク間の切り替えコスト、代理タスク実行開始までの空き時間を含むコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストが小さくなるように選択される、請求項2に記載の方法。コンピュータの処理により、ネットワークトラヒック情報の内容に応じて、処理を適合するように動的に構成を変更するためのシステムであって、記憶手段と、ネットワークトラヒック情報の異なる複数の内容に対応するフェーズに各々適合するように、タスクと該タスクが実行されるリソース割当てをストリーム形式で指定する情報を前記記憶手段に保存する手段と、ネットワークトラヒック情報を測定する手段と、測定された前記ネットワークトラヒック情報に相対的に近いストリーム形式のリソース割当て情報を次のフェーズとして選択する手段と、既に選択されている現在のフェーズのストリーム形式のリソース割当てから、前記次のフェーズのストリーム形式のリソース割当てに切り替える手段であって、現在のフェーズのストリーム形式のリソース割当てにおいて先に処理を終えた前記リソースが、前記次のフェーズのストリーム形式のリソース割当てにおけるタスクを過渡的に代行して実行するようになされる、手段を有する、コンピュータシステム。利用可能な前記リソース毎に、フェーズ間移行の代理タスクを計算してテーブルとして記憶する手段を有し、前記切り替える手段は、当該リソースに対応して記憶された前記代理タスクを、現在のフェーズと次のフェーズとから検索して代行して実行する、請求項4に記載のシステム。前記フェーズ間移行の代理タスクは、関連するタスク間の切り替えコスト、代理タスク実行開始までの空き時間を含むコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストが小さくなるように選択される、請求項5に記載のシステム。コンピュータの処理により、ネットワークトラヒック情報の内容に応じて、処理を適合するように動的に構成を変更するためのプログラムであって、前記コンピュータをして、ネットワークトラヒック情報の異なる複数の内容に対応するフェーズに各々適合するように、タスクと該タスクが実行されるリソース割当てをストリーム形式で指定する情報を予め保存するステップと、ネットワークトラヒック情報を測定するステップと、測定された前記ネットワークトラヒック情報に相対的に近いストリーム形式のリソース割当て情報を次のフェーズとして選択するステップと、既に選択されている現在のフェーズのストリーム形式のリソース割当てから、前記次のフェーズのストリーム形式のリソース割当てに切り替えるステップであって、現在のフェーズのストリーム形式のリソース割当てにおいて先に処理を終えた前記リソースが、前記次のフェーズのストリーム形式のリソース割当てにおけるタスクを過渡的に代行して実行するようになされる、ステップを実行させる、コンピュータシステムの制御プログラム。利用可能な前記リソース毎に、フェーズ間移行の代理タスクを計算してテーブルとして記憶するステップを有し、前記切り替えるステップは、当該リソースに対応して記憶された前記代理タスクを、現在のフェーズと次のフェーズとから検索して代行して実行する、請求項7に記載のプログラム。前記フェーズ間移行の代理タスクは、関連するタスク間の切り替えコスト、代理タスク実行開始までの空き時間を含むコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストが小さくなるように選択される、請求項8に記載のプログラム。従って、この発明の目的は、コンピュータによる動的リソース割当てシステムにおいて、状況に従ってシステム構成を変更する際の、構成変更に伴うシステム停止時間を低減することにある。この発明のシステムは先ず、事前処理として、システムが稼動している間のトラヒックデータをある時間に亘って収集する。そして、収集したトラヒックデータから、典型的ないくつかのパターンを抽出する。この発明のシステムは次に、それらの典型的なパターン毎に、これには限定されないが、例えば、本出願人に係る特願2009-271308号明細書に記載された技術を用いて、個々にストリームプログラムを作成して、後で参照可能に、保存しておく。この発明のシステムは次に、異なるストリームプログラム間で遷移するための代行タスクのIDを保持する。こうしておいて、実際のシステムの稼動では、この発明のシステムは、トラヒックデータを定期的に、あるいは任意の時点で測定し、その結果として得られたパターンを、上記の典型的なパターンと比較し、一番近い典型的なパターンに対応するストリームプログラムを、次のフェーズとして選ぶ。その際、今のフェーズのストリームプログラムから、次のフェーズに移行する際に、この発明によれば、コンピュータの処理により、タスクの切り替えコスト、リソース間のデータ転送コストなどを考慮して、今のフェーズの空きタスクを代理タスクとして次第にフェーズのストリームプログラムに移行することにより、プログラムの停止時間が抑制される。このとき、代理タスクの選択は、関連するタスクのパイプラインピッチ、関連するタスク間の切り替えコスト、及び関連するフェーズ間でリソース間のデータ送受信の時間を含むコストを予め測定して保存しておき、現在のフェーズと次のフェース、使用資源の移行、実行タスクの移行を考慮して、コストが小さくなるように行われる。この発明によれば、コンピュータによる動的リソース割当てシステムにおいて、状況に従って、元の構成から次の構成に移行する際に、元の構成から代行タスクを選択して途中の処理をさせることにより、処理の空き時間を減らして、プログラムの停止時間を低減させるという効果が得られる。以下、図面に基づき、この発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。尚、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことを理解されたい。図1は、本発明を実施するためのハードウェア構成を示すブロック図である。本発明は、これには限定されるものではないが、特にこの例は、PRISMなどのマルチコアマルチプロセッサルータアプライアンス100を使用する。図1において、バス102には、マルチコアプロセッサ104、マルチコアプロセッサ106、RAM108、イーサネットスタックイーサネットポート110、及びフラッシュROM112が接続されている。マルチコアプロセッサ104及び106としては、これには限定されないが、ネットワークプロセッサ、例えば、IntelIXP425NetworkProcessorを使用することができる。ネットワークプロセッサは、イーサネットMACや、暗号処理などの機能を内蔵するものである。マルチコアプロセッサ104とマルチコアプロセッサ106は、実質的に同一の構成なので、代表的にマルチコアプロセッサ104を説明すると、マルチコアプロセッサ104は、複数のコア104a、104b、104c及び104dを有し、コア104a、104b、104c及び104dは、L2キャッシュ104eを介して、バス102に結合されている。コア104a、104b、104c及び104dの各々は、複数のスレッドを走らせることができる。例えば、コア104a中に、ボックスS1及びS2が示されているが、これらがそれぞれ、個別のスレッドS1及びS2である。コア104b、104c及び104dにおいても同様であるので、個別の説明は省略する。この実施例では、図示するように、マルチコアプロセッサ106のコア106d上で、本発明に係る主要な機能を実行する管理スレッドSnが走っているものとする。RAM108は、マルチコアプロセッサ104及びマルチコアプロセッサ106が、処理結果の値を一時保持したり、読み出したりするために使用される。イーサネットスタックイーサネットポート110には、図示しないが、他のコンピュータシステム、ネットワーク接続ストレージNAS、ストレージエリアネットワークSAN、及び別のルータなどが接続される。マルチコアマルチプロセッサルータアプライアンス100は、それらの機器との間で、データを通信する役割を担う。フラッシュROM112には、マルチコアプロセッサ104及びマルチコアプロセッサ106をルータとして動作させるためのJuniperNetworksのJunosまたはCiscoSystsmsIncのIOSなどのネットワークOS、及び後述する本発明に係る処理モジュールが含まれる。次に、図2の機能ブロック図を参照して、フラッシュROM112、RAM108などに含まれる、本発明に係る処理モジュールを説明する。図2において、統計情報収集モジュール202は、イーサネットスタックイーサネットポート110に到来するトラヒックを時間毎に収集する機能をもつ。トラヒックを収集するための従来の典型的な方法として、SNMPプロトコルによる方法がある。あるいは、tcpdumpというパケット解析コマンドを使用することもできる。さらには、フルークネットワークス社から入手可能な、NetFlowTrackerなどの商用ツールを使用してもよい。ここで収集される情報とは、メール、FTP、動画、ウェブなどのトラヒックの割合である。統計情報収集モジュール202は、典型的には、少なくとも平日丸一日分、休日丸一日分のトラヒック情報を収集して、図示しないコンピュータシステムのハードディスクドライブなどに保存する。様相パターン抽出モジュール204は、ハードディスクドライブなどに保存されたトラヒック情報を解析して、典型的な複数のパターンを抽出し、様相パターン群206として、典型的には、RAM108に保存する。様相パターン群206は、一定時間毎のトラヒックパターンの収集、または、K平均法などを用いたクラスタリングによって決定することができる。構成テーブル208は、様相パターン群206の各トラヒックパターン毎に対応するエントリを有するものであり、例えば、本出願人に係る特願2009-271308号明細書に記述された図6に示す表と等価なものであるので、それを図3として、再掲する。図3において、UDOPは、ストリームプログラミングにおけるユーザ定義オペレータであり、この実施例では例えば、これには限定されないが、イーサネット商標プロトコルスタック、IPプロトコルスタック、TCPプロトコルスタック、UDPプロトコルスタック、SSLプロトコルスタック、ウイルススキャン、XMLアクセラレータなどである。図3においてカーネルとは、個々のUDOPに対して用意された、1つまたは複数のモジュールであって、複数ある場合は、パケットの一次元配列のサイズがそれぞれ異っている。実行パターンとは、例えば、下記の規則に従って表記されたものである。ループにするAAAAloopここで、AAAAは、Aの直列処理であり、loopは、Aをn回まわすループのことをあらわす。ループを解くloopAAAAループの直列splitjoinloopこれは、並列に走るAAAを、loopにすることである。ループの並列loopsplitjoingこれは、loopを、並列に走るAAAにすることである。ループの分割looplooploop並列ループ分割loopsplitjoinloopループ融合looplooploopループ融合の直列splitjoinlooploopループ分配looplooploop並列ループ分配loopsplitjoinloopノード結合ABABノード分割ABABループ置換loopXXislowercostノード置換AXXislowercost図3でピッチとあるのは、パイプラインピッチ、すなわち、パイプライン処理の1ステージの処理時間のことである。また、リソースとは、使用するCPUの数である。図3のリソース欄には、この実施例の場合、図1のシステムにおけるスレッドの数が記載される。構成テーブル208のエントリは、イーサネットスタックイーサネットポート110に接続された、ハードウェア及びソフトウェアを含むシステム環境209に基づき、図示しない所定の処理モジュールによって作成される。このことは、UDOP毎に、UDOPを実現するカーネル定義を取得し、実行対象のハードウェアコンフィギュレーションを取得し、使用アーキテクチャを組み合わせて使用リソースの組を用意し、これらについて、実行可能なカーネルを選択し、実行パターンを生成し、パイプラインピッチを測定するという処理を、使用リソースの組全てについて実行することによって達成される。このより詳しい処理は、本出願人に係る特願2009-271308号明細書の図3と対応する明細書の記述を参照されたい。コンパイラ210は、様相パターン群206の各様相パターン毎に、構成テーブル208のエントリを参照して、各様相パターン毎に、ストリーム形式コードを作成する。なお、ストリーム形式コードを記述するためのストリームプログラミング言語として、インターナショナルビジネスマシーンズコーポレーションのSPADE、マサチューセッツ工科大学ののStreamltがなどが知られている。Streamltによれば、図4に示すストリームグラフは、次のようなコードで記述される。addsplitjoinsplitroundrobinaddpipelineaddAaddBaddCaddDaddpipelineaddEaddFjoinroundrobinStreamltのより詳細な説明については、httpgroupscsailmiteducagstreamitあるいは、httpgroupscsailmiteducagstreamitpapersstreamitcookbookpdfを参照されたい。また、SPADEについては、httpdominoresearchibmcomcommresearchprojectsnsfpagesespsspadehtmlを参照されたい。コンパイラ210が、各様相パターンに基づきストリーム形式コードを作成する。より詳しい処理については、後でより詳しく説明する。ストリーム形式コードは、処理を実行するタスクと、そのタスクを実行するハードウェア資源を、グラフ形式で記述する。こうして、ストリーム形式コードが、各様相パターン毎に生成されると、図示しない特定の処理プログラムが、各様相パターンに対応するストリーム形式コードの間の遷移テーブル214を生成する。なお、遷移テーブル214の生成は、コンパイラ210によって行うようにしてもよい。尚、以下では、ストリーム形式コードの集まりを、ストリーム形式コード群212と呼ぶ。以上述べたのは、事前に様相パターン群206、ストリーム形式コード群212、遷移テーブル214を用意するためのモジュールであったが、次に、実際のルータアプライアンス100の動作の間に動作するモジュール群を説明する。様相パターン計測モジュール216は、ルータアプライアンス100の動作の間に、好適には、統計情報収集モジュール202よりも軽量な、ストリーム形式コードの先頭のタスクが処理するデータを種類ごとに数え上げるという処理を用いて、様相パターンを計測する。計測は例えば、ルータアプライアンス100が扱うトラヒックの性質に適切な周期で行われる。様相パターン比較モジュール218は、様相パターン計測モジュール216が計測した様相パターンと、様相パターン群206の各様相パターンとを比較する機能をもつ。その比較の結果、一番近い様相パターンに対応するストリーム形式コードが、ストリーム形式コード選択モジュール220によって、ストリーム形式コード群212から選ばれる。切換モジュール222は、今まで実行環境224で実行されていたストリーム形式コードから、様相パターン比較モジュール218の比較結果に基づき選ばれたストリーム形式コードに切り替えて、実行環境224で実行させる機能をもつ。その際、本発明の特徴によれば、切換モジュール222は、現在のストリーム形式コードから、次のストリーム形式コードに切り替える際に、適切な代行タスクを立てることで、プログラム停止時間を減少させる。この処理の詳細は、後でフローチャートなどを使用して説明する。次に、図5のフローチャートを参照して、統計情報の収集及び事前処理の流れについて説明する。この処理は、例えば、ルータアプライアンス100を本発明の機能に従って動作させる前に、ユーザーの操作により開始される。ステップ502では、統計情報収集モジュール202が、イーサネットスタックイーサネットポート110に到来するトラヒックを時間毎に収集する。統計情報収集モジュール202は、SNMPプロトコル、tcpdumpというパケット解析コマンドまたは、ルークネットワークス社から入手可能な、NetFlowTrackerという商用ツール、などを使用する。ここで収集される情報とは、メール、FTP、動画、ウェブなどのトラヒックの割合である。統計情報収集モジュール202は、典型的には、少なくとも平日丸一日分、休日丸一日分のトラヒック情報を収集して、図示しないコンピュータシステムのハードディスクドライブなどに保存する。図6に、トラヒック情報が時間とともに変化する様子が模式的に示されている。ここでは、メール、FTP、動画及びウェブが例示的に示されているが、これは一例であって、実際はより多様な種類の内容のトラフィックがありえることを理解されたい。ステップ504では、様相パターン抽出モジュール204が、統計情報収集モジュール202が収集したトラヒック情報から、図7に示すような複数の典型的な様相パターン702、704706を抽出する。様相パターン702、704706は、一定時間毎に抽出したトラヒック情報のバターンであってもよいし、あるいは、一定時間毎に抽出したトラヒック情報のバターンを複数集めて、例えばK平均法によってクラスタリングして得られたクラスタから、代表的なものを取り出してもよい。様相パターンフェーズ702、704706は、様相パターン群206として、好適にはRAM108に保存される。このようにして生成された様相パターン702、704706にはそれぞれ、固有のフェーズIDが付与される。ステップ506では、コンパイラ210が、構成テーブル208の項目を参照して、様相パターン群206の各様相パターンフェーズ毎に、ストリーム形式コードを生成する。言い換えると、フェーズ毎に、ストリームプロセッシングに基づいたリソースマッピングを導出する。図8は、ベースとなるストリームプログラムの例であり、図示されているように、イーサネットプロトコルスタックに、IPプロトコルスタックが接続され、そこから、TCPプロトコルスタックと、UDPプロトコルスタックに分岐し、TCPプロトコルスタックと、UDPプロトコルスタックは、ウイルススキャンに接続されるとともに、SSLプロトコルスタックにも接続され、SSLプロトコルスタックはウイルススキャンに接続され、ウイルススキャンは、XMLアクラセレータに接続される。図8では、ストリームプログラムの各処理要素の負荷は考慮されていないが、図9の様相902のように、特定のトラヒック情報の様相に対応して、ストリームプログラムの各処理要素にかかる負荷が変化する。すなわち、図9において、各処理要素を囲むボックスの大きさが、負荷をあらわしているものとする。図10は、さらに別のトラヒック情報の様相1002に対して、各処理要素にかかる負荷分散が異なる様子を示す。すなわち、トラヒック情報の様相が変化したとき、ストリームプログラムの特定の各処理要素に負荷がかかりすぎて、そこがボトルネックになり、全体の処理速度が低下してしまう。そこで、ストリームプログラムにおいては、リソースマッピングにより、処理の最適化が図られる。そのための方法として、次のようなものがある。-データ並列化、パイプラインの決定このとき、タスク並列も利用することで、メモリアクセスのローカリティの向上、通信競合の抑制、通信遅延の隠蔽などの効果が得られる。-処理が重いプロトコルスタックを複数ステージに切り分けたり、軽いプロトコルスタックを1つのステージに統合したりすることで、資源あたりの負荷とパイプラインピッチのバランスを取る。このための詳細な処理は、やや複雑なので、後で別途説明する。生成されたストリーム形式コード群212は、好適にはRAM108に保存される。ステップ508では、このようにして作成されたストリーム形式コード群212のストリーム形式コード間の遷移テーブル214が作成される。遷移テーブル214は、プロファイルのフェーズ毎に、プロセッサ毎のストリーム形式コードにおける本タスク、及び1つのストリーム形式コードから別のストリーム形式コードに切り替える際の代行タスクを含む。遷移テーブル214の内容についても、後で詳細に説明する。次に、図11以下を参照して、ストリーム形式コードを生成する処理について説明する。図11において、システム環境209、すなわちリソース制約ハードウェアコンフィギュレーション、及び構成テーブル208が事前に用意されるものとする。機能ブロックA,B,C.Dからなるストリームグラフとリソース制約の例を、図12に示す。ここでいうシステム環境209とは、図1のイーサネットスタックイーサネットポート110に接続されているシステム構成のことである。コンパイラ210は、ステップ1102で、フィルタリングを行う。すなわち、与えられたハードウェアコンフィギュレーションと構成テーブル208から実行可能なパターンのみ抽出し、最適化表を作成する。コンパイラ210は、ステップ1104で、最適化表を参照して、ストリームグラフ中の各UDOPにもっともパイプラインピッチの短い実行パターンを割り当てた実行パターン群を作成する。それを、ストリームグラフの各ブロックに割り当てた様子を示す例を、図13に示す。次にステップ1106では、コンパイラ210は、実行パターン群は与えられたリソース制約を満たしているかどうかを判断する。ステップ1106で、コンパイラ210が、実行パターン群が与えられたリソース制約を満たしていると判断すると、この処理は完了する。ステップ1106で、コンパイラ210が、実行パターン群が与えられたリソース制約を満たしてないと判断すると、ステップ1108に進み、実行パターン群中の実行パターン群をパイプラインピッチ順にソートしたリストを作成する。次に、ステップ1110に進み、コンパイラ210は、リストから一番パイプラインピッチが短い実行パターンを持つUDOPを選択する。次に、ステップ1112に進み、コンパイラ210は、UDOPについて、消費リソースのより少ない実行パターン次候補が最適化表に存在するかを判断する。もしそうなら、ステップ1114に進み、コンパイラ210は、UDOPについて、実行パターン次候補のパイプラインピッチはリスト内の最長値より小さいかどうかを判断する。もしそうなら、ステップ1116に進み、コンパイラ210は、実行パターン次候補をUDOPの新しい実行パターンとして割り当て、実行パターン群を更新する。ステップ1116からは、ステップ1106の判断に戻る。ステップ1112での判断が否定的なら、ステップ1118に進み、そこで、コンパイラ210は、当該UDOPをから外す。次に、ステップ1120に進み、そこでコンパイラ210は、リストに要素が存在するかどうかを判断する。もしそうなら、ステップ1108に戻る。ステップ1120で、リストに要素が存在しないと判断されたなら、ステップ1122に進み、そこでコンパイラ210は、実行パターン群中の実行パターン群を、実行パターン群の最長パイプラインピッチと次候補のパイプラインピッチの差の順にソートしたリストを作成する。次に、ステップ1124で、コンパイラ210は、リストのうちパイプラインピッチの差が一番短い実行パターンについて、それが要求するリソースが、現在注目しているリソースより少ないかどうかを判断する。もしそうなら、ステップ1126に進み、そこでコンパイラ210は、実行パターンを新しい実行パターンとして割り当て、実行パターン群を更新し、ステップ806に進む。そうでなければ、ステップ1128で当該UDOPをから外して、ステップ1122に戻る。図14は、このような実行パターン群の置き換えによる最適化の例を示す図である。図14では、リソース制約を解くために、D4がD5に置き換えられている。こうして、リソースの割当てが行われると、その各々のストリーム形式コードは、ストリーム形式コード群212として、好適にはRAM108にストアされる。なお、各々のストリーム形式コードの各タスクには、固有のタスクIDが付与される。次に、図15のフローチャートを参照して、フェーズ切り替え時の代行タスクを選択する処理を説明する。この処理は、プロセッサ104またはプロセッサ106で走る所定のスレッドによって実行される。図15のフローチャートの説明を行う前に、以下で使用する記号または数式の定義を説明しておく。定義task資源rのフェーズbでのタスクPreタスクtの先行タスクの集合Postタスクtの後続タスクの集合※1:フェーズbでのタスクtの開始時間startmaxstartp∈Prepitchpitchパイプラインピッチ各タスクの実行時間※2:costDCTDmax0startstartDは、代理タスク実行開始までの空き時間を含むコストである。Cmaxdelaydelayi∈Deputizes∈Prej∈Resourceu∈PostResourceフェーズbでタスクtを担当する資源の集合Deputizeフェーズaからフェーズbへの切り替え時にタスクtを代行する資源の集合delay資源aがデータの送信を開始してから、資源bがデータの受信を完了するまでの時間Tchangetchangechangeもしタスクt1がt2と同じなら0、そうでなければTCタスク切り替え1回あたりのコスト、任意の定数図15のフローチャートに戻って、ステップ1502では、資源の集合Rと、フェーズabが入力される。このとき、資源の集合Rには資源IDと各資源間の通信遅延が含まれる。また、フェーズabにはタスクID、各タスクを担当する資源ID、各タスクの先行後続タスクの集合、各タスクの実行時間が含まれる。これは、図5のステップ508に対応する。ステップ1504では、フェーズbのタスクより厳密に言うと、フェーズbに対応するストリームグラフにおけるタスクを、タスク開始時間の昇順にソートしたリストTbが作成される。ここで、タスク開始時間とは、上記※1で定義されるものである。ステップ1506では、tにTbの先頭のタスクが置かれる。次に、ステップ1508から、ステップ1510、ステップ1512、ステップ1514、ステップ1516までは、フェーズbでtを担当する各資源rbについての処理である。ステップ1510では、Rに含まれ、且つrbと同じ種類である資源rの中で、costが最も小さいrをrbとする。ここで、資源の種類とは、汎用プロセッサ、グラフィックプロセッシングユニットであるアクセラレータなどのことである。また、costとは上記※2で定義されるものである。ステップ1512では、rbの代行タスクがtとされる。次にステップ1514では、Rからrbが削除される。こうして、ステップ1508に戻り、フェーズbでtを担当する資源rbがある限り、ステップ1510、ステップ1512、ステップ1514、ステップ1516までが繰り返される。ステップ1518では、Tbから先頭の要素tが削除されて、ステップ2320で、Tbが空かどうかが判断される。そうでなければ、処理は、ステップ1506に戻る。ステップ1506での先頭というのは、ステップ1518でTbから先頭の要素tが削除された後の次の要素のことである。ステップ2320で、Tbが空であると判断されると、各タスクの代行資源の集合が得られる。すなわち、ステップ1512で、資源rbの代行タスクtが決定されるので、そのようなの集合ということである。図15のフローチャートの処理は、互いに異なるフェーズabのあらゆる組み合わせについて行われる。その結果、図16に示すように、ルータアプライアンス100に接続されて、利用可能なすべての資源の各々について、フェーズIDと本タスクのIDの対応テーブルと、フェーズIDと代行タスクのIDの対応テーブルが作成される。フェーズIDと代行タスクのIDの対応テーブルは、双方向の移行をあらわすために、2次元テーブルとして表される。これらの対応テーブルは、図2で遷移テーブル214として示すものである。すなわち、フェーズIDと本タスクのIDの対応テーブルは、図5のステップ506で作成され、フェーズIDと代行タスクのIDの対応テーブルは、図5のステップ508で作成される。各資源上で実行するプログラムは、タスクIDを基にコールする関数をスイッチするようなラッパーを用意し切り替えることができる。上記は、通常タスク用のテーブルであるが、さらに、監視タスク用のテーブルを用意してもよい。これは、フェーズ切り替え時の判定に用いる閾値を保持するものであって、時間帯毎での切り替えの場合は、時間とフェーズIDの組からなり、K平均法の場合は、重心とフェーズIDの組からなる。図17は、ストリーム形式コード群212と、遷移テーブルが用意された後の、様相パターン計測モジュール216と、様相パターン比較モジュール218の動作を示すフローチャートである。図17において、ステップ1702では、様相パターン計測モジュール216が、負荷測定、すなわち、イーサネットスタックイーサネットポート110に到来するトラヒックを収集する。様相パターン比較モジュール218は、その計測されたトラヒックの様相フェーズと、現在選ばれているフェーズの距離を計算してステップ1702で、フェーズ切り替え判定を行う。すなわち、その距離が、所定の閾値以内であるなら、切り替えないという判定を行って、ステップ1702に戻る。また、その距離が、所定の閾値以上であるなら、切り替えるという判定を行って、ステップ1706に進む。尚、図7に示すように、フェーズは、メール、FTP、動画、ウェブなどのトラヒックの割合を成分とする特徴ベクトルと考えることができ、すると、その特徴ベクトル同士の間に、ユークリッド距離、マンハッタン距離、内積などの値を定義することができる。そして、このような内積や距離が閾値内にあるかどうかを調べればよい。ステップ1706では、様相パターン比較モジュール218が、ストリーム形式コード選択モジュール220に対して、グラフ先頭の資源フェーズ切替指示を送信する。そうして処理は、ステップ1702に戻る。図18は、ストリーム形式コード選択モジュール220、切換モジュール222及び実行環境224の動作のフローチャートを示す図である。ステップ1802では、実行環境224が、現在選ばれているストリーム形式コードにおいて、本タスクを実行する。ステップ1804では、切換モジュール222が、全ての先行資源からフェーズ切替指示を受信したかどうかを判断する。そうでなければ、ステップ1802に戻って、実行環境224が、本タスクを実行し続ける。ステップ1804で、切換モジュール222が、全ての先行資源からフェーズ切替指示を受信すると、ステップ1806に進み、そこで、監視タスクによって既に選択されているストリーム形式コードが、後続ストリーム形式コードとする。そこで、後続ストリーム形式コードのIDがフェーズ切り替え指示に含まれているので、ステップ1806では、切換モジュール222が、全ての後続資源のデータキューの末尾に、フェーズ切替指示を追加する。次に、ステップ1808に進んで、切換モジュール222が、後続ストリーム形式コードにおける本タスク開始時刻を過ぎたかどうか判断する。そうでなければ、ステップ1810で、実行環境224が、フェーズ切替指示のフェーズIDでの代行タスクを実行しつつ、ステップ1808に戻る。代行タスクは、図16に示すように、使用中の資源における、直前のフェーズIDと、今のフェーズIDから決定することができる。ステップ1808で、切換モジュール222が、後続ストリーム形式コードにおける本タスク開始時刻を過ぎたと判断すると、ステップ1812に進む。ステップ1812では、切換モジュール222は、ステップ1812で、代行タスクのデータがキューに残っているかどうかを判断する。そうでなければ、処理は、ステップ1802の本タスク実行に戻る。ステップ1812で、切換モジュール222が、ステップ1812で、代行タスクのデータがキューに残っていると判断したなら、処理はステップ1814に進み、切換モジュール222は、実行環境224に代行タスクを実行させ、その出力を、後続のタスクを本来実行する資源に送信する。以下、代行タスクを用いたフェーズ切り替え動作について、模式的な例によって、より具体的に説明する。先ず、図19は、ルータアプライアンス100のイーサネットスタックイーサネットポート110に接続されている計算資源のトポロジである。これは、物理的トポロジであって、ソフトウェア的なものではないので、動的に再構成できない。図20は、このような資源1~資源6からなる物理的トポロジの計算資源に対して、に示すようにフェーズαとしてストリーム形式で資源の割り振りが行われている状態から、に示すようにフェーズβとしてストリーム形式で資源の割り振りが行われている状態に移行する場合に、に示すような代理タスクを使用する経過的な状態を経ることによって、フェーズ切り替えに伴うシステム停止時間を低減するものである。すなわち、図20で、資源1がタスクaを、資源2がタスクcを、資源3がタスクdを、資源4がタスクeを、資源5がタスクfを、資源6がタスクbを実行しているフェーズαの状態から、図20で、資源1がタスクAを、資源2がタスクBを、資源3がタスクCを、資源4がタスクEを、資源5がタスクDを、資源6がタスクFを実行しているフェーズβの状態に移行するために、図20で、ステップ1810にあるように、資源3がタスクDを実行して資源5に送信し、次にステップ1814にあるように、資源3がタスクDを実行して資源6に送信し、図20に移行して、次にステップ1802にあるように、資源3がタスクCを実行して資源5に送信する。同様に、資源6も、図20で、タスクCを代行で実行して、資源4と資源3に送信する。図21は、実行タスクの遷移サイクルを示す図である。図において特に、資源6のタスクCの実行と、資源3のタスクDの実行が、代行タスクとしての実行である。すなわち、各フェーズは、パイプライン化されているため、先頭のタスクから順に終わっていく。そこで、本発明の基本的なスキームによれば、先にフェーズαを終えた資源が、フェーズβの前方の資源を代行し、全ての資源がフェーズαのタスクを終えたら、本来のタスクを開始する。以上、特定の実施例に従い本発明を説明してきたが、示されたハードウェア、ソフトウェア、ネットワーク構成は例示に過ぎず、本発明は、これらと機能的に等価な任意の構成で実現可能であることを理解されたい。"