cocone TECH TALK Vol.6 - リアルタイム対戦xバックエンドアーキテクチャ

Transcript

1. リアルタイム対戦 × バックエンドアーキテクチャ RYO TOMARU
2. 自己紹介 職歴 ゲーム系企業でクライアント /サーバーを主軸に しつつ、配信サービスのフロントエンド実装など も経験。 趣味 個人ゲーム開発、ドット絵、最近引退気味です が光の戦士。最近はGolangとFlutterが好き。 戸丸 良 / RYO TOMARU
3. 本日の内容 • どのような技術を用いて「リアルタイム対戦」を実現したか • 通信フローについてのご紹介 • 苦労したポイント ※詳細なインフラ構成については今回の範囲外となります ...。
4. 目次 1. リアルタイム通信をどの技術で実現するか 2. 今回採用した技術 3. 苦労したポイント 4. まとめ
5. リアルタイム通信をど の技術で実現するか
6. 多彩な選択肢 最近では、ゲームエンジン側でもサポートが進むなど、開発がしやすい環境となってきてい る。 • 純粋なSocketを用いて構築する • Unity+MLAPI/Mirror/DOTSNET … • Unity + Photon/モノビットエンジン/MagicOnion • gRPC Bidirectional Streaming RPC • WebSocketやDatagram … etc …
7. 選択肢が多い上に、一つ一つが難しい
8. 多彩な選択肢 「リアルタイム通信対戦がしたい」だけであれば、どの手段でも実現は可能。 ここに「サービス・ゲームデザインとしてはどうか 」「運用保守の面でどうか」「UXとしてどう か」など、様々な要素を加えて選択していく必要がある。 （難しい・・・） 今回は担当プロダクトにおいて、どのような選択をしたのか、苦労話と合わせてご紹介しま す。
9. 今回採用した技術
10. gRPCを利用 • 他の機能(API)はgRPCで実装していたため、同一の運用で対応したかった • Unary RPC ◦ Request/Response ◦ 一般的なAPI • Client Streaming RPC ◦ Clientから任意にデータ送信が可能 ◦ ファイルアプロードなど • Server Streaming RPC ◦ Serverから任意にデータ送信可能 ◦ 通知など • Bidirectional Streaming RPC ◦ 双方向通信 ◦ 相互に任意のタイミングでデータ送信が可能
11. 初期に採用したのは・・・ • 初期(モック)時点では、ゲームデザインが完全に FIXしていなかった • 単純に双方向を選択しておけば大抵なんとかなるよね、から選択 • 慣れていた gRPC Bidirectional Streaming RPC
12. gRPC Bidirectional Streaming • 俗に言う双方向通信 • クライアント、サーバー相互に任意のタイミングでデータ送信が行える • oneofを使用し、一つのstreamで複数のコマンドを定義 message Notify { // どれか1つの情報がくるので、 switchなどで処理を振り分ける oneof event { ChatInfo chat_info = 1; Actor join_actor = 2; … } } service StreamingService { rpc StartNotify(...) returns (stream Notify) {} … }
13. 順調に実装は進んでいったが・・・
14. 実装自体は進んだが、次第に様々な問題が発生 複雑化するコード Client/Server間のやり取りの増加 操作に対して必ず結果が必要 テストの複雑化 増えるoneof 開発コスト増加 send/recvそれぞれのgoroutineを 管理する必要 このメソッドってクライアントに何か投 げるんだっけ・・・？ 増え続けるoneof 増え続けるoneof 増え続けるoneof
15. pickup 増え続けるoneof • Request/ResponseをC/Sのmessageへ追加する • 関係性が非常に難解 message ClientNotify { oneof event { Say say = 1; Foo foo = 2; Bar bar = 3; Echo echo = 4; … } message Say {...} … } message ServerNotify { oneof event { SayResult say_result = 1; FooResult foo_result = 2; BarResult bar_result = 3; EchoResult echo_result = 4; … } message SayResult {...} … }
16. まだ間に合う・・・はず！ (そもそもゲームデザイン的にあっていないのでは？ )
17. 最終的な着地点 • gRPC + Unary RPC + Server Streaming RPC • 各種操作については、Unary RPC(Request/Response)へ変更 • 自身の操作などはServer Streaming RPCを利用して通知 • より詳細な情報が必要であれば Unary RPCで取得 gRPC + Unary RPC + Server Streaming RPC 意外とすんなりいけるはず
18. 最終的な着地点 • gRPC + Unary RPC + Server Streaming RPC • 各種操作については、Unary RPC(Request/Response)へ変更 • 自身の操作などはServer Streaming RPCを利用して通知 • より詳細な情報が必要であれば Unary RPCで取得 gRPC + Unary RPC + Server Streaming RPC 全部書き直した
19. gRPC + Unary RPC + Server Streaming RPC
20. Redis PubSubを利用
21. 結果としてどうなったか • 基本的にUnary RPCを利用するため、フローがシンプルになった ◦ いつも通りの実装、テスト手法が通用した • Request/ReponseがIDLにて明示的に定義されるため、読みやすい ◦ この操作きたら何を返すんだっけ・・・が無くなった • Unaryは操作、Streamingはサーバーからの通知と役割を切り分けられた ◦ CRUDとNotifyを切り離せたので、可読性が上がった
22. 苦労したポイント
23. 苦労したポイント 再接続時の復帰処理 復帰時の進行状況に応じて状態を再現する必要があった。 また切断中は自動行動を行うため、タイミングによっては進行不能になるなど、 リリース直前まで頭を悩ませられた。 細かいエッジケース対応 〜の時に〜をするとバグる、という様な話が初期は特に多かった。 最終的にはBOTを作成し、自動的にバトルを繰り返す仕組みでカバーした。 ローンチ後、大きな問題は起きていないので、良い結果が出せた。 参考: https://qiita.com/maruc/items/2393647be5caa32623e3
24. 苦労したポイント PubSubに悩まされた go-redisを使用していたが、コネクション数が多大になったり、 ConnectionPoolとPubSubの接続状態連携が行われていないなど ...。 最終的にはある程度自前でコントロールを行った。 負荷対策 システム上、最新のデータを取得するケースが多く、 Primaryアクセスが頻発。 キャッシュアサイドパターンを用いることで、負荷軽減を行った。 （整合性を担保する必要があるので、可能であれば避けたい所ではあった）
25. pickup go-redis pubsub • 1購読=1コネクションが貼られる • アクティブが1万人いたら1万コネクション ◦ パフォーマンスが著しく低下 ◦ ElasctiCacheの上限にもかかる • 最終的にAPでコネクションを自前プールするよう実装 • 一つのコネクションで複数サブスクライブできるように変更 • 内部的に各Sessionのgo:channelへpush ◦ ch <- event
26. まとめ
27. まとめ • 当たり前ですが「ゲームデザインにあった」技術選定、設計が重要。 • 表面上動くものはすぐに作れる時代ではあるが、その先が深い。 ◦ このタイミングで切断されたら・・・ ◦ 地下鉄で瞬断したら・・・ ◦ バイナリが改造されたら・・・ etc • 「どのようにテストを行うか」も初期段階で考えておくと良い。 • 開発中はクライアント担当とずっと「うーん・・・」と唸ることになる。 • ・・・とはいえ、開発自体は楽しい！
28. ご静聴ありがとうございました