クラウド群：スケールをかけたサービス・アプリにおける性能管理法

クラウド群：スケールをかけたサービス・アプリにおける

性能管理法

Marat Zhanikeev [email protected]

maratishe.github.io

2015/02/07

Cloudy＠tenjin

.

maratishe.github.io

本クラウディ会

.クラウド群とは？..

.

クラウド上で同じソースコード＋複数化で出来たアプリ群を（性能・構成など）を管理すること

• スケールアウトの考え方（同じソースこと）• 第1回のViberの話に絡む

1. クラウド群づくり法（自動化、ロボット化など）

2. クラウド群の性能測定法 → トポ管理法 (マイグレーションを中心にして）

M.Zhanikeev -- [email protected] クラウド群：スケールをかけたサービス・アプリにおける性能管理法 -- bit.do/marat150207 2/49...

2/49

.

maratishe.github.io

（直接の関連がないが）3-WayScriptingの技


3/49

.

maratishe.github.io

3-Way Scripting（が無いときに）：混乱すること

• HTTP APIを設ける時にウェブサーバを立ち上げる必要がある

◦ 答え: PHP Standalone Server◦ 説明：こいうサーバは継続的に動くものでなく、動作を済ませて落とす　◦ クライアント側： wget

• APIを書くときに、1か所が望ましい

◦ 多様化の場合、インタフェース、wrapperなどを少なめにしたい（ゼロが良い）


4/49

.

maratishe.github.io

3-Way Scripting (CLI, HTTP, Object)

1. Class/Object : 普通のオブジェクト指向で動作を書き込む

2. CLI : このClass/ObjectをCLIから呼び出される形にする

3. WebAPI : 又同じClass/ObjectをHTTPリクエストから呼び出される形にする


5/49

.

maratishe.github.io

3-Way Scriptsの例：CLI + Object

• xcp.php : xenクラウドを管理するAPI• hadoop.php : xen.phpを使って、hadoopクラスタを管理するAPI

• どちらも独立的に（CLIとして）使えるし、require_once()→ new xcp()の形でも使えます


6/49

.

maratishe.github.io

3-Way Scripts (2)

• generic (something)• somethingのクラスの関数としてAPIを書く• 3行目： CLIの分岐• 4行目： Web 分岐• 更に便利： aliasを登録


7/49

.

maratishe.github.io

3-Way Scripts (3) CLI mode


8/49

.

maratishe.github.io

VMの自動化


9/49

.

maratishe.github.io

九工大のクラウド環境

• 九工大のクラウド• ラック：高スペックのクラウド（XCP)• ラック上に乗っているMac Mini：隠れたIP空間を使っている小型クラウド


10/49

.

maratishe.github.io

クラウド → サービス → ....

• Cloudの権限： xeのCLIがそのままで使える、PMのIPが分かっているから、直接に管理すること

• Serverの権限： PMがみえない、動作はAPIを通して出来ることだけ

• アマゾンの事例： awsのCLIを使って、最低動作として、VM作成しか出来ない


11/49

.

maratishe.github.io

VM as a Balloon

• Xenクラウドの場合、VMへの入り口として、PV_argsの1つだけです

• 起動する前にKERNEL_PARAMSを与えること

• 起動したら、proc/cmdlineから読み込むことができる

• この方法を使うなら、予め.xvaイメージを用意し、vm_importから新規VMを作成する必要がある


12/49

.

maratishe.github.io

xcp.php : 3-way型のAPI

• xeのCLIをベースにして、便利なAPIを作った

• high order =複雑な動作も出来る(これから実際にやってみる）


13/49

.

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がやってくれる）


14/49

.

maratishe.github.io

xcp.php : vmnew( file, name, ip)

• 実際に（別のパソコンで）やってみましょう• 3Gbyte程度の.xvaから立ち上げる（4分程度かかる）• ゼロから、IP環境が完成した（SSHなどが出来る）形で立ち上がる


15/49

.

maratishe.github.io

VM群の応用：仮想hadoop


16/49

.

maratishe.github.io

Hadoop構築の自動化

• 変なhadoopでしょう。通常だと、hadoopはPMへインストールするもの

• ただし、実験などのために、VM上のhadoopが非常に便利

• 実験だけでなく、大規模分散型hadoopが話題にもなれる


17/49

.

maratishe.github.io

Hadoop構築ロボット：setup.txt• hadoopのマニュアルに従った、必要なものだけを引き出して、別のsetupで書いた

• 特に、マシンの名前とIPが必要


18/49

.

maratishe.github.io

Hadoop構築の実験

... がすでに動いているはずですが、終わっていますか？


19/49

.

maratishe.github.io

VM群の応用：EC2 APIに3-way型API


20/49

.

maratishe.github.io

AWS/EC2 自動化

• 長い＝面倒くさい• 色んな不具合を解決した、たとえば、VMを解除するときにそのAMIが残っている（ストーレジ料金）

• この3-way型APIを以下の実験に使いました


21/49

.

maratishe.github.io

クラウド群の理論


22/49

.

maratishe.github.io

仮想ネットワーク埋め込み（VNE）問題

Cloud A Cloud B

DC DC

DC

Virtual Physical

Many

Service topology


23/49

.

maratishe.github.io

VNE問題の問題点

• 複雑性：仮想グラフｘ１個ｘ１つ性能属性の埋め込みはNP困難

◦ ｘ数個はどうでしょうか？

◦ それぞれが異なっている性能の概念・属性を使っているときにどうなる？

• 実用化：今のところで１例もない


24/49

.

maratishe.github.io

VNE vs 独自管理

• VNE : 集中制御の１つとして、クラウド側で管理する

• 独自管理：クラウド群ごとに、自分の性能を自分で管理する


25/49

.

maratishe.github.io

独自管理の定義

APP

Cloud/DC

APP

APP

VM Container

APP

Cloud/DC

APP

APP ….


26/49

.

maratishe.github.io

独自管理の理想

• EC2が（私の）群の性能を測ってくれる

• （私が）EC2から性能情報をゲットする• 性能情報を分析した上、（私が）群の管理を行う• ....今のEC2では可能でしょうか？ Heroku上は？


27/49

.

maratishe.github.io

独自管理＝DIY管理


28/49

.

maratishe.github.io

DIY群管理法(1)

• DIY: Do It Yourself• 性能情報も、多数多様なもので、自分で測る、自分で分析する

• 群の構成＝トポロジーも、自分で管理する（マイグレーション）◦ EC2・Docker上は自然にできる、herokuはある程度可能


29/49

.

maratishe.github.io

DIY群管理法(2) : groping• 性能測定では、現在の性能状況が分かる

◦ 遅延、スループット、AMI転送時間、VM実行にかかる時間、...

• マイグレーション後の状態は、（測らないと分からないので）、betterかworse、両方あり得る

Migrate

START BETTER WORSE

Revert

Migrate

…

Migrate Migrate

…

Revert


30/49

.

maratishe.github.io

DIY群管理法(3)

Performance

Cost

Stop

New state

• low-start特徴：性能の改善は、早いほど、コストが低くて改善度が大きい

• 次からどんどんコストが上がるし、性能の差分が減ってくる

• 最終的に、停止するか、視点を変える


31/49

.

maratishe.github.io

性能の可視化


32/49

.

maratishe.github.io

性能可視化 (1) : ストレス最適化

• graph drawingの問題、形のないグラフに形を与える

• ストレス（圧力・重力など）の概念を使って、きれいな形を作る

• クラウド群には、使える？


33/49

.

maratishe.github.io

性能可視化：graph vs circle

• facebook social graph vs google circles• グラフ程度の複雑なトポロジーを持っているクラウド群は、殆どない• スケールアウトのアプリ＋ストーレジAPI　→　circle• ユーザ群とクラウド群の可視化→　一部重なっているcircles


34/49

.

maratishe.github.io

EC2上のクラウド群（実験）


35/49

.

maratishe.github.io


• 15VM、ランダムな地域へ配置• 30分毎に

◦ 5VMがランダムな地域へマイグレーションする

◦ ランダムなVM-VMペアで測定（遅延・スループット)


36/49

.

maratishe.github.io


0 1000 2000 3000 4000 5000size (kbytes)

0

1

2

3

4

5tx

,rx th

roug

hput

as y

=log

( 1 +

x in

kbp

s) Intra-DC

AverageMin/Max3 sigma band

0 1000 2000 3000 4000 5000size (kbytes)

0

1

2

3

4

5

tx,rx

thro

ughp

ut a

s y=l

og( 1

+ x

in k

bps) Inter-DC

AverageMin/Max3 sigma band


37/49

.

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)


38/49

.

maratishe.github.io

リング可視化’(2)

california

ireland

oregon

saopaulo

singapore

sydneytokyo virginia

key (probe)sizes (2000 5000)parties (aa)

california

ireland

oregon

saopaulo

singapore

sydney

tokyo

virginia

key (probe)sizes (2000 5000)parties (ab)


39/49

.

maratishe.github.io

EC2上のクラウド群


40/49

.

maratishe.github.io

EC2上のクラウド群(1)

• 少なくても、新規ＶＭからAMI（イメージ）を用意する

• 起動時ジョブ：スクリプトを入れて、/etc/rc.localから呼び出す

• 3-way型APIを用しても良い• Dockerを入れて、Docker用の3-way型APIも役に立つかも

• 終わったら、AMIで保持（このAMIから新規VMが作れる）


41/49

.

maratishe.github.io


• 単純、AMIを使って無限にVMが作れる• ただし、地域範囲、地域ごとにAMIを用意するべき（転送できる）


42/49

.

maratishe.github.io


• EC2が何もやってくれないので、自分で性能を測る

• 必要な時にVMマイグレーションを行う

• 1マイグレーションに（起動の）１時間の料金がかかる（安い！）


43/49

.

maratishe.github.io

Heroku上のクラウド群?

• できる？• スケールを減らして、待って、もとに戻せばどうなる？


44/49

.

maratishe.github.io

TopoAPI


45/49

.

maratishe.github.io

TopoAPI

Stop Contract (key) Population

TopoAPI Service

Stats

New session ID

ADD( a, b, value) OK

OPTIMIZE( model) Graph, Migrations, …

Read Result Solve

• どいうクラウド群でも管理できる（abstract API)

• 性能の変数・意味はクライアントにお任せ

• ストレスリングをベースにしてマイグレーションするべきのところを推薦する


46/49

.

maratishe.github.io

TopoAPI and OR

• 通信ネットの前に、ソーシャルネットでした• 会社・コミュニティ内の接続図を最適化すること (OR: Operations Research)

• TopoAPIがORにも適切


47/49

.

maratishe.github.io

それで、本日の議論では...

• ... DIY群管理法、ストレスリング、TopoAPIなどの活用化につして話したいと思います。


48/49

.

maratishe.github.io

That’s all, thank you ...


49/49

Technology

クラウド群：スケールをかけたサービス・アプリにおける性能管理法