第２回のCloudy会で、「ストーレジのスケール化」とその性能を議論したが、クラウド群のトポロジーに着目していませんでした．今回は、トポロジーを中心に議論します．「クラウド群」は、VM・コンテナ・ストーレジの分散型資源と定義し、お客（エンドユーザ）を含めてグラフの形にする．その中で、性能の測定・管理法と、性能の改善を目指したグラフ更新とそれを実装するマイグレーションの方式を議論する．結論として、クラウド群の種類（サビースの内容）に依存しない、ジェネリックな方法を探してみる．

1. クラウド群：
スケールをかけた
サービス・アプリにおける
性能管理法
Marat Zhanikeev
maratishe@gmail.com
maratishe.github.io
2015/02/07
Cloudy＠tenjin

2. .
maratishe.github.io
本クラウディ会
.
クラウド群とは？
..
.
クラウド上で同じソースコード＋複数化で出来たアプリ群を
（性能・構成など）を管理すること
• スケールアウトの考え方（同じソースこと）
• 第1回のViberの話に絡む
1. クラウド群づくり法（自動化、ロボット化など）
2. クラウド群の性能測定法 → トポ管理法 (マイグレーションを中心にして）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 2/49
...
2/49

3. .
maratishe.github.io
（直接の関連がないが）3-Way
Scriptingの技
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 3/49
...
3/49

4. .
maratishe.github.io
3-Way Scripting（が無いときに）：混乱する
こと
• HTTP APIを設ける時にウェブサーバを立ち上げる必要がある
◦ 答え: PHP Standalone Server
◦ 説明： こいうサーバは継続的に動くものでなく、動作を済ませて落とす
◦ クライアント側： wget
• APIを書くときに、1か所が望ましい
◦ 多様化の場合、インタフェース、wrapperなどを少なめにしたい（ゼロが良い）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 4/49
...
4/49

5. .
maratishe.github.io
3-Way Scripting (CLI, HTTP, Object)
1. Class/Object : 普通のオブジェクト指
向で動作を書き込む
2. CLI : このClass/ObjectをCLIから呼び出さ
れる形にする
3. WebAPI : 又同じClass/ObjectをHTTPリク
エストから呼び出される形にする
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 5/49
...
5/49

6. .
maratishe.github.io
3-Way Scriptsの例：CLI + Object
• xcp.php : xenクラウドを管理するAPI
• hadoop.php : xen.phpを使って、hadoopクラスタを管理
するAPI
• どちらも独立的に（CLIとして）使えるし、require_once()
→ new xcp()の形でも使えます
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 6/49
...
6/49

7. .
maratishe.github.io
3-Way Scripts (2)
• generic (something)
• somethingのクラスの関数としてAPIを書く
• 3行目： CLIの分岐
• 4行目： Web 分岐
• 更に便利： aliasを登録
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 7/49
...
7/49

8. .
maratishe.github.io
3-Way Scripts (3) CLI mode
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 8/49
...
8/49

9. .
maratishe.github.io
VMの自動化
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 9/49
...
9/49

10. .
maratishe.github.io
九工大のクラウド環境
• 九工大のクラウド
• ラック： 高スペックのクラウド（XCP)
• ラック上に乗っているMac Mini： 隠れたIP空間
を使っている小型クラウド
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 10/49
...
10/49

11. .
maratishe.github.io
クラウド → サービス → ....
• Cloudの権限： xeのCLIがそのままで使える、
PMのIPが分かっているから、直接に管理すること
• Serverの権限： PMがみえない、動作はAPIを
通して出来ることだけ
• アマゾンの事例： awsのCLIを使って、最低動
作として、VM作成しか出来ない
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 11/49
...
11/49

12. .
maratishe.github.io
VM as a Balloon
• Xenクラウドの場合、VMへの入り口とし
て、PV_argsの1つだけです
• 起動する前にKERNEL_PARAMSを
与えること
• 起動したら、proc/cmdlineから読み
込むことができる
• この方法を使うなら、予め.xvaイメー
ジを用意し、vm_importから新規VM
を作成する必要がある
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 12/49
...
12/49

13. .
maratishe.github.io
xcp.php : 3-way型のAPI
• xeのCLIをベースにして、便利なAPIを
作った
• high order = 複雑な動作も出来る(こ
れから実際にやってみる）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 13/49
...
13/49

14. .
maratishe.github.io
xcp.php : vmnew(), vmchange()を詳しく
• vmnew = import + set IP + start （VM上でkernel paramsを捕まえるcronが
必要）
• vmchange = rsync setup + shutdown + start (kernel params不要、VM
上のcronがやってくれる）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 14/49
...
14/49

15. .
maratishe.github.io
xcp.php : vmnew( file, name, ip)
• 実際に（別のパソコンで）やってみましょう
• 3Gbyte程度の.xvaから立ち上げる（4分程度かかる）
• ゼロから、IP環境が完成した（SSHなどが出来る）形で立ち上がる
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 15/49
...
15/49

16. .
maratishe.github.io
VM群の応用：仮想hadoop
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 16/49
...
16/49

17. .
maratishe.github.io
Hadoop構築の自動化
• 変なhadoopでしょう。通常だと、hadoopはPMへインス
トールするもの
• ただし、実験などのために、VM上のhadoopが非常に便
利
• 実験だけでなく、大規模分散型hadoopが話題にも
なれる
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 17/49
...
17/49

18. .
maratishe.github.io
Hadoop構築ロボット：setup.txt
• hadoopのマニュアルに従った、必要なものだけを引き出して、別のsetupで書
いた
• 特に、マシンの名前とIPが必要
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 18/49
...
18/49

19. .
maratishe.github.io
Hadoop構築の実験
... がすでに動いているはずですが、終わっていますか？
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 19/49
...
19/49

20. .
maratishe.github.io
VM群の応用：EC2 APIに3-way型API
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 20/49
...
20/49

21. .
maratishe.github.io
AWS/EC2 自動化
• 長い＝面倒くさい
• 色んな不具合を解決した、たとえ
ば、VMを解除するときにそのAMIが残っ
ている（ストーレジ料金）
• この3-way型APIを以下の実験に使
いました
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 21/49
...
21/49

22. .
maratishe.github.io
クラウド群の理論
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 22/49
...
22/49

23. .
maratishe.github.io
仮想ネットワーク埋め込み（VNE）問題
Cloud A Cloud B
DC
DC
DC
Virtual
Physical
Many
Service
topology
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 23/49
...
23/49

24. .
maratishe.github.io
VNE問題の問題点
• 複雑性： 仮想グラフｘ１個ｘ１つ性能属性の埋め込みはNP困難
◦ ｘ数個はどうでしょうか？
◦ それぞれが異なっている性能の概念・属性を使っているときにどうなる？
• 実用化： 今のところで１例もない
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 24/49
...
24/49

25. .
maratishe.github.io
VNE vs 独自管理
• VNE : 集中制御の１つとして、クラウド側で管理する
• 独自管理： クラウド群ごとに、自分の性能を自分で管理する
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 25/49
...
25/49

26. .
maratishe.github.io
独自管理の定義
APP
Cloud/DC
APP
APP
VM
Container
APP
Cloud/DC
APP
APP
….
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 26/49
...
26/49

27. .
maratishe.github.io
独自管理の理想
• EC2が（私の）群の性能を測ってくれる
• （私が）EC2から性能情報をゲットする
• 性能情報を分析した上、（私が）群の管理を行う
• ....今のEC2では可能でしょうか？ Heroku
上は？
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 27/49
...
27/49

28. .
maratishe.github.io
独自管理＝DIY管理
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 28/49
...
28/49

29. .
maratishe.github.io
DIY群管理法(1)
• DIY: Do It Yourself
• 性能情報も、多数多様なもので、自分で測る、自分で分析する
• 群の構成＝トポロジーも、自分で管理する（マイグレーション）
◦ EC2・Docker上は自然にできる、herokuはある程度可能
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 29/49
...
29/49

30. .
maratishe.github.io
DIY群管理法(2) : groping
• 性能測定では、現在の性能状況が分かる
◦ 遅延、スループット、AMI転送時間、VM実行にかかる時間、...
• マイグレーション後の状態は、（測らないと分からないので）、betterか
worse、両方あり得る
Migrate
START BETTERWORSE
Revert
Migrate
…
MigrateMigrate
…
Revert
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 30/49
...
30/49

31. .
maratishe.github.io
DIY群管理法(3)
Performance
Cost
Stop
New
state
• low-start特徴：
性能の改善は、早い
ほど、コストが低く
て改善度が大き
い
• 次からどんどんコスト
が上がるし、性能の差
分が減ってくる
• 最終的に、停止する
か、視点を変える
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 31/49
...
31/49

32. .
maratishe.github.io
性能の可視化
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 32/49
...
32/49

33. .
maratishe.github.io
性能可視化 (1) : ストレス最適化
• graph drawingの問題、形のない
グラフに形を与える
• ストレス（圧力・重力など）の概念を使
って、きれいな形を作る
• クラウド群には、使える？
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 33/49
...
33/49

34. .
maratishe.github.io
性能可視化：graph vs circle
• facebook social graph vs google circles
• グラフ程度の複雑なトポロジーを持っているクラウド群は、殆どない
• スケールアウトのアプリ＋ストーレジAPI → circle
• ユーザ群とクラウド群の可視化 → 一部重なっているcircles
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 34/49
...
34/49

35. .
maratishe.github.io
EC2上のクラウド群（実験）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 35/49
...
35/49

36. .
maratishe.github.io
EC2上のクラウド群（実験）
• 15VM、ランダムな地域へ配置
• 30分毎に
◦ 5VMがランダムな地域へマイグレーションする
◦ ランダムなVM-VMペアで測定（遅延・スループット)
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 36/49
...
36/49

37. .
maratishe.github.io
EC2上のクラウド群（実験）
0 1000 2000 3000 4000 5000
size (kbytes)
0
1
2
3
4
5tx,rxthroughputasy=log(1+xinkbps)
Intra-DC
Average
Min/Max
3 sigma band
0 1000 2000 3000 4000 5000
size (kbytes)
0
1
2
3
4
5
tx,rxthroughputasy=log(1+xinkbps)
Inter-DC
Average
Min/Max
3 sigma band
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 37/49
...
37/49

38. .
maratishe.github.io
リング可視化’(1)
california
ireland
oregon
saopaulo
singapore
sydney
virginia
key (copyami)
sizes (1 10)
parties (ab)
california
ireland
oregon
saopaulo
singapore
sydney
tokyo
virginia
key (probe)
sizes (1 10)
parties (aa)
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 38/49
...
38/49

39. .
maratishe.github.io
リング可視化’(2)
california
ireland
oregon
saopaulo
singapore
sydney
tokyo virginia
key (probe)
sizes (2000 5000)
parties (aa)
california
ireland
oregon
saopaulo
singapore
sydney
tokyo
virginia
key (probe)
sizes (2000 5000)
parties (ab)
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 39/49
...
39/49

40. .
maratishe.github.io
EC2上のクラウド群
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 40/49
...
40/49

41. .
maratishe.github.io
EC2上のクラウド群(1)
• 少なくても、新規ＶＭからAMI（イメ
ージ）を用意する
• 起動時ジョブ： スクリプトを入れ
て、/etc/rc.localから呼び出す
• 3-way型APIを用しても良い
• Dockerを入れて、Docker用の3-way型
APIも役に立つかも
• 終わったら、AMIで保持（このAMIか
ら新規VMが作れる）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 41/49
...
41/49

42. .
maratishe.github.io
EC2上のクラウド群(2)
• 単純、AMIを使って無限にVMが作れる
• ただし、地域範囲、地域ごとにAMIを用意する
べき（転送できる）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 42/49
...
42/49

43. .
maratishe.github.io
EC2上のクラウド群(3)
• EC2が何もやってくれないので、自分で性能
を測る
• 必要な時にVMマイグレーションを行う
• 1マイグレーションに（起動の）１時間の料
金がかかる（安い！）
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 43/49
...
43/49

44. .
maratishe.github.io
Heroku上のクラウド群?
• できる？
• スケールを減らして、待って、もとに戻せば
どうなる？
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 44/49
...
44/49

45. .
maratishe.github.io
TopoAPI
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 45/49
...
45/49

46. .
maratishe.github.io
TopoAPI
StopContract (key)Population
TopoAPI
Service
Stats
New session
ID
ADD( a, b, value)
OK
OPTIMIZE( model)
Graph, Migrations, …
Read
Result Solve
• どいうクラウド群で
も管理でき
る（abstract API)
• 性能の変数・意味
はクライアントに
お任せ
• ストレスリングをベー
スにしてマイグレー
ションするべきの
ところを推薦する
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 46/49
...
46/49

47. .
maratishe.github.io
TopoAPI and OR
• 通信ネットの前に、ソーシャルネットでした
• 会社・コミュニティ内の接続図を最適化すること (OR: Operations Research)
• TopoAPIがORにも適切
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 47/49
...
47/49

48. .
maratishe.github.io
それで、本日の議論では...
• ... DIY群管理法、ストレスリング、TopoAPIなどの活用化につして話
したいと思います。
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 48/49
...
48/49

49. .
maratishe.github.io
That’s all, thank you ...
M.Zhanikeev -- maratishe@gmail.com クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 49/49
...
49/49