JP2020064676A - リソース配置を最適化するための適時性リソース移行 - Google Patents

Abstract

【課題】リソース配置を最適化するために適時性リソース移行を実装する。【解決手段】リソースは、分散型システムの異なるリソースホスト間に配置される。現在の配置の評価が、分散型システムにおけるリソースの配置を改善する配置基準に従って実行される。評価に基づいて、改善閾値を超えるリソースの予想される移行が、移行する候補リソースとして識別される。候補リソースについての移行は、適時的に実行される。優先度が候補リソースに割り当てられ、それに従って、候補リソースが移行を実行するために選択される。【選択図】図６

Description

ハードウェアリソース、ソフトウェア、及び情報ストレージの仮想化をネットワークに
わたって動的に共有するための近年の技術革新は、コンピューティングの信頼性、スケー
ラビリティ、及びコスト効率性を向上させている。より具体的には、仮想化の出現を通じ
て仮想コンピューティングリソース及びストレージを要求に応じて提供する能力によって
、処理リソース及びストレージの消費者が、知覚されるコンピューティング及びストレー
ジの必要性に迅速に応答して、彼らのコンピューティング及びストレージコストを柔軟に
構築することが可能となっている。仮想化は、ハードウェアの製造及び展開の遅延及びコ
ストによって必要とされる供給サイクル内の固定ハードウェアを、購入または貸借するの
ではなく、必要な時に顧客がプロセッササイクル及びストレージを購入できるようにする
。コンピューティング及びストレージの利用可能性を判断するために、将来の需要の予測
精度に依存するのではなく、ユーザが、必要に応じて比較的即時にコンピューティング及
びストレージリソースの使用権を購入することが可能である。

仮想化されたコンピューティング環境は、コンピューティングリソースの利用可能性及
び耐久性に関して様々な保証を提供し得る。複数のリソースホスト間でコンピューティン
グリソースを分散させることが、異なる利用可能性及び耐久性の特性をもたらし得る。例
えば、仮想コンピューティングリソースは、ブロックベースストレージを提供してもよい
。このようなブロックベースストレージは、一連の標準化されたストレージコールを通じ
て様々なコンピューティング仮想化とやり取りすることが可能なストレージシステムを提
供する。一連の標準化されたストレージコールは、ブロックベースストレージがサポート
するボリューム、及びブロックベースストレージがストレージ利用可能性を提供する仮想
化上で実行するオペレーティングシステムの構造的及び機能的詳細に対し、ブロックベー
スストレージを機能的に依存させない。ブロックベースストレージを提供するために、様
々な異なる配置最適化及び／または制約が性能保証を提供するために実装されてもよい。
リソースホスト間にブロックベースストレージリソースを配置するとき、ストレージを配
置するための最適化及び／または制約を満たす異なる配置オプションの中から選択するこ
とが、困難であると証明し得る。

いくつかの実施形態による、リソース配置を最適化するための適時性リソース移行についての論理ブロック図を示す。 いくつかの実施形態による、リソース配置を最適化するための適時性リソース移行を実装するブロックベースストレージサービスなどの、複数のネットワークベースサービスを含む、プロバイダネットワークを示すブロック図である。 いくつかの実施形態による、リソース配置を最適化するための適時性リソース移行を実装するボリューム配置を示す論理ブロック図である。 いくつかの実施形態による、楽観的なリソース移行のための移行キューを示す論理ブロック図である。 いくつかの実施形態による、ブロックベースストレージサービスにおいて適時的にデータボリュームを移行するためのインタラクションを示す論理ブロック図である。 いくつかの実施形態による、リソース配置を最適化する適時性リソース移行のための様々な方法及び技術を示すハイレベルフローチャートである。 いくつかの実施形態による、適時性リソース移行のための候補としてリソースを識別するための様々な方法及び技術を示すハイレベルフローチャートである。 いくつかの実施形態による、候補リソースを選択及び移行するための様々な方法及び技術を示すハイレベルフローチャートである。 いくつかの実施形態による、候補リソースを移行キューから削除するための様々な方法及び技術を示すハイレベルフローチャートである。 いくつかの実施形態による、コンピューティングシステムの実施例を示すブロック図である。

実施形態は、いくつかの実施形態及び例示的な図面についての例として本明細書で説明
されるが、当業者は、実施形態が、説明する実施形態または図面に限定されないことを認
識するであろう。図面及びその詳細な説明は、開示される特定の形態に実施形態を限定す
ることを意図するものではなく、むしろ、意図することは、添付の特許請求の範囲によっ
て定義される思想及び範囲内に入る全ての修正物、均等物及び代替物を含めることを理解
されたい。本明細書で用いられる見出しは、構造化の目的のみのためであり、説明の範囲
または特許請求の範囲を限定するために用いられることを意味しない。本出願全体を通し
て用いられる、「ｍａｙ（してもよい）」という語は、義務的な意味（即ち、しなければ
ならないという意味）ではなく、許容的な意味（即ち、可能性を有するという意味）で用
いられる。同様に、「ｉｎｃｌｕｄｅ（含む）」、「ｉｎｃｌｕｄｉｎｇ（含んでいる）
」、及び「ｉｎｃｌｕｄｅｓ（含む）」という語は、含んでいるが限定はされないことを
意味する。

本明細書で説明するシステム及び方法は、リソース配置のための適時性リソース移行を
実装してもよい。分散型システムは、異なるシステム、サービス、アプリケーション、及
び／または機能を実行または実装するための様々なリソースをホストしてもよい。いくつ
かのリソースは、異なるリソースホスト間の複数のリソースに位置する、より大きな分散
型リソースの一部であってもよい。他のリソースは、個別またはスタンドアロンであって
もよい。リソースは、様々な種類の物理的な、または仮想化されたコンピューティングリ
ソース、ストレージリソース、もしくはネットワーキングリソースのうちの１つなどの、
多くの異なる種類のリソースのうちの１つであってもよい。例えば、ストレージサービス
は、いくつかの異なるリソースホストにわたってデータの異なる複製をホストしてもよい
。

作成中に異なるリソースホストにリソースを位置させるために配置の決定が行われても
よい。しかしながら、動作を開始するためにリソースが配置される必要があるため、最適
な位置が利用可能になるまでリソースの配置を待機することが難しい場合がある。その代
わりに、リソースホストにおけるリソースの初期配置が、最良の利用可能な配置に従って
行われてもよい。時間につれて、最適以下の配置は（配置が、たとえ初期配置の時にリソ
ースについての最良の位置であるとしても）、結局、未活用のリソースホスト、分散型リ
ソースについての非効率的な、もしくは耐久性の低い構成、及び／またはリソースもしく
は分散型システム全体についての様々な他の種類の無駄もしくは非効率性などの、大きな
コストとなり得る。

いくつかの実施形態では、配置決定が、配置基準に従って行われてもよい。配置基準は
、個別のリソースのため、及び分散型システム全体にわたるリソースの配置のための、最
良または最適な配置位置を判断するために使用されてもよい。例えば、利用可能性、耐久
性、及び／またはリソースの他の性能特性を提供し、または改善するために、配置基準は
、リソースが配置されるべき特定の位置（例えば、ネットワークルータまたはブリックな
どの異なる基盤区域）を判断するために使用されてもよい。そのような位置が利用可能で
ない場合、配置基準は、リソースを配置するのにあまり最適でない位置（例えば、配置さ
れるリソースが通信する別のリソースとは異なるネットワークルータまたはブリックなど
の、あまり効率的でない基盤区域にあるリソースホスト）を示してもよい。分散型リソー
ス、利用可能なバイト、ＩＯＰｓ、またはスロット、ＩＯＰｓバランスに対するバイトな
どのリソース利用バランスの一部が、容量フラグメンテーション、ハードウェア／ソフト
ウェア特性、及び／または様々な所望の位置ベースの構成に影響を与える場合、配置基準
は、他のリソースを伴うリソースの構成を含んでもよいが、限定はされない。

図１は、いくつかの実施形態による、リソース配置を最適化するための適時性リソース
移行についての論理ブロック図を示す。分散型システムにおけるリソースが、個別のリソ
ース、及び／または分散型システムにおけるリソースの配置全体のいずれかについてより
良い配置である他のリソースホストに移行されてもよいように、適時性リソース配置１２
０は、適時性リソース移行（複数可）１４０を実行するために、現在配置されているリソ
ース１００を評価してもよい。１つまたは複数のコンピューティングシステム、ノード、
もしくはデバイス（例えば、下記の図１０におけるシステム１０００）であり得るリソー
スホストが、分散型システムのリソースをホストし、または実装するように構成されても
よい。

適時性リソース配置１２０は、リソースの構成（例えば、分散型リソース、サイズ、性
能特性などの個別または一部）に関する情報、リソースホスト（ホストされたリソースの
数、リソース利用率（例えば、処理、ネットワーク、ストレージ、帯域幅など）、ハード
ウェア／ソフトウェア構成、またはホストするためのリソースホストの状態及びそのケイ
パビリティを判断するための任意の他のデータ）に関する情報などの、現在配置されてい
るリソースに関する情報を取得してもよい。コスト利益移行分析１３０は、適時性移行の
ための候補リソースとしてリソースを識別するために実行されてもよい。コスト利益移行
分析１３０は、予想される移行が、移行されるリソースの配置を改善することとなる移行
のための候補リソース、移行されない他のリソース、及び／または分散型システムにおけ
るリソースのより全体的な配置を識別するように実行されてもよい。例えば、配置データ
１１０は、リソース１１２ａ、１１２ｂ、１１２ｃ、１１２ｄ、及び１１２ｅの最適性を
示す。グラフは、最適な配置１１８と比較されるリソースの現在の配置１１６のスコア、
パーセンテージ、または他の標識を表す。少なくともいくつかの実施形態では、配置スコ
ア、または他のメトリックが、各リソース１１２に対して生成されてもよい。同様の評価
が、リソースをホストするのに利用可能であり得るリソースホストに関して行われてもよ
い。利用可能なリソースホストにおけるリソースの可能な配置の効果が、仮定ではリソー
スを含む利用可能なリソースホストについての配置スコアを生成することによって判断さ
れてもよい。このリソースの配置スコアについての移行の効果１１４は、各リソース１１
２についてのグラフに対する追加（例えば、改善）として示される。

リソースを移動するための移行動作は、いくらかのコストを有してもよい。したがって
、より良好に配置された位置にリソースを移動するための移行動作を実行するコストは、
移行によってもたらされる利益に不利に働くことがある。例えば、移行動作の利益が、移
行を実行するためのコストを上回っているリソースを識別することができる改善最適化閾
値が、実装されてもよい。リソース１１２ｂは、他のリソース１１２に関して現在の配置
が最も悪いが、配置を改善する移行の効果が、リソース１１２ａ、１１２ｃ、及び１１２
ｅなどの他のリソースとは同程度にならないことがある。リソース１１２ｂ（及び１１２
ｄ）についての改善量は、改善閾値を超えないことがある場合がある。

分散型システムにおけるリソースの全体的な配置を反映する尺度またはスコア（図示せ
ず）に関して、同様の分析が行われてもよい。例えば、配置全体についての移行スコアに
対する、リソース１１２などのリソースを移行する効果は、全体的な配置に対する利益が
、移行動作を実行するためのコストに値するかどうかを判断するために、最適化閾値と比
較されてもよい。同様に、他の個別の、またはグループのリソースに対する移行の影響に
関して同じ分析が行われてもよく、１つのリソースの予想される移行が、移行を実行する
ための改善閾値を超えて、別のリソースの配置を改善するかどうかを検査する。

適時性リソース移行（複数可）１４０は、コスト利益移行分析１３０の一部として識別
されている候補リソースに対して実行されてもよい。適時性リソース移行（複数可）１４
０は、リソース自体の動作を妨害しないような方法でスケジュールされ、または指示され
てもよい（例えば、適時性リソース移行（複数可）１４０が、バックグラウンドプロセス
またはサービスの一部として実行されてもよい）。少なくともいくつかの実施形態では、
より大きな、またはより有益な効果を有する移行が、より早く（例えば、リソース１１２
ｅについての移行の前に、リソース１１２ｃについての移行）実行されるように、優先度
が、移行に割り当てられてもよい。

時間につれて、適時性リソース移行を動的に実行することが、分散型システムにおける
リソースの配置を最適な位置に再調整して、より大きな効率性、耐久性、利用可能性、ま
たは配置基準がリソース及び分散型システムに対して達成するように設計される任意の他
の性能目標を達成し得る。例えば、分散型リソース（例えば、マスタ及びスレーブペア、
またはピアノードのグループ）が、適時的なリソース移行の結果として最終的に達成され
得る、初期配置において達成されない、分散型リソースの他のメンバに関する最適な構成
を有してもよい。さらに、そのような最適な配置に対する障壁が、（移行がいくつかのリ
ソースまたは分散型システム全体にとってより良い場合に、他のリソースにとってあまり
最適でない位置に対してであっても）他のリソースを移行することによって除去されても
よい。例えば、追加のリソースをホストすることができないリソースホストが、現在最適
以下である他のリソースについて最適な配置を提供し得る位置として識別されてもよい。
（ホストから移動されるリソースが、同じレベルの最適性、またはあまり最適でない位置
に配置され得るとしても）他のリソースをホストすることによって、リソースは、候補リ
ソースとして識別され、最適以下の配置を矯正するために、リソースホストを利用可能に
するように移行されてもよい。個別のリソースにとって望ましい構成もまた、得られても
よい。いくつかの実施形態では、基盤区域に関する配置が、非常に望ましい場合があり、
適時性リソース移行を実装することによって、異なるリソースホストへの移行が、最適な
基盤区域にリソースを位置させることを可能にし得る。

上記の説明は限定することを意図するものではなく、単に、リソース配置のための適時
性リソース移行の一実施例として提供されることに留意されたい。様々なコンポーネント
が、リソース配置を実行してもよい。異なる数または種類のリソース及び配置データが、
採用されてもよい。

本明細書は、プロバイダネットワークの概略的な説明で始まる。プロバイダネットワー
クは、ブロックベースストレージサービスを介して供給されるデータボリュームのための
適時性移行などの、プロバイダネットワーク内の１つまたは複数のネットワークベースサ
ービスを介して供給されるリソース配置のための適時性リソース移行を実装してもよい。
次いで、ブロックベースストレージサービスにおけるデータボリュームについてのボリュ
ーム配置の一部として採用され得る、異なるコンポーネント／モジュール、またはコンポ
ーネント／モジュールの配列を含む、ブロックベースストレージサービスの様々な実施例
が、説明される。次いで、リソース配置のための適時性リソース移行を実装する、いくつ
かの異なる方法及び技術が、説明され、そのうちのいくつかが、添付のフローチャートに
示される。最後に、様々なコンポーネント、モジュール、システム、デバイス、及び／ま
たはノードが実装され得るコンピューティングシステムの実施例の説明が提供される。明
細書全体を通して、様々な実施例が提供される。

図２は、いくつかの実施形態による、リソース配置のための適時性リソース移行を実装
する、ブロックベースストレージサービスを含む複数のネットワークベースサービスを実
装するプロバイダネットワークを示すブロック図である。プロバイダネットワーク２００
は、インターネット及び／または他のネットワークを介してクライアント２１０にアクセ
ス可能な１つまたは複数のサービス（様々な種類のクラウドベースコンピューティングま
たはストレージなど）を提供するように、会社または公共部門組織などの実体によってセ
ットアップされてもよい。プロバイダネットワーク２００は、物理的な、及び／または仮
想化されたコンピュータサーバ、ストレージデバイス、ネットワーキング機器（例えば、
図１０に関して後述するコンピューティングシステム１０００）などの、プロバイダネッ
トワーク２００によって供給されるインフラ及びサービスを実装し、分散させる必要があ
る、様々なリソースプールをホストする多数のデータセンタを含んでもよい。いくつかの
実施形態では、プロバイダネットワーク２００は、仮想コンピュートサービス２３０、ブ
ロックベースストレージサービス２２０及び（オブジェクト／キーバリューベースのデー
タストア、または様々な種類のデータベースシステムなどの、様々なストレージタイプを
含み得る）他のストレージサービス２４０などのストレージサービス、ならびに／または
任意の他の種類のネットワークベースサービス２５０などの、コンピューティングリソー
スを提供してもよい。クライアント２１０は、ネットワーク２６０を介して、プロバイダ
ネットワーク２００によって供給されるこれらの様々なサービスにアクセスしてもよい。
同様に、ネットワークベースサービスそれ自体が、異なるサービスを提供するために、互
いに通信し、及び／または互いを利用してもよい。例えば、仮想または物理コンピュート
インスタンス、またはストレージインスタンスなどの、「インスタンス」と呼ばれる単位
で、クライアント２１０に供給されるコンピューティングリソースは、特定のデータボリ
ューム２２６を利用して、コンピュートインスタンスに対する仮想ブロックストレージを
提供してもよい。

上述のように、仮想コンピュートサービス２３０は、様々なコンピュートインスタンス
をクライアント２１０に供給してもよい。仮想コンピュートインスタンスは、例えば、（
ＣＰＵの種類及び数、メインメモリサイズなどを示すことによって指定され得る）指定さ
れた計算容量、ならびに（例えば、特定のバージョンのオペレーティングシステムであっ
て、ハイパーバイザのトップで動作し得る）指定されたソフトウェアスタックを有する１
つまたは複数のサーバを含んでもよい。いくつかの異なる種類のコンピューティングデバ
イスは、単独で、または組み合わせて使用され、専用コンピュータサーバ、ストレージデ
バイス、ネットワークデバイスなどを含む、異なる実施形態において仮想コンピュートサ
ービス２３０のコンピュートインスタンスを実装してもよい。いくつかの実施形態では、
インスタンスクライアント２１０またはその他の任意の他のユーザが、コンピュートイン
スタンスに対してネットワークトラフィックを指示するように構成され（及び／または認
可され）てもよい。様々な実施形態では、コンピュートインスタンスは、様々な動作を実
行するための永続ブロックベースストレージを取得するために、ブロックベースストレー
ジサービス２２０によって提供される１つまたは複数のデータボリューム２２６にアタッ
チ、またはマッピングしてもよい。

コンピュートインスタンスは、例えば、インスタンスにアクセスするためのクライアン
ト２１０を必要とすることなくクライアントアプリケーションを実行するのに適した、ア
プリケーションサーバインスタンス、Ｊａｖａ（商標）仮想マシン（ＪＶＭ）、専用オペ
レーティングシステム、Ｒｕｂｙ、Ｐｅｒｌ、Ｐｙｔｈｏｎ、Ｃ、Ｃ＋＋などの様々なイ
ンタプリタ型もしくはコンパイル型プログラミング言語をサポートするプラットフォーム
、または高性能コンピューティングプラットフォームなどの、多様な異なるプラットフォ
ームを動作させ、または実装してもよい。いくつかの実施形態では、コンピュートインス
タンスは、所期の稼働率に基づいて、異なる種類または構成を有する。特定のコンピュー
トインスタンスの稼働率は、インスタンスが予約されている総時間量に対する、インスタ
ンスがアクティブ化されている時間量の比率として定義されてもよい。いくつかの実施態
様では、稼働率は、利用率とも呼ばれ得る。クライアントが、インスタンスが予約される
時間の比較的短い部分（例えば、年間予約の３０％〜３５％）の間コンピュートインスタ
ンスを使用することを予期する場合、クライアントは、低稼働率インスタンスとしてイン
スタンスを予約し、関連する価格決定方針に従って、値引きされた時間使用料を支払うよ
うに決定してもよい。クライアントが、時間のほとんどのインスタンスを必要とする、定
常状態の作業負荷を有することを予期する場合、クライアントは、高稼働率インスタンス
を予約し、より低い時間使用料であっても潜在的に支払い得るが、いくつかの実施形態で
は、実際の使用時間数にかかわらず、価格決定方針に従って、予約の全期間について時間
料金が請求されてもよい。中稼働率についての選択肢が、対応する価格決定方針を用いて
同様にいくつかの実施形態でサポートされてもよく、その場合、前払いのコスト及び時間
ごとのコストは、対応する高稼働率及び低稼働率のコストの間にある。

コンピュートインスタンス構成は、また、計算集中型のアプリケーション（例えば、高
トラフィックウェブアプリケーション、広告提供、バッチ処理、ビデオ符号化、分散解析
学、高エネルギー物理学、ゲノム分析、及び計算流体力学）についての計算作業負荷、グ
ラフィック集中型の作業負荷（例えば、ゲームストリーミング、３Ｄアプリケーションス
トリーミング、サーバサイドグラフィックス作業負荷、レンダリング、ファイナンシャル
モデリング、及びエンジニアリング設計）、メモリ集中型の作業負荷（例えば、高性能デ
ータベース、分散型メモリキャッシュ、インメモリ解析、ゲノムアセンブリ及び分析）、
ならびに、ストレージ最適化作業負荷（例えば、データウェアハウジング及びクラスタフ
ァイルシステム）などの、汎用的な、または特定の目的を有するコンピュートインスタン
スを含んでもよい。特定の数の仮想ＣＰＵコア、メモリ、キャッシュ、ストレージ、及び
任意の他の性能特性などの、コンピュートインスタンスのサイズ。コンピュートインスタ
ンスの構成は、また、それらの位置、特定のデータセンタ内、利用可能区域、地理的位置
など、及び（予約されたコンピュートインスタンスの場合）予約期間の長さを含んでもよ
い。

様々な実施形態では、プロバイダネットワーク２００は、また、記憶動作を実行するた
めのブロックベースストレージサービス２２０を実装してもよい。ブロックベースストレ
ージサービス２２０は、複数の独立したリソースホスト２２４ａ、２２４ｂ、２２４ｃ〜
２２４ｎのプール（例えば、サーバブロックデータストレージシステム）からなるストレ
ージシステムであり、リソースホストは、１つまたは複数のデータボリュームデータボリ
ューム（複数可）のセット２２６ａ、２２６ｂ、２２６ｃ〜２２６ｎを記憶するためのブ
ロックレベルストレージを提供する。データボリューム２２６は、特定のクライアント（
例えば、仮想コンピュートサービス２３０の仮想コンピュートインスタンス）にマッピン
グされて、仮想ブロックベースストレージ（例えば、ハードディスクストレージまたは他
の永続ストレージ）を論理ブロックの連続したセットとして提供してもよい。いくつかの
実施形態では、データボリューム２２６は、スナップショット動作または複製動作などの
他のブロックストレージ動作を実行するための（１つまたは複数のデータブロックを含む
）複数のデータチャンクまたはパーティションに分割されてもよい。データボリューム２
２６のボリュームスナップショットは、データボリューム２２６の状態の固定時点の表現
であってもよい。いくつかの実施形態では、ボリュームスナップショットは、別のストレ
ージサービス２４０内など、データボリュームを保持するリソースホスト２２４から離れ
て記憶されてもよい。スナップショット動作は、他のストレージサービス２４０内のリモ
ートスナップショットデータストアなどの、別のストレージ位置に所与のデータボリュー
ムのスナップショットを送信し、コピーし、及び／または保存するために実行されてもよ
い。

ブロックベースストレージサービス２２０は、ブロックベースストレージサービス２２
０の動作を支援するブロックベースストレージサービス制御プレーン２２２を実装しても
よい。様々な実施形態では、ブロックベースストレージサービス制御プレーン２２２は、
仮想コンピュートサービス２３０及び／もしくはプロバイダネットワーク２００内に位置
する他のネットワークベースサービスによって提供されるコンピュータインスタンス上で
実行するプログラム、ならびに／または任意で、１つまたは複数の他のデータセンタ内に
位置するコンピューティングシステム（図示せず）、もしくはネットワーク２６０を介し
て利用可能なプロバイダネットワーク２００の外部にある他のコンピューティングシステ
ムなどの、クライアントに対するブロックデータストレージの利用可能性を管理すること
を支援する。データボリューム２２６へのアクセスは、ブロックデータトランザクション
命令に応答して、プロバイダネットワーク２００内の内部ネットワーク上で、またはネッ
トワーク２６０を介して外部から提供されてもよい。

ブロックベースストレージサービス制御プレーン２２２は、ユーザアカウントの管理（
例えば、作成、削除、課金、支払いの徴収など）を含む、ブロックレベルストレージの機
能性を提供することに関係する多様なサービスを提供してもよい。ブロックベースストレ
ージサービス制御プレーン２２２は、設定要求に応答して、データボリューム２２６の作
成、使用及び削除に関係するサービスをさらに提供してもよい。少なくともいくつかの実
施形態では、ブロックベースストレージサービス制御プレーン２２２は、図３に関連して
さらに詳細に後述するように、ボリューム配置２２８を実装してもよい。ブロックベース
ストレージサービス制御プレーン２２２は、また、他のストレージサービス２４０上のボ
リュームスナップショットの作成、使用及び削除に関係するサービスを提供してもよい。
ブロックベースストレージサービス制御プレーン２２２は、また、データボリューム２２
６及びそれらのボリュームのスナップショットの使用に関係する性能及び検査データの収
集及び処理に関係するサービスを提供してもよい。

プロバイダネットワーク２００は、また、上述のように、別のストレージサービス２４
０を実装してもよい。他のストレージサービス２４０は、ブロックベースストレージサー
ビス２２０によって提供されるのと同一の、または異なる種類のストレージを提供しても
よい。例えば、いくつかの実施形態では、他のストレージサービス２４０は、データをデ
ータオブジェクトとして記憶し管理し得る、オブジェクトベースストレージサービスを提
供してもよい。例えば、様々なデータボリューム２２６のボリュームスナップショットは
、特定のデータボリューム２２６についてのスナップショットオブジェクトとして記憶さ
れてもよい。他のストレージサービス２４０に加えて、プロバイダネットワーク２００は
、クライアント２１０及びプロバイダネットワーク２００の他のサービス（例えば、ブロ
ックベースストレージサービス２２０、仮想コンピュートサービス２３０、及び／または
他のストレージサービス２４０）が、様々なタスクを実行または要求できるようにする、
様々な異なる種類の分析、計算、ストレージ、または他のネットワークベースシステムを
含み得る、他のネットワークベースサービス２５０を実装してもよい。

クライアント２１０は、要求をネットワークプロバイダ２００に提出するように構成可
能な任意の種類のクライアントを包含してもよい。例えば、所与のクライアント２１０は
、適当なバージョンのウェブブラウザを含んでもよく、または、ウェブブラウザによって
提供される実行環境の拡張として、もしくは実行環境の範囲内で実行するように構成され
た、プラグインモジュールもしくは他の種類のコードモジュールを含んでもよい。代替的
に、クライアント２１０は、データベースアプリケーション（もしくは、そのユーザイン
タフェース）、メディアアプリケーション、オフィスアプリケーション、または、様々な
動作を実行するためにコンピュートインスタンス、データボリューム２２６、もしくはプ
ロバイダネットワーク２００内の他のネットワークベースサービスを利用し得る任意の他
のアプリケーションなどのアプリケーションを包含してもよい。いくつかの実施形態では
、そのようなアプリケーションは、全ての種類のネットワークベースのデータについての
完全なブラウザサポートを必ずしも実装することなくネットワークベースサービス要求を
生成及び処理するのに十分な（例えば、適当なバージョンのハイパーテキスト転送プロト
コル（ＨＴＴＰ）のための）プロトコルサポートを含んでもよい。いくつかの実施形態で
は、クライアント２１０は、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ
Ｔｒａｎｓｆｅｒ）型のネットワークベースサービスアーキテクチャ、ドキュメントベ
ースもしくはメッセージベースのネットワークベースサービスアーキテクチャ、または別
の適当なネットワークベースサービスアーキテクチャに従って、ネットワークベースサー
ビス要求を生成するように構成されてもよい。いくつかの実施形態では、クライアント２
１０（例えば、計算クライアント）は、コンピュートインスタンスによって提供される計
算リソースまたはデータボリューム２２６によって提供されるブロックストレージを利用
するクライアント２１０上で実装するアプリケーションにトランスペアレントなやり方で
、コンピュートインスタンスまたはデータボリューム２２６へのアクセスを提供するよう
に構成されてもよい。

クライアント２１０は、外部ネットワーク２６０を介してプロバイダネットワーク２０
０にネットワークベースサービス要求を伝達してもよい。様々な実施形態では、外部ネッ
トワーク２６０は、クライアント２１０及びプロバイダネットワーク２００間でネットワ
ークベース通信を確立するのに必要なネットワーキングハードウェア及びプロトコルの任
意の適当な組み合わせを包含してもよい。例えば、ネットワーク２６０は、概して、集合
的にインターネットを実装する、様々な遠距離通信ネットワーク及びサービスプロバイダ
を包含してもよい。ネットワーク２６０は、また、ローカルエリアネットワーク（ＬＡＮ
）または広域ネットワーク（ＷＡＮ）などの私設ネットワーク、及び公衆または私設無線
ネットワークを含んでもよい。例えば、所与のクライアント２１０及びプロバイダネット
ワーク２００の両方が、それ自体の内部ネットワークを有する企業内でそれぞれ供給され
てもよい。そのような実施形態では、ネットワーク２６０は、所与のクライアント２１０
及びインターネット間、ならびにインターネット及びプロバイダネットワーク２００間で
、ネットワーキングリンクを確立するのに必要なハードウェア（例えば、モデム、ルータ
、スイッチ、負荷分散装置、プロキシサーバなど）及びソフトウェア（例えば、プロトコ
ルスタック、会計ソフトウェア、ファイアウォール／セキュリティソフトウェアなど）を
含んでもよい。いくつかの実施形態では、クライアント２１０は、公衆インターネットで
はなく、私設ネットワークを用いてプロバイダネットワーク２００と通信してもよいこと
に留意されたい。

図３は、いくつかの実施形態による、リソース配置を最適化するための適時性リソース
移行を実装するボリューム配置を示す論理ブロック図である。上述のように、リソースホ
スト３００などの複数のリソースホストが、ブロックベースストレージサービスを提供す
るために実装されてもよい。リソースホストは、ストレージサーバまたは他のコンピュー
ティングシステム（例えば、図１０に関連して後述するコンピューティングシステム１０
００）などの、１つまたは複数のコンピューティングシステムまたはデバイスであっても
よい。各リソースホストは、データボリュームのそれぞれの複製を保持してもよい。いく
つかの実施形態では、いくつかのデータボリュームは、他のデータボリュームとはサイズ
が異なってもよい。リソースホストは、また、マルチテナント型ストレージを提供しても
よい。例えば、いくつかの実施形態では、１つのリソースホストが、ブロックベーススト
レージサービス２２０の１つのアカウントについてのデータボリュームを保持してもよく
、一方、同一リソースホストにおいて保持される別のデータボリュームが、異なるアカウ
ントについて保持されてもよい。リソースホストは、各リソースホストを実装するコンピ
ューティングシステムまたはデバイスに直接取り付けられ得る１つまたは複数のブロック
ベースストレージデバイス（例えば、ハードディスクドライブ、ソリッドステートドライ
ブなど）において、それらのそれぞれのデータボリュームを永続させてもよい。リソース
ホストは、異なる永続ストレージデバイスを実装してもよい。例えば、いくつかのリソー
スホストは、永続ブロックストレージのためのソリッドステートドライブ（ＳＳＤ）を実
装してもよく、一方、他のリソースホストは、ハードディスクドライブ（ＨＤＤ）または
他の磁気ベース永続ストレージデバイスを実装してもよい。このように、異なるボリュー
ムタイプ、仕様、及び他の性能特性は、リソースホストにおいて実装される永続ストレー
ジデバイスに従って提供されてもよい。

ブロックベースストレージサービス２２０は、多様な異なる方法で、データボリューム
を管理及び保持してもよい。異なる耐久性の方式が、データボリュームの異なるパーティ
ションにおいてデータボリュームの同一の複製を保持する分散型リソースとして、２つ以
上のリソースホスト間のいくつかのデータボリュームに対し実装されてもよい。例えば、
データボリュームについての単一障害点を除去することなどによって、データボリューム
の耐久性を向上させるために、異なるタイプのミラーリング及び／または複製技術（例え
ば、ＲＡＩＤ１）が実装されてもよい。データボリュームへのアクセスを提供するために
、リソースホストは、そのときに、データボリュームの複製を保持する２つ以上のリソー
スホスト間で、書き込み要求などのＩ／Ｏ要求を協調させてもよい。例えば、所与のデー
タボリュームについて、１つのリソースホストが、マスタリソースホストとして機能して
もよい。様々な実施形態では、マスタリソースホストが、データボリュームのクライアン
トから要求（例えば、Ｉ／Ｏ要求）を受信し、処理してもよい。したがって、マスタリソ
ースホストは、そのときに、書き込み要求などのＩ／Ｏ要求の複製、またはスレーブリソ
ースホストとして機能する１つもしくは複数の他のリソースホストに対するデータボリュ
ームへの任意の他の変更もしくは修正を協調させてもよい。したがって、書き込み要求が
、マスタリソースホストにおけるデータボリュームについて受信されるとき、マスタリソ
ースホストは、書き込み要求をスレーブリソースホスト（複数可）に転送してもよく、ス
レーブリソースホスト（複数可）が、マスタリソースホストにおいて書き込み要求を完了
する前に完了として書き込み要求を確認応答するまで待機してもよい。マスタリソースホ
ストが、スナップショット動作、または他のＩ／Ｏ動作（例えば、読み取り要求を出すこ
と）のような、データボリュームに対する他の動作を指示してもよい。

いくつかの実施形態では、マスタ及びスレーブリソースホストの役割が、データボリュ
ームごとに割り当てられてもよいことに留意されたい。例えば、１つのリソースホストに
おいて保持されるデータボリュームについて、リソースホストが、マスタリソースホスト
として機能してもよい。別のデータボリュームが、同一のリソースホストにおいて保持さ
れる間、リソースホストが、スレーブリソースホストとしてサービスしてもよい。リソー
スホストは、それぞれのＩ／Ｏマネージャを実装してもよい。Ｉ／Ｏマネージャは、特定
のリソースホストにおいて保持されるデータボリュームに向けられるＩ／Ｏ要求をハンド
リングしてもよい。したがって、Ｉ／Ｏマネージャは、例えば、リソースホストにおける
ボリュームへの書き込み要求を処理し、ハンドリングしてもよい。Ｉ／Ｏマネージャは、
ブロックベースストレージサービスのアプリケーションプログラミングインタフェース（
ＡＰＩ）、及び／または、インターネットスモールコンピュータシステムインタフェース
（ｉＳＣＳＩ）などの他の通信プロトコルに従って、Ｉ／Ｏ要求を処理するように構成さ
れてもよい。

リソースホストは、異なる基盤区域内に位置されてもよい。基盤区域は、サーバラック
、ネットワーキングスイッチ、ルータ、もしくは他のコンポーネントなどのデバイス、電
源（もしくは他のリソースホストサプライヤ）または物理的もしくは地理的位置（例えば
、特定の通り、部屋、建物、データセンタ、フォールトトレラント区域などにおける位置
）によって定義されてもよい。リソースホスト（及び、リソースホスト上に実装されるデ
ータボリュームの複製）が、特定のネットワークルータまたはブリック、特定の部屋の位
置、特定のサイトなどの、複数の異なる種類の基盤区域内にあり得るように、基盤区域が
、範囲内で変化してもよい。

様々な実施形態では、ブロックベースストレージサービス制御プレーン２２２は、ボリ
ューム配置２２８を実装してもよい。ボリューム配置２２８は、１つまたは複数のコンピ
ューティングノード、システム、またはデバイス（例えば、図１０におけるシステム１０
００）において実装されてもよい。少なくともいくつかの実施形態では、ボリューム配置
２２８は、情報、メトリック、メタデータ、またはボリューム配置を実行するための任意
の他の情報を収集するために、配置データ収集３２０を実装してもよい。配置データ収集
３２０は、情報、メトリック、またはメタデータのためのクエリで、リソースホスト（複
数可）３００を周期的にスイープしてもよい。例えば、リソースホストは、現在の利用メ
トリック、進行中のタスクまたは動作（例えば、移行または再ミラータスクなど）、及び
リソースホストに存在するボリュームについてのボリューム固有情報を含む、リソースホ
ストについての任意の他の状態情報を提供してもよい。いくつかの実施形態では、配置デ
ータ収集３２０は、基盤区域、パーティション、リソースホスト、またはブロックベース
ストレージサービス２２０についての他の粒度に従って、データを集計してもよい。配置
データ収集３２０は、収集したデータを永続的に保持し得るボリューム／サービス状態ス
トア３２２において、データを記憶してもよい。いくつかの実施形態では、ボリューム／
サービス状態ストア３２２は、ボリューム配置２２８の他のコンポーネントまたはブロッ
クベースストレージサービス制御プレーン２２６へのアクセスを提供するために、データ
ベースまたは検索可能な／クエリ可能なストレージシステムとして実装されてもよい。

様々な実施形態において、ボリューム配置２２８は、配置エンジン３１０を実装しても
よい。配置エンジン３１０は、新たなデータボリュームの複製、または移行中の現在配置
されているデータボリュームなどの、リソースについての配置位置を識別するために、様
々な種類の分析を実行してもよい。分析は、上述した配置基準について実行されて、個別
のリソースまたはブロックベースストレージサービス全体について最適であり得る配置位
置を判断してもよい。例えば、配置エンジン３１０は、データボリュームのマスタ、スレ
ーブ（複数可）の配置などの、分散型リソース内のリソースの全ての予想される配置構成
を評価する、構成分析３１２を実装してもよい。いくつかの実施形態では、クライアント
または分散型リソース（または分散型リソースのリソース）の他のユーザは、構成分析（
例えば、データボリュームにアタッチされる仮想インスタンスを含む配置構成を評価する
こと）において考慮されてもよい。構成分析３１２は、分散型リソースの他のリソースに
対しより良い構成を提供することとなるリソースホストにおける空間を開放するために、
現在配置されているリソースを他のリソースホストに移行することの影響を考慮してもよ
い。例えば、これは、スレーブボリューム（例えば、リソース）を別のリソースホストに
移動して、そのホストの異なるスレーブボリュームのための場所を開けることを含み得る
。それは、ボリュームのマスタまたはボリュームのクライアントと同じ基盤区域内に別の
スレーブボリュームを作ることになる。いくつかの状況では、この構成（例えば、クライ
アントと同じネットワークルータに接続されているなど、同じ基盤区域内にマスタまたは
スレーブボリュームを有すること）は、改善された性能を提供し、最適な構成であっても
よい。

配置エンジン３１０において配置要求を受信することに応答して、構成分析３１２は、
ボリューム／サービス状態３２２にアクセスすることによって、予想される配置を判断し
てもよい。利用可能であり、いかなる配置制約にも違反しないリソースホストが、評価さ
れてもよい（例えば、データボリュームの２つのパーティションが、同一のリソースホス
ト、十分な容量を有するリソースホスト、または特定のハードウェア及び／もしくはソフ
トウェアを実装するリソースホストによってホストされることができない）。いくつかの
実施形態では、（利用可能なリソースホストの非常に大きなプールを評価することは、計
算上コストが掛かりすぎるため）利用可能なリソースホストのサブセットが、配置決定に
ついて評価されてもよい。予想される配置構成が、リソースについての利用可能なリソー
スホストに基づいて生成され、または識別されてもよい。データボリュームの他の複製が
、実際の、または仮定の配置位置に基づいて評価されてもよい。

１つまたは複数の基盤区域のローカリティが、様々な実施形態では、ボリューム／サー
ビス状態３３２に基づいて、分散型の異なる予想される配置構成について判断されてもよ
い。例えば、メタデータは、データボリュームの異なる複製のリソースホストが、どのネ
ットワークブリックまたはルータに接続されているかを示してもよい。少なくともいくつ
かの実施形態では、予想される配置構成（配置されるべきリソースが、異なる利用可能な
リソースホストに位置される）の基盤区域のローカリティについて、スコアが生成されて
もよい。配置エンジン３１０は、多くの他のメトリック、データ、または基盤区域のロー
カリティ以外の考慮に基づいて、構成分析３１２を実行してもよい。例えば、少なくとも
いくつかの実施形態では、分析は、データボリュームの複製をホストするリソースホスト
の異なる性能メトリックに関して、予想される構成について実行されてもよい。例えば、
ストレージ容量、作業負荷、または１秒当たりの入出力動作（ＩＯＰｓ）が、データボリ
ューム全体について評価されてもよい。異なるパーティションが、データボリュームに対
しデータの異なる部分を保持するように、いくつかのデータボリュームが区画されてもよ
い。例えば、データボリュームは、３セットのマスタ−スレーブ複製のペアに区画されて
もよい。構成分析３１２は、複製されるデータボリュームの各部分（例えば、各マスタ−
スレーブ複製のペア）、またはデータボリュームパーティションの全て（例えば、３つ全
てのマスタ−スレーブ複製のペア）についての配置構成に基づいて実行されてもよい。

配置エンジン３１０は、パーティション配置を決定するために他の分析３１４を実装し
てもよい。例えば、スコアは、特定のリソースホストが、接触された、または接触した最
終時間に基づき、配置について生成されてもよい。分析は、複数のマスタ−スレーブ複製
のペアを識別し、同じ２つのリソースホストに配置されることを防止するように実行され
てもよい。いくつかの実施形態では、パーティションをホストし、未活用の空間を最小量
にしておくことが可能な、リソースホスト上のリソースの配置を最適化するために、リソ
ースホストフラグメンテーション分析が実行されてもよい。上記構成分析と同様に、上記
で与えられる分析例が、移行された場合に移動されなかった他のリソースのより良い配置
を提供し得る、いくつかのリソースについて配置位置を決定するために実行されてもよい
。

いくつかの実施形態では、ボリューム配置２２８は、適時性配置マネージャ３３０を実
装してもよい。リソース（例えば、データボリューム）についての配置が、より最適であ
り、及び／またはリソースホスト（複数可）３１０間のリソースの配置が、（移行の結果
、移行されたリソースについての同一の、もしくはあまり最適でない新たな配置が生じる
場合であっても）全体としてより最適であるように、適時性配置マネージャ３３０は、動
的に、または積極的に、現在配置されているリソース（例えば、ボリュームの複製）を、
１つのリソースホストから別のリソースホストへ移行してもよい。例えば、適時性配置マ
ネージャ３３０は、図６及び図７に関して後述するように、最適以下（例えば、低いスコ
アが付けられている基盤区域のカテゴリ）に配置されるように決定されるリソースについ
ての配置を、配置エンジン３１０から要求するように移行動作スケジューリング３３２を
実装してもよい。移行動作スケジューリング３３２は、次いで、実行される場合にどの配
置が、移行最適化閾値または他の改善閾値（例えば、現在の配置スコアと新たな配置スコ
アとの差）を超えるかを判断してもよい。配置最適化閾値を超えることとなる、可能な配
置を有するリソースについて、移行動作スケジューリング３３２は、移行動作キュー３３
６内のパーティションに対し、移行動作を配置してもよい。いくつかの実施形態では、よ
り有益な移行動作がより早く実行されるように、移行動作スケジューリング３３２は、移
行動作に優先度を割り当ててもよい。

１つのリソースホストから別のリソースホストへリソースを移行するための移行動作の
実行は、非同期式であってもよい。異なる移行動作のスケジューリング及び／または実行
を協調させるために、スケジューリング構造または他のデータセットが保持されてもよい
。いくつかの実施形態では、移行動作キュー３３６などの移行動作のキューが実装されて
もよい。図４は、いくつかの実施形態による、楽観的なリソース移行のための移行キュー
を示す論理ブロック図である。

移行動作キュー４００は、分散型または集中型データストアなどの永続ストレージに保
持されてもよい。少なくともいくつかの実施形態では、データベースシステムまたはトラ
ンザクション制御を提供する他のストレージシステムが、移行動作キューを保持するため
に利用されてもよい。例えば、移行動作キュー４００は、他のストレージサービス２４０
の一部として実装されたＮｏＳＱＬデータストアなど、別のネットワークベースサービス
内にデータベーステーブルとして保持されてもよい。移行動作スケジューリング３３２は
、図６〜９に関連して後述する様々な技術に従って、移行動作キュー４００を周期的に更
新してもよい。例えば、移行動作４０４は、完了するように「進行中」から変更された状
態を有してもよい。ボリューム識別子、行先ホストの位置、状態、最終更新時間、及び／
または優先度値などの、移行動作のための様々なメタデータ及び情報が、保持されてもよ
い。

移行動作スケジューリング３３２は、また、完了または失敗したと識別されるそれらの
移行動作（例えば、移行動作４０４及び４０８）などの移行動作をキュー４００から削除
してもよい。まだ実行されていない移行動作は、キュー内に記憶される更新された優先度
（例えば、優先度値を上昇、または低下）を有してもよい。最終更新時間は、キュー内の
移行動作に対する更新が最後に行われた時を示してもよい。例えば、移行動作５０２は、
他の移行動作５０４、５０６、及び５０８より後の更新時間（１４：３４：０６）を有し
、したがって、より最近の／関連のあるデータを有すると考えられてもよい。図７に関連
して後述するように、優先度値は、移行動作を適時的にスケジュールするために、移行動
作に割り当てられてもよい。少なくともいくつかの実施形態では、移行動作キュー４００
は、優先度キューとして実装されてもよく、したがって、優先度が最も高い移行動作が、
実行のために選択されてもよい。

図３に戻って、移行ワーカ（複数可）３４０が、移行動作を実行するために実装されて
もよい。移行ワーカ（複数可）３４０は、実行する移行動作について、適時性配置マネー
ジャ３３０に要求を送信してもよい。適時性配置マネージャ３３０は、移行動作を移行動
作キュー３３６から取り出し、移行動作を指示するために移行ワーカ３４０に割り当てて
もよい。代替的に、いくつかの実施形態において、移行ワーカは、実行する移行動作を識
別するために移行動作キュー３３６に直接アクセスしてもよい。移行ワーカ（複数可）３
４０は、いくつかの実施形態では、（例えば、状態を「準備中」から「進行中」に変更す
るように）移行動作キュー３３６内の移行動作についてのメタデータを更新してもよい。

いくつかの実施形態では、移行動作抑制３４２は、進行中の移行動作の数を制御するた
めに実装されてもよい。配置データ収集３２０は、ネットワーク利用率、リソースホスト
利用率、または任意の他の動作メトリックなどの他のデータと共に、リソースホスト（複
数可）３１０において進行中の現在の移行動作を追跡し、保持し、または監視し、ボリュ
ーム／サービス状態３２２を更新してもよい。移行ワーカ（複数可）３４０は、いくつか
の移行制限に従って、移行動作が抑制されるべきかどうかを判断するために、ボリューム
／サービス状態３２２にアクセスしてもよい。例えば、いくつかの実施形態では、１つま
たは複数のリソースホスト（複数可）３１０、ネットワーキングデバイス（複数可）、ル
ータ（複数可）、スイッチ、電源（複数可）または仮想ブロックベースストレージサービ
スの他のコンポーネントもしくはデバイスを含み得る、ネットワークローカリティが、識
別されたリソース移行動作を実行する効果に関して評価されてもよい。異なる移行制限（
例えば、移行動作の数、ネットワーク利用率、リソースホスト利用率など）が、ネットワ
ークローカリティに関して実施されてもよい。移行動作が、異なるネットワークローカリ
ティのうちの１つについての制限を超える場合、移行ワーカは、移行動作の実行を抑制し
てもよい（例えば、移行動作が、拒否または遅延されてもよい）。いくつかの実施形態で
は、移行動作抑制が、特定の基盤区域またはネットワークローカリティに（例えば、移行
動作の現在の及び行先リソースホストを含む区域などの、移行の実行に関わることとなる
基盤区域またはネットワークローカリティに）制限されてもよい。いくつかの実施形態で
は、適時性配置管理３３０は、移行ワーカ（複数可）３４０に加えて、または移行ワーカ
（複数可）３４０の代わりに、抑制する移行動作を実行してもよい。

様々な実施形態では、移行ワーカ３４０は、リソースについての新たな配置位置を提供
するために、上記及び下記で説明する様々な技術を実行し得る配置エンジン３１０から、
移行されるべきリソースについての更新された配置を要求してもよい。

図５は、いくつかの実施形態による、リソース（例えば、データボリュームの複製）を
移行するためのインタラクションを示す論理ブロック図である。上述のように、配置デー
タ収集３２０は、ボリュームサービス状態３２２を更新するために、リソースホスト（複
数可）５００からホスト／ボリュームデータをスイープまたは要求５０２してもよい。リ
ソースホスト（複数可）は、ホスト／ボリュームデータを配置データ収集３２０に送信５
０２し、配置データ収集３２０は、ボリューム／サービス状態５０６を集計し、及び／ま
たは更新してもよい。適時性配置管理３３０は、配置エンジン３１０からボリューム配置
（複数可）を要求５０８してもよい。配置エンジン３１０は、図３に関連して上述した技
術に従うなどして、配置位置を決定してもよい。ボリューム配置（複数可）は、適時性配
置管理３３０に提供５１２されてもよい。移行最適化閾値を超えるボリューム（または、
リソース）について、移行動作キューは、新たな移行動作を追加するように更新５１４さ
れてもよい。陳腐化した、または完了した移行動作は、移行キュー３３６から削除されて
もよい。

移行ワーカ（複数可）３４０は、適時性配置マネージャ３３０から移行動作を取得５１
６してもよい。適時性配置マネージャ３３０は、候補移行動作（複数可）を取得５１８す
るために移行動作キュー３３６を評価してもよい。移行動作キュー３３６からの移行動作
（複数可）５２０は、移行ワーカ（複数可）３４０に返され５２２てもよい。次いで、移
行ワーカ（複数可）３４０は、影響を受けるリソースホスト（複数可）５００に対し移行
動作を指示５２４してもよい。いくつかの実施形態では、移行ワーカ（複数可）３４０は
、中継として動作してもよく、リソースを行先リソースホストに送信する前に、元のリソ
ースホストからリソースを取得してもよい。図５で提供される様々なインタラクション及
び例示は、様々な標準の、またはカスタマイズされた通信技術を用いて通信されてもよい
。例えば、配置エンジン３１０、適時性配置管理３３０、移行動作キュー３３６、ボリュ
ームサービス状態３２２、リソースホスト（複数可）５００などのための様々な内部ＡＰ
Ｉは、それぞれのインタフェース（例えば、ＡＰＩなどのプログラムによるインタフェー
ス）をそれぞれ有してもよく、図５におけるそれぞれの通信は、それに応じてフォーマッ
トされてもよい。

図２〜５に関連して上述したリソース配置のための適時性リソース移行の実施例は、ブ
ロックベースストレージサービス、及び／または他のネットワークベースサービスに関連
して示されている。リソースホストに分散型リソースのリソースを配置する、様々な他の
種類または構成の分散型システムが、これらの技術を実装してもよい。例えば、バックア
ップまたはアーカイブの分散型ストレージシステムは、現在配置されているデータについ
てより最適な配置を決定してもよい。リソース配置のための適時性リソース移行を実装し
得る、上述した様々なモジュール、コンポーネント、システム、及びまたはサービスの異
なる構成が、リソースの現在の配置を評価し、候補リソースを識別し、候補リソースを移
行するように構成されてもよい。図６は、いくつかの実施形態による、リソース配置を最
適化する適時性リソース移行のための様々な方法及び技術を示すハイレベルフローチャー
トである。これらの技術は、図２〜５に関連して上述したように、制御プレーン、適時性
配置マネージャ、または現在配置されているリソースを分散型システム内の他のリソース
ホストに配置するための他のコンポーネントを用いて実装されてもよい。

リソースは、様々な種類の物理的な、または仮想化されたコンピューティングリソース
、ストレージリソース、またはネットワーキングリソースのうちの１つなどの、多くの異
なる種類のリソースのうちの１つであってもよい。いくつかのリソースは、分散型リソー
スを構成するリソースのグループの一部であってもよい。例えば、図２〜５に関連して上
述したブロックベースストレージサービスのデータボリュームは、マスタ複製及び１つま
たは複数の複製スレーブとして実装される、分散型リソースであってもよい。リソースホ
ストにおけるリソースの初期配置は、最適な配置位置が利用できないときに行われてもよ
い。ボリュームをより良い位置に適時的に移行することによって、様々な設計目標、保証
、または分散型システムにおけるリソースについての他の望ましい属性に従って、個々の
リソース性能及び／または分散型システム性能が改善され得る。

６１０において示すように、分散型システムの異なるリソースホストにおいてホストさ
れるリソースの現在の配置が、異なるリソースホスト間のリソース配置を改善し、または
最適化する配置基準に従って評価されてもよい。配置基準は、リソースホストにおけるリ
ソースの配置、及び／または（個々の配置が最適より劣っているとしても）リソースホス
ト全体の間のリソースの配置の好適性、または最適性を判断するための様々な分析、検査
、計算であってもよい。例えば、配置基準は、リソースの現在の配置が、現在のリソース
ホストにおけるリソースの利用に関して最適である（例えば、リソースのＩＯＰｓ要件が
、他のタスクを実行し、または他のリソースをホストするためのＩＯＰｓ要件を満たすリ
ソースホストの能力に負担をかける）かどうかを判断するために、リソースホストにおけ
るリソース利用（例えば、ストレージリソース、処理リソース、ネットワーキングリソー
スなど）を評価してもよい。

いくつかの実施形態では、リソースの現在の配置の構成が、分散型リソースを構成する
他のリソースに関して判断されてもよい。リソースが、１つまたは複数の１次的複製が故
障している場合に、データへのアクセスリクエストを提供するデータの２次的またはバッ
クアップの複製として動作するシナリオを考える。このようなシナリオでは、１次的複製
との共通の障害に左右されない位置に、リソースを配置することが望ましい場合がある。
例えば、リソースが、現在、複製リソースをホストする別のリソースホストと同一の電源
に接続されたリソースホストに配置されていた場合、リソース（マスタまたはスレーブ）
のうちの１つが、他のリソースホストと同一の電源に接続されたリソースホストにもう配
置されないように、分散型リソース全体の構成の評価は、リソースについての移行が分散
型リソースについてのそのリソースの配置を最適化することを示してもよい。配置基準は
、様々な実行、障害、及び他のシナリオをサポートし、防止し、または説明するように適
合され得るため、分散型リソース、利用可能なバイト、ＩＯＰｓ、またはスロット、ＩＯ
Ｐｓバランスへのバイトなどのリソース利用バランスの一部が、容量フラグメンテーショ
ン、ハードウェア／ソフトウェア特性、及び／または様々な所望の位置ベースの構成に影
響を与える場合、配置基準の数及び種類が、他のリソースを伴うリソースの構成を含むが
、これに限定されず変化してもよい。図７に関連して後述するように、いくつかの実施形
態では、現在の配置適合性のスコアまたは他の指標が、潜在的な行先リソースホストのス
コアと共に判断されてもよい。

６２０で示すように、少なくとも一部評価に基づいて、候補リソース（複数可）を現在
ホストしているそれぞれのリソースホスト（複数可）から行先リソースホスト（複数可）
に適時的に移行するために、候補リソース（複数可）を識別する。様々な実施形態では、
識別された候補リソース（複数可）は、改善閾値を超える予想される移行を有してもよい
。例えば、候補リソースは、配置基準（例えば、異なる配置基準のうちの１つまたは複数
における最適な配置についてのテストに失敗すること、分析、または閾値）に関して、最
適以下として識別されてもよい。リソースを受信するために利用可能なリソースホストは
、（例えば、テストに失敗すること、分析、または閾値を直すことができる位置を提供す
る）配置基準に関してどれが最適かを識別されてもよい。ペアリングは、識別されること
によって、改善閾値を超えてもよい。いくつかの実施形態では、改善閾値は、初期コスト
利益分析決定として作用して、選択され移行が実行された場合に大きな配置改善を経験す
ることとなるリソースを、候補リソースとして識別するだけであってもよい。改善閾値は
また、候補移行が、分散型システム全体のリソースの最適化を改善するか否かを判断する
ために実装されてもよい。例えば、候補リソースは、他のリソースを移行することなく他
のリソースの配置における改善をもたらすこととなる移行動作を実行するために識別され
てもよい。識別される候補リソース（複数可）は、後述するように、移行キュー、または
移行動作をスケジューリングするための他のデータ構造に入力される、対応する移行動作
エントリを有してもよい。このように、移行動作は、より良い位置が利用可能であるとき
にリソースを移行するように適時的に発生してもよい。

６３０に示すように、移行が、移行動作閾値を超えて分散型システム内のリソースのリ
ソース配置を改善するように、候補リソース（複数可）のうちの少なくとも１つが、行先
リソースホスト（複数可）に移行されてもよい。改善は、移行されたリソースの配置、及
び／または分散型システム全体におけるリソースの配置（例えば、ある位置に集中してい
ないリソース）についてであってもよい。移行動作を適時的に実行することによって、他
のリソースが移行のために識別された後で識別され得る候補リソースのために、いくつか
の移行動作が実行されることが可能であってもよい。例えば、いくつかの実施形態では、
優先度または順序付け方式が、識別される候補リソースについての移行動作の実行を選択
するために適用されてもよい。優先度は、リソース、リソースがその一部である分散型リ
ソース、または分散型システム全体に対してより大きな差をもたらす移行動作が、配置に
対してより小さな改善をもたらす移行よりも早く実行されることを可能にしてもよい。

リソースの移行は、リソースを行先リソースホストに移転するように現在のリソースホ
ストに指示することによって実行されてもよい。いくつかの実施形態では、図３のワーカ
（複数可）３４０などの中継が、行先リソースホストにリソースを送信する前にリソース
を指示し、及び／または受信してもよい。少なくともいくつかの実施形態では、リソース
は、物理的に移行されず、論理的に移行されてもよい（例えば、現在のホストからリソー
スを無効にし、または削除し、かつ行先ホストにおいてリソースをインスタンス生成し、
または作成する）。いくつかのシナリオでは、候補リソースホストが識別された時点で識
別される行先リソースホストは、もはや最適ではない（または、その間に他のリソースが
追加され得るために利用可能ですらない）ことがある。したがって、いくつかの実施形態
では、新たな行先リソースホストが識別されてもよい。いくつかの実施形態では、分散型
リソースの一部であるリソースについて、分散型リソース内の別のリソースが現在移行さ
れている場合、リソースは、選択されなくともよい。図３に関連して上述したように、移
行動作を制限するために抑制する技術もまた、実装されてもよい。

図７は、いくつかの実施形態による、適時性リソース移行のための候補としてリソース
を識別する様々な方法及び技術を示すハイレベルフローチャートである。７１０で示すよ
うに、リソースホストにおけるリソースの現在の配置に対する配置スコアが、１つまたは
複数の配置基準に関して生成されてもよい。配置基準は、上述のように、分散型システム
におけるリソースの配置を最適化するために使用されてもよい。例えば、分散型リソース
、利用可能なバイト、ＩＯＰｓ、またはスロット、ＩＯＰｓバランスに対するバイトなど
のリソース利用バランスの一部が、容量フラグメンテーション、ハードウェア／ソフトウ
ェア特性、及び／または様々な所望の位置ベースの構成に影響を与える場合、配置基準は
、他のリソースを伴うリソースの構成を含んでもよい。リソースが、分散型リソースを構
成する複数のリソースのうちの１つ（例えば、上述のようにデータボリュームのマスタま
たはスレーブ複製）であるシナリオを考える。分散型リソースの他のリソースと同一の基
盤区域（例えば、同一ネットワークルータに接続されている）内にリソースを配置するこ
とが最適であってもよい。配置スコアは、現在の配置がより最適なシナリオ（例えば、同
一ネットワークルータ）に関してどのくらい近くにあるかについてのスコアに反映されて
もよい。スコアは、リソース、リソースホスト、及び／または分散型システム全体への影
響を考慮して、複数の異なる配置基準の複合であってもよい。

リソースホストは、リソースをホストすることが可能なリソースホストを決定するため
に最初に評価されてもよい。例えば、ある条件を満たさないホストは、考慮から除去され
てもよい。そのような条件は、論理グループ（例えば、リソースが配置されるべき特定の
サーバプールを識別すること）、リソースをホストするためのケイパビリティまたは容量
（例えば、データを記憶するのに十分なバイト、十分なＩＯＰ帯域幅、インストールされ
た適切なハードウェア及び／もしくはソフトウェアなど）、位置もしくは多様性の制約（
例えば、分散型リソースの一部であるリソースは、分散型リソースの別のリソースをホス
トする別のリソースホストと同一のサーバラックにあるリソースホスト上に配置されるこ
とができない）、ならびに／または明示的に除外されるリソースホスト（例えば、ブラッ
クリスト）を含むが、これらに限定されない。次いで、リソースをホストすることが可能
な残りの利用可能なリソースホストが、潜在的な行先ホストとして評価されてもよい。例
えば、７２０に示すように、配置スコア（複数可）が、可能な行先リソースホスト（複数
可）におけるリソースの配置に対して生成されてもよい。少なくともいくつかの実施形態
では、利用可能なリソースホストのサブセットが、可能な配置として生成されたスコアを
有してもよく、一方、他の実施形態では、全ての利用可能なリソースホストが、配置スコ
アを生成することによって考慮されてもよい。７１０においてスコアを生成するために使
用される同一の配置基準は、７２０においてスコアを生成するために使用されてもよい（
例えば、分散型リソース、利用可能なバイト、ＩＯＰｓ、またはスロット、ＩＯＰｓバラ
ンスに対するバイトなどのリソース利用バランスの一部が、容量フラグメンテーション、
ハードウェア／ソフトウェア特性、及び／または様々な所望の位置ベースの構成に影響を
与える場合の、他のリソースを伴うリソースの考慮）。

７３０に示すように、リソースの現在の配置の配置スコアと可能な配置のスコアとの差
が判断され、最適化閾値と比較されてもよい。例えば、差は、閾値（差＞０．３である）
と比較される値であってもよい。７３０からの否定的出口によって示すように、可能な配
置のうちのいずれかの差が最適化閾値を超えない場合、７８０に示すように、別のリソー
スが、評価するために選択されてもよい。しかしながら、任意の配置の差が、リソースを
超える場合、リソースは、移行のための候補リソースとして識別されてもよい。（１つよ
り多くの行先ホストが評価された場合、）最も大きな差を生む可能な行先が、行先ホスト
として識別されてもよい。

少なくともいくつかの実施形態では、７４０に示すように、行先リソースホストへのリ
ソースの移行を実行するための優先度が、割り当てられてもよい。優先度係数は、割り当
てられる優先度を、スコア付けし、重み付けし、生成し、または示すために使用されても
よい。例えば、優先度係数は、現在の行先及び可能な行先の間の差の値（例えば、より大
きな改善を行う移行を実行することを優先すること）、リソースの年式または履歴（例え
ば、より新しいリソースは、長く存在する見込みが少なく、したがって、移行が重要でな
いことがある）、移行を実行するサイズまたはコスト（例えば、リソースが、大きなデー
タボリューム、複雑なコンポーネントもしくはサービス、または他のリソース集約型移行
の場合に移行を遅延する）、及び／またはローカルネットワークの状態（サービングクラ
イアント要求などの前述の処理による、ネットワークもしくは他のリソース制約下にあり
得る分散型システム内の位置における実行から移行動作を遅延すること）を含んでもよい
。その他に加えて、これらの係数は、移行動作のための優先度を決定するために、重み付
けされ、結合され、順序付けされ、選択的に適用されてもよい。

移行キューもしくは他のデータ構造、リソース、またはスケジュールが、移行動作を実
行する優先度と共に、実行されるべき移行動作を示すために保持されてもよい。図７に関
連して説明する技術は、周期的に、または非周期的に移行キューを更新するために使用さ
れてもよい。例えば、分散型システム内のリソースホストの利用は、いくつかのやり方で
追加され、削除され、または変更されているリソースに起因して変化してもよい。移行の
決定は、結果として変化してもよい。図７の技術を周期的に実行することは、分散型シス
テムのリソースホストにおいて発生する変更に従って、移行キュー内の移行動作を更新し
、または再度優先度を付けるために使用されてもよい。７５０に示すように、リソースに
ついての移行動作が移行キューに位置するかどうかに関して、判断が行われてもよい。位
置する場合、７５０からの肯定的出口によって示すように、移行キュー内のリソースにつ
いての移行動作が更新されてもよい。例えば、優先度割り当てが、７４０における新たな
分析に従って変更されてもよく、移行動作の状態（例えば、待機中、進行中、完了）、タ
イムスタンプ、新たな行先ホスト、または他の情報などの移行動作メタデータが、変化し
てもよい。いくつかの実施形態では、進行中の移行動作が、（例えば、移行キュー内にあ
る後続の分析のためにメタデータを保存するために）更新されなくてもよい。リソースが
、移行キュー内にない場合、要素７５０からの否定的出口によって示すように、リソース
を行先リソースホストに移行するために、移行動作が追加されてもよい。次いで７８０に
示すように、別のリソース配置が、評価するために選択されてもよい。

移行キュー、または移行のための候補リソースを示す他の構造が、移行動作をスケジュ
ールし、実行するために利用されてもよい。例えば、いくつかの移行動作の実行が、他の
移行動作よりも、（リソースの動作または分散型システムのいずれかに対して）大きな利
益をもたらしてもよい。図８は、いくつかの実施形態による、候補リソースを選択及び移
行するための様々な方法及び技術を示すハイレベルフローチャートである。

８１０に示すように、いくつかの実施形態では、実行されるべき移行動作を含む移行キ
ューが、評価されてもよい。移行のために保持される様々な情報は、現在実行される必要
がない（例えば、移行動作が、既に進行中である、失敗している、または実行準備がされ
ていない）動作を除去するために使用されてもよい。いくつかの実施形態では、移行動作
が特定の数に抑制され、または制限される分散型システムの位置において、いくつかの移
行動作が実行されてもよい。いくつかの実施形態では、８２０に示すように、少なくとも
一部評価に基づいて、移行キュー内の移行動作に割り当てられたそれぞれの優先度に従っ
て、移行動作が、実行するためにキューから選択されてもよい。例えば、移行キューは、
優先度キューであってもよく、したがって、最も高い優先度の移行動作が、移行キューか
ら選択されてもよい。移行動作の実行をスケジュールするための様々な他の優先度、また
は順序付け方式（例えば、先入れ先出し方式）が、実装されてもよい。

８３０に示すように、いくつかの実施形態では、行先リソースホストが、いくつかの実
施形態で、移行動作の候補リソースを受信するために識別されてもよい。例えば、移行動
作が移行キューに追加された時に選択された行先リソースホストを使用する代わりに、要
求は、配置エンジン、または現在のデータに基づいて新たなもしくは異なる行先リソース
ホストを提供し得る他のシステム、サービス、もしくはデバイスに対して行われてもよい
。代替的に、移行キュー内の移行動作エントリにおいて示す行先リソースホストが、行先
リソースホストとして識別されてもよい。

８４０に示すように、現在のリソースホストから、識別される行先リソースホストへの
移行動作が、指示されてもよい。例えば、コマンドまたは命令が、候補リソースを行先リ
ソースホストに送信し、コピーし、通信し、または移転する現在位置のリソースホストに
送信されてもよい。いくつかの実施形態では、現在のリソースホストは、さらなる指示な
しでこの移転を実行するように構成されてもよい。少なくともいくつかの実施形態では、
リソースは、まず、現在のリソースホストから取得され、次いで、移行ワーカ（複数可）
３４０などの中継を経由して移転されてもよい。リソースホストを移行することは、行先
リソースホストにおける様々な構成動作を実行すること、または指示することを含んでも
よい。例えば、図２〜５に関連して上述したように、スレーブ複製及びマスタ複製を伴う
データボリュームの複製の移行は、移行される複製の種類によりデータボリュームの複製
についてのスレーブまたはマスタとして動作するように、行先リソースホストを構成する
ことを伴ってもよい。

図８に示す技術は、１つまたは多くの異なるシステムまたはデバイスによって実行され
てもよい。例えば、図３における３３０などの適時性移行マネージャは、移行キューの評
価を実行し、実行する移行動作を選択してもよく、一方、図３における３４０などの移行
ワーカ（複数可）は、移行動作の一部としてリソースを受信する行先リソースホストの識
別を実行し、移行動作を指示してもよい。移行は、非同期式で実行されてもよいため、移
行ワーカは、リソースの移行動作を指示し、次いで、別の移行動作を取得及び指示しても
よい。いくつかの実施形態では、単一の移行マネージャが上述の様々な技術の全てを実行
してもよい。代替的には、移行ワーカが、上記技術を実行してもよい。よって、前述の実
施例は、限定であることを意図されない。

図４に関連して上述したように、移行キュー、または移行のための候補リソースを示す
他の構造は、候補リソースについての状態情報を保持してもよい。移行キュー内の状態情
報の変更は、移行キュー内のいくつかの移行動作を廃止してもよい。図９は、いくつかの
実施形態による、候補リソースを移行キューから削除するための様々な方法及び技術を示
すハイレベルフローチャートである。９１０に示すように、リソースを行先リソースホス
トに移行するための移行動作のキュー（例えば、図４の移行キュー４００）内の移行動作
が、評価されてもよい。例えば、移行キュー内の各エントリは、移行キューから削除され
るべき移行動作を識別するために評価されてもよい。要素９２０及び９３０は、移行動作
の削除をトリガし得る条件の実施例を提供する。

分散型システム内のリソースホストの状態は、頻繁に変更されてもよい。リソースが作
成され、削除され、またはリソースホストの動作もしくは利用において変化してもよい。
この動的な状況は、リソースを移行するための以前の決定を変更してもよい。例えば、上
記図７で述べたように、移行の優先度が、候補リソースについて変化した場合、移行キュ
ーに含まれる優先度が、移行についての現在の優先度を反映するように更新されてもよい
。いくつかの実施形態では、いくつかの移行動作が、もはや最適ではないことがある。９
２０に示すように、次いで、移行動作が、９２０からの肯定的出口によって示すように陳
腐化した場合、移行動作は、９５０に示すようにキューから削除されてもよい。

様々な実施形態では、陳腐化した移行動作は、（例えば、上述の配置基準に従って）も
はや実行するのに最適でない場合がある動作であってもよい。例えば、陳腐化した移行動
作は、新たな優先度または状態情報で更新されていなくてもよい。優先度及び／または移
行動作の他の状態情報が、移行キューの優先度付けスイープが実行された最終時間を更新
されなかった場合、移行動作は、もはや実行するのに最適でない場合があることを示して
もよい。タイムスタンプまたは他の標識が、最終更新時間を示す移行動作について保持さ
れてもよい。いくつかの実施形態では、更新されたタイムスタンプを有しない場合がある
、「進行中」状態における移行動作については除外されてもよい。いくつかの実施形態で
は、比較は、タイムスタンプと生存時間閾値との間であってもよく、閾値を超える場合、
移行動作が陳腐化していることを示している。いくつかの実施形態では、マーカまたは他
の標識（例えば、廃棄標識）は、移行キュー内の移行動作についてのエントリに配置され
て、移行動作が陳腐化し削除されるべきであることを示してもよい。いくつかのシナリオ
では、移行動作は、（例えば、「移行中」状態の時間を移行時間閾値と比較することによ
り）移行動作が開始されたが失敗した、または完了しなかったことを示す。

９３０に示す移行動作が、９３０からの肯定的出口によって示すように完了した場合、
移行動作は、９５０に示すように移行キューから削除されてもよい。例えば、移行動作状
態は、移行キューの優先度スイープの間に変更されて、移行動作の状態を完了に更新して
もよい。

いくつかの移行動作は、他の動作より長くかかる場合がある（例えば、いくつかのリソ
ースは、他のリソースよりも大きい場合がある）ため、移行動作は、要素９２０及び９３
０によって示すような削除条件が満たされるまで、移行キュー内に残っていてもよい。し
たがって、削除条件が満たされない場合、９４０に示すように、キュー内の別の移行動作
が、評価するために選択されてもよい。図９に示す技術は、移行キュー内の移行動作の全
てが評価されるまで、実行されてもよい。移行キューが再び評価されて移行動作が削除さ
れる前に、ある期間が経過してもよい。

本開示の実施形態は、以下の条項を考慮して説明され得る。
１．複数のリソースのうちの１つまたは複数をそれぞれがホストする複数のリソースホス
トと、
１つまたは複数の配置基準に従って、前記複数のリソースの現在の配置を評価し、前
記１つまたは複数の配置基準が、分散型システムについて前記複数のリソースホスト間の
リソース配置を改善し、
前記評価に少なくとも一部基づいて、１つまたは複数の候補リソースを現在ホストす
る前記それぞれのリソースホストから、前記複数のリソースホストのそれぞれの行先リソ
ースホストに移行するために、前記複数のリソースのうちの前記１つまたは複数の候補リ
ソースを識別し、前記複数のリソースのうちの前記１つまたは複数の候補リソースの予想
される前記移行が、前記１つまたは複数の配置基準に関する改善閾値を越え、
前記１つまたは複数の候補リソースのうちの少なくとも１つを前記それぞれの行先リ
ソースホストに移行するように移行動作に指示し、前記少なくとも１つの候補リソースの
前記それぞれの行先リソースホストへの前記移行が、前記改善閾値を越えて、前記複数の
リソースホストのリソース配置を改善するように構成される、
適時性配置マネージャと、
を備える分散型システム。

２．前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別するために
、前記適時性配置マネージャが、
前記１つまたは複数の候補リソースの移行について、それぞれの優先度を決定し、
前記１つまたは複数の候補リソースのためのそれぞれの移行動作をキューに配置するよ
うに構成され、
前記適時性配置マネージャが、
前記キューの評価に少なくとも一部基づいて、前記１つまたは複数の候補リソースに割
り当てられる前記それぞれの優先度に従って移行するために、前記少なくとも１つの候補
リソースを選択するようにさらに構成される、条項１に記載のシステム。

３．複数の移行ワーカをさらに備え、
前記移行動作に前記少なくとも１つの候補リソースを移行するように指示するために、
前記適時性配置マネージャが、実行するために前記移行動作を前記複数の移行ワーカのう
ちの１つに送信するように構成される、条項２に記載のシステム。

４．前記分散型システムが、仮想ブロックベースストレージサービスであり、前記複数
のリソースが、前記仮想ブロックベースストレージサービスの複数のクライアントのため
に保持される複数のデータボリュームである、条項１に記載のシステム。

５．１つまたは複数の配置基準に従って、分散型システムの複数のリソースホストのう
ちのそれぞれの１つにおいてホストされる複数のリソースの現在の配置を評価することで
あって、前記１つまたは複数の配置基準が、前記分散型システムについて前記複数のリソ
ースホスト間のリソース配置を改善する、前記評価することと、
前記評価に少なくとも一部基づいて、１つまたは複数の候補リソースを現在ホストする
前記それぞれのリソースホストから、前記複数のリソースホストのそれぞれの行先リソー
スホストに移行するために、前記複数のリソースのうちの前記１つまたは複数の候補リソ
ースを識別することであって、前記複数のリソースのうちの前記１つまたは複数の候補リ
ソースの予想される前記移行が、改善閾値を越える、前記識別することと、
前記１つまたは複数の候補リソースのうちの少なくとも１つを前記それぞれの行先リソ
ースホストに移行することであって、前記少なくとも１つの候補リソースの前記それぞれ
の行先リソースホストへの前記移行が、前記改善閾値を越えて、前記複数のリソースのリ
ソース配置を改善する、前記移行することと、
を１つまたは複数のコンピューティングデバイスによって実行することを含む、方法。

６．前記複数のリソースのうちの１つまたは複数の候補リソースを識別することが、前
記１つまたは複数の候補リソースの移行を実行するためのそれぞれの優先度を割り当てる
ことを含み、
前記方法が、前記１つまたは複数の候補リソースに割り当てられた前記それぞれの優先
度に従って移行するために、前記少なくとも１つの候補リソースを選択することをさらに
含む、条項５に記載の方法。

７．前記複数のリソースの前記現在の配置の別の評価に従って、前記１つまたは複数の
候補リソースの前記それぞれの優先度を更新することと、
前記１つまたは複数の候補リソースの前記更新されたそれぞれの優先度に従って移行す
るために、前記１つまたは複数の候補リソースのうちの別の１つを選択することと、
をさらに含む、条項６に記載の方法。

８．前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別することが
、前記１つまたは複数の候補リソースのためのそれぞれの移行動作をキューに配置するこ
とをさらに含み、
前記１つまたは複数の候補リソースに割り当てられた前記それぞれの優先度に従って移
行するために、前記少なくとも１つの候補リソースを選択することが、前記キューの評価
に基づいて実行される、条項６に記載の方法。

９．前記複数のリソースの前記現在の配置の別の評価に従って、前記キューから前記１
つまたは複数の候補リソースのうちの少なくとも１つを削除することをさらに含む、条項
８に記載の方法。

１０．前記１つまたは複数の配置基準に従って、前記分散型システムの前記複数のリソ
ースホストのうちの前記それぞれの１つにおいてホストされる前記複数のリソースの現在
の配置を評価することが、
前記１つまたは複数の配置基準に従って、前記複数のリソースの前記現在の配置に対し
て、それぞれの配置スコアを生成することを含み、
前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別することが、
前記１つまたは複数の配置基準に従って、前記複数のリソースの前記１つまたは複数
の可能な配置に対して、それぞれの配置スコアを生成することと、
前記現在の配置に対する前記それぞれの配置スコアと、１つまたは複数の可能な配置
に対する前記それぞれの配置スコアとの間のそれぞれのスコア差を計算することと、
前記１つまたは複数の候補リソースとして、前記改善閾値を超えるそれぞれのスコア
差を有するリソースを決定することと、
を含む、条項５に記載の方法。

１１．前記リソースが、分散型リソースを実装する複数のリソースのうちの１つであり
、前記１つまたは複数の配置基準が、前記分散型リソースの前記複数のリソースについて
の現在の配置構成の評価を含む、条項５に記載の方法。

１２．前記１つまたは複数の候補リソースのうちの少なくとも１つを、前記それぞれの
行先リソースホストに移行することが、前記行先リソースホストを識別することを含む、
条項５に記載の方法。

１３．前記少なくとも１つの候補リソースを前記それぞれの行先リソースホストに移行
することが、前記複数のリソースの別のリソースのための配置を改善する、条項５に記載
の方法。

１４．前記分散型システムが、ネットワークベースサービスであり、前記複数のリソー
スが、前記ネットワークベースサービスの複数のクライアントに対し、前記ネットワーク
ベースサービスにおいて保持され、
前記評価すること、前記識別すること、前記移行することが、前記ネットワークベース
サービスについてのバックグラウンドサービスの一部として実行される、条項５の記載の
方法。

１５．１つまたは複数のコンピューティングデバイスによって実行されるときに、前記
１つまたは複数のコンピューティングデバイスに、
１つまたは複数の配置基準に従って、分散型システムの複数のリソースホストのうちの
、それぞれの１つにおいてホストされる複数のリソースの現在の配置を評価することであ
って、前記１つまたは複数の配置基準が、前記分散型システムについて前記複数のリソー
スホスト間のリソース配置を改善する、前記評価することと、
前記評価に少なくとも一部基づいて、１つまたは複数の候補リソースを現在ホストする
前記それぞれのリソースホストから、前記複数のリソースホストのそれぞれの行先リソー
スホストに移行するために、前記複数のリソースのうちの前記１つまたは複数の候補リソ
ースを識別することであって、前記複数のリソースのうちの前記１つまたは複数の候補リ
ソースの予想される前記移行が、改善閾値を越える、前記識別することと、
前記１つまたは複数の候補リソースのうちの少なくとも１つを前記それぞれの行先リソ
ースホストに移行することであって、前記少なくとも１つの候補リソースの前記それぞれ
の行先リソースホストへの前記移行が、前記改善閾値を越えて、前記複数のリソースのリ
ソース配置を改善する、前記移行することと、
を実装させるプログラム命令を記憶する、非一時的コンピュータ可読記憶媒体。

１６．前記複数のリソースのうちの１つまたは複数の候補リソースを識別する際に、前
記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、前記１つま
たは複数の候補リソースの移行を実行するためのそれぞれの優先度を割り当てることを実
装させ、
前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、前記１
つまたは複数の候補リソースに割り当てられた前記それぞれの優先度に従って移行するた
めに、前記少なくとも１つの候補リソースを選択することをさらに実装させる、条項１５
に記載の非一時的コンピュータ可読記憶媒体。

１７．前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、
前記複数のリソースの前記現在の配置の別の評価に従って、前記１つまたは複数の候補
リソースの前記それぞれの優先度を更新することと、
前記１つまたは複数の候補リソースの前記更新されたそれぞれの優先度に従って移行す
るために、前記１つまたは複数の候補リソースのうちの別の１つを選択することと、
をさらに実装させる、条項１６に記載の非一時的コンピュータ可読記憶媒体。

１８．前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別する際に
、前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、前記１
つまたは複数の候補リソースのためのそれぞれの移行動作をキューに配置することをさら
に実装させ、
前記１つまたは複数の候補リソースに割り当てられる前記それぞれの優先度に従って移
行するために、前記少なくとも１つの候補リソースを選択することが、前記キューの評価
に基づいて実行される、条項１６に記載の非一時的コンピュータ可読記憶媒体。

１９．前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、
前記少なくとも１つの候補リソースのための前記それぞれの移行動作が、完了したこと
を判断することと、
前記それぞれの移行動作が完了したことを判断することに応答して、前記それぞれの移
行動作を前記移行キューから削除することと、
を実装させる、条項１８に記載の非一時的コンピュータ可読記憶媒体。

２０．前記１つまたは複数の配置基準に従って、前記分散型システムの前記複数のリソ
ースホストのうちの前記それぞれの１つにおいてホストされる前記複数のリソースの現在
の配置を評価する際に、前記プログラム命令が、前記１つまたは複数のコンピューティン
グデバイスに、前記１つまたは複数の配置基準に従って、前記複数のリソースの前記現在
の配置に対するそれぞれの配置スコアを生成することを実装させ、
前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別する際に、前記
プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、
前記１つまたは複数の配置基準に従って、前記複数のリソースの１つまたは複数の可
能な配置に対して、それぞれの配置スコアを生成することと、
前記現在の配置に対する前記それぞれの配置スコアと、１つまたは複数の可能な配置
に対する前記それぞれの配置スコアとの間のそれぞれのスコア差を計算することと、
前記１つまたは複数の候補リソースとして、前記改善閾値を超えるそれぞれのスコア
差を有するリソースを決定することと、
を実装させる、条項１５に記載の非一時的コンピュータ可読記憶媒体。

２１．前記分散型システムが、仮想ブロックベースストレージサービスであり、前記複
数のリソースが、前記仮想ブロックベースストレージサービスの複数のクライアントのた
めに保持されるデータボリュームである、条項１５に記載の非一時的コンピュータ可読記
憶媒体。

本明細書で説明する方法は、様々な実施形態で、ハードウェア及びソフトウェアの任意
の組み合わせによって実装されてもよい。例えば、一実施形態では、方法は、プロセッサ
に連結されるコンピュータ可読記憶媒体上に記憶されたプログラム命令を実行する、１つ
または複数のプロセッサを含むコンピュータシステム（例えば、図１０におけるコンピュ
ータシステム）によって実装されてもよい。プログラム命令は、本明細書で説明する機能
性（例えば、本明細書で説明するブロックベースストレージサービスを実装するものなど
の、様々なサーバ、リソースホスト、制御プレーン、マネージャ及び／または他のコンポ
ーネントの機能性）を実装するように構成されてもよい。図に示され、本明細書で説明さ
れる様々な方法は、方法の実施形態の実施例を表す。任意の方法の順序は、変更されても
よく、様々な要素が追加され、再配列され、結合され、省略され、修正されるなどしても
よい。

本明細書で説明する、リソース配置を最適化するための適時性リソース移行の実施形態
は、様々な他のデバイスとやり取りし得る１つまたは複数のコンピュータシステム上で実
行されてもよい。図１０は、様々な実施形態による、コンピューティングシステムの実施
例を示すブロック図である。例えば、コンピュータシステム１０００は、異なる実施形態
において、コンピュートクラスタのストレージ及び／もしくはコンピュートノード、デー
タストア、ならびに／またはクライアントを実装するように構成されてもよい。コンピュ
ータシステム１０００は、パーソナルコンピュータシステム、デスクトップコンピュータ
、ラップトップもしくはノートブックコンピュータ、メインフレームコンピュータシステ
ム、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、コン
シューマデバイス、アプリケーションサーバ、ストレージデバイス、電話、携帯電話、ま
たは概して任意の種類のコンピューティングデバイスを含むが、これらに限定されない、
様々な種類のデバイスのうちのいずれかであってもよい。

コンピュータシステム１０００は、入力／出力（Ｉ／Ｏ）インタフェース１０３０を介
してシステムメモリ１０２０に連結される１つまたは複数のプロセッサ１０１０（シング
ルまたはマルチスレッドであってもよい、マルチコアを含み得るもののいずれか）を含む
。コンピュータシステム１０００は、Ｉ／Ｏインタフェース１０３０に連結されるネット
ワークインタフェース１０４０をさらに含む。様々な実施形態では、コンピュータシステ
ム１０００は、１つのプロセッサ１０１０を含むユニプロセッサシステム、または複数（
例えば、２個、４個、８個、もしくは別の適当な数）のプロセッサ１０１０を含むマルチ
プロセッサシステムであってもよい。プロセッサ１０１０は、命令を実行可能な任意の適
当なプロセッサであってもよい。例えば、様々な実施形態では、プロセッサ１０１０は、
ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ ＩＳＡ、または任意の他の適
当なＩＳＡなどの多様な命令セットアーキテクチャ（ＩＳＡ）のいずれかを実装する汎用
または組み込みプロセッサであってもよい。マルチプロセッサシステムでは、プロセッサ
１０１０のそれぞれは、一般に、しかし必須ではなく、同一のＩＳＡを実装してもよい。
コンピュータシステム１０００は、また、他のシステム及び／またはコンポーネントと通
信ネットワーク（例えば、インターネット、ＬＡＮなど）を介して通信するための、１つ
または複数のネットワーク通信デバイス（例えば、ネットワークインタフェース１０４０
）を含む。

図示される実施形態では、コンピュータシステム１０００は、また、１つもしくは複数
の永続ストレージデバイス１０６０、及び／または１つもしくは複数のＩ／Ｏデバイス１
０８０を含む。様々な実施形態では、永続ストレージデバイス１０６０は、ディスクドラ
イブ、テープドライブ、ソリッドステートメモリ、他の大容量ストレージデバイス、ブロ
ックベースストレージデバイス、または任意の他の永続ストレージデバイスに対応しても
よい。コンピュータシステム１０００（または、その上で動作する分散型アプリケーショ
ン、もしくはオペレーティングシステム）は、所望により、命令及び／またはデータを永
続ストレージデバイス１０６０に記憶してもよく、記憶された命令及び／またはデータを
必要に応じて取得してもよい。例えば、いくつかの実施形態では、コンピュータシステム
１０００は、ストレージシステムサーバノードをホストしてもよく、永続ストレージ１０
６０は、そのサーバノードに取り付けられたＳＳＤを含んでもよい。

コンピュータシステム１０００は、プロセッサ（複数可）１０１０によってアクセス可
能な命令及びデータを記憶するように構成される、１つまたは複数のシステムメモリ１０
２０を含む。様々な実施形態では、システムメモリ１０２０は、任意の適当なメモリ技術
（例えば、キャッシュ、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ＤＲＡＭ、
ＲＤＲＡＭ、ＥＤＯ ＲＡＭ、ＤＤＲ １０ ＲＡＭ、同期式動的ＲＡＭ（ＳＤＲＡＭ）
、ラムバスＲＡＭ、ＥＥＰＲＯＭ、不揮発性／フラッシュ型メモリ、または任意の他の種
類のメモリのうちの１つまたは複数）を用いて実装されてもよい。システムメモリ１０２
０は、本明細書で説明する方法及び技術を実装するために、プロセッサ（複数可）１０１
０によって実行可能なプログラム命令１０２５を含んでもよい。様々な実施形態では、プ
ログラム命令１０２５は、プラットフォームネイティブのバイナリ、ＪＡＶＡ（商標）バ
イトコードなどの任意のインタプリタ型言語、もしくはＣ／Ｃ＋＋、Ｊａｖａ（商標）な
どの任意の他の言語で、またはそれらの任意の組み合わせで、符号化されてもよい。例え
ば、例示された実施形態では、プログラム命令１０２５は、異なる実施形態で、リソース
ホストの機能性を実装するために実行可能なプログラム命令を含む。いくつかの実施形態
では、プログラム命令１０２５は、複数の別個のクライアント、ノード、及び／または他
のコンポーネントを実装してもよい。

いくつかの実施形態では、プログラム命令１０２５は、ＵＮＩＸ（登録商標）、ＬＩＮ
ＵＸ、Ｓｏｌａｒｉｓ（商標）、ＭａｃＯＳ（商標）、Ｗｉｎｄｏｗｓ（商標）などの様
々なオペレーティングシステムのうちのいずれかであり得る、オペレーティングシステム
（図示せず）を実装するために実行可能な命令を含んでもよい。プログラム命令１０２５
のうちのいずれかまたは全てが、命令をその上に記憶している非一時的コンピュータ可読
記憶媒体を含み得るコンピュータプログラム製品、またはソフトウェアとして提供されて
もよく、命令は、様々な実施形態に従ってプロセスを実行するコンピュータシステム（ま
たは他の電子デバイス）をプログラムするために使用されてもよい。非一時的コンピュー
タ可読記憶媒体は、機械（例えば、コンピュータ）によって可読の形式（例えば、ソフト
ウェア、処理アプリケーション）で、情報を記憶するための任意の機構を含んでもよい。
概して言うと、非一時的コンピュータアクセス可能媒体が、Ｉ／Ｏインタフェース１０３
０を介してコンピュータシステム１０００に連結される、例えば、ディスクまたはＤＶＤ
／ＣＤ−ＲＯＭといった磁気または光学媒体などの、コンピュータ可読記憶媒体またはメ
モリ媒体を含んでもよい。非一時的コンピュータ可読記憶媒体は、また、システムメモリ
１０２０または別の種類のメモリとしてコンピュータシステム１０００のいくつかの実施
形態に含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、Ｓ
ＲＡＭなど）、ＲＯＭなどの任意の揮発性または不揮発性媒体を含んでもよい。他の実施
形態では、プログラム命令は、ネットワークインタフェース１０４０を介して実装され得
るような、ネットワーク及び／またはワイヤレスリンクなどの通信媒体を介して伝達され
る、光学、音響、または他の形態の伝搬信号（例えば、搬送波、赤外線信号、デジタル信
号など）を用いて通信されてもよい。

いくつかの実施形態では、システムメモリ１０２０は、データストア１０４５を含んで
もよく、データストア１０４５は、本明細書で説明するように構成されてもよい。概して
、システムメモリ１０２０（例えば、システムメモリ１０２０内のデータストア１０４５
）、永続ストレージ１０６０、及び／またはリモートストレージ１０７０は、データブロ
ック、データブロックの複製、データブロックに関連付けられるメタデータ及び／もしく
はそれらの状態、構成情報、ならびに／または本明細書で説明する方法及び技術を実装す
るのに利用可能な任意の他の情報を記憶してもよい。

一実施形態では、Ｉ／Ｏインタフェース１０３０は、ネットワークインタフェース１０
４０または他の周辺インタフェースを通じて含む、システム内のプロセッサ１０１０、シ
ステムメモリ１０２０、及び任意の周辺デバイスの間のＩ／Ｏトラフィックを協調させる
ように構成されてもよい。いくつかの実施形態では、Ｉ／Ｏインタフェース１０３０は、
データ信号を１つのコンポーネント（例えば、システムメモリ１０２０）から、別のコン
ポーネント（例えば、プロセッサ１０１０）による使用に適したフォーマットに変換する
ために、任意の必要なプロトコル、タイミングまたは他のデータ変換を実行してもよい。
いくつかの実施形態では、Ｉ／Ｏインタフェース１０３０は、例えば、周辺構成要素相互
接続（ＰＣＩ）バス規格またはユニバーサルシリアルバス（ＵＳＢ）規格の変形などの、
様々な種類の周辺バスを通じて取り付けられたデバイスのためのサポートを含んでもよい
。いくつかの実施形態では、Ｉ／Ｏインタフェース１０３０の機能は、例えば、ノースブ
リッジ及びサウスブリッジなどの２つ以上の別々のコンポーネントに分割されてもよい。
さらに、いくつかの実施形態では、システムメモリ１０２０へのインタフェースなどのＩ
／Ｏインタフェース１０３０の機能性のうちのいくつかまたは全てが、プロセッサ１０１
０に直接組み込まれてもよい。

ネットワークインタフェース１０４０は、コンピュータシステム１０００と、例えば、
他のコンピュータシステム１０９０などの、ネットワークに取り付けられる他のデバイス
との間でデータが交換されることを可能にするように構成されてもよい。さらに、ネット
ワークインタフェース１０４０は、コンピュータシステム１０００と、様々なＩ／Ｏデバ
イス１０５０及び／またはリモートストレージ１０７０との間での通信を可能にするよう
に構成されてもよい。入力／出力デバイス１０５０は、いくつかの実施形態では、１つま
たは複数のディスプレイ端末、キーボード、キーパッド、タッチパッド、スキャニングデ
バイス、音声または光認識デバイス、または、１つもしくは複数のコンピュータシステム
１０００によってデータを入力もしくは取得するのに適した任意の他のデバイスを含んで
もよい。複数の入力／出力デバイス１０５０は、コンピュータシステム１０００内に存在
してもよく、またはコンピュータシステム１０００を含む分散型システムの様々なノード
上に分散されてもよい。いくつかの実施形態では、同様の入力／出力デバイスは、コンピ
ュータシステム１０００とは別個であってもよく、ネットワークインタフェース１０４０
を介するなど、有線または無線接続を通じてコンピュータシステム１０００を含む分散型
システムの１つまたは複数のノードとやり取りしてもよい。ネットワークインタフェース
１０４０は、一般に、１つまたは複数の無線ネットワーキングプロトコル（例えば、Ｗｉ
−Ｆｉ／ＩＥＥＥ８０２．１１、または別の無線ネットワーキング規格）をサポートして
もよい。しかしながら、様々な実施形態では、ネットワークインタフェース１０４０は、
例えば、他の種類のイーサネット（登録商標）ネットワークなどの、任意の適当な有線ま
たは無線汎用データネットワークを介して通信をサポートしてもよい。追加的に、ネット
ワークインタフェース１０４０は、ファイバチャネルＳＡＮなどのストレージエリアネッ
トワークを介して、または任意の他の適当な種類のネットワーク及び／もしくはプロトコ
ルを介して、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークなどの
、遠距離通信／電話通信ネットワークを介した通信をサポートしてもよい。様々な実施形
態では、コンピュータシステム１０００は、図１０に示すもの（例えば、ディスプレイ、
ビデオカード、オーディオカード、周辺デバイス、ＡＴＭインタフェース、イーサネット
インタフェース、フレームリレーインタフェースなどの他のネットワークインタフェース
など）より多くの、少ない、または異なるコンポーネントを含んでもよい。

本明細書で説明する分散型システムの実施形態のいずれか、またはそれらのコンポーネ
ントのいずれかが、１つまたは複数のネットワークベースサービスとして実装されてもよ
いことに留意されたい。例えば、コンピューティングサービス内のコンピュートクラスタ
は、コンピューティング及び／もしくはストレージサービス、ならびに／または本明細書
で説明する分散型コンピューティングシステムをネットワークベースサービスとしてクラ
イアントに採用する、他の種類のサービスを提示してもよい。いくつかの実施形態では、
ネットワークベースサービスは、ネットワーク上で相互運用可能なマシンツーマシンイン
タラクションをサポートするように設計されるソフトウェア及び／またはハードウェアシ
ステムによって実装されてもよい。ネットワークベースサービスは、ウェブサービス記述
言語（ＷＳＤＬ）などのマシン処理可能なフォーマットで記載されたインタフェースを有
してもよい。他のシステムは、ネットワークベースサービスのインタフェースの仕様によ
って規定されたやり方で、ネットワークベースサービスと対話してもよい。例えば、ネッ
トワークベースサービスは、他のシステムが呼び出し得る様々な動作を定義してもよく、
他のシステムが様々な動作を要求するときに従うことを期待され得る、特定のアプリケー
ションプログラミングインタフェース（ＡＰＩ）を定義してもよい。

様々な実施形態では、ネットワークベースサービスが、ネットワークベースサービス要
求に関連するパラメータ及び／またはデータを含むメッセージの使用を通じて要求され、
または呼び出されてもよい。そのようなメッセージは、拡張マークアップ言語（ＸＭＬ）
などの特定のマークアップ言語に従ってフォーマットされてもよく、及び／または簡易オ
ブジェクトアクセスプロトコル（ＳＯＡＰ）などのプロトコルを用いてカプセル化されて
もよい。ネットワークベースサービス要求を実行するために、ネットワークベースサービ
スクライアントは、要求を含むメッセージを集め、ハイパーテキスト転送プロトコル（Ｈ
ＴＴＰ）などのインターネットベースのアプリケーション層転送プロトコルを用いて、ネ
ットワークベースサービスに対応するアドレス指定可能なエンドポイント（例えば、ユニ
フォームリソースロケータ（ＵＲＬ））にメッセージを伝達してもよい。

いくつかの実施形態では、ネットワークベースサービスは、メッセージベースの技術で
はなく、ＲＥＳＴ（「ＲＥＳＴｆｕｌ」）技術を用いて実装されてもよい。例えば、ＲＥ
ＳＴｆｕｌ技術に従って実装されたネットワークベースサービスは、ＳＯＡＰメッセージ
内にカプセル化されるのではなく、ＰＵＴ、ＧＥＴ、またはＤＥＬＥＴＥなどのＨＴＴＰ
方式に含まれるパラメータを通じて呼び出されてもよい。

上記の実施形態は、かなり詳細に説明されているが、一度上記の開示が完全に理解され
れば当業者には明らかとなるような、多くの変形及び修正が行われてもよい。以下の特許
請求の範囲は、そのような修正及び変更の全てを包含するように解釈され、従って、上記
の説明は、限定的な意味ではなく、例示的な意味にみなされるべきであると意図される。

Claims (15)

1. 複数のリソースのうちの１つまたは複数をそれぞれがホストする複数のリソースホストであって、前記複数のリソースホストは、それぞれの前記リソースがネットワークを通じて、前記複数のリソースホストとは異なるリソースホスト上で動作するクライアントにアクセス可能であるようにする、前記複数のリソースホストと、
   １つまたは複数の配置基準に従って、前記複数のリソースの現在の配置を評価し、前記１つまたは複数の配置基準が、前記クライアントに関して、分散型システムの前記複数のリソースホスト間で全体として前記複数のリソースのリソース配置を少なくとも改善するための、前記複数のリソースの現在の配置構成の評価を含み、
   前記評価に少なくとも一部基づいて、１つまたは複数の候補リソースを現在ホストする前記のリソースホストのそれぞれから、前記複数のリソースホストのそれぞれの行先リソースホストに移行するために、前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別し、前記複数のリソースのうちの前記１つまたは複数の候補リソースの予想される前記移行が、前記１つまたは複数の配置基準に関する改善閾値を越え、
   前記１つまたは複数の候補リソースのうちの少なくとも１つを前記それぞれの行先リソースホストに移行するように移行動作に指示し、前記少なくとも１つの候補リソースの前記それぞれの行先リソースホストへの前記移行が、前記改善閾値を越えて、前記複数のリソースホストのリソース配置を改善するように構成される、
   適時性配置マネージャと、
   を備える分散型システム。
2. 前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別するために、前記適時性配置マネージャが、
   前記１つまたは複数の候補リソースの移行について、それぞれの優先度を決定し、
   前記１つまたは複数の候補リソースのためのそれぞれの移行動作をキューに配置するように構成され、
   前記適時性配置マネージャが、
   前記キューの評価に少なくとも一部基づいて、前記１つまたは複数の候補リソースに割り当てられる前記それぞれの優先度に従って移行するために、前記少なくとも１つの候補リソースを選択するようにさらに構成される、請求項１に記載のシステム。
3. 複数の移行ワーカをさらに備え、
   前記移行動作に前記少なくとも１つの候補リソースを移行するように指示するために、前記適時性配置マネージャが、実行するために前記移行動作を前記複数の移行ワーカのうちの１つに送信するように構成される、請求項２に記載のシステム。
4. １つまたは複数の配置基準に従って、分散型システムの複数のリソースホストのうちのそれぞれの１つにおいてホストされる複数のリソースの現在の配置を評価することであって、前記複数のリソースは、それぞれコンピューティングリソース、ストレージリソース、またはネットワーキングリソースを含み、前記複数のリソースホストは、前記複数のリソースのそれぞれのリソースがネットワークを通じてアクセス可能であるようにし、前記１つまたは複数の配置基準が、前記複数のリソースホストとは異なるリソースホスト上で動作するクライアントに関して、分散型システムの前記複数のリソースホスト間で全体として前記複数のリソースのリソース配置を少なくとも改善するための、前記複数のリソースの現在の配置構成の評価を含む、前記評価することと、
   前記評価に少なくとも一部基づいて、１つまたは複数の候補リソースを現在ホストする前記リソースホストのそれぞれから、前記複数のリソースホストのそれぞれの行先リソースホストに移行するために、前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別することであって、前記複数のリソースのうちの前記１つまたは複数の候補リソースの予想される前記移行が、改善閾値を越える、前記識別することと、
   前記１つまたは複数の候補リソースのうちの少なくとも１つを前記それぞれの行先リソースホストに移行することであって、前記少なくとも１つの候補リソースの前記それぞれの行先リソースホストへの前記移行が、前記改善閾値を越えて、前記複数のリソースのリソース配置を改善する、前記移行することと、
   を１つまたは複数のコンピューティングデバイスによって実行することを含む、方法。
5. 前記複数のリソースのうちの１つまたは複数の候補リソースを識別することが、前記１つまたは複数の候補リソースの移行を実行するためのそれぞれの優先度を割り当てることを含み、
   前記方法が、前記１つまたは複数の候補リソースに割り当てられた前記それぞれの優先度に従って移行するために、前記少なくとも１つの候補リソースを選択することをさらに含む、請求項４に記載の方法。
6. 前記複数のリソースの前記現在の配置の別の評価に従って、前記１つまたは複数の候補リソースの前記それぞれの優先度を更新することと、
   前記１つまたは複数の候補リソースの前記更新されたそれぞれの優先度に従って移行するために、前記１つまたは複数の候補リソースのうちの別の１つを選択することと、
   をさらに含む、請求項５に記載の方法。
7. 前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別することが、前記１つまたは複数の候補リソースのためのそれぞれの移行動作をキューに配置することをさらに含み、
   前記１つまたは複数の候補リソースに割り当てられた前記それぞれの優先度に従って移行するために、前記少なくとも１つの候補リソースを選択することが、前記キューの評価に基づいて実行される、請求項５に記載の方法。
8. 前記複数のリソースの前記現在の配置の別の評価に従って、前記キューから前記１つまたは複数の候補リソースのうちの少なくとも１つを削除することをさらに含む、請求項７に記載の方法。
9. 前記１つまたは複数の配置基準に従って、前記分散型システムの前記複数のリソースホストのうちの前記それぞれの１つにおいてホストされる前記複数のリソースの現在の配置を評価することが、
   前記１つまたは複数の配置基準に従って、前記複数のリソースの前記現在の配置に対して、それぞれの配置スコアを生成することを含み、
   前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別することが、
   前記１つまたは複数の配置基準に従って、前記複数のリソースの１つまたは複数の可能な配置に対して、それぞれの配置スコアを生成することと、
   前記現在の配置に対する前記それぞれの配置スコアと、１つまたは複数の可能な配置に対する前記それぞれの配置スコアとの間のそれぞれのスコア差を計算することと、
   前記１つまたは複数の候補リソースとして、前記改善閾値を超える、それぞれのスコア差を有するリソースを決定することと、
   を含む、請求項４に記載の方法。
10. 前記リソースが、分散型リソースを実装する複数のリソースのうちの１つであり、前記１つまたは複数の配置基準が、前記分散型リソースの前記複数のリソースについての現在の配置構成の評価を含む、請求項４に記載の方法。
11. 前記分散型システムが、ネットワークベースサービスであり、前記複数のリソースが、前記ネットワークベースサービスの複数のクライアントに対し、前記ネットワークベースサービスにおいて保持され、
    前記評価すること、前記識別すること、前記移行することが、前記ネットワークベースサービスについてのバックグラウンドサービスの一部として実行される、請求項４の記載の方法。
12. １つまたは複数のコンピューティングデバイスによって実行されるときに、前記１つまたは複数のコンピューティングデバイスに、
    １つまたは複数の配置基準に従って、分散型システムの複数のリソースホストのうちのそれぞれの１つにおいてホストされる複数のリソースの現在の配置を評価することであって、前記複数のリソースは、それぞれコンピューティングリソース、ストレージリソース、またはネットワーキングリソースを含み、前記複数のリソースホストは、前記複数のリソースのそれぞれのリソースがネットワークを通じてアクセス可能であるようにし、前記１つまたは複数の配置基準が、前記複数のリソースホストとは異なるリソースホスト上で動作するクライアントに関して、分散型システムの前記複数のリソースホスト間で全体として前記複数のリソースのリソース配置を少なくとも改善するための、前記複数のリソースの現在の配置構成の評価を含む、前記評価することと、
    前記評価に少なくとも一部基づいて、１つまたは複数の候補リソースを現在ホストする前記リソースホストのそれぞれから、前記複数のリソースホストのそれぞれの行先リソースホストに移行するために、前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別することであって、前記複数のリソースのうちの前記１つまたは複数の候補リソースの予想される前記移行が、改善閾値を越える、前記識別することと、
    前記１つまたは複数の候補リソースのうちの少なくとも１つを前記それぞれの行先リソースホストに移行することであって、前記少なくとも１つの候補リソースの前記それぞれの行先リソースホストへの前記移行が、前記改善閾値を越えて、前記複数のリソースのリソース配置を改善する、前記移行することと、
    を実装させるプログラム命令を記憶する、非一時的コンピュータ可読記憶媒体。
13. 前記複数のリソースのうちの１つまたは複数の候補リソースを識別する際に、前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、前記１つまたは複数の候補リソースの移行を実行するためのそれぞれの優先度を割り当てることを実装させ、
    前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、前記１つまたは複数の候補リソースに割り当てられた前記それぞれの優先度に従って移行するために、前記少なくとも１つの候補リソースを選択することと、
    前記複数のリソースの前記現在の配置の別の評価に従って、前記１つまたは複数の候補リソースの前記それぞれの優先度を更新することと、
    前記１つまたは複数の候補リソースの前記更新されたそれぞれの優先度に従って移行するために、前記１つまたは複数の候補リソースのうちの別の１つを選択することと、
    をさらに実装させる、請求項１２に記載の非一時的コンピュータ可読記憶媒体。
14. 前記１つまたは複数の配置基準に従って、前記分散型システムの前記複数のリソースホストのうちの前記それぞれの１つにおいてホストされる前記複数のリソースの現在の配置を評価する際に、前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、前記１つまたは複数の配置基準に従って、前記複数のリソースの前記現在の配置に対して、それぞれの配置スコアを生成することを実装させ、
    前記複数のリソースのうちの前記１つまたは複数の候補リソースを識別する際に、前記プログラム命令が、前記１つまたは複数のコンピューティングデバイスに、
    前記１つまたは複数の配置基準に従って、前記複数のリソースの前記１つまたは複数の可能な配置に対して、それぞれの配置スコアを生成することと、
    前記現在の配置に対する前記それぞれの配置スコアと、１つまたは複数の可能な配置に対する前記それぞれの配置スコアとの間のそれぞれのスコア差を計算することと、
    前記１つまたは複数の候補リソースとして、前記改善閾値を超える、それぞれのスコア差を有するリソースを決定することと、
    を実装させる、請求項１２に記載の非一時的コンピュータ可読記憶媒体。
15. 前記分散型システムが、仮想ブロックベースストレージサービスであり、前記複数のリソースが、前記仮想ブロックベースストレージサービスの複数のクライアントのために保持されるデータボリュームである、請求項１２に記載の非一時的コンピュータ可読記憶媒体。

Images