"所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、を備えたストレージシステム。請求項1に記載のストレージシステムであって、前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するが否かを検出し、前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、ストレージシステム。請求項2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、検出した前記進捗状況が前記理想値を満たさず前記処理待ちタスクが存在しない前記処理部の前記進捗状況を、その処理部の前記目標値として設定する、ストレージシステム。請求項2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、検出した前記進捗状況が前記目標値を超えている前記他の処理部の前記目標値を引き上げるよう設定する、ストレージシステム。請求項2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、前記目標値を引き上げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き上げるよう設定する、ストレージシステム。請求項2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、検出した前記進捗状況が前記目標値に満たない前記処理部に前記処理待ちタスクが存在している場合に、他の前記処理部の前記目標値を引き下げるよう設定する、ストレージシステム。請求項6に記載のストレージシステムであって、前記目標値設定部は、前記目標値を引き下げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き下げるよう設定する、ストレージシステム。所定のタスクをそれぞれ実行する各処理部が実装された情報処理装置に、前記各処理部による前記情報処理装置全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、を実現させるためのプログラム。請求項8に記載のプログラムであって、前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するが否かを検出し、前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、プログラム。所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出し、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定し、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する、情報処理方法。請求項10に記載の情報処理方法であって、前記進捗状況の検出時に、前記各処理部に処理待ちタスクが存在するが否かを検出し、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、情報処理方法。分散型ストレージシステムでは、システムのアーキテクチャの複雑性、システム固有の不均一性、またロードが予測不能であることから、リソースを制御するメカニズムの設計は困難な仕事である。複合的なシステムに関しては、特定のロードが使用するリソースの種類と量を予測する十分なモデルを定義することは、まずできない。ロードは必要とするリソースを動的に変更するため、ロードに対するリソースの静的割り当てといった簡易な解決策は現実的ではない。さらに、同じサーバに対する外部の処理によって、システム内のロードが利用可能なリソースの総量は時間と共に変化する。また、ユーザにより書込みおよびバックグラウンドタスクの特徴がいずれも非常に多様であることも、この問題が複雑になる理由である。ユーザの書込みには限られた待ち時間が要求されることがあるが、通常は、重複排除、キャッシュ、および作業負荷の変動等の理由により、1つのブロック書込み時間を予測することができない。プリフェッチでは限られたメモリしか使用できないため、高いパフォーマンスを実現するには、ユーザの読出しにはよりいっそう低レイテンシが必要になる。このため、本発明の目的は、上述した課題である、ストレージシステムにおいてリソースの効率的な使用を図り、システムの性能の向上を図ること、にある。本発明の一形態であるストレージシステムは、所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、を備えた、という構成をとる。また、本発明の他の形態であるプログラムは、所定のタスクをそれぞれ実行する各処理部が実装された情報処理装置に、前記各処理部による前記情報処理装置全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、を実現させるためのプログラムである。また、本発明の他の形態である情報処理方法は、所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出し、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定し、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する、という構成をとる。本発明は、以上のように構成されることにより、リソースの効率的な使用を図り、ストレージシステムの性能の向上を図ることができる。<実施形態1>本願では、システム内における高レベルなリソースの利用を確かなものにする一方、異種のロード間で動的にリソースを分配するメカニズムについて述べる。ここで述べるアプローチは、ロードの抽象的概念に基づくものであり、利用するリソースや特定のタイプのロードの処理を仮定することはない。特に、ロードは異なるタイプの複数のオブジェクトによって処理され、各々が同じリソースを得るために競い合うことがある。本願で提案する方法は、ロードが利用するリソースを比例配分するのではなく、ロードを比例的に進捗させることである。ユーザの視点で考えると、ユーザはリソース消費といった内部で実施されることの詳細よりも、ロードの影響と進捗に関心を持つため、このようなアプローチが好ましい。また、このようなアプローチは、システムの観点からも好ましい。その理由は、精密なリソース配分や計算は、複雑なシステム、特に分散型のシステムには問題が多いからである。このため、本願では、バックグラウンドタスクを含む異種のロードまで対象を広げた。異種のロードの進捗を制御するために、各ロードが進捗インジケータを有し、他のロードの進捗と比較できるようにした。ほとんどのタスクはデータに対して動作するため、このようなインジケータは、ロードに関連するタスクによって生成されるスループット、つまり処理データの総量を経過時間で割った値、として選択することができる。例えば、書込み要求のスループットは、1秒当たりのディスクに保存されるデータ量である。データに対する動作ではないタスクについては、そのタスクによって達成される進捗を推定する人為的な値をスループットとして使用してもよい。同じスループットを持つタスクでも、システムに対する負荷が異なる場合がある。他のタスクよりもはるかに重いタスク、つまり、同量のリソースでは進捗がはるかに遅くなるタスクもある。そのようなタスクは、高い進捗を得るために膨大な量のリソースを消費しなければならず、他のタスクの実行を遅延させたり、場合によっては阻害することもある。このような影響を減らすために、任意の加重により、かかるタスクのスループットを人為的に増加させることができる。ここからは、ロードのスループットについて、ロードタイプに関連する加重を加えたスループットと理解する。また、進捗については様々な測定基準があるが、スループットによって測定すると仮定とする。コアアルゴリズムは、所定のポリシに従ってロード間でリソースを分配する。ポリシは、進捗割り当て、つまりシステムの総スループットを既存のロード間で分配する比率、を特定する。このポリシはシステムの状態に応じて動的に変化することがある。例1図1に進捗ポリシの一例を示す。これらの進捗割り当てシェアにより、数1式を満たすロードのスループットを達成することを目的とする。つまり、各ロードタイプによって生成されるスループットが各進捗割り当てに比例することが目的となる。上記のように、ロードの進捗を制御するメカニズムは、システム内のリソースが最大限に使用される状態を維持する。あるロードが自身の進捗配分を消費できない場合例えばアプリケーションのシステムへの書込みスループットが低い、またはメンテナンスタスクを実行する必要がない場合、他のタイプの進捗が加速されるため、システム内の全リソースが使用される。例2図1の進捗ポリシについて検討する。ロードタイプ1が進捗全体の25しか消費できない場合、残りの25はロードタイプ2とロードタイプ3に対して、ポリシに比例して分配される。その結果、ロードタイプ2には453015、ロードタイプ3には302010が分配される。条件の変化に対して十分な反応時間を取ることは重要である。その理由は、特定のロードのリソース消費と利用可能なリソースは常に変動するからである。このような変動の主な原因は、時間と共にポリシとロードが変化することである。さらに、制御されているシステムの外部で行われる処理も、システムのロードが利用可能なリソースに影響を与える。リソース分配メカニズムの高レベル構造を図2に示す。すべてのロードソースは、各々、出力された制限値を通じて各自の処理速度を制御する許可制御メカニズムAdmissionControlMechanism:ACMを持つ。制限値実施形態2における目標値は、ソースによって生成されるスループットに影響を与えるため、制限値の引き上げまたは引き下げは、スループットにおける同様の変化を誘発する。例えば、制限値は、ロードのスループットの上限値、または、特定のロードタイプの同時に実行されるタスク数の制限値、などである。進捗ポリシに定められたスループットの比率を達成するため、アルゴリズムは定期的に各ロードのスループットを測定し、その制限値の現在値を調整する。本願は、以下のように構成されている。まず、本願における新しいアルゴリズムを説明する。次に、アルゴリズムの要素について詳細に述べる。次に、企業向けストレージシステムであるHYDRAstor非特許文献3でのタスクのスケジューリングに関する具体的な問題と、このシステムに実装している本願の解決策について説明する。次に、HYDRAstorで行った実験の結果を提示し、この解決策の主な特性を証明する。次に、関連技術を我々のアプローチと対比させて説明し、最後に、結論を述べる。[リソース管理メカニズム]ここでは、リソース管理メカニズムの構成と、異なるタイプのロードを制御して、進捗ポリシに定める比率でそれらのスループットを維持するコアアルゴリズムについて説明する。[アーキテクチャ]リソース管理メカニズムは、以下の部分によって構成される図2参照。1.許可制御メカニズムACM:あらゆるロードタイプと関連付けられたソフトウェアユニットで、制限値を通じてソースの処理速度を制御する。制限値が大きいとは、上記で説明したように、対応するロードソースがより高速で動作できることを意味する。ロードに関して、ACMは、ソースのスループットを含む情報と、ソース内で実行を待っているタスクの有無の指標と、を集める。ACMの情報については後に詳細に説明する。2.フィルタ:スループット等の値の変動を排除するために、ACMから受信した情報の平滑化を行う機能を持つ。簡易なフィルタでは所定の期間で平均化することがある。3.アルゴリズム:上述したようにロードソースの現状を記述するすべてのACMからのフィルタリングされた情報を用いて、各ロードタイプについて、制限値の引き上げ、引き下げ、または現状維持を決定する。4.コントローラ:アルゴリズムの決定を受信し、そのACMに関する制限値の正確な値を計算する。このアルゴリズムは、定期的に本願で実施したのは10秒毎。この期間は最長の分割不能タスクの長さに基づくすべてのACMから情報を収集し、決定を下し、それを適切なコントローラに提供する。コントローラは制限値の新たな値を計算し、それをACMに提供する。すべてのサイクルにおいて、進捗の実際の分配実施形態2における進捗状況を進捗ポリシが示す所望のもの実施形態2における理想値に近づけるよう制限値実施形態2における目標値が修正される。進捗の分配から進捗ポリシによる分配への収束速度と、システムの安定性と、はトレードオフの関係にある。[飽和検出]ロードソースの処理速度を上げるために、アルゴリズムはそのACMの制限値を引き上げる。しかし、タスクを処理するサーバのリソースは限られているため、ある一定のレベルを超えてロードタイプのパフォーマンスを高めることはできない。例3ACMの制限値を、スループットの上限値と定義する。毎秒Tバイトを処理する能力を持つサーバについて考えてみると、ACMの制限値がTより高くなっても、対応するロードソースはTの速度で動作する。そのサーバで外部の処理が行われている場合、またはそのサーバが他のロードも処理している場合、システムはもっと少ないタスクしか処理できない例えばtバイトt<Tとする。このような状況では、制限値が上がってもロードソースはt以下の速度で動作する。例4制限値を、並行して実行できるタスク数の上限と定義する。サーバは、いくつでも並行してタスクを許可することが可能だが、一定の値を超えて制限値を上げてもスループットが増えるわけではなく、ページングや頻繁なコンテキストのスイッチングにより、スループットが低下することすらある。最大のスループットをもたらす可能性がある最小限の値をnとする。制限値をnより大きくしても、実際のスループットに何ら影響はない。nの値は一定ではなく、システム内で平行して実行されている他のタスクによって変化する。上記例3と例4のいずれでも、スループットを低下させずにそのロードの他の性能例えばレイテンシ待ち時間、メモリ消費等を改善する制約を導入することができる。例3では、システムが現在処理しているデータ量を制限することができる。このような制約は、パフォーマンスに影響を与えずに、スラッシングを排除しメモリ消費を削減する。例4では、同時タスクについて、レイテンシが所定の定数Lを下回った状態を維持することで、同時タスク数nを制御することができる。ACMにnよりも大きい制限値Nが与えられている場合でも、ソースはレイテンシ制限を守るためにnを使用する。例3と同様に、サーバで外部の処理が行われている場合、またはサーバが他のタイプのタスクを処理している場合、サーバが処理できる同時要求はさらに少なくなるレイテンシ制限。すべてのロードソースに対して、システム内の進行中のロードに関するこのような制約を導入できると仮定する。このような制約があると、システムでリソースが不足した場合、ソースは所定の制限値に達しないこともあるが、制限値が低いものとして動作するACMが制限に達しなかった、という。あるタイプのタスクのリソースが不足し、そのために制限値にかかわらず所望の速度に達することができない状態をリソース飽和または単に飽和という。本願では、各ACMが飽和によってロードの動作が非常に遅い状態を検出できるものと仮定する。ロードは飽和の場合だけでなく、十分な仕事がない場合も制限に達しない。例えば、バックグラウンドタスクについては、実行するバックグラウンドタスクがほとんどない場合、またユーザーロードについては、システムに対する外部のアプリケーションの書込みのスループットが低い場合に発生する。[ACM情報]各ACMからアルゴリズムへ送信される情報は、以下のフィールドで構成される。limit制限値:上述した処理速度の制限。この値はアルゴリズムによって事前に設定され、アルゴリズムをステートレスにする場合のみ返送される。hasWaitingWork実行待ち作業あり:ソースに実行待ちタスクがあることを示す例5参照。近い将来の作業量は現在の量と類似すると仮定する。ソースに実行待ち作業がある場合は、limitを引き上げるか、またはリソースを増やす他のソースのlimitを引き下げることで、その処理速度を上げることができる。throughputスループット:前回の情報収集以降に、対応するロードタイプのタスクによって生成されるスループット。これは進捗インジケータである上記参照。limitAchieved制限値達成:ロードタイプが制限値に達したかどうかを示す例6参照。上述したように、リソース不足飽和または処理がないために、ソースが制限まで使用されないこともある。例5:hasWaitingWorkがどのように計算されるかを見るために、バッファからのタスクを処理するソースについて検討する。タスクは、ACMの制限値が許可し、追加のリソース制約がない場合に、バッファからシステムへ送信される。リソース制約とは、例えばシステム内に利用可能なメモリがない、処理される要求のレイテンシが長すぎる例4参照、またはシステム内の実行中のロードが所定値を超えている例3参照、等である。このようなモデルでは、hasWaitingWorkはバッファ内で待っている要求があるかどうかを示す。例6limitAchievedがどのように計算されるかについて、以下の2つのケースを検討する。制限値がスループットの上限値である場合例3参照、limitAchievedは、前回の情報が回収された以降のいずれかの時点で、次の等式が満たされる場合にのみ真である。throughputlimit制限値が同時に実行されるタスク数の上限値である場合例4参照、limitAchievedは前回の情報が回収された以降のいずれかの時点で次の等式が満たされる場合にのみ真である。nlimitロードソースにシステムに出すタスクがない場合その場合、hasWaitingWorkは偽、またはロードソースが十分なリソースを取得しない場合既に飽和に、limitAchievedは偽となる。[アルゴリズム]アルゴリズムは、ACMから収集した情報を用いて、各ロードソース用の制限値limitの引き上げ、引き下げ、または現状維持をすべきかを推論する。この決定に基づき、コントローラが各制限値の新たな値を計算する。アルゴリズムによる決定は、システムが飽和状態かどうかに依存する。あるロードタイプに関して、hasWaitingWorkが真に設定されlimitAchievedが偽に設定されている場合、飽和状態と診断される。つまり、このロードソースには実行すべき作業があり、その制限値は高速化を許可しているが、リソース不足により速度を上げることができないことを意味する。したがって、処理速度を上げるためには、他のタイプのロードの制限値を下げるべきである。一方、システムが飽和状態でない場合各ロードに作業がない、または所定の制限値に達していない場合、アルゴリズムは少なくとも1つのロードの制限値を引き上げる補助定理2参照。このアルゴリズムの骨格を、図4のアルゴリズム1に示す。入力として、ACMから収集した情報と、進捗割り当てマップであるポリシを取る。最初の3ステップで、ローカル変数を初期化する。ステップ4と5で現在の進捗割り当てをカウントする。ステップ6~8では、変数someoneHasWorkを初期化する。以降のステップについては次のサブセクションで説明する。[目標割り当てtargetSharesの再計算]ステップ10で、アルゴリズムは、待ち作業のないロードの割り当てを、待ち作業のあるロードに分配する。待ち作業のないロードにはそれらが利用する割り当てのみが残され、残りの部分は待ち作業のあるロードに分配される。このような割り当ての再計算は、リソースを最大限に利用し、進捗の分配を修正するために行われる。これについては、上述した例2で記載しており、またその詳細を以下に説明する。ロードタイプLに待ち作業がなく、現在の割り当てcurrentShareがポリシで定められるものよりも低い場合hasWaitingWork=偽、および、currentSharetargetShareであるロードタイプのリソースが減少する。3.システムが飽和状態でない場合は、すべてのロードがフルスピードで処理される。[コントローラの設計]上記では、望ましい進捗分配とリソースの最大活用を実現するための一般的な解決策を説明してきた。ここでは、リソース管理メカニズムの反応時間を改善するコントローラの更なるメカニズムについて説明する。[制限引き下げの高速化]limitの引き下げが直ちに実行されない以下の例について検討する。例8ソースのlimitがスループットの上限であると定義する。以下のシーケンスについて検討する。1.ソースには作業があり、それはシステム内で作業がある唯一のロードである。そのためlimitが引き上げられる例えば制限値50MB/秒。2.ソースがタスクを終了したため、作業がなくなった。制限値は50MB/秒のままである。3.しばらくの後、ソースは作業が開始したが、もはやシステム内で唯一のロードではない。その結果、待ち作業がある。制限値は50MB/秒のままだが、作業のスループットは25MB/秒である高速で作業を行うためのリソースがない。ここで、アルゴリズムがこのソースのlimitを例えば45MB/秒に引き下げても、実際は25MB/秒の速度で作業を行っているため、ソースの作業速度に影響を与えない。アルゴリズムが数サイクルした後にlimitが25MB/秒を下回り、ソースの作業速度に影響を与え始める。例8に示す状況は、targetSharesへの収束速度に著しい効果をもたらすことがあるため、何らかの改良を加えることは有益である。以下に他の解決策を2つ示す。[スループットをlimit付近で維持]コントローラは、limitを常にソースの作業の現在速度近くに維持するよう目指すことができる。limitがスループットの制限値の場合例3参照、現在のスループットよりもあまり大きくならないようlimitの修正を試みる。例えば次の通り。limitが同時処理タスク数の制限値である場合例4参照、limitをシステム内における現在の同時タスク数nの近くに維持するよう目指す。例えば次の通り。αとβの値は反応時間を満たすように選択されている。本願のシステムでは、αは1.2に設定し、βは各ソース毎に個別に選択する。[制限を現在速度に引き下げる]limitを値Lに引き下げたいと仮定する例8では、L=45MB/秒。Lが、ソースの処理の現在速度よりも大きい場合、limitを現在速度の値まで引き下げなければならない例8では25MB/秒。limitがスループットの制限値の場合は、次の通りである。limitが同時進行タスク数の限度である場合は次の通り。[制限引き上げの高速化]limitを小さな値例えば1から大きな値例えば10000に引き上げることを検討する。アルゴリズム2では、引き上げステップはoldLimitに比例することがわかる。したがって、このような変更には多大なサイクル数が必要であるため、反応時間に関して満足できるものではない。我々は、制限値が低い場合の収束速度を改善する最小制限minLimitを定めることを決定した。[HYDRAstorでのアルゴリズム]HYDRAstor非特許文献3は、企業向け市場を対象とした拡張性のある高性能分散型コンテンツアドレスストレージシステムである。このシステムは、分散型ハッシュテーブルの周囲に構築されたストレージノードのグリッドであるバックエンドと、フロントエンドとで構成される。各ストレージノードは読出し/書込み要求の処理を担当する。このシステムは重複排除に対応しているため、書込み要求の中には、データブロックのディスク上への保存によるオーバーヘッドをもたらさないものもある。ユーザによる書込みおよび読出し要求とは別に、バックエンドでは、障害後のデータ再構築、デフラグ、早期のエラー検出のためのデータスクラビング、ノード間でのデータのバランス調整、またはガーベジコレクションとスペース再利用、といったバックグラウンドのタスクを実行する。バックグラウンドのタスクには各々差別化された特徴があり、また重要である。HYDRAstorでは、異なるタイプのタスクのスケジューリングを行うために適応性のある高レベルリソース管理を利用している。HYDRAstorでは主に、ユーザ要求書込みおよび読出し、データ削除除去するためのブロックのマーキング、およびバックグラウンドタスク再構築、デフラグ、スペース再利用等、という3つのクラスのタスクがある。1つのストレージノードは、同じリソースを使用してあらゆる種類のタスクを同時に実行することができるが、それらは異なるソフトウェア構成要素によって扱われる。HYDRAstor内のタスクのモデルを作るのは難しい。[書込みと読出し]HYDRAstorでの書込みと読出しは、様々なリソースディスク、CPU、メモリ、ネットワークを用いて、いくつかの構成要素によって処理される。書込みでは、データストリームをブロックに分割し、重複を排除し、ブロックを圧縮し、圧縮したブロックを冗長符号化してフラグメント群を作成し、そのフラグメントを適切なストレージノードに保存する必要がある。重複排除機能により、既に保存されているブロックについては、圧縮、冗長符号化、保存を行う必要がない。重複排除をより機能させるために様々なサイズのブロックがあるため、1つの要求の処理に関するオーバーヘッドは常に同じではなく、予測するのは難しい。このシステムは、いくつかのレベルのキャッシュを用いる。これも、書込みと読出しの要求の負荷の予測を困難にする原因である。また1つの要求に対する反応時間が所定値を下回ることが要求されるため、書込みと読出しの要求はこのシステム固有のものである。[バックグラウンドタスク]HYDRAstorでは、ユーザによる書込みと読出しに加えて、一連のメンテナンスタスクがある。これらはユーザに対して透過的であり、バックグラウンドで実行され、パリティデータの再構築、スペース再利用削除のマークが付けられたブロックの除去、デフラグ等のタスクが含まれる。バックグラウンドタスクでのリソース消費は多様である。デフラグ等については、大きなデータブロック上で動作を実行し、主にハードディスク上にロードを出す。また、メタデータの同期等、非常に小さなチャンク上で動作し他のリソースよりも比較的多くのCPUを消費するものもある。またタスクには様々な優先順位のものがある。重要なデータ再構築は、デフラグやスペース再利用よりも優先順位が高い。一方、システムにスペースが不足している場合は、スペース再利用の優先順位が高くなる。システム内でタスクのスケジューリングを行う際、簡単な解決策は、より高い優先順位がないときにだけ、与えられた優先順位でタスクを実行することである。HYDRAstorでは、実行する特定のバックグラウンドタスクを選択する際にこのアプローチが採用された。しかし、優先順位が最も高いバックグラウンドタスクがある場合でも、他のロードタイプ例えばユーザーロードを停止させてはならない。バックグランドタスクは、読出し/書込み動作よりもはるかに長時間を要し、開始したら先回りして回避することができない。読出し/書込みのトップパフォーマンスに対する影響を削減し、ユーザーロードでの変動に耐えられるように、バックグラウンドタスクは、空きリソースが検出されたときに徐々に開始する必要がある。[削除]HYDRAstorのアーキテクチャと重複排除機能により、データの削除は、かなりの計算能力を必要とする、別個の非常に複雑なプロセスとなっている。このシステムでは、他のバックグラウンドタスクやユーザの読出し/書込みと平行して削除を実行することができる。[状態依存型のリソース分配]HYDRAstorのポリシは、システムの状態の変化に伴って変わる。例えば、データの復元レベルが著しく損なわれる障害発生後は、重要な再構築ポリシが有効となり、バックグラウンドタスクに大きな割り当てが与えられる。システムの状態に依存する進捗割り当てを表す様々なポリシを図6に示す。リソース管理アルゴリズムは、常に現状に対応するポリシを使用する。[ローカルアーキテクチャ]HYDRAstorは分散型のシステムである。各ノードは、ローカルで動作するリソース管理メカニズムのインスタンスを含む。しかし、タスクの中には複数のノードのリソースを使用するものもある。そのようなタスクは同期する必要があるため、関与するすべてのノード上で同じ速度で実行される。各々のノードは計算能力も利用できるリソースも異なることがあるため、複数のノードに関わるタスクは、あるノード上で他のノードでの計算を待たなければならない場合がある。その結果、かかるタスクはポリシで保証された速度よりも遅い速度で実行される場合がある。しかし、すべてのノードが同じポリシを持つ限り、すべてのタスクは、少なくとも1つのノード上でポリシにしたがって進捗割り当てを与えられる。あるタスクに関して、速度の遅いリモートノードと同期する必要があるため、あるノードがポリシで与えられている速度よりも遅い速度でそのタスクを実行する場合は、リソースを最大限に利用するために、そのローカルノードは他のタスクもしあればを実行する。[実験評価]ここでは、HYDRAstorシステムを使用して行った2つの実験の結果を説明する。この実験により、リソース管理メカニズムに関して次の2つの主な特徴が判明した。1このアルゴリズムは常にシステム能力を完全に利用する。2リソースが飽和状態の場合、進捗分配はポリシが定めるものに近くなる。[実験の設定]すべての実験でHYDRAstorの4サーバ構成を使用した。各サーバは、2つのクアドコア、64ビット、3.0GHzのIntelXeonプロセッサ、24GBのメモリ、12のRPMHitachiHUA72101AC3ASATAディスクを含み、すべてのサーバでLinuxカーネル2.6.18を使用した。各サーバは2つの論理的ストレージノードを含む。実験は、所定のスループットでシステムに書込みを行うよう構成されたアプリケーションを用いて行われた。また、このアプリケーションは、このシステムで可能な最高速度で動作するよう構成されているレイテンシ制限による。上記参照。[リソースの最大活用]最初の実験は、書込みタスクがシステム内のすべてのリソースを消費しない場合、バックグラウンドタスクを開始してリソースを完全に利用することを示している。この実験では、書込みとバックグラウンドタスクとの2つのロードタイプのタスクを生成した。書込みの特徴は3回変化した。最初の30分間は、外部のアプリケーションがフルスピードで動作して1ノード当たり55MB/秒に達した。30分の時点で構成が変更されてアプリケーションは40MB/秒で一定のスループットを生成した。60分の時点では、書込み速度が再び変更されて10MB/秒になった。そして90分の時点では、書込み速度を45MB/秒に設定したが、重複データが含まれていた。ユーザの書込みの処理と平行して、システムはデフラグも実行していた。システム内には膨大なデータがあるため、常に実行待ち状態のデフラグのタスクがあった。このテストでは、図6のデータデフラグポリシDatadefragmentationを使用した。これは、進捗全体が、ユーザによる書込みとデータ削除の間でのみ分配されることを意味する。この実験ではデータ削除を行わないため、進捗は100ユーザ書込みに与えられることになる。バックグラウンドタスクは、システム内に使用されないリソースがある場合にのみ実行される。この実験の結果を図7に示す。このプロットは、ユーザの書込みのスループット最後の期間では総書込みスループットと非重複データスループットに分けられていると1つのストレージノードからのバックグラウンドタスクを示している。図8は、プロセッサとハードディスクの利用状態を示しており、書込みの各フェーズでのボトルネックリソースが特定される。最初の期間である0~30分では、書込みアプリケーションがフルスピードで動作しており、バックグラウンドタスクはあまり行われていなかった。このフェーズではプロセッサがボトルネックであった。第2の期間である30~60分では、アプリケーションの動作が遅くなり、使用されていないリソースがバックグラウンドタスクに割り当てられた。バックグラウンドタスクは著しく進捗し、この実験では書込みのスループットに影響はなかった。このフェーズではハードディスクがボトルネックであった。ハードディスクはレイテンシ制約内で最大限に利用されていたからである。第3の期間である60~90分では、アプリケーションの動作が更に遅くなっても、バックグラウンドタスクはより高いスループットを達成した。このフェーズでは、同時に実行される書込みタスクが減少したため、限られたレイテンシを容易に維持することができた。その結果、ハードディスクをほぼ100利用することができた。第4の期間である90~120分では、書込みは、スループットの高さにかかわらずシステムに与える負荷が小さかったためほぼすべての書込みが重複、バックグラウンドタスクは再び高速になった。バックグラウンドタスクが達成した最大スループットである110MB/秒がユーザーロードによって達成されたスループットよりも高いことを考えると、書込み動作はデフラグのタスクよりも重いことがわかる。この違いは、上記で説明したスケーリング要因を用いることで修正することができる。HYDRAstorでは、修正を行わずに実際のスループットを用いることに決定した。[ポリシの変更]2つ目の実験は、現在のポリシを変更するものである。システムに書込みを行う外部のアプリケーションは、実験期間全体に渡ってフルスピードで動作するよう構成されていた。最初の1時間は、システムはデフラグのタスクを実行したので、図6のデータデフラグポリシを使用した。次に、60分の時点で、1つのストレージノードで障害が発生してシステムがポリシを通常の再構築Normalreconstructionに変更してデータの再構築を始めるシミュレーションを行った。その25分後85分の時点、データの削除を開始した。これはポリシの変更を伴わないが、システム内に新たなロードタイプが出現した。書込みとバックグラウンドのタスクは常に待ち作業があり、削除は第3フェーズにしか待ち作業がないことを考えると、3つのテストステップにおいて、次のような進捗分配が想定された。1.第1の期間0~60分:書込みに100。2.第2の期間60~85分:書込みに71.5505/7×30、バックグラウンドタスクに28.5202/7×30。つまり、削除のシェアの30が5:2の比率で書込みとバックグラウンドのタスクに分配される。3.第3の期間85~140分:書込みに50、バックグラウンドタスクに20、データ削除に30。図9は想定される進捗分配、図10は1つのストレージノード上でのユーザによる書込み、バックグラウンドタスク、およびデータ削除によって達成されるスループットを示す。その結果である進捗分配書込み-バックグラウンドタスク-削除は、第1の期間では95-5-0、第2の期間では76-24-0、第3の期間では48-21-31であった。[関連技術]制御理論の応用に関する新たなトレンドは、モデルベースの解決策の利用を促すものである。しかし、本願のシステムでは、タスクは、リソース消費だけでなく、レイテンシ制限、限られたメモリ、または分散型の実行といった他の要件についても、差別化された性質を持つ。本願のシステムの複雑なアーキテクチャと、それによって正確なモデリングが不可能であることを考え、本願では適応高レベルリソース分配の導入を決定した。分散型ストレージシステムにおけるタスクのスケジューリングの問題点には共通性があり、頻繁に取り上げられている。入手可能な多くの文献では、同じタイプのタスク間でのリソースの分配に関する問題、または既知のサイズのパケットのスケジューリングに関する問題に対処している。本願における研究は、ユーザーロードとバックグラウンドタスクとの間でリソースを分配する問題に対処している。これらのタスクは特徴が異なるため、他の問題よりもはるかに複雑である。他の既存の解決策は、アイドル期間にバックグラウンドタスクを実行するよう試みている。しかし、サーバが常にユーザの要求を処理し、バックグラウンドタスクがユーザの活動と平行して効果的に実行される場合、そのような方法は適切ではない。タスクのスケジューリングに関する既存の解決策の多くは、待ち行列のメカニズムであるYFQ、SFQおよびFSFQ、またはそれを改変したものを使用している。各ロードソースは、タスクをキューに入れる。そのタスクは適切なキューから取り出され、所望の進捗分配が行われるようシステムに送信される。我々のシステムの場合、このアプローチの問題点は適切なサイズのキューを維持することである。これは、タスクが差別化された特徴を持つ場合は特に困難である。また、待ち行列のメカニズムでは、メモリオーバーヘッドの追加や要求レイテンシの増加が発生し、これはHYDRAstorのようなシステムでは許可できない。また、待ち行列のメカニズムではタスクモデルが必要であり、我々のケースでは、例えば何個の要求を平行して処理できるのか、といったパフォーマンスに関する質問に対する明確な回答を提供することができない。待ち行列理論の適用とレイテンシ制限に基づくフィードバック制御ループを組み合わせる解決策もあるが、標準的な待ち行列は、同時に処理するタスクの数を決定するメカニズムで強化されているため、レイテンシに関する要件は満たされる。しかし、これらの解決策は、類似する特徴を持つタスク間でのリソース分配に関するものである。異なる性質を持つタスクでのリソース分配は、仮想化によって達成されることが多い。各仮想マシンは、適切なクラスのタスクを実行する単一のアプリケーションを採用している。仮想マシンはアプリケーション間でCPUサイクルを正確に分配することができるが、このようなアプローチはアーキテクチャ上および実装上の制約をもたらし、パフォーマンスのオーバーヘッドが著しく大きくなる。[結論と今後の研究]本願では、異なるロードタイプのタスク間でリソースを分配する新しいメカニズムを提示した。この新たなアプローチは、タスクの抽象的概念に基づくものであり、それらの特徴に関する推測を回避している。したがって、システムのアーキテクチャが複雑なためモデル定義の標準的な方法では失敗する、分散型システムに適する。このメカニズムは、商用システムであるHYDRAstorに実装され、制御されたシステムが高性能を達成することに焦点が当てられている。理論上の検討においても、また実験の評価においても、このアルゴリズムはシステムの飽和状態を維持すること、つまりリソースを最大限に利用することが確認されている。実験によれば、制御されたシステムは安定性がありスループットにもオーバーシュートにも深刻な変動がない、進捗の分配はポリシが定める所望のものに収束する。また、反応時間も条件を満たしている。実験では、新たな進捗分配およびワークロードの変更に適応するまでの時間が合理的であることがわかった。結論として、適応高レベルリソース管理は高性能な同時計算サーバに適している。今後は、システムの安定性を維持しつつメカニズムの反応時間をさらに減少させるために、コントローラの設計における制御理論の利用に関する研究を行う予定である。<実施形態2>本発明の第2の実施形態を、図11ないし図17を参照して説明する。図11は、システム全体の構成を示すブロック図である。図12は、ストレージシステムの概略を示すブロック図であり、図13は、構成を示す機能ブロック図である。図14ないし図17は、ストレージシステムの動作を説明するための説明図である。ここで、本実施形態では、ストレージシステムが上述したHYDRAstorといったシステムであり、複数台のサーバコンピュータが接続されて構成されている場合を説明する。但し、本発明におけるストレージシステムは、複数台のコンピュータにて構成されることに限定されず、1台のコンピュータで構成されていてもよい。図11に示すように、本発明におけるストレージシステム10は、ネットワークNを介してバックアップ処理を制御するバックアップシステム11に接続している。そして、バックアップシステム11は、ネットワークNを介して接続されたバックアップ対象装置12に格納されているバックアップ対象データ記憶対象データを取得し、ストレージシステム10に対して記憶するよう要求する。これにより、ストレージシステム10は、記憶要求されたバックアップ対象データをバックアップ用に記憶する。そして、図12に示すように、本実施形態におけるストレージシステム10は、複数のサーバコンピュータが接続されて構成を採っている。具体的には、ストレージシステム10は、ストレージシステム10自体における記憶再生動作を制御するサーバコンピュータであるアクセラレータノード10Aと、データを格納する記憶装置を備えたサーバコンピュータであるストレージノード10Bと、を備えている。なお、アクセラレータノード10Aの数とストレージノード10Bの数は、図12に示したものに限定されず、さらに多くの各ノード10A,10Bが接続されて構成されていてもよい。さらに、本実施形態におけるストレージシステム10は、データを分割及び冗長化し、分散して複数の記憶装置に記憶すると共に、記憶するデータの内容に応じて設定される固有のコンテンツアドレスによって、当該データを格納した格納位置を特定するコンテンツアドレスストレージシステムである。このコンテンツアドレスストレージシステムについては、後に詳述する。なお、以下では、ストレージシステム10が1つのシステムであるとして、当該ストレージシステム10が備えている構成及び機能を説明する。つまり、以下に説明するストレージシステム10が有する構成及び機能は、アクセラレータノード10Aあるいはストレージノード10Bのいずれに備えられていてもよい。なお、ストレージシステム10は、図12に示すように、必ずしもアクセラレータノード10Aとストレージノード10Bとを備えていることに限定されず、いかなる構成であってもよく、例えば、1台のコンピュータにて構成されていてもよい。さらには、ストレージシステム10は、コンテンツアドレスストレージシステムであることにも限定されない。図13に、ストレージシステム10の構成を示す。この図に示すように、ストレージシステム10は、ストレージシステム10の動作を制御する制御装置20と、データを記憶する記憶装置31と、を備えている。そして、制御装置20は、上記実施形態1におけるロードソースに対応しそれぞれ所定のタスクを実行する複数の処理部21,22,23を備えている。例えば、制御装置20は、各処理部21,22,23として、記憶装置30に対するデータの記憶及び読み出し動作を制御するデータ記憶再生処理部21と、使用されなくなり削除するブロックデータを検出するデータ削除処理部22と、データツリーの再構築やデフラグ領域再利用処理などのバックグラウンドタスクを実行するバックグラウンドタスク処理部23と、を備えている。また、制御装置20は、ストレージシステム10内で上述した各処理部21,22,23に対する様々なリソースディスク、CPU、メモリ、ネットワーク等の割り当てを分散させる構成として、進捗状況検出部24と、目標値設定部25と、処理動作制御部26と、を備えている。なお、実際には、上記制御装置20内の各部21~26は、図12に示したアクセラレータノード10A及びストレージノード10Bが備えているCPUCentralProcessingUnitなどの複数の演算装置にプログラムが組み込まれることで構成され、特に、各部24~26は、ストレージノード10Bに構成されている。また、記憶装置31は、主にストレージノード10Bが備えている記憶装置にて構成されている。なお、上記プログラムは、例えば、CD-ROMなどの記憶媒体に格納された状態でストレージシステム10に提供される。あるいは、上記プログラムは、ネットワーク上の他のサーバコンピュータの記憶装置に記憶され、当該他のサーバコンピュータからネットワークを介してストレージシステム10に提供されてもよい。以下、制御装置20が備える各部21~26の構成について詳述する。はじめに、データ記録再生処理部21によるコンテンツアドレス方式のブロックデータ単位におけるストリームデータの記憶及び読み出し方法を、図14ないし図16を参照して説明する。まず、データ記録再生処理部21は、図15の矢印Y1に示すように、ストリームデータであるバックアップ対象データAの入力を受けると、図14及び図15の矢印Y2に示すように、当該バックアップ対象データAを、所定容量例えば、64KBのブロックデータDに分割する。そして、このブロックデータDのデータ内容に基づいて、当該データ内容を代表する固有のハッシュ値H内容識別情報を算出する矢印Y3。例えば、ハッシュ値Hは、予め設定されたハッシュ関数を用いて、ブロックデータDのデータ内容から算出する。なお、このデータ記録再生処理部21による処理は、アクセラレータノード10Aにて実行される。そして、上記データ記録再生処理部21は、バックアップ対象データAのブロックデータDのハッシュ値Hを用いて、当該ブロックデータDが既に記憶装置30に格納されているか否かを調べる。具体的には、まず、既に格納されているブロックデータDは、そのハッシュ値Hと格納位置を表すコンテンツアドレスCAが、関連付けてMFIMainFragmentIndexファイルに登録されている。従って、データ記録再生処理部21は、格納前に算出したブロックデータDのハッシュ値HがMFIファイル内に存在している場合には、既に同一内容のブロックデータDが格納されていると判断できる図15の矢印Y4。この場合には、格納前のブロックデータDのハッシュ値Hと一致したMFI内のハッシュ値Hに関連付けられているコンテンツアドレスCAを、当該MFIファイルから取得する。そして、このコンテンツアドレスCAアドレスデータを、記憶要求にかかるブロックデータDのコンテンツアドレスCAとして記憶する。あるいは、既に格納されているブロックデータDを参照するコンテンツアドレスCAをさらに参照する他のアドレスデータをツリー構造にて記憶する。これにより、このコンテンツアドレスCAにて参照される既に格納されているデータが、記憶要求されたブロックデータDとして使用されることとなり、当該記憶要求にかかるブロックデータDは記憶する必要がなくなる。また、データ記録再生処理部21は、は、上述したように重複チェック部23にてまだ記憶されていないと判断されたブロックデータDを圧縮して、図15の矢印Y5に示すように、複数の所定の容量のフラグメントデータに分割する。例えば、図14の符号D1~D9に示すように、9つのフラグメントデータ分割データ41に分割する。さらに、データ記録再生処理部21は、分割したフラグメントデータのうちいくつかが欠けた場合であっても、元となるブロックデータを復元可能なよう冗長データを生成し、上記分割したフラグメントデータ41に追加する。例えば、図14の符号D10~D12に示すように、3つのフラグメントデータ冗長データ42を追加する。これにより、9つの分割データ41と、3つの冗長データとにより構成される12個のフラグメントデータからなるデータセット40を生成する。なお、上記データ記録再生処理部21による処理は、WIと呼ばれる1つのストレージノード10Bによって実行される。そして、データ記録再生処理部21は、上記フラグメント生成部24にて生成されたデータセットを構成する各フラグメントデータを、記憶装置31に形成された各記憶領域に、それぞれ分散して格納する。例えば、図14に示すように、12個のフラグメントデータD1~D12を生成した場合には、12個の記憶装置31内にそれぞれ形成したデータ格納ファイルF1~F12データ格納領域に、各フラグメントデータD1~D12を1つずつそれぞれ格納する図15の矢印Y6参照。また、データ記録再生処理部21は、上述したように記憶装置31に格納したフラグメントデータD1~D12の格納位置、つまり、当該フラグメントデータD1~D12にて復元されるブロックデータDの格納位置を表す、コンテンツアドレスCAを生成して管理する。具体的には、格納したブロックデータDの内容に基づいて算出したハッシュ値Hの一部ショートハッシュ例えば、ハッシュ値Hの先頭8Bバイトと、論理格納位置を表す情報と、を組み合わせて、コンテンツアドレスCAを生成する。そして、このコンテンツアドレスCAを、ストレージシステム10内のファイルシステム、つまり、アクセラレータノード10Aに返却する図15の矢印Y7。すると、アクセラレータノード10Aは、バックアップ対象データのファイル名などの識別情報と、コンテンツアドレスCAとを関連付けてファイルシステムで管理する。また、データ記録再生処理部21は、ブロックデータDのコンテンツアドレスCAと、当該ブロックデータDのハッシュ値Hと、を関連付けて、各ストレージノード10BがMFIファイルにて管理する。このように、上記コンテンツアドレスCAは、ファイルを特定する情報やハッシュ値Hなどと関連付けられて、アクセラレータノード10Aやストレージノード10Bの記憶装置30に格納される。さらに、データ記録再生処理部21は、上述したように格納したバックアップ対象データを読み出す制御を行う。例えば、ストレージシステム10に対して、特定のファイルを指定して読み出し要求があると図16の矢印Y11参照、まず、ファイルシステムに基づいて、読み出し要求にかかるファイルに対応するハッシュ値の一部であるショートハッシュと論理位置の情報からなるコンテンツアドレスCAを指定する図16の矢印Y12参照。そして、データ記録再生処理部21は、コンテンツアドレスCAがMFIファイルに登録されているか否かを調べる図16の矢印13参照。登録されていなければ、要求されたデータは格納されていないため、エラーを返却する。一方、読み出し要求にかかるコンテンツアドレスCAが登録されている場合には、上記コンテンツアドレスCAにて指定される格納位置を特定し、この特定された格納位置に格納されている各フラグメントデータを、読み出し要求されたデータとして読み出す図16の矢印Y14参照。このとき、各フラグメントが格納されているデータ格納ファイルF1~F12と、当該データ格納ファイルのうち1つのフラグメントデータの格納位置が分かれば、同一の格納位置から他のフラグメントデータの格納位置を特定することができる。そして、データ記録再生処理部21は、読み出し要求に応じて読み出した各フラグメントデータからブロックデータDを復元する図16の矢印Y15参照。さらに、データ記録再生処理部21は、復元したブロックデータDを複数連結し、ファイルAなどの一群のデータに復元して、読み出し制御を行っているアクセラレータノード10Aに返却する図16の矢印Y16参照。また、上記データ削除処理部22は、ガーベジ識別処理といった、使用されなくなったブロックデータを識別する処理を行う。例えば、記憶装置31に記憶されているブロックデータメタデータを含むが他の上位階層のメタデータから参照されている数である被参照数をカウントし、被参照数が0である全く参照されていないブロックデータを検出する。また、上記バックグラウンドタスク処理部23は、上述したように被参照数が0となったブロックデータを解放して記憶領域を再利用する処理や、デフラグなどのバックグラウンドタスクを実行する。次に、上記進捗状況検出部24、目標値設定部25、処理動作制御部26の構成及び動作について、図17のフローチャートを参照して説明する。上記進捗状況検出部24は、上述したデータ記録再生処理部21、データ削除処理部22、バックグラウンドタスク処理部23といった各処理部による処理の進捗状況を、それぞれ検出するステップS1。各処理部21,22,23の進捗状況とは、例えば、各処理部のスループットであり、ストレージシステム10全体の処理量に対する各処理部21,22,23のそれぞれの処理量の割合である。また、進捗状況検出部24は、上記進捗状況を検出する際に、各処理部21,22,23から、当該各処理部21,22,23に処理待ち状態となっているタスク処理待ちタスクが存在するか否かも検出する。また、進捗状況検出部24は、後述する目標値設定部25にて各処理部21,22,23にそれぞれ設定された処理動作の目標値を取得する。このように、進捗状況検出部24は、各処理部21,22,23から、スループットである進捗状況と、処理待ちタスクの有無と、設定されている目標値と、をそれぞれ取得して、目標値設定部25に渡す。なお、進捗状況検出部24は、上述した各処理部21,22,23以外の他の処理部から上述した進捗状況などの情報を検出してもよく、さらに他の情報を検出してもよい。続いて、上記目標値設定部25は、上記進捗状況検出部24から渡された各情報に基づいて、各処理部21,22,23の処理状態の目標値を設定するステップS2。このとき、目標値の設定は、さらに各処理部21,22,23の進捗状況について予め設定された各理想値に基づいて行われる。このため、目標値設定部25は、各処理部21,22,23の進捗状況の理想値を記憶している。例えば、各処理部21,22,23が理想とするスループットの値ストレージシステム全体の処理量に対する各処理部における処理量の割合を記憶している。ここで、上記目標値は、例えば、各処理部の進捗状況と同様に、当該各処理部のスループットである。つまり、目標値は、ストレージシステム全体の処理量に対する各処理部による処理量の割合を表す値の上限値として設定される。但し、目標値は、各処理部のスループットの上限値であることに限定されず、各処理部が実行可能なタスク数の上限値であってもよい。具体的に、目標値設定部25は、まず、特定の処理部に着目し、当該特定の処理部から取得した進捗状況が当該特定の処理部に対して設定されている理想値に満たない場合であり、当該特定の処理部に処理待ちタスクが存在しない場合を考える。この場合には、特定の処理部に処理待ちタスクが存在しないため、現在の進捗状況が理想値に満たないが、進捗状況をこれ以上引き上げる必要はない。従って、この特定の処理部の現在の進捗状況の値を、当該特定の処理部の処理状態の目標値として設定する。なお、このとき、特定の処理部の目標値は、設定されている値のまま、つまり現状維持としてもよい。そして、上述したように、特定の処理部が理想値に満たない状態で作動している場合には、当該特定の処理部にて利用されるリソースが余ることとなる。すると、この余ったリソースを、特定の処理部とは異なる他の処理部にて利用されるよう分配可能となる。従って、目標値設定部25は、他の処理部の処理状態の目標値を、現在値よりも引き上げて設定する。特に、上記進捗状況検出部24による傑出結果に基づいて、処理待ちタスクが存在する他の処理部の目標値を引き上げて設定する。このとき、上記目標値設定部25は、他の処理部について進捗状況検出部24にて検出した現在の進捗状況が、当該他の処理部に現在設定されている目標値を超えている場合に、当該他の処理部の目標値を引き上げて設定する。さらにこのとき、他の処理部について検出した現在の進捗状況と、当該他の処理部に現在設定されている目標値と、の差の絶対値に、所定の係数例えば、0.2の値をかけた値だけ、目標値を引き上げるよう設定する。また、目標値設定部25は、目標値を引き上げる他の処理部が複数存在する場合には、特定の処理部に対して余ったリソースを、複数の他の処理部にそれぞれ設定された各理想値の割合に対応して分配するよう、当該他の処理部の目標値をそれぞれ設定してもよい。つまり、複数の他の処理部の理想値の割合に対応する値だけ、それぞれ他の処理部の目標値を引き上げてもよい。また、目標値設定部25は、上述したように進捗状況検出部24から取得した情報に基づいて、処理部の目標値を引き下げて設定する場合もある。例えば、特定の処理部に着目し、この特定の処理部から取得した進捗状況が当該特定の処理部に設定されている目標値に満たない場合であり、当該特定の処理部に処理待ちタスクが存在している場合を考える。この場合には、特定の処理部に処理待ちタスクが存在するものの、他の処理部にてリソースが使用されているため、特定の処理部の進捗状況が目標値までも達していないことが考えられる。従って、この特定の処理部の現在の進捗状況を増大させるべく、他の処理部の目標値を引き下げるよう設定する。これにより、他の処理部の進捗状況が低下し、その分のリソースが特定の処理部に割り当てられることが期待される。このとき、他の処理部の目標値は、当該他の処理部について検出した現在の進捗状況と、当該他の処理部に現在設定されている目標値と、の差の絶対値に、所定の係数例えば、0.2の値をかけた値だけ、目標値を引き下げるよう設定してもよい。そして、上記処理動作制御部26は、各処理部21,22,23の処理状態、つまり、進捗状況が、上述したように目標値設定部25にて設定された目標値となるよう、当該各処理部21,22,23の処理状態を制御するステップS3。例えば、ある処理部の進捗状況であるスループットが目標値に満たない場合には、かかるスループットが目標値に近づくようその処理部により多くのリソースを割り当てる。一方、ある処理部の進捗状況であるスループットが目標値を超えている場合には、かかるスループットが目標値に近づくようその処理部に割り当ててられているリソースを減らす。以上のように、各処理部の処理状態、例えば進捗状況であるスループットの目標値を変更して設定することで、進捗状況を徐々に理想値に近付けることができ、ストレージシステム全体のリソースの有効利用を図りつつ、理想の処理状態にすることができる。また、ロード間でスループット比率のバランスを取ることにより、システムの性能向上を図ることができる。<付記>上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージシステム図18参照、プログラムを記憶した記憶媒体、情報処理方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。付記1所定のタスクをそれぞれ実行する各処理部110が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部121と、検出した前記各処理部110の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部110の処理状態の目標値を設定する目標値設定部122と、前記各処理部110の処理状態が設定した前記目標値となるよう当該各処理部110の処理状態を制御する処理動作制御部123と、を備えたストレージシステム100。付記2付記1に記載のストレージシステムであって、前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するが否かを検出し、前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、ストレージシステム。付記3付記2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、検出した前記進捗状況が前記理想値を満たさず前記処理待ちタスクが存在しない前記処理部の前記進捗状況を、その処理部の前記目標値として設定する、ストレージシステム。付記4付記2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、検出した前記進捗状況が前記目標値を超えている前記他の処理部の前記目標値を引き上げるよう設定する、ストレージシステム。付記5付記2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、前記目標値を引き上げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き上げるよう設定する、ストレージシステム。付記6付記2に記載のストレージシステムであって、ストレージシステム全体の処理量に対する前記処理部による処理量の割合を、前記目標値とし、前記目標値設定部は、検出した前記進捗状況が前記目標値に満たない前記処理部に前記処理待ちタスクが存在している場合に、他の前記処理部の前記目標値を引き下げるよう設定する、ストレージシステム。付記7付記6に記載のストレージシステムであって、前記目標値設定部は、前記目標値を引き下げる前記処理部において検出した前記進捗状況と、当該処理部の前記目標値と、の差の絶対値に基づく値だけ、前記目標値を引き下げるよう設定する、ストレージシステム。付記8所定のタスクをそれぞれ実行する各処理部が実装された情報処理装置に、前記各処理部による前記情報処理装置全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出する進捗状況検出部と、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定する目標値設定部と、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する処理動作制御部と、を実現させるためのプログラム。付記9付記8に記載のプログラムであって、前記進捗状況検出部は、前記各処理部に処理待ちタスクが存在するが否かを検出し、前記目標値設定部は、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、プログラム。付記10所定のタスクをそれぞれ実行する各処理部が実装されたストレージシステム全体の処理量に対する、前記各処理部毎の処理量の割合をそれぞれ表す各進捗状況を検出し、検出した前記各処理部の前記進捗状況と、前記各処理部毎に予め設定された前記進捗状況の理想値と、に基づいて、前記各処理部の処理状態の目標値を設定し、前記各処理部の処理状態が設定した前記目標値となるよう当該各処理部の処理状態を制御する、情報処理方法。付記11付記10に記載の情報処理方法であって、前記進捗状況の検出時に、前記各処理部に処理待ちタスクが存在するが否かを検出し、検出した前記進捗状況が前記理想値に満たない前記処理部に前記処理待ちタスクが存在しない場合に、前記処理待ちタスクが存在する他の前記処理部の前記目標値を引き上げるよう設定する、情報処理方法。"