「GDM vol.39 エンジニア向け勉強会」の感想
とてつもなく感動したので記録を取っておく。
序
2019/12/20 にヒカリエで DeNA 主宰のエンジニア向け勉強会に出席しました。
サーバー“コード”レスアーキテクチャ、とは
自分の雑な理解では
- クライアントはサーバーにバイナリデータ(以下DAO)としてデータを保存する、DAOはC#の一定の形式のクラスを便利SDKで保存できる
- サーバーは基本的にデータの中身は感知しない、1APIを1トランザクションとする Key-Value ストア
- サーバーは、ガチャ・課金等、重要な要素ではサーバ側マスターデータで定義された抽象的なトークンをルールに基づいて発行するが、トークンのDAOへのマッピングは感知しない
- クライアントは上のトークンをDAOへと変換するトランザクションをもって消費する、APIとしては冪等性がある
- 汎用的な改竄対策がクライアント・通信共にある
- 別途プレイヤのバイナリデータをJSON等でエクスポートしてDWHに流して非同期に分析するパスはある
- 汎用的なサーバAPI実装と、ゲーム固有のAPI実装の両方があるが、前者だけでも最低限は成立する
シーケンス的なもの
伝統的実装
ロジックはサーバー側だけにあり、APIを投げて結果を受け取るという、伝統的な実装です。
常に通信結果を待つので、通信環境次第ではストレスになり得ます。
一部非同期実装
ロジックはサーバーとクライアントにあり、一部の結果が完全に予測できるAPIのみは同時に実行することで、レスポンスをよくしようとする実装です。
サーバーとクライアントに同じロジックを載せるので辛い。
どこかで、こういう実装をしていた気がします。
サーバー“コード”レスアーキテクチャ
ロジックはクライアントにのみもち、サーバーではロジックを実行しません。ガチャの部分はややこしく見えますが、サーバーではダイスだけを振り、DB(DAO)への反映ロジックは全てクライアントの仕事になります。
一目見て、チート大丈夫？って感想を持つと思いますが、DAOの中身を非同期に監査することが可能です。最終的にチーターがBANされていれば問題は少ない。
DAO は Deserializer を使って変換した上でとることのできる対策として
- DAOの状態を変更するC#のDLLとしてビルドをしたものでチェックを行う
これだと監査タイミングが任意になるだけで、理論的には全チェックが可能ですね - 機械学習で異常値の検出を行う(多段防御の一つとして)
- 緩めな判定ロジックをしこむ(1日に可能なバトル実行回数だとか、課金量あたりでのアイテム増加量であるとか)
DAOへの変更LogicをUnity非依存のアセンブリに記述することを徹底していたり、 重要なLogicの前後でのDAOさえ送信されていればどうにでもなる感じがします。