DeNAのサーバー"コード"レスアーキテクチャ
•Als PPTX, PDF herunterladen•
4 gefällt mir•2,496 views
GDM Vol.39 講演資料 https://gdm39engineer.peatix.com/
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie DeNAのサーバー"コード"レスアーキテクチャ
Ähnlich wie DeNAのサーバー"コード"レスアーキテクチャ (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
DeNAのサーバー"コード"レスアーキテクチャ
- 2. Agenda 2 自己紹介 背景: サーバー”コード”レスアーキテクチャとは何か 実践: サーバー”コード”レスアーキテクチャでのゲームクライアント開発 1 2 3 今後: サーバー”コード”レスアーキテクチャの臨界点と今後の展望4
- 3. 自己紹介 3 • 大竹 悠人(Haruto Otake) • 共通基盤部 ゲームデベロッパーライブラリグループ • a.k.a @Trapezoid • 経歴 • 2009/4 ドワンゴに新卒入社 • 2013/5 DeNAに中途入社 • 仕事 • Unity向けの様々な内製ライブラリの実装・保守 • DeNAの内製ゲームサーバーフレームワーク TakashoのクライアントSDK開発 • Unityを使ったゲームタイトルへの技術面でのサポート(火消し業) • DeNA TechCon 2020でも喋ります
- 4. 4 自己紹介 背景: サーバー”コード”レスアーキテクチャとは何か 実践: サーバー”コード”レスアーキテクチャでのゲームクライアント開発 1 2 3 今後: サーバー”コード”レスアーキテクチャの臨界点と今後の展望4
- 5. 5 自己紹介 背景: サーバー”コード”レスアーキテクチャとは何か 実践: サーバー”コード”レスアーキテクチャでのゲームクライアント開発 1 2 3 今後: サーバー”コード”レスアーキテクチャの臨界点と今後の展望4
- 8. モバイルゲームで主流なアーキテクチャ ● クライアント ○ プレイヤーデータを直接改変する権利を持たない ○ サーバーが持つ情報を必要に応じて取得する ○ 得られた情報に基づいてクライアントがゲームを進行する ■ バトルや、バトル外のUIなど ○ 進行に応じてプレイヤーデータ等に変更を加える場合には、 その内容に応じた種類のサーバーのAPIを進行に応じたパラメータを付けて呼び出す ● サーバー ○ プレイヤーデータを直接改変する権利を持つ ○ プレイヤーデータの更新や取得の内容に応じてAPIを実装する ○ バトルの結果などは、クライアントのパラメータを信じつつ、バリデーションを行 う 8
- 9. このアーキテクチャのPros & Cons • Pros • サーバー側にでプレイヤーデータの変更を行うので、ユーザーの手元でのデータの 改変が難しい • チート対策になる • モバイルゲームによくある非同期なプレイヤー間連携機能を、サーバー側で自由に 実装することで、クライアントからその複雑さを隠蔽できる • サーバーでAPIを実装して、クライアントはそれを呼ぶだけで複雑なイベントな ども実現できる • 多くのエンジニアに馴染みがある • Cons • サーバーとクライアントの実装の分断が発生する • 実装言語もパラダイムも違うので、設計やチームが分断するポイントになる • サーバーロジックだけでは完結せず,どこまでサーバーでやるか?という判断が難し い • バトルはクライアントで持つが、サーバーでバリデーションもかける...など • 社内でもチームごとにノウハウが散らばる • アプリケーションとしての品質もチーム次第に 9
- 10. DeNAのサーバー”コード”レスアーキテクチャ • DeNAでは、一般的な作りにとらわれない手法でのモバイルゲーム開発を実践している • Unity, Cocos2d-xなどによる非ブラウザのネイティブアプリ時代から • 内製でも全てのタイトルがこのアーキテクチャをしている訳ではない • 一言で言えば、クライアントコードを中心に開発するアーキテクチャ 10
- 11. どのようなアーキテクチャか? • クライアントコード中心とは? • サーバーとクライアントのどちらに寄せるかを悩むものを、クライアントに寄せる • クライアントはサーバーからプレイヤーデータそのものを取得する • プレイヤーデータに基づいてクライアントがゲームを進行する • 進行に応じてプレイヤーデータに変更を加える場合には、プレイヤーが更新後のプ レイヤーデータそのものを生成し、その内容をサーバー側にAPIを通じて保存する • ゲーム用mBaaS(PlayFab, GameSparks, GS2)に近い • ターゲットが異なる • mBaaSはどうしても簡単に動くものを作る、ということにフォーカスされがち • サーバー”コード”レスはグローバル展開する大規模タイトルもターゲット • サーバー”コード”レスでは、クライアントでプレイヤーデータの大部分を制御する • 多くのゲーム用mBaaSでは、サーバー側に多くの設定や実装を持つ • FaaS的に振る舞いを設定できるようにしたり • mBaaS側にゲームドメインに沿った広範な機能が実装されていたり 11
- 12. サーバー”コード”レスを実現する共通ゲームサーバー Sakasho 12 • DeNAのモバイルゲームのためのプラットフォーム • Sakashoの環境一つでDeNAの数多くのゲームをホスティングしている • 豊富な機能を持つ • お知らせ / 通知 / プレイヤーデータ / 課金 / ガシャ / ログボ / 報酬 / フレンド/ etc • 専用のゲームサーバーを作らずに、モバイルゲームを開発できるのが特徴 • https://www.slideshare.net/dena_tech/dena-sakasho-denatechcon-72603307
- 14. 故に、サーバー”コード”レス • サーバーレスにサーバーがあるのと同様に、サーバーコードが無いわけではない • クライアントに寄せた作りをした上で、サーバーの機能を共通化する • ゲーム開発チームがサーバーコードを書かない • Sakashoではサーバー機能の共通化をプラットフォーム化という形で解決している • プレイヤーデータ != プレイヤーに関わる全データ • プレイヤーデータと呼ぶのはクライアントが更新の責任を負うデータのこと 14
- 15. サーバー”コード”レスでのプレイヤーデータに関わる責務分担 • プレイヤーデータはサーバーを単なるデータストアとみなして扱う • (現在は)概念的にはKey-Value Store • 1APIリクエスト単位で、アトミックな更新を行える • サーバーで行ったほうがよいものはサーバーに寄せる • ただし、サーバーからはプレイヤーデータを直接編集しない • 全てプレゼントボックスを経由する • サーバーで処理すべき状況 • 時刻や確率に従う形で付与したい • ガシャ / ログインボーナス • 付与する経路や総量を固定化したい • 仮想通貨の付与, ミッション報酬 • ユーザーの行動でなく、運営側からの行動として行う • お詫び配布 15
- 16. プレゼントボックスへの集約 • サーバー上で付与したアイテムはプレゼントボックスに一元化される • サーバー上で付与されたアイテムは、ゲーム内で直接扱うデータではない • サーバー上ではプレゼントボックスの中身の意味を知らない 16 レシート 仮想通貨 プレゼント ボックス 購 入 仮想通貨の消費と引 き換えに、プレゼン トボックスに内容を 付与 ガシャ購入API ログインボ ーナス ログボ獲得API ログボの進行と引き 換えに、プレゼント ボックスに内容を付 与 ログボ1 Stamina_50 ログボ2 Chara_001_Lv1 ガチャ結果1 Chara_999_Lv1
- 17. • プレゼントボックスの内容を、プレイヤーデータに引き換える • プレゼントボックスのアイテムの受け取り済みフラグと、アイテムを獲得した状態 のプレイヤーデータを同時にサーバーに渡して更新する • プレゼントボックスの中身が実際にどのようなプレイヤーデータに引き換えられる かは、クライアント側で制御する • 途中でアプリが終了してもユーザーが不利益を被らないことを保証する プレイヤーデータとサーバー管理のリソースの交換 17 プレイヤー データ プレゼント ボックス プレゼントボッ クス受け取りAPI プレゼントボックスの消費 と同時に、アイテムをプレ イヤーデータとして付与 UserCharaID CharaID Lv ... ... ... xxxx1 001 1 xxxx2 999 1 ログボ1 Stamina_50 ログボ2 Chara_001_Lv1 ガシャ結果1 Chara_999_Lv1 Stamina 10 ⏩ 60
- 18. サーバー”コード”レスによる効果 • 各々のゲームとしての固有の処理の多くをクライアント側だけで実装できる • ゲーム開発チームはクライアント開発のみに集中できる • プレイヤーデータと共通APIの範囲で出来ることならデプロイ不要で開発できる • サーバー開発チームも機能毎にAPIを開発する必要がなくなる • サーバーとクライアント間でプログラミング言語の分断も実質起こらない • スケーラブルなモバイルゲームを作ることができる • サーバー側の処理内容がかなりプリミティブになる • 処理がシンプルなほうが、最適化もしやすい • サーバー側でやることの共通項が飛躍的に多くなる • 最適化した既存の実装の成果を活かしやすい • プラットフォーム化することで、多数のタイトルを効率的に運用できる • いくつもの大規模タイトルのリリースを大きな障害なく乗り切っている 18
- 19. 19 自己紹介 背景: サーバー”コード”レスアーキテクチャとは何か 実践: サーバー”コード”レスアーキテクチャでのゲームクライアント開発 1 2 3 今後: サーバー”コード”レスアーキテクチャの臨界点と今後の展望4
- 21. サーバー”コード”レスアーキテクチャの実践 • サーバー側で担保/処理していたことの一部を、クライアント側で実現できるようにする • サーバーが通常担っていた役割のうちクライアントの方が楽なことをクライアント でこなすのがこのアーキテクチャの目的なので、必然的にこうなる • 後述する様々な問題は、ほぼ全てここに由来する • 2015年リリースの戦魂が、Unityでのサーバー”コード”レスを実現した最初の内製ゲーム • 当然、開発時も運用時も、問題が頻出した • 複数のタイトルの開発を経て、サーバー”コード”レスでクライアントを作る上で抑える べき点が明らかになってきた 21
- 22. サーバー”コード”レスアーキテクチャで抑えるべき点 1. プレイヤーデータのテーブル設計 2. プレイヤーデータの一貫性の保証 3. プレイヤーデータを扱うドメインロジックのレイヤー設計 4. プレイヤーデータのチート対策 5. 時刻の正確性の保証 22
- 23. 1. プレイヤーデータのテーブル設計 • プレイヤーデータの定義はクライアント側で行う • 扱う場所と構造の定義の場所は近くする • RDBMSの構造(表)以上の表現力があり、安全に扱える形でスキーマ設計を行う • Data Access Objectの記述はコード生成などを使って自動化する • 配列や構造体のような構造も利用する。縛られる理由が薄い • プレイヤーデータは必要なものだけを読み込めるようにする • イベントなど、運用時にデータ量の飛躍的な増加が想定されるものでは必須 • 失敗事例 • エンジニアが手作業でテーブルごとのシリアライズ処理を書いていた • 実装上の凡ミスによる不具合が発生 • 安全に倒すと扱える表現が貧弱に(リストやObjectといった構造が扱い辛く) • 起動時に過去のイベントデータをロードしていた • 起動が遅くなりユーザー体験が悪化, メモリを過剰に消費してクラッシュ • 扱うデータサイズが増えることで、サーバー負荷も増大 23
- 24. 2. プレイヤーデータの一貫性の保証 • プレイヤーデータの更新時に一貫性が担保されないと、重大な不具合につながる • プレイヤーデータの更新は、異なる2つのリソース間での交換であることが多い • 強化素材を消費して強化する など • プレイヤーデータ更新を伴うリクエストには冪等性が必要 • 更新時に、クライアントから更新の成功を100%検知することは不可能 • ネットワークエラー時など、サーバー側では成功している可能性がある • 成功していた更新をもう一度実行しても、何も起こらないようにする • 失敗事例 • リトライ時に意図せず、二重に仮想通貨が消費されてしまう • 複数テーブルに跨ったプレイヤーデータの更新が、片方のテーブルだけ更新されて しまい整合性が崩壊 24
- 25. 3. ドメインロジックのレイヤー設計 • クライアントが持つロジックの量が重い • クライアント側でテーブルの定義を全て持ち、データの変更処理なども書く • サーバーでやってきた事をクライアントで書く以上、それを保守できる設計が必要 • 酷い設計/実装をしたときの影響が相対的に大きい • 扱える範囲が広い分、プレイに致命的な影響を及ぼしうる • ユーザーからの信頼に毀損するような不具合に繋がる • 失敗事例 • コントローラに処理が集中、プレイヤーデータの操作とUIが密結合になりがちに • プレイヤーデータの変更内容が予測がつかない 25
- 26. 4. プレイヤーデータのチート対策 • サーバー”コード”レスでは、クライアントチートされる危険性が高い • メモリをチートツールで書き換えると、そのままその結果がサーバー上に反映でき る • クライアントは実行バイナリが手元にあるので、逆アセンブルなどでの解析が可能 • できる対策を可能な限り行う必要がある • https://www.slideshare.net/dena_tech/dena-techcon-2019-132194701 • メモリ書き換えの検知 • ハッシュ値チェックや、マスキングなどを徹底する • デバッガ/エミュレータの検出 • チートの前提になる環境を検出して、チートできなくする 26
- 27. 5. 時刻の正確性の保証 • 安易に信頼できる時計が存在しなくなる • サーバー側の時間が知れるのは、サーバーと通信を行った瞬間のみ • クライアント側でリアルタイムに時間を知りたい場合には、頼りにならない • 毎回サーバーに問い合わせるのも非現実的 • ユーザーの端末の時間は信用できない • 悪意を持って調整してくる可能性も • サーバー側の時間と、それを知った瞬間からの経過時間によってリアルタイムな時 刻を判定する • 経過時間を調整されることも防ぐ必要がある 27
- 28. 多すぎない? • 考えるべきことのオンパレード • これらをゲームごとに考えるのは現実的ではない • 幸いなことに、いずれもゲームごとにやるべき事のブレは少ない • つまりライブラリによる共通化が非常に有効なはず 28
- 29. D4L (DeNA Domain Driven Design Library) 29
- 30. D4Lの誕生 • DeNA Domain Driven Design Library • これまで述べてきたようなサーバー”コード”レスでクライアントを実装する上での課題 を解決するためのライブラリ • と、それを使った実装パターン • (未リリースの..)ゲームタイトルの開発用に開発した草の根ライブラリ • 先立って開発されていたSakasho採用タイトルでの知見を踏まえて実装 • 単体のライブラリとして社内で公開したところ、様々なタイトルで使われるように • 累計約10タイトルで採用。5年の歴史を持つ。大規模なゲームでの利用事例も • 追加で発生していった問題は都度カバーできるようにしていった • 現在ではSakashoの後継フレームワークのTakasho向けのバージョンを開発/保守 • Takasho SDKの一部として提供 30
- 31. プレイヤーデータのテーブル設計 • D4L.Definition.Compiler • パース用のDAO(Data Access Object)と、そのLoaderを自動生成するモジュール • クライアントから読み込むマスターデータも定義できる • テーブル指向 • テーブルがカラムの定義と複数の行を持ち、行はカラムの定義に合わせた値を持つ • 表ではない。RDBMSと違って、構造体やリストをカラムとして持てる • データの反映は行単位で行える • スキーマの定義方法 • C#コードを記述 • できるだけUnityエンジニアが直感的にかけるように • C#のクラスがテーブルに、そのフィールドがカラムになる 31
- 32. テーブルの自動生成 • DAOSchema属性にテーブルや種別を記述、フィールドにSchemaProperty属性をつけ る • Context属性によって、ロード時の単位を指定する • 同じ名前のContextが指定されているテーブルは、クライアントでまとめて読み込む ことが可能 32
- 33. D4Lによるプレイヤーデータのテーブル設計 • 生成するもの • Data Access Object • テーブル単位のクラスと、行単位のクラス • シリアライザ • Data Access Objectと 実際のプレイヤーデータを相互変換 • 読み込み単位を規定するDataCotext • データのコンバータ • 主にマスターデータ用 33
- 34. スキーマ定義に使える型 • C#のプリミティブな型 • string / (u)int / (u)short / (u)long / (s)byte / double / float / char / bool • C#のプリミティブな型に対応するメモリ改ざん保護型 • Guard~ (GuardString等), Guard~Array(GuardStringArray等) • 構造体 (SubSchema属性を付けた定義から構造体が生成される) • enum • 上記すべてのリスト • Dictionary<TKey, TValue> • TKeyはstringか整数型, TValueは任意の型 34
- 35. 35 D4Lによるプレイヤーデータのマッピング • 行単位でシリアライズ • 行のシリアライズにはProtocolBuffersを利用。C#による定義から.protoを自動生成する • マスターデータはFlatbuffersを使う。効率の為に使い分けている • Key-Value Store上へのマッピング • テーブルの1行がKVSの一つのキーに対応する • 複数のキーで一つのテーブルが成り立つ。 • キーはテーブルの識別子, 分割用のキー, 格納される行の主キーの3要素 • 特定のテーブルに所属するキーを前方一致でまとめて取得出来るように PlayerAvatar:2:12345 テーブルの識別子 水平分割用のキー (イベントのIDなど) 行の主キー
- 36. D4Lによるプレイヤーデータの分割読み込み • DataContextという単位でプレイヤーデータを読み込む • DataContextを必要に応じて読み込んでは、アンロードすることでプレイヤーデータ全体を クライアントが常時持たなくて良い状態にする • 垂直分割 / 水平分割の2軸でのテーブル分割を可能にする • 利用場面ごとの対象の切り分けにはテーブル毎のDataContextの振り分けによる垂直分割 • 量がスケールするものへ対処には分割用キーを利用した水平分割 • DataContextのインスタンス毎に1つグルーピングキーを持てる • 同じグルーピングをしている異なるプレイヤーデータを同時に取得できる • マスターデータとプレイヤーデータが同じDataContextに所属できる • プレイヤーデータと同じ分割単位で読み込みたいマスターデータというのも多い • 特にイベントデータ関連 36
- 37. 垂直分割 37 所持装備 キャラ倉庫 キャラごとの育成度 キャラごとの装備情報 キャラ倉庫 キャラごとの育成度 キャラごとの装備情報所持装備 所持品コンテキスト 倉庫コンテキスト キャラコンテキスト まとめて取得したい単位 (コンテキスト)に分類 シーンや場面に応じて読み込むテーブルを分けることができる (この分類はあくまで例です)
- 39. D4Lによるプレイヤーデータの一貫性の保証 • StorageChangeSetというクラスを1単位として、トランザクションを形成する • DataContextのアクセサクラスから、更新用のDAOを取得 • DAOのプロパティを更新 • 内容が確定したら、StorageChangeSetというクラスに登録 • Update/Deleteが可能。登録した時点でシリアライズされる • StorageChangeSetをAPIの引数に変換し、サーバー側に送信 • ApplyToDaoの呼び出しでメモリ内のDAOに更新を反映する • StorageChangeSetはマージ/シリアライズが可能 • サーバーが無くても動くので、開発初期に有用 • サーバーに送るタイミングを制御可能 • StorageChangeSetをサーバー送信の代わり にマージ • 送る前にアプリが終了すると巻き戻るが、 データの整合性は崩れない 39
- 40. D4Lによるレイヤ設計 • D4Lは軽量DDDによる設計を推奨している • Repository / ValueObject / Specificationの実装の為の基礎実装が存在 • 個別のビジネスロジックはDataContextやDAOに直接アクセスはしない • Repositoryを経由させ、ビジネスロジックから扱うEntitiyとDAOを分離する • プレイヤーデータは運用していくと頻繁にテーブルの種類が追加される • テーブルの追加がEntityの実装に与える 影響を最小化できる • 強く強制はしていない • ゲームによって準拠度はまちまち 40
- 41. D4Lによるプレイヤーデータのチート対策 • ヒープ上に常時乗る値に気軽にメモリ改ざん保護をかけれるようなライブラリをバンド ル • プリミティブ型の代わりに使うだけで、改ざんを検出した瞬間に検知 • スキーマ定義時に使うことで、メモリに乗った段階から破棄まで一貫して保護 • 元の型への暗黙的なキャストを有効にしているので、既存のコードの型を機械的に 書き換えるだけで殆どのケースでそのままコンパイルが通り、動作する • 改ざんを検知しても、すぐに強制終了はしない • 改ざんが成功したことを攻撃者に悟りにくくさせることが目的 • チート検出モードを有効にして、サーバーに送らずにメモリ内にのみ反映させる • チートが成功しているように見えるが、データは保存されない • 一定のランダムな時間の経過後に、強制終了する 41
- 42. D4L以外によるチート対策 • 社内のセキュリティ部と協力して様々なチート対策を徹底的に実施 • エミュレータ/ルート化の検出 • 署名の検証 • apkの署名のシグネチャが、想定のものかを検証 • 実行バイナリのダイジェスト検証 • コード領域のダイジェストを計算して、想定のものかを検証 • コードの難読化や、改ざん検出ソリューションの導入 • 内製化も進めている • これらの複合的に組み合わせて相互に守り合わせることで、突破をより難しくする • チートユーザーの動向を観察して継続的な対策を実施 • チート検出を回避されたら、回避策への対処を検討 • いたちごっこを地道に繰り返す • https://www.slideshare.net/dena_tech/dena-techcon-2019-132194701 42
- 43. データ分析によるチート対策 • その場はチートされても、他のユーザーに害を及ぼす前に検出できれば被害は少ない • データ分析によるチートユーザ検出 • プレイヤーデータのスキーマを分析側にも共有しておく • 分析基盤にプレイヤーデータを定期的に保存 • 異常なパラメータ上昇しているユーザーを検出できるように 43
- 44. D4Lによる時刻の正確性の保証 ● D4L.Moment ○ 信頼できる時間軸を扱うライブラリ ● 実行中の自プロセスの経過時間(ProcessTime)を信頼する ○ 時間が十分な精度で書き換えられずに進行するような相対時刻 ○ 経過した時間が分かるだけで、現在の日時が分かるわけではない ● あるProcessTimeの時点での日時を記録しておく ○ 都度現在のProcessTimeと記録済みのProcessTimeの差を記録された日時に足すこ とで現在の日時を計算できる 44
- 45. サーバー時間からの時間軸の取得 ● RTT分の誤差が発生してしまう可能性がある ● サーバーからのレスポンスに以下の情報を付与する ○ リクエスト受信開始時のサーバータイムスタンプ ○ レスポンス送信開始時のサーバータイムスタンプ ● クライアント側の送受信時の経過時間と合わせて、時刻を補正する ● これが信頼できる時間軸になる ○ クライアントでは、補正時処理の初期化だけしておく ○ あとはServerTime.Nowを呼ぶだけで信頼できる現在のサーバー時間を取得できる 45
- 46. 時間の速度の制御 ● 誤差をすぐに補正すると、時間の巻き戻りや早送りで意図せぬ不具合が発生する可能性 も ○ 特に、巻き戻るのは避けたい... ● 時間の流れを調整して、時間をかけて時間を補正 ○ 現実の1秒で0.9秒経過する時計なら、10秒で1秒の進みを巻き戻せる ■ 時刻自体が巻き戻ることはない。常に増加し続ける ■ 誤差がなくなったら、時間の流れは等倍速に自動的に戻る ■ ユーザーに違和感を持たれにくいよう、時間の速度は0.9倍速~1.1倍速の範囲 ○ 時間を補正した際に、補正時の差を時間の遅れとして捉えて時間軸を切り替える ○ シーン遷移時などに、まだ払いきっていない時間の差を一括で払うことも出来る 46
- 47. 47 自己紹介 背景: サーバー”コード”レスアーキテクチャとは何か 実践: サーバー”コード”レスアーキテクチャでのゲームクライアント開発 1 2 3 今後: サーバー”コード”レスアーキテクチャの臨界点と今後の展望4
- 49. サーバー”コード”レスアーキテクチャの臨界点 • MMOのようなゲームをこのアーキテクチャで作れるか? • 作れない。むしろ大半をサーバーに寄せるアーキテクチャが合っている • これはSakashoの開発時から分かってはいた • 当初は選択と集中の為に作るものをあえて制限していた • 作るものに合わせて、効率的な作り方を模索するべき • 実際に、サーバー”コード”レスではない作りをしているゲームも社内に存在 49
- 50. サーバー”コード”レスアーキテクチャの臨界点 • サーバーに寄せたい機能 != 共通機能 • ソーシャル性の高い機能はサーバーがあったほうがやりやすい • このような機能が無いと、今の市場で戦うのは厳しい • 共通機能として意識して設計しようとすると、難易度も速度感も損なわれる • 頑張って共通機能として実装しても、実質1タイトルしか使わないことも • Sakashoはマルチテナントなので、下手を打つと全社影響が出る • ゲーム側のエンジニアがSakashoチーム内にやってきてAPIを追加するようにな った • ゲームの為の実装だけをゲーム開発チームの意思決定で行いたい • 一方で、サーバー”コード”レス自体は一定成功を収めている • 同じ基準で、クライアントで書きやすい機能を実装するにはやはり効率的 • 基本路線は保ちつつ、案件ごとの独自APIも気軽に定義できるようにしたい • 必要なことが、必要なところに、書くべき人が書けるようであるべき 50
- 51. SakashoからTakashoへ • Sakashoの後継となるプロダクト、Takashoを開発中 • マルチテナントからシングルテナントへ。他のゲームへの影響が無くなる • FeatureSetという概念で複数のAPIセットをカプセル化 • 共通機能と独自機能を簡単に共存/保守できるようなサーバーフレームワーク & 共通 機能セット • サーバー”コード”レスは基本にしつつ、独自APIを気軽に案件ごとに足していける • 大量に独自APIを作る使い方も、殆ど共通APIで済ませる使い方も選択できる • D4LもTakashoに合わせて再設計 • 殆ど書き直した... • ライブラリ無しでSakashoを使う時の苦労から、TakashoからはD4Lは必ず提供さ れるようになった • Takashoについての既存の資料 • https://www.slideshare.net/dena_tech/dena-87961203 • https://speakerdeck.com/kyotak/xin-kemusahaji-pan-takashotefalsegoyan-yu-huo- yong-shi-li-falseshao-jie 51
- 52. まとめ • DeNAではサーバー”コード”レスアーキテクチャで大規模なモバイルゲームを実際に開発 /運用している • サーバー”コード”レスを運用するのに必要な要素は多岐に渡るので、D4Lというライブ ラリを開発/運用している • サーバー”コード”レスでの開発運用経験を踏まえて、いいとこ取り次世代の開発スタイ ルを実現するTakashoを開発中 52
- 53. PR: TechCon2020でも喋ります ● 2020/03/04 渋谷ヒカリエホールにて。気になる方は参加登録を! ○ https://techcon.dena.com/2020/session/4 ○ https://techcon2020-dena.peatix.com/ 53
- 54. Thank you for listening! 54
Hinweis der Redaktion
- どこまでサーバーでやるか?というのはどういうことかというと それこそブラウザゲームの時代はバトルなどのゲーム本体の処理も含めて全てサーバーで処理を行って、クライアントにはその経過や結果を表示しているだけでした。 今はアプリになり、さらにインタラクティブ性が高まっていった結果として、このような純粋なサーバーロジックのみの作り方はできなくなりました。 ゲームバトル前にパラメータを受け取ってバトル後に結果をサーバーに渡す、ということをよくするかと思いますが、これはバトルの内部の処理はクライアントを信頼することで成り立っています。 このギャップを埋めるために一部サーバーで結果のバリデーションなどもすることになったりするわけですが、このあたりが人や案件ごとに解釈を分ける要因になってしまいます。