JP2023509369A - マルチクラウド環境におけるワークロードの実施 - Google Patents

Abstract

一態様によるコンピュータ実装方法は、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

Description

本発明はワークロードの実施に関し、より詳細には、本発明はクラウド・ベンダーへのワークロード動作の分散に関する。

クラウド・ベンダーを使用して、コンピューティング、ストレージ、帯域幅などのリソースをワークロードに提供することがよくある。これらのワークロードの実施中に、サイバー・レジリエンスを維持することが重要な懸念事項になる。たとえば、ワークロードの実施中にワークロード・データは保護される必要があり得、ワークロードの実施中に所定のサービス・レベルが提供される必要があり得る。同様に、システム障害、マルウェアなどに関係なく、ワークロードは完了される必要があり得る。

しかしながら、現在のワークロードの実施では、ワークロードの実施を最適化および保護するために、利用可能なクラウド・ベンダーを考慮すると、ワークロードの様々な部分が最適化されていない。

一態様によるコンピュータ実装方法は、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

他の態様によれば、複数のクラウド・ベンダーのうちのそれぞれの特性は、クラウド・ベンダーを分析することによって決定され、分析することは、クラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅｓ）を動作させることを含む。

このようにして、ワークロード内の各論理ステージの実施は、最適なクラウド・ベンダーに送られて実施され得る。これにより、各論理ステージを実行するために必要なリソース（たとえば、コンピューティング・リソース、ストレージ・リソース、セキュリティ・リソースなど）の量が減少し得、ひいては、ワークロードを実施（たとえば、実行など）する１つまたは複数のコンピューティング・システムのパフォーマンスが向上し得る。

他の態様によれば、マルチクラウド環境においてワークロードを実施するためのコンピュータ・プログラム製品は、プログラム命令を具現化するコンピュータ可読記憶媒体を含み、コンピュータ可読記憶媒体自体は一過性の信号ではなく、プログラム命令は、プロセッサによって実行可能であり、プロセッサに方法を実行させ、方法は、プロセッサによって、複数のクラウド・ベンダーの特性を決定および記憶することと、プロセッサによって、ワークロードを複数の論理ステージに分割することと、プロセッサによって、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、プロセッサによって、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

一態様によれば、複数のクラウド・ベンダーのうちのそれぞれの特性は、クラウド・ベンダーを分析することによって決定され、分析することは、クラウド・ベンダーに関して収集されたレビュー情報に基づいて、クラウド・ベンダーのそれぞれに関する１つまたは複数の実行可能性要因（ｖｉａｂｉｌｉｔｙ ｆａｃｔｏｒ）を推定することを含み、実行可能性要因は、サービス性、ネット・プロモーター・スコア（ＮＰＳ：ｎｅｔ ｐｒｏｍｏｔｅｒ ｓｃｏｒｅ）、ユーザ・レビュー、パフォーマンス・ベンチマーク、およびチューニングの柔軟性を含むグループから選択される。

他の態様によれば、システムは、プロセッサと、プロセッサと統合された、もしくはプロセッサによって実行可能な、またはプロセッサと統合され、プロセッサによって実行可能なロジックと、を含み、ロジックは、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を行うように構成される。

他の態様によれば、ワークロードを分割することは、ワークロード内のデータ入力および出力のポイント、ならびにワークロードへの入力に関連する依存関係を特定するために、ワークロードを解析することを含む。

このようにして、各論理ステージのサイバー・レジリエンシーが確保され得、これにより、システムの機能停止またはマルウェアによって失われるデータ／計算作業の量が減少し得、ひいては、ワークロードを実施するコンピューティング・システムのパフォーマンスも向上し得る。

他の態様によれば、コンピュータ実装方法は、複数のクラウド・ベンダーを分析することによって、複数のクラウド・ベンダーの特性を決定することであって、分析することは、複数のクラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることと、複数のクラウド・ベンダーのうちのそれぞれのレポート、傾向、脆弱性、セキュリティ問題などのうちの１つまたは複数を特定するために、１つまたは複数のパブリックおよびプライベート・セキュリティ・データベース情報を収集および解析することと、複数のクラウド・ベンダーのうちの１つまたは複数に関する既存のセキュリティ問題に対する既存の解決方法を決定するために、１つまたは複数の解決策データベースを解析することと、を含む、決定することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

他の態様によれば、コンピュータ実装方法は、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することであって、ワークロード内のデータ入力および出力のポイント、ならびにワークロードへの入力に関連する依存関係を特定するために、ワークロードを解析することと、ワークロード内のデータ入力および出力のインスタンスを予測するために、ワークロードのソース・コードをスキャンすることと、を含み、論理ステージのそれぞれは、ワークロード内の他の論理ステージに依存しないデータ入力を含む、分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

本発明の他の態様および実施形態は以下の詳細な説明から明らかになり、以下の詳細な説明は、図面と併せて解釈されるときに、本発明の原理を例として示す。

本発明の一態様によるクラウド・コンピューティング環境を示す図である。 本発明の一態様による抽象化モデル・レイヤを示す図である。 本発明の一態様によるクラウド・コンピューティング・ノードを示す図である。 本発明の一態様による階層型データ・ストレージ・システムを示す図である。 本発明の一態様による、マルチクラウド環境においてワークロードを実施するための方法のフローチャートである。 本発明の一態様による、クラウド・ベンダーをスキャンするための方法のフローチャートである。 本発明の一態様による、ワークロード要件を特定するための方法のフローチャートである。 本発明の一態様による、マルチテナント・ワークロード管理エンジンを実装するための方法のフローチャートである。 本発明の一態様による、例示的な算出されたオーケストレーション・スキーマを示す図である。

以下の説明は、本発明の一般的な原理を説明することを目的として行っており、本明細書で特許請求する本発明の概念を限定することを意図するものではない。さらに、本明細書に記載の特定の特徴は、様々な可能な組み合わせおよび置き換えのそれぞれにおいて、記載した他の特徴と組み合わせて使用することができる。

本明細書で特に明確に定義していない限り、全ての用語は、本明細書から暗示される意味、ならびに当技術分野の当業者によって理解され、または辞書、論文などで定義され、あるいはその両方である意味を含む、最も広い可能な解釈が与えられるべきである。

また、本明細書および添付の特許請求の範囲で使用する場合、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、別段の指定がない限り、複数の指示対象を含むことに留意されたい。「備える（ｃｏｍｐｒｉｓｅｓ）」という用語、もしくは「備えている（ｃｏｍｐｒｉｓｉｎｇ）」という用語、またはその両方は、本明細書で使用する場合、記述した特徴、整数、ステップ、動作、要素、もしくは構成要素、またはそれらの組み合わせの存在を示すものであるが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、もしくはそれらのグループ、またはそれらの組み合わせの存在または追加を排除するものではないということはさらに理解されよう。

以下の説明では、マルチクラウド環境においてワークロードを実施するいくつかの態様を開示する。

１つの一般的な態様では、一態様によるコンピュータ実装方法は、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

他の一般的な態様では、複数のクラウド・ベンダーのうちのそれぞれの特性は、クラウド・ベンダーを分析することによって決定され、分析することは、クラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることを含む。

このようにして、ワークロード内の各論理ステージの実施は、最適なクラウド・ベンダーに送られて実施され得る。これにより、各論理ステージを実行するために必要なリソース（たとえば、コンピューティング・リソース、ストレージ・リソース、セキュリティ・リソースなど）の量が減少し得、ひいては、ワークロードを実施（たとえば、実行など）する１つまたは複数のコンピューティング・システムのパフォーマンスが向上し得る。

他の一般的な態様では、マルチクラウド環境においてワークロードを実施するためのコンピュータ・プログラム製品は、プログラム命令を具現化するコンピュータ可読記憶媒体を含み、コンピュータ可読記憶媒体自体は一過性の信号ではなく、プログラム命令は、プロセッサによって実行可能であり、プロセッサに方法を実行させ、方法は、プロセッサによって、複数のクラウド・ベンダーの特性を決定および記憶することと、プロセッサによって、ワークロードを複数の論理ステージに分割することと、プロセッサによって、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、プロセッサによって、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

他の一般的な態様では、複数のクラウド・ベンダーのうちのそれぞれの特性は、クラウド・ベンダーを分析することによって決定され、分析することは、クラウド・ベンダーに関して収集されたレビュー情報に基づいて、クラウド・ベンダーのそれぞれに関する１つまたは複数の実行可能性要因を推定することを含み、実行可能性要因は、サービス性、ネット・プロモーター・スコア（ＮＰＳ）、ユーザ・レビュー、パフォーマンス・ベンチマーク、およびチューニングの柔軟性を含むグループから選択される。

他の一般的な態様では、システムは、プロセッサと、プロセッサと統合された、もしくはプロセッサによって実行可能な、またはプロセッサと統合され、プロセッサによって実行可能なロジックと、を含み、ロジックは、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を行うように構成される。

他の一般的な態様では、ワークロードを分割することは、ワークロード内のデータ入力および出力のポイント、ならびにワークロードへの入力に関連する依存関係を特定するために、ワークロードを解析することを含む。

このようにして、各論理ステージのサイバー・レジリエンシーが確保され得、これにより、システムの機能停止またはマルウェアによって失われるデータ／計算作業の量が減少し得、ひいては、ワークロードを実施するコンピューティング・システムのパフォーマンスも向上し得る。

他の一般的な態様では、コンピュータ実装方法は、複数のクラウド・ベンダーを分析することによって、複数のクラウド・ベンダーの特性を決定することであって、分析することは、複数のクラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることと、複数のクラウド・ベンダーのうちのそれぞれのレポート、傾向、脆弱性、セキュリティ問題などのうちの１つまたは複数を特定するために、１つまたは複数のパブリックおよびプライベート・セキュリティ・データベース情報を収集および解析することと、複数のクラウド・ベンダーのうちの１つまたは複数に関する既存のセキュリティ問題に対する既存の解決方法を決定するために、１つまたは複数の解決策データベースを解析することと、を含む、決定することと、ワークロードを複数の論理ステージに分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

他の一般的な態様では、コンピュータ実装方法は、複数のクラウド・ベンダーの特性を決定および記憶することと、ワークロードを複数の論理ステージに分割することであって、ワークロード内のデータ入力および出力のポイント、ならびにワークロードへの入力に関連する依存関係を特定するために、ワークロードを解析することと、ワークロード内のデータ入力および出力のインスタンスを予測するために、ワークロードのソース・コードをスキャンすることと、を含み、論理ステージのそれぞれは、ワークロード内の他の論理ステージに依存しないデータ入力を含む、分割することと、複数の論理ステージのうちのそれぞれの特性を決定することと、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージを複数のクラウド・ベンダーのうちの１つに割り当てることと、を含む。

本開示はクラウド・コンピューティングに関する詳細な説明を含むが、本明細書に列挙した教示の実装形態はクラウド・コンピューティング環境に限定されないことを理解されたい。むしろ、本発明の態様は、現在知られているまたは今後開発される他の任意のタイプのコンピューティング環境と共に実装することが可能である。

クラウド・コンピューティングは、最小限の管理労力またはサービスのプロバイダとのやりとりによって迅速にプロビジョニングおよび解放することができる、設定可能なコンピューティング・リソース（たとえば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特徴と、少なくとも３つのサービス・モデルと、少なくとも４つのデプロイメント・モデルとを含み得る。

特徴は以下の通りである。

オンデマンド・セルフ・サービス：クラウド・コンシューマは、サービスのプロバイダとの人的な対話を必要とせずに、必要に応じて自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング能力を一方的にプロビジョニングすることができる。

ブロード・ネットワーク・アクセス：能力はネットワークを介して利用することができ、異種のシンまたはシック・クライアント・プラットフォーム（たとえば、携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準的なメカニズムを介してアクセスされる。

リソース・プーリング：プロバイダのコンピューティング・リソースをプールして、様々な物理リソースおよび仮想リソースが需要に応じて動的に割り当ておよび再割り当てされるマルチ・テナント・モデルを使用して複数のコンシューマにサービス提供する。一般にコンシューマは、提供されるリソースの正確な位置に対して何もできず、知っているわけでもないが、より高い抽象化レベル（たとえば、国、州、またはデータセンターなど）では位置を特定可能であり得るという点で位置非依存の感覚がある。

迅速な弾力性：能力を迅速かつ弾力的に、場合によっては自動的にプロビジョニングして素早くスケール・アウトし、迅速に解放して素早くスケール・インすることができる。コンシューマにとって、プロビジョニング可能な能力は無制限であるように見えることが多く、任意の時間に任意の数量で購入することができる。

測定されるサービス：クラウド・システムは、サービスのタイプ（たとえば、ストレージ、処理、帯域幅、およびアクティブ・ユーザ・アカウント）に適したある抽象化レベルでの計量機能を活用して、リソースの使用を自動的に制御し、最適化する。リソース使用量を監視、管理、および報告して、利用されるサービスのプロバイダおよびコンシューマの両方に透明性を提供することができる。

サービス・モデルは以下の通りである。

ソフトウェア・アズ・ア・サービス（ＳａａＳ：Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、クラウド・インフラストラクチャ上で動作するプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザ（たとえば、ウェブ・ベースの電子メール）などのシン・クライアント・インターフェースを介して様々なクライアント・デバイスからアクセス可能である。コンシューマは、限定されたユーザ固有のアプリケーション構成設定を可能性のある例外として、ネットワーク、サーバ、オペレーティング・システム、ストレージ、さらには個々のアプリケーション機能を含む、基盤となるクラウド・インフラストラクチャを管理も制御もしない。

プラットフォーム・アズ・ア・サービス（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、コンシューマが作成または取得したアプリケーションをクラウド・インフラストラクチャ上にデプロイすることである。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む、基盤となるクラウド・インフラストラクチャを管理も制御もしないが、デプロイされたアプリケーションおよび場合によってはアプリケーション・ホスティング環境構成を制御する。

インフラストラクチャ・アズ・ア・サービス（ＩａａＳ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをコンシューマがデプロイして動作させることが可能な、処理、ストレージ、ネットワーク、および他の基本的なコンピューティング・リソースをプロビジョニングすることである。コンシューマは、基盤となるクラウド・インフラストラクチャを管理も制御もしないが、オペレーティング・システム、ストレージ、デプロイされたアプリケーションを制御し、場合によっては選択したネットワーキング・コンポーネント（たとえば、ホスト・ファイアウォール）を限定的に制御する。

デプロイメント・モデルは以下の通りである。

プライベート・クラウド：クラウド・インフラストラクチャは組織専用に運用される。これは組織または第三者によって管理され得、構内または構外に存在し得る。

コミュニティ・クラウド：クラウド・インフラストラクチャはいくつかの組織によって共有され、共通の懸念（たとえば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンスの考慮事項など）を有する特定のコミュニティをサポートする。これは組織または第三者によって管理され得、構内または構外に存在し得る。

パブリック・クラウド：クラウド・インフラストラクチャは、一般大衆または大規模な業界団体に対して利用可能にされ、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままであるが、データおよびアプリケーションの移植性を可能にする標準化技術または独自技術（たとえば、クラウド間の負荷分散のためのクラウド・バースティング）によって結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）を合成したものである。

クラウド・コンピューティング環境は、ステートレス性、低結合性、モジュール性、および意味論的相互運用性に重点を置いたサービス指向型である。クラウド・コンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。

ここで図１を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示のように、クラウド・コンピューティング環境５０は１つまたは複数のクラウド・コンピューティング・ノード１０を含み、これらを使用して、たとえば、パーソナル・デジタル・アシスタント（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）もしくは携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはそれらの組み合わせなどの、クラウド・コンシューマによって使用されるローカル・コンピューティング・デバイスが通信し得る。ノード１０は相互に通信し得る。これらは、たとえば、上述のプライベート、コミュニティ、パブリック、もしくはハイブリッド・クラウド、またはそれらの組み合わせなどの１つまたは複数のネットワークにおいて、物理的または仮想的にグループ化され得る（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを維持する必要がない、インフラストラクチャ・アズ・ア・サービス、プラットフォーム・アズ・ア・サービス、またはソフトウェア・アズ・ア・サービス、あるいはそれらの組み合わせを提供することが可能になる。図１に示したコンピューティング・デバイス５４Ａ～Ｎのタイプは例示的なものにすぎないことが意図されており、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意のタイプのネットワークまたはネットワーク・アドレス指定可能接続（たとえば、Ｗｅｂブラウザを使用）あるいはその両方を介して任意のタイプのコンピュータ化デバイスと通信できることを理解されたい。

ここで図２を参照すると、クラウド・コンピューティング環境５０（図１）によって提供される機能的抽象化レイヤのセットが示されている。図２に示したコンポーネント、レイヤ、および機能は例示的なものにすぎないことが意図されており、本発明の態様はこれらに限定されないことを事前に理解されたい。図示のように、以下のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例には、メインフレーム６１、ＲＩＳＣ（縮小命令セット・コンピュータ）アーキテクチャ・ベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびにネットワークおよびネットワーキング・コンポーネント６６が含まれる。いくつかの態様では、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化レイヤ７０は抽象化レイヤを提供し、抽象化レイヤから、仮想エンティティの以下の例、すなわち、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５が提供され得る。

一例では、管理レイヤ８０は、下記の機能を提供し得る。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソースおよび他のリソースの動的調達を提供する。計量および価格決定８２は、クラウド・コンピューティング環境内でリソースが利用されたときの費用追跡と、これらのリソースの消費に対する会計または請求とを提供する。一例では、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含み得る。セキュリティは、クラウド・コンシューマおよびタスクの同一性検証だけでなく、データおよび他のリソースに対する保護も提供する。ユーザ・ポータル８３は、コンシューマおよびシステム管理者にクラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理８４は、要求されたサービス・レベルが満たされるような、クラウド・コンピューティング・リソースの割り当ておよび管理を提供する。サービス・レベル合意（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）の計画および履行８５は、ＳＬＡに従って将来要求されると予想されるクラウド・コンピューティング・リソースの事前手配および調達を提供する。

ワークロード・レイヤ９０は、クラウド・コンピューティング環境が利用され得る機能性の例を提供する。このレイヤから提供され得るワークロードおよび機能の例は、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育配信９３、データ分析処理９４、取引処理９５、およびワークロード実施９６、を含む。

ここで図３を参照すると、クラウド・コンピューティング・ノードの一例の概略図が示されている。クラウド・コンピューティング・ノード１０は、適切なクラウド・コンピューティング・ノードの一例に過ぎず、本明細書に記載の本発明の態様の使用または機能性の範囲に関するいかなる制限を示唆することも意図するものではない。いずれにしても、クラウド・コンピューティング・ノード１０は、上記の機能性のいずれをも実装するまたは実行するあるいはその両方を行うことが可能である。

クラウド・コンピューティング・ノード１０には、コンピュータ・システム／サーバ１２が存在し、これは、他の多くの汎用または専用のコンピューティング・システム環境または構成で動作可能である。コンピュータ・システム／サーバ１２での使用に適し得るよく知られているコンピューティング・システム、環境、または構成、あるいはそれらの組み合わせの例には、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベースのシステム、セット・トップ・ボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムもしくはデバイスのいずれか含む分散クラウド・コンピューティング環境などが含まれるが、これらに限定されない。

コンピュータ・システム／サーバ１２は、コンピュータ・システムによって実行されるプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的なコンテキストで説明し得る。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造などが含まれ得る。コンピュータ・システム／サーバ１２は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散クラウド・コンピューティング環境において実施され得る。分散クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ・デバイスを含むローカルおよびリモート両方のコンピュータ・システム記憶媒体に配置され得る。

図３に示すように、クラウド・コンピューティング・ノード１０内のコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形態で示している。コンピュータ・システム／サーバ１２のコンポーネントは、１つまたは複数のプロセッサまたは処理ユニット１６と、システム・メモリ２８と、システム・メモリ２８を含む様々なシステム・コンポーネントをプロセッサ１６に結合するバス１８とを含み得るが、これらに限定されない。

バス１８は、メモリ・バスまたはメモリ・コントローラ、ペリフェラル・バス、アクセラレーテッド・グラフィックス・ポート、および様々なバス・アーキテクチャのいずれかを使用するプロセッサまたはローカル・バスを含む、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ：Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ：Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ：Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ビデオ・エレクトロニクス規格協会（ＶＥＳＡ：Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカル・バス、および周辺機器相互接続（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。

コンピュータ・システム／サーバ１２は、典型的には、様々なコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ１２によってアクセス可能な任意の利用可能な媒体であり得、揮発性および不揮発性の媒体、取り外し可能および取り外し不可能な媒体の両方を含む。

システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）３０またはキャッシュ・メモリ３２あるいはその両方などの、揮発性メモリの形態のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１２は、他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ・システム記憶媒体をさらに含み得る。単なる例として、取り外し不可能な不揮発性の磁気媒体（図示しない、典型的には「ハード・ドライブ」と呼ばれるもの）に読み書きするためのストレージ・システム３４を設けることができる。図示していないが、取り外し可能な不揮発性の磁気ディスク（たとえば、「フレキシブル・ディスク」）に読み書きするための磁気ディスク・ドライブと、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、または他の光学媒体などの取り外し可能な不揮発性の光学ディスクに読み書きするための光学ディスク・ドライブと、を設けることができる。そのような例では、それぞれを、１つまたは複数のデータ・メディア・インターフェースによってバス１８に接続することができる。以下でさらに図示および説明するように、メモリ２８は、本発明の態様の機能を実行するように構成されるプログラム・モジュールのセット（たとえば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含み得る。

プログラム・モジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０は、限定ではなく例として、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データと同様に、システム・メモリ２８に記憶され得る。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データまたはそれらの何らかの組み合わせのそれぞれは、ネットワーキング環境の一実装形態を含み得る。プログラム・モジュール４２は、一般に、本明細書に記載の本発明の態様の機能または方法論あるいはその両方を実行する。

コンピュータ・システム／サーバ１２はまた、キーボード、ポインティング・デバイス、ディスプレイ２４などの１つまたは複数の外部デバイス１４、ユーザがコンピュータ・システム／サーバ１２とやりとりすることを可能にする１つまたは複数のデバイス、またはコンピュータ・システム／サーバ１２が１つまたは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（たとえば、ネットワーク・カード、モデムなど）、あるいはそれらの組み合わせと通信し得る。そのような通信は、入力／出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インターフェース２２を介して行うことができる。またさらに、コンピュータ・システム／サーバ１２は、ネットワーク・アダプタ２０を介して、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、またはパブリック・ネットワーク（たとえば、インターネット）、あるいはそれらの組み合わせなどの、１つまたは複数のネットワークと通信することができる。図示のように、ネットワーク・アダプタ２０は、バス１８を介してコンピュータ・システム／サーバ１２の他のコンポーネントと通信する。図示していないが、他のハードウェア・コンポーネントまたはソフトウェア・コンポーネントあるいはその両方を、コンピュータ・システム／サーバ１２と併用できることを理解されたい。例には、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが含まれるが、これらに限定されない。

ここで図４を参照すると、一態様によるストレージ・システム４００が示されている。図４に示す要素の一部は、様々な態様に応じて、ハードウェアまたはソフトウェアあるいはその両方として実装され得ることに留意されたい。ストレージ・システム４００は、少なくとも１つの上位ストレージ階層４０２および少なくとも１つの下位ストレージ階層４０６上の複数の媒体と通信するためのストレージ・システム・マネージャ４１２を含み得る。上位ストレージ階層（複数可）４０２は、好ましくは、１つまたは複数のランダム・アクセスおよび／またはダイレクト・アクセス媒体４０４、たとえば、ハード・ディスク・ドライブ（ＨＤＤ：ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ）内のハード・ディスク、不揮発性メモリ（ＮＶＭ：ｎｏｎｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、ソリッド・ステート・ドライブ（ＳＳＤ：ｓｏｌｉｄ ｓｔａｔｅ ｄｒｉｖｅ）内のソリッド・ステート・メモリ、フラッシュ・メモリ、ＳＳＤアレイ、フラッシュ・メモリ・アレイなど、ならびに／あるいは本明細書に記載しているか、または当技術分野で知られているその他のものを含み得る。下位ストレージ階層（複数可）４０６は、好ましくは、１つまたは複数のより低性能な記憶媒体４０８を含み得、これには、順次アクセス媒体、たとえば、テープ・ドライブ内の磁気テープおよび／または光メディア、より低速なアクセスのＨＤＤ、より低速なアクセスのＳＳＤなど、ならびに／あるいは本明細書に記載しているか、または当技術分野で知られているその他のものが含まれる。１つまたは複数の追加のストレージ階層４１６は、システム４００の設計者によって望まれるストレージ・メモリ媒体の任意の組み合わせを含み得る。また、上位ストレージ階層４０２または下位ストレージ階層４０６あるいはその両方のいずれかは、ストレージ・デバイスまたは記憶媒体あるいはその両方の何らかの組み合わせを含み得る。

ストレージ・システム・マネージャ４１２は、図４に示すように、ストレージ・エリア・ネットワーク（ＳＡＮ：ｓｔｏｒａｇｅ ａｒｅａ ｎｅｔｗｏｒｋ）などのネットワーク４１０、または他の何らかの適切なネットワーク・タイプを介して、上位ストレージ階層（複数可）４０２および下位ストレージ階層（複数可）４０６上の記憶媒体４０４、４０８と通信し得る。ストレージ・システム・マネージャ４１２はまた、ストレージ・システム・マネージャ４１２の一部である場合もそうでない場合もあるホスト・インターフェース４１４を介して、１つまたは複数のホスト・システム（図示せず）と通信し得る。ストレージ・システム・マネージャ４１２、またはストレージ・システム４００の他の任意のコンポーネント、あるいはその両方は、ハードウェアまたはソフトウェアあるいはその両方で実装され得、当技術分野で知られているタイプのコマンドを実行するためのプロセッサ（図示せず）、たとえば、中央処理装置（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）などを利用し得る。当然ながら、本説明を読めば当業者には明らかであるように、ストレージ・システムの任意の構成が使用され得る。

より多くの態様では、ストレージ・システム４００は、任意の数のデータ・ストレージ階層を含み得、各ストレージ階層内に同じまたは異なるストレージ・メモリ媒体を含み得る。たとえば、各データ・ストレージ階層は、同じタイプのストレージ・メモリ媒体、たとえば、ＨＤＤ、ＳＳＤ、順次アクセス媒体（テープ・ドライブ内のテープ、光ディスク・ドライブ内の光ディスクなど）、ダイレクト・アクセス媒体（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭなど）、またはメディア・ストレージ・タイプの任意の組み合わせを含み得る。１つのそのような構成では、上位ストレージ階層４０２は、より高性能なストレージ環境にデータを記憶するための大多数のＳＳＤ記憶媒体を含み得、下位ストレージ階層４０６および追加のストレージ階層４１６を含む残りのストレージ階層は、より低性能なストレージ環境にデータを記憶するための、ＳＳＤ、ＨＤＤ、テープ・ドライブなどの任意の組み合わせを含み得る。このようにして、より頻繁にアクセスされるデータ、優先順位の高いデータ、より迅速にアクセスされる必要があるデータなどは、上位ストレージ階層４０２に記憶され得、これらの属性のうちの１つを有さないデータは、下位ストレージ階層４０６を含む追加のストレージ階層４１６に記憶され得る。当然ながら、当業者は、本説明を読めば、本明細書に提示する態様に従って、異なる記憶方式で実装される記憶媒体タイプの他の多くの組み合わせを考案し得る。

いくつかの態様によれば、ストレージ・システム（４００など）は、データ・セットを開く要求を受信するように構成されるロジックと、要求されたデータ・セットが階層型データ・ストレージ・システム４００の下位ストレージ階層４０６内の複数の関連付けられた部分に記憶されているか否かを判定するように構成されるロジックと、要求されたデータ・セットの各関連付けられた部分を階層型データ・ストレージ・システム４００の上位ストレージ階層４０２に移動させるように構成されるロジックと、階層型データ・ストレージ・システム４００の上位ストレージ階層４０２上で関連付けられた部分から要求されたデータ・セットを組み立てるように構成されるロジックと、を含み得る。

当然ながら、このロジックは、様々な態様によれば、任意のデバイスもしくはシステムまたはその両方における方法として、あるいはコンピュータ・プログラム製品として実装され得る。

ここで図５を参照すると、一態様による方法５００のフローチャートが示されている。方法５００は本発明に従って、様々な態様で、とりわけ図１～図４に示す環境のいずれかにおいて実行され得る。当然ながら、本説明を読めば当業者に理解されるように、図５に具体的に記載したものよりも多いまたは少ない動作が方法５００に含まれ得る。

方法５００の各ステップは、動作環境の任意の適切な構成要素によって実行され得る。たとえば、様々な態様において、方法５００は、１つまたは複数のサーバ、コンピュータ、あるいは１つまたは複数のプロセッサを内部に有する他の何らかのデバイスによって部分的または全体的に実行され得る。方法５００の１つまたは複数のステップを実行するために、ハードウェアまたはソフトウェアあるいはその両方で実装され、好ましくは少なくとも１つのハードウェア・コンポーネントを有するプロセッサ、たとえば、処理回路（複数可）、チップ（複数可）、またはモジュール（複数可）、あるいはそれらの組み合わせが任意のデバイスで利用され得る。例示的なプロセッサには、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、それらの組み合わせ、または当技術分野で知られている他の任意の適切なコンピューティング・デバイスが含まれる。

図５に示すように、方法５００は動作５０２から開始し得、ここで複数のクラウド・ベンダーの特性が決定され、記憶される。一態様では、複数のクラウド・ベンダーのうちのそれぞれは、クラウドベースのサービス・プロバイダ（たとえば、クラウド・コンピューティング環境内に位置するサービス・プロバイダなど）を含み得る。他の態様では、複数のクラウド・ベンダーのうちのそれぞれは、計算処理、データ記憶などのサービスを提供し得る。たとえば、各クラウド・ベンダーは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａＳ）、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）などの１つまたは複数のサービスを提供し得る。

さらに、一態様では、複数のクラウド・ベンダーのうちのそれぞれの特性は、クラウド・ベンダーを分析することによって決定され得る。他の態様では、分析することは、クラウド・ベンダーのスキャンを実行するために、１つまたは複数の能力または費用あるいはその両方のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることを含み得る。さらに他の態様では、分析することは、各クラウド・ベンダーのレポート、傾向、脆弱性、セキュリティ問題などのうちの１つまたは複数を特定するために、１つまたは複数のパブリックおよびプライベート・セキュリティ・データベース情報を収集および解析することを含み得る。

さらに、一態様では、分析することは、クラウド・ベンダーのうちの１つまたは複数に関する既存のセキュリティ問題に対する既存の解決方法を決定するために、１つまたは複数の解決策データベースを解析することを含み得る。他の態様では、分析することは、クラウド・ベンダーに関して収集されたレビュー情報に基づいて、クラウド・ベンダーのそれぞれに関する１つまたは複数の実行可能性要因を推定することを含み得る。たとえば、実行可能性要因は、サービス性、ネット・プロモーター・スコア（ＮＰＳ）、ユーザ・レビュー、パフォーマンス・ベンチマーク、チューニングの柔軟性などのうちの１つまたは複数を含み得る。

またさらに、一態様では、各クラウド・ベンダーについて、特性は、クラウド・ベンダーの能力、クラウド・ベンダーの実施の費用、クラウド・ベンダーによって実現されるセキュリティ・レベル、クラウド・ベンダーに関連する実行可能性要因などを含み得る。他の態様では、各特性のレベルを決定するために、各特性は１つまたは複数の事前定義された閾値と比較され得る。

たとえば、クラウド・ベンダーによって実現されるセキュリティの程度が第１の閾値を超えている場合、クラウド・ベンダーのセキュリティ特性に第１のレベル（たとえば、高レベル）が割り当てられ得る。他の例では、クラウド・ベンダーによって実現されるセキュリティの程度が第１の閾値よりも低いが第２の閾値を超えている場合、クラウド・ベンダーのセキュリティ特性に第２のレベル（たとえば、中レベル）が割り当てられ得る。さらに他の例では、クラウド・ベンダーによって実現されるセキュリティの程度が第２の閾値よりも低い場合、クラウド・ベンダーのセキュリティ特性に第３のレベル（たとえば、低レベル）が割り当てられ得る。

また、一態様では、特性は、ワークロードの実施中にクラウド・ベンダーによって提供されるセキュリティのレベルを示し得る各クラウド・ベンダーのサイバー・セキュリティ特性を含み得る。他の態様では、特性は、ワークロードの実施中にクラウド・ベンダーによって提供されるレジリエンシー（たとえば、クラッシュ保護、マルウェア保護、冗長データ保護など）のレベルを示し得る各クラウド・ベンダーのサイバー・レジリエンシー特性を含み得る。たとえば、各クラウド・ベンダーのサイバー・セキュリティ特性およびサイバー・レジリエンシー特性は、そのクラウド・ベンダーに対して特定される他の特性から導出され得る。

さらに、一態様では、クラウド・ベンダーの識別子が、特性のテキスト説明、各特性に関連する数値評価などのうちの１つまたは複数に関連付けて記憶され得る。他の態様では、特性は、１つまたは複数のストレージ・デバイス、クラウド・ストレージ環境などに記憶され得る。

さらに、方法５００は動作５０４に進み得、ここでワークロードが複数の論理ステージに分割される。一態様では、ワークロードは、必要な入力（たとえば、ワークロードによって分析または操作あるいはその両方が行われるデータの１つまたは複数のインスタンスなど）を含み得る。他の態様では、ワークロードは、ワークロードの一部として実行される１つまたは複数の計算（たとえば、所定の入力に対して実行される１つまたは複数の計算アルゴリズムなど）を含み得る。さらに他の態様では、ワークロードは、ワークロードを実行した結果として出力される１つまたは複数の結果（たとえば、出力データなど）を含み得る。

またさらに、一態様では、ワークロードは、１つまたは複数の一般化された処理パイプライン・ステージを含み得る。他の態様では、ワークロード内のデータ入力および出力のポイント、ならびに入力に関連する依存関係を特定するために、ワークロードが解析され得る。たとえば、ワークロード内のデータ入力の所与のインスタンスについて、データ入力が同じワークロード内から出力されるデータに依存するか否かが判定され得る。

また、一態様では、ワークロード内のデータ入力および出力のインスタンスを予測するために、ワークロードのソース・コードがスキャンされ得る。たとえば、これは、ワークロードの分割／論理ステージの作成の精度を高めるために行われ得る。他の態様では、ワークロードは次いで論理ステージに分割され得、各論理ステージはワークロード内の他の論理ステージに依存しないデータ入力を含む。

さらに、一態様では、ワークロードを論理ステージに分割する場合に、所定の入力（たとえば、所定のステージを識別する入力など）が参照され得る。他の態様では、各論理ステージを解析して、論理ステージ内で１つまたは複数の非並列タスク（たとえば、１つまたは複数のデータまたはリソースの依存関係などのために並列に実行できないタスク）が実行されるか否かを判定し得る。たとえば、論理ステージが非並列タスクを含むと判定したことに応答して、論理ステージは、それぞれが非並列タスクのうちの１つを含む複数のより小さい論理ステージに分割され得る。

さらに、方法５００は動作５０６に進み得、ここで複数の論理ステージのうちのそれぞれの特性が決定される。一態様では、ステージ内の入力、出力、および中間結果に基づいて各論理ステージの複雑性が決定され得る。たとえば、ステージ内の入力、出力、および中間結果を過去のワークロード・ステージと比較して、ステージの複雑性を決定し得る。

またさらに、一態様では、ステージの複雑性に基づいて各論理ステージの特性が決定され得る。たとえば、特性には、推定実行時間、１つまたは複数の所望のパフォーマンス特性、１つまたは複数のセキュリティ要件、１つまたは複数のリソース要件、１つまたは複数のサイバー・レジリエンシー要件などのうちの１つまたは複数が含まれ得る。

また、一態様では、複数のリソースのうちのそれぞれについて、全ての論理ステージの第１のランク付けが決定され得る。たとえば、リソースには、コンピュート・リソース、ストレージ・リソース、ネットワーク・リソース、外部リソースなどのうちの１つまたは複数が含まれ得る。他の例では、コンピュート・リソースの場合、第１の論理ステージは、多くの計算が実行されることを必要とし得、第２の論理ステージは、より少ない量の計算が実行されることを必要とし得る。さらに他の例では、それに応じて、第１の論理ステージは、コンピュート・リソースに関して第２の論理ステージよりも上位にランク付けされ得る。

さらに、一態様では、第１のランク付けに基づいて、サイバー・セキュリティ要因およびサイバー・レジリエンシー要因に関して、全ての論理ステージの第２のランク付けが実行され得る。たとえば、この第２のランク付けにより、実施中に論理ステージによって必要とされるセキュリティのレベルを示す各論理ステージのサイバー・セキュリティ・ランキングが決定され得る。他の例では、この第２のランク付けにより、実施中に論理ステージによって必要とされるレジリエンシー（たとえば、クラッシュ保護、マルウェア保護、冗長データ保護など）のレベルを示す各論理ステージのサイバー・レジリエンシー・ランキングも決定され得る。

さらに、方法５００は動作５０８に進み得、ここで、複数の論理ステージのうちのそれぞれについて、複数のクラウド・ベンダーの特性と論理ステージの特性との比較に基づいて、論理ステージが複数のクラウド・ベンダーのうちの１つに割り当てられる。一態様では、各論理ステージについて、論理ステージの要件（たとえば、処理要件、ストレージ要件、帯域幅要件、サイバー・セキュリティ要件、サイバー・レジリエンシー要件など）を満たすことが可能な１つまたは複数のクラウド・ベンダーを決定するために、ステージの特性が複数のクラウド・ベンダーのうちのそれぞれの特性と比較され得る。

またさらに、一態様では、論理ステージをクラウド・ベンダーに割り当てることは、クラウド・ベンダーが論理ステージに必要な入力を受け取り、論理ステージに必要な操作を実行し、論理ステージに必要なデータを出力するように、論理ステージをクラウド・ベンダーにマッピングすること／割り当てることを含み得る。他の態様では、割り当ては過去のパフォーマンス・データに基づいて調整され得る。たとえば、所定のクラウド・ベンダーが、現在の論理ステージと所定のレベルの類似性を有する過去の論理ステージに関して所定の閾値を上回るパフォーマンスを提供した場合、その所定のクラウド・ベンダーが現在の論理ステージに割り当てられ得る。

また、一態様では、（たとえば、グラフィカル・ユーザ・インターフェース（ＧＵＩ：ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）などを使用して）クラウド・ベンダーへの各論理ステージのマッピングが１人または複数のユーザに提示され得る。たとえば、ユーザは、ＧＵＩ内に提供される選択肢を使用して、論理ステージを確認、調整、または実施、あるいはそれらの組み合わせを行い得る。

さらに、一態様では、ユーザ／エンティティの優先順位に基づいて各論理ステージ内のリソース割り当てが調整され得る。たとえば、過去のワークロード内で実行された過去のタスクに統計的学習を実行して、過去のタスクに必要な１つまたは複数のリソースを決定し得る。これらの過去のタスクを論理ステージ内の現在のタスクと比較して、そのタスクに必要なリソースを決定し得る。

たとえば、論理ステージ内で第１のエンティティによって実行される第１のタスクは、その論理ステージに割り当てられたクラウド・ベンダー内の所定のリソース（たとえば、高速ストレージなど）の使用を必要とし得る。他の例では、論理ステージ内で第２のエンティティによって実行される第２のタスクもまた、その論理ステージに割り当てられたクラウド・ベンダー内のその所定のリソースの使用を必要とし得る。さらに他の例では、第１のエンティティが第２のエンティティよりも高い優先順位を有すると判定したことに応答して、第１のエンティティに所定のリソースが割り当てられ得、第２のエンティティに他のリソース（たとえば、中速ストレージなど）が割り当てられ得る。

さらに、一態様では、各タスク中にデータが必要なクラウド・ベンダーに配置されるようにするために、ワークロードの実施中にクラウド・ベンダー間でデータ移行が実行され得る。たとえば、最初に高セキュリティのクラウド・ベンダーで生成されたデータは、後で操作するために低セキュリティのクラウド・ベンダーに移行され得るが、そのようなデータを安全に記憶するために、そのような操作が実行された後に高セキュリティのクラウド・ベンダーに移行し戻され得る。これにより、ライフ・サイクル管理が実施され、所定のデータのセキュリティが確保され得る。

このようにして、ワークロード内の各論理ステージの実施は、最適なクラウド・ベンダーに送られて実施され得る。これにより、各論理ステージを実行するために必要なリソース（たとえば、コンピューティング・リソース、ストレージ・リソース、セキュリティ・リソースなど）の量が減少し得、ひいては、ワークロードを実施（たとえば、実行など）する１つまたは複数のコンピューティング・システムのパフォーマンスが向上し得る。さらに、各論理ステージのサイバー・レジリエンシーが確保され得、これにより、システムの機能停止またはマルウェアによって失われるデータ／計算作業の量が減少し得、ひいては、ワークロードを実施するコンピューティング・システムのパフォーマンスも向上し得る。

ここで図６を参照すると、一態様による、クラウド・ベンダーをスキャンするための方法６００のフローチャートが示されている。方法６００は本発明に従って、様々な態様で、とりわけ図１～図４に示す環境のいずれかにおいて実行され得る。当然ながら、本説明を読めば当業者に理解されるように、図６に具体的に記載したものよりも多いまたは少ない動作が方法６００に含まれ得る。

方法６００の各ステップは、動作環境の任意の適切な構成要素によって実行され得る。たとえば、様々な態様において、方法６００は、１つまたは複数のサーバ、コンピュータ、あるいは１つまたは複数のプロセッサを内部に有する他の何らかのデバイスによって部分的または全体的に実行され得る。方法６００の１つまたは複数のステップを実行するために、ハードウェアまたはソフトウェアあるいはその両方で実装され、好ましくは少なくとも１つのハードウェア・コンポーネントを有するプロセッサ、たとえば、処理回路（複数可）、チップ（複数可）、またはモジュール（複数可）、あるいはそれらの組み合わせが任意のデバイスで利用され得る。例示的なプロセッサには、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、それらの組み合わせ、または当技術分野で知られている他の任意の適切なコンピューティング・デバイスが含まれる。

図６に示すように、方法６００は動作６０２から開始し得、ここで、クラウド・ベンダーによって提供されるセキュリティおよびレジリエンシー特徴がスキャンされる。さらに、方法６００は動作６０４に進み得、ここで、能力および費用見積アプリケーション・プログラミング・インターフェース（ＡＰＩ）がクラウド・ベンダーに対して実行される。

さらに、方法６００は動作６０６に進み得、ここで、クラウド・ベンダーが動作させる全てのアプリケーションに関するレポート、脆弱性に関連する傾向、セキュリティ情報、攻撃情報、および脅威情報を収集するために、パブリックおよびプライベート・ナレッジ・ベースにわたってスキャンが実行される。さらに、方法６００は動作６０８に進み得、ここで、セキュリティ・データベース（たとえば、ＮＩＳＴなど）内で、特定された脆弱性に対する特定された解決策候補が解析される。

またさらに、方法６００は動作６１０に進み得、ここで、クラウド・ベンダーが動作させる全てのアプリケーションに関して、レビュー共有クラウド・プラットフォームおよびコミュニティに登録されたフィードバックに基づいて、クラウド・ベンダーの実行可能性要因が推定される。

このようにして、クラウド・ベンダーの特性が特定され得る。

ここで図７を参照すると、一態様による、ワークロード要件を特定するための方法７００のフローチャートが示されている。方法７００は本発明に従って、様々な態様で、とりわけ図１～図４に示す環境のいずれかにおいて実行され得る。当然ながら、本説明を読めば当業者に理解されるように、図７に具体的に記載したものよりも多いまたは少ない動作が方法７００に含まれ得る。

方法７００の各ステップは、動作環境の任意の適切な構成要素によって実行され得る。たとえば、様々な態様において、方法７００は、１つまたは複数のサーバ、コンピュータ、あるいは１つまたは複数のプロセッサを内部に有する他の何らかのデバイスによって部分的または全体的に実行され得る。方法７００の１つまたは複数のステップを実行するために、ハードウェアまたはソフトウェアあるいはその両方で実装され、好ましくは少なくとも１つのハードウェア・コンポーネントを有するプロセッサ、たとえば、処理回路（複数可）、チップ（複数可）、またはモジュール（複数可）、あるいはそれらの組み合わせが任意のデバイスで利用され得る。例示的なプロセッサには、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、それらの組み合わせ、または当技術分野で知られている他の任意の適切なコンピューティング・デバイスが含まれる。

図７に示すように、方法７００は動作７０２から開始し得、ここで、ワークロードに含まれるワークロード・ステージが識別されるか、または既存のパイプライン・ステージへの修正が提案される。さらに、方法７００は動作７０４に進み得、ここで、入力および出力ならびに子／親機能（ｆｕｎｃｔｉｏｎ）に基づいてワークロードが独立したステージに分割される。さらに、方法７００は動作７０６に進み得、ここで、手動入力が受け取られ、そのような入力はワークロードの機密性要件に関連する。

またさらに、方法７００は動作７０８に進み得、ここで、独立したステージを分析して、各ステージに存在する非並列タスクに基づいて実行時間に関するパイプラインの最適化を検証する。また、方法７００は動作７１０に進み得、ここで、提案されたステージの分割が、元の独立したステージと共に提示され、ユーザ選択される。

さらに、方法７００は動作７１２に進み得、ここで、ワークロード・スキャンに基づいて、各ステージのサイバー・セキュリティおよびレジリエンシー特徴が推定される。さらに、方法７００は動作７１４に進み得、ここで、各ステージによって要求される推定リソースに基づいて、予想利用時間、致命性（ｃｒｉｔｉｃａｌｎｅｓｓ）、および重要性に基づいてリソース間でランク付けが実行される。またさらに、方法７００は動作７１６に進み得、ここで、ランク比較に基づいて、各ステージにマッチするクラウド・ベンダーが決定される。

このようにして、ワークロードに対して作成されたステージにクラウド・ベンダーがマッチングされ得る。

ここで図８を参照すると、一態様による、マルチテナント・ワークロード管理エンジンを実装するための方法８００のフローチャートが示されている。方法８００は本発明に従って、様々な態様で、とりわけ図１～図４に示す環境のいずれかにおいて実行され得る。当然ながら、本説明を読めば当業者に理解されるように、図８に具体的に記載したものよりも多いまたは少ない動作が方法８００に含まれ得る。

方法８００の各ステップは、動作環境の任意の適切な構成要素によって実行され得る。たとえば、様々な態様において、方法８００は、１つまたは複数のサーバ、コンピュータ、あるいは１つまたは複数のプロセッサを内部に有する他の何らかのデバイスによって部分的または全体的に実行され得る。方法８００の１つまたは複数のステップを実行するために、ハードウェアまたはソフトウェアあるいはその両方で実装され、好ましくは少なくとも１つのハードウェア・コンポーネントを有するプロセッサ、たとえば、処理回路（複数可）、チップ（複数可）、またはモジュール（複数可）、あるいはそれらの組み合わせが任意のデバイスで利用され得る。例示的なプロセッサには、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、それらの組み合わせ、または当技術分野で知られている他の任意の適切なコンピューティング・デバイスが含まれる。

図８に示すように、方法８００は動作８０２から開始し得、ここで、マルチテナント環境ワークロード管理プラットフォーム内で、ユーザの詳細を使用して、ユーザによって解決される問題およびタスクの性質を定義する。さらに、方法８００は動作８０４に進み得、ここで、ユーザ・プロファイルに対して決定されたワークロードに基づいて、ワークロード計算アルゴリズムの要件が特定される。さらに、方法８００は動作８０６に進み得、ここで、要件に基づいて、タスクの各ステージにクラウド・ベンダーがマッチングされる。

サイバー・レジリエンシーに基づいてリソースを管理するためのマルチクラウド・オーケストレーション、ワークロード管理エンジンの改善

マルチクラウド／ハイブリッド・オーケストレーション／マネージャ

マルチクラウド・オーケストレータは、複数のクラウド・リソースならびにオンプレミス・インフラストラクチャ間の相互接続およびインタラクションの管理に役立つ１つまたは複数のアプリケーションを含み得る。オーケストレーション・レイヤは、ビジネス要求およびワークロードをアプリケーション、データ、およびインフラストラクチャと調整し得る。オーケストレータは、自動化されたワークロード、プロビジョニング、および変更管理を通じてポリシーおよびサービス・レベルを定義するのに役立ち得る。オーケストレータは、各アプリケーションのニーズに基づいてスケール・アップまたはスケール・ダウンすることができる、アプリケーションに合わせたインフラストラクチャを作成し得る。オーケストレータはまた、消費の会計、計量、および支払取消を含む、リソース・プールの集中管理を提供し得る。

ワークロード管理エンジン

ワークロード管理エンジンは、既存の異種のＩＴリソースに作業を分散させることによって、より高速で、より信頼性の高いワークロード・パフォーマンスを発揮し、費用を削減する、共有されたスケーラブルな耐障害性のインフラストラクチャを作成し得る。エンジンは、負荷のバランスを取り、リソースを割り当て、それらのリソースへのアクセスを提供し得る。エンジンは、ジョブ要件を取得し、ジョブを実行するための最適なリソースを見つけ、ジョブの進捗を監視するリソース管理フレームワークを提供し得る。ジョブは、ホストの負荷およびサイトのポリシーに従って実行され得る。

サイバー・レジリエンシー

サイバー・レジリエンシーは、有害なサイバー・イベントが発生した場合でも意図した結果を継続的に配信するエンティティの能力を含み得る。サイバー・レジリエンス能力を必要とする可能性のあるエンティティには、ＩＴシステム、重要インフラストラクチャ、ビジネス・プロセス、組織、社会、および国民国家が含まれるが、これらに限定されない。有害なサイバー・イベントとは、ネットワーク化されたＩＴシステムならびに関連する情報およびサービスの可用性、完全性、または機密性に悪影響を与えるイベントである。これらのイベントは、意図的なもの（たとえば、サイバー攻撃）または意図的でないもの（たとえば、ソフトウェア更新の失敗）であり得、人間によって、または自然に、あるいはそれらの組み合わせで引き起こされ得る。

サイバー・レジリエンシーの１つの目的は、（たとえば、危機中またはセキュリティ侵害後に）通常の配信メカニズムに障害が発生した場合でも、意図した結果を継続的に配信するエンティティの能力を維持することである。この概念はまた、そのようなイベントの後に通常の配信メカニズムを復旧する能力、ならびに新たなリスクに直面した場合に必要に応じてこれらの配信メカニズムを継続的に変更または修正する能力を含む。データ・バックアップおよびディザスタ・リカバリ動作の実行は、配信メカニズムを復旧するプロセスの一部である。

コンポーザブル・インフラストラクチャ

コンポーザブル・インフラストラクチャは、物理的なコンピュート、ストレージ、およびネットワーク・ファブリック・リソースがサービスとして扱われるフレームワークを含み得る。コンポーザブル・インフラストラクチャでは、リソースが論理的にプールされるので、管理者は特定のソフトウェア・アプリケーションをサポートするためにハードウェアを物理的に構成する必要がない。代わりに、ソフトウェアの開発者は、ポリシーおよびサービス・プロファイルを使用して物理的なインフラストラクチャに関するアプリケーションの要件を定義し得、次いでソフトウェアは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）呼び出しを使用して、ベア・メタルで、仮想マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）として、またはコンテナとして、動作させる必要のあるインフラストラクチャを作成（構成）し得る。

一態様では、オーケストレーションおよびワークロード管理エンジンが従来のクラウド・オーケストレータ・プラットフォームと統合され得る。エンジンは、提供されたワークフローに必要なリソースを関係付け（ｅｎｇａｇｅ）ながら開始し得、関連するステージを識別し、ステージの特性を分析し、ステージごとに必要なサイバー・レジリエンシー特徴を推定し、それらの特徴を、複数のクラウドまたはオンプレミス・デコンポーザブル・インフラストラクチャ（ｏｎ－ｐｒｅｍｉｓｅ ｄｅｃｏｍｐｏｓａｂｌｅ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）によって提供される、事前に収集されたサイバー特徴と比較し、ステージごとにマッチするクラウドまたはオンプレミス・インフラストラクチャを決定し（必要に応じてセキュリティおよびパフォーマンスのチューニングを実行し）、リソースのライフ・サイクル管理を実行し得る。

一態様では、マルチテナント対応のオーケストレーションおよびワークロード管理エンジンが従来のクラウド・オーケストレータ・プラットフォームと統合され得る。ワークフロー入力が供給されるリソースをスピンアップしながら、エンジンは、（非並列タスク分析および依存ステージ分析に基づいて）関連するステージを自動識別し、（ステージに含まれるアルゴリズムの複雑性と、完了までの予想時間とに基づいて）ステージ特性を分析し、ステージごとに必要なサイバー・セキュリティおよびレジリエンシー特徴を推定し、これらを、複数のクラウドまたはオンプレミス・デコンポーザブル・インフラストラクチャによって提供される、事前に収集されたサイバー特徴と比較し、ステージごとにマッチするクラウドまたはオンプレミス・インフラストラクチャを決定し（また、必要に応じてセキュリティおよびパフォーマンスのチューニングを実行し）、リソースのライフ・サイクル管理（たとえば、デプロイメント、チューニング、移行、記憶、破棄など）を実行する。

１つの例示的なオーケストレーションおよびワークロード管理エンジンは以下を含む。

１．推奨クラウド・ベンダーによって提供されるサービスごとにセキュリティおよびレジリエンシー特徴を費用の関連付けと共にスキャンすること。

Ａ．クラウド・ベンダーによって提供されるサービスごとに能力ＡＰＩおよび費用見積ＡＰＩを実行することによって、スキャン・アクションが実行される。

Ｂ．パブリックおよびプライベート・セキュリティ・データベースにわたってスキャン・アクションを（アクセスの契約レベルに応じて）実行して、クラウド・ベンダーごとに提供されるアプリケーションごとに、最新のレポート、脆弱性に関連する傾向、セキュリティ、攻撃、脅威などを収集および解析する。また、スケジューラは、特定されたセキュリティ問題に関してＮＩＳＴなどのデータベースを解析することにより、解決策候補を特定する。

Ｃ．スキャン動作を実行して、クラウド・ベンダーごとに提供されるアプリケーションごとに、レビュー共有クラウド・プラットフォーム、コミュニティに登録されたフィードバック、開発者メール・スレッド、業界トレンド／調査レポートなどに基づいて、実行可能性要因（たとえば、サービス性、ネット・プロモーター・スコア（ＮＰＳ）、ユーザ・レビュー、ユーザビリティ、パフォーマンス・ベンチマーク、最適化された使用／チューニングの柔軟性など）を推定する。

スキャン結果は、以下の表１に示すスキーマなどのテーブルに記憶することができる。このテーブルは、ネットワーク、ＶＰＮ速度などの能力、およびＮＰＳ、チューニングなどの実行可能性要因などを含むように拡張され得る。

２．入力ワークフローに含まれるステージを自動識別すること、または入力済みのパイプライン・ステージへの修正を提案すること。

Ａ．自動識別は、ワークロード全体（入力、計算アルゴリズム（複数可）、および予想される出力）を解析し、それらを独立したステージに分割する（独立したステージは、入力がすぐに利用可能であり、またはより少ない子／機能を有する）アルゴリズムを含む。自動識別アルゴリズムは、入力ワークロードに関連する業界に関係する手動入力、機密性に関係する手動入力などを含み得る。

Ｂ．自動識別はまた、入力済みのパイプライン・ステージの分析を含む。各ステージに存在する非並列タスクを分析することにより、パイプラインが実行時間に関して最適化されているか否かを判定する。分析に基づいて、修正されたステージ分割を管理者に提案する（ここで、元のまたは修正されたステージ分割を選択してワークロードを実行する自由が提供される）。

３．ステージごとに必要なサイバー・セキュリティおよびレジリエンシー特徴を推定すること。

Ａ．サイバー・セキュリティおよびレジリエンシー特徴は、各ステージの計算アルゴリズムと、それらの予想される入力、出力、および中間結果とをスキャンして分析する。推定は、各ステージを、ワークロード管理プラットフォームを使用して実行された過去のワークロード・ステージと比較すると共に、各ステージを、デプロイメント中に入力済みの事前定義されたステージ・テンプレートと比較することに基づく（入力テンプレートは、調査研究を通じて得られるソフトウェア・メーカーの経験、ベータ版プログラム、および他の顧客から借りたワークロード・テンプレートなどに基づく）。

Ｂ．計算アルゴリズムの複雑性に基づいて、概算の実行時間が決定される。推定時間に基づいて、推定計算時間と（たとえば、この場合、ステージごとの計算あたりの費用が管理者によって入力されるか、または自動的に決定される）、ステージに含まれるタスクによって要求されるセキュリティ要件およびリソース（たとえば、ネットワーク、外部要因－ＷＡＮ速度、コンピュート、ストレージ）とにマッチする所望のパフォーマンス特性が決定される。

Ｃ．各ステージによって要求される推定リソースに基づいて、予想利用時間、リソースの致命性および入力の重要性、ならびにステージによって生成される出力に基づいて、リソース間でランク付けが実行される。たとえば、以下の表２に示すように、ステージＮは、機密出力を生成するか、または入力が一般的もしくは周知である多くの計算の後に出力を生成することが予想される。同様に、ステージ１は、最小限の計算で一般的な出力を生成することが予想され、オンプレミスのデータストアから供給される入力データを必要とする。

上記のランク付けに基づいて、提案したランク付けアルゴリズムは、以下の表３に示すように、サイバー・セキュリティおよびレジリエンシーに対してステージをランク付けする。

ワークロード管理プラットフォームは、（上記のステップ３で）算出されたランキングを、複数のクラウドまたはオンプレミス・デコンポーザブル・インフラストラクチャによって提供される、事前に収集されたサイバー特徴、レジリエンシー特徴などを含む（上記のステップ１からの）スキャン結果と比較し得る。ランク比較に基づいて、マッチするクラウドまたはオンプレミス・インフラストラクチャが各ステージにマッチングされ得る。

さらに、オーケストレーション・スキーマが、承認のためにユーザ（たとえば、管理者）に提示され得る。承認されると、提案したワークロード管理プラットフォームは、それぞれのクラウド内のリソースを要求し、セキュリティおよびパフォーマンスのチューニングを実行し（これには、オンプレミス・クラスタおよびクラウド間のＣＰＵ速度の差に適応するためのアプリケーションのチューニング、ならびにローカル・ネットワークおよびＷＡＮ接続間の速度の差の調整が含まれ得る）、リソースのライフ・サイクル管理（たとえば、安全なデプロイメント、チューニング、移行、安全な記憶、破棄など）を実行する。

図９は、１つの例示的な態様による、ディスプレイに出力される例示的な算出されたオーケストレーション・スキーマ９００を示している。図示のように、複数のステージ９０２Ａ～Ｃはそれぞれ、リソース、費用、クラウド・ベンダー、および実行時間の決定結果を含む。ステージ９０２Ａ～Ｃ間のデータ転送ボリューム９０４Ａ～Ｂの表示も提供されており、算出されたオーケストレーション・スキーマ９００を承諾９０６またはカスタマイズ９０８する選択肢も提供されている。

一態様では、ワークロード管理プラットフォームは、マルチテナント対応でもあり得る。たとえば、プラットフォームは、ユーザＩＤの詳細をランクまたは組織／部門の詳細と共に取得し、これらの詳細に基づいて、プラットフォームはユーザによって実行される問題／タスクの性質を推定する。たとえば、核研究の科学者が、ワークロード管理プラットフォームを利用し得る。アルゴリズムは、対応するユーザＩＤを「核科学者」として識別し得、ワークロードを核／原子のものとして識別し得る（これはスペクトル分析またはボルツマン分布などのアルゴリズムに対応するワークロードであり得る）。

同様に、同じワークロード管理プラットフォームが生物学の大学生によって共有され、使用され得る。提案したアルゴリズムは、対応するユーザＩＤを「生物学の学生」として識別し得、ワークロードを計算生物学のものとして識別し得る（これはシークエンシングまたはプロトン（ｐｒｏｔｏｎ）・モデル構築などのアルゴリズムに対応するワークロードであり得る）。それに応じて、核科学者は生物学の学生よりもコンピュート、ストレージ、および帯域幅に関して優先され得、その理由は、前者が後者よりも高い優先順位を有するためである。

ワークロード管理プラットフォームのアクセス許可が引き上げられ得、それによってシステムは、ユーザがデータを供給する予定のコンピュート・ソフトウェアまたはアルゴリズムのソース・コードをスキャンし得、そのようなコンピュート・ソフトウェアのコード・スキャンに基づいて、システムは入力／出力の性質を予測し得、同様に、最適化されたターゲット・クラウド・リソースを推定し、比較を実行してマルチクラウド・セキュリティ・スコアを算出し得る。ワークロード管理プラットフォームはまた、現在提供されているワークロード・パターンが過去にいずれかのクラウド・ベンダーによって既に実行されているか否かを特定し得、それがどれほどうまく機能したかを分析し得る。分析の結果に基づいて、ランク付けが改変される。

ワークロード管理プラットフォームはまた、ステージ／タスクごとに必要なデータの必要性を推定し得、ライフ・サイクル管理を実行し得る。たとえば、ワークロード管理プラットフォームは、（決定された最高ランクに基づいて）第１のクラウド・リソースを使用してワークロード・ステージの実行を開始し得る。しかしながら、ワークロード・ステージの完了後、プラットフォームは、現在のステージの入力または出力あるいは中間結果が、下位ランクのリソースを使用するように計画されている将来のステージで必要であることを特定し得るが、第１のクラウド・リソースは、下位ランクのリソースと比較して、長期保存に関して高いランクを提供する。この場合、ワークロード管理アルゴリズムは、必要なデータを所定の期間（この期間はステージ実行時間に依存する）、下位ランクのリソースに移行し、それが完了した後、データは長期保存のために第１のクラウド・リソースに安全に移行し戻される。

本発明は、任意の可能な技術的詳細レベルの統合におけるシステム、方法、またはコンピュータ・プログラム製品、あるいはそれらの組み合わせであり得る。コンピュータ・プログラム製品は、本発明の態様をプロセッサに実行させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読記憶媒体（または複数の媒体）を含み得る。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のために命令を保持および記憶可能な有形のデバイスとすることができる。コンピュータ可読記憶媒体は、たとえば、限定はしないが、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであり得る。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストには、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ：ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、デジタル・バーサタイル・ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、メモリー・スティック（Ｒ）、フレキシブル・ディスク、命令が記録されたパンチ・カードまたは溝の隆起構造などの機械的にコード化されたデバイス、およびこれらの任意の適切な組み合わせが含まれる。コンピュータ可読記憶媒体は、本明細書で使用する場合、たとえば、電波または他の自由に伝搬する電磁波、導波管もしくは他の伝送媒体を伝搬する電磁波（たとえば、光ファイバ・ケーブルを通過する光パルス）、または有線で伝送される電気信号などの一過性の信号自体であると解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいは、たとえば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくは無線ネットワーク、またはそれらの組み合わせなどのネットワークを介して外部コンピュータまたは外部ストレージ・デバイスにダウンロードすることができる。ネットワークは、銅線伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはそれらの組み合わせを含み得る。各コンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ－ｓｅｔ－ａｒｃｈｉｔｅｃｔｕｒｅ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路の構成データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または類似のプログラミング言語などの手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで書かれたソース・コードまたはオブジェクト・コードであり得る。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上かつ部分的にリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で実行され得る。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続され得、または（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータへの接続がなされ得る。いくつかの態様では、たとえば、プログラマブル論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ）を含む電子回路は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用してコンピュータ可読プログラム命令を実行することによって、電子回路を個人向けにし得る。

本発明の態様は、本発明の態様による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して本明細書で説明している。フローチャート図またはブロック図あるいはその両方の各ブロック、およびフローチャート図またはブロック図あるいはその両方におけるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装できることは理解されよう。

これらのコンピュータ可読プログラム命令を、コンピュータまたは他のプログラム可能データ処理装置のプロセッサに提供して、それらの命令がコンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行された場合に、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定された機能／行為を実装するための手段が生成されるようなマシンを生成し得る。また、これらのコンピュータ可読プログラム命令を、コンピュータ、プログラム可能データ処理装置、または他のデバイス、あるいはそれらの組み合わせに特定の方法で機能するように指示することが可能なコンピュータ可読記憶媒体に記憶して、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定された機能／行為の態様を実装する命令を含む製造品を構成するようにし得る。

また、コンピュータ可読プログラム命令をコンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードして、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実行させることによって、それらの命令がコンピュータ、他のプログラム可能装置、または他のデバイス上で実行された場合に、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定された機能／行為が実装されるようなコンピュータ実装処理を生成し得る。

図中のフローチャートおよびブロック図は、本発明の様々な態様によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示している。これに関して、フローチャートまたはブロック図の各ブロックは、指定された論理的機能（複数可）を実装するための１つまたは複数の実行可能命令を含むモジュール、セグメント、または命令の一部を表し得る。いくつかの代替的実装形態では、ブロックに記載した機能は、図示した順序以外で行われ得る。たとえば、関与する機能に応じて、連続して示した２つのブロックは、実際には、１つのステップとして実現され得、同時に、実質的に同時に、部分的にまたは完全に時間的に重なるように実行され得、またはそれらのブロックは、場合により逆の順序で実行され得る。ブロック図またはフローチャート図あるいはその両方の各ブロック、およびブロック図またはフローチャート図あるいはその両方におけるブロックの組み合わせは、指定された機能もしくは行為を実行するか、または専用ハードウェアおよびコンピュータ命令の組み合わせを実行する専用のハードウェア・ベースのシステムによって実装できることにも気付くであろう。

さらに、様々な態様によるシステムは、プロセッサと、プロセッサと統合された、またはプロセッサによって実行可能な、あるいはその両方であるロジックと、を含み得、ロジックは、本明細書に記載の処理ステップのうちの１つまたは複数を実行するように構成される。「～と統合される」とは、特定用途向け集積回路（ＡＳＩＣ）、ＦＰＧＡなど、ハードウェア・ロジックとしてロジックがプロセッサに組み込まれることを意味する。「プロセッサによって実行可能」とは、ロジックがハードウェア・ロジックであるか、ファームウェア、オペレーティング・システムの一部、アプリケーション・プログラムの一部などのソフトウェア・ロジックなどであるか、またはプロセッサによりアクセス可能であり、プロセッサによる実行時にプロセッサに一部の機能を実行させるように構成されるハードウェアおよびソフトウェア・ロジックの何らかの組み合わせであることを意味する。ソフトウェア・ロジックは、当技術分野で知られているように、任意のメモリ・タイプのローカルまたはリモートあるいはその両方のメモリに記憶され得る。当技術分野で知られている任意のプロセッサ、たとえば、ソフトウェア・プロセッサ・モジュール、またはハードウェア・プロセッサ、たとえば、ＡＳＩＣ、ＦＰＧＡ、中央処理装置（ＣＰＵ）、集積回路（ＩＣ：ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、グラフィックス処理装置（ＧＰＵ：ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）など、あるいはその両方が使用され得る。

前述のシステムまたは方法論あるいはその両方の様々な特徴を任意の方法で組み合わせて、上記の説明から複数の組み合わせを作成し得ることは明らかであろう。

本発明の態様が、オンデマンドでサービスを提供するために顧客のために展開されるサービスの形で提供され得ることがさらに理解されよう。

本発明の様々な態様の説明は例示の目的で提示しているが、網羅的であることも、開示した態様に限定されることも意図したものではない。記載した態様の範囲および思想から逸脱することなく、多くの修正および変形が当業者には明らかであろう。本明細書で使用する用語は、態様の原理、実際の応用、または市場で見られる技術に対する技術的改善を最もよく説明するために、または当業者が本明細書に開示した態様を理解できるようにするために選んでいる。

Claims (25)

1. 複数のクラウド・ベンダーの特性を決定および記憶することと、
   ワークロードを複数の論理ステージに分割することと、
   前記複数の論理ステージのうちのそれぞれの特性を決定することと、
   前記複数の論理ステージのうちのそれぞれについて、前記複数のクラウド・ベンダーの前記特性と前記論理ステージの前記特性との比較に基づいて、前記論理ステージを前記複数のクラウド・ベンダーのうちの１つに割り当てることと、
   を含む、コンピュータ実装方法。
2. 前記複数のクラウド・ベンダーのうちのそれぞれの前記特性は、前記クラウド・ベンダーを分析することによって決定され、前記分析することは、前記クラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることを含む、請求項１に記載のコンピュータ実装方法。
3. 前記複数のクラウド・ベンダーのうちのそれぞれの前記特性は、前記クラウド・ベンダーを分析することによって決定され、前記分析することは、前記複数のクラウド・ベンダーのうちのそれぞれのレポート、傾向、脆弱性、セキュリティ問題などのうちの１つまたは複数を特定するために、１つまたは複数のパブリックおよびプライベート・セキュリティ・データベース情報を収集および解析することを含む、請求項１に記載のコンピュータ実装方法。
4. 前記複数のクラウド・ベンダーのうちのそれぞれの前記特性は、前記クラウド・ベンダーを分析することによって決定され、前記分析することは、前記複数のクラウド・ベンダーのうちの１つまたは複数に関する既存のセキュリティ問題に対する既存の解決方法を決定するために、１つまたは複数の解決策データベースを解析することを含む、請求項１に記載のコンピュータ実装方法。
5. 前記複数のクラウド・ベンダーのうちのそれぞれの前記特性は、前記クラウド・ベンダーを分析することによって決定され、前記分析することは、前記クラウド・ベンダーに関して収集されたレビュー情報に基づいて、前記クラウド・ベンダーのそれぞれに関する１つまたは複数の実行可能性要因を推定することを含み、前記実行可能性要因は、サービス性、ネット・プロモーター・スコア（ＮＰＳ）、ユーザ・レビュー、パフォーマンス・ベンチマーク、およびチューニングの柔軟性を含むグループから選択される、請求項１に記載のコンピュータ実装方法。
6. 前記複数のクラウド・ベンダーのうちのそれぞれについて、前記クラウド・ベンダーの前記特性は、前記クラウド・ベンダーの能力、前記クラウド・ベンダーの実施の費用、前記クラウド・ベンダーによって実現されるセキュリティ・レベル、および前記クラウド・ベンダーに関連する実行可能性要因を含む、請求項１に記載のコンピュータ実装方法。
7. 前記複数のクラウド・ベンダーの前記特性のうちのそれぞれのレベルを決定するために、前記複数のクラウド・ベンダーの前記特性のうちのそれぞれが１つまたは複数の事前定義された閾値と比較される、請求項１に記載のコンピュータ実装方法。
8. 前記複数のクラウド・ベンダーのうちのそれぞれについて、前記クラウド・ベンダーの前記特性は、
   ワークロードの実施中に前記クラウド・ベンダーによって提供されるセキュリティのレベルを示すサイバー・セキュリティ特性と、
   ワークロードの実施中に前記クラウド・ベンダーによって提供されるクラッシュ保護、マルウェア保護、および冗長データ保護のレベルを示すサイバー・レジリエンシー特性と、
   を含む、請求項１に記載のコンピュータ実装方法。
9. 前記ワークロードは、
   分析および操作されるデータの１つまたは複数のインスタンスと、
   実行される１つまたは複数の計算と、
   出力される１つまたは複数の結果と、
   を含む、請求項１に記載のコンピュータ実装方法。
10. 前記ワークロードを分割することは、前記ワークロード内のデータ入力および出力のポイント、ならびに前記ワークロードへの入力に関連する依存関係を特定するために、前記ワークロードを解析することを含む、請求項１に記載のコンピュータ実装方法。
11. 前記ワークロード内のデータ入力および出力のインスタンスを予測するために、前記ワークロードのソース・コードがスキャンされる、請求項１に記載のコンピュータ実装方法。
12. 前記論理ステージのそれぞれは、前記ワークロード内の他の論理ステージに依存しないデータ入力を含む、請求項１に記載のコンピュータ実装方法。
13. 前記論理ステージ内の入力、出力、および中間結果に基づいて前記論理ステージのうちのそれぞれの複雑性が決定される、請求項１に記載のコンピュータ実装方法。
14. 前記論理ステージの複雑性に基づいて前記論理ステージのうちのそれぞれの特性が決定される、請求項１に記載のコンピュータ実装方法。
15. 各論理ステージについて、前記論理ステージの要件を満たすことが可能なクラウド・ベンダーを決定するために、前記論理ステージの前記特性が前記複数のクラウド・ベンダーのうちのそれぞれの前記特性と比較される、請求項１に記載のコンピュータ実装方法。
16. 前記論理ステージをクラウド・ベンダーに割り当てることは、前記クラウド・ベンダーが前記論理ステージに必要な入力を受け取り、前記論理ステージに必要な操作を実行し、前記論理ステージに必要なデータを出力するように、前記論理ステージを前記クラウド・ベンダーにマッピングすることを含む、請求項１に記載のコンピュータ実装方法。
17. グラフィカル・ユーザ・インターフェース（ＧＵＩ）を使用して前記クラウド・ベンダーへの各論理ステージのマッピングを１人または複数のユーザに提示することをさらに含む、請求項１に記載のコンピュータ実装方法。
18. ユーザの優先順位に基づいて各論理ステージ内のリソース割り当てを調整することをさらに含む、請求項１に記載のコンピュータ実装方法。
19. 前記ワークロードの各タスク中にデータが必要なクラウド・ベンダーに配置されるようにするために、前記ワークロードの実施中に前記クラウド・ベンダー間でデータ移行を実行することを含む、ライフ・サイクル管理を実施することをさらに含む、請求項１に記載のコンピュータ実装方法。
20. マルチクラウド環境においてワークロードを実施するためのコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は、プログラム命令を具現化するコンピュータ可読記憶媒体を含み、前記コンピュータ可読記憶媒体自体は一過性の信号ではなく、前記プログラム命令は、プロセッサによって実行可能であり、前記プロセッサに方法を実行させ、前記方法は、
    前記プロセッサによって、複数のクラウド・ベンダーの特性を決定および記憶することと、
    前記プロセッサによって、ワークロードを複数の論理ステージに分割することと、
    前記プロセッサによって、前記複数の論理ステージのうちのそれぞれの特性を決定することと、
    前記複数の論理ステージのうちのそれぞれについて、前記プロセッサによって、前記複数のクラウド・ベンダーの前記特性と前記論理ステージの前記特性との比較に基づいて、前記論理ステージを前記複数のクラウド・ベンダーのうちの１つに割り当てることと、
    を含む、コンピュータ・プログラム製品。
21. 前記複数のクラウド・ベンダーのうちのそれぞれの前記特性は、前記クラウド・ベンダーを分析することによって決定され、前記分析することは、前記クラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることを含む、請求項２０に記載のコンピュータ・プログラム製品。
22. 前記複数のクラウド・ベンダーのうちのそれぞれの前記特性は、前記クラウド・ベンダーを分析することによって決定され、前記分析することは、前記複数のクラウド・ベンダーのうちのそれぞれのレポート、傾向、脆弱性、セキュリティ問題などのうちの１つまたは複数を特定するために、１つまたは複数のパブリックおよびプライベート・セキュリティ・データベース情報を収集および解析することを含む、請求項２０に記載のコンピュータ・プログラム製品。
23. プロセッサと、
    前記プロセッサと統合された、もしくは前記プロセッサによって実行可能な、または前記プロセッサと統合され、前記プロセッサによって実行可能なロジックと、
    を備え、前記ロジックは、
    複数のクラウド・ベンダーの特性を決定および記憶することと、
    ワークロードを複数の論理ステージに分割することと、
    前記複数の論理ステージのうちのそれぞれの特性を決定することと、
    前記複数の論理ステージのうちのそれぞれについて、前記複数のクラウド・ベンダーの前記特性と前記論理ステージの前記特性との比較に基づいて、前記論理ステージを前記複数のクラウド・ベンダーのうちの１つに割り当てることと、
    を行うように構成される、システム。
24. 複数のクラウド・ベンダーを分析することによって、前記複数のクラウド・ベンダーの特性を決定することであって、前記分析することは、
    前記複数のクラウド・ベンダーのスキャンを実行するために、能力および費用アプリケーション・プログラミング・インターフェース（ＡＰＩ）を動作させることと、
    前記複数のクラウド・ベンダーのうちのそれぞれのレポート、傾向、脆弱性、セキュリティ問題などのうちの１つまたは複数を特定するために、１つまたは複数のパブリックおよびプライベート・セキュリティ・データベース情報を収集および解析することと、
    前記複数のクラウド・ベンダーのうちの１つまたは複数に関する既存のセキュリティ問題に対する既存の解決方法を決定するために、１つまたは複数の解決策データベースを解析することと、
    を含む、前記決定することと、
    ワークロードを複数の論理ステージに分割することと、
    前記複数の論理ステージのうちのそれぞれの特性を決定することと、
    前記複数の論理ステージのうちのそれぞれについて、前記複数のクラウド・ベンダーの前記特性と前記論理ステージの前記特性との比較に基づいて、前記論理ステージを前記複数のクラウド・ベンダーのうちの１つに割り当てることと、
    を含む、コンピュータ実装方法。
25. 複数のクラウド・ベンダーの特性を決定および記憶することと、
    ワークロードを複数の論理ステージに分割することであって、
    前記ワークロード内のデータ入力および出力のポイント、ならびに前記ワークロードへの入力に関連する依存関係を特定するために、前記ワークロードを解析することと、
    前記ワークロード内のデータ入力および出力のインスタンスを予測するために、前記ワークロードのソース・コードをスキャンすることと、
    を含み、
    前記論理ステージのそれぞれは、前記ワークロード内の他の論理ステージに依存しないデータ入力を含む、
    前記分割することと、
    前記複数の論理ステージのうちのそれぞれの特性を決定することと、
    前記複数の論理ステージのうちのそれぞれについて、前記複数のクラウド・ベンダーの前記特性と前記論理ステージの前記特性との比較に基づいて、前記論理ステージを前記複数のクラウド・ベンダーのうちの１つに割り当てることと、
    を含む、コンピュータ実装方法。

Images