AWS Summit Japan 2024 Game Industry Booth の舞台裏
Author : 西坂 信哉, 瀧田 直斗, 秋山 周平
AWS Summit Japan 2024 Game Industry Booth の舞台裏
Author : 西坂 信哉, 瀧田 直斗, 秋山 周平
こんにちは、ソリューションアーキテクトの西坂 信哉です。
今年の夏も、AWS の国内最大級イベントである AWS Summit Japan 2024 が開催され、多くのお客様にご来場いただきました。実はそのイベント内で、ゲーム業界のお客様向けに「実際に遊びながら学べるデモゲームの展示」ブースを開いていたことを、ご存じでしたか ?
本記事では、「知らなかった !」というあなたにも、「知ってた ! 遊んだよ !」というあなたにも (ありがとうございます !) 楽しんでいただけるよう、展示概要だけでなく、デモゲーム開発の裏側で開発者がどんな思いを持ちどんな作業をしていたのかも含めてご紹介したいと思います。
ゲーム開発者向けのその他の記事はこちら
- 選択
- Amazon DynamoDB で作るサーバーレスなゲーム用アチーブメントマイクロサービス
- AWS の知識ゼロから始める AWS GameKit
- Amazon GameLift を使って「最短」でマルチプレイヤーゲームを作る
- Amazon DynamoDB で作るサーバーレスなゲーム用フレンドマイクロサービス
- Amazon GameSparks でインフラを意識せずにゲームのバックエンドサービスを開発しよう
- 魔法で作る Amazon DynamoDB の 簡単ゲームインベントリ
- レベル 1 から作るゲームのクエスト手帳
- サーバーレスなゲームのギルド検索
- 一緒に学び考える ! ゲームの AI/ML 活用
- 3 ステップで始める AI モデル開発 ! 始める前に知っておくべきコト !
- 実践 ! 機械学習でゲームの休眠ユーザーを予測してみよう
- Amazon GameLift Anywhere でサクッとマルチプレイゲームを開発しよう
- ゲーム分析を Amazon Aurora と Amazon Redshift の Zero-ETL 統合ではじめよう
- Amazon Redshift を活用したゲームの行動ログ分析
- Amazon QuickSight によるゲーム分析ダッシュボードの構築
- 品質管理に生成 AI は使えるのか !? テキストチェックを生成 AI にやらせてみた
- 生成 AI を用いたヘルプソリューションを作成する
- 世界に 1 つだけの AI アシスタント作成 ~オリジナルにカスタマイズ
- マルチモーダルな生成 AI 活用の入門編! - 画像認識と画像生成
- Amazon S3 と Amazon CloudFront を活用したグローバル向けゲームビルドバイナリ共有環境の構築
- Terraform を利用した Amazon EKS の構築
- Amazon Bedrock でゲームの BGM を作ってみました !
- Amazon EC2 ではじめる Unreal Engine Pixel Streaming 入門
- Agones on Amazon EKS で構築するマルチプレイゲームの専用ゲームサーバー
- AWS Summit Japan 2024 Game Industry Booth の舞台裏
AWS Summit Japan 2024 でのデモ展示の概要
AWS Summit Japan 2024 は、2024 年 6 月 20 - 21 日に幕張メッセで開催され、オンラインを含めて 5 万人以上の方にご参加いただきました。本イベント内の Industry Zone というコーナーにて、主にゲーム業界のお客様を対象とした展示を行いました。
コンセプトは「実際に遊べるゲームを通じて AWS サービスを学ぼう」といったもので、来場いただいた皆様がお持ちのモバイル端末で実際にゲームを遊んでいただき、そのバックエンドとして動いている AWS サービスについて知っていただけるようなブースを目指しました。
実際には以下の 4 種類のゲームを作成・展示し、のべ 1,200 人近くの方にプレイいただけました !
画像をクリックすると拡大します
- プログラミング言語当てゲーム
こんな言語見たことないよ !!
表示されるサンプルコードがなんという名前のプログラミング言語かを当てるゲームです。知っている言語と似ているけど実は違う言語かも ?? - 脱出ゲーム “密室「AWS」からの脱出”
あなたは何分で脱出できるか !?
AWS のサービス名や関連キーワードが鍵になる脱出ゲームです。裏側では生成 AI の技術も活用しています。 - 生成 AI ゲームブック
あなただけのオリジナルエンディングを目指そう !
いくつもの選択肢を選びながらストーリーを進めていくゲームブックライクなゲームです。生成 AI が挿絵を添えながらあなただけのストーリーを紡いでいきます。 - AWS アイコン探しゲーム “Find The Icon”
AWS サービスアイコンの中から指示されたサービスのアイコンを誰よりも早く探しだせ !
最大 4 人まで同時に参加できるマルチプレイヤー対戦ゲームです。バックエンドには Amazon EKS や Agones を利用しています。
本記事では、AWS アイコン探しゲーム “Find The Icon” と 脱出ゲーム “密室「AWS」からの脱出” の 2 本についてご紹介したいと思います。
AWS アイコン探しゲーム “Find The Icon” について
ゲームの概要は先述の通りですが、簡単に言うと「かるた」のようなゲームになっています。指示された AWS サービス名のサービスアイコンを探し出し、一番最初に見つけたプレイヤーにポイントが入ります。ランダムで選ばれた 24 枚を取り切ったらゲーム終了です。取ったポイントの多さを競うマルチプレイヤーゲームです。
アーキテクチャ
全体のアーキテクチャはこのようになっています。
クライアントアプリは Unity、サーバーアプリは Go 言語で実装しています。サーバーアプリのホスティングには Agones、Amazon EKS、そして Karpenter を、マッチメイキングには OpenMatch を利用しました。
今回はシングルリージョンの構成になっていますが、グローバルに展開されている AWS の各リージョンを利用してマルチクラスタ構成とすることでゲームのグローバル展開にも対応できます。
(参考ソリューション: Guidance for Game Server Hosting Using Agones and Open Match on Amazon EKS)
クライアントアプリ
クライアントアプリは Unity を使い、WebGL 向けにビルドすることでブラウザでプレイできるようにしています。モバイルデバイスでのプレイを前提として作っていますが、PC でもプレイ可能です。ちなみに、本ゲームでは見つけた AWS サービスアイコンをタップ/クリックする操作でもプレイできるゲーム性ではありますが、開発者の個人的なこだわりで「十字キーでカーソルを動かす」という仕様にしています。
各プレイヤー名はあらかじめ準備された複数のキーワードと数字を組み合わせてランダムに決定されます。同時にキャラクターアイコンも表示されますが、こちらは Amazon Titan Image Generator (v1) にあらかじめ作成してもらった画像を入れています。
WebGL ビルドしたアプリは AWS Amplify の Hosting 機能でデプロイしています。AWS Amplify は CDN を利用したホスティングが簡単にできるのに加え、Basic 認証や URL リダイレクトの設定、カスタムドメインの設定などを手軽に行えるため、特にデモアプリには便利です。
サーバーアプリ
サーバーアプリは、各プレイヤーが使うクライアントアプリからの接続を受け付け、操作時のコマンドに応じたゲームロジックの処理を行い、ゲーム状態を送信する、といった処理を繰り返し行うようなアプリケーションになっています。
クライアントアプリ側では基本的にゲーム状態の表示に関するロジックしか持たず、並んでいるアイコンや各プレイヤーのスコアの情報は全てサーバー側で保持・アップデートされています。
EKS での稼働にあたっては、Agones の GameServer リソースでデプロイされるコンテナとしてビルドします。
今回はクライアントアプリとの通信は WebSocket で行われるため、GameServer リソースの定義には spec.ports.protocol: TCP を指定する必要がありました。指定しないとデフォルトで UDP 通信となります。
gameserver.yaml
apiVersion: agones.dev/v1
kind: GameServer
metadata:
name: find-the-icon
spec:
ports:
- name: default
portPolicy: Dynamic
containerPort: 8081
protocol: TCPサーバーアプリ開発における生成 AI 活用
サーバーアプリは Go 言語で開発しましたが、今回の開発者は Go 言語での開発経験がなかったこともあり、Amazon Bedrock と Amazon Q Developer を大いに活用しました。
まず、Amazon Bedrock に Go の WebSocket サーバーコードの作成をお願いしました。なお、汎用的なコールバック関数を追加実装していけるように、この時点でメッセージ ID を使った実装の指示をしています。
画像をクリックすると拡大します
作ってくれたコードの実行方法がわからなかったので、聞きながら開発環境を整え、実行しました。
画像をクリックすると拡大します
次に WebSocket 通信のテストをするため、クライアントのコード作成をお願いしました。この時点で、Go の WebSocket サーバーとクライアントを使ったテストまでできてしまいました。
画像をクリックすると拡大します
画像をクリックすると拡大します
Go 言語で実装したテスト用クライアントはコマンドラインから簡単にテストできる点で有用ですが、実際にはクライアントアプリは Unity で実装するので、クライアントのコードを C# で再実装してもらいました。
画像をクリックすると拡大します
画像をクリックすると拡大します
これで Unity からもサーバーに接続できるようになりましたが、現状 1 対 1 の通信にしか対応していません。ゲームは最大 4 人同時対戦なので、複数のクライアントから接続して相互にメッセージ通信ができるように、サーバーコードを修正してもらいました。
画像をクリックすると拡大します
また、Go のクライアントアプリを C# に変換したり、WebSocket でやりとりするオブジェクトの定義を Go と C# 間で変換したりといったタスクをお願いし、Unity アプリとの通信の実装もスムーズに進められました。
画像をクリックすると拡大します
画像をクリックすると拡大します
画像をクリックすると拡大します
ここまでのようなやりとりと、Amazon Q Developer の VSCode Extention を使ったコーディング支援も活用し、経験のなかった Go 言語での開発にもかかわらず 約 2 日間で サーバーとクライアントの骨子を完成できました。
ちなみに詳細は割愛しますが、Unity によるクライアントアプリの開発にも、同様に生成 AI をフル活用しました。
クライアント・サーバーアプリ間の通信
はじめは gRPC の利用を検討していましたが、ブラウザベースのゲームにすることになり、技術的実現性の観点から WebSocket ベースとなりました。加えてブラウザでは WebSocket 接続時に WebSocket secure での接続が必須となること、来場いただくお客様にスムーズにプレイいただける必要があること、から、以下のように正規の TLS 証明書を用いた構成を採る必要がありました。
まず今回実装したいフローは次のとおりです。
- ブラウザアプリがマッチメイキングリクエストを送信します。
- OpenMatch がゲームサーバーの割り当てを要求します。
- 割り当てが完了すると OpenMatch は DNS 名を返します。
- ブラウザが DNS 名を解決して IP アドレスを取得します。この時点で、証明書の検証が行われます。
- ブラウザアプリは、取得した IP アドレスを使用してゲームサーバーとの WebSocket secure 接続を確立します。
このフローを実装するために、以下の対処を行いました。
- A: Let's Encrypt を使用してドメインの TLS 証明書を取得し、取得した証明書を AWS Secrets Manager にインポートしました。
- B: EKS ノードが起動したタイミングでノードのパブリック IP アドレス (EKS では externalDNS というパラメータとして認識される) を登録しました。実装としては Amazon EC2 のユーザーデータスクリプトを利用して パブリック IP を Amazon Route 53 Public Hosted Zone に自動的に登録するようにしました。
- C: マッチメイキングレスポンスを送信する前に、externalDNS をドメイン名に変換する処理を実装しました。
- D: WebSocket secure 接続はクライアントアプリとサーバーアプリの間で確立するため、サーバーアプリ内で TLS 証明書とプライベートキーを使った処理が必要になります。ASCP (AWS Secrets Configuration Provider) を利用することで、ゲームサーバーの Pod に証明書とキーをファイルとしてマウントしました。
ブラウザベースではないゲーム、例えばモバイルアプリや PC のスタンドアロンアプリであれば自己署名証明書を利用できますが、ブラウザベースのマルチプレイヤーゲームでは必要性の高いトピックになります。例えばユーザーのプレイハードルを下げるためにブラウザベースで展開しているメタバースアプリなどで応用できると思います。
OpenMatch
OpenMatch はオープンソースのゲーム向けマッチメイキング用フレームワークで、Agones 同様 kubernetes 上で動作します。OpenMatch ではマッチメイキングロジックを Go 言語で実装できます。今回は 1 人～ 4 人でプレイできるゲームなので、4 人がマッチすればすぐにゲーム開始、3 人以下の場合は一定時間経過したらその人数でゲーム開始、となるようなロジックを実装しました。
また、open-match-core で使う Redis には別途構築した Amazon ElastiCache を利用するように、Helm でのインストール時に values を適用しています。
helm install open-match --create-namespace --namespace open-match open-match/open-match -f ./om-values.yamlom-values.yaml
open-match-core:
redis:
enabled: false
hostname: xxxxxxxxxxxxxxxxxx.apne1.cache.amazonaws.com.OpenMatch のコンポーネントは、frontend、match-function、director と 3 つありますが、frontend はクライアントアプリからの接続を受け付けるため、Ingress で Application Load Balancer を構成しています。
“Find The Icon” のインフラ対応について
こんにちは、ソリューションアーキテクトの瀧田 直斗です。
ここからは Agones と Karpenter にどのような設定をしていたかご紹介します。
EKS / Karpenter について
EKS についてはデフォルトの状態から特別なカスタマイズをしておらず、 Agones で利用する Balancer で利用する AWS Load Balancer Controller を追加で入れています。
AWS Load Balancer Controller »
Karpenter については以下の公式ドキュメントに従って構築しています。
Karpenter Doc - Getting Started - Getting Started with Karpenter »
Karpenter の NodePool 、 EC2NodeClass は以下のようなマニフェストで始めました。
実際のアイコン探しゲームに合わせて設定していますが後ほど触れさせていただきます。
・NodePool / EC2NodeClass のマニフェスト
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
- key: kubernetes.io/os
operator: In
values: ["linux"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot","on-demand"]
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["t"]
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values: ["2"]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
expireAfter: 720h
limits:
cpu: 1000
memory: 1000Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1m
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2
role: "KarpenterNodeRole-aws-summit2024-demo"
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "aws-summit2024-demo"
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "aws-summit2024-demo"
amiSelectorTerms:
- id: "ami-040ee8c09934347b0"Karpenter の基本的な動作確認も簡単で Resource を EKS Node が足りなくなるように設定しスケールさせて実際に Karpenter が Node をプロビジョニングしてくれるかテストをしました。
・テスト用の Deployment のマニフェスト
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 0
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1・テスト
Karpenter の controller のログを見ることでどのような動作をしているかを見ることができます。
また kubectl get nodeclaim や kubectl describe nodeclaim コマンドを利用することでステータスの確認をすることができます。
# 別ターミナルでnode数のwatch
watch -n 1 kubectl get nodes
# 別ターミナルでkarpenterのcontrollerのログの確認
kubectl logs -f -n kube-system -l app.kubernetes.io/name=karpenter -c controller
# deployment作成
kubectl apply -f karpenter-test.yaml
# replicasを変更していくつか試してみる
kubectl scale deployment inflate --replicas 5
# nodeclaimの詳細を確認
kubectl get nodeclaim
kubectl describe nodeclaimKarpenter をテストする環境を作成するのは非常に簡単なことがわかりました。
私は EKS や Kubernetes の知見はあったものの、 Karpenter の知見はありませんでしたが構築からテストを行うまで一時間程度でできたのを覚えています。
また、 Node の状態を kubectl を使って確認できるのは開発者体験として結構良いと感じていました。
Agones について
Agones 環境も公式ドキュメントにそって構築しており、Agones 自体に特別なカスタマイズはしていませんが Agones で利用する LoadBalancer は、aws-load-balancer-controller を利用しています。これにより Agones の Allocator はデフォルトで NLB で構成されます。
Agones - Documentation - Installation - Install Agones - Helm »
Agones の基本的な動作を確認するために、 FleetAutoscaler の bufferSize を変更して Gamerserver を ALLOCATE します。そして定義した bufferSize の Ready 状態の Gamerserver ができることを確認します。
・(参考) FleetAutoscaler のマニフェスト
bufferSize を変更。
apiVersion: autoscaling.agones.dev/v1
kind: FleetAutoscaler
metadata:
name: simple-game-server-autoscaler
spec:
fleetName: simple-game-server
policy:
type: Buffer
buffer:
bufferSize: 2
minReplicas: 0
maxReplicas: 10Agones もテストする環境を作成するのは非常に簡単なことがわかりました。
Agones 自体の知見もありませんでしたがこのテストを行うまでも一時間程度でできたのを覚えています。 Karpenter の構築と合わせても二時間程度だったことを覚えています。
Karpenter と Agones の統合
Karpenter と Agones を統合するまでに特別な設定は不要でした。
Agones は FleetAutoscaler の bufferSize の定義に従って Gamerserver の Pod を作成します。この時デプロイ先の Node のリソースに空きがないときは Pending 状態になりまが Karpenter はすぐに Pending 状態を確認して、必要な EC2 Node の Provisioning を始めます。今回の環境では実際に Karpenter が Node を選定するまでは数秒程度、 Node が Ready 状態で EKS に組み込まれるまで 40~50 秒程度となっており、非常に早いと感じました。
簡単に Karpenter と Agones の統合できてしまったことに驚いたことを覚えています。
GameBooth の主なカスタマイズ
今回のアイコン探しゲームでは Booth に来ていただいた方のスマホの Web ブラウザで対戦を行う形式のため、 Web ブラウザと Agones の Gamerserver が WebSocket Secure で接続する必要がありました。
カスタマイズとしては接続先の Gamerserver は起動している Pod が動作している Node のポートを利用するため、 Karpenter が起動する Node を Public Subnet に配置すること、そして起動と同時に Route53 に登録し名前解決を行う必要があります。
今回は EC2 の UserData を使って、 Node の起動時に Amazon Route53 を登録するという選択肢を取ることにしました。 Karpenter では EC2NodeClass の定義で UserData を扱うことができます。何度も変更してテストをしていたのですが、 kubectl apply で確認が簡単にできたので実はここでも Karpenter の開発体験の良さが出てきます。
Karpenter Doc - Concepts - NodeClasses - spec.userData »
最終的は以下のような EC2NodeClass の定義としました。
事前にドメインの取得と、 Route53 へのゾーン登録をしたドメイン名とゾーン ID 後ベタ書きではありますが、 UserData を kubernetes のマニフェストという形で扱うことができ、なんてテストがしやすいんだと思ったことを覚えています。
・EC2NodeClass の定義
spec.subnetSelectorTerms の tags に kubernetes.io/role/elb: "1" を設定することで Public Subnet で Node を起動しています。 userData を使い、起動時に Node の PublicIP アドレスを取得し Route53 に登録しています。
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2
role: "KarpenterNodeRole-aws-summit2024-demo"
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "aws-summit2024-demo"
kubernetes.io/role/elb: "1"
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "aws-summit2024-demo"
amiSelectorTerms:
- id: "ami-040ee8c09934347b0"
userData: |
#!/bin/bash
yum install -y aws-cli
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
PUBLIC_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/public-ipv4)
if [ -z "$PUBLIC_IP" ]; then
echo "No public IP assigned to this instance."
exit 1
fi
PUBLIC_HOSTNAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/public-hostname)
HOSTED_ZONE_DOMAIN={※ドメイン名を記載}
RECORD_NAME=$(echo $PUBLIC_HOSTNAME | cut -d '.' -f 1).${HOSTED_ZONE_DOMAIN}
HOSTED_ZONE_ID={※Route53のゾーンIDを記載}
cat <<EOF > /tmp/route53.json
{
"Comment": "Add record for new instance",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "${RECORD_NAME}",
"Type": "A",
"TTL": 300,
"ResourceRecords": [{ "Value": "${PUBLIC_IP}" }]
}
}
]
}
EOF
aws route53 change-resource-record-sets --hosted-zone-id ${HOSTED_ZONE_ID} --change-batch file:///tmp/route53.jsonKarpenter と Agones を統合するのは非常に簡単であり、特別な設定をほとんどしていません。
また、 Karpenter のリソースは Kubernetes の Custom Resource で定義されているため今回のようなカスタマイズでも kubectl コマンドで簡単にテストする事ができました。
当日の GameBooth の対応
Karpenter の開発体験の良さや Agones と Karpenter の統合の容易さが伝わって来たのではないでしょうか ?
実際当日の GameBooth では来場者に合わせた対応として Agones の Fleet Autoscaler の BufferSize を 100 から 200 へ変更して kubectl apply コマンドを実行しただけです。 EC2 Node の Provisioning は来場者の方がゲームを遊んでくれている状況に合わせて Karpenter が適切な Node の選定と Provisioning を自動でやってくれているので特に何も対応していません。
インフラ運用に気を取られることなく私自信も来場者の方とアイコン探しゲームでしっかりと遊びました。
画像をクリックすると拡大します
AWS アイコン探しゲーム開発の裏側のお話は以上です。
脱出ゲーム 「密室」 AWS からの脱出について
こんにちは、ソリューションアーキテクトの秋山 周平です。
冒頭でご紹介の通り、AWS Summit Japan 2024 では複数のゲームを展示していました。ここからはそのうちの一つである脱出ゲームについて簡単に紹介します。
ゲーム概要
ゲームジャンルは脱出ゲームですが、通常の脱出ゲームと異なる点として、脱出をサポートする役割の人物がゲーム内に存在します。その人物とのやりとりの裏側に RAG (Retrieval-Augmented Generation) を使った応答の仕組みを取り入れている点が特徴です。
動機としては、直近のホットトピックである RAG をインゲームの体験に組み込んでみることは可能か、可能な場合どういったメリットデメリットがあるかについて詳しくなりたかったからです。ゲームを作るにあたって、RAG ありきでゲームを作るため、まずは RAG の特性からゲーム性を抽出できないか ? という点を考えました。
RAG は検索などによって、モデルのパラメータに含められない大量のデータから一部の情報を引き出し、それをプロンプトに含めることが特徴だと思います。そのため、「大量のデータから情報を引き出す」という手続きとゲーム性を結びつけることができれば RAG を使ったゲームと言えると思います。
しかし、少しずつユーザーに情報を開示していくことはゲームの面白さの一つのため、検索次第で全てが明らかになってしまう RAG とは相性が悪いことが想定されました。そのため、あえて検索では見つかりにい語句を答えとし、ゲームを進めることで検索に有効な語句を集めることでゲームの進捗が進む仕様としました。
アーキテクチャとポイント
構成図はこのようになっています。以下の点が工夫したポイントとなります。
- Amazon CloudFront によるエッジでのゲーム配信
WebGL 製のゲームでは配信アセットサイズが大きくなりがちで、なるべく端末に近いところで配信することが望ましいと思います。Amazon CloudFront の POP は日本にも多数存在し、安定した配信が可能なことから要件に適していると思います。 - AWS CDK / AWS SAM によるインフラストラクチャ管理
今回アーキテクチャにおいて変更が多い部分は、Amazon CloudFront から配信する Unity 製のゲーム本体と、プロンプトを定義している AWS Lambda 関数です。 AWS CDK を活用することで IaC の一般的なメリットを享受でき、更に AWS SAM の活用により Lambda 関数の更新と実行をローカルで実現できるため、開発速度を高速化することができました。 - 速度差のある 2 種類の Bedrock モデルを利用
応答の生成の際には、まず検索を行い取得したデータをプロンプトに注入した後回答を生成するため、全体の手続の数に加えて、プロンプト長が長くなることによる応答時間が課題となると予想できました。加えて、AWS Summit Japan での展示当時は Claude 3 が日本リージョンで提供前であったため距離によるレイテンシーも懸念がありました。そのため、東京リージョンの Claude2 Instant で先に一次応答を行うことで、ユーザー体験の向上を図りました。 - 開発速度を優先し Amazon Kendra を採用
今回は資料の投入から検索までの手続きが一番簡単な Kendra を採用しました。 Agents for Amazon Bedrock も検討しましたが、内部で複数のモデルを応答の生成に利用していることから、応答に時間がかかるため採用しませんでした。
当日のブース対応とコストを意識したアーキテクチャ
当日のブースでは来場者に遊んでいただきましたが、当初の想定通り、すんなりとクリアされる方は少なかった印象です。生成 AI の出力の揺らぎの制御についてはまだ課題が多く、プレイヤーの質問に対して異なる回答をすることも時々見られました。この点は、誤答を許すようなゲーム設計とするか、アーキテクチャやプロンプトの工夫で精度を上げるかいずれかの対応が必要になる課題かと思います。
一部の来場者の方とはコスト観点の議論をしました。今回のように RAG のデータとして使いたい資料が少ない場合は、Kendra を使わないことや、応答として生成したい文章のパターンが少ない場合は応答をキャッシュすることはコスト削減につながります。実装に時間がかかりますが、ベクトル検索エンジンと Embedding されたデータをコンテナイメージに格納することで、Lambda コンテナのみで検索部分を完結できると大幅なコスト削減ができそうです。以下に参考アーキテクチャを記述します。
まとめ
本記事では、AWS Summit Japan 2024 のゲーム業界のお客様向けブースにて展示したゲームのうち、Agones / OpenMatch / Karpenter を Amazon EKS 上で利用して構築したマルチプレイヤー対応のデモゲームである AWS アイコン探しゲーム “Find The Icon” と、生成 AI の RAG 構成をゲーム性に採り入れた脱出ゲームである “密室「AWS」からの脱出” の 2 本について、構成や開発時の思い・体験談も含めてご紹介しました。前者については、先月の記事「Agones on Amazon EKS で構築するマルチプレイゲームの専用ゲームサーバー」と合わせてお読みいただくことで、Karpenter も含めてより理解を深めていただけると思います。
今回のデモゲームのような小さなものでも、新しい技術の特性をつかんでゲーム企画や開発に活かす素地とするには十分有用です。本記事が、マルチプレイのゲーム開発や生成 AI の活用を視野に入れられている皆様の一助になれば幸いです !
筆者プロフィール
西坂 信哉
アマゾン ウェブ サービス ジャパン合同会社
ゲームソリューションアーキテクト
SIer のインフラエンジニアを経て 2019 年にアマゾンウェブサービスジャパン合同会社に入社。現在は主にゲーム業界のお客様の技術支援を担当しています。
二児の父として育児奮闘中。ときどきアフタヌーンティーに出かけます。
瀧田 直斗 (たきた なおと)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
前職では 10 年以上オンプレミスの運用に従事。
現在は、業種・規模を問わず幅広いお客様に対して技術的な側面からビジネスを支援行う。
自宅のサーバーで kubernetes を飼っています。
秋山周平
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部
ソリューションアーキテクト
以前は AWS サポートにて広範のお客様をご支援していました。現在は特にゲーム業界のお客様に対して、ソリューションアーキテクトとして技術的なご支援をしています。
好きなサービスは Amazon GameLift と Amazon Cognito。週末は大自然の中にいます。
AWS を無料でお試しいただけます