twitter icon   twitter icon   rss icon

Linux.com Japan

Home 特集 仕掛け人に聞く 資源管理機能cgroup開発の仕掛け人 亀澤 寛之氏

仕掛け人に聞く 亀澤寛之氏

杉田:  ところで、現在は、メモリも豊富に仕えるメニコア時代で、資源を使い切れなくなってcgroupへの期待も大きいですよね。でも、過去には資源管理の要求が薄れた時期があります。2000年頃、CPUが高速になって、大容量メモリが出て、マシンも安くなって。だから1台のマシンで資源を分割管理しなくてもスケールアウトすればよい、という考えが生まれた。同じようにハードに革新が起きたら、cgroupの効力がなくなるってことはあるでしょうか?


亀澤:  その可能性はあるかもしれません。でも、結局、システム余力が不足している時や余り過ぎる時には、資源管理したいって気持ちになると思いますよ。ソフトによる解決とハードによる解決って形を変えながら順繰りに発生する気がしますね。cgroupが不要になることはないと思っています。それに、革新が起きるとハードがもっと複雑になって、cgroupでの緻密なリソース管理がますます重要になってくるかもしれない。逆に要求が増えるかもしれませんね。


杉田:  確かに、コア数が増えたときにこう分けたいなど、さらに複雑な要望が来るかもしれませんね。


亀澤: そこまで複雑な使い方が出てくると、逆に面白いです。でも、そういう運用が出てくるのは、もっと先のような気がしますね。


杉田: では、どれか1つのグループの稼働率が上がってきたときに、メモリやCPUなどのリソースをそこに動的に移したいという要望はどうでしょう?


亀澤: その要望はありますね。でも、リソースの移動制御は、カーネルではなくミドルウェアでやった方がよいと考えています。ただし、そのミドルウェアは、cgroupを使って、他のアプリケーション等の影響を受けないようにしておく必要はあるでしょうけど。また、バッチジョブのスケジューリングを計画的に実施するために使いたいという要望は聞きますね。例えば20分で処理したいジョブがある。終わるのは20分以上でも20分以下でもいけない、20分きっかりに終わらせたい、という要望。そのためのリソース制御をしたいと。でもこれが難しい。


杉田: 何かのタイミングと合わせるために、20分という時間が重要になるケースでしょうか。


亀澤: そうだと思います。HP-UXや他のOSだと、アプリと連携して、アプリが今の進捗は何%ですというと、リソースを増やしたり減らしたりして時間を調整する機能があったはずですが、、Linuxにはまだその機能はないですからね。
たぶん、カーネルはそこまで踏み込まないから、ミドルがアプリと連携して実現していくのかな、と思います。カーネルは、今CPUやメモリをどれくらい使っているかを知ることはできても、アプリの仕事が何%終わったかはわからないし、このあと何かを変えるべきかもわからないですから。


杉田: 言われてみれば、Linux/cgroupが得た数値がどういう意味を持つのかがわかるのは、実行しているアプリですからね。


亀澤: そうです。そして、アプリが実際に欲しいリソースは何か伝えたり推測したりするAPIも必要になります。でも、個々のディストリビューションで対応していくのは大変だし、ミドルウェアで勝手に持つと対応するアプリケーションも大変。共通化APIがいるのかなぁ、と思ったりもします。


杉田: なるほど。では、仮想化環境との融合はどうなのでしょう? 今もうすでに連携が始まっていると思いますが。


亀澤: ディストリビューションでは、libvirtを使ってQEMUを管理していると、勝手にcgroupに入れてくれます。最近は、libvirt側にcputuneのようなcgroup専用のチューニングコマンドがサポートされています。最新版のlibvirtを使えばいろいろなコントロールができますよ。


杉田: それはいいですね。cgroupのメンバとlibvirtのメンバが連携して実現しているのですか?


亀澤: 期待に添えなくて申し訳ないけど、活発に連携開発しているわけではありません。cgroupの最新機能が出ると、どこかの誰かが話をしてlibvirt側で実装、という感じですね。


杉田:  必要と思った人が話をしているのですね。亀澤さんも、その実装に参加しているんですか?


亀澤: 僕自身は参加していませんが、富士通の同じグループの開発者がやっています。


杉田: なるほど。6月のLinuxCon Japan 2011では仮想化ミニサミットが開催されますが、今回のメインテーマは運用なんです。libvirtの開発関係者も発表するので、その開発者の方も亀澤さんも、ぜひ活発な議論をお願いします。


亀澤: それは楽しみです。


杉田: ところで、cgroupはRed Hatだと2010年11月に出荷されたRHEL6からサポートされていますよね。世界中のシステムで使われると考えると、開発者冥利につきるのでは?


亀澤: やっと出たか、という安堵感が大きいです。実は、RHELに採用されるためには、まずFedoraに入らないといけない。ところが、cgroupをoffにする機能がないとFedoraに入れられないと言われて。cgroupを使わないユーザのために、cgroupの影響を性能面で受けない仕組みが必要だったんです。デフォルトはonでも、コンフィグでもbootオプションでもoffできる仕組みがあるので、あまり重要と考えていませんでした。、Fedoraの要求は、デフォルトで影響なしにすること。 IBMの開発者も一緒に対応してくれましたが、すぐに作って欲しいと言われて慌てましたね。


杉田: cgroupをまだ使わないユーザが多いと踏んだのでしょうか?


亀澤: デスクトップやノートPCで使う限りは、必要ないのでしょう。


杉田: なるほど。でも、Fedoraのリリース期間を考えると、開発期間は短かったのでは?


亀澤: そうなんです! Fedoraに入るかどうか、やきもきしました。だから、RHELでサポートされた時にはほっとしたわけです。


杉田: ところで、cgroupという機能を開発することに対して反対意見はなかったのですか?


仕掛け人に聞く 亀澤氏亀澤:  反対意見という程ではありませんが、少し古い話になりますけど、僕がcgroupに最初に参加した頃に、cgroupがなくてもVMで十分では、という意見がありました。でも、VMで実現すると、VM間通信のオーバヘッドが出るとか、余計な管理コストがかかるとか、いろいろ課題はあったので、やはりcgroupは必要だと思いましたね。もちろん、今後、VM側ががんばってこれらの課題を解決してしまうかもしれませんけど。いずれにしても、それぞれに特徴があるので、用途によって使い分ければよいのだと思います。cgroupの開発をやめる理由にはなりませんでした。

杉田: ディストリビューションに入ったことで、cgroup、特にメモリcgroupの開発は一段落ついたのでしょうか? 今後の開発は?


亀澤: 一通りの形ができた、という感じですね。今は次のステップを検討しています。性能向上、アイソレーションをなくす(AとBのグループが存在する時に、お互いの影響を受けないようにする)、などです。あたかも、2つのOSがそこにあるかのように。今はまだそこまで行っていないですから。


杉田: 使い勝手の向上ではなく、信頼性強化、性能強化なんですね? 


亀澤: はい、そうです。使い勝手はいろいろな考え方があり、やり出すときりがないので、今は基本的な部分の強化を優先します。足りない点や改良点はリストアップされているので、その開発を進めていく。ただ、改良を進めていくと、メモリcgroupだけではなくて、Linuxのメモリ管理全体を変えていかなくてはならない可能性があり、そこにどうやって足を踏み入れるべきかが悩みです。


杉田: またLinuxのメモリ管理がガラッと変わる可能性もあるわけですか?


亀澤: 実は、4月にサンフランシスコで開催された、mm summit (memory management summit)で、このメモリcgroupの改良が議題にあがりました。結論からいうと、「変えることを恐れるな」となり、検討を進めることになりました。ただ、影響力が大きい機能なので、変えて行きつつも慎重にやる、というスタンスになると思います。


杉田:  ぜひ、慎重にお願いします。製品として使っている側としては、仕様がガラッと変わるのは大変なことですから。


亀澤: 改良する場合でも、メモリcgroupを使わなければ今までと同じですよ、という選択肢を作る方向で考えています。


杉田: このメモリ管理の改良は何年構想でしょう?


亀澤: 1~2年でやります。そうでないと熱が冷めちゃうので。


杉田: となると、ここ1~2年はメモリ周りに注目ですね! どんな戦略で行きますか?


亀澤: まぁ、パッチをお楽しみに!


杉田: 亀澤さんのcgroup開発はまだまだ続くと?


亀澤:  その予定です。今はcgroupの開発が面白いですからね。もう1~2年くらいは活発に開発をすると思いますよ。


杉田:  話は使い勝手のことになりますが、cgroupの使い勝手の向上の取り組みは何かありますか? 


亀澤:  使い勝手はツールなどで実現するのが良いと思っています。すでに、libcgroupという自動的に配置するツールがあってRed Hatなどのディストリビューションに入っています。ただ、全体のバランスを判定して配置するツールはまだないので、ミドルウェアやアプリケーションに期待ですね。実は、自分でも状況が知りたくて自分用にcgroup用のtopを作っていました。最近、latency topやpower topなどがあるので、cgroup topもあってもいいかな、と。


杉田:  そのcgroup topは、どうなったんですか?


亀澤:  いやぁ、時間がなくなってしまって、まだ途中です。


杉田:  完成させてくださいよ! 期待しています。Cgroupの状況が見えるツールがあると、効果がわかってすごく良いと思いますので。私も使ってcgroupの効果などを観察してみたいです。


杉田:  cgroupの他に、注目している、もしくは興味がある機能がありますか?


亀澤:  Stackable file systemですね。外部ツリーのAufs2とかほとんど完成品で歴史は古いですけど、メインラインはまた別の開発をやってるようなので。VMでジョブを分け、管理する台数が増えたらこういうものの出番じゃないかなと。


 



「仕掛け人に聞く」 バックナンバー

最新パッケージでサポートされたControl Group(以下cgroup)。今回は、その開発でメモリ管理部分のメンテナとして活躍し、ユーザにとって有用な機能の実現を仕掛けている、富士通株式会社の亀澤さんにお話を伺いました。cgroupの開発の動機や現在の状況、コミュニティ開発の様子などをお聞きしました... ...
第二回目は、2010年9月27日~29日に六本木ヒルズで開催されたLinuxCon Japan 2010 において、仮想化ミニサミットを仕掛けた、日本電信電話株式会社のフェルナンドさんにお話を伺いました... ...
第一回目は、2010年9月27日~29日に六本木ヒルズで開催されたLinuxCon Japan 2010 において、トレーシングミニサミットを仕掛けた、(株)日立製作所の平松さんにお話を伺いました... ...
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!