7月25日にはDeNAをゲストに迎えて「DeNAとPhotonが語る!! ゲーム開発に集中するための技術アーキテクチャ～DeNAの～開発基盤とPhotonの最新情報（IPV6対応）～」と題した勉強会を渋谷のGMO Yoursで開催。GMOアプリクラウドによる総合プロデュースのもと、数十名のエンジニアが参加し、最先端のゲームサービス運用について事例を学びました。
【DeNAのインフラを支えるSakashoの運用】
勉強会は二部構成をとり、前半ではDeNAの春山誠氏が「DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて」と題して講演を行いました。なお本講演のスライドは下記にアップされているので、あわせてご覧ください。
http://www.slideshare.net/blueskyblue/dena-sakasho
ウェブアプリからネイティブアプリに移行する過程で、内製の開発コンポーネントを積み上げてきたDeNA。本講演で紹介された「Sakasho」もまた、そうしたコンポーネントの一つです。その目的はユーザー情報・マスターデータ配信・課金など、ゲーム開発・運用に共通して用いられる機能を一括して提供することで、ゲーム開発の効率化を進めること。約50種類のAPIに加えて、クライアント向けのSDKやWebView用インターフェースも提供しています。
Sakashoは大きく「認証サーバ（プロキシサーバ・Webサーバ））」「APIサーバ」「Sakasho DB」からなるサーバ群と管理ツールによって構成されています。SDK経由のネイティブアプリと、Web View経由のウェブアプリとでデータの仕様を統一するために、必ずAPIサーバを経由する点がポイントです。1日のアクセス数は8000万にものぼり、これを12台のプロキシサーバ、26台のAPIサーバ、そしてDB（4系統のMySQL、水平分散あり）で分担しています。
DeNA・春山誠氏
なおSakashoはクラウドではなく、社内の減価償却が終わったサーバを中心に、オンプレミスで構築されています。この手の共通プラットフォームでコストがかさむと、ゲームの売上にも影響が出かねないためです。もっとも春山氏は「Webサーバのようにオンメモリで動作できるものであれば、意外と枯れたサーバの方が故障率が低いんです。もちろんDBのようにディスクにアクセスするものは、最新のサーバを使用しています」とあかしました。
開発にはRubyが使用されています。当時、社内ではPerlが主流でしたが、たまたまSakashoの開発・運用にあたったチームでRubyのエンジニアが多かったためとのこと。その後、Rubyエンジニアの採用が増えたこともあり、本格的に採用されました。Perlで書かれたツールを1-2ヶ月かけて、すべてRubyに書き直した経緯もあるほどです。なお、開発の詳細については下記の講演資料に詳しく記されています。
DeNAのゲーム開発を支えるGame Backend as a Service
直近の取り組みでは、さらなるパフォーマンス向上のために、メモリキャッシュの活用が進められています。「Sakashoには10の独立したAPIコード群があり、マイクロサービス的な作りで役割分担がなされているため、それにあわせた形で進められています」（春山氏）。APIサーバはprefork型（Rubyのunicorn）で、1サーバで125プロセス（60MB～100MB/プロセス）をさばき、1時間に1回程度の再起動で回しているとのこと。主にゲームの設定値をキャッシュするため、そこまでメモリを消費することもないといいます。
また、時には初期に作られたコードでPKがない、DBのindexが不足しているといった、好ましからざる状態が見つかることもあるとのこと。日々増加を続けるプレイヤーの保存履歴で、DBが溢れかえることもあります。こうした問題に直面する度に、徐々に新しいテーブルにデータを移行させたり、ログが保存されたjsonファイルをAmazon S3に待避させたり、といったメンテナンスが行われています。「S3へのアップロードは、今では毎日バッチを組んで行っています」（春山氏）
【メモリ効率化とSDKのテスト自動化を推進】
メモリ効率化も重要な取り組みの一つです。これまでSakashoでは、Unicornの新しいプロセス（master＋worker）の新規立ち上げをすべて見届けた後に、古いプロセスを停止させていました。しかし、これでは一時的にプロセス数が全体の2倍になり、メモリ使用量も平常時の2倍に達する恐れがあるため、APIサーバのslow restartを実施。現在は新しいworkerプロセスを1つ起動したタイミングで、古いworkerプロセスを停止するように修正をかけているところだと言います。
また運用を通して、APIのコール回数がゲームごとに異なることがわかってきました。あるタイトルは100万DAUがさばけても、別のゲームは特定のAPIにアクセスが集中しがちなため、50万DAUが限界といった状況があるというのです。そのため「1分間にN万回のコールであればさばけるという視点で考えています」（春山氏）。APIの収容限界値は過去データから見積もれるため、テストプレイで得られたデータと目標DAUをもとに、各APIの負荷計算をしているとのことでした。
一方、現在直面している課題として、SDKのテスト自動化が上げられました。これにはSakashoチームの特徴も背景にあります。メンバーは8名程度で、それぞれの出入りが激しく、2週間ごとに新しい機能をリリースしているSakashoチーム。そのため不要なトラブルを避けるため、開発チームとのヒアリングから開発・実装まで、非常に細かく手順が決められています。
しかし、結果として機能数が増大し、前述の通り約50種類ものAPIが誕生。SDKも45バージョンに達し、それぞれを個別にサポートする必要が生じました。前述の通り、中途半端にマイクロサービス的になっていることも、開発効率の悪化を招いているといいます。そのため、まずはSDKのテストを自動化するための環境づくりが必用とされたのです。この解決策として春山氏は、GoogleのC++テスティングフレームワーク「googletest」を用いたパイプラインを構築したと語りました。
googletestではライブラリのインストールを行うことなく、ccファイルをテストコードと一緒にビルドするだけで、テストの実行ファイルが作成できます。Xcode（XCTest）と一緒に動作させられ、テスト形式を出力しやすいこと（JUnit形式）も魅力です。春山氏はGithubエンタプライズとJenkinsを組み合わせて、テスト結果が自動的にSlackなどに通知されるパイプラインを構築し、SDKのテスト自動化を行っているところだと解説し、デモも披露しました。
このように日々改善が行われながら、DeNAのゲーム開発を根底で支えるSakasho。もっとも春山氏は、抜本的な対応も必用だと補足しました。前述の通り、役割毎に10個の独立したAPIコード群が存在し、変にマイクロサービス的になっているところがそれです。他のAPIへの影響を考慮せずにデプロイできたり、リソースを細かく調整できるなどのメリットはあるものの、共通化されているgmeの管理をはじめ、管理工数が思いのほかかさみ、開発効率を悪化させているとのこと。全体の機能を一度統合した上で、改めて切り分け方を検討したいとあかしました。
【PhotonのIPV6対応について】
勉強会の第二部ではPhoton運営事務局からシニアテクニカルアドバイザーの並木健太郎氏が登壇しました。並木氏は「PhotonのIPv6対応情報 & Server構築ポイント」と題して講演。Photon Cloudを使用する場合は、基本的にClient SDKのアップデートで対応できること。Photon Serverの場合は、追加でいくつかの設定が必用になると解説しました。なお、本講演もスライド資料が下記にて公開されています。
http://www.slideshare.net/GMOCloudJP/photonipv6-server
多くの開発者に愛用されており、特にUnityベースのゲーム開発で使用されるケースが多いPhoton。大きくアプリにClient SDKを組み込むだけで利用できるPhoton Cloudと、サーバサイドのカスタマイズが自由にできるPhoton Serverに分かれています。前者はクラウドサーバの活用、後者はユーザーが自らサーバを構築することが必用です。
Photon運営事務局シニアテクニカルアドバイザー・並木健太郎氏
さて、2015年のWWDCで発表され、全世界のスマホアプリ開発者を激震させたiOSのIPv6対応。2016年6月1日から、App Storeに登録するすべてのアプリに対してIPv6対応を義務づけました。アップル曰く「HTTPの通信においては、IPv6をサポートするAPI「NSURLSession」「CFNetwork」を採用しているため、影響はない」としています。
しかし、ゲームではSocketを直接使用する例も少なからずあり、「CFNetwork」に移行する、「アドレスファミリAF_INET6にも対応する」などの対策が考えられるものの、いささか面倒だと並木氏は指摘します。これに対してサーバ側は「IPv6クライアント群はすべてNAT配下からアクセスがあると思えば基本はOK」とコメントされました。
もっとも、こうした問題もPhotonを使用すれば手軽に解決できます。当初はPhotonのプロトコルや接続に関する問題、そしてUnityの対応に関する問題があり、IPv6対応は茨の道でしたが、現在はすべて解消。Photon Cloudを使用している場合は、Client SDKのアップデートだけで対応できると胸をはりました。
これに対してユーザーがサーバを構築し、自由にカスタマイズできるPhoton Serverの場合は、若干の追加設定が必用です。もっともClient側、Server側のSDKアップデートに加えて、各サーバーへのFQDN設定、接続先のFQDN設定、ゲームサーバのFQDN設定を行えばOK。IPV6のBridge接続への対応についても、ゲームサーバのPhoton.LoadBalancing.dll.configを編集すればいいと解説されました。なお、詳細は上記講演資料をご参照ください。
このほかPhoton Serverの設定についてTIPSが紹介されました。
まずサーバの構成については、ロビー＆バランシングを行うマスターサーバと、ゲームの実処理を行うゲームサーバがあり、複数台の構成になることがほとんどです。この場合の設定はPhotonのヘルプセンターにある記事を参照して欲しいと言います。
次にサーバ台数では「ぶっちゃけ、ゲームの内容次第です」としつつも、ゲームサーバ側では4コアCPU/4GBメモリのサーバで1000-2000CCUが目安になるとコメント。一方マスターサーバ側では同様のスペックで40000CCUが目安になるとしました。もっとも、実際はロビーやルーム数の影響が大きく、大規模な利用が想定される場合は、あらかじめ複数のクラスタセットを利用することを想定したクライアント設計が求められるとします。
またパフォーマンスのチューニングについては、「基本はWindowsもPhotonもデフォルト設定で使うのがオススメ」（並木氏）で、とのこと。MMOのように大量のクライアントが同時接続される場合は別だが、一般的なMOであれば下手に弄らない方が高速に動作するとしました。
このほか「Photon Swarm」「Photon Thunder」「Photon TrueSync」という新サービスが開始されるとあかした並木氏。新たにナレッジベースやフォーラム機能を備えたヘルプセンターもスタートしたので、ぜひ活用して欲しいと呼びかけました。
このようにDeNA、Photonの両インフラアーキテクチャの技術解説が行われた本勉強会。終了後は軽食と飲み物も振る舞われ、参加者間で交流が続けられました。
