Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à DeNAのネイティブアプリにおけるサーバ開発の現在と未来
Similaire à DeNAのネイティブアプリにおけるサーバ開発の現在と未来 (20)
Plus de DeNA
Plus de DeNA (20)
Dernier
Dernier (10)
DeNAのネイティブアプリにおけるサーバ開発の現在と未来
- 2. 自己紹介 北澤 慶郎 (Kitazawa Yoshiro) ● 2008年 DeNA新卒入社 ● ブラウザゲームタイトルの新規開発・運用 ● ネイティブアプリタイトルの新規開発 ● タイトル横断で利用するBaaSの開発などに携わる
- 5. 今日お話ししたいこと • これまで編 • DeNAのゲーム年表 • Sakasho • これから編
- 6. DeNAのゲーム年表
- 7. DeNAのゲーム年表
- 8. DeNAのゲーム年表
- 9. DeNAのゲーム年表
- 10. DeNAのゲーム年表
- 11. DeNAのゲーム年表
- 12. DeNAのゲーム年表
- 13. DeNAのゲーム年表
- 14. DeNAのゲーム年表
- 15. DeNAのネイティブアプリ開発の現在 2018年現在 • 内製開発 6タイトルリリース • 多数のタイトルを新規開発中 • 協業開発でも多数のタイトルを開発・運用中
- 18. Sakasho 特徴 • Sakashoサーバ + クライアントアプリ で完結 • 多数のタイトルのサーバを一手に引き受ける • 同一のアプリケーション • 1つのチーム(10人前後) • タイトルチームはクライアントエンジニアだけ • 一般的なソーシャルゲームの機能をほぼ実装
- 19. Sakasho 機能一覧 • アカウント認証 • クライアント主導のセーブデータ管理 • アセット配信 • 課金 • 仮想通貨管理 • Push通知 • メンテナンス • 強制バージョンアップ • ログインボーナス • ガチャ • SNS連携データ引継ぎ • フレンド • アイテム補填機能 • ランキング • 他プレイヤー検索機能 • 返信付きお問合せ機能 • 分析ログ送信 • , etc.
- 21. Sakasho なぜそうしたか?
- 22. Sakasho • 選択と集中 • アーキテクチャの統一 • 運用ポリシーの統一 • サーバ技術の集約
- 23. Sakasho • 選択と集中 • アーキテクチャの統一 • 運用ポリシーの統一 • サーバ技術の集約
- 24. Sakasho 選択と集中 • webブラウザゲームでは、単純な表現力という意味では一定の制限がある • その中で、様々なゲームシステムやサーバ技術が生まれた • ネイティブアプリにおいては、その表現力を存分に発揮しないといけない • 強みのある領域に選択と集中ではなく、強みを作るために集中する
- 25. Sakasho • 選択と集中 • アーキテクチャの統一 • 運用ポリシーの統一 • サーバ技術の集約
- 26. Sakasho アーキテクチャの統一 • サーバで何をやるかクライアントで何をやるかという設計 • 一度間違うとかなり痛い目を見るポイント • 最適かはわからないが間違いではないライン、で全体を統一 • かなりクライアントに主導権を寄せている
- 27. Sakasho • 選択と集中 • アーキテクチャの統一 • 運用ポリシーの統一 • サーバ技術の集約
- 29. Sakasho • 選択と集中 • アーキテクチャの統一 • 運用ポリシーの統一 • サーバ技術の集約
- 31. Sakasho 結果 • サーバ開発・運用は1チームで、同時並行で多数のタイトルを展開できた • アーキテクチャはある程度統一され、同じノウハウを適用できた • 各タイトルチームはクライアント側の開発に注力できた • サービスの運用はある程度均質化された • サーバ負荷に関連するトラブルはかなり少なかった
- 32. DeNAのネイティブアプリ開発の現在 2018年現在 • 内製開発 6タイトルリリース • 多数のタイトルを新規開発中 • 協業開発でも多数のタイトルを開発・運用中
- 33. DeNAのネイティブアプリ開発の現在 2018年現在 • 内製開発 6タイトルリリース • 多数のタイトルを新規開発中 • 協業開発でも多数のタイトルを開発・運用中 戦略が結果につながった
- 37. DeNAのネイティブアプリ開発の未来 良い点 (一定の枠組みからはみ出さなければ) • サーバ開発を全くしなくても新規タイトルを開発・リリースが出来る • タイトル数のだけサーバ運用しなくてよい • タイトルチームはサーバで用意された機能をそのまま使うだけで良い
- 38. DeNAのネイティブアプリ開発の未来 課題点 • タイトルチーム • 制約が強く、自由度が小さい • 独自のカスタマイズや最適化が困難 • 意思決定がチーム内で完結しない • 共通基盤チーム • どんな変更も、直接的に全体に影響を与えうる • 常に先手を取って全体最適となるような意思決定が必要 • ボトルネックになりがち
- 40. DeNAのネイティブアプリ開発の未来 • 良い点: 可能な限り残したい • 独自のカスタマイズをしないなら開発が不要 • サーバ運用出来るだけ省力化したい • 課題点: 全て解決したい • 独自のカスタマイズや最適化を可能にしたい » ブラックボックスではなくホワイトボックス • 意思決定をチーム内で完結させたい » 中央集権ではなく地方分権
- 41. DeNAのネイティブアプリ開発の未来 • 良い点: 可能な限り残したい • 独自のカスタマイズをしないなら開発が不要 • サーバ運用出来るだけ省力化したい • 課題点: 全て解決したい • 独自のカスタマイズや最適化を可能にしたい » ブラックボックスではなくホワイトボックス • 意思決定をチーム内で完結させたい » 中央集権ではなく地方分権 ハードルは高いが、チャレンジしたい
- 44. DeNAのネイティブアプリ開発の未来 サーバ運用出来るだけ省力化したい • サーバインフラはフルマネージドなクラウドに寄せる » GCP GAE/SE Go • この層ではタイトル毎の最適化はしない • ここはブラックボックスと割り切る
- 45. DeNAのネイティブアプリ開発の未来 ブラックボックスではなくホワイトボックス 独自のカスタマイズをしないなら開発が不要 • 基本的な機能はライブラリとして用意 • 用意はするが差し替え可能・改変可能 • 独自の機能を追加しやすい作り • 引き続き、共通基盤チームは作る • タイトルを跨いだ最適化や再利用は行う 機能一覧 • アカウント認証 • クライアント主導のセーブデータ管理 • アセット配信 • 課金 • 仮想通貨管理 • Push通知 • メンテナンス • 強制バージョンアップ • ログインボーナス • ガチャ • SNS連携データ引継ぎ • フレンド • アイテム補填機能 • ランキング • 他プレイヤー検索機能 • 返信付きお問合せ機能 • 分析ログ送信 • , etc.
- 46. DeNAのネイティブアプリ開発の未来 • 良い点: 可能な限り残したい • 独自のカスタマイズをしないなら開発が不要 • サーバ運用出来るだけ省力化したい • 課題点: 全て解決したい • 独自のカスタマイズや最適化を可能にしたい » ブラックボックスではなくホワイトボックス • 意思決定をチーム内で完結させたい » 中央集権ではなく地方分権 ハードルは高いが、達成できそう
- 48. まとめ 魅力的な面白いゲームを開発し、世界に Delight を届ける そのためにも • より自由度高く、作りたいゲームが作れるように • より開発効率よく、作りたいゲームに集中できるように この2つを両立出来るような開発・運営体制を整えることに挑戦していきます
- 49. ご静聴ありがとうございました
Notes de l'éditeur
- みなさん初めまして。DeNAの北澤と言います。 本日はDeNAのネイティブアプリ開発の歴史の中で、 サーバ側でやってきたこと、現在の状態、そして今後の未来についてどう考えているのかについて、 説明させていただきます。
- まず最初に自己紹介させてください。 私、キタザワヨシロウと言います。 (あと読み上げ)
- アジェンダなのですが、 まあ要するに今までの過去の話と、 それを踏まえて、未来の話、今後どうしていくつもりかの話です。
- まずDeNAのゲームのこれまでの話なのですが、 DeNA Techcon 2016, 2017 それぞれで、 弊社池田の方から、DeNAのネイティブアプリ開発についての戦略だったり課題だったりをお話しさせていただきました。
- その中で、 元々インターネットサービスの会社だったDeNAが、 ゲーム開発の世界の中で、どういう歴史を辿ってきたかがまとまっているので、 簡単におさらいします。
- 最初はガラケーのブラウザゲームから始まり
- Kickmoter という、 webとネイティブのハイブリットのような、 webのレイヤーとネイティブのレイヤーを重ねて描画するシステムを作って それでゲームを作っていたり
- ブラウザの上でどこまでできるのかというのにチャレンジしたりもしていました。 いわゆる Single Page Application ですね。 ブラウザ的なページ遷移はせずに、 webとしての1ページの上でゲームでのシーン遷移をどんどんしていく形です。
- で、その後 2015年になって、 いわゆるネイティブアプリとして開発したタイトルをリリースします。
- ここで今、「ネイティブアプリとして」という表現を使いましたが、 ちょっとこの後にも本発表の中で「ネイティブアプリ」という言葉が何回も出てくるのですが、 とは何を言っているのかといいますと、 まあそうですね、Unity や cocos2d-x 等のゲームエンジンで開発した、、 とそういうのを想像していただければ大丈夫です。
- ここまで約5年間で、モバイルゲームを取り巻く状況は大きく変化し、 合わせて我々もそれに合わせて変化してきました。 ただ、ネイティブアプリの開発に本格着手したのは、他社さんに比べると遅かったと実際遅めだったのかなと思っています。
- まずSakashoというのがあります。 内製で開発した BaaS であり汎用ゲームサーバでもあります。 DeNA Techcon 2017で、弊社春山の方から発表がありました。 内部の詳細な技術要素についてはこちらの方で説明されています。 ちなみなのですが、この会場の2つ前の発表の「協業アプリ開発を推進するテクニカルコンサルタントの挑戦」の中でも紹介されています。 本発表の中では、内部の技術要素と言うよりは、役割や戦略に焦点を当てて話していきたいと思います。
- まず特徴を簡単に説明します。 Sakashoサーバ + クライアントアプリ で完結します。 多数のタイトルのサーバサイドを、同一のサーバアプリケーション、そして1つのチームで引き受けています。 なので、実はタイトル開発チームにはクライアントエンジニアしかいません。 開発しているクライアントがSakashoサーバとAPI通信しているだけ、タイトル開発チームがサーバ側の何かを開発したりすることはありません。 これは、そうですね。今だと、Google Cloud Platform の Firebase に近いかもしれないですね。 シンプルなスマートフォンアプリなら、Firebaseを使えばクライアント側の開発だけでシンプルなスマートフォンアプリを作れてしまいますが、 Sakashoだと、シンプルなスマートフォンアプリではなく、一般的なソーシャルゲームアプリまで作れてしまう。と言うのが最大の特徴です。 なぜそんなことが可能なのか? それは、圧倒的な機能量です。 一般的なソーシャルゲーム、に必要なおよそ全てのサーバ機能を用意しています。
- ここでは代表的な機能を挙げています。 ゲームのコア部分を表現する部分のほとんどは、 「クライアント主導のセーブデータ管理」で実現しています。 サーバではステートを持たずに、ちょっと表現が古いですが、家庭用ゲーム機でメモリカードにセーブするようなノリで、サーバに対してセーブデータをセーブアンドロードしています。 それ以外の機能群は、ゲームのコア部分を表現すると言うわけではないけれどもソーシャルゲームあるあるな機能群です。 これだけ機能を用意していることによって、 Sakashoサーバ + クライアントで完結というのを実現しています。
- 一方それによりこのような特徴もあります。 (読み上げ) ここでの最適化と言うのは、 実行時パフォーマンスの最適化という意味もありますが、 それよりも、 サーバクライアント両方を使って表現する必要のある、独自性の強い機能やワークフローも含まれます。
- 決して、成り行きで結果的にそうなったという類のものではありません。 かなり意図的に戦略的に進めた結果です。
- (ちなみにここでのアーキテクチャは、サバクラ的アーキテクチャのこと)