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

Copyright © DeNA Co.,Ltd. All Rights Reserved.
Feb 10, 2017
Makoto HARUYAMA
DeNA Co., Ltd.
のゲームを支えるプ
ラットフォーム
Sakasho

自己紹介
2
 2008年 DeNA入社 (みんなのウェディング)
 2010年エンジニアになる
 2011年 DeNA退社 -> 福岡へ
 2013年 DeNAに出戻り
 2016年ゲーム事業本部
Makoto HARUYAMA
GitHub https://github.com/SpringMT
Twitter https://twitter.com/Spring_MT
春山誠
@Spring_MT

モバイルゲーム用プラットフォーム
Sakasho

 Sakashoは社内のほぼ全てのゲームで
使われ続けている
 Sakashoを使っていると
クライアント開発に集中できる
 Sakashoを使っているゲームは
盛り上がっている！
4
Sakashoとは
今回お話しするSakashoとは？

目次
1. Sakashoの機能と構成
2. 堅実な開発を目指して
3. 安定した運用
4. Sakashoの取り組み
5. Sakashoの課題とこれから
6. まとめ
5

Sakashoの機能と構成

 アカウント管理
 ユーザーデータ管理
 課金処理
 マスタ配信
 アセット配信
 CS対応のための仕組みなど
7
モバイルゲームを作る上で必要な機能を提供
スムーズなゲーム開発が可能に

SDKの提供
組み込むだけでSakashoの機能が利用可能
 Unity、C++のゲームエンジンに対応
 iOS、Android共に対応可能
 課金などのOSに依存している機能も、Sakasho
と連携して簡単に使える
インターフェースを提供
8

各ゲームの専用サーバーとの連携機能
 ゲーム専用サーバーからSakashoにアクセスできるWeb APIを提供
 ゲーム専用サーバーを介してのユーザー情報の取得などに対応
 デバッグ、QA、テストにも利用
9

汎用的なWebページもかんたんに
作るのが地味に面倒な
お知らせなどの汎用的な
ページ配信システムも提供
10
タイトル問わず
同一文言を利用したい
ポリシーや規約などの
一元管理も可能

Sakashoの構成を考える上で
最も避けたいのはサービスダウン
 障害の影響は最小限に押さえ込みたい
運用が始まったAPIは極力変更しない
 サービスへの影響のある変更は極力抑える
 後方互換製を担保する
一貫性を重視し、不整合が起こりにくい作り
 1つのトランザクションで複数のデータの更新を一気に
 アイテムを受取済みにすると同時にプレイヤーデータを更新

13
マイクロサービスがよいのでは？

マイクロサービスとは
参考: http://microservices.io/patterns/microservices.html
機能をサービスという
⼩さなコンポーネント単位に
分割するアーキテクチャ

一般的なマイクロサービスの利点
各サービスは比較的小さくなる
○ コンテナの起動が早くなり、開発のイテレーションが高速に
各サービスのデプロイは独⽴して⾏える
○ 各サービスを独⽴して開発可能
○ 複数のチームが独立して動く事ができる
○ 各サービスが独立しているので開発の規模拡大が容易
障害耐性を向上させる
○ 各サービスが完全に独立しているので、影響が他に及ばない
http://www.slideshare.net/zigorou/microservices-57643957

マイクロサービスの構成で必要なこと
独立性の確保
○ 開発、デプロイの独立
○ 各サービスは夫々独立したデータベースを持っている
各サービスのインターフェース
○ HTTP/RESTのような同期的なプロトコル
○ AMQPのような非同期的なプロトコル
http://www.slideshare.net/zigorou/microservices-57643957

Sakashoに合いそう

役割毎に10の独立したAPIコード群
Sakashoの構成
 他のAPIへの影響を考えずにデプロイできる
 ひとつのAPIが止まっても
他のAPIに影響がでない状態を保てる
 API毎のコード量は少ない
 サーバーリソースを細かく調整できる
 省メモリ

実際に開発・運用してみて
スタート当初はAPI数も少なく管理自体も楽だった
運用を続けていくにつれてAPIが増加
メンテナンスが大変に…

APIをまたいだ共通モジュール群が存在
同一トランザクションで処理するため
API毎の担当者制ではない
結局少ないメンバーで運用しているので、
全員が全てのAPIを触っている
API毎のコードは独立しているが、DBは共通
独立性が担保できていない
発生してしまったデメリット

21
マイクロサービスから
モノリシックへ

コードを統合
 省メモリ
 サーバーリソースを細かく調整できる
 API同士の影響を最小限に
10あったAPIのうち、2つを統合済
これまでのよいところは引き継ぐ
サーバーの増強などは特になし(今の構成のまま)

堅実な開発を目指して

 要件定義からエンジニアが参加して仕様を作る
 仕様通りに作る
 仕様通りに動き続けることを担保する
堅実な開発を目剤して
Sakashoの開発で重要なポイント

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

仕様はゲームチームと一緒になって作る
プレイヤーに届けたい価値を共有する
ビジョンの共有 / とにかく聞きまくる
有識者の知見を集約させ、
仕様を練り上げる
必要であればCS、QA、関連チームの意見もSakashoが集約する

ユースケースをベースにした
インターフェース作成
 呼び出し方
 レスポンスに何を含めるか
 エラーのハンドリング

28
仕様通りに作る

設計実装テスト

仕様書はGithubで管理
常にみんなが確認できる状態に
設計
用語の定義 / 機能要件の整理 / APIのインターフェース / テーブル定義など

コードだけでなく仕様や設計の時点でPRして運用
しっかりと検討してから実装に着手することで
実装開始後の手戻りを減らすことができる
設計
仕様や設計書の段階からチーム内でレビュー

SDKの実装と
ドキュメント生成を自動化
フォーマットはJSON形式で定義→
実装 (SDK)

ロジックのレビューに集中できる環境を準備
 rubocopの自動化ツール
 PRのフォーマット bookmarklet
実装 (Web API)
https://github.com/SpringMT/bitting

 単体テスト
 結合テスト
 テストアプリを使った動作テスト
 QAチームでのテスト
テスト

単体テスト
 仕様を保証するものではなく、
あくまでDeveloper Testing
結合テスト
 仕様を保証するテスト
 後述
単体テスト・結合テスト

テストアプリは、組み込んだSDKから
自動的に機能を反映するので
メンテフリー
skackへの通知や必要な情報の
ダンプなどの機能あり
テストアプリはQAチームも利用
テストアプリを使ったテスト

 仕様が確定したら必ずSakashoチームが仕様をシェア
 テスト観点・テスト項目の作成を行ってもらいSakasho
チームとシェア
 実際にテストアプリを使って検証
QAチームでのテスト

39
仕様通りに動き続けること

結合テストの整備
 因子・水準を作成してそれを満たすテストを書く
 因子・水準QAチームも共有しレビューしてもらう
後方互換性の担保
APIのバージョニング戦略
 基本的にリリースしたバージョンには手を加えない
 加えるような変更をする場合は、新しいバージョンにする
 新しいSDKからそのバージョンを使うようにする
 古いバージョンのAPIが残り続けている現状 -> 2017年の課題

 因子・水準を作成しそれを満たす
テストを書く
 因子・水準はQAチームと共有し
レビューしてもらう
結合テストの整備

42
 googletestを使ったSDKのテスト
 google製のC++テスティングFW
 https://github.com/google/googletest
 ライブラリのインストールはいらず、ccファイルをテストコ
ードと一緒にビルドすればテストの実行ファイルができる
 Xcode(XCTest)と一緒に動かせる
 テスト結果を出力しやすいこと(JUnit形式)
結合テストと自動化
42

テスト結果を
通知

負荷テストなど人力では難しい検証も実施
 同時実行のテストによるデッドロックの検証
 レプリ遅延を狙った検証

安定した運用

安定した運用のための取り組み
1. スパイクを避ける
2. キャパシティ管理
3. 継続的なパフォーマンス改善
47
安定した運用

48
スパイクを避ける

49
安定した運用
APIサーバーのslow restart
 Unicornの新しいプロセス(master + worker)が全て立
ち上がってから古いプロセスを停止
 一時的にプロセス数が全体の２倍になり、メモリ
使用量が一瞬増える
 これを防ぐために、新しいworkerプロセスを１つ起
動できたタイミングで古いworkerプロセスを停止す
るように修正

APIサーバーのslow restart
50
安定した運用

51
キャパシティ管理

安定した運用
リソースの使用状況をシミュレ
ーションするコマンドを作成。
このコマンドの結果をdailyで
レポートメール送るように
しており、サーバーの台数調整
の指標としている
リソースの過不足判断を出来るレポート

53
Worker枯渇監視
安定した運用
rack-server_statusを使ったworkerの枯渇監視
Unicorn::ConfiguratorFromEnvで
UNICORN_WORKER_PROCESS_NUM を変更してworkerを増やす
https://github.com/SpringMT/rack-server_status
https://github.com/SpringMT/unicorn-configurator_from_env

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

55
パフォーマンス向上のために
安定した運用
 クエリ改善
 キャッシュ導入
 ロジック改善
やっていることはシンプル

56
安定した運用
56
 Web API <-> DBネットワークの帯域の使用が増えた
 DBに大量にデータを取りにいくようなクエリが発行
されていた
 Web APIのプロセスキャッシュ導入
 大量にデータを取りにいかないように仕様を変え
ずにWeb APIを修正
メモリキャッシュとアプリの修正

57
安定した運用
メモリキャッシュとアプリの修正
57
プロセスキャッシュ導入 Web APIのコード修正

 Sakashoはゲームのメンテナス状態や、マスター、アセッ
トのバージョンなど、リクエスト毎に必ず項目がある
 データが格納されたそれぞれのテーブルにSELECT分を投げる
 リクエスト毎に各テーブルにクエリを投げると負荷がかか
りすぎるので、必要なデータをまとめておくテーブルを作
成してそれを一回参照する
58
安定した運用
キャッシュテーブルの導入
58

59
安定した運用
59
game_id version
1 1.0
2 2.0
masters
game_id version
1 1.0
2 2.0
assets
game_id opend_at
1 2017-02-10
2 2017-02-11
maintenances
・・
Web API

60
安定した運用
60
game_id asset master maintenace
1 1.0 1.0 true
2 2.0 2.0 false
game_status
Web API
・・

61
安定した運用
61

Sakashoの取り組み

「社内専用」という利点を活かした開発
 リリース後のCS対応のサポート
 プレイヤーの調査や障害対応
 ポリシーなどの確認
 プロモーション時の負荷対策
63
Sakashoの取り組み
機能提供以外にも
横断的にゲームチームをサポートして情報収集

Sakashoの課題とこれから

65
特定の構成に最適化させたつくりになっていた
 異なる構成のゲームに対応させようとなると、
要件が複雑になり機能開発の難易度が上がる
 あえてクライアントに実装されたロジックでゲームの大
部分が進行するような構成のゲームに最適化させること
でスピードと安定性を優先

66
Sakashoのポリシー (抜粋)
原則的にゲームロジックを持たず、抽象化された機能提供のみを行うため、主に
一定のインタラクションを要求するために、クライアントに実装されたロジック
でゲームの大部分が進行するような構成のゲームに向いています。逆に、
MMORPGのような、サーバ上にゲームロジックやステータスを多く持ち、クラ
イアントでは主に表示と入力を行うような構成を要求するゲームには向いてい
ません。
クライアント側にタイトル特有のロジックが寄ることは、サーバアクセスの少な
さによるユーザ体感の向上とともに、ロジックが一ヶ所に集まることによる開発
効率の向上が図れる、という思想に基づいて各APIは設計されています。
Sakasho Users Guideより抜粋

これまでの制約を超えて
スピード感や安定した開発を優先して、特定の構成に寄せ
た作りになっていたが、安定した運用が定着した今、新た
なステージとして「これまで対応できていなかった構成の
ゲームへの対応」を進めていく

68
ゲームのロジックをサーバーへ
 ゲームのロジックを取り込める体制へ
 ゲームチームがより「おもしろいゲーム」づくりに
集中できる体制へ
ゲームチームとと一緒になって
より複雑な機能を作り始めている

まとめ

70
まとめ
 Sakashoは社内専用ゲームプラットフォームとして安定
して稼働をつづけている
 この安定稼働は、社内専用という利点と
構成に制約を設けることによって実現されている
 今後はこの制約を取り払い、
より幅広いゲーム構成に対応できるよう挑戦を続ける

ご清聴ありがとうございました

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

More Related Content

What's hot

Viewers also liked

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

More from DeNA

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