Slide 1

Slide 1 text

開発から本番まで、 サーバーレスで本格的な リアルタイム対戦型ゲーム 運用とAWS環境解説 第1回: Meet-Up the 1st はじまり 2022年6月14日 (火) 株式会社コールド・フュージョン テッダー マイケル JAWS-UG GameTech専門支部

Slide 2

Slide 2 text

$ 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

Slide 3

Slide 3 text

今日お話しすること ● 軽くCrystal Clashのゲーム内容を紹介 ● Crystal Clashアーキテクチャ設計の説明 ○ 全体図 ○ APIとWebSocket (Lambda)の使い分け ○ ECS/Fargateのリアルタイム対戦サーバー ○ Step Functionsでランクマッチ進行 ○ ゼロ・ダウンタイムのデプロイのコツ ● 今後の進展

Slide 4

Slide 4 text

Crystal Clashのゲーム内容

Slide 5

Slide 5 text

対戦ゲームモード ● 基本はピクセルロジックパズル ● 7x7のゲームフィールド ○ パネル正しく塗って兵士を沸かす ○ 長く塗るほどコンボで強い兵士に ○ 兵士は自動的に相手兵士へ攻撃 ○ 3レーン中2レーン確保と勝利 ● 1対1の対戦型 ○ 相手は反転した同じパズル ○ マッチング失敗場合はbotと対戦 ● 1ゲームは最大3分間

Slide 6

Slide 6 text

ランクマッチ ● 同時に8人のターン型の陣取り合戦 ● 2・12・48時間の3種類 ● 進軍することで対戦ゲームで戦う ○ ターン中でチップに旗が設置 ○ ターン終了でチップごと最高点数のプ レイヤーが獲得 ○ 城との繋がりを失うと切断されたチップ を全て喪失 ● マッチ終了でランクポイント取得 ○ 頂上登るほど高いランクポイント

Slide 7

Slide 7 text

Crystal Clashのアーキテクチャ

Slide 8

Slide 8 text

最初はこんな感じ...

Slide 9

Slide 9 text

2017年(発売当時)のアーキテクチャ たった1台のt2.micro!! ● 3ヶ月の開発期間 ● いわゆるLAMPサーバー ○ Apache ○ MySQL ○ PHP (API) ○ 対戦ゲームサーバー ● よく耐えてくれた...

Slide 10

Slide 10 text

そして5年後...!

Slide 11

Slide 11 text

2022年(現在)のアーキテクチャ全体図

Slide 12

Slide 12 text

アーキテクチャ全体設計 ● 各本番環境は個別 のAWSアカウント ● dev+stagingは 1つのアカウント ● devは自由にリソー ス作成 / 変更 ● stagingはdevのリ ソースでCFn作成 ● 本番はstagingの CloudFormation をそのまま利用

Slide 13

Slide 13 text

● HTTPS/WSSは CloudFront通す ● 各本番環境に CloudFront設置 ● 本番環境を通して dev+stagingは 別パスでアクセス ● Origin設定をクライ アント側で管理する より楽! アーキテクチャ全体設計

Slide 14

Slide 14 text

アーキテクチャ全体設計

Slide 15

Slide 15 text

APIとWebSocketの使い分け HTTPS APIの役割 ● プレイヤー認証 ● データ同期 ● ランキング表 ● 課金レシート検証 ● 動画広告結果適用 ● ランクマッチ操作 ● などなど... ゲームサーバーからの プレイヤーデータ取得と ゲーム結果の通信も!

Slide 16

Slide 16 text

APIとWebSocketの使い分け WebSocketの役割 ● 同時接続数 ● マッチメイキング ● ゲームサーバーの 選択とIPv4/ポートの 返答 API GWではWSS接続は 最大2時間が上限 クライアント側で自動的に 再接続するのが必要

Slide 17

Slide 17 text

Fargateのリアルタイム対戦サーバー ● Dockerコンテナで サーバー用のLinux バイナリを実行 ● Auto Scaling グループで自動的に スケーリング ● 各インスタンスは Cloud Mapに登録 ● Lobbyはマッチング したプレイヤーを同じ インスタンスに接続さ せる

Slide 18

Slide 18 text

Fargateのリアルタイム対戦サーバー ● 1つインスタンスは同 時に複数ゲーム可能 (CPU/メモリある限 り) ● ゲームサーバーは API専用権限を持つ ● ゲーム設定 / プレイ ヤーデータ取得・ゲー ム結果などはAPIに POSTする

Slide 19

Slide 19 text

Fargateのリアルタイム対戦サーバー Cloud Mapは パブリックIPv4が対応して ないので対策が必要 カスタムアトリビュートが可 能なので、IPv4を取得し てから保存するとキャッ シュとして使える

Slide 20

Slide 20 text

Step Functionsでランクマッチ進行 ● 各ランクマッチは 15分毎にターン進行 ● 同時に複数ランクマッ チが行える ● 各ランクマッチの 開始時間はバラバラ ● APIでターン処理を行 い、次に処理すべき 待ち時間を返答 ● Step Functionで 呼び出して寝かすを ループするだけ!

Slide 21

Slide 21 text

Step Functionsでランクマッチ進行 ● Step Functionは最 大イベント数の上限あ るので、イベント数を測 りながら実行 ● 最大に近づいたら 自動的に再起動する

Slide 22

Slide 22 text

ゼロ・ダウンタイムのデプロイのコツ ● バックエンドのアップデートはCloudFormationのおかげでデプ ロイに信頼性がある ● ゲームサーバーはコンテナなので新規バージョンは数分程度で デプロイ可能(stagingでテスト済み!) ● API/WSSのLambdaはCodeDeployを利用 トラフィック移行機能で 安定してるか確認できる 万が一エラー発生した場合 は自動的にロールバック

Slide 23

Slide 23 text

今後の進展

Slide 24

Slide 24 text

今後の進展 ● マルチリージョン! ○ 現在は us-east-1 のみ... ○ 日本のプレイヤーのために東京リージョンを追加したい ○ 対戦中には通信遅延対策あるのでゲーム性には 影響ない ● ようやくNintendo Switchの発売! ○ 2022年秋...!?(本気で頑張ります!)

Slide 25

Slide 25 text

ご清聴ありがとうございます!