TechCon2017 - D-Stage02:DeNAのゲームを支えるプラットフォーム Sakasho(春山誠)

2017年2月10日に開催された「TechCon2017」のなかで、ゲーム事業部 春山誠によるセッション「DeNAのゲームを支えるプラットフォーム Sakasho」が行われました。DeNAの社内専用プラットフォームであるSakashoが、どのように構成され、DeNAのゲームアプリ開発を支えているかについてを中心にお話しました。

トピックス一覧

1. 自己紹介
2. Sakashoとは
3. Sakashoの機能と構成
4. 堅実な開発を目指して
5. Sakashoの取り組み
6. Sakashoの課題とこれから
7. まとめ

自己紹介

DeNAのゲームを支えるプラットフォーム Sakasho

お疲れ様です。
「DeNAのゲームを支えるプラットフォームSakasho」というタイトルでお話しさせていただきます。よろしくお願いします。
先ほど池田さんからもあったとおり、Sakashoっていろいろゲームで使われていますということで、紹介できればと思います。

まず、軽く自己紹介からさせてください。
春山誠といいます。

DeNAのゲームを支えるプラットフォーム Sakasho

2008年DeNAに入社しているんですけれども、最初は「みんなのウエディング」というサービスに関わっていました。
で、この頃は営業でキャリアをスタートしていて、2010年にちょうどエンジニアに転向しました。
2011年にエンジニアに転向してすぐにDeNAを辞めてしまって、実は福岡のベンチャーにちょっと行って、2年ぐらいするとまたDeNAに戻ってきました。
で、今ゲーム事業本部で現在Sakashoのテックリードをしています。主にSpring_MTって名前で活動しています。

Sakashoとは

DeNAのゲームを支えるプラットフォーム Sakasho

では改めまして、Sakashoのお話ができればと思います。まずSakashoはモバイル用のプラットフォームです。
去年のテクコンでも少しお話ししたんですけれども、とはいえSakashoを知っているという人は少ないと思います。
「Sakashoって聞いたことある」という方ってどれくらいいらっしゃいますか?
(会場の挙手を見て)あ、ちょいちょいいる。ありがとうございます。

DeNAのゲームを支えるプラットフォーム Sakasho

で、社内のほぼすべてのゲームで使われているんですけど、何でこんなにSakashoが知られていないかというと、社内専用のプラットフォームだからなんです。
Sakashoで、クライアント開発に集中できる環境を提供できているということが言えます。
ちょっと盛った感はあるんですけれども、Sakashoを使っているゲームは結構盛り上がっています。
そういうのも含めて今日紹介できればと思っています。

この発表ではSakashoの開発をするためにやっていることをできる限りお話しできればと思ってますし、もし自分の会社とかでこういうプラットフォームを作りたいというときの参考になれればな、と思っています。

DeNAのゲームを支えるプラットフォーム Sakasho

本日はこんな感じのお話をできればと思っています。 まず初めにSakashoの機能と構成、その後にSakashoの開発・運用で取り組んでいることを紹介していきます。 最後に、Sakashoはまだやっぱり抱えてる問題というのがあるので、その問題とこれからの取り組みについてのお話ができればと思います。

Sakashoの機能と構成

DeNAのゲームを支えるプラットフォーム Sakasho

ではまず、Sakashoの機能と構成について紹介していきます。
Sakashoには、モバイルゲームを作る上で必要なアカウント管理だったりとかユーザーデータの管理、課金処理、マスタ配信、アセット配信などの機能があります。
この辺り、ちょっとDeNA用語っぽいんですけれども。
あとCS対応のための仕組みなどをモバイルゲームをサービスとして提供するためのものを、ほぼすべて提供しています。
で、ゲーム開発者が利用するための機能も含め、もちろんゲームの開発だったりとか運用まで幅広くSakashoがサポートしています。

DeNAのゲームを支えるプラットフォーム Sakasho

モバイルゲームの開発において、サーバーサイドでやるべきことをすべて引き受けていて、各開発チームはクライアント側の開発に専念してもらってるという状況になります。
あと、今までのWeb開発のノウハウをベースに作っていますけれども、今までDeNAが使ってなかった新しい技術——今まで結構Perlが多かったんですけれどもSakashoは全部Rubyで動いたりとか、そういうところもいろいろ挑戦してやっています。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoなんですけれども、SDKを提供してこれを組み込むだけでSakashoの機能が利用可能となっています。UnityとC++のゲームエンジンに対応しています。
C++に関しては、主にLiftEngineが対象で、SakashoにSDKを組み込むことによって使うことができるようになってます。iOS、Android共に対応可能です。
さらに課金などのOSに依存している機能も、Sakashoと連携し簡単に使えるインターフェースを提供しています。
よくゲームであるような、課金をして仮想通貨を得るみたいなところを単純に仮想通貨を増やすという機能ではなくその辺りすべてをラップしていて、さらに途中で課金が止まってしまった場合の処理等々もすぐにリカバリできるような機能も提供し、簡単に使えるようになっているので、ゲーム開発をしている人たちにとってはかなり便利だと言われています。

DeNAのゲームを支えるプラットフォーム Sakasho

SDKだけではなく、独自のゲームサーバーとSakashoを連携できるような機能も提供しています。
もちろんこれは「ゲーム専用」と書いてあるとおり、ゲームの開発にも使ってもらっていますけれども、デバックだったりとか、あとはSakashoのQAとかテストにも工夫してちょっと使っている部分があります。
こういう機能を提供することによって、より幅広いゲームをフォローできるようにしています。

DeNAのゲームを支えるプラットフォーム Sakasho

汎用的なWebページも簡単に作れるようになっています。
ネイティブで実装する時に作るのが面倒な「画面作るほどでもないよね」というところに関しては、Sakasho側で汎用的なWebページを提供し、それを見せるようにしてくださいという風になっています。
特にゲームの間で共通にしなければいけないポリシーのページなどは、Sakasho側で全て文言を管理し、ゲーム側には触らせないようにする、一括管理してポリシーがずれないようにするという工夫もしています。
それとは別にまた自分たちでHMTLの配信ができるようになっているだとか、そういう機能をSakashoは汎用的に提供しています。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoのサーバー構成についてちょっと簡単にまとめてみました。
Sakashoが提供しているSDKが最初前段のProxyサーバーというところにアクセスしにいって、ここでユーザーの認証が行われます。
で、リクエストを受け付けたProxyサーバーが、その後各機能単位に分けられたAPIにアクセスしにいって、必要な情報をSDKに返すという仕組みになっています。APIサーバーは機能単位で、結構独立したマイクロサービス的な作りにもなっています。
で、ゲームチームはこっちの、SDKからProxy、APIとはまた別のところの管理ツールを使ってマスターデータを取るとかゲームデータを入力することができます。

ここには載せてなかったんですけど、サーバーの具体的な数字を少しお出しできればと思っています。ここのProxyサーバーがだいたい今9台ぐらいで動いていて、オンプレスミスの32コアCPU、24GBメモリが載っているサーバーが前段に9台います、と。
あと裏側に大体36台ぐらいのAPIサーバーがあります。で、DBがだいたい31台ぐらいで全部のゲームをさばいてるという形になっています。

DeNAのゲームを支えるプラットフォーム Sakasho

こういったSakashoの構成を考える上で、3点こういうコンセプトで考えました。
最も避けたいと思っていたのはサービスダウンで、さらに障害の影響を最小限に押さえ込みたいというのがあります。
あと、運用が始まったAPIは極力変更したくないという、ちょっと時代に逆行した流れかもしれないですけど、サービスへ影響のある変更は極力避けたいです。
あと、後方互換性を担保したいです。一貫性を重視して、不整合が起こりにくい作りをSakashoとしては提供してあげたいなと思っていました。
1つのトランザクションで複数のデータの更新を一気にしたりとかいうことをして、アイテムを受取済みにすると同時にプレイデータを更新するとか、そういうことをよくゲームではやると思うんですけど、そういうことをなるべく不整合を起こりにくい作りでなるように提供できればなと思って考えました。

DeNAのゲームを支えるプラットフォーム Sakasho

そういうことも含めて先ほどもちょっと言ったとおり、マイクロサービスがよいのではないかということでこの構成にしています。
少しマイクロサービスの話をすると、機能をサービスという小さなコンポーネント単位に分割するアーキテクチャのことです。

DeNAのゲームを支えるプラットフォーム Sakasho

一般的に、マイクロサービスの利点としては、各サービスは比較的小さくなってコンテナの起動が早くなって開発のイテレーションが高速になるだとか、各サービスのデプロイは独立して行えて、各複数チームが独立して動くことができるとか。あとは耐障害性を向上させることができる、各サービスが独立していることによって影響が他に及ばないってことがあるので、そういう耐障害性が上がるという形が利点としてあるかなと思います。
これらの利点を享受するためにはもちろん必要なことがあって、独立性の確保とかかなり重要な点になります。

DeNAのゲームを支えるプラットフォーム Sakasho

こういうところも含めていくとSakashoに合いそうかなと思って、マイクロサービス的な作りにしようという流れになりました。

DeNAのゲームを支えるプラットフォーム Sakasho
DeNAのゲームを支えるプラットフォーム Sakasho

今のSakashoの構成なんですけれども、役割毎に大体10個の独立したAPIがずらっとあります。
Sakasho(酒匠)という名前だけあって、全部日本酒の名前がついています。
ちなみに前任者がお酒好きだったんですけど僕はちょっとお酒が飲めなくて、日本酒が何だか分からないというのがちょっと悩みです。

DeNAのゲームを支えるプラットフォーム Sakasho

で、10個の独立したAPIコード群があって、他のAPIへの影響を考えずにデプロイできるようになってます、と。
他、ひとつのAPIが止まっても他のAPIには影響が出ないようになっています。
分けていることによってAPI毎にコード量が少なくて、サーバーの省メモリになっていると。あとはサーバーリソースを細かく調整できるようになっています。

DeNAのゲームを支えるプラットフォーム Sakasho

ただ、実際に開発・運用してみて、スタート、開発当初、2014年とかなんですけれどもAPI数も少なくて管理自体も楽だったんですけれども、運用を続けていくにつれてAPIがとても増えていって、かなりメンテナンスが大変になってきています。
そういうメンテナンスが大変だというところが今増えてきていて、さらにデメリットが出てきています。

DeNAのゲームを支えるプラットフォーム Sakasho

APIをまたいだ共通のモジュール群が存在するんですけれども、同一トランザクションで処理をするために例えばプレイヤーデータを保存しながら他の何かをするというのを、プレイヤーデータを保存する部分だったりとかは共通のモジュールとして存在してしまったりとか、その共通のモジュールをアップデートしていくときの工数がかなりかかっているということがあります。
結構少ないメンバーで今Sakashoチームを回していて、API毎の担当制ではないです。
大体7人ほどの体制で全部のSakashoの業務を回しているんですけれども、全員が全部のAPIの開発に携わってるという形になっています。
そのために分けていることによってAPIの行き来が多くて非効率な部分がちょっと出てきているというのがあります。

最後に一番大きい問題で、本当はやってはいけなかったんだろうなと思ってるんですけれども、API毎にコードは独立しているんですがDBは共通という、ちょっとアンチパターンなことをやってしまいました。データベースが統合されているため、結合が失われています。
これにも理由があって、先ほど言ったように整合性を、不整合をなるべく少なくしたいということで、1つのデータベースでワントランザクションでやりたいということもあったので、そういう作りになってしまっているという感じです。

DeNAのゲームを支えるプラットフォーム Sakasho

こういうことも踏まえて、ちょっとマイクロサービスはやめようと。いったんモノリシックに戻しましょうというのが現在です。
ちょうど今コードの統合をしていて、10あったAPIのうち今2つを統合しています。今月中にだいたい8個まで統合できる予定です。統合したからといってこれまでの良いところをなくすのではなくて、省メモリだったりとかサーバーリソースを細かく調整できるとか、API同士の影響を最小限にするというところは引き継いでいけるかなということで、構成を考えています。

DeNAのゲームを支えるプラットフォーム Sakasho

サーバーの増強などは特にせず、今の構成のままでいっています。
多分、ゲーム開発を実際にこのSakashoを使ってやっている人に関しては、この部分に関しては特に何も感じずに今やっているはずです。
ゲーム側には迷惑をかけないように、そういうところはちゃんと守って、内部的にはちゃんとやっていきましょうという感じになっています。
で、こうやって開発効率を上げるための改善は引き続きやってければな、と思っています。

堅実な開発を目指して

DeNAのゲームを支えるプラットフォーム Sakasho

では次に。
Sakashoはいろいろな開発をしているんですけれども、ゲーム側の人たちに開発したものをしっかり渡せるように、堅実な開発を目指した取り組みをしています。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoの開発は、重要なポイントがいくつかあります。
要件定義からちゃんとSakashoのエンジニアが参加して仕様を作るということ。
仕様通りにちゃんと作ること。
仕様通りに動き続けることを担保するということを、重要なポイントとして挙げて取り組んでいます。
見てみると「普通かな」と思うんですけど、その辺りをきっちり守ってやってこうということがSakashoチームの中のコンセンサスになっています。

要件定義からエンジニアが参加して仕様を作る

DeNAのゲームを支えるプラットフォーム Sakasho

1個ずつ、どういう取り組みをしているか紹介できればと思います。要件定義からエンジニアが参加して仕様を作る、ということに関して説明していきます。
仕様は、基本的にゲームチームと一緒になって作るという風にしています。
Webエンジニアがそのままゲームサーバー側に移っているということも先ほどの池田さんの講演にあったとおり、自分たちがゲームに慣れてない部分もたくさんあるので、必ずゲームチームと一緒になっていろんなもの作っています。
エンジニアと話すのはもちろんそうなんですけれども、プレイヤーにどんな価値を届けたいか、というところを共有するというのも、必ずゲームチームにやってもらうようにしています。
ビジョンだったりとか、どういうことを実現したいのかというのを、とにかく詳しく聞きに行きます。

DeNAのゲームを支えるプラットフォーム Sakasho

こんな感じで。ゲームの人が何をやりたいんだというのをちゃんとまとめて欲しいと言って返ってきたメール文面なんですけれども。こういうことをちゃんとやっています。
あと、Sakashoはいろんな共通のプラットフォームということもあって、いろんな人といろんなつながりがあるので、そういう人たちから意見をもらって仕様を作り上げます。
必要であれば、CSだったりとかQAだったりとか、もちろん他のゲームチームにも意見をもらってSakashoチームが集約して仕様を練り上げます。

DeNAのゲームを支えるプラットフォーム Sakasho

もちろんエンジニアとも話して、インターフェースの作成をちゃんとします。
呼び出し方とかレスポンスに何を含めるかとか、エラーハンドリングどうするかというところです。
写真はちょうどゲームチームと話していろいろ激論を交わした後のホワイトボードなんですけれども、こういうことをまとめて必ずゲームチームと寄り添っていきながら仕様を作っていってます。
ここまでいくとだいたい仕様が練り上がってくるので、あと今度はSakashoチームが仕様通りにちゃんと作っていく、という段階になります。

仕様通りに作る

DeNAのゲームを支えるプラットフォーム Sakasho

仕様通りに作るといっても、設計と実装とテストという3ステップがあると思います。それぞれどういうことをやってるかを紹介できればと思います。

DeNAのゲームを支えるプラットフォーム Sakasho
DeNAのゲームを支えるプラットフォーム Sakasho

設計なんですけれども、仕様書はGithubで管理していて、常にみんなが確認できる状態になっています。
用語の定義、機能用件の整理、APIのインターフェース、テーブル定義などを全部仕様書をGithubに上げていて、こんな感じでGithubで見られるようになっています。これを、仕様や設計書の段階からチーム内で必ずレビューしています。コードだけでなく仕様の観点、設計の観点を必ず一応マークダウンで管理しているんですけれども、プルリクエストを送ってそれで運用しています。

DeNAのゲームを支えるプラットフォーム Sakasho

しっかりと検討すること、みんなでコミュニケーションを交わすことによって、実装に着手した時の理解度だったりとか、その後のレビューでかなり詳細にレビューできる、というメリットがあります。
ここ、少し数字が見にくいんですけれども、大きいとやはり30とか、それくらいのコメントが付いて激論が交わされています。

DeNAのゲームを支えるプラットフォーム Sakasho

マスクが多くて申し訳ないのですが、これは一部、そのコミュニケーションを取り出してきました。
質問しているのはシニアなエンジニアで、コメントしているのが新卒1年目とか2年目とかの人なんですけれども、そういう人たちと一緒にやりながらコミュニケーションを取って、「こうしたらいい」「ああしたらいい」というのを激論しているという感じですね。
この時にも、もちろんSakashoチームだけではなく、ゲームチームの人にも仕様を見てもらったりもありますし、セキュリティチームに見てもらって、この段階でかなり詳細に仕様を固めていくということをします。
ここまで来るとだいたい仕様が、まあ設計もできて、「じゃ、いざ実装を始めましょう」という風になります。

DeNAのゲームを支えるプラットフォーム Sakasho

SDKのほうなんですけれども、設計からこういうJSONフォーマットでインターフェースを定義します。
それをすると自動生成でこういうドキュメントだったりとか、コードの大体8割ぐらいを自動生成して、それで大体終わるという形にしています。
設計書がだいたいあるとSDKのインターフェースとしては、ほぼほぼブレなくいけるかなというところにまでなっています。

DeNAのゲームを支えるプラットフォーム Sakasho

ロジックに関しては大体Web APIのほうにロジックが寄っていますので、自動生成なかなかしにくいところなので、結構、開発者に依存しています。
どういう風に担保しているかというと、やはりレビューが中心になってくるので、そのレビューをしやすくするような仕組みをSakashoとしては維持しています。

よくあるのが「インデントずれてる」とか、「これ、Rubyっぽくないね」とか。
そういうのはなるべくもうレビューに入れたくなかったので、自動的にrubocopという解析ツール、自動的に全部直してくれるようなツールがあるんですけど、それを呼び出して。
何か行動修正があったら再度修正済のプルリクエストを送ってくれるようなツールを作って、それでフォーマットの部分とかをなるべくコメントで入らないようにしてます。

あとは、プルリクエストのフォーマットとかも。
DeNAのGithubエンタプライズのバージョンが古くて、新しい機能を使えていないんですけれども、bookmarkletをうまく使ってプルリクのコメントとかに必要な情報を全部入るようにしています。
こうやってレビューをしやすくするような工夫をしといて、なるべくレビュワーとレビュイーがちゃんと設計通りになってるかというのを確認しやすい環境を作っています。

DeNAのゲームを支えるプラットフォーム Sakasho

実装が終わった後に、テストをします。
Sakashoは、いろんなテストをします。
単体テスト、結合テスト、あとテストアプリを使った動作テストと、QAチームでのテストというのがあります。

DeNAのゲームを支えるプラットフォーム Sakasho

単体テストはあくまで仕様を保証するものではないという位置づけでやっています。あくまでDeveloper Testingとして扱っています。
結合テストは、これはどちらかというと仕様をちゃんと保証するテストとして作りましょう、という風になっています。これは後で説明しま1す。

DeNAのゲームを支えるプラットフォーム Sakasho

あとはテストアプリを使った動作テストがあります。
今、組み込んだSDKから自動的に機能を反映するテストアプリをSakashoチームでも作っています。
例えば新しいメソッドが追加されると、こういうボタンが自動的に追加されるようになっていて、基本的にメンテフリーの状態になっています。Slackの通知だったりとか、必要な情報をダンプする機能とかもあります。

DeNAのゲームを支えるプラットフォーム Sakasho

このテストアプリをSakashoチーム、ないしはQAチームが使ってテストします。
で、最後にQAチームのテストがあって、先ほどのテストアプリを使ったテストを行うんですけれども、仕様をちゃんと読み込んでいただいてテスト観点・テスト項目の作成をQAチームでしてもらって、Sakashoチームとシェアして、実際テストアプリを使って検証してもらいます。
こういう風にテストまで持っていって、Sakashoはリリースをしています。

仕様通りに動き続けることを担保する

DeNAのゲームを支えるプラットフォーム Sakasho

これで仕様通りに作ってリリースしました。
さらに、この仕様通りに作ったものがちゃんと仕様通りに動き続けていること、これもゲーム開発者としてはかなり重要な点かなと思っているので、ここもかなりSakashoとしては取り組んでやっています。

DeNAのゲームを支えるプラットフォーム Sakasho

大枠で2つあって、結合テストの整備と後方互換制の担保という観点でやっています。
今回の発表では主に結合テストの整備に関してお話ししてみようと思います。ちょっと後方互換制の話はこのスライドを公開しますので、あとで見てください。

DeNAのゲームを支えるプラットフォーム Sakasho

結合テストの整備。
因子と水準をちゃんと作成して、それを満たすテストを書きましょうということでやっています。
見辛くて申し訳ないですけれども、CSVで管理していて、Githubでこれも管理してプレリクベースで満たしているかどうかをQAチームと一緒になって管理しています。この因子水準のシートを作ったのをベースに、テストコードを書いています。

DeNAのゲームを支えるプラットフォーム Sakasho

結合テストなんですけれども、これ自動化もしていてこういうGoogleTestを使ったSDKテストというのをやっています。GoogleTestは、Google製のC++のテスティングフレームワークになります。ライブラリのインストールはいらなくて、ccファイルをテストコードと一緒にビルドすればテストの実行ができます。これXcodeと一緒に動かせたりとか、あとはテスト結果を出力しやすいということもあって採用し今やっています。
結合テストはJenkinsと連携してプレリクエストができたら自動的に結合テストが流れるようになっています。

DeNAのゲームを支えるプラットフォーム Sakasho
DeNAのゲームを支えるプラットフォーム Sakasho

ちょっと流れをまとめたので、ここで紹介します。
プルリクエストがGithubに送られたらJenkinsがそれを食って、Xcode起ち上げてテスト実行してJUnitのXMLファイルを入って、それをGithubだったりとかSlackにちゃんと通知するようになっています。

DeNAのゲームを支えるプラットフォーム Sakasho

もう1個こういう結合テストで良かったことがあって。
仕様のテストもこれを使ってやっているんですけれども、負荷テストなど人力ではちょっと難しい検証もこの結合テストを使ってやっています。
同時実行のテスト。これで同時実行によるデッドロックの検証をしているんですけれども、ここでちょっとエラーが出てるのを持ってきたんですけれども、意図的にデッドロックを起こせるかどうかを試して、こういう検知をしているのもこの自動テストでやっています、と。あとはレプリ遅延とかを狙った検証とかも、こういう負荷テストを先ほどの結合テストを使ってやっています。

こういう風にSakashoの開発は、良いものを作れるようにいろいろと工夫して今進めているところです。

安定した運用

DeNAのゲームを支えるプラットフォーム Sakasho

こうしてSakashoの機能を開発していろいろリリースしているんですけれども、安定して動くように、さらに運用にも力を入れているので、運用のお話しも少しご紹介できればと思っています。

DeNAのゲームを支えるプラットフォーム Sakasho

安定した運用のために、いろいろSakashoも取り組みをしています。
大枠で3つあって、スパイクを避ける運用をしましょう。
キャパシティ管理をしっかりしましょう。
あと、継続的なパフォーマンス改善をしていきましょう、ということがあります。
それぞれちょっと紹介できればと思います。

スパイクを避ける

DeNAのゲームを支えるプラットフォーム Sakasho

1つ、スパイクを避けるためにSakashoでやった取り組みについて紹介できればと思います。

DeNAのゲームを支えるプラットフォーム Sakasho

APIサーバーのslow restartということをやっています。
今Rubyで書いてるんですけれども、RubyのhttpサーバーであるUnicornというのを使っています。Unicornの新しいプロセスの立ち上げの方法をちょっと書いています。
新しいプロセスを、今までだとすべて立ち上げてから古いプロセスを停止するという方法を取っていたんですけれども、これだと一時的にプロセスの数がだいたい2倍になって、メモリの使用量が一瞬増えるという風になっていました。
これがネックで、なかなかサーバーのリソースを使い切れてなかったりということもあったので、ここを直しましょうということでヘッドを修正を入れています。
で、これを防ぐために新しいworkerプロセスを1つ起動できたタイミングで、1つ古いプロセスを停止してくというふうにコードを修正して対応しています。

DeNAのゲームを支えるプラットフォーム Sakasho

これによって結構良い効果があって、メモリのスパイクをほとんど減らすことができたという風になっています。

キャパシティ管理

DeNAのゲームを支えるプラットフォーム Sakasho

次にキャパシティ管理という点で少し紹介できればと思います。
今、これをインフラチームと一緒になってやっているんですけれども、リソースの過不足を判断できるレポートを作っています。

DeNAのゲームを支えるプラットフォーム Sakasho

リソースの使用状況をシミュレーションするコマンドを作成して、このコマンドの結果をdailyでレポートメールで送るようにしています。これをサーバー台数の指標としていて、ちょっといろんなAPI毎とかサーバー毎にどれだけCPU使ってるとか、どれだけメモリ使ってるかというところをかなり詳細に把握することができて、あらかじめサーバー増やすだったりとかWorker増やすということも、かなり事前に手を打てる状況になっています。

DeNAのゲームを支えるプラットフォーム Sakasho

次、Workerの枯渇監視。先ほども伝えたとおりUnicornというhttpサーバーを使っているんですけれども、masterとWorkerのプロセスが両方ともあります。Workerのプロセスが処理を担ってるんですけれども、このプロセス数が枯渇してないかどうかを監視するようにしています。
そのためにrack-server_statusというちょっとモジュールを書いたんですけれども、ここでWorkerの枯渇監視をしています。
このメールは、完全に枯渇している状態のアラートメールなんですけれども、こういうふうにどれだけ処理が占有されているかというところを監視して、アラートメールが飛ぶようになっています。
ここにも1つ工夫があって、アラートメールが来たらすぐに対応できるように、Worker数とかをプロセスの外部から渡すことによって、ほぼリアルタイムにWorkerの数を変えることができるというふうになっていて、それは次の起動のタイミングになってしまうんですけれども、それでコードの修正なくWorker数を増やすことができるようになっています。
それも自分たちで書いたモジュールを食わせてやっています。
こういうふうにWorkerの枯渇監視をしてリソースをちゃんとキャパシティ管理して、Workerを増やすだったりとかサーバーを増やすとか、そういうことを継続的にやっています。

継続的なパフォーマンス改善

DeNAのゲームを支えるプラットフォーム Sakasho

次にいきます。
やっぱり、こういういろんな取り組みをしながら継続的なパフォーマンス改善もいろいろやっています。

DeNAのゲームを支えるプラットフォーム Sakasho

パフォーマンス改善、パフォーマンス向上のためにやっていること。大枠はクエリ改善とキャッシュの導入と、ロジックの改善というのをやっています。大体とてもシンプルなことをやっています。

1つ、最近あった問題について取り上げられればと思っています。
メモリキャッシュとアプリの修正ということで、キャッシュの導入なんですけれども。あんまりRedisとかmemcachedをほぼ使っていなくて、メモリキャッシュ、プロセスのないキャッシュをほぼ積んでいます。
それで大体さばくようにしています。
これ、なんでこんなことしているかというと、そこまでWorker数の数が多くないということと、やっぱりメモリキャッシュの方が速いということと、あと他のコンポーネントを増やすことによって障害リスクが上がるので、なるべくメモリキャッシュでできることはメモリキャッシュでしましょうとやってきています。
今のところ、そのメモリキャッシュだけで事足りているというのがあるので、Sakashoのキャッシュとなると、ほぼプロセス内キャッシュのメモリキャッシュを使ってやっています。
それとプラスアルファで、やっぱアプリもちゃんと修正してやっていきましょうってことで、この取り組みをちょっと少し紹介できればと思います。

で、起きた事象がWeb APIとDBのネットワークの帯域の使用量がめちゃくちゃ増えたということがあります。
ここら辺は、Sakashoはプラットフォームなのでゲーム側の動きをなかなか事前に察知できないパターンもあって、DBに大量にデータを取りにいくようなクエリが発行されていた。

これはSakashoの問題もあったんですけれども、ゲーム側が意図せずデータを取りにいくような設定にしていて、それをSakasho側に負担となって出てきました。
それで、「これ直すの2か月かかります」って言われたので、Sakasho側で何とかしなければいけませんというパターン。大体いつものパターンなんですけれども。

DeNAのゲームを支えるプラットフォーム Sakasho

まず、次のスライド。ここで1ギガの通信ネットワークを食っていて、完全に死んでいる状況でした。「これ、まずい」ってなったので、まずはWeb APIのプロセスキャッシュを導入しました。

DeNAのゲームを支えるプラットフォーム Sakasho

これはプロセスキャッシュをすぐに入れられるような仕組みになっていて、あるDBへのクエリを飛ばすような、メソッド名をちょっと変えるだけで実はプロセスキャッシュをするような設定になっています。
それでまずキャッシュを導入しました。そうすると、大体これぐらいあったネットワークがぱかんと落ちる。まずプロセスキャッシュ導入して落ちました。
ただ、プロセスキャッシュもずっと永続的にキャッシュしているわけではなくて、一定期間たつと失効するようにしているので、こんな感じで150メガぐらいを行ったり来たりとずーっとしている状況になっていました。

これスパイクしているのは良くないので、そもそも大量にデータを取りにいかないように、ゲーム側からの見た目は変わらないようにしてSakashoのほうでうまく工夫をしました。
まずゲームのデータを全部取りにいってからSakasho側でフィルターをかけるという仕様にしていたので、そこのアプリの作りをちょっと変えて、まずSakashoで必要なデータのプライマリーキーだけをうまく抽出するようにして、その抽出した後に再度もう1回クエリを投げてデータを取ってくるというふうにしました。
そうするとこんな感じで、最初のだいたい100分の1とかそれくらいのネットワーク量に落ちて、このときは事なきを得たという形になります。
ここまでが大体1、2……5時間ぐらいかかってるんですけれども、これくらいでちょっとぱぱっと直して入れるということをやっていました。これが1つ。

DeNAのゲームを支えるプラットフォーム Sakasho

もう1個はキャッシュテーブルというのを最近入れました。Sakashoはこのゲームのメンテナンス状態だったりとかマスタとかアセットのバージョンだったりとか、リクエスト毎に必ずチェックする項目が結構あります。
基本的にはそれぞれデータが格納されたテーブルにSELECTを投げてデータを取ってきて返すんですけれども、リクエスト毎に各テーブルに来るように投げると負荷がとてもかかりすぎるので、必要なデータをまとめておくテーブルを作って、それを一回だけ参照するようにしました。

DeNAのゲームを支えるプラットフォーム Sakasho

キャッシュテーブルの導入ということで、今までだとこうmastersだったりとかassetsとかmaintenancesみたいなテーブルがあって、それに対していろんなデータが入ってます。
で、毎回それぞれアクセスしにいってリクエストをさばくということをやってたんですけれども、これをgame_statusという名前がちょっと微妙なんですけれども、一度そういうテーブルwを、一箇所にすべて格納するようにしました。

DeNAのゲームを支えるプラットフォーム Sakasho

このときに気をつけたのが、データのずれがないように、ワントランザクションで処理するということをやって、これを実現していますという感じです。
これでどうなったかというと、この山は普通にピークだったんですけど、ここの段差、だいたい2分の1から3分の1ぐらいに全体のクエリが減っているという感じになりました。

DeNAのゲームを支えるプラットフォーム Sakasho

これでだいぶクエリの数も減って、サーバーの台数も減らせたかなというふうになっています。こうやってSakasho、継続的に運用の改善をして安定性を高めてくということをやっています。

ちょっとここのスライドに載せきれなかったんですけれども、最近やっている取り組みがまた1つありまして、プレイヤーデータの圧縮の改善等々もやってます。
ちょうど今修正している最中なんですけれども、今までSnappyという圧縮の方式を使ってたんですけれども、ちょっとそれだとデータが大きすぎるという問題が出てきたので、プレイヤーデータの圧縮の方式を今Zstandardという新しい圧縮方式を使おうかな、というとこで検討していたりしています。
もちろんプレイヤーデータの削減に関してはゲームタイトルにも協力してもらってますけれども、Sakasho側でもそういうことをしてデータを小さくしようという試みを最近しています。

Sakashoの取り組み

DeNAのゲームを支えるプラットフォーム Sakasho

今までがSakashoの機能的な話を紹介だと思うんですけれども、それ以外の部分を紹介できればと思います。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoは、社内専用という利点を活かしていろいろ開発しています。
機能提供以外にも横断的にゲームチームにサポート、入り込んでサポートしていろいろやっています。
企画とかマーケ、あとCSのチームとかと連携し、横断的にゲームをサポートしています。

リリース後のCS対応のサポート。プレイヤーの調査だったりとか、障害対応。
あとはポリシーの確認。
資金決済法等の確認等々はSakasho側で一律で責任を持ってやっていたりとか、あとプロモーションのときの負荷対策だったりとかそういう情報をいち早くもらって、Sakasho側でトラブルがないように備えるということもやっています。
こういうところもSakashoチームのやるべきことということで、取り組んで安定を目指してやっています。

Sakashoの課題とこれから

DeNAのゲームを支えるプラットフォーム Sakasho

今までSakashoのお話をして、Sakashoってこう作っていてみんなに使われているんですけれども、やっぱりまだ課題があるかなと思っています。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoでゲーム開発がちゃんとスムーズにできてるとか、あとはゲームが盛り上がってることもあるんですけれども、何でそんなことが実現できたかなというと、特定の構成に最適化させたつくりになっているというのが大きいかと思います。
異なる構成のゲームに対応させようとなると、要件が複雑になって機能開発の難易度が上がるということもあると思いますし、Sakashoのコンセプトとしてあえてクライアントに実装されたロジックでゲームの大半が進むような構成のゲームに最適化させるということを選択したことによって、開発のスピードだったりとか安定性を優先させています。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoのポリシーを抜粋してきました。
これはSakashoの管理ツールから見えるところに置いてあるんですけれども、これは先ほどの池田さんが作った文章になります

ちゃんとここに明示していて、「MMORPGのような、ゲーム上にゲームロジックやステータスを多く持ち、クライアントでは主に表示と入力を行うような構成を要求するゲームには向いていません」と完全にSakashoはこういうゲームには対応していません、と今までは言ってきました。
こういう思想のもとSakashoを作って、Sakashoを使うゲームはそういうゲームになってくるというのがあるんですけど、そういう一定の思想を持って作ることによって、ちゃんと安定したゲームができてはいます。

DeNAのゲームを支えるプラットフォーム Sakasho

ただ、これこのまま制約を設けたままいくのかというと、それはないと思っていて、これまでの制約を超えてゲーム開発をしていかなければいけないかな、と思います。
Sakashoはかなり安定してきているので、新しいステージにもう1個進んでいこうという取り組みを今しています。
これまで対応できていなかった構成のゲームへの対応を進めていっているところです。

DeNAのゲームを支えるプラットフォーム Sakasho

今新たに取り組んでいることとして、ゲームのロジックをサーバーへ移そうと、一部サーバーで持ちましょうということを取り組んでいます。
ゲームロジックを取り込める体制だったりとか、機能の作成を今しています。
これはゲーム毎にロジックは積むんですけれども、基本的にはインターフェースとかは共通で使えるようにするとか、そういうところも含めて考えられるように、一部機能をベータ版として出しています。

これから出るタイトルでこの機能を使ってもらうことも今やってもらったりとかしてますので、ちょっと今後期待していただければと思っています。
そして、よりゲームチームがよりおもしろいゲームづくりに集中できる体制になれればな、と思っています。ゲームチームと一緒になって、こういうより複雑な機能を作り始めている段階になっています。
今、Sakashoも岐路に立っているので、Sakashoのサーバーサイドも、それを使ってくれている人たちに関しても、かなりおもしろい状況になってるかなと思います。

まとめ

DeNAのゲームを支えるプラットフォーム Sakasho

では、まとめに入ります。

DeNAのゲームを支えるプラットフォーム Sakasho

Sakashoは社内専用ゲームプラットフォームとして今安定して稼働をつづけています。この安定稼働は、社内専用という利点と構成に制約を設けることによって実現されているものです。
今後はこの制約を取り払って、より幅広いゲーム構成に対応できるように、これからもSakashoチームは挑戦を続けてければなと思います。Sakashoでは、こういう挑戦を一緒にしてくれるような人を募集しております。
ご清聴ありがとうございました。

DeNAのゲームを支えるプラットフォーム Sakasho


TechCon トップへ戻る

RECRUIT - 募集職種一覧

「DeNAのイメージを破壊」してくれる、ゲームクリエイターを常に募集しています。

EVENT - イベント

Game Developer's Meeting
PAGE TOP

DeNA for GAME CREATORS