Build Insider MEETUP with Grani 第1回レポート(2)
最新Windows技術中心で実現するとこうなる! ソーシャルゲームのインフラ構築&運用
ソーシャルゲームの運用環境を、LinuxからWindows(PHP→C#)に変えた企業が最終的に実現したインフラとは? Windows系インフラエンジニア必読の、Build Insider主催勉強会のレポート記事。
2015年3月25日(水曜日)、Build Insider主催&グラニ共催の勉強会「Build Insider MEETUP with Grani 第1回」を開催した(場所は、六本木ヒルズ森タワー15Fにあるグラニのファンスペース)。この勉強会では、下記の2つのセッションがあった。
- 1A Framework for LightUp Applications of Grani
- 2Grani's way of thinking Infrastructure
本稿は、グラニの立ち上げ時からインフラ構築に携わっているインフラ部長の齋藤 龍一 氏(カスタマーサポート部のマネージャーも兼任)が登壇した2のセッション内容の中から、筆者が重要だと感じたポイントを簡潔にまとめたものである。文章によるレポートの他、本稿の最後にはセッションスライドと動画もあるので、全内容を詳しく知りたい場合は併せて閲覧・視聴してほしい。
セッション2: Grani's way of thinking Infrastructure
株式会社グラニ 齋藤 龍一(さいとう りゅういち)
「サービスを乗せるインフラの構築と運用」が、齋藤氏が部長を務めるインフラチームの仕事となる。グラニでは、AWSでソーシャルゲーム運用のためのインフラを構築しており、例えばEC2インスタンスの構築を自動化するなどしている。その他、社内コンピューターや開発用サーバーアプリケーションの管理などを含む、社内インフラの保守も行っているという。
セッションでは、そのインフラチームが行ってきた仕事が時系列で紹介されたが、その中のマイルストーンとして、まずグラニのサービスリリースの歴史が示された(図1)。
・「ヴァルハラ」=「神獄のヴァルハラゲート」。
・「モンハンロア」=「モンスターハンター ロア オブ カード」。
・「マンモンラン」=「マンモンラン 爆走のヴァルハラゲート」。
第1のマイルストーン: 2013年1月、“ヴァルハラ”のリリースまで
2012年9月にグラニを創業して最初にリリースした製品が、「神獄のヴァルハラゲート」というソーシャルゲームだ。実はこのゲーム、PHPで実装されており*1、図2に示すようによくあるLAMP(Linux、Apache、MySQL、PHP)環境のインフラ構成になっていた。
* 2015/05/13更新 「PHP 5.6」となっていた箇所を「PHP 5.4」に修正しました。図3についても同様の修正を行いました。お詫びして訂正させていただきます。
- *1 ちなみに、この時点でもごく一部(バッチ部分など)のコードはC#になっていたという(* 2015/05/13更新 説明の一部に事実誤認がありましたので、その部分をカットしました)。
齋藤氏の前職はソーシャルゲーム会社での開発担当で、その流れから、グラニの立ち上げ期でも開発エンジニアとして仕事をしていたのだが、インフラ構築を専任で担当できる者が社内にいなかったため、齋藤氏1人がインフラ関係も兼任で担当することになった。その当時、インフラ構築に関しては初心者だったが、何とかサービスリリースを成功させた。しかしその裏には、下記のような問題点を抱えていたという。
- Linux初心者で知識不足だった
- インフラ担当が1人のため、肉体的にも精神的にもつらく、「自分がSPOF(Single Point of Failure:単一障害)になりかねない」という危機感もあった
- リリース後、何となく正常に動作してしまったので、逆になぜ動作しているか分からず、サービスダウンにおびえる日々を過ごした
第2のマイルストーン: 2013年7月、“ヴァルハラ” v 2.0のリリースまで
2013年1月のヴァルハラ(バージョン1)のリリース後、2人のインフラエンジニアがグラニにジョインして3人体制になったことで、上記の問題は解消された。
ヴァルハラのユーザー数も増え、テレビCMが予定されるなど、会社もアプリも絶好調になってきた。その半面、新たな問題も表面化してきた。具体的には、下記のような問題だ。
- PHP実装のコードがおせじにも「きれい」とは言えず、インフラも初心者が作ったものなので例えばネットワーク構成が「取りあえず動けばよい」というレベルだったりと、技術的負債が多かった
- CakePHPやPHPのレベルで、アプリのパフォーマンスが高まらず、サーバー台数を増やして対応したため、コストが増加した
「こんな状況では、テレビCMが開始され、大量のユーザーがやってきたら、さばけない!! 近い将来、詰む……!!!」
これがきっかけとなり、CTO河合氏が「C#に移行しよう」と提言し、実際にヴァルハラのバージョン2に向けて、今ある全てのPHPコードベースをC#に一本化していくことになった。
ただしC#への移行は一筋縄ではなかったという。そもそも実運用しているビジネスは止められない。それに伴って増えていくPHPコードに、C#側コードも追従していく必要性が発生した。また、スマホだけでなくガラケーにも対応しているので、古いFlash Lite技術を使ってアニメーションを動的に合成したり、ガラケーの絵文字に対応したりする必要があり、PHPならそういった処理に使えるライブラリが存在したがC#にはないので、簡単に移行できないことが課題となった。さらにインフラも問題で、LinuxサーバーからWindowsサーバーに移行したため、「WindowsサーバーのIISのチューニングはどうすればよいのか」や「Linux向けのCapistranoツールに依存したデプロイ環境からの移行をどうすればよいのか」など、数多くの課題があった。
C#移行に伴い、これらの数多くの課題を1つ1つ解決していった。具体的には、下記のような対処を実施した。
- SWF(Flash Lite技術)での動的合成や絵文字対応:
→ C#で社内ライブラリを作成 - MySQLへの接続やRedisへの接続:
→ 既存の.NETライブラリに対する、独自のラッパーを作成 - WindowsサーバーのIISのチューニング:
→ MSDNやWeb上の技術ドキュメントをあさり、地道に頑張った - デプロイ環境:
→ Capistrano相当のツール「Valentia」を自作(詳細後述)。ちなみにCUIツールだけでなく、GUI(WPF製)でクリックにより作業できるツールも作成した
C#への移行の結果、PHP時代と比べて、以下のような効果が得られ、無事、CMによるトラフィック急増も乗り越えられた。
- 1台あたりのスループット向上
- Webサーバー台数を減らせた
- 汚いPHPコードを一新でき、技術的負債を一部返済できた
- 在籍エンジニアが本来のパワーを出せるようになった(当時、すでに8割ほどがC#開発者になっていたので)
サーバー構成についても、図3に示す通り、移行によってかなりシンプルになった。
図3のポイントを説明すると、まずnginxが担当していたリバースプロキシー機能は、IISのARRが担っている。また、Redisもバージョンアップするなどしている。Memcachedは、Redisで代用できるので無くした。
このようにC#移行は大成功に終わったと、齋藤氏は説明した。
第3のマイルストーン: 2013年7月、“モンハンロア”のリリースまで
C#移行が完了し、ヴァルハラのユーザー数が増える中、新しいゲーム「モンスターハンター ロア オブ カード」という別プロジェクトが立ち上がった。そこでまた、新たな問題点も浮き上がってきた。具体的な以下のような点だ。
- C#移行に伴うインフラの課題点(前述の「技術的負債」)がいくつか残ったまま
- ユーザー数や運用期間の増大につれて新たに発生した細かな問題点(データベースのデータ量が増えてきたり、設計・実装時は考慮していなかった問題が発生したりなど)
モンハンロアのプロジェクトは、これらの問題点を解消するために、一からインフラ環境とアーキテクチャを構築し直す良い機会となったという。具体的にはこの時期、以下のようなことを実施した。
- ネットワーク設計の見直し
- AWSのスポットインスタンスを活用してコスト削減
- MySQLの当時の最新バージョン5.6を採用
- AWSのElastiCache for Redisを採用
- アバター画像などの動的生成サーバーを作成(ImageMagickのような機能を自作)
先ほどと同じようにサーバー構成を示すと、上記の対応により図4のように変化した。
当然ながらこの結果、ヴァルハラとモンハンロアで、各プロジェクトのプログラミング環境やインフラ環境が大きく乖離(かいり)することになった。また、仕事の専門性が増して、「これに関する作業はこの人しかできない」ということ(SPOF)が増えてきたと、齋藤氏は当時の課題を振り返った。
第4のマイルストーン: 2014年11月、“マンモンラン”のリリースまで
モンハンロアのリリースから数カ月後、上記の課題の解決に向けて、以下のようなことを実施したという。
- インフラエンジニアがさらに1人増えて4人体制に。新人を介して知識のSPOFを無くすようにしていった
- Immutable Infrastructure: Web界わいで現実的な事例が出てきたので調査開始した
- ログ収集基盤の構築: このときまでにもAWS RedShiftなどさまざまなサービスを調査してきていたが、河合氏の記事で説明されたBigQueryに決まったのはこのころ
- AD(Active Directory)、ADFS(ADフェデレーションサービス)、Azure ADを使ったSSO(シングルサインオン)環境の構築: 社員数も増えてきたのでセキュリティ面をより強固にしつつ、働きやすい環境にした
こういった課題解決をしつつ最近では、iOS/Androidネイティブアプリも手がけ、「マンモンラン 爆走のヴァルハラゲート」という“ランゲー”をリリースしている。
セッションでは、上記のインフラ環境の課題解決の中で、「Immutable Infrastructure」について、より詳しい説明があった。
Immutable Infrastructure
Immutable Infrastructureとは、直訳すると「状態が変わらないインフラ」ということになる。要するに、サーバーのセットアップをしたら、それには手を加えず、要らなくなったら棄てて新たに作り直す、ということで、いわば「Disposable Components(使い捨て可能なコンポーネント)」である。
Disposable Componentsとは、「要らなくなったら捨てられる」ということで、それを実現するためには、サーバー設定や、そのサーバーにインストールされるべきミドルウェアといったサーバー構成(Configuration)などが、いつでもあるべき状態(Desired State)になっている必要がある。そうするためには、その状態をコードで書いて管理した方が効率的である。すなわち「Infrastructure as Code」だ。
あるべき状態にサーバーをどうセットアップ(=プロビジョニング)すればよいかというと、シェルスクリプトやPowerShellスクリプトなどで地道に書いていくことも考えられるが、いかんせん、正常に動作するものを作るのは大変で、できたとしてもそのスキルをメンバー全員に伝えていくのも難しい。こういったプロビジョニングの課題を解決できるプロビジョニング・サポート・ツールとして、最近ではChef、Serf、Docker、Vagrantなどが登場している。
一般的なプロビジョニングの過程は、次のような3つのレイヤーに分けることができるだろう。
- Bootstrapping(OSインストール):
→ AWS EC2/Docker/Vagrantなどを使用する - Configuration(ミドルウェアのインストールや設定):
→ Chef/Ansibleなどを使用する - Orchestration(サービスとして動くようにする):
→ Capistrano/Serfなどを使用する
グラニの場合は、各プロビジョニングレイヤーで下記のようなツールを使うことになったそうだ。
- Bootstrapping(OSインストール):
→ AWS EC2 - Configuration(ミドルウェアのインストールや設定):
→ PowerShell DSC(Desired State Configuration)(後述) - Orchestration(サービスとして動くようにする):
→ Valentia(後述)
PowerShell DSCについて詳しくは、連載記事などを参照してほしいが、例えば次のようなコードを記述する。
Valentiaについてはすでに紹介したが、もう少し説明しておこう。これは、アプリをサーバーに簡単にデプロイするために、グラニのインフラエンジニアが作成したツールである。その実体はリモートサーバーに(PowerShellスクリプトに記載された)コマンドを送信するような仕組みになっている。例えば次のようなコマンド実行により、このValentiaが使える。詳細を知りたい場合は、こちらも参照してほしい。
最後に
この他、現状の課題やインフラ構築のポリシーなどが説明されたが、本稿では割愛する。興味がある方は、以下の動画を視聴してほしい。
セッションでは締めくくりとして、「Windowsインフラを選択肢にする」ためのモデルケースに、グラニ自身がなり、事例や成果物を今後も公開していきたい、と語った。
■
このセッションのスライドと動画
セッションスライド
セッション動画
1. 「using CSharp;」な企業を支える技術方針とベスト.NETライブラリ
「最先端のC#技術活用」を掲げる会社の開発現場では、どのような技術やライブラリが、どんな理由で使われているのか。C#開発者必読の、勉強会レポート。