マイクロサービスっぽい感じの話

Copyright © DeNA Co.,Ltd. All Rights Reserved.
November 22, 2016
Makoto HARUYAMA
DeNA Co., Ltd.
マイクロサービスっぽい感じの話

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

3
DeNAのゲーム開発について

DeNA for GAME CREATORS
4参照元 : http://recruit-games.dena.jp/technology/

今日お話すること
1. Sakashoとは(軽く)
2. マイクロサービスぽい？
3. 最近の取り組み
4. まとめ
8

9
Sakashoとは

ネイティブゲーム用プラットフォーム
Sakasho

Sakashoとは
ネイティブアプリゲーム開発に
必要とされるサーバー機能を
提供するゲームプラットフォーム
ゲーム開発におけるサーバーサイドで
やるべき事をSakashoが一括で受け持
つことで、各開発チームはクライアント側
の開発に専念できる
運用のしやすさも見据えたゲームの
作り方のルールもある程度強いる
11

ゲーム開発・運用に必要なAPIの提供
● ユーザー情報API
● マスターデータ配信API
● ログインボーナスAPI など
12
Sakashoが提供している機能
● 課金API
● アセット配信API
● CS対応のための機能

SDK
● 課金やPush通知など、OSに依存している機能について
簡単に使えるインターフェースの提供
● Unity、C++のゲームエンジンに対応
13

WebView用インターフェースの提供
● お知らせの配信
● 掲示板
● 利用規約など
14

ゲーム専用サーバーとの連携機能
● ゲーム専用サーバーからSakashoにアクセスできるWeb APIを提供
● ゲーム専用サーバーを介してのユーザー情報の取得などに対応
15

Sakashoの機能一覧(一部抜粋)
● マスターデータ配信
● アセット配信
● プレイヤー管理
● お知らせ管理
● アイテム管理
● ログインボーナス
● お問合せ機能
● 課金
● ログ管理
16
● ランキング
● 掲示板
● 補填機能
● メンテナンス
● Push通知
● プレイヤー検索機能
● ギルド
● アプリのバージョン管理
● CS運用ツール

主なリリースタイトル
17

18
マイクロサービスぽい？

Sakashoの構成について

Sakashoの構成について(Web View)

マイクロサービス？
役割毎に10の独立したAPIコード群がある
○ メリット
■ 他のAPIへの影響を考えずにデプロイできる
■ リソースを細かく調整できる
○ デメリット
■ 運用工数がかかる(gemの更新とか)
■ 結局サービス毎に人を専用にアサインとかしなかったので、全員
全部見る状態
コード量も少ない(API全部ファイル数が700程度、行数3万行)のでこの規模
だと管理工数のほうが大きい

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

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

Sakashoの構成を考える上で
■ Sakashoはプラットフォームなので、サービスが落ちることは避けたい。
● 障害の影響を最小限に押さえ込みたい
○ workerの枯渇等で一気にサービスダウンになるのを防ぐ
■ 仕様が固まったサービスには極力触らない
● 仕様が固まりリリースされたサービスには手をつけたくない
○ QAもしない(影響範囲に加えない)

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

実際は
● サービス毎にデータは隔離されていない
○ データベースが別れてもいないので、どれか1つのサービスでTMC
がでたら、他のサービスも影響を受ける
● サービス毎にロジックが独立になっていない
○ あるサービスのロジックを他のサービスでもつかえるようなgemが
あったりする(本来は各サービスのインターフェースを通して行うは
ず)
○ 共通のgemのアップデート問題
● チーム体制は一チーム(8人〜10人)で開発・運用が続いていて、そこまで
独立性が高くはない

実際は
● サービスが別れすぎていて、結局全部触るチームなのに、チームにjoinし
てからのキャッチアップが時間がかかる
● 共通化している部分がわからん

30
1番の問題は？

あるサービスのロジックを他のサービスでもつ
かえるようなgemがあったりする
● プレイヤーのデータを保存しながら同時にほげほげしたい
例)
● アチーブメント
○ プレイヤーデータの保存とアチーブメント報酬の受け取りを１トラン
ザクションで実行したい
○ ClaimAchievementPrizesAndSave()

結果生まれたのが
● sakasho-common_models

なぜ？
● 一貫性を重要視し、不整合が起きない仕組みにする
○ 同一トランザクションでなんとかできないか？
■ プレイヤーの仮想通貨の管理
■ プレイヤーのデータの保存
■ プレイヤーのアイテム管理
● チートはさせたくない
○ ロジックはサーバーによせる

現在、コードベース整理中
● 管理
○ サービスが別れてて逆に分かりにくくなっている
○ チーム規模は小さい
● サーバーリソースの状況
○ 省メモリのサービス
● サービスを跨いだコードベース・データの共有
○ 影響範囲が読めなくなりつつある
● データベース
○ ほぼ共通になっている

● 今まででも良かった部分もある
○ workerの枯渇等でとあるサービスが止まっても他のサービスに影響
はない状態(DBが詰まるとだめなのはそのまま)
○ APIのコードがそこまで膨れ上がっておらず、省メモリで運用できて
いる

● 一旦コードを1つにまとめる
○ 管理のしやすさ
■ 共通のモジュールはgemではなく、1つのサービスに取り込む
○ サーバーリソースには余裕がある
■ 1つにまとめても問題ない
○ 独立性
■ そもそも1チームしかないので、独立性を持たせることは今は重
要じゃない(将来的に必要になるかもしれないが)

スケジュール
● コードベースを整理する前に、仕様が変わっていないことを保証するため
に結合テストを準備
○ 2016年上期に集中的に対応
● 2016年下期
○ コードベースの統合に着手
○ deployの整理も合わせてしている

SDKのテストと自動化

39
結合テストの整備
● google製のC++テスティングFW
○ https://github.com/google/googletest
○ ライブラリのインストールはいらず、ccファイルをテストコードと一緒
にビルドすればテストの実行ファイルができる
● Xcode(XCTest)と一緒に動かせる
● テスト結果を出力しやすいこと(JUnit形式)
● Native Sakasho SDKが対象
googletestの採用
39

SDK
✔テスト結果を
通知
テストを実行
Slackプラグインで通知も
GitHub pull request builder plugin
で結果を表示
PP
Junit XML

41
SDKのテスト(iOS)
41

● 自動テストも整備が終わって
○ 粛々とAPIを一緒にしている
■ 全部ロードさせる
■ 最初は統合のみ、改善は後で

ゲーム開発を支えるプラットフォームSakasho
○ Sakashoがサーバー側の運用を一括で受け持つことで
各ゲームタイトルはゲーム開発に集中できる
マイクロサービスぽい構成からモノリシックな構成に直してる
○ 管理コストの削減が狙い
○ まだ途中なので、後日談も発表したいですね
まとめ

44
最近の取り組み
44
2017/2/10 FRI 13:00-20:30
SHIBUYA HIKARIE HALL A/B

45
最近の取り組み
SDKのテスト
45
● SWETチームとの共同作業
参照元 : https://career.dena.jp/job.phtml?job_code=476

マイクロサービスっぽい感じの話

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à マイクロサービスっぽい感じの話

Similaire à マイクロサービスっぽい感じの話 (20)

Plus de Makoto Haruyama

Plus de Makoto Haruyama (13)

マイクロサービスっぽい感じの話