Slide 1
Slide 1 text
マイクロサービスと kubernetes の性能分析
岩本俊弘
Slide 2
Slide 2 text
Disclaimer
●
This is not something production-ready.
●
Uses a synthetic app for analysis
●
No details on Istio will be provided, while I’d love to discuss later
Slide 3
Slide 3 text
マイクロサービス化
● 最近の流行だそうです
– 去年 12 月の kubecon は推しがすごかった
● アプリの開発がやりやすくなる等は専門じゃないのでよくわからない
●
単純な処理をする Pod(container) に分解されることで、システムに与える負
荷がわかりやすくなるかは興味がある
– IO 主体
– CPU 負荷主体
– メモリ負荷主体
– Etc.
Slide 4
Slide 4 text
イメージ図 (monolithic)
client
service
service
0
1
2
3
4
5
6
7
8
9
10
CPU usage
IO
memory
Slide 5
Slide 5 text
イメージ図 (microservice’d)
client
micro-A
0
1
2
3
4
5
6
7
CPU usage
IO
memory
micro-B
micro-C
Slide 6
Slide 6 text
イメージ図 (microservice’d)
client
micro-A
0
1
2
3
4
5
6
7
CPU usage
IO
memory
micro-B
micro-C
Slide 7
Slide 7 text
夢は広がる ...
●
ノード間の CPU, メモリ ,IO 帯域が平準化されるように Pod を
配置したい ( 自動的に )
●
Pod 間の負荷に正の相関がある場合 ( 複数のサービスが混在
してるような ) 、それらを別々のノードに配置して性能の悪影響
を抑えられる (?)
●
IO 負荷はノード単位で限界を越えないと顕在化しずらい
● マイクロサービスの応答時間で負荷状況がみえるはず
Slide 8
Slide 8 text
実験環境
● On-prem OpenStack クラスタ上
– 4GB, 2 vCPU x 4 台
●
Kubernetes 1.12.2
●
Istio 1.0.3
– mTLS 無効
●
Prometheus-operator master (commit 5805237b)
– Node-exporter
– cAdvisor (kubelet)
Slide 9
Slide 9 text
テスト用 web アプリ
● フロントエンド (fe)
– worker にリクエスト投げるだけ ( 複数回 )
●
Worker
– CPU 担当
– mysql からデータとってきて regression する
●
パラメータで指定された比率でランダムサンプリング
– 乱数でデータつくって mysql にいれる
●
Mysql
– IO 担当 ( のはず )
Slide 10
Slide 10 text
動作確認 (Istio)
Slide 11
Slide 11 text
動作確認 (Istio)
Slide 12
Slide 12 text
動作確認 (Istio)
Slide 13
Slide 13 text
動作確認 (prometheus)
mysql 動くノード
（ｋｕｂ−３）
Slide 14
Slide 14 text
動作確認 (prometheus)
worker 動くノード
(kub-4)
Slide 15
Slide 15 text
動作確認 (prometheus)
fe 動くノード
(kub-2)
Slide 16
Slide 16 text
動作確認 (prometheus)
Slide 17
Slide 17 text
Cpu usage by pods
Slide 18
Slide 18 text
CPU usage: mysql vs. worker
Slide 19
Slide 19 text
CPU usage と通信量 ( データサイズ ) の関係
Slide 20
Slide 20 text
Pod 単位で一定の傾向を示してほしかった
●
アクセスにいってるテーブルの大きさが 1 桁ちがう
– 中間のちょうどいいサイズの負荷があれば (?)
– 並列に動かしてもキャッシュアルゴリズムの関係で ...
●
間引きして worker に渡るデータの大きさを揃えてる
– これ使って正規化すればよかったかも
●
実際の workload ならいろいろ混ざって定常的になる？
–
Slide 21
Slide 21 text
本当は blackbox で Pod を分類したい
● 今回は素性がわかっている
● しかもパラメータも整えてある
●
Slide 22
Slide 22 text
ところで Jaeger どうなった
● API 応答とノードの負荷状況の相関があるはず
● Span のあたりが技術的には肝っぽいけど今回は活
用してない
●
定常負荷 (User-Agent: curl-probe
) と変動負荷をかけ
て、 curl-probe
の worker の応答時間を分析
Slide 23
Slide 23 text
各 CPU 時間、 probe 応答時間
Slide 24
Slide 24 text
各 CPU 時間 vs. 応答時間
拡大します ...
Slide 25
Slide 25 text
各 CPU 時間 vs. 応答時間
Slide 26
Slide 26 text
相関ありません ...
>>> i2s=np.loadtxt('30-i2scatter.data')
>>>
print(np.array2string(np.corrcoef(i2s[...,1:5],rowvar=0),pre
cision=4))
[[ 1.0000e+00 7.6919e-03 4.2872e-02 -1.2068e-04]
[ 7.6919e-03 1.0000e+00 -4.0794e-01 8.9741e-01]
[ 4.2872e-02 -4.0794e-01 1.0000e+00 -6.7476e-01]
[-1.2068e-04 8.9741e-01 -6.7476e-01 1.0000e+00]]
Slide 27
Slide 27 text
そもそも分布の形
Slide 28
Slide 28 text
人工的ですが 90percentile...
Slide 29
Slide 29 text
>>> print(np.array2string(np.corrcoef(i2s[...,1:5],
rowvar=0),precision=4))
[[ 1. 0.1716 0.019 0.1387]
[ 0.1716 1. -0.4079 0.8974]
[ 0.019 -0.4079 1. -0.6748]
[ 0.1387 0.8974 -0.6748 1. ]]
Slide 30
Slide 30 text
無事回帰できました
Slide 31
Slide 31 text
まとめ
● Prometheus でなんかとれる ( ご存知の通り )
● Istio/Jaeger でなんかとれる ( ご存知の通り )
●
これらは理屈としては当然関連がある指標
– いちおう見えた
●
どう活用できるか
– 性能予想
– ノードの負荷状況の指標として
●
他の負荷もあったらどうなっていたか
Slide 32
Slide 32 text
ちなみに全体像
Slide 33
Slide 33 text
Thank you!
/
ちょっと一緒に考えてみませんか ?