令和 4 年 9 月に開催した「サーバサイド特集 〜 KLabのサーバサイドエンジニアが、元 SIer が、CTOが語ります！」のセッション資料です。 https://klab-tech-meetup.connpass.com/event/254481/

1. 「リアルISUCON」としての
モバイルオンラインゲーム開発
KLab TECH Meetup #10 発表資料
@hnw
1

2. 自己紹介
塙 与志夫（はなわ よしお）
KLab株式会社 CTO
Twitter: @hnw
自慢：
GitHubの脆弱性を指摘して賞金をもらいました
ISUCON 4で予選通過しました
2

3. KLabのカラー
様々なスキルの人材がチームとして力を発揮する会社
モバイルオンラインゲームはさまざまな技術の組み合わせ
多くの専門家がチームとしてゲーム作りをしている
社内外への情報発信が推奨される会社
社外発表やOSS contributeを継続的に実施しています
社内勉強会は10年以上継続しています
3

4. 4
どぶろく制度
業務につながるかわからない研究・開発・探求を推奨する制度
業務時間の10%以内であれば上司の許可は不要
KLabのベンチャースピリットを象徴する制度

5. 本日お話しすること
ISUCONは仕事に活かせるか？
実戦での負荷試験・性能改善
ボトルネックの事例
まとめ
5

6. 本日お話しすること
ISUCONは仕事に活かせるか？
実戦での負荷試験・性能改善
ボトルネックの事例
まとめ
6

7. ISUCONとは
サーバアプリケーションの性能改善コンテスト
ISUCON＝いい感じにスピードアップコンテスト
最大3人チームで参加
チームごとに正常動作するWebアプリ+サーバが提供される
わざと遅くなるような設定やプログラムを作りこんである
提供される負荷試験ツールを動かすとスコアが出る
設定やプログラムを修正してはスコア確認する、を繰り返す
7

8. ISUCONの面白さ
単純に競争として楽しい
スコアを他人と競うこと自体に競技性がある
ボトルネックを探すのが楽しい
1つ目のボトルネックを倒すと次のボトルネックが登場する
全然違うボトルネックが次々登場して楽しい
チーム戦が楽しい
得意領域が異なる人と1つの問題に取り組むのは楽しい
8

9. ISUCONは実戦的か？
人によって意見が変わりそう
「実戦ではありえない設定ミス」は知識問題に近い
実戦ではお金（＝CDN・サーバ増設）で解決が正解のこともある
スマートフォンゲーム業界の観点では非常に実戦的
スマートフォンゲームのサーバサイドでは性能改善は必須スキル
ボトルネックの探し方、直し方、バリエーションの多さは役立つ
9

10. 本日お話しすること
ISUCONは仕事に活かせるか？
実戦での負荷試験・性能改善
ボトルネックの事例
まとめ
10

11. モバイルオンラインゲームのサーバ構成
サーバ構成は普通のWebサービスと同様です
11

12. モバイルオンラインゲームの規模感
アクセス規模：最大10000req/s程度
静的コンテンツのアクセスは除いた数字
この規模になるとさまざまなボトルネックに遭遇する
ほぼ全requestがRDBの書き込みを伴う
CDNでキャッシュするわけにもいかない
さまざまなボトルネックと真っ向勝負する必要性
ISUCONの知識が生きる現場
12

13. 負荷試験の進め方
①目標性能を決める
ピーク時1時間のユニークユーザー数を推定
1ユーザーあたりの想定APIリクエスト数と掛け算
→目標とするreq/sが決まる
13

14. 負荷試験の進め方
②目標性能を達成するまで性能改善を行う
負荷試験ツールでユーザーアクセスに似せたシナリオを作成
明らかに遅すぎるAPIがあれば都度修正
WebサーバがボトルネックならWebサーバを増やしていく
14

15. 負荷試験の進め方
③限界性能と、限界時のボトルネックを確認する
KLabでは目標性能を達成しても負荷試験を続けることが多い
限界性能を把握しておくことがいざというときの保険になる
15

16. 負荷試験のよくある落とし穴
リアルなデータを使わないと負荷試験の意味がない
RDBレコード数が増えると見つかるボトルネックもある
運用6ヶ月後くらいを想定してダミーデータを作る
リレーションも含めリアルなデータを作るべき
（例：全ユーザーがメンバー数1人のギルドに所属するようなデータは良くない）
リアルなシナリオを作らないと負荷試験の意味がない
上と同様だが、意外と難しかったりする
16

17. 性能改善の進め方
①各種メトリクスを見てボトルネックを探す
②ボトルネックを解消する
の繰り返し
やみくもに改善しても全体への影響は小さかったりする
ボトルネックを順番に潰していくのが効率的
17

18. 本日お話しすること
ISUCONは仕事に活かせるか？
実戦での負荷試験・性能改善
ボトルネックの事例
まとめ
18

19. わかりやすいボトルネックは対処しやすい
WebサーバのCPU利用率が高い場合
Webアプリケーションプログラムが非効率、頑張って直す
RDBのCPU利用率またはディスクI/Oが高い場合
クエリチューニングやキャッシュ化などで対応
RDBのパラメータチューニングが必要なことも
ボトルネックがわからない場合は困ります
19

20. ボトルネックが見当たらない？
注意点1：負荷をかけきれているか？
攻撃側サーバが足りないなどで、負荷をかけきれないことがある
注意点2：意外なボトルネックが無いか？
パッと見でわからないボトルネックも多い
引き出しの多さが大事
20

21. ボトルネック事例(1) RedisのCPU
RedisのCPUがボトルネックになることがある
Redisは高性能だが、ヘビーに使うとボトルネックになる
知らないとボトルネックに気付きにくい
CPU利用率グラフが25%や12.5%に張り付く
Redisはシングルスレッド動作なのでマルチコア全部を使えない
（Memcachedでも同じ現象が起こります）
21

22. ボトルネック事例(2) 内部ネットワーク帯域
内部ネットワークの帯域を使い切ることがある
例：MySQLやMemcached/Redisとの通信量が多すぎる場合
修正しづらいことが多い
通信量を減らす必要があるので、作り直しになりがち
MySQLの圧縮プロトコルに変更するだけで済んだこともあります
22

23. ボトルネック事例(3) RDBへの通信回数
APIによっては数十件のSQL問合せを行う
一本一本は非常に軽いクエリ
Webサーバ-RDB間のRTTがボトルネックになりうる
RTT: Round Trip Time
グラフやログではわかりにくいボトルネック
複文で問い合わせを投げると通信回数を減らせる
参考：MySQLで大量のシンプルなクエリを高速化する
23

24. ボトルネック事例(3) RDBへの通信回数
24

25. ボトルネック事例(3) RDBへの通信回数
RDBがネットワーク的に「遠い」と特に有効
Multi-AZなど
保守性は下がる点に注意
ORMの利点などは活かせない
とはいえ面白いので紹介しました
複文でクエリが投げられる、その結果も取り出せるというのはあまり知られ
ていない印象
25

26. 本日お話しすること
ISUCONは仕事に活かせるか？
実戦での負荷試験・性能改善
ボトルネックの事例
まとめ
26

27. まとめ
ISUCONは実戦的なコンペです
みなさん一度挑戦してみてください
ゲームのサーバサイドには性能改善の仕事があります
リリース時に障害を出さないために結構工数を取っています
負荷試験はダミーデータ作成とシナリオ作成が大事
実際にあった特徴的なボトルネックを紹介しました
高負荷環境の性能改善は創意工夫が必要で楽しいですよ！
27

28. 28
ご清聴
ありがとうございました