負荷試験、どうしてる？(公開版)

負荷試験、どうしてる？
KLabではこうしてます
Copyright © 2017 KLab Inc.

自己紹介
山田大久(おおひさ)
● 勤務先: 福岡事業所勤務
● 所属: インフラマネジメント部(社歴は13年目)
● おもにDSASのお守りをしています
● インフラをやることになってから、8年ぐらい
● インフラをやる前は、iアプリのクライアント/サーバサイドをやってました
● 趣味: フリークライミング

アジェンダ
● はじめに
● 負荷試験の目的
● 構成/担当役割
● モニタリングツール(グラフ)
● アタッカー並列数
● 負荷試験フロー
● 最後に

はじめに
負荷試験、どうしてる？

はじめに
実際にどうしているのか、あまり情報が出回っていな
いような気がします
そこで、KLab ではこうしているよ、という話をしようか
と

負荷試験の目的
負荷試験の目的ってなに？

● ユーザーに迷惑をかけない
○ 過負荷 -> メンテ -> 過負荷 -> 再メンテ
■ ユーザーからの信頼を損なう

そうならないためには、
事前に十分な負荷をかけ、
どこまでいけるかを把握
しておけば、

本番を迎えた時に、
持っている力を十二分に
発揮することができます！

● 想定アクセスに耐えられることを確認する
● 限界性能を把握する

構成
ATTACKER
LB
DB
KVS
WEB
WEB
WEB
モニタリングツール(グラフ)
インフラ
PJ
KLabが自社で運用しているサーバインフラ環境 (DSAS)

プロジェクト担当者の役割
負荷試験自体は、プロジェクト担当者が実施
● WEBアプリ
○ プロファイリング
○ チューニング
● 負荷試験ツールの選定
● シナリオの作成

インフラ担当者の役割
負荷試験の進め方や結果に対して、指摘やアドバイスを行う
● インフラ用意
● ミドルウェア設定
● ボトルネック調査
○ モニタリングツール(グラフ)
○ 詳細調査

インフラ担当者 ⇔ プロジェクト担当者
インフラ
PJ
PJ: 負荷シナリオを実施しますねー
インフラ: はーい
PJ: 終わりましたー

構成
ATTACKER
LB
DB
KVS
WEB
WEB
WEB
インフラ
PJ
KLabが自社で運用しているサーバインフラ環境 (DSAS)
CPU, IO
NETWORK,
etc...

インフラ担当者 ⇔ プロジェクト担当者
インフラ
PJ
PJ: 負荷シナリオを実施しますねー
インフラ: はーい
PJ: 終わりましたー
インフラ: どこそこがまずいですね
PJ: どこそこを改修/変更します ⇒ しました
and/or
インフラ: どこそこを変更します ⇒ しました
PJ: 負荷シナリオを実施しますね
(以下、繰り返し)

モニタリングツール、何使ってる？

DSASでは、こちら
● Ganglia + 独自ビュー
○ 情報収集は、Ganglia(gmetad,gmond,gmetric)
○ グラフ表示は、独自(ganglia-webをベース)

アタッカー並列数
アタッカーの並列数は？

KLabでは、こうしています
　　　アタッカーの並列数
　　　　　　　||
　　WEBアプリの総ワーカー数

どうして同じにするの？

簡単な負荷試験の結果を紹介

● WEBマシン
○ CPU = 8
● WEBアプリ
○ Worker = 8 (CPU数に一致させる)
○ ListenBackLog = 100

並列数 req / sec time / req (msec)
8 42.47 188.380
24 42.48 564.939
100 42.45 2355.925
200 エラー発生 (928 リクエストのみ完了 )
※ abによる1000回試行の結果

ATTACKER
WEB
a-1
w-1 w-2 ・・・ w-N
a-2 ・・・ a-N
a-N+1 a-N+2 ・・・ a-X
● 並列数 > ワーカー数
○ レイテンシ劣化
● 並列数 >> ワーカー数
○ 接続エラー
○ タイムアウト
詰まる

アタッカーの並列数 = 総ワーカー数
||
エラーは発生しない

● エラーが発生し得ない状況で、エラーのないこと
を確認
● WEBアプリ本来の性能を把握

負荷試験フロー
目標設定
WEB 1台
目標設定
WEB 1台
負荷試験
WEB 8台
負荷試験
レビュー
限界性能
試験
終了
OK？
目標
達成？
OK？
YES
NO
YES
NO
NO
NO
YES
YES

目標設定
目標設定
WEB 1台
目標設定
レビュー
YES
NO
● 目標設定
○ req/sec, response time, etc
● レビュー
○ 設定値の妥当性検証
○ PJ/インフラ担当者間の認識のすり合わせ
● WEB 1台あたりの目標設定
○ 大まかにreq/secを決定

WEB 1台
WEB 1台
負荷試験
OK？
YES
NO
● WEBマシンの負荷/性能確認
○ req/sec, response time,
○ cpu, memory, traffic
● DB/KVSマシンの負荷確認
○ query/sec
○ IO etc…
● アタッカーマシンの負荷確認

WEB 8台
● スケールアウト確認
● ネットワーク帯域確認
○ サービストラフィック
● DB/KVSマシンの負荷確認
○ cpu, memory, traffic
○ query/sec
○ evictions
○ IO etc…
● ボトルネック予測/対策
WEB 8台
負荷試験
OK？
NO
YES

限界性能
限界性能
負荷試験
目標
達成？
NO
YES
ボトルネックを解消しながら、以下を繰り返す
● WEBマシン追加
● DB/KVS 分割
想定アクセス数を十分に上回れば、
負荷試験終了！
終了

負荷試験フロー
● 少ない台数から段階的にWEB台数を増やす
○ 想定どおりにスケールアウトするか確認
○ ボトルネック特定が容易
● 限界性能の把握
○ アクセス数が想定を超えそうな場合の対応を検討しておく
例えば、
■ ネットワーク帯域の増強
■ DBマシンのCPU数を増やす
■ WEBアプリの軽量化を図る

最後に
過負荷による緊急メンテは、
いままで、一回もなし！！

最後に
ローンチを控えての負荷試験は大変ですが、
負荷試験は、のちの安定運用に繋がります
安定運用を続けることで、ユーザーからの信頼を得
られます

最後の最後に
苦労して開発し、ローンチさせたゲーム
アクセスが多いことは嬉しいこと
アクセス増による負荷に怯えるのではなく、
純粋に楽しめるようにしたいですね

最後に
ご静聴ありがとうございました！

負荷試験、どうしてる？(公開版)

More Related Content

Viewers also liked

Recently uploaded

負荷試験、どうしてる？(公開版)