リアルタイムサーバー運用改善
〜メタバースプラットフォームにおけるEKS運用とDatadog活用によるオートスケール実践〜
2025年11月18日
CloudNative Days Winter 2025
1
1
自己紹介
2
Toshiki Ishii
CTO室インフラチーム所属
ホロアースSRE(2024/10~)
興味: Edge Computing/Peformance Tuning
カバーについて
01
3
3
VTuberの多面的な特性を活かした事業展開
日々の配信やライブイベントを通じて熱量の高いファンコミュニティを拡大。
バーチャルアバターの特性を活かして多面的なコマース展開を行う
多面的なコマース展開
VTuber IP・ファンベースを育成
※１：2025年3月期売上高に占める内訳
※２：月額料金を支払いチャンネルメンバーになり、バッジ・絵文字、限定動画視聴等の特典を得られる制度
※３： YouTubeのライブチャットを利用したライブ配信動画の公開時に視聴者が有料課金を行うことでチャットメッセージを目立たせることができる機能
主な�収益源
主な�コスト項目
サービス�概要
売上構成比 *1�（売上高前期比）
配信/コンテンツ
マーチャンダイジング
ライセンス/タイアップ
ライブ/イベント
配信プラットフォームを通じた�ライブ配信
オフライン/オンラインでの�ライブイベント開催
フィジカル/デジタルの�VTuberグッズ販売
メーカー等へのIPライセンスアウトや�タイアップ広告等のプロモーション支援
chメンバーシップ *2 、 Super Chat *3
チケット販売、関連物販
自社/外部ECサイトでの販売
ライセンシーからのロイヤリティ�広告主からのプロモーション料
プラットフォーム手数料、演者分配
ライブイベント制作費、演者分配
販売手数料、グッズ原材料、演者分配
制作費、演者分配
47.3％
（YoY +64.6%）
13.2％
（YoY +29.4%）
18.0％
（YoY +39.1%）
21.5％
（YoY +21.9%）
ホロアースについて
02
5
5
メタバースプラットフォーム「ホロアース」
ゲームとオンラインライブを主軸とした3Dエンターテインメントプラットフォームとして、
世界中の人々が遊び、創造し、稼ぐ、が成立する世界を実現する
6
© COVER Corp.
VTuber
ユーザー
ライブ・コンサート
ファン・ミーティング
アバター衣装等の仮想空間内
アセットの製作・販売
人気アニメーターによる
アバター・衣装デザイン
メタバースプラットフォーム「ホロアース」
ユーザー間コミュニケーションを楽しめるオープンワールドプラットフォームとして、弊社ホロライブのタレントが降臨するイベントを積極開催中
7
SREのロードマップと課題
03
8
8
ホロアースSREロードマップ
9
2025/4
2025/10
2026/4
2024/10
サーバーサイドのテレメトリデータを
Datadogへ集約
UGCリリースの
負荷試験・インフラ構築支援
API Gateway/Database移行によるインフラの再構築
監視基盤構築/インフラ構築支援
インフラ構成の見直しと
プラットフォームエンジニアリング
SLI/SLO
導入推進
クライアントサイドへのSentry導入
リアルタイム通信の
Kubernetesの運用改善
アラート運用改善
エラートラッキング実装
SLO導入計画策定
UJの洗い出しと成功率の可視化
新規リリースのインフラ構築支援
2024年10月から最終目標のSLI/SLOアラートの運用を見据えて、監視基盤およびインフラ構成の見直しやプラットフォームエンジニアリングを進めている
ホロアースSREロードマップ
10
2025/4
2025/10
2026/4
2024/10
サーバーサイドのテレメトリデータを
Datadogへ集約
UGCリリースの
負荷試験・インフラ構築支援
API Gateway/Database移行によるインフラの再構築
監視基盤構築/インフラ構築支援
インフラ構成の見直しと
プラットフォームエンジニアリング
SLI/SLO
導入推進
クライアントサイドへのSentry導入
リアルタイム通信の
Kubernetesの運用改善
アラート運用改善
エラートラッキング実装
SLO導入計画策定
UJの洗い出しと成功率の可視化
新規リリースのインフラ構築支援
2024年10月から最終目標のSLI/SLOアラートの運用を見据えて、監視基盤およびインフラ構成の見直しやプラットフォームエンジニアリングを進めている
ホロアースSREロードマップ
11
2025/4
2025/10
2026/4
2024/10
サーバーサイドのテレメトリデータを
Datadogへ集約
UGCリリースの
負荷試験・インフラ構築支援
API Gateway/Database移行によるインフラの再構築
監視基盤構築/インフラ構築支援
インフラ構成の見直しと
プラットフォームエンジニアリング
SLI/SLO
導入推進
クライアントサイドへのSentry導入
リアルタイム通信の
Kubernetesの運用改善
アラート運用改善
エラートラッキング実装
SLO導入計画策定
UJの洗い出しと成功率の可視化
新規リリースのインフラ構築支援
2024年10月から最終目標のSLI/SLOアラートの運用を見据えて、監視基盤およびインフラ構成の見直しやプラットフォームエンジニアリングを進めている
システムの安定稼働のためにリアルタイムサーバーの運用を見直すことが最優先に
(タレント降臨に伴う負荷増加に耐える必要が出てきた)
現在のシステム構成
12
現在のシステム構成
13
クライアント
・ホロアース(Desktop App): Unity
・クリエイター用ツール(Web): React, WebGL
メインのホロアースを遊ぶためのUnityビルドとUGCコンテンツを作成するためのWebサイトを開発・運用
現在のシステム構成
14
各種テレメトリデータはクライアント・サーバーごとそれぞれ監視Saasへ集約
クライアントサイド：Sentry
サーバーサイド：Datadog
現在のシステム構成
15
●API サーバー
●リアルタイムサーバー
各機能ごとに別々のサーバーチームで開発・運用
現在のシステム構成
16
ここの話
一般的なゲームサーバーとKubernetes
17
・ゲームサーバーはステートフルなため負荷分散が難しい
→Node IP経由でPodとUDP直接通信を行い、Ingress等での負荷分散が難しい
・ゲームクライアントは特定のゲームサーバーインスタンスに直接接続する
→一部のCaaSではNode IPの利用に制約があり、ゲームサーバー運用に不向き
・大量のNode(VM)の管理を行う必要がある
→KubernetesによるNodeプロビジョニングを活用したい
Diarkis(Room)について
18
Statefulなサーバー運用を簡素化できる仕組みを提供する商用ソフトウェア
・UDPでの高速な通信/HTTPによる接続先分散/MARSによるサーバーメッシュ
・サーバーサイドへのカスタムゲームロジックの記述
・同接数等取得のためのメトリクス生成(Prometheus)
・Goのバイナリのためポータビリティが高い
ホロアースのリアルタイムサーバー
19
ホロアースで利用している位置同期システムのこと
・DiarkisのRoomモジュールを利用し、EKS上で運用している
ホロアースでのDiarkisユースケース
20
同一Room内のユーザー間へのパケット(座標やエモート等のイベント)のブロードキャストを行っている
ホロアースにおけるEKS運用の課題
21
2025年の年始当時に抱えていた課題
ホロアースにおけるEKS運用の課題
22
2025年の年始当時に抱えていた課題
まずはSREチームの管理下に置き塩漬け状態を脱却することで、Kubernetes運用における最低限のセルフサービス化を目指す
ホロアースにおけるEKS運用の課題
23
ホロアースの状況をプラットフォームエンジニアリングの成熟度モデルに当てはめ、SRE・ホロアース開発チーム双方が協業していけるような構想をした
https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/#model-table
SREチームが専任としてEKSクラスタの運用に責任を持ち開発者との運用境界を定める
ArgoCD等、業界標準のCI/CDツールの整備から既存の運用フローを再構築し直す
共通で利用可能なインフラとしてTerraformによるIaC化とCRDの導入を進める
開発チームが自立して横断リソースを運用できるようなドキュメンテーションする
DatadogをEKSへ導入し、計測値を元に議論しながら改善を進められるようにする
EKSプラットフォームへの道のり
04
24
24
バックログ
25
構想をもとに改善を進めるために大枠の課題を分割した。
1.EKSクラスタの管理の放置問題
2.ワークロードクラスタの内部状態の可視化
3.Room管理とインスタンスのサイジングによるコスト適正化
4.オートスケールの改善
5.大規模利用に向けて
バックログ
26
構想をもとに改善を進めるために大枠の課題を分割した。
1.EKSクラスタの管理の放置問題
2.ワークロードクラスタの内部状態の可視化
3.Room管理とインスタンスのサイジングによるコスト適正化
4.オートスケールの改善
5.大規模利用に向けて
1.EKSクラスタの管理の放置問題 - 改善前の当時のEKSの状況
27
当時はeksctl create cluster後、ほぼ何もしていない状態のEKSが塩漬けになって数年放置されていた
1.EKSクラスタの管理の放置問題 - 目指す形
28
Github上で自動デプロイを行うGitOpsのパイプラインが構成され、開発チームは必要なリソースのみにアクセスできる状態を目指した。
1.EKSクラスタの管理の放置問題 - 改善前の当時のEKSの状況
29
当時はeksctl create cluster後、ほぼ何もしていない状態のEKSが塩漬けになって数年放置されていた
1.EKSクラスタの管理の放置問題 - Terraform化
30
EKSはClusterごと入れ替えるのを前提にTerraformによるIaC化を推進
またこのタイミングで導入するCustom Resourceを選定
[Terraform管理対象]
・EKS Cluster/Managed NodeGroup
・EKS Addon
・kube-proxy
・VPC CNI plugin
・CoreDNS
・Pod Identity agent
・EBS CSI Driver�・Helm� ・AWS Load balancer controller
・Karpenter
[Terraform管理対象外](基本はhelmfile)
・管理対象以外のHelmリソース
・External Secrets
・External DNS
・KEDA
・Datadog
1.EKSクラスタの管理の放置問題 - Terraform化
31
EKSはClusterごと入れ替えるのを前提にTerraformによるIaC化を推進
またこのタイミングで導入するCustom Resourceを選定
[Terraform管理対象]
・EKS Cluster/Managed NodeGroup
・EKS Addon
・kube-proxy
・VPC CNI plugin
・CoreDNS
・Pod Identity agent
・EBS CSI Driver�・Helm� ・AWS Load balancer controller
・Karpenter
→EKS Auto Modeを参考にSREチームの管理下におくリソースを定義
[Terraform管理対象外](基本はhelmfile)
・管理対象以外のHelmリソース
・External Secrets
・External DNS
・KEDA
・Datadog
→利用ベンダー、CNCFコミュニティの成熟度を元に最低限のCustom Resourceのみを導入
1.EKSクラスタの管理の放置問題 - tfactionの導入
32
Terraformはモノレポで管理し、Terraform実行フローはtfactionをベースに作成
・エントリーポイントごとにjobの並列実行/lockfileの自動更新/trivy, tflintスキャンの実行
1.EKSクラスタの管理の放置問題 - RenovateによるTerraform/Helmの更新
33
Renovateのdefault.jsonを作成し、Org内の複数のRepositoryで共通設定を利用
・minReleaseAgeの指定/Group化によるPR数削減/ActionsのCommit hashの固定
1.EKSクラスタの管理の放置問題 - 改善前の当時のEKSの状況
34
当時はeksctl create cluster後、ほぼ何もしていない状態のEKSが塩漬けになって数年放置されていた
1.EKSクラスタの管理の放置問題 - ArgoCDの導入
35
開発環境、本番環境それぞれにOpsClusterとしてArgoCD用のEKSを構築
・1つのClusterから複数アカウントのワークロードクラスタを管理
各環境にArgoCDをインストールするのは手間
・dev
・test
・qa
・....
1.EKSクラスタの管理の放置問題 - ArgoCD Image Updaterの導入(v0.x)
36
各環境のベースブランチに対してPRを作成するようにImage Updaterを構成
・ApplicationSetでnewest-buildを指定
→同一のコミット内容でコミットハッシュが別のPRができてしまう問題があるため、各アプリケーション単位でブランチを固定
<env>環境の<Application>に対してのImage Tagの更新と分かるようでPRを作成
1.EKSクラスタの管理の放置問題 - ArgoCDに対する最低限のRBAC
37
Github Teamをベースとしてアクセス可能なApplicationを制御
・Custom ResourceはSREチームのみ、ワークロードのApplicationは各チーム管理
1.EKSクラスタの管理の放置問題 - マニフェスト/Helm管理
38
マニフェストはKustomize + Helmfileのシンプルな構成
・開発チーム/SREチームのそれぞれのリポジトリで管理
・各チームのアプリケーションはApplicationSet管理
・preserveResourcesOnDeletion:on/autoSync:off
・helmfile
・+αリソースはraw chartを利用し一括管理
・各種Security設定はSAST(弊チームメンバー製)+Trivyで検査
https://note.cover-corp.com/n/n39460f36d3ac
1.EKSクラスタの管理の放置問題 - Cluster管理
39
OpsClusterではEKS Auto Modeを使用
・管理工数を可能な限り下げたい(EKSの面倒を見れる人が少ない)
・現状管理用のクラスタのユースケースは限られており導入しやすい
・一部ワークロードの制約
・Fargateの利用
・Security for Podsの利用
・ノードの自動削除を許容できない(21日間)
Auto Mode採用
Auto Mode未使用
1.EKSクラスタの管理の放置問題 - 振り返り
40
変更容易性を手に入れワークロードクラスタに対してテコ入れがしやすくなった
Terraformでリソースを管理を統一できたことで、マルチアカウントのEKSクラスタ、アドオンのバージョンを容易に統一可能に
Org横断で利用可能なRenovateやtfactionのReusable Workflowの定義により、簡単なセットアップでセキュリティ、バージョン管理が可能に
Custom Resourceはhelmfileで管理し、ManifestはArgoCD管理下に置くことでGithubをSSoTとしたデプロイ基盤を構築
バックログ
41
構想をもとに改善を進めるために大枠の課題を分割した。
1.EKSクラスタの管理の放置問題
2.ワークロードクラスタの内部状態の可視化
3.Room管理とインスタンスのサイジングによるコスト適正化
4.オートスケールの改善
5.大規模利用における課題への対応
2.ワークロードクラスタの内部状態の可視化 - メトリクス
42
ホロアースリアルタイムサーバーとして観測可能なメトリクスとして下記がある
・一般的なKubernetesのメトリクス(CPU, Memory...etc)
・Custom Resourceのメトリクス(KEDA, Karpenter...etc)
・Diarkisがデフォルトで提供するメトリクス(Room数、パケット数...etc)
・Diarkisに登録したカスタムメトリクス(各エリアの人数、メッセージ数...etc)
https://help.diarkis.io/diarkis-server/metrics-api
2.ワークロードクラスタの内部状態の可視化 - Datadog Operator
43
Datadog Operatorを導入し、各Podレベルの状態を観測可能にする
・各NodeへDaemonSetとしDatadog Agentとして配置
・Datadog Cluster Agent経由でDiarkisのPrometheusのエンドポイントからメトリクスを収集
※リアルタイムに変わる指標取得するためエンドポイントへのアクセスは4~5秒に一回実行している
2.ワークロードクラスタの内部状態の可視化 - Datadog Tracing
44
Tick※に対して計装を行いカスタムロジックを観測可能な状態にする
※サーバーが一定間隔でゲーム状態を更新する処理
ex)TickのカスタムロジックではRedisに対してRoom情報を同期している、ユーザー影響が大きい箇所には計装を行いエラー率およびレイテンシを監視
2.ワークロードクラスタの内部状態の可視化 - Trace Agentの分離
45
APMを有効化したDatadog AgentはDatadog のバックエンド(SaaS)へトレースを送信したホストがAPM Hostとしてカウントされる
・デフォルトだとNode数分がAPM Hostとしてカウントされコストが高い
→アプリケーションPodからのTraceの送信先を統合する(Trace Agentを切り出す)
2.ワークロードクラスタの内部状態の可視化 - ダッシュボードとアラート
46
同接数、ワークロードのパケット数(IN/OUT)、CPU Usage等の指標を収集し、
ダッシュボード・Slackへアラート・オートスケールに活用をしている
2.ワークロードクラスタの内部状態の可視化 - 振り返り
47
EKSにDatadogを導入したことでリアルタイムサーバーも含め観測可能な状態となった
Diarkis/Kubernetes どちらのメトリクス・トレースを収集することができ、リアルタイムサーバーのボトルネックの調査が可能に
ダッシュボード・アラートを整備することで、開発チームも簡単にリアルタイムサーバーの状態を確認可能に
バックログ
48
構想をもとに改善を進めるために大枠の問題を分割し進めた。
1.EKSクラスタの管理の放置問題
2.Kubernetesの内部状態の可視化
3.Room管理とインスタンスのサイジングによるコスト適正化
4.オートスケールの改善
5.大規模利用に向けて
3.Room管理とインスタンスのサイジングによるコスト適正化 - Room管理
49
ホロアースでは様々なエリア※があり、そのほとんどのエリアの1Roomが1Node上の1Podに対して割り当てられるようになっている※ユーザーが遊んだり交流できる場所
3.Room管理とインスタンスのサイジングによるコスト適正化 - Room管理
50
Diarkis Roomの制約上、位置同期は同じRoom(Hostnetworkが有効化されたPod)に対して行われる
・Diakisはリレーサーバーのような使い方をしているため、人数に比例してサーバー側のI/Oの負荷が高くなる
3.Room管理とインスタンスのサイジングによるコスト適正化 - Room管理
51
過去ホロアースにおいてはc5n.4xlarge EC2インスタンスにおいて秒間アウトバウンドのパケット処理数が24万あたりを超えると、経験則的に安定運用ができないとされていた。
n: Room内のプレイヤー数
f: 同期頻度（updates/second）
インバウンド(クライアント→サーバー): PPS_in = n × f
アウトバウンド(サーバー → クライアント): PPS_out = PPS_in× (n - 1)
PPS_total = n² × f となり大体O(n^2)でパケットの量が指数関数的に増加する
実数値を当てはめるとn=200人, f=6回
PPS_total=24万Pakets/second 経験に基づくと1Roomあたり200人が限界...?
3.Room管理とインスタンスのサイジングによるコスト適正化 - 計測1
52
[計測1]
c5n.4xlargeで200人(動き続けるBOT)を1Roomへ投入、ネットワークのIN/OUTの状態を計測
[結果1]
200人到達前にユーザーがルームから追い出され計測が中断された。
・追い出し時に下記のENAドライバーのメトリクスは特に観測されなかった。
・bw_in_allowance_exceeded
・bw_out_allowance_exceeded
・pps_allowance_exceeded
・CPU使用率は40~50%程度
→NICのI/Oではなくアプリケーション側に問題があると判断、暫定的な対応として1Roomの上限人数を設定し運用を行うことにした。
3.Room管理とインスタンスのサイジングによるコスト適正化 - 計測2
53
[計測2]
c5n.4xlarge ~ c5n.xlargeで100人(動き続けるBOT)を投入、ネットワークのIN/OUTの状態を計測
[結果2]
・どのパターンも下記のENAドライバーのメトリクスは特に観測されなかった。
・bw_in_allowance_exceeded
・bw_out_allowance_exceeded
・pps_allowance_exceeded
・CPU使用率は4xlarge:5%, 2xlarge:10%, xlarge:20%とコア数に対してほぼ線形に推移していた。
→Diarkis社と相談しピークのCPU使用率が20%程度で運用するのが良いと判断したため、
1Room 100人を上限としてc5n.xlargeでUDPサーバーのインスタンスで運用を決断
3.Room管理とインスタンスのサイジングによるコスト適正化 - 帯域幅
54
EC2にはベースライン/バースト帯域幅があり、c5n系ではバースト帯域幅は同じでもベースライン帯域幅に差がある。
今回はNetworkOutの合計が最大で2GB/min程度であったため、帯域幅の差は運用に問題はないという判断だった。
https://docs.aws.amazon.com/ja_jp/ec2/latest/instancetypes/co.html#co_network
3.Room管理とインスタンスのサイジングによるコスト適正化 - 最新の機能
55
最新のホロアースでは、タレントのみ複数のRoom間の状態を同期する仕組みがリリースされている
・Roomに対しての人数制限があったとしてもタレントとユーザーの交流が可能な仕組みが実装されている
https://holoearth.com/news/ver110-update/
3.Room管理とインスタンスのサイジングによるコスト適正化 - 振り返り
56
EC2のサイジングを行なったことにより、EKSのコストを大幅に下げることができた。
c5n.4xlargeからc5n.xlarge系のEC2インスタンスの変更により、AWSの料金の大幅削減を行うことができた
ENAドライバーのメトリクスまで収集できたことで、今後の運用の際に観測するべき指標を整理することができた
バックログ
57
構想をもとに改善を進めるために大枠の問題を分割し進めた。
1.EKSクラスタの管理の放置問題
2.Kubernetesの内部状態の可視化
3.Room管理とインスタンスのサイジングによるコスト適正化
4.オートスケールの改善
5.大規模利用に向けて
4.オートスケールの改善
58
ホロアースではピークタイム以外で以下の2パターンのスケールが起こりうる
・事前に予定されたイベント: タレントの降臨祭等
・突発のイベント: Youtubeでのタレントのホロアース配信等
4.オートスケールの改善
59
ホロアースではピークタイム以外で以下の2パターンのスケールが起こりうる
・事前に予定されたイベント: タレントの降臨祭等
・突発のイベント: Youtubeでのタレントのホロアース配信等
事前に予測できるものではないため
オートスケールが必須
4.オートスケールの改善 - 元々のオートスケール運用
60
UDP PodのCPUの使用率は低めにでる傾向があり、一般的なCPUベースのHPA+Cluster Autoscaleだと高速にかつ精度よくRoomを増やすことが非常に難しい
・ユーザーが動かなければ位置同期の必要がない
・ユーザーはコストの高い動きを常にするわけではない(エモート等)
→不要な同期の処理が減り、CPUの使用率が下がる
4.オートスケールの改善 - 元々のオートスケール運用
61
UDP PodのCPUの使用率は低めにでる傾向があり、一般的なCPUベースのHPA+Cluster Autoscaleだと高速にかつ精度よくRoomを増やすことが非常に難しい
・ユーザーが動かなければ位置同期の必要がない
・ユーザーはコストの高い動きを常にするわけではない(エモート等)
→不要な同期の処理が減り、CPUの使用率が下がる
CPU使用率は低いが
Roomの人数は満員に近い状況があり得る
4.オートスケールの改善 - Datadogのカスタムメトリクスの利用
62
UDPサーバーにおいてRoom数を正確にスケールアウトさせるためにDatadogMetricを定義する
・Roomに対するカスタムメトリクスを新規に定義
・各エリアごとの合計人数
・各Roomに対して1人以上の参加者がいる合計Room数
[Room占有率]
・1ルームあたりの平均参加者数の割合
クエリ: 各エリアごとの合計人数
/ 各エリアのRunningのPod数 × Room数 >= 0.5
[アクティブRoom率]
・全ルームのうち、参加者がいるルーム数の割合
クエリ: 各エリアごとの参加者がいるRoom数
/ 各エリアのRunningのPod数 × Room数 >= 0.5
4.オートスケールの改善 - KEDAを導入
63
下記のどちらのパターンにも柔軟に対応するためにKEDAの導入を検討
・事前に予定されたイベント: タレントの降臨祭等: Metrics API
・突発のイベント: Youtubeでのタレントのホロアース配信等: Datadog Scaler
→複数のTriggerを組み合わせ柔軟なスケールを行うことができる
https://keda.sh/docs/2.18/scalers/metrics-api/
https://keda.sh/docs/2.18/scalers/datadog/
4.オートスケールの改善 - KEDAとDatadogを連携(Datadog Scaler)
64
DatadogのTriggerを構成し、各エリアごとに定義されたDatadogMetricを評価する
(評価間隔はHPAと同じ15秒、現状EKSでは15秒以下にはできない。https://github.com/aws/containers-roadmap/issues/1809)
・Cluster Agent Proxyを利用: Datadog APIのレート制限を考慮
・データの収集: Cluster Agent側の構成で4~5秒でカスタムメトリクスを収集
・Cluster Agent <-> KEDA間はBound Service Account Tokensを利用しTokenの管理を簡素化
4.オートスケールの改善 - KEDA(Metrics API Scaler)と管理用APIを連携
65
Metrics APIのTriggerを構成し、APIのレスポンスに定義されたレプリカ数へスケールさせられるようにする
・External metrics(MetricsType: Value)では、
desiredReplicas = ceil(currentMetricValue / targetValue) の
計算式で評価されるため、targetValueを1に設定しておくことでAPIレスポンスの値がそのままDesiredReplica数となり、マニフェストを触らずにPodをスケールさせられる
4.オートスケールの改善 - Karpenter検討
66
元々はCluster Autoscalerを活用していたが、Auto Modeの登場や移行事例等を踏まえ、ホロアースのユースケースにも合致していたためKarpenterの導入を検討
・EC2 Fleet APIを直接コールするためEC2の起動が早い
・NodePoolごとに細かくDisruptionを制御できる
https://aws.amazon.com/jp/blogs/news/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/
4.オートスケールの改善 - Karpenter導入
67
ホロアースにおいてはNodeの管理コストを下げ、細かい中断制御を行うためにKarpenterを全てのクラスタへ導入を行なった
[導入背景]
管理面
・ UDP用のNodeGroupがエリアごとに定義されておりManaged NogeGroupの管理が煩雑になっていた
コスト面
・開発環境でSpotインスタンスが活用できていなかった
その他
・UDPサーバーはNode単位のスケールアウトとなるため、EC2の起動速度を改善させたかった
・本番環境の中断時間を細かく制御したかった
4.オートスケールの改善 - Karpenter運用考慮点
68
NodeClass
・IMDSを利用しているためホップカウントを2に設定
・AMIを固定(AMIの更新AL2→AL2023でNIC名が変更)
・[開発環境]maxPodsを調整しIPの割り当て数を増加(VPC CNI のPrefix Delegationを有効化)
NodePool
・[開発環境]Spot Instanceを優先的に使用
・Diarkisの各コンポーネントごとにNodePoolを分割しインスタンスタイプを割り当てる
・expireAfter: Neverで運用、イベント時にNodeの入れ替えが起きないようにしている
※AutoModeでは21日の生存期間があるが、メンテナンス時間をコントロールできず導入を断念した
・[本番環境]DisruptionはDiarkisのWorkload Podが存在しない場合 & ピーク時間以外のみ行う
・consolidationPolicy: WhenEmpty
・budgets: 特定時間内のみ許可、nodeは1台ずつ減らす(それ以外は0台)
4.オートスケールの改善 - 本番環境のスケールイン運用
69
KEDAのScaleDown PolicyはCronJobによって特定時間のみ有効化
4.オートスケールの改善 - 本番環境のスケールイン運用
70
スケールアウトしたPod及びNodeを特定時間内のみスケールインするようにしている
・Node(Karpenter): terminationGracePeriod
・Pod: terminationGracefulPeriodSeconds
・Diarkis: DIARKIS_SHUTDOWN_TIMEOUT
スケールインが許可される時間帯の場合:
PodにSIGTERM
猶予時間(セッションは維持される)
PodにSIGKILL
Node削除
[Consolidation]
WhenEmptyの状態のNodeから1Nodeずつ削除
4.オートスケールの改善 - 振り返り
71
KEDAとKarpenterによってオートスケールの最適化を行うことができた
KEDA導入により複数のtriggerを設定し、柔軟にオートスケールを調整可能に
カスタムメトリクスの活用によってDiarkisのワークロードにあったスケール方法を定義が可能に
Karpenter導入によってNodeのプロビジョニングが大幅に改善し、NodePoolの管理とコストの削減に
バックログ
72
構想をもとに改善を進めるために大枠の問題を分割し進めた。
1.EKSクラスタの管理の放置問題
2.Kubernetesの内部状態の可視化
3.Room管理とインスタンスのサイジングによるコスト適正化
4.オートスケールの改善
5.大規模利用に向けて
5.大規模利用に向けて - 大型イベントに関して
73
ホロアースのイベント時、リアルタイムサーバーの同接は数千人以上となる
・特にタレントが絡む場合は特定エリアと移動先に負荷が集中するため、移動対象となるエリアは基本的に全てのエリアを事前にスケールアウトさせておく必要がある
同接数 / (100人/Room) ×エリア数 ≒ Node数
例えば移動対象が5エリアあり、3000人の同接が予想される場合は150Node程度あらかじめ起動させる必要がある
5.大規模利用に向けて - PodとNodeの配置と可用性
74
AZは3つに分散し、DeploymentにpodAntiAffinityを設定
・1Node 1 Pod(UDP)として扱うようにしている
ZoneA
ZoneB
ZoneC
Area A
Area B
Area C
Area A
Area C
Area A
Area B
Pod Topology Spread Constraints(maxSkew:1, whenUnsatisfiable: ScheduleAnyway)を設定し、可能な限りZone分散を行う
5.大規模利用に向けて - パフォーマンス問題1 メトリクス収集の遅延
75
イベント時にDiarkisのPrometheus Endpoint(via Service)が遅延が発生
[当時の状況]
・Cluster AgentからDiarkisへのリクエストがTimeOut
→メトリクスの収集ができず、オートスケール、ダッシュボードが停止
→暫定でタイムアウトを伸ばしたが、1データポイントの取得に1分以上かかっていた...
5.大規模利用に向けて - パフォーマンス問題1 メトリクス収集の遅延
76
開発環境で複数のパターンで負荷実験を行い原因を調査
・Room数/Node(Pod)数それぞれを増やすパターンで検証
・time curl -s http://<svc>/metrics/prometheus/v/3を実行し、平均をとる
5.大規模利用に向けて - パフォーマンス問題1 メトリクス収集の遅延
77
開発環境で複数のパターンで負荷実験を行い原因を調査
・Room数/Node(Pod)数それぞれを増やすパターンで検証
・time curl -s http://<svc>/metrics/prometheus/v/3を実行し、平均をとる
Node数の増加がレイテンシ増加の主要因であることがわかった
5.大規模利用に向けて - パフォーマンス問題1 メトリクス収集の遅延
78
根本原因を探るためにNode数を増やした状態で、HTTP Serverに対してプロファイリングを実施
・pprofを仕込み計測
5.大規模利用に向けて - パフォーマンス問題1 メトリクス収集の遅延
79
根本原因を探るためにNode数を増やした状態で、HTTP Serverに対してプロファイリングを実施
・pprofを仕込み計測
内部の文字列の結合処理が負荷を与えていることが判明
→GOGC or GOMEMLIMITをいじってGCの頻度を調整
→最終的にDiarkis社と相談し、パッチを当ててもらいメトリクスの計算の内部ロジックを差し替えた
5.大規模利用に向けて - パフォーマンス問題1 メトリクス収集の遅延
80
結果HTTP Serverへの負荷偏りは消え、メトリクス収集の遅延は解消された
・1PodにCPU負荷が集中してしまっていたために、水平分散が適切に行えていなかった問題も同時に解決
→HTTP Server用のNodePoolの見直しとPodのCPU Requestを調整しコスト削減、可用性向上に繋がった
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
81
イベント時にCoreDNS全体への負荷が非常に高くなる現象が起きていた
[当時の状況]
・事前スケールアウト中(2000人~)にCoreDNSのCPUの使用率が100%付近に...
・直後にイベントを控えていたため、この時は直接Replica数を増やして緊急対応...
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
82
UDPサーバーを増やした際にCoreDNSの負荷が増加することはわかっていたため、状況を再現し原因調査を進めた
・CoreDNSはデフォルトの2Replicaのまま、UDPサーバーの台数を増やし調査
→CoreDNSのmetricsのエンドポイントにcurl
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
83
UDPサーバーを増やした際にCoreDNSの負荷が増加することはわかっていたため、状況を再現し原因調査を進めた
・CoreDNSはデフォルトの2Replicaのまま、UDPサーバーの台数を増やし調査
→CoreDNSのmetricsのエンドポイントにcurl
NOERROR: 517,036回
NXDOMAIN: 1,993,104回
※該当するドメイン名が存在しない
存在しないドメインに対してのアクセスが集中していた
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
84
UDPサーバーを増やした時に負荷増加するため、UDPのPodからのアクセス先を確認
・/etc/resolv.confを確認したところ、search対象のドメインとndots:5が指定されていた(デフォルト値)
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
85
UDPサーバーを増やした時に負荷増加するため、UDPのPodからのアクセス先を確認
・/etc/resolv.confを確認したところ、search対象のドメインとndots:5が指定されていた(デフォルト値)
→ドットの数が 5未満の場合にサーチリストに指定されているドメインを末尾に追加して名前解決
→結果として存在しないドメイン名へのアクセスが大量発生していた
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
86
UDPサーバーを増やした時に負荷増加するため、UDPのPodからのアクセス先を確認
・/etc/resolv.confを確認したところ、search対象のドメインとndots:5が指定されていた(デフォルト値)
→ドットの数が 5未満の場合にサーチリストに指定されているドメインを末尾に追加して名前解決
→結果として存在しないドメイン名へのアクセスが大量発生していた
UDPのPodが増えるとMarsのServiceに対しての名前解決が大量発生していたことが判明
→DeploymentのdnsConfigをndots: 1として設定し、
常にFQDNとして解決されるように修正
5.大規模利用に向けて - パフォーマンス問題2 CoreDNSの負荷
87
同等の対応をDatadogのNodeAgent等にも行うことで、NXDOMAINの数はほぼ0となり、Replica数2の状態でCoreDNSのCPU使用率はピーク時の1/4程度に
CoreDNSはEKS Addonで管理しているため、
Terraformに対してautoScalingの設定を追加し、さらなるPod数の増加にも対応した
5.大規模利用に向けて - 振り返り
88
大規模なNode運用に向けてパフォーマンス上の課題へ対応し、イベントを乗り越えるための基盤を整備ができた
リアルタイムサーバーの可用性を向上させるためにNodeの配置戦略を見直した
大規模イベント時に起きたパフォーマンス上の課題を負荷試験を行いながら改善し、安定運用が可能なようにチューニングを行なった
今後の展望とまとめ
05
89
89
今後の展望
90
開発環境のEKSを1つにまとめ、コストおよび運用の最適化を目指す
・各環境ごとにEKSを運用
・固定バージョン１つのみ
・共通EKSを1つを運用
・namespaceごとにバージョンを可変に
まとめ
91
Thank You!
92