(57)【要約】特定処理、画像処理、又は並列処理に特化した高い処理性能を実現するクラウドサービスを提供する。リソース選択装置１は、ユーザの性能要件及び機能要件が特定の計算処理、画像処理、又は並列処理を一定以上の処理性能で処理することを要求しているかに基づき、少なくともFPGAかGPUを含む複数のリソース及び複数のプロビジョニング方法からリソース及びプロビジョニング方法をそれぞれ選択する。
2017029826.tif 000002
【特許請求の範囲】
【請求項１】
クラウド上のリソースを選択するリソース選択装置と、リソースを構成し又はそのリソース構成を再構成するリソース再構成装置と、を備えたリソース構成システムにおいて、
前記リソース選択装置は、
前記リソースに対するユーザの要件を受信する受信手段と、
前記要件が特定処理、画像処理、又は並列処理を一定以上の処理性能で処理することを要求しているかに基づき、少なくともＦＰＧＡかＧＰＵを含む複数の計算リソース及び複数のプロビジョニング方法から計算リソース及びプロビジョニング方法をそれぞれ選択する選択手段と、
を備えることを特徴とするリソース構成システム。
【請求項２】
前記選択手段は、
前記要件が前記特定処理を一定以上の処理性能で処理することを要求している場合、前記計算リソースとしてＦＰＧＡを選択し、当該計算リソースのプロビジョニング方法としてベアメタルを選択することを特徴とする請求項１に記載のリソース構成システム。
【請求項３】
前記選択手段は、
前記要件が前記画像処理又は前記並列処理を一定以上の処理性能で処理することを要求している場合、前記計算リソースとしてＧＰＵを選択し、当該計算リソースのプロビジョニング方法として、計算リソースに対して要求されている処理性能の大きさ又はＯＳに対するカスタマイズの要否に基づきベアメタル又はコンテナを選択することを特徴とする請求項１に記載のリソース構成システム。
【請求項４】
前記選択手段は、
前記要件に基づきブロック単位又はオブジェクト単位のプロビジョニング方法を選択し、動作させるアプリケーションプログラムの特性に応じて記憶リソースを選択することを特徴とする請求項１に記載のリソース構成システム。
【請求項５】
前記リソース再構成装置は、
ユーザの要件に応じた計算ロジックをＦＰＧＡの計算リソースに設定し、当該計算ロジックを当該計算リソースで利用させる構成手段、
を備えることを特徴とする請求項１に記載のリソース構成システム。
【請求項６】
前記リソース再構成装置は、
リソース構成後の計算リソースで前記ユーザが利用している各種計算処理の利用頻度をそれぞれ収集する収集手段と、
前記利用頻度が増大した特定の計算処理に合わせて前記リソース構成後の計算リソースの構成を変更する再構成手段と、
を備えることを特徴とする請求項１に記載のリソース構成システム。
【請求項７】
クラウド上のリソースを選択するリソース選択装置と、リソースを構成し又はそのリソース構成を再構成するリソース再構成装置と、で行うリソース構成方法において、
前記リソース選択装置は、
前記リソースに対するユーザの要件を受信するステップと、
前記要件が特定処理、画像処理、又は並列処理を一定以上の処理性能で処理することを要求しているかに基づき、少なくともＦＰＧＡかＧＰＵを含む複数の計算リソース及び複数のプロビジョニング方法から計算リソース及びプロビジョニング方法をそれぞれ選択するステップと、
を備えることを特徴とするリソース構成方法。
【請求項８】
前記リソース再構成装置は、
リソース構成後の計算リソースで前記ユーザが利用している各種計算処理の利用頻度をそれぞれ収集するステップと、
前記利用頻度が増大した特定の計算処理に合わせて前記リソース構成後の計算リソースの構成を変更するステップと、
を備えることを特徴とする請求項７に記載のリソース構成方法。
【請求項９】
請求項１に記載のリソース構成システムとしてコンピュータを機能させることを特徴とするリソース構成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウド上のリソースを構成する技術に関する。特に、多様なリソース及びプロビジョニング方法が利用可能なクラウドサービスにおいて、ユーザの要件に合うリソース及びそのリソースのプロビジョニング方法を選択し、必要に応じてリソース構成を再構成する技術に関する。
【背景技術】
【０００２】
近年、IaaS（Infrastructure as a Service）型クラウドサービス等、ユーザに対してコンピュータシステムの仮想リソースをプロビジョニングするクラウドサービスが普及している。ユーザは、サービス事業者と契約することにより、仮想サーバ、仮想ネットワーク、仮想ルーター、仮想ストレージ、仮想ロードバランサー等の仮想リソースをオンデマンドで利用することができる。例えば、Amazon Web Services（登録商標、http://aws.amazon.com/ec2）等のクラウドサービスが存在する。ユーザは、OS（Operating System）、DB（Data Base）、Web、電子メール等のミドルウェアを仮想リソース上で動作させることにより、自分自身で物理的なハードウェア機器を用意することなく、自身専用のサーバを構築することができる。【０００３】
また、IaaSを実現するためのオープンソースソフトウェアも普及している。例えば、OpenStack（登録商標）と呼ばれるオープンソースソフトウェアを基盤とする商用クラウドサービスが提供されている。例えば、Rackspace（登録商標、Public Cloud Powered by OpenStack、http://www.rackspace.com/cloud/）等の商用クラウドサービスが存在している。【０００４】
このような状況下、市中のクラウドサービスにおいて、ユーザに提供される仮想サーバとしては、プロビジョニング方法で分類した場合、CPUがメニーコア（many core）のサーバをXenやKVM（Kernel based Virtual Machine）等のハイパーバイザーで仮想化した仮想サーバが主流である。一方、ハイパーバイザーは仮想化処理のオーバヘッドが大きいという欠点を持つため、性能劣化が小さいコンテナ型の仮想サーバ（コンテナ）や仮想化を行わないベアメタル型の物理サーバ（ベアメタル）がある。また、計算リソースで分類した場合、CPUを持つ一般的なサーバ以外に、特定の計算ロジックに最適化されたFPGA（Field Programmable Gate Array）サーバがある。例えば、Microsoft社のBing検索サーバである。さらに、一般のクライアントPCが持つGPU（Graphical Processing Unit）をクラウドサーバにも搭載し、画像処理能力が高いサーバをクラウドサーバとして提供するサービス事業者も出現している。例えば、Amazon Web ServiceのGPUインスタンスサーバである。【０００５】
また、ユーザに提供される仮想ストレージとしては、プロビジョニング方法で分類した場合、ブロックストレージやオブジェクトストレージがある。また、記憶リソースで分類した場合、これまでHDDベースの専用ストレージ（例えば、EMC社のVNX）から仮想ボリュームを切り出してユーザに提供する形態が主流であったが、ランダムIO（Input Output）性能がHDDに比べて高いSSD、SSDとHDDのハイブリッドストレージを仮想ボリュームとして提供するサービス事業者も出現している。例えば、Yahoo（登録商標）では、Nimble社のハイブリッドストレージをクラウドのストレージに利用している。さらに、低価格を好むユーザに対しては、CephやSwift等の分散ストレージが利用される。例えば、GMOクラウドのKonohaである。【０００６】
このように、クラウドサービスに利用される仮想リソース及びその仮想リソースのプロビジョニング方法は多様である。それゆえ、ユーザの利用用途に応じて適材適所の仮想サーバ等を選択することにより、IaaSの性能が向上し、ユーザの利便性が高まると考えられる。しかし、従来のクラウドサービスでは、同一機種の仮想リソース中から選定するため、個々のユーザの要件に合致した適材適所の仮想リソースを提供することは困難であった。そのため、ユーザは、自らの機能要件及び性能要件に合わせて適切なサーバ構成を自分自身で設計し、そのサーバ構成の性能検証を行う必要があり、多くの技術知識や労力が必要とされていた。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１５−１０３０９４号公報
【非特許文献】
【０００８】
【非特許文献１】Y. Yamato、“SERVER STRUCTURE PROPOSAL AND AUTOMATIC VERIFICATION TECHNOLOGY ON IAAS CLOUD OF PLURAL TYPE SERVICERS”、International Conference on Internet Studies, July 18-19, 2015, Tokyo, Japan
【発明の概要】
【発明が解決しようとする課題】
【０００９】
そこで、特許文献１又は非特許文献１の技術を用いることが考えられる。【００１０】
特許文献１は、仮想リソースを提供するクラウドサービスにおいて、適切な物理機器にユーザの仮想リソースを配置する技術である。しかし、例えば一定の仮想CPU数を持つ仮想サーバをどの物理機器に対応付けるかをスケジューリングするだけであり、ベアメタルやコンテナ等のプロビジョニング方法を用いて強力なGPUユニットやFPGAを備えた仮想サーバをユーザに提供することはできない。【００１１】
また、非特許文献１は、ベアメタル、コンテナ、及びハイパーバイザーが提供されているクラウドサービスにおいて、ユーザの機能要件及び性能要件に従い、適切なプロビジョニング方法を提案する技術である。しかし、プロビジョニング方法を提案するだけであり、ユーザの性能要件及び機能要件に対応する仮想リソースをGPUやFPGAを備えた仮想サーバの中から選択することはできない。【００１２】
さらに、特許文献１及び非特許文献１は、ユーザに対して仮想リソースを提供するための技術であり、仮想リソースに対するユーザの利用形態が変化した場合、それに合わせて仮想リソースの構成を再構成することはできない。【００１３】
本発明は、上記事情を鑑みてなされたものであり、特定処理、画像処理、又は並列処理に特化した高い処理性能を実現するクラウドサービスを提供することを目的とする。
【課題を解決するための手段】
【００１４】
以上の課題を解決するため、本発明のリソース構成システムは、クラウド上のリソースを選択するリソース選択装置と、リソースを構成し又はそのリソース構成を再構成するリソース再構成装置と、を備えたリソース構成システムにおいて、前記リソース選択装置は、前記リソースに対するユーザの要件を受信する受信手段と、前記要件が特定処理、画像処理、又は並列処理を一定以上の処理性能で処理することを要求しているかに基づき、少なくともFPGAかGPUを含む複数の計算リソース及び複数のプロビジョニング方法から計算リソース及びプロビジョニング方法をそれぞれ選択する選択手段と、を備えることを要旨とする。【００１５】
また、本発明のリソース構成方法は、クラウド上のリソースを選択するリソース選択装置と、リソースを構成し又はそのリソース構成を再構成するリソース再構成装置と、で行うリソース構成方法において、前記リソース選択装置は、前記リソースに対するユーザの要件を受信するステップと、前記要件が特定処理、画像処理、又は並列処理を一定以上の処理性能で処理することを要求しているかに基づき、少なくともFPGAかGPUを含む複数の計算リソース及び複数のプロビジョニング方法から計算リソース及びプロビジョニング方法をそれぞれ選択するステップと、を備えることを要旨とする。【００１６】
また、本発明のリソース構成プログラムは、請求項１に記載のリソース構成システムとしてコンピュータを機能させることを要旨とする。
【発明の効果】
【００１７】
本発明によれば、特定処理、画像処理、又は並列処理に特化した高い処理性能を実現するクラウドサービスを提供することができる。
【図面の簡単な説明】
【００１８】
【図１】第１の実施の形態に係るリソース構成システムの全体構成を示す図である。
【図２】リソース及びプロビジョニング方法の選択処理フローを示す図である。
【図３】計算リソースの選択処理フローを示す図である。
【図４】第２の実施の形態に係るリソース構成システムの全体構成を示す図である。
【図５】FPGAサーバに対する計算ロジックの構成処理フローを示す図である。
【図６】FPGAサーバに対する計算ロジックの構成処理フローを示す図である。
【図７】FPGAサーバに対する計算ロジックの再構成処理フローを示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明を実施する一実施の形態について図面を用いて説明する。
【００２０】
＜第１の実施の形態＞
図１は、第１の実施の形態に係るリソース構成システムの全体構成を示す図である。このリソース構成システムは、クラウドシステム上に配置され、ユーザの性能要件及び機能要件に合致するリソース及びプロビジョニング方法を選択するリソース選択装置１と、その選択結果に基づきリソース構成を構築するIaaSコントローラ３と、を備えて構成される。
【００２１】
まず、IaaSコントローラ３について説明する。このIaaSコントローラ３は、例えば既存のOpenStackを用いて構成する。OpenStackとは、クラウドコンピューティングの基盤を構築するためのオープンソースソフトウェアである。IaaSコントローラ３は、クラウド上に配置された複数の物理機器と通信可能であり、Volume Manager等の仮想化ソフトウェアを介してクラウド上の仮想リソース、及び仮想化ソフトウェアを介することなく物理リソースを管理する。本実施の形態では、リソース選択装置１からの設定要求を受け付けるOpenStack API３１と、その設定要求に基づき該当ユーザのリソース構成を構築するリソース構成構築部３２（Heat、Nova、Cinder等）と、クラウド上に存在する様々なリソース情報やユーザ毎のリソース構成情報を記憶するOpenStack DB３３と、を備えて構成される。
【００２２】
続いて、リソース選択装置１について説明する。このリソース選択装置１は、ユーザ端末５とIaaSコントローラ３との間で動作する。本実施の形態では、ユーザ端末５で入力されたユーザの性能要件及び機能要件を受け付ける要求受付部１１と、受け付けた要求に基づきリソース及びプロビジョニング方法を選択するリソース選択部１２と、その選択結果をユーザ端末５へ通知する選択結果通知部１３と、その選択結果に対するユーザの承認指示に基づきリソース設定をIaaSコントローラ３へ要求する設定要求部１４と、リソース及びプロビジョニング方法の選択時に用いる情報を記憶するデータ記憶部１５と、を備えて構成される。選択時に用いる情報とは、例えば、IaaSコントローラ３で設定及び利用可能な全てのリソース及びプロビジョニング方法、ユーザ端末５からの要求、その要求に基づくリソース及びプロビジョニング方法の選択結果等に関する情報である。
【００２３】
ここまで、リソース構成システムの全体構成について説明した。なお、リソース選択装置１は、CPU等の演算機能やメモリ等の記憶機能を備えたコンピュータで実現可能である。また、そのコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。さらに、リソース選択装置１は、IaaSコントローラ３と物理的に異なる装置として機能させてもよいし、IaaSコントローラ３の一機能としてもよい。
【００２４】
次に、IaaSコントローラ３で設定及び利用可能な全てのリソース及びプロビジョニング方法について説明する。つまり、ここでは、リソース選択装置１で選択可能なリソース及びプロビジョニング方法について説明する。なお、リソースとは、仮想リソースと物理リソースの双方又はいずれかを指す。例えばIaaSコントローラ３としてOpenStackを用いた場合、一般的には仮想化ソフトウェアによる仮想リソースが考えられるが、仮想化ソフトウェアを介することなく物理リソースを選択対象のリソースとしてもよい。
【００２５】
まず、プロビジョニング方法について説明する。本実施の形態では、リソースが計算リソースの場合、例えば、ベアメタルプロビジョニング、コンテナプロビジョニング、ハイパーバイザープロビジョニングを用いる。一方、リソースが記憶リソースの場合、例えば、ブロックストレージプロビジョニング、オブジェクトストレージプロビジョニングを用いる。
【００２６】
ベアメタルとは、仮想化を行わない物理サーバである。従来のDedicated Hostingと同じである。それゆえ、ベアメタルプロビジョニングとは、仮想化を行わない物理サーバを確保等することをいう。例えばOpenStackでは、Ironicというコンポーネントがベアメタルプロビジョンを行っている。ベアメタルは専用サーバであるため、自由度は高くて性能も高いが、プロビジョニングして起動するまでの時間は長く、ライブマイグレーションを行うことができない。
【００２７】
コンテナとは、OS仮想化技術を用いた仮想サーバである。OpenVZ等、VPS（Virtual Private Server）で用いられている。それゆえ、コンテナプロビジョニングとは、OS仮想化技術を用いた仮想サーバを確保等することをいう。コンテナプロビジョニングは、コンテナと呼ばれる単位でコンピュータリソースを隔離することで物理サーバを仮想化する。コンテナプロビジョニングは、OSのカーネルを共有する点で後述するハイパーバイザーと異なる。2013年にLXC（Linux Container）を用いたDockerが登場し、その使い勝手の良さから利用が増えている。コンテナは、カーネルの自由度はないが、その確保及び生成処理はプロセスを立ち上げただけであるため、起動時間が短く、性能劣化も小さい。また、OpenVZはライブマイグレーションが可能であるが、DockerやLXCでは現時点では不可能である。
【００２８】
ハイパーバイザーは、ハードウェア仮想化技術を用いて物理サーバを仮想化する技術である。それゆえ、ハイパーバイザープロビジョニングとは、ハードウェア仮想化技術を用いた仮想サーバを確保等することをいう。ハイパーバイザープロビジョニングは、ハードウェア仮想化技術でエミュレートされたハードウェア上で動作するため、自由にOSをカスタマイズすることができる。主なハイパーバイザーとして、例えば、Xen、KVM、VMware ESXがある。この仮想サーバは、OSの自由度が高く、ライブマイグレーションも可能である。一方、この仮想サーバは、エミュレーションオーバヘッドが大きいため、性能や起動時間でベアメタルやコンテナに劣る欠点がある。
【００２９】
続いて、計算リソースについて説明する。本実施の形態では、例えば、CPU、GPU、FPGAを用いる。
【００３０】
CPUは、多くのサーバやクライアントPCに搭載されている一般的な計算リソースであり、低遅延を意識した設計がされている。CPUは、大きなキャッシュ、高度な制御、強力な演算機能を備える。特にクラウドサーバでは、CPUのコア数が10個を超えるメニーコアのCPUが使われることが多い。
【００３１】
GPUは、画像処理向けの計算ユニットであり、高スループットを意識した設計がされている。GPUは、小さなキャッシュ、単純な制御、エネルギー効率の良い演算機能を備え、高スループットのために大量の並列計算を行うよう計算ユニットが配置されている。GPUはクライアントPCに多く搭載されているが、画像処理用のアプリケーションを動かすサーバにも搭載されている。
【００３２】
FPGAは、製造後に購入者や設計者が構成を設定又は変更できる集積回路であり、プログラマブルロジックデバイスの一つである。FPGAは、出荷後においても機能を更新でき、設計面で部分的に再構成でき、ASIC設計よりエンジニアリングコストが低い点等の利点がある。FPGAは汎用処理には向かないが、特定の計算にロジックを構成することにより、CPUやGPUに比べて高い処理性能を実現することができる。FPGAに向いた計算の同一処理であれば、GPUの数倍、CPUの10-100倍以上の処理性能を持つ。FPGAは、科学学術での利用が中心だったが、クラウドサーバでも検索処理やNoSQL Engineの処理の高速化に用いられるようになっている。例えば、MicrosoftのBing検索やIBM社のNoSQLエンジンで利用されている。
【００３３】
引き続き、記憶リソースについて説明する。本実施の形態では、例えば、HDD、SSD、ハイブリッドストレージ、分散ストレージを用いる。
【００３４】
HDD（Hard Disk Drive）は、多くのサーバやクライアントPCに搭載されている一般的な記憶リソースである。通常のHDDベースのストレージに関しては、IO（Input Output）の性能向上のため、HDDを並列化してストライピングを行う。例えば、一般的な15000 rpm(rotation per minute)のHDDはランダムWriteで150-200 IOPS程度であるが、20本並べることで3000-4000 IOPS程度となる。しかし、並列するHDDの増加に伴い、電力や場所のコストがかかり、HDD追加時やHDD故障交換時はストレージ筐体の停止に伴うサービス停止が必要となる。
【００３５】
SSD（Solid State Drive）は、フラッシュメモリ等を使用した記憶リソースである。SSDは、ランダムIOの性能がHDDに比べて高く数千IOPS程度だが、HDDに比べてシーケンシャルIOの性能は低い。また、SSDは、単位容量当たりのコストが高く、耐久性も低い。そのため、全てSSDのストレージでクラウドユーザのボリュームを準備するのは高コストで困難である。現状、クラウドでのSSDの利用は、OLTP（Online Transaction Processing）等のIOPSが要求されるアプリケーションが中心であり、ファイルサーバ等にはあまり使われていない。
【００３６】
ハイブリッドストレージは、HDDとSSDの各特性を踏まえ、それぞれの特長を生かした記憶リソースである。例えば、Nimble社のStorageは、CASL（Cache Accelerated Sequential Layout）と呼ばれる方式を採用している。CASLでは、書き込み時は、まずSSDに書き込み、圧縮してシーケンシャルアクセスできる形式に変換してHDDに書き込むと同時に、一部はキャッシュに保存する。読み込み時は、SSD及びキャッシュから検索し、最後にHDDを検索して応答を返す。これにより、CASLでは、通常のSSDと同程度以上のランダムIOPSを実現している。ハイブリッドストレージの研究は2000年代終わりから盛んであり、Nimble以外にも多くの研究、製品が挙げられる。例えば、“Extending SSD Lifetimes with Disk-Based Write Caches”（G. Soundararajan、外３名、FAST 2010: 8th USENIX Conference on File and Storage Technologies, Feb. 2010.）を参照されたい。
【００３７】
分散ストレージは、IA（Intel Architecture）サーバを用いた記憶リソースである。安価なIAサーバを並置することで、大容量で拡張性のあるストレージシステムが構築されている。近年、IAサーバに内蔵できるドライブの容量、本数が増えており、これらIAサーバ群のドライブをソフトウェアで統一的に管理することで、単一ストレージのSPOF（Single Point Of Failure）やボトルネック、追加等のメンテナンス時のサービス停止を防止している。利用するドライブにSSDも利用できるが、通常はコストを重視してSATA（Serial Advanced Technology Attachment）のHDDが利用される。分散ストレージを構成するソフトウェアは、１つのデータを複数ノードに複製を多重に配置し、追加時の再配置や障害時の縮退を自動で行うことができる。ファイルシステムとして利用する分散ストレージとしては、例えば、GlusterFS、Ceph、GFS、HDFS等がある。また、オブジェクトストレージとして利用する分散ストレージとしては、例えば、OpenStack Swift等がある。
【００３８】
ここまで、リソース選択装置１で選択可能なリソース及びプロビジョニング方法について説明した。本実施の形態では、このようなリソース及びプロビジョニング方法の特徴及び性能をリソース毎・プロビジョニング方法毎に互いに比較検討しておく。そして、ユーザが求める性能要件及び機能要件に対して一定の必要条件判定基準を階層的に定め、各基準での判定結果に応じてリソース及びプロビジョニング方法をそれぞれ特定しておき、ユーザの要求条件に合致するリソース及びプロビジョニング方法を選定する。これにより、ユーザの要件に応じたリソース及びプロビジョニング方法を適材適所に配置可能となり、ユーザの要件に見合った処理性能のリソース及びプロビジョニング方法を提供することができる。
【００３９】
次に、リソース選択装置１の動作について説明する。図２は、リソース及びプロビジョニング方法の選択処理フローを示す図である。ここでは、リソース及びプロビジョニング方法をクラウド事業者側が提案するユースケースを想定している。その際、ユーザは性能設計及び機器選定に関するノウハウが少ないものとする。
【００４０】
まず、要求受付部１１は、ユーザによりユーザ端末５で指定された性能要件及び機能要件を受信する（ステップＳ１０１）。このとき、リソース選択装置１に対して直接指定するのに代えて、PaaS（Platform as a Service）を介して指定してもよい（図１参照）。PaaSとは、クラウド上のアプリケーションの実行管理を行うプラットフォームである。アプリケーションのデプロイを該PaaSを介して行うことも可能である。例えば、Cloud Foundry等を用いる。なお、機能要件とは、OSがLinuxかLinux以外か、カーネルのカスタマイズが必要か、どのようなアプリケーションが動作するか、等に関する情報である。また、性能要件とは、スループットやレイテンシー等に関する情報である。
【００４１】
次に、リソース選択部１２は、複数のリソース及び複数のプロビジョニング方法から、ステップＳ１０１で指定された性能要件及び機能要件に合致するリソース及びプロビジョニング方法を選択する（ステップＳ１０２）。具体的には、リソース選択装置１で選択可能なリソース及びプロビジョニング方法の特徴及び性能を考慮し、その特徴及び性能に基づく必要条件判定基準をユーザ要件に対して階層的に定めておく。そして、指定された性能要件及び機能要件を各必要条件判定基準で判定し、その判定結果に応じたリソース及びプロビジョニング方法を選択する。計算リソースについては、プロビジョニング方法として、ベアメタル、コンテナ、ハイパーバイザーのうちいずれか、サーバ機器として、通常のCPU主体のサーバ、GPUが強化されたサーバ、特定の計算処理に最適化されたFPGAを備えたサーバのうちいずれかを選択する。また、記憶リソースについては、プロビジョニング方法として、ブロックストレージ、オブジェクトストレージのうちいずれか、ストレージ機器として、HDDベースのストレージ、SSDベースのストレージ、HDD-SSDハイブリッドストレージ、Ceph等の分散ストレージのうちいずれかを選択する。リソース及びプロビジョニング方法の具体的な選択手順例については後述する。
【００４２】
次に、選択結果通知部１３は、ステップＳ１０２で選択されたリソース及びプロビジョニング方法をユーザ端末５へ送信する（ステップＳ１０３）。それを受けたユーザ端末５は、受信したリソース及びプロビジョニング方法を提案リソース及び提案プロビジョニング方法として画面に表示する。ユーザ端末５のユーザは、その提案内容を確認し、問題なければ承認指示をリソース選択装置１に返信する。
【００４３】
最後に、設定要求部１４は、ユーザにより承認されたリソース及びプロビジョニング方法を指定してIaaSコントローラ３にリソース設定及び生成を要求する（ステップＳ１０４）。その後、IaaSコントローラ３は、リソース選択装置１からの該要求に基づきリソースを確保する。
【００４４】
続いて、ステップＳ１０２で行うリソース及びプロビジョニング方法の具体的な選択手順について説明する。ここでは、図３を参照しながら、計算リソースの選択手順について説明する。
【００４５】
まず、ユーザの機能要件及び性能要件が、特定の計算処理を一定以上の処理性能で処理することを要件としているか否かを判定する（ステップＳ１０２ａ）。
【００４６】
ステップＳ１０２ａの判定結果がYesの場合、その特定の計算処理を高速化するFPGAを備えたサーバを選択し、そのサーバのプロビジョニング方法としてベアメタルを選択する（ステップＳ１０２ｂ）。FPGAでの高速化の例として、memcachedを高速化する方法やMicrosoftのBing検索の高速化等の例がある。仮想化するとFPGAのメリットが十分に生かせないので、ベアメタルでプロビジョニングする。なお、memcachedを高速化の方法については、「“Thin Servers with Smart Pipes: Designing SoC Accelerators for Memcached”、http://bit.ly/1BBNBEI、ISCA、2013」に記載されている。
【００４７】
一方、ステップＳ１０２ａの判定結果がNoの場合、続いて、ユーザの機能要件及び性能要件が、画像処理（又は並列処理）を一定以上の処理性能で処理することを要件としているか否かを判定する（ステップＳ１０２ｃ）。
【００４８】
ステップＳ１０２ｃの判定結果がYesの場合、GPUが強化されたサーバを選択し、そのサーバのプロビジョニング方法としてベアメタル又はコンテナを選択する（ステップＳ１０２ｅ，Ｓ１０２ｆ）。いずれのプロビジョニング方法を選定するかについては、計算リソースに対して要求されている処理性能の大きさ又はＯＳに対するカスタマイズの要否に基づき判定する（ステップＳ１０２ｄ）。ステップＳ１０２ｄの判定結果がYesの場合はベアメタルを選択し、Noの場合はコンテナを選択する。なお、画像処理には、映像編集、加工、分析等を行うアプリケーションがある。サーバのGPUはクライアントPCに比べて、そこまで強化されていないことが多かったが、強力なGPUを備えたサーバも出現している。GPUを制御する際は、仮想マシンではハードウェアが抽象化され制御できないため、ベアメタル又はコンテナでプロビジョニングする。但し、コンテナはLXCやDocker等、OSがLinuxに限定される場合が多いため、Linux以外の場合はベアメタルでプロビジョニングが必要となる。なお、WindowsがOSに対応したコンテナ技術も近年登場してきており、それを用いることにより、WindowsがOSでもコンテナプロビジョニングが可能となる。
【００４９】
一方、ステップＳ１０２ｃの判定結果がNoの場合、通常のCPU主体のサーバを選択し、そのサーバのプロビジョニング方法としてベアメタル、ハイパーバイザー、又はコンテナを選択する（ステップＳ１０２ｉ，Ｓ１０２ｊ，Ｓ１０２ｋ）。いずれのプロビジョニング方法を選定するかについては、計算リソースに対して要求されている処理性能の大きさ（例えば、高スループット、低遅延）又はＯＳに対するカスタマイズの要否に基づき判定する（ステップＳ１０２ｇ，Ｓ１０２ｈ）。ステップＳ１０２ｇの判定結果がYesの場合は、ベアメタルを選択する。一方、その判定結果がNo、かつ、ステップＳ１０２ｈの判定結果がYesの場合は、ハイパーバイザーを選択する。ステップＳ１０２ｇ及びステップＳ１０２ｈの判定結果がいずれもNoの場合は、コンテナを選択する。
【００５０】
ここまで、計算リソースを選択する場合について説明した。なお、図３に示した各ステップの順番は一例である。例えばステップＳ１０２ｃをステップＳ１０２ａの前に行う等、各ステップの順番を入れ替えてもよい。
【００５１】
記憶リソースの場合も同様に、記憶リソース及びプロビジョニング方法の特徴及び性能に基づく必要条件判定基準を階層的に定めておき、指定された性能要件及び機能要件に合致する計算リソース及びプロビジョニング方法を選択する。具体的には、ユーザにより指定された機能要件に基づき、プロビジョニング方法として、ブロックストレージ又はオブジェクトストレージを選択する。ブロックストレージは塊であるブロック単位でデータを管理する。オブジェクトストレージはオブジェクト単位で管理する。オブジェクトストレージは一般に安価であるため、ユーザによりオブジェクトストレージが機能要件に指定された場合は、OpenStack Swift等の分散ストレージを選択する。一方、ブロックストレージが機能要件に指定された場合は、動作させるアプリケーションプログラムの特性に応じてストレージを選択する。OLAP等のように高いIOが要求されるアプリケーションの場合は、性能要件に応じてSSD又はHDD-SSDハイブリッドストレージを選択する。一方、ファイルサーバやアーカイブ等、高いIOが要求されないアプリケーションの場合は、性能要件に応じてHDD又は分散ストレージを選択する。一般に価格はSSD＞HDD-SSDハイブリッド＞HDD＞分散ストレージの順に高価であり、性能要件が満たせる安価なストレージが選択される。
【００５２】
以上より、本実施の形態では、リソース選択装置１が、ユーザの性能要件及び機能要件が特定の計算処理、画像処理、又は並列処理を一定以上の処理性能で処理することを要求しているかに基づき、少なくともFPGAとGPUを含む複数の計算リソース、複数の記憶リソース及び複数のプロビジョニング方法から所定の計算リソース、所定の記憶リソース及び所定のプロビジョニング方法をそれぞれ選択するので、特定の計算処理、画像処理、又は並列処理に特化した高い処理性能を実現するクラウドサービスを提供することができ、さらにユーザによるサーバ構成設計等の稼働や労力を低減することができる。
【００５３】
また、本実施の形態では、リソース選択装置１が、動作させるアプリケーションプログラムの特性に応じて記憶リソースを選択するので、HDD、SSD等が混在している中、高いIOが要求されるOLAP等の処理を行いたいユーザに対してSSD等の高いIOを持つストレージを提示することができる。
【００５４】
また、本実施の形態では、リソース選択装置１が、CPU、GPU、FPGA等が混在している中、特定の計算処理を高速で行いたい場合は、その計算に最適化されたFPGAを備えたハードウェアをベアメタルプロビジョニングし、画像処理を高速で行いたい場合は、GPUが強化されたハードウェアをベアメタルもしくはコンテナでプロビジョニングし、それ以外の場合は通常のCPUサーバに、ベアメタル、コンテナ、ハイパーバイザーでプロビジョニングするので、ユーザは計算リソース上で高い処理性能を実現できる。
【００５５】
＜第２の実施の形態＞
第１の実施の形態では、リソース及びプロビジョニング方法の選択方法について説明した。一方、第２の実施の形態では、ユーザの要求に応じてリソースを選択及び構成し、さらにユーザによるリソースの利用方法の変化に応じて該リソース構成を再構成する方法について説明する。
【００５６】
図４は、第２の実施の形態に係るリソース構成システムの全体構成を示す図である。このリソース構成システムは、リソース及びプロビジョニング方法を構成及び再構成するリソース再構成装置７と、その構成又は再構成結果に基づきリソース構成を構築又は再構築するIaaSコントローラ３と、を備えて構成される。
【００５７】
続いて、リソース再構成装置７について説明する。このリソース再構成装置７は、ユーザ端末５で入力されたユーザの性能要件及び機能要件を受け付ける要求受付部７１と、受け付けた要求に基づきリソース及びプロビジョニング方法を構成又は再構成するリソース再構成部７２と、その構成又は再構成結果をユーザ端末５へ通知する再構成結果通知部７３と、その構成又は再構成結果に対するユーザの承認指示に基づきリソース設定をIaaSコントローラ３へ要求する設定要求部７４と、構成又は再構成されたリソースに対するユーザの利用頻度を収集するリソース利用頻度収集部７５と、リソース及びプロビジョニング方法の構成時及び再構成時に用いる情報を記憶するデータ記憶部７６と、を備えて構成される。
【００５８】
なお、リソース再構成装置７は、CPU等の演算機能やメモリ等の記憶機能を備えたコンピュータで実現可能である。また、そのコンピュータを機能させるためのプログラムや該プログラムの記憶媒体を作成することも可能である。さらに、リソース再構成装置７は、リソース選択装置１又はIaaSコントローラ３と物理的に異なる装置として機能させてもよいし、リソース選択装置１又はIaaSコントローラ３の一機能としてもよい。
【００５９】
次に、リソース再構成装置７の動作について説明する。ここでは、FPGA内部の計算ロジックを再構成する場合について説明する。これは、各目的の計算ロジックをそれぞれ備えた複数のFPGAを予め用意しておくことは高コストであることを考慮したものであり、ユーザの利用状況に応じてFPGAの計算ロジックを最適化するようにする。
【００６０】
本動作例では、２つの動作パターンを用いて説明する。１つ目はFPGAの計算ロジックを構成する動作である。２つ目はユーザのリソース運用中にFPGAの計算ロジックを再構成する動作である。
【００６１】
最初に、１つ目の動作パターンについて説明する。図５は、FPGAサーバに対する計算ロジックの構成処理フローを示す図である。
【００６２】
まず、要求受付部７１は、ユーザによりユーザ端末５で指定された性能要件及び機能要件を受信する（ステップＳ２０１）。なお、機能要件とは、高速化が必要な計算ロジックが必要か、どのようなアプリケーションが動作するか、等に関する情報である。また、性能要件とは、スループットやレイテンシー等に関する情報である。
【００６３】
次に、リソース再構成部７２は、ステップＳ２０１で指定された性能要件及び機能要件に基づきFPGAサーバの計算ロジックを構成し、さらにプロビジョニング方法を選択する（ステップＳ２０２）。具体的には、使用されていないFPGAサーバを選択し、指定された性能要件及び機能要件に応じた計算ロジックを設定する。高速化が必要な計算ロジックが指定されていない場合は、アプリケーションの種類に応じて構成するようにしてもよい。その構成処理自体については公知技術を用いて実現可能である。例えば、NoSQLでのFPGAによるアクセラレートについては、Data Engine for NoSQL - IBM Power Systems Edition White Paper等に記載されている。この記載内容に基づく構成に設定することを予めリソース再構成装置７の内部で定義しておけばよい。FPGAの構成又は再構成にかかる時間は一般的に数十ms程度で可能であり、ユーザ要件に応じて構成又は再構成しても問題はない。FPGAサーバに対する計算ロジックの具体的な構成手順例については後述する。なお、プロビジョニング方法については、ここではFPGAサーバを対象としているため、図３のステップＳ１０２ｂと同様にベアメタルを選択する。
【００６４】
次に、再構成結果通知部７３は、ステップＳ２０２で構成されたFPGAへの計算ロジック及び選択されたプロビジョニング方法をユーザ端末５へ送信する（ステップＳ２０３）。それを受けたユーザ端末５は、受信した計算ロジック及びプロビジョニング方法を提案リソース及び提案プロビジョニング方法として画面に表示する。ユーザ端末５のユーザは、その提案内容を確認し、問題なければ承認指示をリソース選択装置１に返信する。このとき、問題があれば、FPGAに設定する計算ロジックをユーザが指定して返信してもよい。
【００６５】
最後に、設定要求部７４は、ユーザにより承認されたリソース及びプロビジョニング方法を指定してIaaSコントローラ３にリソース設定・生成を要求する（ステップＳ２０４）。その後、IaaSコントローラ３は、リソース選択装置１からの該要求に基づきリソースを確保する。これにより、ステップＳ２０２で構成及び選択された計算ロジックとプロビジョニング方法が未使用のFPGAサーバで利用されることになる。
【００６６】
続いて、ステップＳ２０２で行う計算ロジックの具体的な構成手順について説明する。図６は、FPGAサーバに対する計算ロジックの構成処理フローを示す図である。
【００６７】
まず、ユーザの機能要件及び性能要件が、特定の計算処理用の計算ロジックを指定しているか否かを判定する（ステップＳ２０２ａ）。
【００６８】
ステップＳ２０２ａの判定結果がYesの場合、指定された特定の計算ロジックを用いてFPGAサーバを構成する（ステップＳ２０２ｂ）。一方、ステップＳ２０２ａの判定結果がNoの場合、ユーザにより指定されたアプリケーションタイプに対応する計算ロジックがリソース構成システム上で利用できるか否かを判定する（ステップＳ２０２ｃ）。
【００６９】
その後、ステップＳ２０２ｃの判定結果がYesの場合、指定されたアプリケーションタイプに対応する計算ロジックを用いてFPGAサーバを構成する（ステップＳ２０２ｄ）。一方、ステップＳ２０２ｃの判定結果がNoの場合、ユーザに対して利用可能な１つ以上の計算ロジックを提示し、それに応じて指定された計算ロジックを用いてFPGAサーバを構成する（ステップＳ２０２ｅ）。
【００７０】
なお、指定する構成をFPGAに反映する方法としては、例えば、FPGAを開発しているアルテラ社やザイリンクス社が提供している開発ツールを用いて反映すればよい。
【００７１】
ここまで、１つ目の動作パターンについて説明した。なお、この１つ目の動作パターンでは、FPGAに対して計算ロジックを新規に設定する場合について説明したが、後述するように既に設定されている計算ロジックを変更する場合でも図５及び図６の「構成」を「再構成」と読み替えることによりそのまま流用することができる。
【００７２】
続いて、２つ目の動作パターンについて説明する。再度説明するが、この２つ目は、ユーザのリソース運用中にFPGAの計算ロジックを再構成する動作である。図７は、FPGAサーバに対する計算ロジックの再構成処理フローを示す図である。この２つ目の動作は、例えば１つ目の動作の後に行われる。
【００７３】
まず、リソース利用頻度収集部７５は、各FPGAサーバでユーザが利用している各種計算処理の利用頻度をそれぞれ定期的に収集する（ステップＳ３０１）。例えば、グラフ分析の回数が１時間に何回であるか、NoSQLのCRUD処理が１時間に何回であるか、等の回数をFPGAサーバ毎に収集する。
【００７４】
次に、リソース再構成部７２は、FPGAサーバに設定されている計算ロジックの種類に基づき各FPGAサーバの得意な計算処理を検出し、検出された各FPGAサーバでの得意な計算処理の種類と該各FPGAサーバにおける各種計算処理の回数とを定期的に照合し、その照合結果に基づきFPGAサーバを再構成した方がよいかを判定する（ステップＳ３０２）。例えば、グラフ分析が得意なFPGAサーバ上で、グラフ分析回数が１時間に１０回行われ、NoSQLのCRUD処理が１時間に１００００回行われている場合、NoSQL処理に得意なFPGAサーバへ再構成する方が適切である。それゆえ、ステップＳ３０２では、例えば、得意な計算以外の計算回数が一定の閾値を超えた場合に、FPGAサーバの再構成が適切であると判定する。なお、グラフ分析が得意なFPGAサーバとは、グラフ分析用の計算ロジックが設定されているFPGAサーバである。
【００７５】
次に、再構成結果通知部７３は、ステップＳ３０２でFPGAサーバの再構成が適切であると判定した場合、計算ロジックを変更すべき旨の通知をユーザ端末５へ送信する（ステップＳ３０３）。例えば、上記例の場合、該当のFPGAサーバ設定されているグラフ分析用の計算ロジックをNoSQL用の計算ロジックに変更した方が適切である旨及びその理由をユーザへ提案する。それを受けたユーザ端末５は、受信した計算ロジックの変更案を画面に表示する。ユーザ端末５のユーザは、その提案を確認し、問題なければ承認指示をリソース選択装置１に返信する。このとき、問題があれば、FPGAに設定する計算ロジックをユーザが指定して返信してもよいし、再構成を行わない指示を返信してもよい。
【００７６】
最後に、リソース再構成部７２は、ユーザが利用しているFPGAサーバを選択し、ユーザによる承認結果に基づき、計算回数が増えた計算ロジックが高速化されるように該FPGAサーバの計算ロジックを変更する（ステップＳ３０４）。上記例の場合、グラフ分析用の計算ロジックを利用頻度が増大したNoSQL用の計算ロジックに変更する。FPGAの再構成にかかる時間は一般的に数十ms程度で可能であり、FPGAサーバの動作中に再構成しても問題はない。
【００７７】
これまで、FPGA内部の計算ロジックを構成及び再構成する場合について説明した。勿論、異なる計算ロジックを持つFPGAサーバ間、異なる種類の計算リソース間や記憶リソース間、異なるプロビジョニング方法同士についても、それら各間において、ユーザの変更後の性能要件及び機能要件、計算リソースに対するユーザの利用頻度に基づき変更することも可能である。
【００７８】
ここまで、２つ目の動作パターンについて説明した。この２つ目の動作パターンは、第１の実施の形態で用いたリソース選択装置１よりプロビジョニングされ、事前に特定の計算処理が最適化されたFPGAサーバに対して適用してもよい。
【００７９】
以上より、本実施の形態では、リソース再構成装置７が、ユーザの要件に応じて、特定の計算ロジックに最適化したFPGAサーバに設定を変更し、ベアメタルプロビジョニングするので、ユーザは高い処理性能を実現できる。
【００８０】
また、本実施の形態では、リソース再構成装置７が、FPGAサーバ上でユーザがシステム運用をしている場合、そのFPGAサーバでユーザが利用している各種計算処理の利用頻度をそれぞれ収集し、ユーザの利用方法の変化により特定の計算処理が増大してきた場合、増大した計算処理に合わせてFPGAサーバの構成を変更するので、ユーザはFPGAサーバ上でより高い処理性能を実現でき、さらに各種の計算ロジックを備えた複数のFPGAサーバを予め準備する必要性を低減することができる。
【００８１】
最後に、第１の実施の形態及び第２の実施の形態では、ユーザ要件に対して適切なリソース構成を提案する方法について説明したが、その一方でユーザは該提案内容で十分であるかを実際に確認する必要がある。そのような場合、提案されたリソース構成の性能を検証する性能検証装置を利用することも考えられる。例えば、非特許文献１は、サービス事業者側が提案したサーバ構成での性能を自動検証する仕組みを備えており、それらを利用することでユーザは容易に性能検証を実施可能となる。
【符号の説明】
【００８２】
１…リソース選択装置
１１…要求受付部
１２…リソース選択部
１３…選択結果通知部
１４…設定要求部
１５…データ記憶部
３…IaaSコントローラ
３１…OpenStack API
３２…リソース構成構築部
３３…OpenStack DB
５…ユーザ端末
７…リソース再構成装置
７１…要求受付部
７２…リソース再構成部
７３…再構成結果通知部
７４…設定要求部
７５…リソース利用頻度収集部
７６…データ記憶部
Ｓ１０１〜Ｓ１０４、Ｓ１０２ａ〜Ｓ１０２ｋ、Ｓ２０１〜Ｓ２０４、Ｓ２０２ａ〜Ｓ２０２ｅ、Ｓ３０１〜Ｓ３０４…ステップ
【図１】
2017029826.tif 000003
【図２】
2017029826.tif 000004
【図３】
2017029826.tif 000005
【図４】
2017029826.tif 000006
【図５】
2017029826.tif 000007
【図６】
2017029826.tif 000008
【図７】
2017029826.tif 000009
【国際調査報告】
2017029826.tif 000010
2017029826.tif 000011