たのしい負荷試験

Transcript

1. たのしい負荷試験 京都.なんか #4
2. 自己紹介 • なまえ: non117 • twitter: non_117 • 職 ◦ サーバ設計・実装（Rails） ◦ AWSを使ったインフラ構築 ◦ 管理画面React業 • 属性 ◦ KMC, tumblr
3. 負荷試験とは？ クライアントを大量に並べて、サーバに負荷をかける実験 • 対象：HTTPを喋るサーバ • いつやるのか？ ◦ 大きなサービスのリリース前 ◦ （大規模）機能追加をリリースする前 • 必要なものは？ ◦ 対象のサーバの実装を把握してる人 ◦ 対象のサーバのインフラ構成を把握してる人 ◦ 時間：１ヶ月〜 ◦ 負荷試験専用のインスタンスたち（ ）
4. 負荷試験で得られるもの 1. バグ・高負荷でのみ発生する現象の検出 ◦ システム全体の挙動をチェックする ▪ アプリケーションサーバだけでなく、 DB, Cache, S3, etc...ぜんぶ込みで実験する ◦ レビューをすり抜けたバグ、遅い実装、高負荷マルチスレッド 、インデックスメモリにのるのか問題 2. システムの特徴把握 ◦ 例: c4.large, CPU 40%で 1000 request / secくらいさばける ◦ 監視の内容・閾値が決められる ◦ リリース時のインフラ構成の根拠にもなる 3. 負荷をかけながらオペレーションの実験 ◦ DB, Redisのfailoverをさせてみる：8] ◦ B/Gデプロイをしてみる ◦ DB schemaの変更
5. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる
6. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • シナリオ（仕様）を決めるための準備 ◦ どの機能を試験の対象とするのか決める • 例: twitterの負荷試験をする場合 • エンドポイント一覧 ◦ timeline取得 ◦ like ◦ retweet ◦ follow ◦ unfollow ◦ userのtweet一覧 ◦ etc...
7. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • シナリオ（負荷クライアントの仕様）を決め る ◦ 負荷クライアントがどんな動作をするのか定義 する ◦ ありえそうなユーザ行動の簡易なモデル • 例 ◦ タイムライン200件取得 ◦ ツイートを上から見ていく ▪ ランダムにlike ▪ ランダムにretweet ▪ ランダムにreply ◦ n件見たらtweet
8. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • 負荷クライアントでシナリオを表現 する • APIの仕様書をみながら黙々と実装 • 負荷クライアントの入力変数 ◦ 並列度 ◦ シナリオ内で処理を分岐するときの確率 ◦ その他シナリオに応じてなにか • 負荷試験ツールの上に実装、あるいはま るごと自作
9. 負荷クライアントのつくりかた • 負荷試験ツール選択肢 ◦ ab, tung, jmeter, gatling... • 選びかた ◦ シナリオが複雑なら、 高機能な負荷試験ツールをえらぶ ◦ シナリオが複雑 システムが複雑 ▪ 高負荷安定稼働させるのに注力する ◦ 読み書きできる言語 • 自作するケース ◦ シンプルなシナリオならあり ◦ golangで作ったことがありますが、結構たのしい ◦ ログフォーマットだけ他ツールと互換性を持たせ、分析は丸投げするとかも可能 // gatlingでの実装例 // DSL(Scala)を使ってGETとvalidation val timeline = exec(http("timeline") .get("/")) .check(status.is(200)))
10. gatling • 業務で使ってます • よいところ ◦ スケールする ◦ 書きやすい ◦ レポート機能が優秀 • 微妙なところ ◦ gatlingの郷に入る必要がある ◦ 謎DSLの制約 ◦ 好き勝手にResponseをいじりまわしたい • しかし、総合的には優秀なツール ◦ 複雑なシナリオの実装も easy ◦ インスタンス並べたら難なく数万 RPSだせる
11. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • 負荷をかけるシステム（ぜんぶ）の 専用環境をつくる • できれば本番相当の規模 • 構築が（半）自動化されているとよい ◦ 特にアプリケーションサーバ ◦ 頻繁に立てて壊してをやる • ◦ それなりにかかる ◦ 無理なとき ▪ 線形にスケールすると仮定し小規模で ▪ 一部の処理を迂回させて、 アプリケーションサーバと DBだけでやる とか
12. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • 負荷クライアントを動かす • 負荷クライアントが1インスタンス ですむ場合 ◦ sshしてエイヤッ • 目標スループットに複数台必要な場合 ◦ 負荷試験のコントロールが必要 ▪ 起動、強制終了、ログ収集 ◦ 例: sshkitで制御 • 負荷走行中 ◦ mackerel, Cloudwatchを眺める ◦ 各種ログをターミナルに流す ◦ 実行時間: 数十分から数日まで様々
13. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • 複数の負荷クライアントインスタンスから ログを集めて、統計処理 ◦ エンドポイントごとの処理時間、平均など • シンプルなシナリオならExcelで十分 • 負荷試験ツールにレポート機能が ついているなら、特にやることなし
14. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • 課題を見つけて、修正するための設計を 行う • もっとも重要なフェーズ • 手癖でちょろっと設定をいじり、 「もう一度負荷試験❗」をやりがち ◦ 散歩にいきましょう ◦ よく観察して、なぜスケールしないのか 仮説を立てる ◦ 仮説を検証するための設定を行ってから 再試験する
15. 負荷試験の流れ 1. エンドポイントを並べる 2. シナリオを決める 3. 負荷クライアントの実装 4. 負荷試験環境の構築 5. 負荷試験走行 6. ログ収集・レポート生成 7. 分析・仮説構築 8. 実装や設定の修正 9. 5. にもどる • 仮説の検証をするための修正作業
16. 負荷試験の目標を何にするのか問題 • 目標の例 ◦ N request / secを達成する ◦ 用意できるDBに最高負荷をかける ◦ 高負荷を1週間まわして異常なし • シミュレーションなので は不可能 ◦ 逆立ちしても現実には勝てない ◦ 目標を意識して適当なところで切り上げなければならない • 達成できれば、シナリオはある程度非現実的なものでよい ◦ クライアント含めた全体として、どんな挙動になるかは 開けてみるまでわからない
17. よくハマるところ • ポート65535制約 ◦ websocket案件 ◦ 素直に負荷クライアント、サーバともに増やす • 負荷クライアントのリソースが足りなくなる ◦ 負荷クライアントの監視も必要 • 思い込み ◦ ここがおかしいに違いないと思い込む ◦ グラフがたくさんあり雑にスクロールしてわかった気になる ◦ 理想的にはレビューがあるとよい ▪ 今回の負荷走行で何を変えたか、今までどんな傾向があったかを共有するのがたいへん ▪ 人員に余裕があるなら２人でやる
18. 蛇足 • 負荷クライアント少し手を入れると、外形監視に流用できる • つまり？？？ ◦ 負荷試験クライアントの一部を切り出して、 AWS Lambdaとかその他jenkinsなどで定期実行 ◦ じっさいにAPIを叩いて正常系の確認ができる ◦ 外形監視というよりは、本番 E2E❓ • 複数リージョンに置いておく ◦ カリフォルニア → 東京の監視で ◦ シンガポール → 東京の監視は ◦ 経路障害の切り分けができる
19. まとめ • 負荷試験はたいへんだが、様々な効用もある • 負荷試験の大まかな流れを示しました • 分析・仮説構築で手を抜くと時間を無駄にする • 業務でやっているお気持ち ◦ 属人化はしやすい ◦ チューニングの楽しさが大きい