1. NII dodai-deploy2.0 project
クラウドアプリケーションの
マルチプロセス・プログラミングモデル
を実現する「Data Center Kernel」
Ver1.1 2013/02/21
Etsuji Nakai

2. NII dodai-deploy2.0 project
$ who am i
 Etsuji Nakai
– Senior solution architect and cloud
evangelist at Red Hat.
– Working for NII (National Institute of
Informatics Japan) as a cloud technology
consultant.
– The author of “Professional Linux Systems” series.
• Available only in Japanese. Translation offering from publishers are welcomed ;-)
Professional Linux Systems
Technology for Next Decade
2
Professional Linux Systems
Deployment and Management
Professional Linux Systems
Network Management

3. 「クラウドアプリケーション」の３形態

4. NII dodai-deploy2.0 project
クラウドアプリケーション = PaaS上のアプリケーション ？
 PaaSの特徴
– 開発者にはクラウドを（なるべく）意識しないプログラミングモデルを提供
– 実行環境の最適化はPaaS基盤が自動管理
• ユーザによるコントロールの自由度は少ない
– つまり「トラディショナルなアプリケーション開発者」を支える自動化機構
オートスケール
/ 負荷分散など
実行コンテナ
実行コンテナ
アプリケーション
コード
アプリケーション
コード
PaaS基盤
クラウド基盤
4
開発者が用意するのは
「クラウドを意識しない」
アプリケーションコード
実行環境の最適化は
PaaS基盤が自動管理

5. NII dodai-deploy2.0 project
クラウドアプリケーション = クラウド管理ツール？
 RightScale/Scalar/CloudFormsなどのクラウド管理ツールの特徴
– クラウド管理者に実行環境の自動化/最適化ロジックを実装するためのDSLを提供
– 管理者はVMインスタンス内のアプリケーションコードの開発には関わらない
– つまり、「開発済みのアプリケーション」に対する運用の効率化を支える自動化機構
クラウド管理者は、
VMインスタンス内の
アプリケーションの
開発には関わらない
オートスケール
/ 負荷分散など
VMインスタンス
アプリケーション
コード
クラウド管理ツール
自動化スクリプト
VMインスタンス
アプリケーション
コード
クラウド基盤
5
実行環境の最適化ロジックを
クラウド管理者がプログラミング
クラウドAPI

6. NII dodai-deploy2.0 project
本当の意味のクラウドアプリケーションとは？
 PaaSモデルとクラウド管理ツールモデルは、考え方が分断されており、これら
を融合/選択する包括的な利用モデルはまだ見当たらない。
– より汎用的で、どちらの使い方もできて、さらに、今までにない使い方を生み出すよう
なモデルは無いのだろうか？
 ヒント
– PaaS基盤よりも汎用的なクラウド基盤自動化/管理層を用意して、このレイヤーでクラ
ウド上のリソース（VMイメージ/ VMインスタンス等）を抽象化する。
– 専用の管理ツールから自動化を行うのではなく、汎用的なプログラムコードからの自動
化を実現するAPI/ライブラリを用意する。
– このプログラムコードの実行場所は任意に選択可能。
• 専用マシンで実行してもよい
→ クラウド管理ツール的利用法
• アプリケーションが実行されるVMインスタンス内で実行してもよい
→ 「クラウドをあえて意識したプログラミングモデル」を提供するPaaS的な利用法
6

7. NII dodai-deploy2.0 project
汎用的な「クラウドアプリケーション」のモデルイメージ
アプリケーションコード内部にも
自動化の機構を組み込んでしまう
管理サーバ
オートスケール
/ 負荷分散など
クラウド管理ツール
VMインスタンス
VMインスタンス
アプリケーション
コード
アプリケーション
コード
自動化Library
自動化Library
自動化Library
クラウド管理ツール的な自動化
自立分散的な自動化
汎用的なクラウド基盤自動化/管理層
自立分散のために、VMインスタンスリスト
などのグローバル情報はこの層で保持する
クラウドAPI
クラウド基盤
7
それぞれの利用方式に対して
必要なAPIの種類は異なる

8. 「Data Center Kernel」とは？

9. NII dodai-deploy2.0 project
提案
 「自立分散的な自動化」を咀嚼して理解しやすくするように、リソースの抽象化
をトラディショナルなOS（オペレーティングシステム）のリソースモデルに
マッピングしてみる。
– 汎用的なクラウド基盤自動化/管理層 → Linuxカーネル
– VMインスタンス → プロセス
– 自動化ライブラリ → glibc
– 自動化ライブラリからの呼び出し → システムコール
– クラウドAPI → デバイスドライバ呼び出し
9

10. NII dodai-deploy2.0 project
つまりこんな感じ？
管理サーバ
fork / fork&exec
クラウド管理ツール
VMインスタンス
VMインスタンス
libdck
アプリケーション
コード
アプリケーション
コード
libdck
libdck
システムコール
システムコール
Data Center Kernel
デバイスドライバ
クラウド基盤
10

11. NII dodai-deploy2.0 project
さらに類推を進めると・・・
 この類推のもとで、DC Kenrelに必要な機能 / APIを洗い出してみる。
– マシンイメージのビルドデータ → ソースコード
– マシンイメージ → バイナリ実行ファイル
• ビルドデータを「make」するとマシンイメージができる
• lsコマンドでマシンイメージ一覧が取得できる
– VMインスタンス → プロセス
• psコマンドでVMインスタンス一覧が取得できる
• fork / fork&exec命令でVMインスタンスの起動ができる
• upstart/initスクリプトで関連するVMインスタンスの連携起動ができる
– VMの稼働状況/負荷状況 → プロセス負荷
• topコマンドでVMの負荷情報が取得できる
– etc.....
 つまり、DC Kernelに必要な機能は・・・
– vmイメージ作成/管理機能、VMインスタンス起動/管理機能、VMインスタンスのモニ
タリング機能、etc...
11
• 結果的には従来の自動化ツールが持っている/今後実装されるであろう機能にほぼ一致
• しかしながら、従来の自動化ツールをベースに機能追加するよりも、こちらの方がより自然な
モデルで汎用的なプラットホームを実装できるはず。

12. NII dodai-deploy2.0 project
Data Center Kernelモデルの可能性
 VMインスタンス内部のアプリケーションコードからオートスケールなどの処理
が実施可能
– VMインスタンス内部でしか取れない負荷情報に基づいたより精緻なリソース配分
– 単なる負荷状況ではなく、アプリケーションロジックから推定される必要リソース量に
基づく「プロアクティブ」なリソース配分
• Hadoop MapReduceは、データ量の均等割による分散しかできないが、これであれば、アプリ
ケーションコードがデータを解析中に自発的にスケールすることも可能
 プログラミングモデルが、従来のOS上の「マルチプロセス/マルチスレッドプロ
グラミング」に近くなる。
– このモデルから見ると、従来のクラウド上の自動化は、「シングルタスクシステム用の
アプリを擬似マルチタスク化していた」ような制限があるように思える。このモデルで
しか実現できない、新しいクラウドアプリケーションのパラダイムが開けると素晴らし
い。
12

13. NII dodai-deploy2.0 project
Data Center Kernelモデルの可能性
 自動化ライブラリ（glibc）の改変による抽象度の高い自動化を提供可能
– DC Kernel自体に埋め込まないので、アプリケーションごとにライブラリの差し替えが
可能。
• アプリケーションの特性に応じて最適なライブラリを選択可能
• より「インテリジェント」な自動化機構を研究／開発する共通プラットホームとなり得る
 複数クラウドをDC Kernelで束ねることで、「場所を意識しないアプリケーショ
ン実行」が可能に
– 適切なクラウドの選択ロジックなどは、自動化ライブラリのレイヤで実装可能
13

14. NII dodai-deploy2.0 project
その他のアイデア
 VMイメージの提供モデル
– アプリケーションとVMイメージが蜜結合するので、VMイメージは、全世界共通の
UUIDで管理する必要がある。
– 利用するクラウドに必要UUIDのイメージがあればそれを利用。
– ない場合は、ビルドデータから自前でmakeして配置するか、「イメージストア」から
バイナリを購入して、利用するクラウドに配置する。
 クラウド管理ツール的な使い方の例 〜 複数VM連携デプロイ機能の実装
– Upstartのようなイベントベースのフロー管理ツールで、イベントの発生に応じてアク
ションを発生する。
– イベントの種類やアクションの種類は、さらなる検討が必要。
 クラウド管理ツール的な使い方の例 〜 DC Kernel専用シェルの実装
– DC KernelのAPI（システムコール）を直接呼ぶ代わりに、シェルのように、コマンド
ラインで各種操作ができるツールがあると便利。クラウド自動化の「シェルスクリプ
ト」が書けるようになると良い。
14

15. NII dodai-deploy2.0 project
コンポーネントスタックの整理
ユーザ
DCKを前提としたアプリケーション
DCKを容易に利用するためのツール
dckapp
DCKのAPIを呼び出す
ライブラリ
dcktool
libdck
libdck
Data Center Kernel本体
dck
dckemu
IaaS Infra
15
本来はIaaS基盤が提供するべきだが、
既存のIaaSでは未実装の機能を
代替として提供するモジュール
AWS / OpenStack / Eucalyputus /
Wakame VDCなどの既存の
IaaS基盤を前提とする

16. NII dodai-deploy2.0 project
各コンポーネントスタックで実装するもののアイデア
 dcktool
– dcksh
– dckinit
 dckapp
– Autoscale httpd
– Autoscale echo server
 dkclib
– Ontology based resource assignment library
 dck
–
 dckemu
– Shared memory service
– Network virtualization service
 IaaS
– AWS/OpenStack/Eucalyptus/Wakame VDC/etc...
16

17. NII dodai-deploy2.0 project
Thank You!
Etsuji Nakai
Twitter @enakai00