Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

禍つヴァールハイトを支える負荷試験

66 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

禍つヴァールハイトを支える負荷試験

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

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

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

  4. 4. 4 その前に、

  5. 5. 5
 まがつってなに?

  6. 6. 6    遡ること2017年

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

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

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

  10. 10. 10 すげー!

  11. 11. 11
 負荷やばくね?

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

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

  14. 14. 14
 負荷やばくね?

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

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

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

  18. 18. 18 webサーバ

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

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

  21. 21. 21 同期通信が必要!

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

  23. 23. 23 gameサーバ→

  24. 24. 24
 目標値

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

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

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

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

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

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

  31. 31. 31 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア 負荷試験 おねがいします!
  32. 32. 32 インフラエンジニアとサーバエンジニア
 
 
 
 インフラ エンジニア サーバ エンジニア 負荷試験 実施中... アタッカー 実行中 各種メトリクス 確認
  33. 33. 33 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア メモリリークしてるっ ぽいよ! 確認おねがいします ><;
  34. 34. 34 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア 修正 対応中...
  35. 35. 35 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア 対応しました!
  36. 36. 36 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア なおってるようです! ありがとうございます!
  37. 37. 37 逆もある

  38. 38. 38 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア グラフが バグってるんですが ...
  39. 39. 39 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア ひぃ〜 すいませんなおします ... (土下座) 修正 対応中...
  40. 40. 40 インフラエンジニアとサーバエンジニア
 
 
 インフラ エンジニア サーバ エンジニア なおしました!
  41. 41. 41 ...と、このように
 サーバエンジニアに、
 「ここ直して!」

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

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

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

  45. 45. 45
 webサーバの試験

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

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

  48. 48. 48
 gameサーバの試験

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

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

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

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

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

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

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

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

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

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

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

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

  61. 61. 61
 大量切断の問題

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

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

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

  65. 65. 65 同時接続数の大量切断
 スレッドA スレッドB タイムライン
  66. 66. 66 同時接続数の大量切断
 スレッドA スレッドB RLock() 読み取りロックして、 
 タイムライン
  67. 67. 67 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() 読み取りロックして、 
 さらに読み取りロック 
 するぶんには
 
 問題は
 発生しなかったが...
 タイムライン
  68. 68. 68 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() 読み取りロックして、 
 さらに読み取りロック 
 するぶんには
 
 問題は
 発生しなかったが...
 RUnlock() RUnlock() タイムライン
  69. 69. 69 同時接続数の大量切断
 スレッドA スレッドB タイムライン
  70. 70. 70 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() スレッドAだけ
 だとこう
 RUnlock() RUnlock() タイムライン
  71. 71. 71 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() 運悪く(?)
 
 スレッドAの
 RLockと
 RLockの間のタイミングで 
 
 スレッドBで
 排他ロックをしてしまうと... 
 RUnlock() RUnlock() Lock() タイムライン
  72. 72. 72 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() 運悪く(?)
 
 スレッドAの
 RLockと
 RLockの間のタイミングで 
 
 スレッドBで
 排他ロックをしてしまうと... 
 RUnlock() RUnlock() Lock() ロック 獲得待ち タイムライン
  73. 73. 73 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() 運悪く(?)
 
 スレッドAの
 RLockと
 RLockの間のタイミングで 
 
 スレッドBで
 排他ロックをしてしまうと... 
 RUnlock() RUnlock() Lock() ロック 獲得待ち ロック 獲得待ち タイムライン
  74. 74. 74 同時接続数の大量切断
 スレッドA スレッドB RLock() RLock() 運悪く(?)
 
 スレッドAの
 RLockと
 RLockの間のタイミングで 
 
 スレッドBで
 排他ロックをしてしまうと... 
 RUnlock() RUnlock() Lock() ロック 獲得待ち ロック 獲得待ち デッドロック タイムライン
  75. 75. 75 同時接続数の大量切断
 ● このようなデッドロックにより...
 ○ クライアントにレスポンスが返せなくなり、
 その結果コネクションの大量切断が発生していた

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

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

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

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

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

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

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

  83. 83. 83 Redis,DBの分割

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  111. 111. 111
 リリースの延期!

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

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

  115. 115. 115 しかし...!

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

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

  118. 118. 118
 性能限界試験

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

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

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

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

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

  124. 124. 124
 負荷やばくね!?

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

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

  127. 127. 127
 サービス開始当日

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

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

  130. 130. 130
 サービス開始直後

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

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

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

  134. 134. 134
 リリース以降

  135. 135. 135 DeadLock発生時にslack通知

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

  137. 137. 137 DeadLock発生時にslack通知

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

  139. 139. 139
 発表は以上です

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


×