スケーラブルなゲームサーバーを支えるサービスディスカバリ

スケーラブルなゲームサーバーを 支えるサービスディスカバリ とうとう (X: @__tou__tou) ・ 基盤エンジニア

ゲームサーバーは全プレイヤーの状態を1台で同期する マルチプレイゲームにおいて、1台のゲームサーバー上で１セッション（１部屋）を管理するケース を考えます。１台のゲームサーバー上で全プレイヤーの位置や行動を集約し、各クライアントへ配 信して同期します。 2

クライアントはどのゲームサーバーに接続するのか? 数千人規模の同時接続は、1台のサーバーでは処理できません。 サーバー台数を増やすことで負荷を分散する必要があります。 このとき、クライアントは「どの１台のサーバーに接続するか」を知っておく必要があります。 3

サービスディスカバリ 4

サービスディスカバリで接続先を決める クライアントが接続先を自動的に発見する仕組みを、サービスディスカバリと呼びます。 クライアントはサービスディスカバリに問い合わせ、接続先のIPアドレスを受け取ります。 全ゲームサーバーのIPアドレスは、サービスレジストリに登録されています。 5

ゲームサーバーは起動時にIPアドレスを登録する ゲームサーバーの台数とIPアドレスは、増設・再起動・障害のたびに変わります。 そのため、ゲームサーバーは起動時に自分からIPアドレスを登録します。 6

接続の流れ クライアントはサービスディスカバリに接続先を問い合わせ、IPアドレスを受け取ります。 以後は受け取ったIPアドレスのゲームサーバーと直接通信します。サービスディスカバリは通信 経路に入りません。 7

稼働中のサーバーだけが接続先の候補に残る サーバーが稼働中であることを保証するため、ハートビートやヘルスチェックの仕組みがありま す。 ハートビート（≒keep-alive）は、ゲームサーバーが自分から生存を通知する方式です。 逆に、サービスディスカバリ側からゲームサーバーを確認する方式はヘルスチェックと呼ばれる ことが多いです。 8

スケーラブルなゲームサーバーの実現 9

スケーラブルなゲームサーバーの実現 クライアントの接続要求は、スケールアウトしたゲームサーバーへ適切に割り振られます。 サービスディスカバリ自体も、サービスレジストリを共有したまま台数を増やせます。 10

スケールインは登録解除してから停止する サーバーコスト削減には、不要になったサーバーを停止するスケールインが必要です。 ただし、突然の停止は接続中のクライアントを部屋から追い出してしまいます。 そのため、まずはゲームサーバーの登録解除を実施し、既存接続は維持しつつ新規接続を防ぎま す。 11

接続がゼロになってから停止する 時間経過で接続数がゼロになったらサーバーを停止します。 クライアントに影響を与えずに安全に、サーバー台数とコストを減らせます。 この一連の手順はドレイン（draining）と呼ばれます。 12

サービスディスカバリが使われている身近な例 サービスディスカバリに当たる部分 接続先の決め方 AWS ELB ロードバランサ ヘルスチェックで稼働中のインスタンスだけに振り分ける Kubernetes Service サービス名の名前解決（DNS） 稼働中のPodに振り分ける Agones（Kubernetes上のOSS） ゲームサーバーの割り当てAPI 割り当てたサーバーのIPアドレスとポートを返す ゲームもWebも、スケールするサーバーはこの仕組みが支えています。 出典: Agones Overview ／ Kubernetes: Service ／ Elastic Load Balancing とは 13

• https://agones.dev/site/docs/overview/
• https://kubernetes.io/docs/concepts/services-networking/service/
• https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html

まとめ 14

まとめ：サービスディスカバリ 接続先は、クライアントが接続時にサービスディスカバリへ問い合わせて決まる。IPアドレス はサービスレジストリに保存 ゲームサーバーは起動時に登録、ハートビートが途絶えると登録解除。稼働中のサーバー だけが接続先の候補に残る 15