大規模になったサービスでやるべき基本的なこと

2人目のご登壇は、株式会社ミクシィ XFLAG スタジオの清水勲さんです。

清水勲（しみず・いさお）/株式会社ミクシィ XFLAG スタジオ ゲーム開発室 SREグループ。大手SIerでの勤務を経て、2011年にミクシィへ入社。クラフトビールが大好き。

■サービスが大きくなるときに対応すべき7つのキホン

ミクシィのXFLAG スタジオが展開する人気スマホゲーム「モンスターストライク」は、2017年1月時点で世界累計利用者数が4,000万人を突破。清水さんはこの状況を「日々増えるアクセスによる負荷との戦い」と形容します。こうした状況に対応するための基本的な問題として清水さんは次の7点紹介します。

・監視、モニタリング
清水さんは、「Nagios」「CloudForecast」「Mackerel」「Datadog」などのツールをうまく活用して、負荷を可視化することが大切だと説明します。

負荷を可視化したグラフは毎日確認し、毎月の負荷状況をサマライズしておくと振り返り時に今後の対策に役立てられやすくなるというのが清水さんの薦めるTIPSです。

・スケールアップ／スケールアウト
増える負荷に対応するために「スケールアップ」と「スケールアウト」のどちらを選ぶべきなのでしょうか。清水さん2つを以下のように解説し、適材適所に選ぶことが重要だと解説します。

「スケールアップ」
ハードウェアの性能値によってスケールできる上限が決まってしまうので、さらなる負荷対応は難しいのが特徴です。イベントなどの一時的な負荷増への対策であれば効果的。

「スケールアウト」
例えば、LB配下のアプリケーションサーバーを増やすことでCPUリソースを負荷分散させる方法があります。ただし、DBへの接続とアクセスが増える点には要注意。スケールアウトは中長期的な負荷対策として有効です。

・トラフィックの増加

負荷が増えてくるとトラフィックも意識しなければなりません。例えば、「AWS」を利用しているケースでは、インスタンスタイプによってトラフィック量の限界が決まっているため、台数を増やすかインスタンスタイプを変えるかで対処します。その際に、ベンチマークを自分でとっておくと安心だと清水さんは共有します。

・サーバー／インスタンス数の増加
サーバーが増えると管理コストもあがります。そこで、デプロイやプロビジョニングを効率化、自動化することが重要です。「Capistrano」「AWS CodeDeploy」「Chef」「Ansible」などのツールを使い、できるだけ台数に依存しないオペレーションを実現することが理想的だと清水さんは説明します。

・データベースにおけるクエリ数の増加
サービスが大きくなってからは、データベース、テーブルの単位でサーバーを分割する、シャーディングやキャッシュを活用することを清水さんはオススメします。加えて、ストレージのIO性能の限界の見極めやバッファプール利用率状況の可視化も重要です。

・データベースにおけるサイズの増加

テーブルのデータやインデックスサイズが増え、ディスクサイズを超えてしまうと対処がとても困難な状況に陥ります。

バッファプールのキャパシティにおいても、データサイズが増えプールが溢れるとSELECTクエリも遅くなります。その場合、メモリサイズを増やしてプールサイズを広げることが望ましいと清水さんは指摘します。

また、更新が多くなるとバイナリログが増え、ディスクを圧迫する要因となります。「AUTO INCREMENT」の上限値にも注意し、閾値を設定してどれくらい使っているかを監視しておくことが重要です。

・人員の増加
サービスが拡大すると、エンジニアの数も増加します。人数が増えるとアカウント管理の問題が生じてきます。

「AWS」の場合、「CloudTrail」を使って簡単な監査ログをとることを清水さんはお奨めします。

ミクシィでは、アラートにおいては「PaperDuty」を導入し、当番制やエスカレーションを効率的におこなえるようにしています。また、ノウハウや手順の共有も対処事項として起こるため、Wikiを活用し、障害発生時の対応方法をドキュメント化。事故防止のために「4eyes」での作業確認、「ChatOps」で作業できることを増やすなどの手法で対応しています。

以上7点でした。清水さんの当日のスライドはこちらに公開されています。