Performance analysis on microservices and kubernetes

This is an attempt on analyzing and finding correlations between node usage metrics (CPU, IO, etc.) and API level responsiveness. For node and container level metrics collection, prometheus was used. Istio/Jaeger was used to collect API level traces.

Transcript

1. マイクロサービスと kubernetes の性能分析 岩本俊弘 <iwamoto@valinux.co.jp>
2. 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
3. マイクロサービス化 • 最近の流行だそうです – 去年 12 月の kubecon は推しがすごかった • アプリの開発がやりやすくなる等は専門じゃないのでよくわからない • 単純な処理をする Pod(container) に分解されることで、システムに与える負 荷がわかりやすくなるかは興味がある – IO 主体 – CPU 負荷主体 – メモリ負荷主体 – Etc.
4. イメージ図 (monolithic) client service service 0 1 2 3 4 5 6 7 8 9 10 CPU usage IO memory
5. イメージ図 (microservice’d) client micro-A 0 1 2 3 4 5 6 7 CPU usage IO memory micro-B micro-C
6. イメージ図 (microservice’d) client micro-A 0 1 2 3 4 5 6 7 CPU usage IO memory micro-B micro-C
7. 夢は広がる ... • ノード間の CPU, メモリ ,IO 帯域が平準化されるように Pod を 配置したい ( 自動的に ) • Pod 間の負荷に正の相関がある場合 ( 複数のサービスが混在 してるような ) 、それらを別々のノードに配置して性能の悪影響 を抑えられる (?) • IO 負荷はノード単位で限界を越えないと顕在化しずらい • マイクロサービスの応答時間で負荷状況がみえるはず
8. 実験環境 • 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)
9. テスト用 web アプリ • フロントエンド (fe) – worker にリクエスト投げるだけ ( 複数回 ) • Worker – CPU 担当 – mysql からデータとってきて regression する • パラメータで指定された比率でランダムサンプリング – 乱数でデータつくって mysql にいれる • Mysql – IO 担当 ( のはず )
10. 動作確認 (Istio)
11. 動作確認 (Istio)
12. 動作確認 (Istio)
13. 動作確認 (prometheus) mysql 動くノード （ｋｕｂ−３）
14. 動作確認 (prometheus) worker 動くノード (kub-4)
15. 動作確認 (prometheus) fe 動くノード (kub-2)
16. 動作確認 (prometheus)
17. Cpu usage by pods
18. CPU usage: mysql vs. worker
19. CPU usage と通信量 ( データサイズ ) の関係
20. Pod 単位で一定の傾向を示してほしかった • アクセスにいってるテーブルの大きさが 1 桁ちがう – 中間のちょうどいいサイズの負荷があれば (?) – 並列に動かしてもキャッシュアルゴリズムの関係で ... • 間引きして worker に渡るデータの大きさを揃えてる – これ使って正規化すればよかったかも • 実際の workload ならいろいろ混ざって定常的になる？ –
21. 本当は blackbox で Pod を分類したい • 今回は素性がわかっている • しかもパラメータも整えてある •
22. ところで Jaeger どうなった • API 応答とノードの負荷状況の相関があるはず • Span のあたりが技術的には肝っぽいけど今回は活 用してない • 定常負荷 (User-Agent: curl-probe ) と変動負荷をかけ て、 curl-probe の worker の応答時間を分析
23. 各 CPU 時間、 probe 応答時間
24. 各 CPU 時間 vs. 応答時間 拡大します ...
25. 各 CPU 時間 vs. 応答時間
26. 相関ありません ... >>> 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]]
27. そもそも分布の形
28. 人工的ですが 90percentile...
29. >>> 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. ]]
30. 無事回帰できました
31. まとめ • Prometheus でなんかとれる ( ご存知の通り ) • Istio/Jaeger でなんかとれる ( ご存知の通り ) • これらは理屈としては当然関連がある指標 – いちおう見えた • どう活用できるか – 性能予想 – ノードの負荷状況の指標として • 他の負荷もあったらどうなっていたか
32. ちなみに全体像
33. Thank you! / ちょっと一緒に考えてみませんか ?