お久しぶりですCDSLの高木です.
みなさんはFortnite: Battle RoyaleやApex Legends, Warframeなどのビデオゲームをご存知でしょうか？(Apex楽しいですよね😇)今回はただプレイするだけでなく, どうやって動いているのかAWSのブログを参考に少し紹介したいと思います.
これら多くのビデオゲームでは，プレイヤーがゲームの一部に無料でアクセスできる「Free-to-Play(参考：wiki, NEXONブログ)」モデルを採用しています．このようなゲームは低品質を無料で提供しているわけではなく，今やプレミアムな品質を必要としています(その高品質ゆえプレイヤーが増えるわけですね)．その運用のためには，プレイヤーへの影響を最小限に抑え，コストを最適化するメカニズムが必要となります．AWSブログではゲームサーバーワークロード(参考：IT用語辞典)について触れていたので, その一部を抜粋しました．
マルチプレイヤーで行うゲームのサーバーは，現在のキャラクターの位置とアニメーションを更新していくのにほとんどの時間を費やします(下の画像でいうと, キャラクターが立っている位置座標の更新とキャラ操作です)．残りの時間は，戦闘に関するアクションや移動，その他ゲームイベントに関連する画像の更新に費やされます(下の画像でいうと，銃のエイム，リコイル制御，銃弾のエフェクト等です)．ゲームサーバのCPUはこのキャラクターの位置情報を取得，いろんな演算処理を行い，他のプレイヤーに送信するという処理を主に行っています．
このマルチプレイヤーゲームサーバの展開に，CDSLでも使っている人もいるKubernetesやSwarmといったコンテナベースのオーケストレーションによるデプロイというのも考えられます．コンテナは軽量で高速に起動し，インスタンスの使用率が向上するためワークロードに適しているそうです．
ゲームサーバはステートフル(参考：IT用語辞典)なワークロードなため，冗長性の無い１つだけの専用ゲームサーバインスタンスとして実行されます．複数のゲームサーバに対してトラフィックを分散させるようにロードバランサ―を使用するケースも多いようです．以下のアーキテクチャはAmazon EKSにおけるオンデマンド/スポットインスタンスを混在させたマルチプレイヤーゲームサーバのアーキテクチャです．１つのVPC(Virtual Private Cloud)では，マスターホストとストレージホストには高可用性(参考：IT用語辞典)が求められるためにオンデマンドインスタンスを利用しています．
マルチプレイヤー向けのゲームサーバは数分から数時間の間で持続し消失するプロセスで実装されています．この1つのプロセスに私たちは何度もインして遊んでいるわけですね．ゲーム中に「重いな」「これバグか？」と思ったら裏側を想像してみると面白いかもしれません. それではまた！