How we run a Realtime Puzzle Fighting Game on AWS Serverless

A 15 minute presentation I gave at JAWS-UG GameTech: Meet-Up the 1st describing the architecture for our 1 vs 1 realtime puzzle fighter, Crystal Clash, on AWS Serverless.

(Note: This presentation is only in Japanese, sorry.)

Transcript

1. 開発から本番まで、 サーバーレスで本格的な リアルタイム対戦型ゲーム 運用とAWS環境解説 第1回: Meet-Up the 1st はじまり 2022年6月14日 (火) 株式会社コールド・フュージョン テッダー　マイケル JAWS-UG GameTech専門支部
2. $ whoami > テッダー　マイケル（昭和51年生まれ / 2000年アメリカから日本） > 25年以上ゲーム業界で3Dエンジンと最適化を中心とするゲーム開発 　　（PS1 〜 Switchゲーム機 / モバイル端末 / PC / Oculus VR） > 10年以上AWSのクラウドアプリケーション開発（現在はサーバーレス / コンテナ） > JAWS-UG GameTech+札幌運営 / Tokyo Demo Fest実行委員 / AWSコミュニティビルダー > できること: リアルタイム3D / ゲームエンジン開発 / ユーザー向けAPI設計 / アプリ+バックエンド開発 / アーキテクチャ設計 / DevOps (CI/CD) > 好きな言語: C++17 / GLSL / ASM (x64/ARM/MIPS) / PHP / TypeScript > 好きなAWSサービス: Lambda
3. 今日お話しすること • 軽くCrystal Clashのゲーム内容を紹介 • Crystal Clashアーキテクチャ設計の説明 ◦ 全体図 ◦ APIとWebSocket (Lambda)の使い分け ◦ ECS/Fargateのリアルタイム対戦サーバー ◦ Step Functionsでランクマッチ進行 ◦ ゼロ・ダウンタイムのデプロイのコツ • 今後の進展
4. Crystal Clashのゲーム内容
5. 対戦ゲームモード • 基本はピクセルロジックパズル • 7x7のゲームフィールド ◦ パネル正しく塗って兵士を沸かす ◦ 長く塗るほどコンボで強い兵士に ◦ 兵士は自動的に相手兵士へ攻撃 ◦ 3レーン中2レーン確保と勝利 • 1対1の対戦型 ◦ 相手は反転した同じパズル ◦ マッチング失敗場合はbotと対戦 • 1ゲームは最大3分間
6. ランクマッチ • 同時に8人のターン型の陣取り合戦 • 2・12・48時間の3種類 • 進軍することで対戦ゲームで戦う ◦ ターン中でチップに旗が設置 ◦ ターン終了でチップごと最高点数のプ レイヤーが獲得 ◦ 城との繋がりを失うと切断されたチップ を全て喪失 • マッチ終了でランクポイント取得 ◦ 頂上登るほど高いランクポイント
7. Crystal Clashのアーキテクチャ
8. 最初はこんな感じ...
9. 2017年(発売当時)のアーキテクチャ たった1台のt2.micro!! • 3ヶ月の開発期間 • いわゆるLAMPサーバー ◦ Apache ◦ MySQL ◦ PHP (API) ◦ 対戦ゲームサーバー • よく耐えてくれた...
10. そして5年後...!
11. 2022年(現在)のアーキテクチャ全体図
12. アーキテクチャ全体設計 • 各本番環境は個別 のAWSアカウント • dev+stagingは 1つのアカウント • devは自由にリソー ス作成 / 変更 • stagingはdevのリ ソースでCFn作成 • 本番はstagingの CloudFormation をそのまま利用
13. • HTTPS/WSSは CloudFront通す • 各本番環境に CloudFront設置 • 本番環境を通して dev+stagingは 別パスでアクセス • Origin設定をクライ アント側で管理する より楽！ アーキテクチャ全体設計
14. アーキテクチャ全体設計
15. APIとWebSocketの使い分け HTTPS APIの役割 • プレイヤー認証 • データ同期 • ランキング表 • 課金レシート検証 • 動画広告結果適用 • ランクマッチ操作 • などなど... ゲームサーバーからの プレイヤーデータ取得と ゲーム結果の通信も！
16. APIとWebSocketの使い分け WebSocketの役割 • 同時接続数 • マッチメイキング • ゲームサーバーの 選択とIPv4/ポートの 返答 API GWではWSS接続は 最大2時間が上限 クライアント側で自動的に 再接続するのが必要
17. Fargateのリアルタイム対戦サーバー • Dockerコンテナで サーバー用のLinux バイナリを実行 • Auto Scaling グループで自動的に スケーリング • 各インスタンスは Cloud Mapに登録 • Lobbyはマッチング したプレイヤーを同じ インスタンスに接続さ せる
18. Fargateのリアルタイム対戦サーバー • 1つインスタンスは同 時に複数ゲーム可能 (CPU/メモリある限 り) • ゲームサーバーは API専用権限を持つ • ゲーム設定 / プレイ ヤーデータ取得・ゲー ム結果などはAPIに POSTする
19. Fargateのリアルタイム対戦サーバー Cloud Mapは パブリックIPv4が対応して ないので対策が必要 カスタムアトリビュートが可 能なので、IPv4を取得し てから保存するとキャッ シュとして使える
20. Step Functionsでランクマッチ進行 • 各ランクマッチは 15分毎にターン進行 • 同時に複数ランクマッ チが行える • 各ランクマッチの 開始時間はバラバラ • APIでターン処理を行 い、次に処理すべき 待ち時間を返答 • Step Functionで 呼び出して寝かすを ループするだけ！
21. Step Functionsでランクマッチ進行 • Step Functionは最 大イベント数の上限あ るので、イベント数を測 りながら実行 • 最大に近づいたら 自動的に再起動する
22. ゼロ・ダウンタイムのデプロイのコツ • バックエンドのアップデートはCloudFormationのおかげでデプ ロイに信頼性がある • ゲームサーバーはコンテナなので新規バージョンは数分程度で デプロイ可能（stagingでテスト済み！） • API/WSSのLambdaはCodeDeployを利用 トラフィック移行機能で 安定してるか確認できる 万が一エラー発生した場合 は自動的にロールバック
23. 今後の進展
24. 今後の進展 • マルチリージョン！ ◦ 現在は us-east-1 のみ... ◦ 日本のプレイヤーのために東京リージョンを追加したい ◦ 対戦中には通信遅延対策あるのでゲーム性には 影響ない • ようやくNintendo Switchの発売！ ◦ 2022年秋...！？（本気で頑張ります！）
25. ご清聴ありがとうございます！