サーバーレスをどこまで使う？ WebRTC対戦ゲームで選んだVPSとの共存設計

Transcript

1. サーバーレスをどこまで使う？ WebRTC対戦ゲームで選んだVPSとの共存設計 2026/09/19（土） ServerlessDays Tokyo 2026 Pegass85 竹内 佑介 1
2. 自己紹介 竹内佑介 • インディーゲーム制作サークルPegass85代表 • IT企業の会社員／趣味でインディーゲーム制作 • 代表作「機動倶楽部Gブレイバーバースト」 主な実績 🌐 AWS builders. ash寄稿「サーバーレスでターンベース制のネット対戦ゲームを作った話」 🎪 東京ゲームショウ2022 インディーゲーム選考出展に選出 🏆 ニコニコ自作ゲームフェス2023 敢闘賞 fl 2
3. はじめに • 本セッションでは、実際の開発事例を題材として、サーバーレスの採用判断、 サーバーレスが適さないケースでの代替方法を説明する • WebRTCのP2P通信によるゲーム状態同期など、 アプリケーション固有のものは取り扱わない 3
4. 今回の題材「あいことば対戦」 ユーザ登録なし で利用可能 ひながな5文字 でマッチング 4 P2P(WebRTC)で対戦
5. デモ動画 5
6. 背景および基礎設計 🔍背景 • 既存ネット対戦はユーザー登録が必須だったが、 小中学生からは「家でも対戦したいけど、ユーザー登録は難しい」と言われた • そこで、ログインなしで対戦できる「あいことば対戦」を開発することになった 📋要件定義 (1)ユーザー登録不要 (2)低コスト (3)子供でも使える ※ベストエフォート提供 💡解決方針 WebRTCを採用 • WebRTCは大半のフローでP2Pなので、 サービス提供側のインフラ負担が抑えられ → (1)、(2)を満たす ひらがな5文字でマッチング • 小学生が理解できる「ひらがな」を採用 → (3)を満たす 6
7. (1)シグナリング WebRTCのフロー お互いの通信先を交換 ※シングナルサーバー経由で双方向通信を実施 シグナルサーバー (3)P2P接続 中継なしで直接接続 ※ブラウザが接続先を網羅的に検証 端末A 端末B TURN (3ʼ)TURN経由P2P ネットワーク的にP2P できない場合はTURNで中継 (2)STUN 端末のグローバルIPを教えてもらう ※P2P確率を上げるために STUN 7
8. モジュール設計 ①シグナルサーバー ひらがな5文字マッチングなど UI/UXを細かくカスタマイズしたい ① → 独自実装 シグナルサーバー ②TURN/STUNサーバー coturnというTURN/STUNの デファクトスタンダードがある ③ 端末A 端末B ② → coturnの動作インフラ構築 ③ゲームの状態同期ロジック TURN システム固有の作り込み → 本セッションでは取り扱わない STUN 8
9. 技術選定について シグナルサーバー、coturnを以下の方法で技術選定する 評価項目（5段階評価） 稼働環境 • サーバーレス • 値段 • CaaS • 固定費、変動費 • スケール • IaaS（モノリシック） • 負荷分散、フェイルオーバー • 運用 • VPS（モノリシック） • デプロイ、インフラ整備 9
10. 前提(1/3)：稼働環境ごとの料金について 時間単価 VPS < IaaS < CaaS < サーバーレス アイドルコスト < サーバーレス →アイドルコスト0 CaaS = IaaS = VPS →リクエストがなくても課金 → 稼働時間が短ければサーバーレスが最安 10
11. 前提(2/3)：サーバーレスの動作モデル ハンドラ呼び出し HTTPリクエスト ユーザー Amazon API Gateway イベント駆動 • ユーザーからのHTTPリクエストなど、 AWS Lambda 原則として長時間連続稼働はできない • 最大15分のタイムアウトがある • AWS Step Functionsで定期的に呼び出すことで イベントをトリガーにして動作する 擬似的な長時間稼働は実現可能 → イベント駆動、短時間処理でサーバーレスは真価を発揮 11
12. 前提(3/3)：IaCによる運用上のメリット 既存環境 既存環境に影響なく新環境を生成 IaC(Infrastructure as Code) 新環境 ブルーグリーンデプロイ • リリースのたびにIaCで新環境を作成し、 → 別次元の運用の快適さ 気軽にできる破壊的変更 • 共用のテスト環境とは別に、IaCなら簡単に個人用の 向き先を切り替えるデプロイ 検証用環境を作成できる • 既存環境はそのままなので、 • アーキテクチャ変更、障害再現など、環境を破壊 安全・迅速な切り戻しが可能 するおそれのある構成も手軽に試すことができる 12
13. シグナルサーバーの要件 (1)ひらがな5文字でのマッチング ・ホスト側にランダム生成されたひらがな5文字が与えられる ・あいことばがマッチしたゲストとシグナリング開始 シグナルサーバー 端末A (2)接続情報の交換 ・自身の接続先情報を相手に送信 → イベント駆動、短時間処理で実現可能 13 端末B
14. シグナルサーバー x サーバーレス アーキテクチャ概要 Amazon API Gateway (WebSocket API) AWS Lambda Amazon DynamoDB • Lambdaをつかったサーバーレスの定番構成 • Push通知が必要なので、WebSocket APIを採用 • DynamoDBの条件付き更新で排他制御 評価 • 料金：５ • アイドルコストが0、トータルで激安なLambda • DynamoDB、API Gatewayの料金もたかが知れてる • スケール：5 • Lambdaはスケーラビリティのノウハウ、実績ともに充実 • 運用：5 • マネージドな環境なので、インフラ整備は軽い • Serverless FrameworkでIaC化、別次元の快適さ 14
15. シグナルサーバー x CaaS アーキテクチャ概要 Amazon API Gateway (WebSocket API) AWS Fargate • 前スライドのLambdaをFargateに置き換えた構成 • Push通知が必要なので、WebSocket APIを採用 • DynamoDBの条件付き更新で排他制御 評価 • 料金：2 • 時間単価が高いFargate • DynamoDB、API Gatewayの料金はたかが知れてる • スケール：5 • Fargateはスケーラビリティのノウハウ、実績ともに充実 • 運用：4 • マネージドな環境なので、インフラ整備は軽い • IaC化はできるが、コンテナ、IaCの二重管理が面倒 Amazon DynamoDB 15
16. 参考：サーバーレスとCaaSのIaC サーバーレス sls deploy サーバーレス serverless.yml CaaS cdk deploy コンテナイメージのビルド AWS CDK この工程が足を引っ張る ※体感でサーバーレスの1.5から2倍の時間がかかる 16 CaaS
17. シグナルサーバー x IaaS（モノリシック） アーキテクチャ概要 • モノリシックなEC2インスタンス • DBなどのミドルウェアはインスタンスに腹持ちする 評価 Amazon Elastic Compute Cloud (Amazon EC2) • 料金：3 • 時間単価が安いEC2 • スケール：1 • モノリシック構成なのでスケールできない • 運用：1 • 手作業 or オーケストレーションツール 17
18. シグナルサーバー x VPS（モノリシック） アーキテクチャ概要 • モノリシックなさくらのVPS • DBなどのミドルウェアはインスタンスに腹持ちする さくらのVPS 評価 • 料金：4 • 時間単価が激安なVPS • スケール：1 • モノシック構成なのでスケールできない • 運用：1 • 手作業 or オーケストレーションツール 18
19. シグナルサーバーの技術選定 料金 スケール 運用 サーバーレス 5 5 5 CaaS 2 5 4 IaaS（モノリシック） 3 1 1 VPS（モノリシック） 4 1 1 → 料金、スケール、運用が1位のサーバーレスを採用 19
20. coturnの要件 (1)P2P通信を中継する ・大容量・長時間通信も考慮する → 常時接続、長時間処理 端末A TURN STUN (2)グローバルIPを返す ・自身にアクセスしたグローバルIPをそのまま返す → イベント駆動、短時間処理 → 安全側に倒して、常時接続、長時間処理 20 端末B
21. coturn x サーバーレス アーキテクチャ概要 • プロトコルだけならLambdaで論理上はcoturnが動く構成 • Lambdaを長時間稼働させる仕組みが別途必要 Network Load Balancer 評価 • 料金：1 • 時間単価が激高なLambdaを常時稼働 • NLBはバカにできない料金 → 頑張って長時間稼働させる仕組みを作っても アイドルコストが一番高い AWS Lambda ❌選択肢からはずす 21
22. coturn x CaaS アーキテクチャ概要 • HTTP以外を稼働させる際のFargate定番構成 Network Load Balancer AWS Fargate 評価 • 料金：1 • 時間単価が高いFargate • NLBはバカにできない料金、従量課金な通信費 • スケール：5 • Fargateはスケーラビリティのノウハウ、実績ともに充実 • 運用：4 • マネージドな環境、インフラ整備は軽い • コンテナ、IaCの二重管理がやや煩雑 22
23. coturn x IaaS（モノリシック） アーキテクチャ概要 • モノリシックなEC2インスタンス • DBなどのミドルウェアはインスタンスに腹持ちする 評価 Amazon Elastic Compute Cloud (Amazon EC2) • 料金：2 • 時間単価が安いEC2 • 従量課金な通信費 • スケール：1 • モノリシック構成なのでスケールできない • 運用：1 • 手作業 or オーケストレーションツール 23
24. coturn x VPS（モノリシック） アーキテクチャ概要 • モノリシックなさくらのVPS • DBなどのミドルウェアはインスタンスに腹持ちする さくらのVPS 評価 • 料金：5 • 時間単価が激安なVPS • 通信費はサーバー代に含まれる • スケール：1 • モノシック構成なのでスケールできない • 運用：1 • 手作業 or オーケストレーションツール 24
25. coturnサーバーの技術選定 料金 スケール 運用 サーバーレス 1 ? ? CaaS 1 5 4 IaaS（モノリシック） 2 1 1 VPS（モノリシック） 5 1 1 あいことば対戦でcoturnのスケール、運用は必須ではない • 要件定義より「(2)低コスト」かつ「ベストエフォート」 • coturnがなくても、同一ネットワーク上の端末は対戦できることがある • 一般的にturnサーバーが利用されることは少ないと言われている ※登壇者は家庭用Wi 、モバイル回線でcoturnなしで直接接続できた（IPv6、UDPホールパンチング） → 料金を優先してVPSを選択 fi 25
26. あいことば対戦の認証・認可について • あいことば対戦はログイン不要で利用可能だが、 攻撃の緩和、ユーザーセッション追跡などを目的として匿名トークンを導入する • 認証・認可のベストプラクティスにならい、トークンを一元管理することを目指す 認証基盤 シグナルサーバー 誰でも発行可能 未ログイン ユーザー 認可 匿名トークン 26 coturn 認可
27. 認証基盤の要件 認証基盤 (1)匿名トークン発行 (2)匿名トークン検証 よくあるWebアプリの挙動 よくあるWebアプリの挙動 匿名トークン → イベント駆動、短時間処理で実現可能 27
28. 認証基盤の設計方針 coturnの組込み認証を利用 サーバーレスに認証基盤を構築 とくにこだわりはないので、 組込み機能を利用する 認証基盤はイベント駆動、短時間処理で実現可能 匿名トークン サーバーレス さくらのVPS DynamoDBに匿名トークンを保持 • 柔軟性、料金を考えてDynamoDBに匿名トークンを保持する • DynamoDBにトークンが存在するか否かでトークン検証をする Amazon DynamoDB → coturnの組込み認証について考える 28
29. coturn組込み認証の比較・検討 HMAC認証 DB認証 OAuth認証 • シークレットを共有して、 • 認証情報（ユーザー名、 ハッシュの突き合わせを する パスワード）をDBに保存 • 認証基盤にOAuthを使う • あいことば対戦ではOAuth • サーバーレス、VPSで 共有シークレットを持つ だけで実現可能 → 導入可能 • サーバーレス、VPSで 同じDBを参照すればいい • coturnはDynamoDBに を採用しておらず、coturn のためだけにOAuthを導入 するのは過剰 対応していない → 導入できない 29 → 導入しない
30. 参考：coturnのHMAC認証について クレデンシャル ユーザー名 coturn 有効期限内か確認 sha1 有効期限:ユーザー名 sha1 パスワード 共有シークレット 一致するか確認 30 ハッシュ
31. coturnの匿名トークン統合について coturnクレデンシャル 有効期限まで無効化できない 共有シークレット VPS(coturn) 共有シークレットを変更すれば 理論的には無効化できる 変更したら正規ユーザーにも影響 共有シークレットを変更した場合、 正規ユーザーのクレデンシャルも無効になる → 匿名トークン無効化でcoturn利用停止はできない 31
32. coturnクレデンシャルの生成フロー (1)匿名トークンを生成 サーバーレス (シグナルサーバー/認証基盤) VPS(coturn) (2)匿名トークンで認可 (3)coturnクレデンシャル生成 匿名トークン coturnクレデンシャル ※有効期間は短時間（10分） coturnクレデンシャルの有効期間は短時間 • トークンを一元管理できないので、リスクを減らす ゲーム特性から有効期間は10分 • Gブレイバーバーストの試合時間は3〜5分程度、 ためにcoturnクレデンシャルの有効期間は短時間に する • 32 これを2倍して有効期間は10分とした これ以上の試合時間になることもあるが、その場合 は既存対戦（要ログイン）を利用してもらう
33. あいことば対戦の認証基盤（完成系） AWS Secret Manager に記載 coturn設定ファイルに記載 共有シークレット サーバーレス (シグナルサーバー/認証基盤) coturnクレデンシャル生成には 匿名トークンが必要 匿名トークン coturnクレデンシャル 33 VPS(coturn)
34. 参考：あいことば対戦のソースコード • あいことば対戦のバックエンド、フロントエンドをGitHubに公開しています • https://github.com/kaidouji85/gbraver-burst-network 34
35. まとめ • 本セッションでは、どこまでサーバーレスを採用し、 どこをVPSへ切り出したのか、その設計判断を実例とともに紹介した • シグナルサーバーはイベント駆動、短時間処理なので、料金、運用、スケール に優れるサーバーレスを採用した • coturnは常時接続、長時間処理であり、ベストエフェオート提供であること を考慮して料金に優れるVPSを採用した 35
36. ご清聴ありがとうございました 36