2009年度森基金 活動報告書

研究課題名:省電力化のためのアプリケーション別電力管理機構

氏名:森 雅智

所属:政策・メディア研究科

 

要旨

 サーバの仮想化・並列化技術の発展を要因としたクラウドコンピューティングの発展により,GoogleAmazonといったクラウドインフラを提供する企業は多くのPCを備えたデータセンターを保有している.また,国内においてもプライベートクラウドと称したサービスに取り組んでいる企業は多く,サービスやソフトウェアのクラウド化に伴って,今後も多くのデータセンターが必要とされていくと考えられる.こうしたデータセンターにおけるコストダウンは重要な課題である.特に昨今のサービス単価の低価格化を考慮すると,インフラ維持コストを下げなければ利益も少なくなってしまうため,対応策が望まれている.

 こうしたデータセンターにおけるコストの中で大きなウェイトを占めるのが電気代である.電気代の大部分はサーバの冷却にかかる費用であるが,熱源となっているのはサーバのCPUやディスク,ネットワークカードと言ったPCそのものの電力である.それらのサーバ上のデバイスは,動作しているソフトウェアによって大きく発生する消費電力が変動する.つまり,サーバ上で行っている処理の量に応じて必要な冷却コストが変動するので,クラウドコンピューティング環境の様に複数のユーザーが一つのPCを共有する環境においては,ユーザーが使っているアプリケーションの消費電力に応じて課金することができればインフラ側の冷却コストに見合った課金を行うことができる.現在はIaaSInfrastracture as a Servie)型のVPSVirtual Private Server)を提供するクラウドなどでは,常時フル回転で稼働させようが,特に何もサービスを稼働させていようが課金される料金が同じであるため,不公平感が強い.

 本研究では,こうした問題を解決するため,アプリケーション別電力管理機構pSurviveを開発し,サーバ上で動作しているアプリケーションの消費電力のアプリケーション毎測定を実現した.デバイス使用量をリアルタイムで取得することにより,アプリケーションの消費電力を取得することができる.

 

システム設計

 本章ではpSurviveのシステム設計について述べる.pSurviveの基本設計については,修士論文[1]に詳しい内容がまとまっているため,本報告書では全体の設計と重要な部分のみ掲載する.

想定環境

 本システムはLinuxが動作するPCを動作要件としている.Linuxを採用した理由は以下の通りである.

l   昨今のサーバ用OSとして一般的である.特に,仮想化を想定した環境においてはほとんどがLinuxシステムであることが多い

l   Kernelのソースコードが公開されており,開発に適している.本研究ではデバイスの使用量を取得するなど,OSに近い部分の情報を取得する必要があるため,オープンソースソフトウェアであることによる利点は大きい

 

システム構成

 pSurviveの全体構成は下図の通りである.

:::::Downloads:image002.png

pSurviveは図に示したとおり,消費電力計測・予測機構と動作時間保証機構によって構成される.

 

アプリケーション別消費電力計測・予測機構

 本節では pSurvive の根幹であるアプリケーション別消費電力計測・予測機構の設計について解説する.まず pSurvive が用いる消費電力量モデルを示し,その後各変数をどのようにして計測し定義するかを示す.

消費電力量モデル

 pSurvive では,アプリケーションの使用電力量を各アプリケーション,各デバイス別に計測し,それらの電力の和を全体の消費電力として扱う.まず,ノードがn 個のデバイスを持っていると考える.このデバイスとは,CPU やメモリ,ネットワークやHDDといった電力を消費するハードウェアを指し,各デバイスをd1, d2, d3, ..., dn とする.そして,各デバイスの単位使用量あたりの消費電力をc[mW/units] とし,c1, c2, c3, ..., cn とする.これは例えばCPU1秒間動作させるのに必要な電力といったものに対応する.この単位使用量の単位unit とは,デバイスによって定義が異なる.例えばCPUといったデバイスでは使用時間が電力消費量の指標になるが,ネットワークでは送受信したデータ・パケット量で使用電力が決まるため,時間ではなくデータ量・パケット数となる.この時,デバイスの消費電力の合計E はデバイスの使用量をt [units] とすると,E =ct [mW] で表される.そのため,各デバイスの使用時間をt1, t2, t3, ..., tn とすると,ノード全体の消費電力量は以下の式で表される.

:::::Downloads:image006.png

 次に,ノード上ではm個のアプリケーションが動作しているとし,p1, p2, p3, ..., pmで表す.このアプリケーションはアプリケーションに対応している.アプリケーションは各デバイスを使用するため,アプリケーションの使った各デバイスの消費電力量の総和がそのアプリケーションの消費電力量であると考えられる.ここで,アプリケーションp がデバイスd を使用した使用量を求める関数f(p, d) を定義する.すると,アプリケーションp の消費電力Ep は以下の式で表される.

:::::Downloads:image008.png

 ここで,OS や待機電力を特殊なアプリケーションとして抽象化すると,デバイス全体の消費電力は各アプリケーションの消費電力の和となる.そこで,これまでの2式から以下の式がが導き出される.

:::::Downloads:image010.png

 pSurvive では,この式に従って消費電力を計測する.そのために必要な情報はf(p, d)及びc,つまりアプリケーションがどのデバイスをどれだけ使っているのかという使用量と各デバイスの単位使用量あたりの消費電力量である.よって,アプリケーション別の消費電力計測ではこの二つを計測する.

 

アプリケーション別消費電力量の計測

 まず,アプリケーションのデバイス使用量を計測する方法については,アプリケーションはデバイスを使用する際に必ずデバイスドライバを通してアクセスを行うため,デバイスドライバに機能を追加するという手法を用いる.アプリケーションがデバイスを使用する度に使用量を通知するという手法も考えられるが,この場合デバイス上の全てのアプリケーションに修正の必要があるため,現実的ではない.また,CPU やメモリについてはデバイスドライバに相当するものが無いため,OS の統計情報などからデータを取得する.

 次に,デバイスの単位使用量あたりの消費電力量c については前もってキャリブレーションを行い,実測値から求めることで対応する.しかし,キャリブレーションで得た値を静的に利用するのでは動作環境に大きく影響を受けるデバイスについて,実際の値と大きく異なった値になってしまう恐れがある.例えば,ネットワークカード を考えた場合,送信についてはアプリケーションが明示的にデバイスドライバを通して送信を行うため計測可能であるが,受信の際のOS オーバヘッドを考えた場合,LANチップレベルではブロードキャストパケットやマルチキャストパケットといった,自分宛以外のパケットも受信してしまうため,多くのLAN 機器が同じネットワークセグメントで通信している環境の場合,消費電力量がキャリブレーション時と異なる値になってしまう.こうした問題に対応するために,システムの動作時には静的な値だけでなく動作環境に応じてc を微調整していく必要がある.

 

アプリケーション動作時間保証機構

 保証対象となるアプリケーションをR1,R2,R3, ...,Rk し,それぞれに要求された保証時間をT1, T2, T3, ..., Tk とする.すると,アプリケーションR T だけ動作するために必要な電力量ER は電力計測の式から以下の式で表される

:::::Downloads:image012.png

 よって,全ての保証対象アプリケーションが必要な電力量Erequired

:::::Downloads:image014.png

 となる.

 

実装

 本章ではpSurviveの実装について述べる.実装においては,2008年度森基金報告書で記載したARMアーキテクチャのマイクロユビキタスノード向けpSurvivex86アーキテクチャでも動作するようにポーティングした.具体的には,組み込みデバイスでは専用のレジスタを参照して取得していたデバイス使用量などを,一般的なsysfsといったカーネル情報から取得するように修正したり,ロギング部分や消費電力ビューアについて,より柔軟な計測ができるようにコードをスクラッチから再設計し直した.

 

アプリケーション別消費電力計測・予測機構

pSurvive の実装では,消費電力計測・予測機構をデバイス毎に実装するモニタリングモジュールとデータ集約モジュール,消費電力予測モジュールの三種類に分割した.その構成を表したものが以下の図である.

:::::Downloads:image020.png

 それぞれのモジュールは動作レベルでは互いに独立しており,それぞれ別途開発が可能である.このようにモジュールを分割することで,各部の機能追加や交換を可能とし,拡張性を高めた.

モニタリングモジュール

 モニタリングモジュールは各デバイスに依存するモジュールで,基本的にデバイスと一対一で対応する.モニタリングモジュールが最低限持つ機能はデバイスの使用量をカウントする機能で,後述するデータ集約モジュール内のアグリゲータからの要求に応じてアプリケーション動作中のデバイス使用量をカウントする.デバイス使用量は CPU なら使用時間,ネットワークであればパケット数といったものが単位となる.モニタリングモジュールはデバイスに対応するものであり,同じデバイスを使っているノードであればそのまま再利用できる.

 具体的な実装方法はデバイスに大きく依存するところがあるが,基本的には Linux Kernel ModuleLKM)を用いて実装することを想定している.LKM を用いて実装する理由はデバイスとアプリケーションの対応を取るためである.アプリケーションレベルで実装してしまうと,デバイスの使用量を取得することはできるが,その消費量がどのアプリケーションに関連付いているかを取得することができない.なぜならば,モニタリングする時点で既にスケジューラはモニタリングアプリケーションに処理を渡してしまっているので,実際にデバイスを使用したアプリケーションが限定できないからである.

LKM によって実装することでこの問題を解決する.LKM によってデバイスのモニタリングを実装することで,コンテキストスイッチ無しにデバイスの使用量を監視することができる.これにより,デバイス使用時にスケジューリングを割り当てられているプロセスが実際にデバイスを使用したアプリケーションとなるため,デバイスとアプリケーションの対応を取ることができる.

データ集約モジュール

 データ集約モジュールは,定期的にモニタリングモジュールに対してデバイスの消費量を取得するアグリゲータと,取得したデータを時系列で保存する消費電力履歴データで構成される.

 アグリゲータは特定の周期でモニタリングモジュールに各アプリケーションのデバイス消費量を問い合わせ,消費電力履歴として保存する.モニタリングの周期を短くすることで,よりアプリケーションの詳細なデータが取れるが,その一方でデータ集約モジュールのオーバヘッドは増加する.

 データ集約モジュールは LKM によるカーネルレベルでの実装ではなく通常のアプリケーションとして実装する.その理由はデータ集約モジュール自体も電力を消費するため,オーバヘッドを考慮する必要があるからである.LKM による実装を行った場合,pSurvive の消費電力は OS のオーバヘッドに含まれることになるが,pSurvive の評価を行う段階で pSurvive を搭載することによるオーバヘッドを測定することができない.また,LKM による実装では利用できる OS の機能が著しく限定されてしまうため,消費電力履歴の保存先の変更といった柔軟な対応が難しくなるということも理由の一つである.

消費電力予測モジュール

 消費電力予測モジュールは,アプリケーション別動作時間保証機構からの要求に応じて,データ集約モジュールが保存した消費電力履歴を元に消費電力予測を行うエスティメータと,その予測アルゴリズムで構成される.消費電力予測モジュールは,マイクロユビキタスノード版のpSurviveにおいてはバッテリ予約の為に重要な機能であったが,本研究における対象はサーバであるため,重要度は下がった.しかし,予測モジュールを使うことでユーザーに対して今後の使用予測電力を提供することができるため,ユーザーに提供する情報としては有益である.その為,消費電力予測モジュールについてもx86版へのポーティングを行った.

 消費電力予測は時系列のデータから未来の消費電力を予測するものであるが,必ずしも全てのアプリケーションに対して一つのアルゴリズムが精度の高い予測結果を返すとは限らない.例えば,ほぼ一定周期で動作するバッチ処理のようなアプリケーションであれば,過去のデータからの移動平均といった値が合致すると考えられるが,Webアプリケーションのような利用者の使用や環境によって電力消費の傾向が大きく変わるアプリケーションの場合,移動平均だけでは精度の高い予測は難しい.そのため,消費電力予測モジュールでは複数のアルゴリズムを用意し,アプリケーションに応じた予測アルゴリズムを選択可能としておく.これにより,アプリケーション毎に柔軟な予測を行うことができ,予測精度が高まる.本論文における実装では,2 種類の予測アルゴリズムを用意する.一つは,消費電力モジュールが直近に計測したのと同じ量の消費電力を使うという単純なモデルである.このモデルは常に電力消費が一定になるようなアプリケーションに最も適合すると考えられる.もう一つは移動平均アルゴリズムである.但し,パラメータとして参照する履歴の幅を指定できる様にする.履歴の幅を短く設定すると,急激な値変動に対して敏感に予測値が変動するため,より早くアプリケーションの消費電力変動に対応できる一方で,一時的な値変動の影響を大きく受けてしまう.これは電力を消費するときにある程度長い期間,急激に消費するようなアプリケーションが適合するだろう.また,履歴の幅を長く設定することで,一時的な値変動の影響は小さくなるが,値変動後に変動後の値が続くような場合には予測値が理想値に近づくのが遅くなる.このアルゴリズムは短い時間に一時的に消費電力が大きくなる様なアプリケーションが適合するだろう.

 消費電力予測モジュールもデータ集約モジュールと同じく通常のアプリケーションとして実装する.その理由もデータ集約モジュールの場合と同じく,拡張性のためである.特に予測アルゴリズムを容易に追加,交換可能とすることは pSurvive の汎用性を高めるために重要な点である.

消費電力ビューア

 既存のマイクロユビキタスノード向けpSurviveで実現していた機能に加えて,サーバシステムにおいてはユーザが消費電力を容易に閲覧できるGUIが必要となる.本研究ではGUIWebアプリケーションとして実装した.Webアプリケーションには以下の機能が含まれている.

1.       現在のアプリケーション別消費電力量をグラフ表示する機能

2.       アプリケーションの消費電力量履歴をグラフ表示する機能

3.       RESTful APIとして,pSurviveが持っている情報に外部のアプリケーションからアクセスできること

 1,2については特にWebアプリケーションである必要は無いが,昨今のクラウドサービスはほぼ必ずと言っていいほどWebブラウザからアクセスするインターフェースを持っているため,Webアプリケーションとして提供した方が利便性が高い.3についてはpSurviveの持つデータを専用Webアプリケーションだけではなく外部からアクセスできるようにすることで,マッシュアップアプリケーションの開発が可能となり,応用の幅が広がる.GoogleAmazonのクラウドサービスもSOAPRESTといった形でAPIを公開しているため,pSurviveでもその流れを踏襲した.

 

研究成果

 本章では本研究における成果について述べる

既存のマイクロユビキタスノードのx86

 修士論文において特定のマイクロユビキタスノード向けに開発していたコードを一般的なx86サーバ上で動作するようにポーティングした.これにより,従来は専用デバイスでしか動作しなかったpSurviveを,現在一般に出回っている多くのPC上で動作させることができるようになった.

 このことは本システムの今後の普及にあたり大きな成果といえる.

ネットワーク使用量計測

 ネットワーク使用量はOSレベルではネットワークインターフェース単位で管理されているため,従来はアプリケーション毎に使用量を出すということは難しかった.本研究では,ntop (http://ntop.org/)というネットワークアナライザを用いTCPポート番号毎のネットワーク通信量を計測すると共に,OSから現在のTCPセッションデータを取得し,TCPセッションとプロセスのマッピングからアプリケーションのネットワーク使用量計測を実現した.これにより,サーバシステムでは大きなウェイトを占めると思われるネットワーク使用量について,アプリケーション毎の計測が可能となった.

 ネットワーク帯域は電力とは別にクラウドサービスのコスト要因となっているので,ネットワーク使用量が計測できるようになったことは非常に大きな成果といえる.

Webブラウザからのデバイス使用量表示

 マイクロユビキタスノード用pSurviveではハードウェアリソースの制約からテキストベースでのAPIしか用意していなかったが,サーバシステムにおいてはデバイス使用量を容易に一覧できるGUIが必要であった.そこで,現在のデバイス使用量や,アプリケーションにおける過去のデバイス使用量をグラフでわかりやすく表示するGUIWebアプリケーションとして開発した.

 以下に画面のスクリーンショットを添付する.

Screenshot-110218

Screenshot-110218-3

 こうしたわかりやすいデータの可視化は,ユーザーに情報を過不足無く伝えるために必須である.そのため,本研究において可視化機能を実装したことは大きな成果である.

 

まとめ

 本研究では昨今増え続けるサーバシステムの消費電力コストに着目した.今後クラウドサービスが増えて行くにあたって,サーバの数は増え,それに伴う総消費電力も増えていくことが容易に予測される.そうした時代に答えるため,本研究ではサーバシステムを対象としたアプリケーション別電力管理機構pSurviveを開発した.

 pSurviveではアプリケーション毎に各デバイスの使用量を計測し,そこから消費電力を求めるため,一台のサーバを複数人で共有しているようなモデルでもユーザ別に消費電力を計測することができる.

 本研究の成果により,サーバ上で動作するプログラムの電力使用状況に応じた課金モデルの構築といった,より実際のリソース使用量に応じたサービスを構築することが今後可能となるだろう.

 

[1] 2008 年度修士論文 マイクロユビキタスノードにおける高可用性を実現するバッテリ管理機構 March, 2009