re:Invent 2024: KRAFTONが語るPUBG: BATTLEGROUNDSのAWS EKS移行と最適化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - The evolution story of game architecture: PUBG: Battlegrounds, Krafton (GAM311)
この動画では、世界的に有名なオンラインゲームPUBG: BATTLEGROUNDSのインフラストラクチャモダナイゼーションについて、KRAFTONのDevOpsチームの取り組みが紹介されています。LobbyサーバーとSession Serverの両方をコンテナ化し、Amazon EKSへ移行した過程で得られた知見や、直面した課題とその解決策が詳しく解説されています。特に、KarpenterやAgonesといったツールの活用方法や、AWS Gravitonへの移行によって35%のコスト削減を実現した事例など、具体的な成果が示されています。また、Enterprise Supportの一環として提供されるAWS Countdownプログラムの活用事例や、AWSへのフィードバックを通じてEKSの新機能実装につながった経験など、AWS活用のベストプラクティスも共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
PUBGのモダナイゼーション：セッション概要
こんにちは。本日は、世界で最も有名なオンラインマルチプレイヤーゲームの1つである、KRAFTONが開発したPUBG: BATTLEGROUNDSのモダナイゼーションの取り組みについてご紹介するGAM311セッションにお越しいただき、ありがとうございます。現在、PUBGは完全なコンテナ化環境で稼働していますが、最初からコンテナで運用されていたわけではありません。このセッションでは、KRAFTONがどのようにしてコンテナ化されたモダンアーキテクチャに移行したのかをご紹介します。私はKRAFTONを担当するAWSのSolutions ArchitectのMinsuk Kimです。本日は、KRAFTONのDevOps Team LeadであるJungHun Kim氏と、AWSのTechnical Account ManagerであるMinwook Chun氏も貴重な知見を共有してくださいます。
まず初めに、ゲームアーキテクチャのモダナイゼーションとは何を意味するのか、そしてKRAFTONがゲームのローンチ以降、PUBGのアーキテクチャをどのように進化させてきたのかについてお話しします。次に、KRAFTONがモダナイゼーションのプロセス、特にコンテナとKubernetesへの移行において得た教訓を共有します。最後に、KRAFTONが実施した重要なステップと、AWSがどのようにしてそのモダナイゼーションの取り組みをサポートしたのかについてお話しします。
アプリケーションアーキテクチャのモダナイゼーションとPUBGの進化
KRAFTONのPUBGに対するモダナイゼーションの取り組みについて詳しく説明する前に、 アプリケーションアーキテクチャにおけるモダナイゼーションの意味について説明させていただきます。モダナイゼーションとは、現状のアプリケーション環境をより俊敏で、柔軟性が高く、高可用性のあるものへと変革することを意味します。アプリケーションのモダナイゼーションには、俊敏性の向上、運用オーバーヘッドの削減、ビジネスクリティカルな機能の提供への注力など、数多くのメリットがあります。モダナイゼーションには3つの重要な側面があります：段階的な技術とアーキテクチャの採用、人材とプロセスの変革、そして運用とガバナンスのスケーリングです。本日は主にKRAFTONの技術とアーキテクチャのモダナイゼーションについてお話ししますが、真のモダナイゼーションは単なる技術の採用以上のものであることを覚えておいていただきたいと思います。それには、人々の働き方を進化させ、運用を効果的にスケールするための自動化とセルフサービスモデルを実装することが必要です。
私たちAWSでは、クラウドトランスフォーメーションの視点を提供するモダナイゼーションパスウェイと呼ばれるパターンがあります。これらのパスウェイにより、アプリケーションドメインを実証済みのパターンとAWSサービスにマッピングすることができます。KRAFTONはPUBGをAmazon Elastic Kubernetes Service（EKS）上に再アーキテクトするためにコンテナパスウェイを選択しました。このアプローチにより、アプリケーションのパッケージング方法を標準化し、スケーラブルで安全なインフラストラクチャ上でホストすることが可能になりました。KRAFTONはさらに、ワークロードの価格性能比を最適化するため、EKSワーカーノードを専用設計のチップセット、具体的にはAWS Gravitonに移行しました。
それでは、PUBGの注目すべきモダナイゼーションの道のりにおける重要なマイルストーンを見ていきましょう。2017年、PUBGはWindowsベースのAuto Scaling groupsでローンチされ、Terraformによってデプロイおよびマネジメントされていました。グローバルな成功を収めたことで、PUBGのDevOpsチームはいくつかの課題に直面し、それがアーキテクチャのモダナイゼーションにつながりました。PUBGのようなセッションベースまたはオンラインマルチプレイヤーゲームをモダナイズする際には、アーキテクチャの2つの異なる部分を考慮する必要があります：ゲームサービスまたはLobby Server、そしてGame Serverです。Lobby Serverは認証、リーダーボード、実績などのゲームプレイ以外のゲームを補完するWebサービスです。Game Serverはゲーム内でのプレイヤーの状態を処理・管理する信頼できる情報源として機能します。それぞれの部分は異なるソフトウェアスタックを使用し、異なる要件を持っています。Lobby Serverの変革は、Game Serverをコンテナに移行することと比較すると比較的複雑ではありませんでした。そのため、KRAFTONは2018年11月にLobbyサービスのQA環境をコンテナに移行することから始めました。
この最初のステップに続いて、2019年10月にはLobbyサーバーの本番環境が完全にコンテナ化された環境に移行され、2021年7月にはKRAFTONがゲームサーバーのアーキテクチャを再設計してこちらもコンテナに移行しました。最近では、KRAFTONはLobbyサーバーをAWS Gravitonベースのワーカーノードに移行しました。
PUBGをご存じない方のために、このゲームについて簡単にご紹介させていただきます。 PUBGは、ファーストパーソンおよびサードパーソン視点のシューターゲームで、同一セッションで100人のプレイヤーがバトルロイヤル形式で対戦し、最後まで生き残ったプレイヤーが勝利を収めます。PUBGは世界で最も人気があり、最もプレイされているマルチプレイヤーFPSゲームの一つで、Steamプラットフォームでは325万人の同時接続プレイヤー数の記録を保持しています。7周年アップデート後、PUBGは週末のピーク時に70万人の同時接続プレイヤー数を記録しました。このような大規模なゲームの維持とスケーリングに必要なエンジニアリングの取り組みは注目に値し、KRAFTONの継続的なモダナイゼーションへの取り組みがこの成功の鍵であったと考えています。ゲームを活気付け続けているPUBG開発チームの素晴らしい仕事に、大きな拍手を送りたいと思います。
PUBGのゲームシステムとLobbyサーバーのコンテナ化への道のり
それでは、PUBGのプレイ感覚を体験していただくために、ゲームのトレーラーをご覧ください。
ここで、皆さんがこのゲームのプレイヤーだと想像してみてください。まず最初に、ゲーム内の全プレイヤーの入り口となるLobbyにログインします。ここではストアでアイテムを購入したり、インベントリを確認したりできます。また、ゲームに参加する前にキャラクターのカスタマイズも可能です。準備が整ったら、Lobbyサーバーが提供するマッチメイキングに参加して対戦相手を見つけ、ゲームに参加します。
マッチメイキングを通じてゲームに参加すると、プレイヤーは飛行機に搭乗し、好きな場所に降下してゲームを開始します。その後、プレイヤーはアイテムを集め、他のプレイヤーと戦って最後の一人になることを目指します。ゲームが終了すると、プレイヤーはLobbyに戻り、直前の試合の結果を確認することができます。プレイヤーは、より良い報酬と実績を目指してゲーム内とLobbyを行き来し、このプロセスを繰り返していきます。
ここで視点を変えて、エンジニアの観点から見ていきましょう。 Lobby Serverは複数の.NETベースのMicroservicesで構成されており、単一リージョンからグローバルにサービスを提供する大規模なクラスターを形成しています。主にHTTPとWebSocketを使用して通信を行い、AWSが提供する目的別のマネージドデータベースサービスやストレージサービスを活用してデータの処理と永続化を行っています。Session Serverは Unreal Dedicated Serverをベースとしており、複数のリージョンに分散配置されることで、プレイヤー間の低レイテンシーと安定したゲームプレイ体験を提供しています。UDPプロトコルを使用し、クライアント間の直接通信を可能にしています。
Session Serverは永続的なストレージを持たず、ゲームプレイの状態を維持します。
PUBGが爆発的な成長を遂げる中、DevOpsチームは既存のインフラストラクチャーで大きな課題に直面していました。これらの課題は、効率性の低下、生産性の減少、運用の機動性の制限につながっていました。PUBGの初期アーキテクチャーは、各サービスごとに個別のAuto Scaling GroupとAWS CodeDeployの設定で構成されていました。この構成では、新しいQA環境が必要になるたびにDevOpsチームの介入が必要となり、開発プロセスのボトルネックとなっていました。
さらに、新機能をサポートするためのMicroservicesの継続的な追加により、インフラストラクチャーコードの頻繁な更新と継続的なメンテナンスが必要となりました。これらの作業は、チームの効率性と生産性に大きな影響を与え、より戦略的な取り組みへの注力を妨げていました。DevOpsチームはまた、様々な運用・監視ツールの定期的なデプロイメントと保守も担当しており、これによってチームのリソースがさらに圧迫され、全体的な運用の機動性に影響を及ぼしていました。
これらの課題を認識し、KRAFTONはコンテナ化を採用するという戦略的な決断を下しました。この移行は、DevOpsチームに影響を与えていた差別化されない重労働を排除することを目的としていました。コンテナ化を通じて、KRAFTONは運用を効率化し、チームがゲームの成功と会社の成長に真に重要な高付加価値タスクに集中できるようにすることを目指しました。
セッションサーバーのKubernetes移行：課題と解決策
それでは、KRAFTONのDevOps Team LeadであるJungHun Kimより、モダナイゼーションの取り組みについて詳しくご説明させていただきます。皆様、こんにちは。本日は、PUBG: BATTLEGROUNDSのモダナイゼーションについてお話しさせていただきます。ContainerとKubernetesを使用する際の一般的なシナリオに基づいたお話なので、ご存知の方もいらっしゃるかもしれませんが、私たちの経験が皆様にとって有益な洞察やヒントとなれば幸いです。
まず、アーキテクチャについてご説明させていただきます。こちらの図は、PUBG: BATTLEGROUNDSの以前のアーキテクチャを示しています。上部にご覧いただけるように、単一リージョンで集中的に運用されているLobby Serverがあります。これは、Amazon CloudFront、Elastic Load Balancing、Lobby Server、そして様々なAWSマネージドサービスを含む典型的なWebサーバーアーキテクチャとなっています。一方、下部に示されているSession Serverは、複数のリージョンに分散配置されたUnreal Dedicated Serverのプールで構成されています。両サーバーともCloudFormationスタックとEC2 Auto Scaling Groupsで構築されており、CodeDeployを使用してサーバーのアーティファクトをインスタンスに配布しています。
このレガシーアーキテクチャは、現在のアーキテクチャと非常によく似ていますが、効率性と柔軟性を向上させるため、特定の領域でモダナイゼーションを実施しました。私たちは様々な運用要件に対応するためにサーバーのモダナイゼーションを行いました。 主な課題の一つは、複数のQA環境を維持するためのオーバーヘッドを最小限に抑え、時間とコストを削減することでした。以前は、様々な種類のリクエストに対応するため、ケースバイケースでQA環境を手動で作成・管理していました。ほとんどのリクエストが予測不可能なタスクで、処理に時間がかかるため、頻繁なコンテキストスイッチングが発生し、大きな時間の無駄が生じていました。この作業フローは、最終的にDevOpsチーム全体の効率を低下させることになりました。
各QA環境に対して、多数のAWSサービスを個別に作成・管理していました。 この個別管理のワークフローは、多大な時間と労力を必要とし、また各環境のリソースを個別に維持することによる大きな無駄も発生していました。この問題を解決するため、より効率的なワークフローでQA環境をモダナイズすることを目指しました。 新しいワークフローを設計する前に、3つの重要な目標を設定しました。第一に、運用コストを最小限に抑えるため、必要なリソースのみを効率的にプロビジョニングすることを目指しました。第二に、大規模なコミュニティによってサポートされ、スケーラブルで高度にカスタマイズ可能な標準的なソリューションを探しました。最後に、DevOpsチームのリクエスト処理の負担を軽減するため、各チームが自身の環境を簡単に管理できるようにすることを目指しました。
これらの目標を念頭に置き、Containerを使用してQA環境を管理し、ContainerとKubernetesシステムにワークロードを移行することを決定しました。 AWSリソースを、複数の環境間で共有できるかどうかに基づいて2つのグループに分類しました。第一のグループは、各環境専用のリソースです。例えば、Amazon SQSやDynamoDBテーブルは、各環境に対して個別に作成する必要がありました。第二のグループは、Containerを通じて複数の環境間で共有できるリソースです。VPCやEC2インスタンスなどの一部のコンピューティングリソースやネットワークリソースは、複数の環境間で簡単に共有することができます。さらに、Amazon OpenSearch Serviceドメインなどの一部のリソースは、設定を通じて仮想的に簡単に分離することができます。
環境の作成と破棄を容易に行う必要があるため、専用リソースは頻繁な変更が必要でした。これに対応するため、それらをContainer Appsに移行し、Kubernetesリソースとして動的に管理することにしました。一方、共有リソースは頻繁な作成・破棄が不要で比較的安定しているため、AWSリソースとして維持し、Terraformを統合したCI/CDパイプラインで管理することにしました。リモートCI/CDパイプライン上でコードレビューを伴うTerraformを実行することで、信頼性の高い一貫したクラウドリソース管理を実現しています。Kubernetesリソースの管理を簡素化するため、チームが直接自身の環境を管理できるWebツールを開発しました。このツールは様々なカスタマイズ要件に対応する環境設定も管理し、各環境のライフサイクルに基づく日次更新や削除などのライフサイクル管理も行います。この新しいワークフローにより、労力とコストを最小限に抑えながら、数百の環境を効率的に管理できるようになりました。
QA環境の管理を実現した後、本番環境の管理にも着手しました。QA環境ではデータが重要でないため、破壊的な変更も許容されます。しかし、本番環境ではユーザーデータが最優先事項であり、移行戦略を立てる際にはデータの一貫性を確保することが絶対に不可欠でした。幸いなことに、DynamoDBのようなマネージドデータベースサービスを使用していたため、データベースの移行を心配することなく、サービスワークロードのコンテナへの移行に専念することができました。そこで、QA環境で実践したアプローチを本番環境にも適用することにしました。
私たちはTerraformを使用して、Amazon EKSクラスターの展開やALBコントローラー、EBSコントローラーなどの各種コントローラー、そして様々なAWSリソースといった安定したリソースを管理しています。一方、サーバーのデプロイメントと関連する設定は、頻繁な変更が必要なため、Kubernetes上で動的に管理しています。このハイブリッドなアーキテクチャにより、本番運用がより柔軟になり、予期せぬ問題や変化するニーズに素早く効率的に対応できるようになりました。本番ワークロードを段階的に移行するため、トラフィック制御とロードバランシングに重点を置きました。
以前は、独自のetcdベースのサービスディスカバリーを使用していました。各サーバーは定期的にIPアドレスやサービス名などの位置情報をetcdに更新し、同時に他のサーバーからの更新情報もetcdを監視していました。このサービスディスカバリーにより、サーバー同士が位置情報を使って直接通信することができました。 VPCとVPC CNIを使用することで、PodはVPCから直接プライベートIPを取得できます。これにより、ネットワーク変換を必要とせず、EC2インスタンスとPod間でプライベートIPを使用した直接通信が可能になりました。このメリットから、クラスターCNIにはVPC CNIを選択しました。これにより、既存のetcdベースのサービスディスカバリーを活用でき、スムーズで効率的な移行が実現できました。必要な作業は、既存のEC2インスタンスと同様のサイズでKubernetes Podを作成し、Podとインスタンス間のトラフィック比率を調整し、段階的な移行を確実にするためにステータスを監視することだけでした。
Kubernetesへの移行後、Kubernetesに合わせて新しいサービスディスカバリーとしてKubernetes Serviceを使用することにしました。しかし、Kubernetes Serviceをサービスディスカバリーとして使用する際に課題が発生しました。各サーバーは1つのサービスDNS名を使用して複数のターゲットサーバーにトラフィックをルーティングしていました。さらに、サーバーは各ターゲットに対して新しい接続を作成せず、サービス名にリンクされた既存の接続を使用していました。
この方式では複数のPodへのトラフィック分散が不均一となり、Pod間で負荷の偏りが生じていました。時にはサーバーの一部でCPU負荷が高くなりサーバー障害を引き起こすこともありました。しかし、リクエストごとに新しい接続を作成するのは接続枯渇の問題があり現実的ではなかったため、別の解決策を見つける必要がありました。
私たちは新しいService MeshとしてIstioを採用しました。 Istioは各ServiceのPodにSidecar Proxyを注入することでMesh構造に適合します。このIstio Sidecarがサーバー間のすべてのトラフィックを処理し、ルーティングポリシーに基づいて転送先に分散させることができます。この解決策によってトラフィック分散の問題を解決することができました。さらに、高度なルーティングやトラフィック制御機能で様々なユースケースに対応できることに加え、セキュリティや可観測性の設定も提供してくれます。主要なルーティングルールと認可ポリシーをIstioに移管することで、クラウドに依存しないネットワーク層を構築しました。このネットワーク層は、PUBGサーバー自体を含む多くのサーバーワークロードに活用されています。
Lobbyサーバーをコンテナとそれを管理するKubernetesベースのシステムへと近代化することで、 インフラ管理を簡素化し、コストを削減し、DevOpsチームのエンジニアリング負担を軽減することができました。また、トラフィック管理の改善により、より柔軟で信頼性の高いサービス運用が可能になりました。ただし、Kubernetesとそのエコシステムのメリットを最大限に活用するためには、まだまだ学ぶべきことが多くあります。そのため、Kubernetesを採用して前に進む際には、学習曲線を慎重に評価することが重要です。
AWS Gravitonへの移行：パフォーマンスとコスト最適化の追求
Lobbyサーバーの近代化が完了した後、私たちはSessionサーバーにも同様のアプローチを検討し始めました。SessionサーバーもコンテナとKubernetesシステムで近代化したいと考えたのです。この図は、以前のSessionサーバーのアーキテクチャを示しています。先ほど述べたように、複数のリージョンと環境にまたがる専用サーバープールを管理するために、AWS CloudFormation StacksとAuto Scaling Groupを2つ使用していました。専用サーバープロセスをプールとして管理するために、要件を満たすサーバーのライフサイクルを処理するソリューションが必要でした。そこで、専用サーバーバイナリのインストール、アップデート、削除、さらには起動や終了、キャパシティ管理などのライフサイクル管理機能を扱うManagerサービスを開発しました。このサービスは専用サーバーからのログを処理し、管理目的でLobbyサーバーからのリクエストも処理します。Managerサービスのデプロイと管理には、各インスタンスに効率的にアーティファクトを配布するためにAWS CodeDeployを使用しました。
Sessionサーバーを Kubernetesに移行することを決めた後、いくつかの目標を設定しました。まず、AWS CloudFormationやAWS CodeDeployなどのレガシースタックの置き換えを目指しました。これらのツールは過去には上手く機能していましたが、Kubernetesベースのシステムには最適ではありませんでした。また、これらのソリューションのメンテナンス負担を減らすため、適切なオープンソースツールを見つけることも目標としました。次に、追加のプロビジョニングや割り当ての遅延なしに、既存の本番環境のゲームワークロードを効率的に処理するソリューションが必要でした。最後に、リソースのBin-packingやダイナミックスケーリングなどの技術を通じて、リソース利用率を最大化することに焦点を当てました。これらの目標により、要件を満たす標準化された、スケーラブルで費用対効果の高いゲームセッションサーバーのソリューションを見つけることができました。
私たちがAgones（ゲームサーバーのオーケストレーションソリューション）を採用した理由は主に以下の3つです。まず、大規模でアクティブなコミュニティが存在し、ソリューション自体の開発やメンテナンスの負担を軽減できます。次に、Agonesはセッションサーバーに必要な機能をすべて提供してくれます。具体的には、セッションゲームサーバーのライフサイクル管理、アロケーション、キャパシティ管理のためのスケーリング、セレクターベースのアロケーション、そしてKubernetesのDeploymentに似たローリングアップデート戦略などです。そして3つ目に、AgonesはゲームサーバーのホスティングにKubernetesのPodを使用するため、リソース管理やテレメトリーなど、既存のKubernetesエコシステムとの統合が容易でした。
Agonesへの移行にあたり、キャパシティ管理、スケーリング管理、条件付きサーバーアロケーションなど、Manager Serviceの機能の大部分をControllerに委譲し、各ゲームサーバーのライフサイクルはSidecarコンテナとしてAgentが管理するようにしました。ただし、ローカル処理については従来通り維持しました。
私たちは社内要件を満たすため、Agonesを専用サーバーコンテナとして使用しています。必要に応じて、DaemonSetやSidecarコンテナをデプロイすることで、ローカル処理をコンテナにオフロードすることも可能です。さらに、AgonesのControlとゲームサーバーを異なるノードグループに分離することで、Control層により堅牢なセキュリティ設定を適用できるようになりました。
セッションサーバーをKubernetesに移行することで、効率的なリソースパッキングを通じてインスタンスコストを大幅に削減できました。セッションサーバーは複数のリージョンに分散していたため、各環境で最小数のセッションサーバーインスタンスが必要でした。また、CodeDeployエージェントや専用サーバーバイナリのインストールに時間がかかるため、新しいインスタンスの起動には時間がかかっていました。これに対処するため、1つのインスタンスで複数のサーバーをホストする必要があり、より大きなインスタンスタイプが必要になりました。これは特にQA環境で大きな問題となり、リソースの無駄が発生していました。そのため、QA環境ではセッションサーバーのプロビジョニングに厳格なポリシーを適用し、テストが必要でない場合はセッションサーバータスクを作成しないよう各チームに徹底しました。
Kubernetesへの移行後、Kubernetesのnamespaceを使用して管理環境の分離を開始しました。現在は環境全体で1つのKubernetesクラスターを共有し、リソースのBin PackingとスケーリングをKubernetesが自動的に処理しています。このアプローチにより、リソース利用率を最大化してコストを大幅に削減できました。しかし、Kubernetesへの移行により新たな課題も生まれました。新しいアーキテクチャによってリソース管理は改善されましたが、新規インスタンスの初期起動の遅延が依然としてボトルネックとなっています。新しいインスタンスとゲームサーバーを一から作成してブートストラップするまでに、平均で10〜15分かかっています。リソース利用率の最適化により、ノードの作成頻度が増加し、ブートストラップの遅延による影響が増幅されました。これは特に、迅速なプロビジョニングがテストサイクルにとって重要なQA環境で問題となっており、エンジニアたちはテストスケジュールが中断されることについて頻繁に不満を訴えていました。
このブートストラップの遅延を解消するため、私たちはいくつかの新しいソリューションを導入しました。まず、ノードをより効率的に管理するために、Cluster AutoscalerをKarpenterに置き換えました。 Cluster Autoscalerとは異なり、KarpenterはEC2 Auto Scaling groupsに依存せず、追加のプロビジョニングステップを省くために、インスタンスを直接管理します。Karpenterの採用は、ノード管理においても大きなメリットをもたらしました。異なるファミリーやサイズの複数のインスタンスタイプを、単一のノードプールに組み合わせることができるようになったのです。この柔軟性により、固定のCPUとメモリの比率に縛られることなく、より効率的なリソースのビンパッキングとキャパシティ管理が可能になりました。さらに、Karpenterは中断制御機能を備えたより効率的なインスタンス置換ポリシーを提供し、AIのアップグレードやノードの置換などの運用効率を向上させています。
次に、HarborとCloudFront CDNを使用してコンテナレジストリプロキシを構成しました。 Harborはオープンソースのコンテナレジストリで、私たちのプライベートレジストリやDocker Hubなど、多くのパブリックレジストリからのイメージをキャッシュするように設定しました。また、Harborの前段にCloudFrontを配置し、イメージをグローバルにキャッシュして配信できるようにしました。この構成により、データ転送コストを削減し、イメージプルのネットワークレイテンシーとスピードを改善することができました。VPCエンドポイントとECRのリージョナルレプリケーションを使用すれば、レイテンシーとコストを削減できたのですが、AWS外のインスタンスもサポートする必要があったため、この選択肢は使えませんでした。最後に、Image Puller Podをデーモンセットとして作成・デプロイしました。専用サーバーイメージが非常に大きいため、イメージのプルがPodプロビジョニング時間の大部分を占めていました。Image Pullerは、インスタンスのブートストラップ時に、待機中の専用サーバーPod用のイメージをプルすることで、インスタンスの起動時間をより効率的に活用できるようになりました。これらの取り組みにより、ブートストラップの総所要時間を15分以上から4分未満に短縮することができました。
セッションサーバーをKubernetesでモダナイズすることで、いくつかのメリットを得ることができました。まず、特にQA環境において、効率的なリソースパッキングによって運用コストを大幅に削減できました。次に、すべてのロビーサーバーとセッションサーバーのタスクをKubernetes上で統一することができました。
ただし、このPUBGの移行にはいくつかのトレードオフがありました。ゲームサーバープロセスは初期化プロセス中にCPUの負荷が高くなります。同じノード上で複数のサーバーPodが同時に作成される場合、サーバーのCPUの競合が発生する可能性があります。これは、KubernetesにはPodのプロビジョニングと同時実行を管理する上で制限があり、初期化の負荷を均等に分散させることが難しいためです。
PUBGのゲームセッションは時間とともに進行し、セッション内のユーザー数が徐々に減少するにつれてCPU使用率も低下していきます。この使用パターンにより、リソース割り当ての正確な予測と制御が困難になっています。リソース効率を改善するには、Pod のリソース割り当てを動的に調整するソリューションが必要です。KubernetesにはPod作成後にリソースを変更できる機能があり、これは「Podのリソースのインプレースリサイジング」と呼ばれています。ただし、現在はアルファ版であり、どのケースでも利用できません。1.32でベータ版になり、EKS 1.32でも利用可能になる予定です。この機能は、プロビジョニングの競合とリソース効率の両方の課題を解決する可能性があると考えています。
モダナイゼーションの教訓とAWSサポートの活用
Lobbyサーバーとセッションサーバーの両方をKubernetesとコンテナベースのシステムに移行した後、私たちはクラウドリソース管理のコスト削減戦略の検討を開始しました。その取り組みの一つがAWS Gravitonの採用でした。AWS GravitonはAWSが独自に開発したARMアーキテクチャベースのプロセッサーで、x86プロセッサーと比較して優れた価格性能比を実現しています。私たちはコスト削減戦略の一環としてGravitonインスタンスの採用を検討しました。Lobbyサーバーは一般的なWebサーバースタックに従っていたため、ARMアーキテクチャへの移行に関する参考情報を見つけやすく、セッションサーバーと比べて移行の複雑さが低かったことから、まずはLobbyサーバーの移行を優先することにしました。
AWS Gravitonを採用するにあたり、まずARMアーキテクチャ用のコンテナイメージをビルドする必要がありました。また、ARMとx86のイメージを効率的に管理する方法も必要でした。幸いなことに、移行フェーズの時点でLobbyサーバーのSDKレベルのビルドチェーンはすでにARM互換のアーティファクトを生成できる状態でした。これにより、ARM向けのコンテナイメージを簡単に作成することができました。その後、異なるアーキテクチャ間での複数イメージを管理するプロセスの最適化に注力しました。私たちの目標は、これらのイメージを単一のタグで管理することでした。この標準的なプラクティスに従うため、イメージマニフェストを生成するようビルドパイプラインを調整しました。このパイプラインはARMとx86の両方のイメージを生成し、それらを統一されたイメージマニフェストタグにマージします。これにより、単一のイメージタグでARMとx86の両方のイメージをサポートすることが可能になりました。さらに、このアプローチは移行プロセス中に複数のオペレーティングシステムをサポートする際にも応用できます。
最も顕著な違いは、Intel、AMD、Gravitonが仮想コアをどのように利用するかという点でした。IntelとAMDはハイパースレッディングとSMTテクノロジーを使用しており、これにより1つの物理コアが複数のスレッドを同時に処理できるよう、オペレーティングシステムに複数の仮想コアとして提供されます。一方、Gravitonは1つの物理コアを1つのスレッドに直接マッピングし、物理コアと仮想コアの1対1のマッピングを提供します。IntelとAMDベースのインスタンスでは、CPU使用率が高くなるとレイテンシーのスパイクが発生することに気づきました。これらのスパイクは、仮想コアが物理コアのリソースを奪い合うことで発生し、このリソースの競合がフィードバックループを作り出し、最終的にサーバーの障害を引き起こしていました。これを緩和するため、Lobbyサーバーの目標CPU使用率を40～50%程度に調整する必要がありました。
Gravitonベースのインスタンスでは、設計上リソースの競合が解消されていました。これにより、インスタンスとレイテンシーを安定させながら、はるかに高いCPU使用率を達成することができました。ただし、Intelインスタンスと比較すると、同じリクエストの処理により多くのCPU使用率が必要であることに気づきました。これは、私たちのワークロードがARMアーキテクチャに対して完全に最適化されていなかったためだと考えています。より良い定価と高い安定性を得られましたが、最適化が理想的ではない状態でも、レイテンシーの安定性を損なうことなく、約35%の価格性能比の改善を実現することができました。
Lobbyサーバーの移行とは異なり、セッションサーバーの移行は私たちにとってはるかに複雑です。このプロセスでは、Unrealデディケイテッドサーバーのコードベースを修正するだけでなく、サーバーに依存するライブラリにも大幅な変更を加える必要がありました。これらの作業のため、セッションサーバーのAWS Gravitonへの移行は私たちにとって依然として課題となっています。セッションサーバーはLobbyサーバーと同様にCPU集約型でレイテンシーに敏感なため、Lobbyサーバーで実現したのと同様の改善がGravitonでも期待できると考えています。
モダナイゼーションの取り組みから得られた重要な教訓をご紹介します。第一に、本質的な部分に注力することです。私たちは、AWS Managed ServiceとOpen-sourceソフトウェアを積極的に活用して、不要なタスクを排除しました。これにより、差別化につながらない作業を最小限に抑え、時間とコストを節約しながら、真の価値の提供に集中することができました。第二に、副作用を意識することです。移行には予期せぬ課題がつきものです。潜在的な副作用を認識しておくことで、移行プロセスをよりスムーズに進めることができます。第三に、ロールバックの準備をしておくことです。予期せぬ問題に対応できるよう、常にロールバック計画を用意しておきましょう。ロールバック計画があれば、問題を双方向のドアに変え、決定を覆すことができ、長期的なリスクを回避できます。
ご清聴ありがとうございました。それでは、残りのセッションをMinuに引き継ぎたいと思います。皆様、こんにちは。KRAFTONのTechnical Account Managerとして5年以上働いているMinuです。まとめのセクションに進ませていただきます。私たちは、効率性、エンジニアの生産性、そしてアジリティの向上という3つの主要な課題から始まったKRAFTONの移行の旅をご紹介してきました。様々なモダナイゼーションの道筋の中で、コンテナへの移行がKRAFTONの成功の重要な要因となりました。ゲーム業界ではコンテナの採用が増えており、チームがKubernetesに精通している場合、Amazon EKSは優れた出発点となります。Control PlaneやHigh Availabilityの管理という複雑なタスクから解放され、より効率的な領域に集中できます。
KRAFTONのAmazon EKSへの移行も、同様の考えに基づいています。専用のSession Serverをコンテナで実行することは、Load Balancerの代わりにHost Portを必要とするなど、一般的なWebサービスとは若干異なります。それでも、コンテナはゲームインフラストラクチャにおける役割を拡大しています。EKSクラスターのより良い管理のため、KRAFTONは効率的なコンピュート管理とゲーム運用のためにKarpenterを採用しました。これにより、小規模なDevOpsチームで多様な運用を効率的に管理できるようになりました。クラウドインフラストラクチャを管理する上で、コストは見過ごすことのできない重要な要素です。Right-sizing、Spot Instance、Savings Planなどの戦略をすでに活用されているかもしれません。KRAFTONでは、性能対価格比で考えた場合、IntelやAMDのインスタンスと比べて約35%のコスト削減を実現できるGravitonベースのインスタンスの利用を拡大していく予定です。
移行は、どの組織にとっても大変な課題です。入念な準備をしていても、プロセスの途中で予期せぬ問題が発生する可能性があります。ここでAWSの専門知識が非常に価値を発揮し、ターゲットアーキテクチャと移行手順の検証をサポートします。Enterprise Supportのお客様向けに、AWS Countdownというプログラムを提供しています。このサービスは、計画から実行、そして実施後の分析まで包括的なサポートを提供します。例えば、KRAFTONは新作ゲームのローンチやアカウント統合などの重要な変更の際にこれを活用しました。まだAWS Countdownをご利用になっていないEnterprise Supportのお客様は、ぜひアカウントチームにご相談ください。また、EnterpriseとBusiness Supportのお客様向けに、移行の取り組みに追加リソースを提供するCountdown Premiumティアもご用意しています。
安定した運用は、どのようなチームにとっても重要な目標です。問題解決は重要ですが、貴重な時間を節約するために問題を未然に防ぐことも同様に重要です。Enterprise Supportのお客様向けに、この目標を達成するための様々なツールを提供しています。これには包括的な
Amazon EKSやAWSサービスのネットワークなど、様々なサービスに関する運用レビューを提供しています。また、スキルと知識を向上させるための体系的なワークショップも用意しています。最も良い点は、Enterprise Supportをご利用のお客様であれば、これらのリソースを追加費用なしでご利用いただけることです。現在のアーキテクチャを最適化し、潜在的な問題を事前に防ぐために、これらのツールを活用されることを強くお勧めします。AWSの専門家と協力して、インフラストラクチャを次のレベルに引き上げる絶好の機会となります。
AWSサービスを使用していると、サービスに制限があったり、必要な通りに動作しないことに気づくことがあるかもしれません。そのような状況では、自分で解決策を見つけようとするかもしれませんが、より良いアプローチがあります：AWSのアカウントチームに相談することです。KRAFTONの多くの方々はすでにご存知かと思いますが、新しいAWSサービスや機能の多くは、お客様からのフィードバックがきっかけとなっています。実際にあった話をご紹介させていただきます。
KRAFTONが新しいプロジェクトに取り組んでいた際、Amazon EKSのWindowsシステムで「HostPort」という特定の設定が必要でしたが、当時この機能はサポートされていませんでした。実現可能な代替手段がなかったため、彼らは私たちにその要望を伝えてきました。アカウントチームとして、私たちはEKSチームに彼らのユースケースと課題を説明しました。EKSチームはこの機能の実装を決定し、その結果、2ヶ月足らずで新バージョンのWindows EKS最適化AMIにこの機能を搭載することができました。KRAFTONからのフィードバックのおかげで、この機能をリリースすることができたのです。
AWSサービスを使用する中で制限に直面した場合は、ぜひチームにご連絡ください。皆様から問題をお聞かせいただくことで、AWSサービスの使用方法をより深く理解し、サービスを改善することができます。皆様からのフィードバックは非常に重要です。皆様のフィードバックに基づいてサービスを改善することで、皆様だけでなく、AWS全体のコミュニティにもメリットをもたらすことができます。この15分間で、KRAFTONの移行の旅をご紹介させていただきましたが、皆様自身の移行の取り組みにとって価値ある洞察となれば幸いです。ご清聴ありがとうございました。皆様のクラウドジャーニーが成功することを願っています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion