AWS Summit Japan 面白かったブースまとめ

# はじめに
 こんにちは、H×Hのセンリツ大好きエンジニアです。（同担OKです😉）
 2024年6月20日(木)、21日(金)に開催されたAWS Summit Japanで出会った面白いブースをまとめました！

 AWS初学者ということもあり、認識が間違っている可能性もあるのでその際は教えていただければ幸いです🥹

 # 面白かったブース一覧
 ### 『FINAL FANTASY VII EVER CRISIS』のマルチプレイサーバーに Amazon GameLift を採用。快適なプレイ体験を実現

 #### 内容
 株式会社アプリボットがリリースした『FINAL FANTASY VII』シリーズ最新作のスマートフォン向けタイトルである『FINAL FANTASY VII EVER CRISIS』のインフラ構築において、アマゾン ウェブサービス（AWS）のマネージドサービスを活用することで、運用負荷の低減や機能改善を実現した。
インフラ費用も、同社が提供する他のゲームタイトルと比較し2分の1まで抑えられている。

このゲームは、リリース時に数十万規模の同時接続を処理する必要がある＆プレイヤー同士がマッチングして同じバトルに参加する「マルチプレイ」機能が搭載されているため、どのように実現するか考える必要があった。

**アーキテクチャ**
![スクリーンショット 2024-06-23 10.46.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2653241/511ece18-ca25-d9e4-e064-378642d659b6.png)

ここでは、マルチプレイ時に稼働するBattle Serverとそれ以外のログインなどの機能を提供するGame Serverに分けられている。
Game Serverは一般的な構成になっているが、Battle Serverでは「Amazon GameLift」が使用されている。
これは、AWSが提供するマルチプレイゲーム用のクラウドサーバを管理するマネージドサービスであり、競合と比較して費用が抑えられるといったメリットがあったとのこと。

また、処理効率の向上やコスト削減の観点から、Amazon GameLift のフルマネージド機能である GameLift Hosting ではなく、運用の自由度が高く自社でのカスタマイズができる Amazon GameLift FleetIQ を採用しているらしい。
ユースケースに合わせて使い分けられることも要因の一つのようだ。

このような構成にすることで、リリース後3ヶ月時点でのインフラ起因の大規模障害はゼロという堅牢なインフラ環境となっているようだ。

#### 所感
大規模サービスのインフラ構成にはとても興味がありましたが、それに加えてマルチプレイゲームということで、どうなってるんだろうと気になってました。
Amazon GameLiftというサービスを初めて耳にしたのですが、マルチプレイ用のサーバとのことで具体的にインフラの中身がマルチプレイだとどう変わるのか気になりました。
大規模サービスでCloudFrontとALBくらいしか冗長化している風に見えなかったのですが、この構成で耐えられるのも驚きでした。

### Serverlesspresso バリスタの舞台裏

#### 内容
こちらのServerlesspressoは、スマートフォンからコーヒーの注文ができるサーバレスなサーービスである。
注文の流れとしては、
1. モニターに5分ごとに変わるQRコードが表示されるのでスキャンして注文を行う。QRコードは5分間で10杯まで利用でき、ドリンクがなくなると画面からQRコードが消える。
1. QRコードによって読み込まれたブラウザ上で注文を行う。バックエンドは注文を検証し、注文番号を作成して、バリスタがそれを利用する。
1. バリスタは注文がバリスタ側のアプリに表示されるのを確認し、注文のステータスを変更して、いま作成中か、いつ完了したか、または注文をキャンセルされたかをユーザに表示する。
1. スマートフォンですべてのバリスタによる注文状態の更新を確認できる。現地には大型のディスプレイが設置されており、現在注文されているオーダーや完成したコーヒーのステータスが表示されている。

**アーキテクチャ**
![スクリーンショット 2024-06-23 11.22.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2653241/90199e49-7bb1-404e-6067-42a769710d91.png)

スマートフォンからは注文管理API、モニターからはQRコード検証API、バリスタ端末からはドリンクのステータスを更新するAPIを叩いている。
検証処理や注文処理はLambdaで行わず、単にイベントをEventBridgeに送信するだけである。
EventBridgeで受け取ったイベントに応じてStep Functionsがそれぞれの処理ロジックとなるワークフローを実行している。

#### 所感
現地で注文してみたのですが、QRコードが発行されるたびに早い者勝ちみたいな感じで結構盛り上がってました！
![servelesspresso.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2653241/45c2ea03-6ce5-8064-b953-5a2715e46057.jpeg)

サーバレスでStep FunctionsとEventBridgeによるオーケストレーションとコレオグラフィを使用してイベント駆動の設計になっていたのでとても勉強になりました。
API Gatewayから直接イベントをEventBridge pipesを通じてEventBridgeに流せないのかなと気になりました。

### DMMオンクレのAmazon Kinesis Video Streams導入事例
#### 内容
DMMオンクレは、24時間いつでもインターネットからアクセスできて遊べるオンラインクレーンゲームである。オンライン上でクレーンを動かし、ゲットした景品は後日郵送されて送られてくる仕組みである。

**アーキテクチャ**
![dmm_onkure.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2653241/ce7a8f13-ac67-3100-e4e6-df9f53e1d219.jpeg)

仕組みとしては、クレーンゲームプレイ中は、1つのクレーンゲーム毎に2台設置されたカメラからAmazon Kinesis Video Streamsを伝って映像が送られてくる。プレイヤーが行うボタン操作は、クレーンに付与されているラズベリーパイで制御される。
1つのクレーンゲーム機に対してカメラ2台とクレーン1台の計3台にラズベリーパイが使用されており、それら全てのIoT機器をAWS IoT Coreで管理・監視している。
そのため、どの機器でエラーが発生しているかを特定することが可能になる。

また、ゲームの解析にはAmazon QuickSightを使用している。
これにより、どのゲームで景品が取りやすいかであったり、どのゲームが人気であるかをビジネスサイドからも把握できるようになる。
後は、セッション保持やリアルタイム性が重視される情報などの揮発性の情報に関してはAmazon ElastiCacheを使っており、DBの負荷を軽減しているとのこと。

#### 所感
DMMオンクレをやった事があったので、中身が一体どうなっているか気になっていましたが、ラズパイでの制御を行っているとのことと、全てのIoTデバイスを一元管理していることを知れてよかったです。
オンライン上からのラズパイでの制御はリアルタイム性が非常に求められるようで、少しでもズレるとユーザの意図しない動きになるのが課題のようですね。
更に同期を正確にする場合、どのようにすれば良いか気になりました。

# おわりに
今回は、個人的に面白かったブースを紹介しました！
他にもたくさんのブースがありどれも面白かったのですが、全てを紹介するのは大変なので厳選してどういうものか書いてみました！

こういうお祭りみたいなイベントがあると楽しいですね！
また行きたいと思いました（次までには何かしら資格欲しいですね🫣）

最後までご覧いただきありがとうございました！
以上、センリツでした。🤓