【CEDEC2017】グリーのリードエンジニアが教える「クラウド時代の長く効率よく運用するためのゲームサーバとインフラ設計」

一般社団法人コンピュータエンターテインメント協会（CESA）が、8月30日～9月1日までパシフィコ横浜にて開催した、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2017」（CEDEC 2017）。 

本稿では、8月30日に実施された講演「クラウド時代の長く効率よく運用するためのゲームサーバとインフラ設計」についてのレポートをお届けしていく。 本セッションでは、グリー株式会社のリードエンジニア・堀口真司氏が登壇。多種多様なサーバを運用してきた経験から、起こった問題や改善を紹介した。


▲グリー株式会社のリードエンジニア・堀口氏。コンシューマゲーム、オンラインゲーム、アーケードゲームなどの開発を経て、現在スマホ向けサービスのサーバ管理や技術サポートを行っている。


本セッションでは、まず堀口氏がグリーのサービスについて大まかに説明。その後、「インフラとはなにか」という根本的な部分からスタートした。本セッションは、これからオンラインゲームのサービスを始めようと考えていたり、他社の事例や改善を取り入れたいエンジニア。または、インフラ技術を知りたい方や、インフラエンジニアってなんだろう？という興味を持つ方を対象にしており、チュートリアル的な要素も含んでいる。

インフラとは、「アプリに必要なもの色々」であると堀口氏。効率的なOSやミドルウェアの設定・最適化・調査・対応、リソースの見積もりと費用の最適化などがあり、インフラは安定しているのが当たり前であるため普段は存在を意識しない部分だという。しかしながら、2015年の「ゲーム開発者の生活と仕事に関するアンケート」によると、サービス運営型従事者となっているゲーム開発者は全体の2/3にも上り、当たり前に存在すべきインフラに依存するコンテンツや人は増え続けている現状がある。一方で、インフラは規模×期間で難しくなるという。リリース直後は人が集まるが、その後人気が低迷したとしてもサービスを落とすわけにはいかない。売上があるうちは継続させるため、運営期間が長くなるほど支えるための人やカネを多く消費するようになり、やがて維持できなくなる傾向がある。

堀口氏が考えるインフラエンジニアとは、存在が気づかれないぐらい何事もないのが当然だという。しかし、現実では様々な問題が発生すると語った。

 
▲オンプレの特徴と、モノリシックなサービスについて。

話題は、“おさらい”として、基本的なLAMP環境とスケーリングに。システムの基本要素としては、携帯から来たHTTP/HTTPSのリクエストをApacheやnginxなどで受けて、その先にMySQLやredisなどの永続的なサーバを配置する。つまり、1つのDBと1つのWebが必要となる。

リクエストを捌く流れは下記の通り。
1：HTTP Requestが来る
2：何か処理をしてDBへ問い合わせる
3：DBから情報をもらい、結果を作る
4：HTTP Responeseを返す

もしリクエストが膨大になった際、一箇所でも詰まるとすべてが詰まってしまう。HTTPワーカーは処理中に新しいリクエストを処理できず、DBの処理にも限界がある。これに対応するには、ワーカーを増やし、携帯やスマホなどからのアクセスを並列非同期に処理する必要がある。


▲10数台規模の基本的なシステム構成。

 
▲スケーリングの規模が数100台の場合。

 
▲スケーリングの規模が数1000台の場合。規模が拡大するにつれて、障害のダメージや全体変更時間の増加などが変化する。

次に堀口氏は、スケール以外の厄介な問題を紹介。負荷以外の障害として、最も起こるのが破損である。「データを保持するサーバなどが壊れた」際は、レプリカに切り替えたり、バックアップまで巻き戻す作業が必要になる。切り替え先がなく、バックアップもなければ最悪サービス終了に、そのタイトル1本に頼っている場合は会社ごと無くなることもあるという。

 
▲負荷以外の障害について。

復帰に時間がかかるケースとしては、Jenkinsが壊れた場合、バッチや集計処理用のサーバなどが挙げられた。前者は、バージョンアップが激しく同じ状態に戻らない、各々がプラグインを入れている、ジョブのバックアップがない、Javaのバグを踏む、Jenkinsでリリース処理やイベントの処理を行っている、などがある。後者は、色々なデータやジョブを保持している、インフラでは内容が把握しにくい、よくOOMが出たりCPUがサチる、などの危険性があるという。

障害が発生するとレビューが荒れ、ゲームの品質を損なう結果を招く。また、補填などの追加施策が必要となり、機会損失だけでなく協力会社へ影響も起こり得る。これらを防ぐ、というよりも当然の如く安定させるのがインフラであると堀口氏は語った。

 
▲障害も様々。外部からの攻撃多く、BOTはすぐに現れる。

 
▲長期運用になるとシステムが古くなり、仕組みも把握しきれなくなる。

続いての話題は、事例を交えた効率化について。開発者や権利関係者たちは、基本的に担当のサービス1つに集中している。しかし、インフラは共通の技術を扱うため、他のサービスで得られた知見を共有しやすいように、チームを組んで対応している。仕事の流れとしては、まずゲーム開発者とざっくりとした調整を行う。その内容はスケジュール共有や事務的な手続きから始まり、使う言語や依存ライブラリ、必要なバックエンドのシステム、ログの取り方解析方法、デプロイ方法、モニタリングツール、セキュリティ関連など様々だ。

 
▲スケジュールはこのようなイメージとなる。インフラの相談が来るのはリリースの半年～1年前ほどだそうだ。

 
▲グリー社内において、ゲーム開発にはPHPを用いることが多いという、

 
▲パフォーマンスと費用の関係。グリーのゲームをいくつかサンプルとして扱っている。

 
▲並列処理と非同期処理の特徴など。

 
▲堀口氏の私見として、秒間1万コネクションに近くなったらプール系の運用を考えるという。

グリーのゲームにおいて、よく使われるバックエンドは「MySQL」「Redis」「memcache」「AWS DynamoDB」などがある。それぞれの特徴だが、「MySQL」は複雑なトランザクションや高度な分散システムを必要としないゲームとの相性が良い。ランキングやPubSubを使うものに対してはRedisがオススメで、そこそこの揮発性とレプリケーションもゲームとの相性が良いという。memcacheはユーザIDなどでキーを分散させやすくゲームと、ドキュメン指向の「AWS DynamoDB」はゲーム、最小コストが安価でそれ以外でも相性が良いという。ここまで相性の観点から紹介した堀口氏だが、インフラ的には無停止でスケールできるか、障害時のオペレーションは簡単か、データの巻き戻しや復旧はどうか、要は簡単に扱えるかを重視していると話した。

 
▲更新系と参照系でアクセスが異なるなど、レプリケーションの特徴について。

 
▲ログの種類（左）やログなどの注意点（右）。


▲ログの回収・転送方法について。

上記のうち、クローリングについては、実装がシンプルで、プロトコルやフォーマットに依存しないという特徴をもつ。テキストなら何でもアリで、分析もテキストベースなので簡単に扱うことができる。ただし、大量のテキストログ解析にかなり時間がかかり、クロールが間に合わなかった分は障害時に消えるという一面も。

fluentdを使った転送に関しては、送り先（受け口）がたくさんあり、分析サービスを使い分けられると説明。送り先も柔軟で、定期的に送る、サーバシャットダウン前に送る、大量のサーバのログを一箇所にまとめてから送るなど、様々な対応ができる。また、どのファイルをどこまで転送したかという情報が永続的に残るため、障害時に強い。総じて、雑な運用に耐えられる特徴をもつ。

 
▲特殊サービスを利用する場合（左）、DBに入れておく場合（右）。

続いて話題は「デプロイ」に。サーバで動作しているアプリのコードを最新のものと置き換えるものだが、まだまだ課題が多いと堀口氏。無停止でできるか、一貫性のある動作になるか、ロールバックはできるか、デプロイ速度は十分か、切り替え方法は適切か、キャッシュの揮発に影響は問題ないか、などが挙げられた。それぞれの説明は下記を参照。

 
 
 

「モニタリング」の話では「死活監視」と「リソース監視」を紹介。死活監視はアプリが正常に動いているか、リソース監視はCPU使用率やディスクの空き容量などを数値化したものである。

 
▲「死活監視」と「リソース監視」のそれぞれの特徴。

これからの見通しに関しては、AWSを筆頭に「エンジニア向け」のサービスが増加、GCP／Azureなどの加速、IaaSレイヤの希薄化などが挙げれた。また、運用のソフトウェア化も進み、自動化がしやすくなっている現状も踏まえ、自動化のための開発が必要になっていると発言。負荷を予測しスケールする、アラートから機械学習で予測するなどを行うことで、休日深夜を平穏に過ごす方法が重要になってきていると語った。

最後に、最近はいわゆる「ゲーム」らしいアプリが増加しており、バトルや共闘のようなマルチプレイ要素が多く含まれるようになってきたという。内容に合わせて採用ミドルウェアや開発言語が変わってくる。HTTP以外のプロトコルが台頭することで、いわゆるLAMP系の技術だけでは通用しなくなる。インフラ側から「できません」というのはちょっとダサいと語る堀口氏は、今後ゲーム開発に近づいたインフラ設計が重要であるとコメント。そして「自動化とデータ化を常に考えましょう！」と語り、本セッションを終えた。