パフォーマンスチューニングのために普段からできること/Performance Tuning: Daily Practices

Transcript

1. パフォーマンスチューニングのために 普段からできること 2025-10-28 藤原俊一郎 (@fujiwara)
2. 自己紹介 @fujiwara (X, GitHub, Bluesky) @sfujiwara (hatena, mixi2) 2011〜2024 面白法人カヤック 2025-02〜 さくらインターネット ISUCON 優勝4回 / 運営(出題)4回 github.com/kayac/ecspresso github.com/fujiwara/lambroll
3. 「パフォーマンスチューニングの楽しみ」 ↑941さんの企画のタイトル案 パフォーマンスチューニングで「楽しい」時とは？ 明らかな改善に成功した時 ISUCONで勝った時 逆に「楽しくない」時は？ 今まさに負荷で死んでいるサービスを直さないといけない時 (ISUCONで負けた時)
4. 今まさに負荷で死んでいるサービスを直さないといけない時 自分があまり関わってこなかったサービス → そこまででもない 長年開発・運用して面倒を見てきたサービス → つらい 自分がやってきたことが負けているのを突きつけられるのがつらい (ある意味ISUCONでの敗北も同じ)
5. なぜパフォーマンスの問題は突然起こるのか 普段安定して動いて不満がない場合、パフォーマンス改善の必要を感じない 優先度はどうしても他の項目に振り分けられる パフォーマンスの劣化は危険になる直前まで体感しにくい ← 理由があります
6. 待ち行列理論 あるサービスを提供する窓口に顧客が並ぶ時の状況をモデル化 お客さんの到着 窓口（処理） ↓ ↓ → → 待ち行列 → → ↑ ↑ λ (ラムダ) μ (ミュー) 到着率 処理率 1秒に何人来る？ 1秒に何人捌ける？ 一番単純な M/M/1 モデル(窓口が一つ)で説明
7. 待ち行列理論 到着率 (λ): 単位時間に来る顧客(リクエスト)数 処理率 (μ): 単位時間に処理できるリクエスト数 平均応答時間 = 1 ÷ (μ - λ) （M/M/1モデル） 例えば μ = 100/sec(1秒間に100リクエスト処理可能) λ = 50/sec(1秒間に50リクエスト到達) 平均レイテンシ(レスポンスタイム) = 1 / (100 - 50) = 0.02sec = 20ms
8. μ = 100req/sec のサーバーのレイテンシ = 1 / (100 - λ) λ (req/sec) レイテンシ 体感 0 10ms 快適 20 12.5ms 快適 50 20ms 快適 80 50ms 快適 90 100ms 普通 95 200ms ちょっと重いかも? 99 1s 重いな… 100 ∞
9. μ = 100req/sec で処理できるサーバーのレイテンシ
10. パフォーマンスの劣化が体感しにくい理由 平均応答時間は利用率がかなり高くなるまで大きく劣化しないが 利用率が高くなると急激に悪化する 50%=20ms(2倍) → 80%=50ms(5倍) → 95%=200ms(20倍) → 99%=1000ms(100倍) 人間は数十ms程度のレイテンシ悪化は知覚できない 50ms程度までは気が付かない、100msを超えてやっと気がつく人が出る 人間が「重い」と感じた時点ですでに利用率は限界に近い 人間は知覚できないが機械なら計測できる。モニタリングをしましょう。
11. (参考) M/M/cモデル (c=10) 10台で同じ処理性能(合計)を持たせた場合 上がり方が緩やかだが限界近くで急上昇するのは同じ
12. (参考) 平均 vs p99 (99 percentile) p99 (99%の処理が含まれる時間)は平均より先行して悪化し始める(敏感)
13. システム全体の性能はボトルネックで決まる システムは複数の構成要素が全て繋がって処理を行う user ↔︎ CDN ↔︎ LB ↔︎ App ↔︎ DB ↔︎ Storage... 一番細い(弱い)ところが埋まるとスループットは頭打ち (レイテンシは上がり続ける)
14. 前職での昔話 - Lobi ゲームユーザー向けのコミュニティ サービス 2010年 ナカマップとしてリリース 2013年 Lobiに改名 オンプレミスの仮想化基盤(KVM) アプリケーションサーバーは比較的 容易にスケール可能 hostは24vCPU、台数も余裕あり データベースには ioDrive 当時最強の フラッシュメモリストレージ
15. 事件発生 2013年6月某日 ある日のピーク時刻(23時頃)にアプリケーションのレイテンシが急激に悪化 全てのサーバーの CPU, メモリ, IO などは完全に余裕がある 数十分すると回復する(リクエストが減るので) 毎日発生するけどモニタリングしても全く理由が分からない slow query log もちゃんと取っているけど何もでてこない
16. 何が遅いのか切り分ける アプリケーションからアクセスする 相手 = MySQL, KyotoTycoon PerlのDevel::KYTProfを仕込んで観察 (分散Traceの先駆け的なライブラリ) useするだけで各種外部通信に掛かっ た時間をログに出してくれる 任意のコードにhookを設定可能
17. 結果 = アプリからDBへのクエリ発行、結果取得までが遅くなっている 通常時 2,3ms で終わる処理が 20〜30ms になる DB側のクエリ処理自体は遅くなっていない つまりアプリケーションとDBの間に何かあるはず 丹念にグラフを見る ……なんかこのネットワーク転送量、頭打ってるな…?
18. # ethtool eth1 Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: pumbag Wake-on: g Current message level: 0x00000001 (1) Link detected: yes
19. # ethtool eth1 Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: pumbag Wake-on: g Current message level: 0x00000001 (1) Link detected: yes
20. 100Mb/s !!? # ethtool eth1 Settings for eth1: Speed: 100Mb/s 1GbpsのNIC/スイッチなのになぜか100Mbpsでリンクアップしていた (多分オートネゴシエーションがおかしかった) ネットワークが100Mbpsで頭を打った結果 DBはクエリを2msで完了して結果を送信する slow logはこのタイミングで閾値を超えたら書かれる(ので出ない) DBとアプリケーション間のネットワークがボトルネック アプリケーションは結果を受信するのに20〜30ms掛かってしまう
21. 画に描いたようなボトルネック 1Gbpsに設定変更してあっさり解決
22. 教訓 1カ所のボトルネックがシステム全体の性能を制約する お金で殴ったつもりでも1カ所のボトルネックが全てを破滅させる
23. ボトルネックは全てを破滅させるし、体感では破滅直前まで気がつくことはできない → 普段から計測しましょう
24. 「推測するな計測せよ」 Rob Pike / Notes on Programming in C Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is. Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest. ルール1：プログラムがどこで時間を消費しているかを事前に予測することはできませ ん。ボトルネックは予想外の場所に発生するため、推測で高速化を試みるのではな く、まず実際に測定してボトルネックの発生箇所を特定することが重要です。 ルール2：測定を行いましょう。速度チューニングは、実際に測定を行った後でも必要 最小限に留めてください。特に、コードの一部が全体の処理時間の大部分を占めてい る場合にのみ実施すべきです。
25. 計測は必須だが、全てを計測する事はできない 今すぐ何とかしたい場合、あらゆる箇所を計測することは不可能(普段でも無理) 推測で当たりを付ける→計測して確信する(外れたら戻る)→改善する 最初はある程度推測から入る 推測があまりに的外れだと計測に無駄に時間がかかるだけ 的外れな推測をしないためにも普段からの計測、観察が大事 APM/分散トレーシングは「全てを計測する」に近い解決法 (ただしコストを気にしなければ)
26. 普段からの計測 = ダッシュボード ちゃんと運用されているシステムなら、ダッシュボードはあると思いますが… なければまず1枚だけ、システムの全体が俯瞰できるダッシュボードを
27. ダッシュボード おすすめの作り方 画面の上の段から順番に、ユーザーに近い箇所のグラフを並べる CDN: リクエスト数、エラー数(率)、転送量 LB: リクエスト数、エラー数(率)、レスポンスタイム、ターゲットの状態 アプリケーション: ECS/EC2: CPU、メモリ、転送量、台数、処理中のリクエスト数 Lambda: 並列数、実行時間 DB: クエリ数、レイテンシ、slowlog、CPU KVS: コマンド数、CPU JobQueue: 処理数、滞留数
29. ダッシュボードで全体を俯瞰する ユーザーへの影響があるか一目で判断できる情報(CDNなど) ↓↓↓ 内部の情報(App, DBなど) の順に並べて問題があったときに見る順番と一致させる 1. CDNでのエラーレートやレイテンシは? (ユーザー影響を最初に確認) 2. アプリケーションの状況は? 3. アプリから使っているミドルウェアなどの状況は? 1枚に並べることで問題の発生箇所を俯瞰して眺められる 怪しいところがあったら各要素のダッシュボード/グラフ/APMを深掘りしていく
30. 健康診断とアラート なぜ健康診断で異常が見つかるのか 統計的にこの範囲が通常という範囲を決めている、外れたものを検知する ITシステムの場合…「通常取りうる範囲」はシステムごとにかなり異なる レスポンスタイム 50ms or die が求められる広告システム 1秒で返っても安定していれば問題がない業務システム 平日日中に安定した流量のリクエストが送られてくるシステム 夜間休日問わず、数分間で数倍、数十倍のトラフィック変動があるシステム 「通常これぐらい」はそれぞれ異なる
31. 普段の状態を知っておく必要性 自分が運用するシステムで「何が普通なのか」は把握しておく必要がある 異常があったときだけグラフを見ると見誤る 1. 障害！ 2. その時間のDBのグラフに変なピークがある！ 3. 怪しい！調べよう！ 実は毎日同じ時間に実行しているバッチでした(無罪) 緊急時にこれをやっていると時間が無駄に
32. 機械学習・AIによる異常検知の活用 従来の閾値アラートの課題: 誤検知が多い、設定が難しい 機械学習による正常パターンの学習 本当に異常な時だけ通知 → オンコール負荷軽減 数年前から機械学習による異常検知の機能はモニタリングツールに存在している CloudWatch anomaly detectionなど (が、何も考えずにいい感じに使えてたかというと…???) 今後の発展に期待したい分野
33. 待ち行列理論とレイテンシ(復習) レイテンシは処理能力限界近くまで 悪化しづらい 目に見えて悪化した時には手遅れ 普段からダッシュボードを眺めてお くと変化に気づきやすい 定例などでみんなで見るのが良い
34. コンピューターの原理と動作速度 コンピューターの動作原理は発明以来何十年も変わらない 性能は年々上がっているように見えるが…… CPUのシングルスレッド性能は向上ペースが鈍化 最近10年でわずか2倍程度 コアが増えているのでマルチスレッド性能は伸びている が、普通のWebアプリケーションが勝手に速くなったりはしない 性能は最終的には物理法則に支配される(特にレイテンシは光速と密接) 地球の裏側に10msで情報を送ることは不可能
35. 全プログラマーが知るべきレイテンシー数 nano sec L1キャッシュ参照 0.5 分岐予測失敗 5 L2キャッシュ参照 7 Mutexのロックとアンロック 25 メインメモリー参照 100 Zippy[Snappy]による1KBの圧縮 3,000 1Gbpsネットワーク越しに2KBを送信 20,000 メモリーから連続した1MBの領域の読み出し 250,000 同一データセンター内におけるラウンドトリップ 500,000 0.5 msec ディスクシーク 10,000,000 10 msec ディスクから連続した1MBの領域の読み出し 20,000,000 20 msec パケットをカリフォルニア→オランダ→カリフォルニアと送る 150,000,000 150 msec http://norvig.com/21-days.html#answers
36. 実際のアプリケーションのチューニングでは CPU内(L1キャッシュにヒットするとか)まではほぼ気にしない 他のところがもっと圧倒的に遅いことが多い ある処理がCPUとメモリで完結するか 例: プロセス内のメモリキャッシュ ローカルディスクを読み書きするか (最近は少ないですね) データセンター内の別サーバーにアクセスするか 例: DBへのクエリ (0.5 ms〜∞) 地理的に離れた場所にアクセスするか(その距離は?) 例: 外部APIアクセス (10 ms〜∞) 処理単位でこれらのレイテンシを常に意識するのが大事
37. マイクロベンチマークを手癖にする 例:「Goでsliceに要素を追加する場合、先にキャパシティを確保したほうが速い」 func AppendFromEmpty(n int) { var s []int // sliceを宣言するだけ for i := 0; i < n; i++ { s = append(s, i) } } func AppendFromPreallocated(n int) { s := make([]int, 0, n) // capacityをn個分確保したslice for i := 0; i < n; i++ { s = append(s, i) } }
38. Go標準のtestingモジュールでベンチマークができる import "testing" func BenchmarkAppendFromEmpty(b *testing.B) { for i := 0; i < b.N; i++ { AppendFromEmpty(10000) } } func BenchmarkAppendFromPreallocated(b *testing.B) { for i := 0; i < b.N; i++ { AppendFromPreallocated(10000) } } $ go test -bench . -benchmem (他の言語でも同じようなものがあります)
39. $ go test -bench . -benchmem goos: linux goarch: amd64 pkg: example.com/bench cpu: AMD Ryzen 5 3400G with Radeon Vega Graphics BenchmarkAppendFromEmpty-8 9975 121229 ns/ 357627 B/op 19 allocs/op BenchmarkAppendFromPreallocated-8 43009 27803 ns/ 81920 B/op 1 allocs/op 事前にcapacityを確保することで メモリのアロケート回数が減る (19 -> 1 allocs/op) 4倍速い (121μs = 0.12ms -> 28μs = 0.028ms) のがわかる
40. 折に触れて「これはどれぐらい時間が掛かる?」を意識しておく MySQLでprimary keyで1行引くだけのクエリ MySQLで100万行を読んで1行だけ返すクエリ Redisのget/set... 使っている言語のHTTPクライアントでリクエストを送受信 使っているフレームワークでHello Worldを返すだけのアプリ https://www.techempower.com/benchmarks/ 1MBのJSONをencode/decode
41. 実例: ISUCON 11 優勝の分岐点 Zipを生成してダウンロードさせる機能 初期実装は zip 外部コマンド呼び出し → Go の archive/zip で作成するように fujiwara組: zip.Store (非圧縮)を指定してCPUコスト削減 NaruseJun: 圧縮(deflate)したZipを生成 ← 非圧縮だったら逆転していたらしい
42. AI時代のパフォーマンスチューニング LLMに最適化案を提案させる 明らかに良くないコードは指摘してくれる AIの提案は推測として扱う。必ず計測、検証してから取り入れること 自信満々に提案してきた修正で何も変わらない/遅くなることもよくある コードが複雑化・メンテナンス性低下するのは明確なデメリット ルール2：測定を行いましょう。速度チューニングは、実際に測定を行った後で も必要最小限に留めてください。特に、コードの一部が全体の処理時間の大部分 を占めている場合にのみ実施すべきです。 AIは責任を取ってくれない
43. まとめ パフォーマンスの劣化は突然発生する 使用率が上がっても性能はなかなか劣化しない 目に見えて劣化した時にはすでに余裕はほとんどない 「推測するな計測せよ」とは言いますが 効率のよい計測のためには推測が必要 精度の良い推測のためには普段からの計測が重要 これってどれぐらい時間がかかる処理? 普段から意識しておくと、うっかり変なボトルネックを作りにくくなる 発生してから慌てて直すより、発生しないように作る方が楽
44. 最後にひとこと アーキテクチャ(戦略)で敗北している場合 チューニング(戦術)でなんとかするのは無理