コロプラのエンジニアブログ Vol.5【サーバーサイド 白猫負荷対策チーム】

私たち白猫負荷対策チームは、普段は『白猫プロジェクト（以下、白猫）』チームでサーバーサイドエンジニアをしています。

多くの方にプレイいただいている『白猫』には、 Google が提唱するサービスやインフラの信頼性を維持するための SRE（Site Reliability Engineering）チームが 2018年 6月から参加しており、モニタリング整備に加え、サーバー台数に関して属人化していた部分を減らしていきました。

次第にそのSREチームは他タイトルも横断的に見るようになっていったため、『白猫』内のイベント毎の台数調整などタイトルに寄った部分に関しては、白猫負荷対策チームを結成しこのチームで見ていくことになりました。
今回は白猫負荷対策チームが普段していることについて話していこうと思います。

河本 結理 / 2016年12月、サーバーサイドエンジニアとして中途入社。『白猫プロジェクト』のサーバーサイドを担当、白猫負荷対策チーム所属。

李 蓓瑶 / 2018年3月、サーバーサイドエンジニアとして中途入社。『白猫プロジェクト』のサーバーサイドを担当、白猫負荷対策チーム所属。

野中 智矢 / 2019年4月、サーバーサイドエンジニアとして新卒入社。『白猫プロジェクト』のサーバーサイドを担当、白猫負荷対策チーム所属。

日々していること

SREチームがこれまで見てくれていたイベント毎の台数調整や、日々行われるリリースの監視と数値の記録を主にしています。また『白猫』は長期運用タイトルのため、パフォーマンスが劣化している箇所が無いかも確認しています。

以下、サーバー台数の見積もり方法・日々の記録方法・システム改善で行なっていることを具体的に見ていきます。

1. サーバー台数の見積もり方法

通常のイベントと、周年などの大型イベントでは見積もり方法が変わってきます。通常のイベントの場合、大体リリースの前日に見積もりします。前日に見積もりするのは、より近い値に近づけるためです。また、大型イベントの場合は相当の台数が必要になるため、サーバーを確実に確保できるように およそ1ヶ月前から見積もりを始め、データベースへの負荷対策なども念入りにするようにしています。

まず通常のイベントですが、見積もりを出すためにいくつか必要な情報があります。

1　過去に実施した類似イベントのリクエスト数の前日比
　● そのイベントに対してどれだけリクエスト数が上がったか相対的に見るために必要な数値です。

2　プッシュ通知の送信時間やイベントのリリース手順
　● プッシュ通知ではおおよそ 1.1倍のリクエスト数になることが記録から見えてきています。そのため送信時間がピーク時間と重なる場合は、見積もりに影響してきます。
　● イベントのリリース手順に関してもイベント内容によっては、ユーザーさまに一度タイトル画面に戻っていただく必要があるのですが、その手順を行う際に約 1.5倍の負荷がかかるため見積もりに影響してきます。

3　サーバーが CPU 1% でどれだけのリクエストが捌けるかの数値
　● CPU 利用状況やイベント内容によって捌けるリクエスト数は変わってくるため、見積もりする際に重要な値となっています。
　● CPU の使用率が一定数以上を超えると、捌けるリクエスト数が徐々に下がっていく傾向があると記録から見えてきています。
　● 特定の機能が使われる場合に、処理が重くなる箇所があり、捌けるリクエスト数が下がっていくことも記録から見えてきています。
　● 担当プランナーやエンジニアとコミュニケーションを取りつつ企画書を見てどれぐらい捌けるか過去のデータと比較し判断します。

例えば直近のピークリクエストが 1分間に 100回で、類似イベントの 1分間リクエスト数の前日比が 1.5倍ぐらいだとすると、1分間に 150リクエスト来ると予測できます。そこに通知がピーク時間に送信するとなった場合は更に 1.1倍となり165リクエスト。CPU 1% で捌ける量は、リクエスト数を CPU で割った値となります（特定の機能が使われる場合は効率が 8割ほど下がることもあります）。そして CPU 使用率が一定数以上超えてくると捌けるリクエスト数が下がってくる傾向があるため、CPU が一定数超えないよう調整します。

上記の例から、"リクエスト数 / CPU 1% で捌けるリクエスト数/想定台数" の計算結果で CPU が一定数超えないよう調整しています。
上記の計算方法以外にも、直近の台数とピーク時のリクエスト数と CPU 利用状況に対して、想定リクエスト数と CPU の閾値があるためそこから台数を割り出したり、ロードバランサーに来たリクエスト数や CPU 使用率の合計の実績値を元に、想定リクエスト数と台数を入力して CPU を割り出すキャパシティプランニング専用のツール ※1 もあります。
これらの手法の結果を見比べて台数を判断します。

補足として、類似したイベントが無い場合は直近のリクエスト数をベースにイベント内容を見つつ多めに見積もり、低ければリリース後に多すぎた分を減らします。またイベント以外にも週末は 一定の負荷が上がる傾向があるため、金曜日のピーク時の値とその値を考慮して見積もりをしています。

次に大型イベントとなりますが、リクエスト数の予測方法以外は、ほとんど通常イベントと同じになります。大型イベントはプランナーが DAU の見積もりを立てているためそちらをベースに、過去の大型イベントの数値と照らし合わせていきます。

大型イベントでは下記の数値を出して、盛り上がり度として保存しています。
　● 当日の DAU に対してピーク 1分間に訪れている UU から割合
　● ピーク時に 1UU から送られるリクエスト数

上記の数値が高いと、盛り上がっていると捉えています。ですが後者のリクエスト数に関しては、実装方法によって上下する可能性もあるため盛り上がり度が高いとは一概には言えません。

上記の数値と見積もりの DAU から想定するリクエスト数を算出します。過去に記録した盛り上がり度の数値から、近いと思われるデータを選びます。予め予想されている DAU に対して、ピーク 1分間に訪れるUU割合・1UU のリクエスト数から概算してピーク時のリクエスト数を出します。リクエスト数が出たら、通常のイベントと同様に CPU 1% で捌けるリクエスト数を用いて CPU が一定数超えない値が台数となります。

2. 日々の記録方法

「1. サーバー台数の見積もり方法」で触れていた数値の記録方法を紹介したいと思います。記録ではいくつかのサービス・ツールを使っています。

● Googleスプレッドシート
　○ 通常のイベント・大型イベントの実績値の格納や、台数算出するための計算などに使用しています。
　○ 入力したら slack に結果を通知できるので、多すぎたら減らすなど slack 上で話し合って再度台数調整することもあります。

● Googleカレンダー
　○ プランナーがイベントを入力してくれているので、毎朝 10時に当日のイベント内容を送信して Googleスプレッドシートへ記入しています。

● LogAnalyze
　○ 内製ツールで、各タイトルの KPI を可視化している BIツールとなります。
　○ DAU結果を slack に通知することが可能なため、毎朝 10時に前日の DAU を送信して Googleスプレッドシートへ記入しています。

● Grafana / Prometheus
　○ 当記事では深くは触れませんが、 Prometheus で各種サーバーのメトリクスを収集し Grafana で収集したデータを閲覧しています。
　○※1. キャパシティプランニング専用のツールは Prometheus から収集したデータから Grafana で作成しています。
　○ Grafana からピーク時の rpm (1分あたりのリクエスト数) や CPU 使用率、サーバー台数を確認し Googleスプレッドシートへ記入しています。

● Google BigQuery
　○ アクセスログが格納されており、大型イベントの見積もり時に使った盛り上がり度はこちらから必要な値を取得しています。

現状は基本手動で記録しており、流れは以下となります。Slack に毎朝前日の DAU、当日のイベントが通知され Googleスプレッドシートへ記入し、リリース時間に Grafana を監視し rpm, CPU, サーバー台数を記入します。大型イベント時は上記にプラスして、Google BigQuery からピーク時のUU・1UUのリクエスト数を取得し、盛り上がり度として Googleスプレッドシートへ記入しています。

3. システム改善

毎週 newrelic の確認をしており、そこで時間がかかっている処理を探し、タスクとして消化しています。特定アイテムの所持数が増える都度 db アクセスが上がる機能、特定機能が使われると重くなるクエリ、スロークエリなどいくつか改善する余地があるものが見つかっているため今後解消していく予定です。

また直近ですと大型イベントのリリース時に slave 遅延が発生した際に、インフラエンジニアが slave の設定値を変更し解消したのですが、後日、白猫負荷対策チームがプラスして binlog から書き込みが多いクエリを抽出し、無駄な書き込みが減るよう対策を行いました。

今後の改善・活動

以上、白猫負荷対策チームが普段行っていることを紹介させていただきました。
今後としては改善タスクの消化や、記録に関して手動の部分が多いため、各種ツールから Googleスプレッドシートなど見積もる際に閲覧しやすいツールに自動で記録できるようにしたいと思っています。
当記事から参考になるものが 1つでもあれば幸いです。

こちらに情報も記載していますので、ぜひご覧ください！

• Twitter
• connpass
• COLOPL Tech Blog
• Speaker Deck