ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 これまでにも、「オンラインサポートチーム」や「AI活用促進チーム」などの社内活動を紹介してきました。今回は、中途採用の強化を目的に、ニフティのエンジニアの考え方や働き方などについて発信する「採用ブランディングワーキンググループ」の取り組みを紹介。メンバーたちに、具体的な活動内容を聞きました。 自己紹介 D.K.さん 2003年4月に新卒入社。所属部署での業務内容はWebサービスの開発、運用チームのマネージャー。採用ブランディングワーキンググループでの役割は「まとめ役」。趣味は老舗の甘味屋巡り。 K.R.さん 2025年5月に中途入社。所属部署での業務内容はオプションサービス（セキュリティサービスなど）の開発、運用。採用ブランディングワーキンググループでの役割はエンジニアブログの運営。趣味はバレエ鑑賞。 S.H.さん 2024年4月 に新卒入社。所属部署での業務内容は自社コールセンターのシステム運用・開発。採用ブランディングワーキンググループでの役割は社外イベントへの参加促進。趣味は料理とプログラミング。 S.S.さん 2023年3月 に中途入社。所属部署での業務内容は「@nifty auひかり」申込システムの開発運用。採用ブランディングワーキンググループでの役割は新規企画の立案実行。趣味はボードゲーム、テニス。 ニフティのエンジニアが持つ知見や技術、考え方を発信し、転職市場で選ばれる会社に みなさんはそれぞれの所属部署での業務とは別に、チーム外活動として「採用ブランディングワーキンググループ（以下、採用WG）」にも参加されているとお聞きしました。はじめに、所属部署と採用WGでの役割を教えてください。 D.K.さん 所属部署では、ニフティのWEBサービスの開発や運用をするチームでマネージャーをしています。採用WGには立ち上げ時から関わっていて、現在は取りまとめ役としてメンバーの活動をサポートするのが主な役割ですね。 K.R.さん 普段はサービスシステムグループという部署に所属し、オプションサービス（セキュリティサービスなど）の開発、運用に携わっています。採用WGでの役割は、『NIFTY engineering』というブログの運営。このインタビュー記事もまさにそうですが、ニフティ社員の様々な活動を発信しています。 S.H.さん 所属部署での業務内容は、自社コールセンターのシステム運用・開発です。採用WGでは、ニフティのエンジニアの認知を上げる活動を行っていて、特に力を入れているのは、社外で開催されているイベントへ社内のエンジニアに参加してもらうための呼びかけやサポートです。 S.S.さん 普段は「@nifty auひかり」という回線サービスの申込システムの開発、運用に携わっています。採用WGでの役割は新規企画の立案と実行。採用強化につながる新しい施策を考え、実践していくのが主な活動ですね。 ありがとうございます。そもそも、この採用WGはどのような目的で発足したのでしょうか？ D.K.さん ニフティってもともと新卒入社の割合が多い会社なのですが、全社的に開発力や組織力を底上げしてくためには新卒だけでなく、力のあるエンジニアの中途採用にも力を入れていくべきだろうという話が、数年前から持ち上がっていました。 そのためには、改めてニフティという会社が何をやっているのか、社内のエンジニアがどんな仕事をしているのか、広く周知する必要がある。当時の私の上長がそんなアイデアを持っていて、有志を中心に採用WGが立ち上がり、活動がスタートしたのが4年ほど前ですね。 ただ、D.K.さんを含む発起人のメンバーは、採用まわりのご担当ではなかったんですよね。 D.K.さん そうですね。開発の部署になります。ただ、エンジニアの採用に関して、細かい技術のことを知っている開発の人間が協力するのは不自然なことではないのかなと思います。私自身も、「どんな人材が増えると、よりよい組織になるのか」「そのためにニフティという会社や働き方、技術などをいかにブランディングすべきか」といったことに関心がありましたので、ぜひ参加したいと手を挙げました。 社内のエンジニアが寄稿する「Tech Book」で技術力をアピール あらためて、採用WGの具体的な活動内容について教えてください。 D.K.さん 20人ほどのメンバーが、複数のサブチームに分かれています。ここにいるメンバーもそれぞれ別々のサブチームに所属していて、基本的にはチームごとの活動。週1回は全体で集まる場を設けて、各チームの活動報告や、現状の課題について話し合っています。 S.S.さんは「新規企画チーム」、K.R.さんは「ブログチーム」、S.H.さんは「イベント参加促進チーム」で活動されているということですが、これまでに関わった印象深いプロジェクトを教えてください。 S.S.さん 私が印象深いのは、『Nifty Tech Book #2』という技術書を作ったことですね。ニフティのエンジニアたちに「書きたい！」と思ったことを自由に執筆してもらった技術書で、イベントの際などに無料配布しています。もともと、私が採用WGに参加した当初からやりたかったプロジェクトなので、完成した時は達成感がありましたね。 こちら、総ページ数が144ページにも上ります。本業の傍ら、これだけボリュームのある技術書を作るのはかなり大変だったのではないですか？ S.S.さん 制作当時は、かなりの時間と労力を割いていました。ただ、#2とあるように、じつは2冊目のテックブックになります。以前に別の方が『Nifty Tech Book #1』を作っていて、当時のノウハウやシステムが残っていたので、それをうまく活用することで効率よく進めることができました。 執筆者は社員の中から募集して、私は主に原稿のレビューや印刷の手配などを担当しています。 イベントなどで配布されているということですが、反響はいかがですか？ S.S.さん イベントで配布した際には、「ニフティの回線使っていますよ」といった嬉しい反応を多くいただきました。技術書としても面白い内容になっていると思いますが、ニフティという会社自体を改めて認知していただく効果も、一定程度はあるのかなと感じます。 あとは、社内の新卒採用の場面でも活用されているようで、例えば、大学訪問の際に教授にこの本を渡して、学生に読んでもらったり、つい最近も中途入社の方から「転職活動中にこのTech Bookを読んで、ニフティに興味を持ちました」という声をいただいたりもして、とても嬉しかったですね。 S.H.さん 私の同期も寄稿しているのですが、内容的にも普通にお金を取っていいくらいレベルが高い技術書になっていると感じました。この本を通じて、ニフティのエンジニアが持つ技術、レベルの高さを知っていただけるのではないかと思います。 D.K.さん 採用WGがスタートした当初はブログだけで情報発信していて、本という発想は全くなかったんです。そもそも本業を抱えながらやるには、労力がかかりすぎるため、無理だろうと思っていました。ただ、そのめちゃくちゃ大変なことにS.H.さんはチャレンジして、実際に形にしてくれた。純粋にすごいと思いますし、それくらい熱心に活動してくれているのが嬉しいですね。 ニフティのエンジニアが「社外イベント」に参加しやすい環境をつくる K.R.さんはブログの運営をご担当されていると。 K.R.さん はい。具体的には、ブログの見栄えや使い勝手を良くしたり、コンスタントに記事が投稿されるような施策を実施しています。例えば、新入社員の方にリレー形式で記事を書いてもらったり、クリスマスの時期にAdvent Calendarというテーマを立ててブログの執筆者を募ったりと、色んな企画を行ってきました。 K.R.さんはブログの運営をご担当されていると。 K.R.さん ニフティの採用サイトにも社員にインタビューした記事はあるのですが、チームでの活動にスポットを当てた記事があってもいいんじゃないかということでスタートしました。チームの考え方や、目的意識、リアルな仕事の進め方を見せることで、入社後の働き方のイメージがより湧くのではないかと。そういう私自身も、入社前に別チームのインタビュー記事を読んでいて、ニフティでの仕事により興味が湧きました。 K.R.さんはこれまでの活動で印象に残っていること、あるいは印象に残っている記事はありますか？ K.R.さん やはり記事がバズった時は印象に残るというか、素直に嬉しいです。最近では、Advent Calendarの「ファミコンのソフトを作る。Rustで。」という記事がよく読まれました。 あとは新人さんに記事を書いてもらうこともあるのですが、クオリティの高さに驚かされます。私が読んでも普通に勉強になることが多くて、読者として楽しませてもらっています。 ＜関連記事＞ ・ファミコンのソフトを作る。Rustで。 ファミコンのソフトを作る。Rust で。 では、S.H.さんはいかがですか？　S.H.さんのチームではニフティのエンジニアが社外イベントに参加しやすいよう、サポートを行っているということでしたよね。 S.H.さん そうですね。ニフティではこれまで自社イベントを積極的に開催してきた一方で、社外イベントへの参加促進にはあまり力を入れてきませんでした。そこで、注目度の高い社外イベントにどんどん参加し、会社のことやエンジニアの考え方を発信していくことで、ニフティに関心を持ってもらおうと考え、昨年からその後押しになるような取り組みを強化しています。 具体的に、どんな取り組みを？ S.H.さん まず、そもそも社外イベントに関心を持っている、参加したいと思っている社員がどれくらいいるのかを知るためにアンケートを取りました。すると、8割くらいが関心を持っていると。 かなりの割合ですね。 S.H.さん 私たちも正直驚きました。ただ、関心はあっても、「イベントの準備をする時間が取れない」「自分に合うイベントが分からない」「参加にあたって、社内申請や手続きの方法が分からない」といった課題を感じていることが分かったんです。 こうした課題をふまえ、申請のフローを明確化したり、登壇資料の作成をお手伝いしたり、その方に合いそうなイベントを紹介したりと、少しでも障壁を減らすためのサポートを行っています。 ちなみに、これまでどんなイベントに、社内のエンジニアが登壇してきたのでしょうか？ S.H.さん ニフティも協賛しているSRE NEXTというカンファレンスのセッションに、社内のエンジニアも登壇してもらいました。ちょうどSRに関する活動をしている社員がいて、こちらから参加をお願いして実現した事例ですね。 D.K.さん 社外イベントへの参加促進に関してはまだ取り組みが始まったばかりですので、これからどんどん数を増やしていきたいと思っています。いきなり「登壇しませんか？」と言ってもハードルが高いと思いますので、まずは観る側・聞く側として気軽に参加してもらうことが大事です。実際、社内のイベント参加記録を見ても、採用WGが強化の取り組みを始めてから参加者が増えていますので、少しずつ成果が出始めていると感じますね。 後編に続きます！ 今回はニフティの採用ブランディングワーキンググループのインタビューの様子をお届けしました。後編の記事は近日公開予定です。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

はじめに リアルタイム性の高いマルチプレイヤーゲームは、複数のプレイヤーの入力を集約し、ゲームの状態を一貫させて全員へ配信する仕組みを必要とします。この仕組みの一つに、権威あるサーバーがゲームの状態を管理する専用ゲームサーバー (Dedicated Game Server) 方式があります。対戦の公平性やチート対策、多人数の同時接続が求められるタイトルでは、専用ゲームサーバー方式が広く採られています。この方式では、マッチメイキング、ゲームサーバーの割り当て、セッション終了後のサーバー回収といったライフサイクル管理が必要になり、そのオーケストレーション基盤をどう構築・運用するかが設計上の大きなテーマとなります。 AWS で専用ゲームサーバーをホストする主な選択肢は、マネージドサービスの Amazon GameLift Servers を利用するか、 Amazon Elastic Compute Cloud (EC2) や Amazon Elastic Container Service (ECS) 、 Amazon Elastic Kubernetes Service (EKS) 上でセルフホストするかの 2 つです。GameLift Servers はインフラ構築・運用の大部分を担いますが、要件によってはより柔軟な制御が必要な場合があり、 Agones の利用が選択肢の一つとなります。Agones はオープンソースの専用ゲームサーバーホスティング向け製品で、Amazon EKS 上にデプロイでき、柔軟性を享受しつつ専用ゲームサーバーの構成を簡素化できます。しかし Kubernetes 基盤の運用は避けられず、Agones の運用には一定の負荷が存在しました。 2024 年 12 月に一般提供が始まった Amazon EKS Auto Mode は、Kubernetes の構築・運用負担を低減する機能です。Agones の基盤となる EKS クラスタで EKS Auto Mode を利用できれば、専用ゲームサーバーを柔軟かつ簡素に構築・運用できます。ただし EKS Auto Mode にはいくつかの制約もあります。 本記事では、EKS Auto Mode の制約が Agones の特性を阻害しないようにするための設計方針を紹介します。 Agones リソースの概要 本記事の内容に関連する Agones カスタムリソースについて説明します。 GameServer： プレイヤーが接続するゲームサーバープログラムが動作する Pod にあたるリソースです。状態を持ち、Ready 状態はゲーム開始可能で待機している状態、Allocated 状態はゲームプレイのためにリソースが確保された状態を表します。 Fleet： GameServer のまとまりを管理するためのリソースです。常に起動しておくべき GameServer リソースの数を指定でき、Fleet Autoscaler リソースによるスケーリング制御も可能です。 GameServer Allocation： ゲームプレイのために GameServer リソースを選択し確保する操作を行うリソースです。この操作により選択された GameServer リソースは Ready 状態から Allocated 状態となります。 コントローラ系リソース： Agones の機能を実現・制御するためのリソース群です。 EKS Auto Mode と Agones の共存における課題 EKS Auto Mode は、クラスタのノード管理を AWS の責任範囲で自動化します。例えば Karpenter をベースとしたノードのプロビジョニング・スケーリング・入れ替え、Bottlerocket による最適化された OS、各種アドオンのマネージド管理といった機能により、Kubernetes の運用を大幅に簡素化できます。 一方、ユーザー側で設定できる範囲が狭まるというトレードオフがあります。Agones の基盤として特に考慮が必要なのは、EKS Auto Mode が以下の目的のために自動で行うノードの中断です。 Consolidation： 稼働中の Pod が少ないノードを終了し、利用率の高いノードへ Pod を集約してコストを最適化する。 Drift： NodePool や NodeClass の設定変更、AMI の更新などに追従してノードを入れ替える。 Expiration： セキュリティ維持のため、一定期間が経過したノードを強制的に入れ替える。 Interruption： Spot Instance の中断通知やハードウェア障害などに応じてノードを終了する。 ※EKS Auto Mode の長期実行ワークロードでの扱いについては、builders.flash 記事「 Amazon EKS Auto Mode のノード自動更新を Deep Dive する 」もあわせて参照ください。 いずれの中断でも、対象ノード上の Pod へ SIGTERM が発行されます。Agones上で動かすような専用ゲームサーバーには「プレイ中のゲームセッションを中断させない」という強い制約があるため、対策をしないとプレイ中のゲームサーバーが強制終了されるリスクがあります。 EKS Auto Mode と Agones を共存させる設定のポイント そこで、Agones のコントローラ系とゲームプレイ中のサーバープログラムをノードの中断から保護する仕組みを、次の 6 つのポイントで構成します。以降、それぞれのポイントについて、実際の設定ファイル ( nodepools.yaml / fleet.yaml / agones-values.yaml ) を引用しながら、具体的な実装方法を説明します。 Point # 対象 内容 Point 1 共通 NodePool の expireAfter 、 terminationGracePeriod を適切に設定する Point 2 GameServer GameServer の Pod の terminationGracePeriodSeconds をゲームの最大持続時間より長い値に設定する Point 3 GameServer GameServer 上で動くサーバーアプリで、適切なシグナルハンドリングを実装する Point 4 GameServer Eviction を許可してノードの自動最適化を機能させる ( spec.eviction.safe: Always ) Point 5 コントローラ系 Agones コントローラ系と GameServer が配置される NodePool を分ける Point 6 コントローラ系 agones-allocator と agones-ping の PDB を有効にする Point 1 (共通) ：NodePool の expireAfter / terminationGracePeriod を適切に設定する EKS Auto Mode では、ノードは必ずいつか中断されます。特に Expiration はノード生存期間最大21日の制約があり、必ず発生します。この expireAfter の値と、ノードが強制的に中断されるまでの猶予期間である terminationGracePeriod を、ワークロード特性に合わせて NodePool に設定することが起点になります。 NodePool とは、Karpenter ベースのノード管理機能で、Pod の要求に応じてインスタンスを自動的にプロビジョニング・スケーリングし、クラスターのコンピュートリソースを柔軟に管理するための仕組みです。 設定にあたっては、次の関係を守るようにしてください。 terminationGracePeriod は、後述する Pod の terminationGracePeriodSeconds より長く設定する (ノードが強制削除される前に、Pod が Graceful に終了しきるようにするため) 。 expireAfter + terminationGracePeriod の合計は最大 21 日に収める (EKS Auto Mode の制約) 。 また disruption.budgets の nodes: "10%" （NodePool Disruption Budgets: NDB）により、同時に中断処理へ入るノード数を全体の 10 % に制限し、一斉中断の影響を抑えます。 consolidationPolicy: WhenEmpty については Point 4 で触れます。 Point 1 を踏まえた NodePool の設定例は次の通りです（ nodepools.yaml ）。 # GameServer 用 NodePool apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: agones-worker spec: template: spec: # Point 1: ゲームセッション時間を考慮して設定 # terminationGracePeriod は Pod の terminationGracePeriodSeconds より長くすること expireAfter: 336h # 14日 terminationGracePeriod: 4h # expireAfter + terminationGracePeriod が21日(504h)に収まるように disruption: consolidationPolicy: WhenEmpty consolidateAfter: 30s budgets: - nodes: "10%" Point 2（GameServer）：Pod の terminationGracePeriodSeconds をゲーム最大持続時間より長く設定する ノードが中断され Pod に SIGTERM が発行されてから、Pod が強制終了（SIGKILL）されるまでの猶予が terminationGracePeriodSeconds です。この値をゲームの最大持続時間より長く設定することで、進行中のゲームが途中で強制終了されることを防ぎます。 terminationGracePeriodSeconds は Pod リソースの設定値ですが、Agones では GameServer リソース定義内で設定することになります。また GameServer の制御は Fleet で行うことが一般的なため、ここでは Fleet の設定例を次の通り示します ( fleet.yaml ) apiVersion: "agones.dev/v1" kind: Fleet metadata: name: simple-game-server-fleet spec: replicas: 3 template: spec: # ... (省略) template: spec: # Point 2: ゲームセッション最大持続時間 + バッファより長い値を設定 # 例: ゲーム最大30min + クリーンアップ5min = 35min = 2100sec terminationGracePeriodSeconds: 2100 ゲームセッション 1 つの最大持続時間に、クリーンアップ処理のバッファを加えた値を設定します。Point 1 の terminationGracePeriod (ノード側の猶予) を、この terminationGracePeriodSeconds (Pod 側の猶予) より長く設定することで、 terminationGracePeriod > terminationGracePeriodSeconds > ゲーム最大持続時間 の関係が成立し、プレイ中のゲームを保護できます。 まとめると、 以下を満たすように各パラメータを設定すればよいことになります。 NodePool の terminationGracePeriod > Pod の terminationGracePeriodSeconds > ゲームの最大持続時間 NodePool の expireAfter は自由 ( terminationGracePeriod との合計は 21 日以下) Point 3 (GameServer) ：適切なシグナルハンドリングを実装する Point 1・2 で猶予期間を確保しても、SIGTERM を受け取ったサーバープログラムが適切に振る舞わなければ、ゲームサーバーは安全に終了できません。GameServer 上で動くサーバープログラムでは、SIGTERM を受信したときに次の動作を実装します。 Allocated 状態 (ゲーム進行中) ：進行中のゲームの終了を待ち、クリーンアップ処理を行った後に Agones SDK の sdk.Shutdown() を呼び出す。 Ready 状態 (待機中) ：新規 Allocation を防ぐため、即時 sdk.Shutdown() を呼び出す。 この実装により、ノード中断のシグナルを受けても、進行中のゲームを守りつつ、待機中のサーバーは速やかに退去できます。 Point 4 (GameServer) ：Eviction を許可してノードの自動最適化を機能させる ( spec.eviction.safe: Always ) Point 1〜3 でプレイ中のゲームを保護できたら、次に Agones の spec.eviction.safe を Always に設定し、EKS Auto Mode によるノードの自動最適化を機能させます ( fleet.yaml ) 。 spec: template: spec: # Point 4: eviction.safe を Always に設定 # Karpenter の Drift/Consolidation/Expiration 時に Graceful な Eviction を許可する eviction: safe: Always spec.eviction.safe は、各 GameServer の Pod に対して Agones が内部的に作成する PDB ( maxUnavailable: 0% ) を有効化するかどうかを制御します。デフォルトの Never の場合、常に eviction をブロックする動きとなります。 (表は https://agones.dev/site/docs/advanced/controlling-disruption/ より) Never のままでは、この PDB がすべての Eviction をブロックし、EKS Auto Mode 環境で次の問題が発生します。 Karpenter が Consolidation / Drift を試みても Pod に SIGTERM が発行されず退去しないため、Cordon 状態のノードが既存 Pod ごと残り続け、コスト効率が悪化する。 Drift (AMI 更新) が PDB にブロックされ、セキュリティパッチの適用が遅延する。 上記の動作の結果、近い時間帯に起動した全ノード上の Pod が Expiration まで生存し続け、それらの Pod が近い時間帯に一斉に SIGKILL されるリスクが生じる。 Always を設定すると Agones のネイティブ PDB が無効化され、Eviction が許可されます。Pod が稼働中のノードでも Drift による AMI 自動更新と、Expiration 時の Graceful なノード入れ替えが機能するようになります (Never ではこれらが PDB にブロックされます) 。プレイ中のゲームの保護は Point 1〜3 で確保した猶予期間とシグナルハンドリングが担保するため、Always にしても進行中のゲームが即座に切断されることはありません。 Always の設定でも安全に運用する目的で、Point 1 で設定した consolidationPolicy: WhenEmpty (Pod が残っているノードでは Consolidation を発動させない) と NDB ( nodes: "10%" 、同時中断ノード数の制限) を補完策として組み合わせます。Always は Drift / Expiration を有効に機能させる一方、Consolidation まで WhenEmptyOrUnderutilized にすると稼働中 Pod のあるノードも集約対象となりゲームサーバーが頻繁に Evict され得るため、Consolidation は WhenEmpty に絞り、空ノードの回収のみに留めます。Agones の Fleet 設定 spec.scheduling の値はデフォルトで Packed となっており、できるだけ既に GameServer が動作しているノードに新規 GameServer を起動するようにスケジュールするため、 WhenEmpty の設定でも十分なコスト最適化効果が見込めます。 Point 5 (コントローラ系) ：Agones コントローラ系と GameServer の NodePool を分ける Point 1 で設定した expireAfter / terminationGracePeriod は NodePool 単位の設定です。Agones のコントローラ系 (controller / extensions / allocator / ping) と GameServer では、必要な猶予期間が異なります。 コントローラ系： 短時間の再起動が許容されるため、長期安定稼働を優先しつつ猶予は比較的短くてよい。 GameServer： ゲーム最大持続時間に対応した長い猶予 ( terminationGracePeriod ) が必要。 そこで、コントローラ系用と GameServer 用で NodePool を分離します ( nodepools.yaml ) 。 # コントローラ用 NodePool apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: agones-controller spec: template: metadata: labels: agones-role: controller # ラベルで役割を区別 spec: # コントローラは長期安定稼働を優先 expireAfter: 336h # 14日 terminationGracePeriod: 72h # 3日 --- # GameServer 用 NodePool (Point 1 で前掲) # labels: agones-role: gameserver / terminationGracePeriod: 4h そのうえで、GameServer 側は Fleet の nodeSelector で GameServer 用 NodePool を指定します ( fleet.yaml ) 。 template: spec: # Point 5: GameServer 用 NodePool にスケジュール nodeSelector: agones-role: gameserver コントローラ系は、Agones の Helm Values で nodeSelector を指定し、コントローラ用 NodePool に配置します ( agones-values.yaml ) 。 agones: controller: # Point 5: コントローラ用 NodePool にスケジュール nodeSelector: agones-role: controller extensions: nodeSelector: agones-role: controller allocator: nodeSelector: agones-role: controller ping: nodeSelector: agones-role: controller これにより、それぞれのワークロード特性に合った猶予期間を両立できます。 Point 6 (コントローラ系) ：agones-allocator と agones-ping の PDB を有効にする 前述の通り EKS Auto Mode ではいつか必ずノードの中断が発生するため、Agones のコントローラ系サービスでも可用性維持のための設定が重要です。agones-allocator (ゲームサーバーの割り当てリクエストを受け付けるサービス) と agones-ping (レイテンシー計測用サービス) はデフォルトで PDB が無効のため、ノードが中断されてもこれらが全停止しないよう、PDB を有効化します ( agones-values.yaml ) 。 agones: allocator: replicas: 3 # Point 6: allocator の PDB を有効化 pdb: enabled: true minAvailable: 1 ping: replicas: 2 # Point 6: ping の PDB を有効化 pdb: enabled: true minAvailable: 1 minAvailable: 1 により、ノード中断時にも最低 1 レプリカが稼働し続けることを保証し、コントロールプレーンの可用性を維持します。 なお、agones-controller, agones-extensions はデフォルトで PDB が有効となっています。 さらに安定した運用のための補足 (レアケースへの対処) Point 1〜6 の設計により、通常のノード中断からのゲームサーバー保護を実現できます。さらに安定した運用のためには、次のレアケースへの対処も検討ポイントになります。いずれも各実装に依存するため、必要に応じて検討してください。 GameServerAllocation のレースコンディション Ready 状態の GameServer が SIGTERM を受信した直後から Shutdown 完了までの間に、GameServerAllocation によって Allocate される可能性がゼロではありません。これが起こると、プレイヤーが接続するころには Allocate された GameServer が既に停止しておりエラーとなるリスクがあります。以下はこれを防ぐ方法の例です。 GameServer にあらかじめラベル ( allocationblock=false 等) を付与し、GameServerAllocation 側でそのラベルを持つ Pod のみを対象とする設定を行う。SIGTERM 受信時には即座にラベルを外す。ラベル削除後も一定時間待機し、その間に Allocate された場合はゲームを継続し、終了後に Shutdown する。 起動中 Pod への SIGTERM 発行時のハンドリング不可 コンテナ起動中 (Starting / ContainerCreating) に SIGTERM が発行されると、アプリケーション側でハンドリングできず、GameServer は正常に起動し Ready 状態となる一方、 Pod は terminationGracePeriodSeconds 経過後に停止してしまう動作となり、ゲームを保護できません。これを防ぐには以下の方法が例として挙げられます。 対策例 1： GameServer にあらかじめラベル (allocationblock=false 等) を付与し、GameServerAllocation 側でそのラベルを持つ Pod のみを対象とする設定を行う。外部コントローラで Pod の deletionTimestamp を監視し、非 null、つまり削除予定がある状態なら、前述の Allocation 用ラベルを外し、新規 Allocation を防ぐ。 対策例 2： イメージサイズの削減・DaemonSet 等による事前 pullといった方法で起動時間短縮を図り、発生確率を最小化する。 まとめ 本記事では、Agones の基盤に EKS Auto Mode を採用する際、ノードの自動中断からゲームサーバーを保護する設計を 6 つのポイントで紹介しました。専用ゲームサーバーのセルフホストで、Agones の柔軟性を活かしつつ EKS Auto Mode で運用管理をシンプルにするには、EKS Auto Mode のノード中断と Agones のゲームサーバーライフサイクルの競合を解消する設計が鍵になります。 本記事で紹介した Point 1〜6 の設計パターンと実装例 ( nodepools.yaml / fleet.yaml / agones-values.yaml ) が、EKS Auto Mode 上での Agones 導入を検討する方の参考になれば幸いです。

1. はじめに これまで、AWS AI League Community Editionについて、以下の記事で全体像とデプロイ方法を紹介しました。 AWS AI Leagueを自身のAWS環境で試す ─ Community Editionの全体像 AWS AI Leagueを自身のAWS環境で試す ─ Community Editionのデプロイ 前回の記事では、Community Editionを自身のAWSアカウントへデプロイし、ブラウザからログインできるところまで確認しました。今回は、実際に Game Play を実行してみます。 Community Editionでは、用