KLab福岡Meetup 「禍つヴァールハイトを支える負荷試験」 近年、サービス開始直後メンテが多発する中、インフラ面でどのようにして安定稼働をめざしたかについて

1. 筆 智章
職種 技術職
所属部署 技術統括部インフラG
KLab株式会社
禍つヴァールハイトを
支える負荷試験

2. 2
2014年 新卒入社
ガラケー・スマートフォンアプリ向けソーシャルゲーム
サーバサイドエンジニア
2015年 インフラエンジニアへジョブチェンジ
さくらのクラウドやawsを触り始める
趣味: タイピング・自宅サーバ
筆 智章
職種 技術職
所属部署 技術統括部 インフラグループ
KLab株式会社
自己紹介

3. 3
今日お話するのは
負荷試験についてですが、

4. 4
その前に、

5. 5
まがつってなに？

6. 6
遡ること2017年

7. 7
新作ゲームラインナップ発表会
KLabGames NEXT VISION

8. 8
● PVをみる
→ おもしろそうー！
新作ゲームラインナップ発表会にて発表

9. 9
● PVをみる
→ おもしろそうー！
● 豪華クリエイター陣が制作に参加！
新作ゲームラインナップ発表会にて発表

10. 10
すげー！

11. 11
負荷やばくね？

12. 12
リリース前から
数ヶ月おきに生放送

13. 13
Twitterトレンド1位も
(TGS時)

14. 14
負荷やばくね？

15. 15
実際にくるユーザ数は
神のみぞ知る値だが、
予測することはできる
(たとえ大幅に間違ってても)

16. 16
負荷試験の流れ
1. req/secや同時接続数をみつもって、目標値を決める
2. 試験に必要なツール類の整備とか
3. 次に試験
○ 1台あたりの性能を計測して、何台必要になりそうかみておく
○ 複数台構成で目標値をクリアできるか確認する

17. 17
試験対象のサーバは？

18. 18
webサーバ

19. 19
webサーバだけじゃない！

20. 20
リアルタイムマルチオンラインRPG

21. 21
同期通信が必要！

22. 22
その役割を担う
gameサーバもいます

23. 23
gameサーバ→

24. 24
目標値

25. 25
目標値
● 5000 req/sec
● 5万同時接続

26. 26
目標値
● 5000 req/sec
● 5万同時接続
← webサーバ
← gameサーバ

27. 27
目標値
● 5000 req/sec
● 5万同時接続
これをクリアしないといけない
← webサーバ
← gameサーバ

28. 28
目標値
● 5000 req/sec
● 5万同時接続
Q. リリース直後にこの予想を大幅に
超えてきたらどうなる？
← webサーバ
← gameサーバ

29. 29
目標値
● 5000 req/sec
● 5万同時接続
答え. 鯖落ちします！
← webサーバ
← gameサーバ
Q. リリース直後にこの予想を大幅に
超えてきたらどうなる？

30. 30
インフラエンジニアと
サーバエンジニア

31. 31
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
負荷試験
おねがいします！

32. 32
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
負荷試験
実施中...
アタッカー
実行中
各種メトリクス
確認

33. 33
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
メモリリークしてるっ
ぽいよ！
確認おねがいします
><;

34. 34
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
修正
対応中...

35. 35
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
対応しました！

36. 36
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
なおってるようです！
ありがとうございます！

37. 37
逆もある

38. 38
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
グラフが
バグってるんですが ...

39. 39
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
ひぃ〜
すいませんなおします ...
(土下座)
修正
対応中...

40. 40
インフラエンジニアとサーバエンジニア
インフラ
エンジニア
サーバ
エンジニア
なおしました！

41. 41
...と、このように
サーバエンジニアに、
「ここ直して！」

42. 42
と指摘する立場でした

43. 43
本当に改善できたのは
サーバエンジニアのパワーです

44. 44
問題の修正で半日かかったり
１日かかったりするので
1日試験が流せなかったりもしました

45. 45
webサーバの試験

46. 46
webサーバの試験
● めちゃめちゃ優秀
● 試験始めたばかりのころから、
1台で400req/secを記録
● レスポンスタイムも95パーセンタイルのもので200ms台
● 使用した負荷をかけるツール
○ green-hakai

47. 47
webサーバの試験
● 負荷試験初期から、
台数的にはwebサーバは少なくてもよくなるという肌感があっ
た

48. 48
gameサーバの試験

49. 49
gameサーバの試験
● 負荷試験用botを作成
○ ゲーム内を自動で走ってクエストを順次クリアしていくbot
○ 実機でフィールドに入ると、
大量のbotがゲーム内を走り回ってるのが見える

50. 50
モニタリングで
工夫したこと

51. 51
gameサーバの試験
● プロセス毎のルーム最大同時接続数をモニタリング
○ 1ルームでの最大同時接続数の目安は100接続
○ これを大幅に越えるとまともにゲームがプレイできなくなる
● コマンドタイムアウト発生件数をモニタリング
○ gameサーバにコマンドを送って、
一定の時間を超えてもレスポンスが返せない場合に
タイムアウトとして件数をカウント

52. 52
gameサーバの試験
● プロセス毎のルーム最大同時接続数をモニタリング
○ 1ルームでの最大同時接続数の目安は100接続
○ これを大幅に越えるとまともにゲームがプレイできなくなる
● コマンドタイムアウト発生件数をモニタリング
○ gameサーバにコマンドを送って、
一定の時間を超えてもレスポンスが返せない場合に
タイムアウトとして件数をカウント

53. 53
gameサーバの試験
● プロセス毎のルーム最大同時接続数をモニタリング

54. 54
gameサーバの試験
● プロセス毎のルーム最大同時接続数をモニタリング
目安の100を超えているので、
これはマズイ状況

55. 55
gameサーバの試験
● プロセス毎のルーム最大同時接続数をモニタリング
○ 1ルームでの最大同時接続数の目安は100接続
○ これを大幅に越えるとまともにゲームがプレイできなくなる
● コマンドタイムアウト発生件数をモニタリング
○ gameサーバにコマンドを送って、
一定の時間を超えてもレスポンスが返せない場合に
タイムアウトとして件数をカウント

56. 56
gameサーバの試験
● プロセス毎のルーム最大同時接続数をモニタリング
○ 1ルームでの最大同時接続数の目安は100接続
○ これを大幅に越えるとまともにゲームがプレイできなくなる
● コマンドタイムアウト発生件数をモニタリング
○ gameサーバにコマンドを送って、
一定の時間を超えてもレスポンスが返せない場合に
タイムアウトとして件数をカウント

57. 57
gameサーバの試験
● コマンドタイムアウト発生件数をモニタリング

58. 58
gameサーバの試験
● コマンドタイムアウト発生件数をモニタリング
DBで大量のデッドロックが
発生していたり、

59. 59
gameサーバの試験
● コマンドタイムアウト発生件数をモニタリング
どこかにボトルネックが
発生している

60. 60
gameサーバで起こった
トラブルを紹介

61. 61
大量切断の問題

62. 62
同時接続数の大量切断
● 試験時のトラブル
○ 同時接続数が安定しない
■ なぜか5000同時接続あたりで大量切断が発生し、落ち込む
※イメージ図です

63. 63
同時接続数の大量切断
一体なにがおこっていたのか

64. 64
同時接続数の大量切断
サーバエンジニア Nさんに
詳細を伺いました

65. 65
同時接続数の大量切断
スレッドA スレッドB
タイムライン

66. 66
同時接続数の大量切断
スレッドA スレッドB
RLock()
読み取りロックして、
タイムライン

67. 67
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
読み取りロックして、
さらに読み取りロック
するぶんには
問題は
発生しなかったが...
タイムライン

68. 68
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
読み取りロックして、
さらに読み取りロック
するぶんには
問題は
発生しなかったが...
RUnlock()
RUnlock()
タイムライン

69. 69
同時接続数の大量切断
スレッドA スレッドB
タイムライン

70. 70
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
スレッドAだけ
だとこう
RUnlock()
RUnlock()
タイムライン

71. 71
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
運悪く(?)
スレッドAの
RLockと
RLockの間のタイミングで
スレッドBで
排他ロックをしてしまうと...
RUnlock()
RUnlock()
Lock()
タイムライン

72. 72
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
運悪く(?)
スレッドAの
RLockと
RLockの間のタイミングで
スレッドBで
排他ロックをしてしまうと...
RUnlock()
RUnlock()
Lock()
ロック
獲得待ち
タイムライン

73. 73
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
運悪く(?)
スレッドAの
RLockと
RLockの間のタイミングで
スレッドBで
排他ロックをしてしまうと...
RUnlock()
RUnlock()
Lock()
ロック
獲得待ち
ロック
獲得待ち
タイムライン

74. 74
同時接続数の大量切断
スレッドA スレッドB
RLock()
RLock()
運悪く(?)
スレッドAの
RLockと
RLockの間のタイミングで
スレッドBで
排他ロックをしてしまうと...
RUnlock()
RUnlock()
Lock()
ロック
獲得待ち
ロック
獲得待ち
デッドロック
タイムライン

75. 75
同時接続数の大量切断
● このようなデッドロックにより...
○ クライアントにレスポンスが返せなくなり、
その結果コネクションの大量切断が発生していた

76. 76
同時接続数の大量切断
Nさん「どこで起こってるのか見つけるのがかなり大変」

77. 77
同時接続数の大量切断
Nさん「どこで起こってるのか見つけるのがかなり大変」
ぼく「直すのにどのくらいかかったのでしょう？」

78. 78
同時接続数の大量切断
Nさん「どこで起こってるのか見つけるのがかなり大変」
ぼく「直すのにどのくらいかかったのでしょう？」
Nさん「原因調査を含めて2週間くらいかかりました」

79. 79
同時接続数の大量切断
Nさん「どこで起こってるのか見つけるのがかなり大変」
ぼく「直すのにどのくらいかかったのでしょう？」
Nさん「原因調査を含めて2週間くらいかかりました」
ぼく「・・・もしリリース時に初めて発生していたら
2週間くらいメンテになっていた？」

80. 80
同時接続数の大量切断
Nさん「どこで起こってるのか見つけるのがかなり大変」
ぼく「直すのにどのくらいかかったのでしょう？」
Nさん「原因調査を含めて2週間くらいかかりました」
ぼく「・・・もしリリース時に初めて発生していたら
2週間くらいメンテになっていた？」
Nさん「そうですね、なってたかもしれないです」

81. 81
Go言語の
ランタイムバグ

82. 82
Go言語のランタイムバグ
● 突如クラッシュするgameサーバ
○ 原因がわからず頭を悩ませていたところ、
社内でGoにすごく詳しい方が調査して原因を特定
● 使用していたGoのバージョンのGCの処理で
ランタイムバグがあった
● Goのバージョンを下げればクラッシュしなかった
● 詳細はDSAS開発者の部屋へ
○ Goのライトバリアに関するバグを修正した話

83. 83
Redis,DBの分割

84. 84
Redis,DBの分割
● Redis,DBがボトルネックになり、
目標rps,目標同時接続数を達成するためには
Redis,DB分割を行わなければならない状況となった
● 当初は分割は何もしていなかったが、
負荷試験期間中に分割を実施

85. 85
DBのCPUが100%で張り付く

86. 86
レプリカラグ増大しすぎ事件

87. 87
DBのCPUが100%で張り付く
● 試験当時、DBは3つあった(RDS)
● ３つのうちどれか１つがなぜかCPU100%で張り付く
● そしてレプリカラグが10時間くらいも

88. 88
DBのCPUが100%で張り付く
● 試験当時、DBは3つあった(RDS)
● ３つのうちどれか１つがなぜかCPU100%で張り付く
● そしてレプリカラグが10時間くらいも
Auroraへの移行で解消

89. 89
az間のレイテンシ問題

90. 90
az間のレイテンシ問題
● az間にはレイテンシがある
● DBのMasterとは異なるAZでレスポンスタイムが増大
○ 例: 100ms程度のものが200msかかったり
● 最終的にはSingleAZ構成へ変更し、
万が一のことも考えて、
使用しているAZがAWS側の障害で使えなくなっても
別のAZへおひっこしできるようにある程度備えている

91. 91
ハズレインスタンス事件

92. 92
ハズレインスタンス事件

93. 93
ハズレインスタンス事件
● インスタンスが稼働している親ホストによって
性能にバラツキがあるのでは
...と思いながらもawsサポートへ連絡すると、

94. 94
ハズレインスタンス事件
● インスタンスが稼働している親ホストによって
性能にバラツキがあるのでは
...と思いながらもawsサポートへ連絡すると、
「ホスト側で障害が発生していた」
とのことで直していただきました

95. 95
Auroraのスローログこわれる

96. 96
Auroraのスローログがこわれる
● CloudWatchLogsへログを逃し、
CloudWatchLogsInsightsで
スローログの分析をするようにした

97. 97
ルームに入れない事件

98. 98
bot負荷強すぎ問題
(人間にはできない高速な操作をしていた)

99. 99
メモリもりもり事件

100. 100
メモリもりもり事件
● 3GByte程度のメモリ使用率から、

101. 101
メモリもりもり事件
● 3GByte程度のメモリ使用率から、
いきなり
60GByte！

102. 102
メモリもりもり事件

103. 103
メモリもりもり事件
大量にメモリ確保してプロセスが落ちる！

104. 104
メモリもりもり事件

105. 105
試験シナリオの停止忘れで
メモリリークに気づく

106. 106
ElastiCache
TCP再送しまくり事件

107. 107
いろんな事件がありました

108. 108
今となってはいい思い出です

109. 109
負荷試験で見逃してたら、
リリース後にこれらの事件に
遭遇していたと考えると
ゾッとします

110. 110
あ、そういえば
まだありました

111. 111
リリースの延期！

112. 112
リリース延期
● 当初予定していた時期よりも数ヶ月先に延期
● 数ヶ月ずれることで、
負荷試験時のwebサーバ、gameサーバのコードに
そこそこの変更あり
もう一度負荷試験を
やったほうが良いのでは？

113. 113
ってことで、

114. 114
第二次負荷試験！！

115. 115
しかし...!

116. 116
特定のAPIが重すぎて
試験できない問題

117. 117
第二次負荷試験
● とあるwebのAPIでレスポンスタイムが激重に
○ 第一次負荷試験時から数ヶ月経過していたため、
アセットのリストが肥大化していた
○ アセットリストを返すAPIで激重に...!
○ 試験ができないレベルだったので
試験シナリオからこのAPIは除外
○ 除外したAPIは後日改修して試験
○ １ヶ月後ごろに修正が取り込まれて爆速になった.

118. 118
性能限界試験

119. 119
性能限界試験
● webサーバの台数を増やしていって、
rpsの伸びが鈍化する台数をみておく
● gameサーバを増やしていって
同時接続数のピークが伸びなくなる台数をみておく

120. 120
性能限界試験
● 結果としては負荷とgameサーバの台数増やして、
DBが詰まり始めたので
その時の構成がシステム限界だった

121. 121
性能限界試験
● 驚くべきことに、
webサーバはいくら増やしても限界が見えなかった...

122. 122
まだ
トラブル？はあります...!

123. 123
生放送中に
リリースボタン押します！

124. 124
負荷やばくね!？

125. 125
作戦会議
● 性能限界を超えるアクセスがあると、鯖落ちする
● 性能限界に達する前に、
「ユーザ流入せき止め作戦」を用意しておくことに...!

126. 126
作戦会議
● 性能限界を超えるアクセスがあると、鯖落ちする
● 性能限界に達する前に、
「ユーザ流入せき止め作戦」を用意しておくことに...!
→ユーザ数が多すぎると、
新規ユーザ作成ができないモードにする

127. 127
サービス開始当日

128. 128
サービス開始当日
● 最悪のケース(=嬉しいケース)を想定して、
はじめから性能限界構成でサービス開始。

129. 129
サービス開始当日
● ネット上では、
サービス開始して即メンテになるのではとの見方も

130. 130
サービス開始直後

131. 131
サービス開始直後
ネット上の書き込み
「鯖落ちしないとかやるやん！」

132. 132
サービス開始直後
ネット上の書き込み
「鯖落ちしないとかやるやん！」
...というありがたいお言葉をいただきました

133. 133
リリース直後
● 結果としてはreq/sec、 同時接続数は
性能の範囲内になったので、
インフラ面としては安定稼働となった。

134. 134
リリース以降

135. 135
DeadLock発生時にslack通知

136. 136
DeadLock発生時にslack通知
● グラフをみていると、
時たまレスポンスタイムがかなり増大している様子
● 同じタイミングでDBのLockTimeのグラフも増大
● slack通知をするように

137. 137
DeadLock発生時にslack通知

138. 138
DeadLock発生時にslack通知
● サーバエンジニアにて
対応をすすめていただけていたようで、
改善対応が入ってからinnodb_row_locktimeのグラフが落ち着いた!

139. 139
発表は以上です

140. 140
ありがとうございました