リアルタイムサーバー運用改善〜メタバースプラットフォームにおけるEKS運用とDatadog活用によるオートスケール実践〜

by COVER Corporation

Embed

Start on current slide

Slide 1

Slide 1 text

リアルタイムサーバー運⽤改善〜メタバースプラットフォームにおけるEKS運⽤とDatadog活⽤によるオートスケール実践〜 2025年11⽉18⽇ CloudNative Days Winter 2025 1

Slide 2

Slide 2 text

⾃⼰紹介 Toshiki Ishii CTO室インフラチーム所属ホロアースSRE(2024/10~) 興味: Edge Computing/Peformance Tuning 2

Slide 3

Slide 3 text

01 カバーについて 3

Slide 4

Slide 4 text

VTuberの多面的な特性を活かした事業展開日々の配信やライブイベントを通じて熱量の高いファンコミュニティを拡大。バーチャルアバターの特性を活かして多面的なコマース展開を行う多面的なコマース展開 VTuber IP・ファンベースを育成配信プラットフォームを通じたライブ配信オフライン/オンラインでのライブイベント開催フィジカル/デジタルの VTuberグッズ販売メーカー等への IPライセンスアウトやタイアップ広告等のプロモーション支援主な収益源 chメンバーシップ *2 、 Super Chat *3 チケット販売、関連物販自社/外部ECサイトでの販売ライセンシーからのロイヤリティ広告主からのプロモーション料主なコスト項目プラットフォーム手数料、演者分配ライブイベント制作費、演者分配販売手数料、グッズ原材料、演者分配制作費、演者分配サービス概要売上構成比 *1 （売上高前期比） 21.5％ 18.0％ 47.3％ 13.2％（YoY +21.9%）（YoY +39.1%）（YoY +64.6%）（YoY +29.4%） ※１：2025年3月期売上高に占める内訳 ※２：月額料金を支払いチャンネルメンバーになり、バッジ・絵文字、限定動画視聴等の特典を得られる制度 ※３： YouTubeのライブチャットを利用したライブ配信動画の公開時に視聴者が有料課金を行うことでチャットメッセージを目立たせることができる機能

Slide 5

Slide 5 text

02 ホロアースについて 5

Slide 6

Slide 6 text

メタバースプラットフォーム「ホロアース」ゲームとオンラインライブを主軸とした3Dエンターテインメントプラットフォームとして、世界中の⼈々が遊び、創造し、稼ぐ、が成⽴する世界を実現する © COVER Corp. 人気アニメーターによるアバター・衣装デザイン VTuber ライブ・コンサートファン・ミーティングアバター衣装等の仮想空間内アセットの製作・販売ユーザー 6

Slide 7

Slide 7 text

メタバースプラットフォーム「ホロアース」ユーザー間コミュニケーションを楽しめるオープンワールドプラットフォームとして、弊社ホロライブのタレントが降臨するイベントを積極開催中 7

Slide 8

Slide 8 text

03 SREのロードマップと課題 8

Slide 9

Slide 9 text

ホロアースSREロードマップ 2024年10⽉から最終⽬標のSLI/SLOアラートの運⽤を⾒据えて、監視基盤およびインフラ構成の⾒直しやプラットフォームエンジニアリングを進めている 2024/10 2025/4 2025/10 インフラ構成の⾒直しとプラットフォームエンジニアリング監視基盤構築/インフラ構築⽀援 2026/4 SLI/SLO 導⼊推進サーバーサイドのテレメトリデータを Datadogへ集約クライアントサイドへの Sentry導⼊ SLO導⼊計画策定アラート運⽤改善エラートラッキング実装 UJの洗い出しと成功率の可視化リアルタイム通信の Kubernetesの運⽤改善 UGCリリースの負荷試験‧インフラ構築⽀援 API Gateway/Database移⾏によるインフラの再構築新規リリースのインフラ構築⽀援 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

ホロアースSREロードマップ 2024年10⽉から最終⽬標のSLI/SLOアラートの運⽤を⾒据えて、監視基盤およびインフラ構成の⾒直しやプラットフォームエンジニアリングを進めている 2024/10 2025/4 2025/10 インフラ構成の⾒直しとプラットフォームエンジニアリング監視基盤構築/インフラ構築⽀援 2026/4 SLI/SLO 導⼊推進サーバーサイドのテレメトリデータを Datadogへ集約クライアントサイドへの Sentry導⼊システムの安定稼働のためにリアルタイムサーバーの運⽤を⾒直すことが最優先に SLO導⼊計画策定 (タレント降臨に伴う負荷増加に耐える必要が出てきた) アラート運⽤改善エラートラッキング実装 UJの洗い出しと成功率の可視化リアルタイム通信の Kubernetesの運⽤改善 UGCリリースの負荷試験‧インフラ構築⽀援 API Gateway/Database移⾏によるインフラの再構築新規リリースのインフラ構築⽀援 11

Slide 12

Slide 12 text

現在のシステム構成 12

Slide 13

Slide 13 text

現在のシステム構成クライアント ‧ホロアース(Desktop App): Unity ‧クリエイター⽤ツール(Web): React, WebGL メインのホロアースを遊ぶためのUnityビルドとUGCコンテンツを作成するためのWebサイトを開発‧運⽤ 13

Slide 14

Slide 14 text

現在のシステム構成各種テレメトリデータはクライアント‧サーバーごとそれぞれ監視 Saasへ集約クライアントサイド：Sentry サーバーサイド：Datadog 14

Slide 15

Slide 15 text

現在のシステム構成 ●API サーバー ●リアルタイムサーバー各機能ごとに別々のサーバーチームで開発‧運⽤ 15

Slide 16

Slide 16 text

現在のシステム構成ここの話 16

Slide 17

Slide 17 text

⼀般的なゲームサーバーとKubernetes ‧ゲームサーバーはステートフルなため負荷分散が難しい →Node IP経由でPodとUDP直接通信を⾏い、Ingress等での負荷分散が難しい ‧ゲームクライアントは特定のゲームサーバーインスタンスに直接接続する →⼀部のCaaSではNode IPの利⽤に制約があり、ゲームサーバー運⽤に不向き ‧⼤量のNode(VM)の管理を⾏う必要がある →KubernetesによるNodeプロビジョニングを活⽤したい 17

Slide 18

Slide 18 text

Diarkis(Room)について Statefulなサーバー運⽤を簡素化できる仕組みを提供する商⽤ソフトウェア ‧UDPでの⾼速な通信/HTTPによる接続先分散/MARSによるサーバーメッシュ ‧サーバーサイドへのカスタムゲームロジックの記述 ‧同接数等取得のためのメトリクス⽣成(Prometheus) ‧Goのバイナリのためポータビリティが⾼い 18

Slide 19

Slide 19 text

ホロアースのリアルタイムサーバーホロアースで利⽤している位置同期システムのこと ‧DiarkisのRoomモジュールを利⽤し、EKS上で運⽤している 19

Slide 20

Slide 20 text

ホロアースでのDiarkisユースケース同⼀Room内のユーザー間へのパケット(座標やエモート等のイベント)のブロードキャストを⾏っている 20

Slide 21

Slide 21 text

ホロアースにおけるEKS運⽤の課題 2025年の年始当時に抱えていた課題 ● リアルタイムサーバーとしての安定運⽤に難あり ○ 2025年4⽉にホロアースがv1.0としてリリース ■ これを機にタレントの協業を進めホロアースのユーザーを拡⼤していく⽅針へ ■ ⼤量のユーザーの流⼊‧⼤型のアップデートが潜む中が、⼤規模なトラフィックに対応できる構成‧運⽤体制ではなかった ● 開発⽣産性‧運⽤体制に難あり ○ EKSを運⽤できる⼈員が不⾜しており2023年ごろからほとんど塩漬けだった ■ Cluster/Addon等のアップデートや構成管理は全て⼿動(eksctl) ■ Github上のマニフェストの状態が稼働しているClusterの状態と⼀致しておらずいつ事故が起きてもおかしくない状況だった 21

Slide 22

Slide 22 text

ホロアースにおけるEKS運⽤の課題 2025年の年始当時に抱えていた課題 ● リアルタイムサーバーとしての安定運⽤に難あり ○ 2025年4⽉にホロアースがv1.0としてリリース ■ これを機にタレントの協業を進めホロアースのユーザーを拡⼤していく⽅針へ ■ ⼤量のユーザーの流⼊‧⼤型のアップデートが潜む中が、⼤規模なトラフィックに対応できる構成‧運⽤体制ではなかった ● 開発⽣産性‧運⽤体制に難あり ○ EKSを運⽤できる⼈員が不⾜しており2023年ごろからほとんど塩漬けだった ■ Cluster/Addon等のアップデートや構成管理は全て⼿動(eksctl) まずはSREチームの管理下に置き塩漬け状態 ■ Github上のマニフェストの状態が稼働しているClusterの状態と⼀致しておを脱却することで、Kubernetes運⽤におけらずいつ事故が起きてもおかしくない状況だったる最低限のセルフサービス化を⽬指す 22

Slide 23

Slide 23 text

ホロアースにおけるEKS運⽤の課題ホロアースの状況をプラットフォームエンジニアリングの成熟度モデルに当てはめ、 SRE‧ホロアース開発チーム双⽅が協業していけるような構想をした SREチームが専任としてEKSクラスタの運⽤に責任を持ち開発者との運⽤境界を定める ArgoCD等、業界標準のCI/CDツールの整備から既存の運⽤フローを再構築し直す共通で利⽤可能なインフラとしてTerraformによるIaC化とCRDの導⼊を進める開発チームが⾃⽴して横断リソースを運⽤できるようなドキュメンテーションする DatadogをEKSへ導⼊し、計測値を元に議論しながら改善を進められるようにする https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/#model-table 23

Slide 24

Slide 24 text

04 EKSプラットフォームへの道のり 24

Slide 25

Slide 25 text

バックログ構想をもとに改善を進めるために⼤枠の課題を分割した。 1.EKSクラスタの管理の放置問題 2.ワークロードクラスタの内部状態の可視化 3.Room管理とインスタンスのサイジングによるコスト適正化 4.オートスケールの改善 5.⼤規模利⽤に向けて 25

Slide 26

Slide 26 text

バックログ構想をもとに改善を進めるために⼤枠の課題を分割した。 1.EKSクラスタの管理の放置問題 2.ワークロードクラスタの内部状態の可視化 3.Room管理とインスタンスのサイジングによるコスト適正化 4.オートスケールの改善 5.⼤規模利⽤に向けて 26

Slide 27

Slide 27 text

1.EKSクラスタの管理の放置問題 - 改善前の当時のEKSの状況当時はeksctl create cluster後、ほぼ何もしていない状態のEKSが塩漬けになって数年放置されていた ● EKS関連リソースはIaC化されておらず全ての操作はeksctl(CFn)で⼿動管理 ● EKS Addon/CRDは無し ● 諸々のバージョンアップグレードに伴う検証フロー未整備 ● GitOpsの未整備 27

Slide 28

Slide 28 text

1.EKSクラスタの管理の放置問題 - ⽬指す形 Github上で⾃動デプロイを⾏うGitOpsのパイプラインが構成され、開発チームは必要なリソースのみにアクセスできる状態を⽬指した。 28

Slide 29

Slide 29 text

Slide 30

Slide 30 text

1.EKSクラスタの管理の放置問題 - Terraform化 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管理対象外](基本はhelmﬁle) ‧管理対象以外のHelmリソース ‧External Secrets ‧External DNS ‧KEDA ‧Datadog 30

Slide 31

Slide 31 text

1.EKSクラスタの管理の放置問題 - Terraform化 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管理対象外](基本はhelmﬁle) ‧管理対象以外のHelmリソース ‧External Secrets ‧External DNS ‧KEDA ‧Datadog →利⽤ベンダー、CNCFコミュニティの成熟度を元に最低限のCustom Resourceのみを導⼊ 31

Slide 32

Slide 32 text

1.EKSクラスタの管理の放置問題 - tfactionの導⼊ Terraformはモノレポで管理し、Terraform実⾏フローはtfactionをベースに作成 ‧エントリーポイントごとにjobの並列実⾏/lockﬁleの⾃動更新/trivy, tﬂintスキャンの実⾏ 32

Slide 33

Slide 33 text

1.EKSクラスタの管理の放置問題 - RenovateによるTerraform/Helmの更新 Renovateのdefault.jsonを作成し、Org内の複数のRepositoryで共通設定を利⽤ ‧minReleaseAgeの指定/Group化によるPR数削減/ActionsのCommit hashの固定 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

1.EKSクラスタの管理の放置問題 - ArgoCDの導⼊開発環境、本番環境それぞれにOpsClusterとしてArgoCD⽤のEKSを構築 ‧1つのClusterから複数アカウントのワークロードクラスタを管理各環境にArgoCDをインストールするのは⼿間 ‧dev ‧test ‧qa ‧.... 35

Slide 36

Slide 36 text

1.EKSクラスタの管理の放置問題 - ArgoCD Image Updaterの導⼊(v0.x) 各環境のベースブランチに対してPRを作成するようにImage Updaterを構成 ‧ApplicationSetでnewest-buildを指定 →同⼀のコミット内容でコミットハッシュが別のPRができてしまう問題があるため、各アプリケーション単位でブランチを固定環境のに対しての Image Tagの更新と分かるようでPRを作成 36

Slide 37

Slide 37 text

1.EKSクラスタの管理の放置問題 - ArgoCDに対する最低限のRBAC Github Teamをベースとしてアクセス可能なApplicationを制御 ‧Custom ResourceはSREチームのみ、ワークロードのApplicationは各チーム管理 37

Slide 38

Slide 38 text

1.EKSクラスタの管理の放置問題 - マニフェスト/Helm管理マニフェストはKustomize + Helmfileのシンプルな構成 ‧開発チーム/SREチームのそれぞれのリポジトリで管理 ‧各チームのアプリケーションはApplicationSet管理 ‧preserveResourcesOnDeletion:on/autoSync:off ‧helmfile ‧+αリソースはraw chartを利⽤し⼀括管理 ‧各種Security設定はSAST(弊チームメンバー製)+Trivy で検査 https://note.cover-corp.com/n/n39460f36d3ac 38

Slide 39

Slide 39 text

1.EKSクラスタの管理の放置問題 - Cluster管理 OpsClusterではEKS Auto Modeを使⽤ Auto Mode採⽤ ‧管理⼯数を可能な限り下げたい(EKSの⾯倒を⾒れ Auto Mode未使⽤ ‧⼀部ワークロードの制約る⼈が少ない) ‧Fargateの利⽤ ‧現状管理⽤のクラスタのユースケースは限られて ‧Security for Podsの利⽤おり導⼊しやすい ‧ノードの⾃動削除を許容できない(21⽇間) 39

Slide 40

Slide 40 text

1.EKSクラスタの管理の放置問題 - 振り返り変更容易性を⼿に⼊れワークロードクラスタに対してテコ⼊れがしやすくなった Terraformでリソースを管理を統⼀できたことで、マルチアカウントの EKSクラスタ、アドオンのバージョンを容易に統⼀可能に Org横断で利⽤可能なRenovateやtfactionのReusable Workﬂowの定義により、簡単なセットアップでセキュリティ、バージョン管理が可能に Custom Resourceはhelmﬁleで管理し、ManifestはArgoCD管理下に置くことでGithubをSSoTとしたデプロイ基盤を構築 40

Slide 41

Slide 41 text

バックログ構想をもとに改善を進めるために⼤枠の課題を分割した。 1.EKSクラスタの管理の放置問題 2.ワークロードクラスタの内部状態の可視化 3.Room管理とインスタンスのサイジングによるコスト適正化 4.オートスケールの改善 5.⼤規模利⽤における課題への対応 41

Slide 42

Slide 42 text

2.ワークロードクラスタの内部状態の可視化 - メトリクスホロアースリアルタイムサーバーとして観測可能なメトリクスとして下記がある ‧⼀般的なKubernetesのメトリクス(CPU, Memory...etc) ‧Custom Resourceのメトリクス(KEDA, Karpenter...etc) ‧Diarkisがデフォルトで提供するメトリクス(Room数、パケット数...etc) ‧Diarkisに登録したカスタムメトリクス(各エリアの⼈数、メッセージ数...etc) https://help.diarkis.io/diarkis-server/metrics-api 42

Slide 43

Slide 43 text

2.ワークロードクラスタの内部状態の可視化 - Datadog Operator Datadog Operatorを導⼊し、各Podレベルの状態を観測可能にする ‧各NodeへDaemonSetとしDatadog Agentとして配置 ‧Datadog Cluster Agent経由でDiarkisのPrometheusのエンドポイントからメトリクスを収集 ※リアルタイムに変わる指標取得するためエンドポイントへのアクセスは4~5秒に⼀回実⾏している 43

Slide 44

Slide 44 text

2.ワークロードクラスタの内部状態の可視化 - Datadog Tracing Tick※に対して計装を⾏いカスタムロジックを観測可能な状態にする ※サーバーが⼀定間隔でゲーム状態を更新する処理 ex)TickのカスタムロジックではRedisに対してRoom情報を同期している、ユーザー影響が⼤きい箇所には計装を⾏いエラー率およびレイテンシを監視 44

Slide 45

Slide 45 text

2.ワークロードクラスタの内部状態の可視化 - Trace Agentの分離 APMを有効化したDatadog AgentはDatadog のバックエンド(SaaS)へトレースを送信したホストがAPM Hostとしてカウントされる ‧デフォルトだとNode数分がAPM Hostとしてカウントされコストが⾼い →アプリケーションPodからのTraceの送信先を統合する(Trace Agentを切り出す) 45

Slide 46

Slide 46 text

2.ワークロードクラスタの内部状態の可視化 - ダッシュボードとアラート同接数、ワークロードのパケット数(IN/OUT)、CPU Usage等の指標を収集し、ダッシュボード‧Slackへアラート‧オートスケールに活⽤をしている 46

Slide 47

Slide 47 text

2.ワークロードクラスタの内部状態の可視化 - 振り返り EKSにDatadogを導⼊したことでリアルタイムサーバーも含め観測可能な状態となった Diarkis/Kubernetes どちらのメトリクス‧トレースを収集することができ、リアルタイムサーバーのボトルネックの調査が可能にダッシュボード‧アラートを整備することで、開発チームも簡単にリアルタイムサーバーの状態を確認可能に 47

Slide 48

Slide 48 text

バックログ構想をもとに改善を進めるために⼤枠の問題を分割し進めた。 1.EKSクラスタの管理の放置問題 2.Kubernetesの内部状態の可視化 3.Room管理とインスタンスのサイジングによるコスト適正化 4.オートスケールの改善 5.⼤規模利⽤に向けて 48

Slide 49

Slide 49 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - Room管理ホロアースでは様々なエリア※があり、そのほとんどのエリアの1Roomが1Node上の 1Podに対して割り当てられるようになっている※ユーザーが遊んだり交流できる場所 49

Slide 50

Slide 50 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - Room管理 Diarkis Roomの制約上、位置同期は同じRoom(Hostnetworkが有効化されたPod)に対して⾏われる ‧Diakisはリレーサーバーのような使い⽅をしているため、⼈数に⽐例してサーバー側のI/Oの負荷が⾼くなる 50

Slide 51

Slide 51 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - Room管理過去ホロアースにおいては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⼈が限界...? 51

Slide 52

Slide 52 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - 計測1 [計測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の上限⼈数を設定し運⽤を⾏うことにした。 52

Slide 53

Slide 53 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - 計測2 [計測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サーバーのインスタンスで運⽤を決断 53

Slide 54

Slide 54 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - 帯域幅 EC2にはベースライン/バースト帯域幅があり、c5n系ではバースト帯域幅は同じでもベースライン帯域幅に差がある。今回はNetworkOutの合計が最⼤で2GB/min程度であったため、帯域幅の差は運⽤に問題はないという判断だった。 https://docs.aws.amazon.com/ja_jp/ec2/latest/instancetypes/co.html#co_network 54

Slide 55

Slide 55 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - 最新の機能最新のホロアースでは、タレントのみ複数のRoom間の状態を同期する仕組みがリリースされている ‧Roomに対しての⼈数制限があったとしてもタレントとユーザーの交流が可能な仕組みが実装されている https://holoearth.com/news/ver110-update/ 55

Slide 56

Slide 56 text

3.Room管理とインスタンスのサイジングによるコスト適正化 - 振り返り EC2のサイジングを⾏なったことにより、EKSのコストを⼤幅に下げることができた。 c5n.4xlargeからc5n.xlarge系のEC2インスタンスの変更により、AWSの料⾦の⼤幅削減を⾏うことができた ENAドライバーのメトリクスまで収集できたことで、今後の運⽤の際に観測するべき指標を整理することができた 56

Slide 57

Slide 57 text

バックログ構想をもとに改善を進めるために⼤枠の問題を分割し進めた。 1.EKSクラスタの管理の放置問題 2.Kubernetesの内部状態の可視化 3.Room管理とインスタンスのサイジングによるコスト適正化 4.オートスケールの改善 5.⼤規模利⽤に向けて 57

Slide 58

Slide 58 text

4.オートスケールの改善ホロアースではピークタイム以外で以下の2パターンのスケールが起こりうる ‧事前に予定されたイベント: タレントの降臨祭等 ‧突発のイベント: Youtubeでのタレントのホロアース配信等 58

Slide 59

Slide 59 text

4.オートスケールの改善ホロアースではピークタイム以外で以下の2パターンのスケールが起こりうる ‧事前に予定されたイベント: タレントの降臨祭等 ‧突発のイベント: Youtubeでのタレントのホロアース配信等事前に予測できるものではないためオートスケールが必須 59

Slide 60

Slide 60 text

4.オートスケールの改善 - 元々のオートスケール運⽤ UDP PodのCPUの使⽤率は低めにでる傾向があり、⼀般的なCPUベースの HPA+Cluster Autoscaleだと⾼速にかつ精度よくRoomを増やすことが⾮常に難しい ‧ユーザーが動かなければ位置同期の必要がない ‧ユーザーはコストの⾼い動きを常にするわけではない(エモート等) →不要な同期の処理が減り、CPUの使⽤率が下がる 60

Slide 61

Slide 61 text

Slide 62

Slide 62 text

4.オートスケールの改善 - Datadogのカスタムメトリクスの利⽤ UDPサーバーにおいてRoom数を正確にスケールアウトさせるためにDatadogMetric を定義する ‧Roomに対するカスタムメトリクスを新規に定義 ‧各エリアごとの合計⼈数 ‧各Roomに対して1⼈以上の参加者がいる合計Room数 [Room占有率] ‧1ルームあたりの平均参加者数の割合 [アクティブRoom率] ‧全ルームのうち、参加者がいるルーム数の割合クエリ: 各エリアごとの合計⼈数クエリ: 各エリアごとの参加者がいるRoom数 / 各エリアのRunningのPod数 × Room数 >= 0.5 / 各エリアのRunningのPod数 × Room数 >= 0.5 62

Slide 63

Slide 63 text

4.オートスケールの改善 - KEDAを導⼊下記のどちらのパターンにも柔軟に対応するためにKEDAの導⼊を検討 ‧事前に予定されたイベント: タレントの降臨祭等: Metrics API ‧突発のイベント: Youtubeでのタレントのホロアース配信等: Datadog Scaler →複数のTriggerを組み合わせ柔軟なスケールを⾏うことができる https://keda.sh/docs/2.18/scalers/metrics-api/ https://keda.sh/docs/2.18/scalers/datadog/ 63

Slide 64

Slide 64 text

4.オートスケールの改善 - KEDAとDatadogを連携(Datadog Scaler) 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の管理を簡素化 64

Slide 65

Slide 65 text

4.オートスケールの改善 - KEDA(Metrics API Scaler)と管理⽤APIを連携 Metrics APIのTriggerを構成し、APIのレスポンスに定義されたレプリカ数へスケールさせられるようにする ‧External metrics(MetricsType: Value)では、 desiredReplicas = ceil(currentMetricValue / targetValue) の計算式で評価されるため、targetValueを1に設定しておくことでAPIレスポンスの値がそのままDesiredReplica数となり、マニフェストを触らずにPodをスケールさせられる 65

Slide 66

Slide 66 text

4.オートスケールの改善 - Karpenter検討元々は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/ 66

Slide 67

Slide 67 text

4.オートスケールの改善 - Karpenter導⼊ホロアースにおいてはNodeの管理コストを下げ、細かい中断制御を⾏うために Karpenterを全てのクラスタへ導⼊を⾏なった [導⼊背景] 管理⾯ ‧ UDP⽤のNodeGroupがエリアごとに定義されておりManaged NogeGroupの管理が煩雑になっていたコスト⾯ ‧開発環境でSpotインスタンスが活⽤できていなかったその他 ‧UDPサーバーはNode単位のスケールアウトとなるため、EC2の起動速度を改善させたかった ‧本番環境の中断時間を細かく制御したかった 67

Slide 68

Slide 68 text

4.オートスケールの改善 - Karpenter運⽤考慮点 NodeClass ‧IMDSを利⽤しているためホップカウントを2に設定 ‧AMIを固定(AMIの更新AL2→AL2023でNIC名が変更) ‧[開発環境]maxPodsを調整しIPの割り当て数を増加(VPC CNI のPreﬁx Delegationを有効化) NodePool ‧[開発環境]Spot Instanceを優先的に使⽤ ‧Diarkisの各コンポーネントごとにNodePoolを分割しインスタンスタイプを割り当てる ‧expireAfter: Neverで運⽤、イベント時にNodeの⼊れ替えが起きないようにしている ※AutoModeでは21⽇の⽣存期間があるが、メンテナンス時間をコントロールできず導⼊を断念した ‧[本番環境]DisruptionはDiarkisのWorkload Podが存在しない場合 & ピーク時間以外のみ⾏う ‧consolidationPolicy: WhenEmpty ‧budgets: 特定時間内のみ許可、nodeは1台ずつ減らす(それ以外は0台) 68

Slide 69

Slide 69 text

4.オートスケールの改善 - 本番環境のスケールイン運⽤ KEDAのScaleDown PolicyはCronJobによって特定時間のみ有効化 69

Slide 70

Slide 70 text

4.オートスケールの改善 - 本番環境のスケールイン運⽤スケールアウトしたPod及びNodeを特定時間内のみスケールインするようにしている ‧Node(Karpenter): terminationGracePeriod ‧Pod: terminationGracefulPeriodSeconds ‧Diarkis: DIARKIS_SHUTDOWN_TIMEOUT スケールインが許可される時間帯の場合: PodにSIGTERM PodにSIGKILL Node削除猶予時間(セッションは維持される) [Consolidation] WhenEmptyの状態のNodeから 1Nodeずつ削除 70

Slide 71

Slide 71 text

4.オートスケールの改善 - 振り返り KEDAとKarpenterによってオートスケールの最適化を⾏うことができた KEDA導⼊により複数のtriggerを設定し、柔軟にオートスケールを調整可能にカスタムメトリクスの活⽤によってDiarkisのワークロードにあったスケール⽅法を定義が可能に Karpenter導⼊によってNodeのプロビジョニングが⼤幅に改善し、 NodePoolの管理とコストの削減に 71

Slide 72

Slide 72 text

バックログ構想をもとに改善を進めるために⼤枠の問題を分割し進めた。 1.EKSクラスタの管理の放置問題 2.Kubernetesの内部状態の可視化 3.Room管理とインスタンスのサイジングによるコスト適正化 4.オートスケールの改善 5.⼤規模利⽤に向けて 72

Slide 73

Slide 73 text

5.⼤規模利⽤に向けて - ⼤型イベントに関してホロアースのイベント時、リアルタイムサーバーの同接は数千⼈以上となる ‧特にタレントが絡む場合は特定エリアと移動先に負荷が集中するため、移動対象となるエリアは基本的に全てのエリアを事前にスケールアウトさせておく必要がある同接数 / (100⼈/Room) ×エリア数 ≒ Node数例えば移動対象が5エリアあり、3000⼈の同接が予想される場合は150Node程度あらかじめ起動させる必要がある 73

Slide 74

Slide 74 text

5.⼤規模利⽤に向けて - PodとNodeの配置と可⽤性 AZは3つに分散し、DeploymentにpodAntiAﬃnityを設定 ‧1Node 1 Pod(UDP)として扱うようにしている ZoneA ZoneB Area A Area B Area C ZoneC Area A Area A Area B Area C Pod Topology Spread Constraints(maxSkew:1, whenUnsatisfiable: ScheduleAnyway) を設定し、可能な限りZone分散を行う 74

Slide 75

Slide 75 text

5.⼤規模利⽤に向けて - パフォーマンス問題1 メトリクス収集の遅延イベント時にDiarkisのPrometheus Endpoint(via Service)が遅延が発⽣ [当時の状況] ‧Cluster AgentからDiarkisへのリクエストがTimeOut →メトリクスの収集ができず、オートスケール、ダッシュボードが停⽌ →暫定でタイムアウトを伸ばしたが、1データポイントの取得に1分以上かかっていた... 75

Slide 76

Slide 76 text

5.⼤規模利⽤に向けて - パフォーマンス問題1 メトリクス収集の遅延開発環境で複数のパターンで負荷実験を⾏い原因を調査 ‧Room数/Node(Pod)数それぞれを増やすパターンで検証 ‧time curl -s http:///metrics/prometheus/v/3を実⾏し、平均をとる 76

Slide 77

Slide 77 text

5.⼤規模利⽤に向けて - パフォーマンス問題1 メトリクス収集の遅延開発環境で複数のパターンで負荷実験を⾏い原因を調査 ‧Room数/Node(Pod)数それぞれを増やすパターンで検証 ‧time curl -s http:///metrics/prometheus/v/3を実⾏し、平均をとる Node数の増加がレイテンシ増加の主要因であることがわかった 77

Slide 78

Slide 78 text

5.⼤規模利⽤に向けて - パフォーマンス問題1 メトリクス収集の遅延根本原因を探るためにNode数を増やした状態で、HTTP Serverに対してプロファイリングを実施 ‧pprofを仕込み計測 78

Slide 79

Slide 79 text

5.⼤規模利⽤に向けて - パフォーマンス問題1 メトリクス収集の遅延根本原因を探るためにNode数を増やした状態で、HTTP Serverに対してプロファイリングを実施 ‧pprofを仕込み計測内部の⽂字列の結合処理が負荷を与えていることが判明 →GOGC or GOMEMLIMITをいじってGCの頻度を調整 →最終的にDiarkis社と相談し、パッチを当ててもらいメトリクスの計算の内部ロジックを差し替えた 79

Slide 80

Slide 80 text

5.⼤規模利⽤に向けて - パフォーマンス問題1 メトリクス収集の遅延結果HTTP Serverへの負荷偏りは消え、メトリクス収集の遅延は解消された ‧1PodにCPU負荷が集中してしまっていたために、⽔平分散が適切に⾏えていなかった問題も同時に解決 →HTTP Server⽤のNodePoolの⾒直しとPodのCPU Requestを調整しコスト削減、可⽤性向上に繋がった 80

Slide 81

Slide 81 text

5.⼤規模利⽤に向けて - パフォーマンス問題2 CoreDNSの負荷イベント時にCoreDNS全体への負荷が⾮常に⾼くなる現象が起きていた [当時の状況] ‧事前スケールアウト中(2000⼈~)にCoreDNSのCPUの使⽤率が100%付近に... ‧直後にイベントを控えていたため、この時は直接Replica数を増やして緊急対応... 81

Slide 82

Slide 82 text

Slide 83

Slide 83 text

5.⼤規模利⽤に向けて - パフォーマンス問題2 CoreDNSの負荷 UDPサーバーを増やした際にCoreDNSの負荷が増加することはわかっていたため、状況を再現し原因調査を進めた ‧CoreDNSはデフォルトの2Replicaのまま、UDPサーバーの台数を増やし調査 →CoreDNSのmetricsのエンドポイントにcurl NOERROR: 517,036回 NXDOMAIN: 1,993,104回 ※該当するドメイン名が存在しない存在しないドメインに対してのアクセスが集中していた 83

Slide 84

Slide 84 text

5.⼤規模利⽤に向けて - パフォーマンス問題2 CoreDNSの負荷 UDPサーバーを増やした時に負荷増加するため、UDPのPodからのアクセス先を確認 ‧/etc/resolv.confを確認したところ、search対象のドメインとndots:5が指定されていた(デフォルト値) 84

Slide 85

Slide 85 text

5.⼤規模利⽤に向けて - パフォーマンス問題2 CoreDNSの負荷 UDPサーバーを増やした時に負荷増加するため、UDPのPodからのアクセス先を確認 ‧/etc/resolv.confを確認したところ、search対象のドメインとndots:5が指定されていた(デフォルト値) →ドットの数が 5未満の場合にサーチリストに指定されているドメインを末尾に追加して名前解決 →結果として存在しないドメイン名へのアクセスが⼤量発⽣していた 85

Slide 86

Slide 86 text

Slide 87

Slide 87 text

5.⼤規模利⽤に向けて - パフォーマンス問題2 CoreDNSの負荷同等の対応をDatadogのNodeAgent等にも⾏うことで、NXDOMAINの数はほぼ0となり、Replica数2の状態でCoreDNSのCPU使⽤率はピーク時の1/4程度に CoreDNSはEKS Addonで管理しているため、 Terraformに対してautoScalingの設定を追加し、さらなるPod数の増加にも対応した 87

Slide 88

Slide 88 text

5.⼤規模利⽤に向けて - 振り返り⼤規模なNode運⽤に向けてパフォーマンス上の課題へ対応し、イベントを乗り越えるための基盤を整備ができたリアルタイムサーバーの可⽤性を向上させるためにNodeの配置戦略を⾒直した⼤規模イベント時に起きたパフォーマンス上の課題を負荷試験を⾏いながら改善し、安定運⽤が可能なようにチューニングを⾏なった 88

Slide 89

Slide 89 text

05 今後の展望とまとめ 89

Slide 90

Slide 90 text

今後の展望開発環境のEKSを1つにまとめ、コストおよび運⽤の最適化を⽬指す ‧各環境ごとにEKSを運⽤ ‧共通EKSを1つを運⽤ ‧固定バージョン１つのみ ‧namespaceごとにバージョンを可変に 90

Slide 91

Slide 91 text

まとめ ● SREチームの管理下でEKSを管理し、開発チームと協⼒しながら新しいリアルタイムサーバー基盤を構築をした ● ⼤規模な運⽤に備えて信頼性‧可⽤性を向上させるために負荷試験や監視基盤の整備を⾏なった 91

Slide 92

Slide 92 text

Thank You! 92