- はじめに
- KubeCon + CloudNativeCon Japan 2025 とは
- レポート
- さいごに
はじめに
こんにちは。プラットフォーム開発本部 第 3 開発部 認可チームの山本暉能です。 今回は、デジタルコンテンツ開発本部 メディア配信基盤開発部 配信インフラグループ SRE チームの片岡歩夢さんと一緒に、KubeCon + CloudNativeCon Japan 2025 に参加してきたので、その内容をお伝えします。
本記事では、前半を山本、後半を片岡が担当します。
KubeCon + CloudNativeCon Japan 2025 とは
KubeCon + CloudNativeCon Japan 2025 は、先日ついに日本で初開催された Kubernetes をはじめとしたクラウドネイティブ技術の祭典で、私たちも現地で参加してきました。 会場は国内外から集まったエンジニアたちで満員となり、コミュニティ全体の大きな熱量を感じる、活気にあふれた場となっていました。
今回のブログでは、特に印象的だったセッションについてレポートします。
レポート
Kubernetes SIG Node Intro and Deep Dive
まずは山本が個人的に一番興味があった、Kubernetes のノードに関するあらゆることを扱う「SIG Node」の入門と深掘りセッションについて紹介します。 youtu.be
そもそも SIG Node とは何か
コンテナを動かしたり止めたりといったライフサイクル管理から、パフォーマンスの監視、障害からの復旧まで、ノード上のあれこれを担当しています。
SIG Node が扱う主要なコンポーネントは以下の通りです。
| コンポーネント名 | 役割 |
|---|---|
| Kubelet | 各ノードの司令塔。コンテナを起動し、監視し、時には再起動させ、後片付けまで行います。 |
| Container Runtime | Kubelet からの指示を受けて、実際にコンテナを動かすエンジン部分です。 |
| Device Plugin | GPU や FPGA といった特別なハードウェアを、必要なコンテナに割り当てるのを手伝います。 |
| Node Problem Detector | ノードに何か問題が起きていないか常に見張り、コントロールプレーンに報告します。 |
| CSI (Container Storage Interface) / CNI (Container Network Interface) | コンテナのデータを永続化するためのストレージ接続や、ネットワークの設定を担当します。 |
セッションでは、SIG Node が今とくに力を入れている分野として「リソース管理」が挙げられていました。効率的なワークロードのためには欠かせない重要なテーマですね。
In-Place PodResize (インプレース Pod リサイズ):
この機能の特筆すべき点は、なんと言っても Pod を再起動することなく、動いているコンテナの CPU やメモリ割り当てを自由に変えられる点です。 リソース使用量の変動が激しい AI ワークロードや、起動に時間がかかる Java アプリ、Karpenter などでクラスターを自動スケールさせている環境では、運用が楽になります。 以前のバージョンではリソース変更の反映に少し時間がかかるという課題がありましたが、v1.33 で改善され、よりスピーディーに更新できるようになりました。
Sidecar Containers (サイドカーコンテナ):
Kubernetes v1.33 (2025 年 4 月リリース) に GA（一般提供）になったばかりの、注目すべき新機能です。 サイドカーコンテナは、メインのコンテナと同じ Pod 内で IP アドレスやストレージを共有し、メインコンテナより先に起動して、Pod が終了するまで動き続けます。 この仕組みを使えば、アプリケーションコードを一切変更せずに、mTLS で通信を暗号化したり、高度なログ収集機能を追加したり、といったことが効率的に実現できます。 なお、もともとあった Init コンテナの仕組みを拡張する形で実装されています。 Init コンテナは本来、初期化タスクを終えたら終了するものでしたが、サイドカーとして動き続けられるように改良されたわけです。 これまでのサイドカーパターンでは、メインアプリとの起動・終了順序が保証されず、タイミングの問題に悩まされることがありました。 しかし、ネイティブサポートされたこの機能ではライフサイクルが厳密に保証されるため、サービスメッシュやロギングエージェントのような、Pod と一対一で動く仕組みの信頼性が格段に向上したと言えます。
DRA (Dynamic Resource Allocation - 動的リソース割り当て):
DRA は、GPU などのハードウェアアクセラレーターを、もっと柔軟かつ効率的に使うための新しい仕組みです。 特に AI ワークロードのように、ハードウェアを細かく制御したいというニーズに応えるために設計されました。
DRA が解決してくれる「よくある悩み」は、主にこの 2 つだと思います。
悩み 1：高価な GPU、もっと有効活用したいのに…
これまでの Kubernetes では、GPU のような高価なリソースは 1 つのワークロードが占有しがちで、実はあまり使われていない時間もコストだけがかかる…という、リソースの利用効率の低い状況がありました。
DRA ならこう解決！
複数のワークロードや Pod 内のコンテナで、1 つの GPU を共有できるようになります。 これにより、リソースの利用率が上がり、コストの最適化につながります。 「時間単位で分割して使う（時間共有）」や「メモリ領域を分割して使う（空間共有）」といった、より高度な割り当ても可能です。 AI/ML で発生しがちなメモリ不足や、巨大なモデルのダウンロード時間といった課題の解決も期待できます。
悩み 2：特殊なハードウェアの管理が複雑で大変…
従来の Device Plugin では、GPU をはじめとしたハードウェアごとの細かい設定や、柔軟な割り当てが難しいという側面がありました。
DRA ならこう解決！
コンテナや Pod 間でデバイスを柔軟に共有したり、デバイスに設定パラメータを渡したりといったことが、宣言的にできるようになります。 これにより、多様なハードウェアの管理方法が標準化され、複雑な要件にも効率的に対応できるわけです。
DRA は 2022 年に登場し、2024 年に大きく再設計されました。 その中核となる structured parameters(構造化パラメータ)機能は現在ベータ版で、Kubernetes 1.34 での GA を目指しているとのことでした。
コントリビュート方法
「Kubernetes に貢献する」と聞くと、高度な専門知識を持つエンジニアのみが貢献できるというイメージがあるかもしれませんが、セッションでは様々な関わり方があると紹介されていました。
- KEP (Kubernetes Enhancement Proposal) のレビュー
- CI（継続的インテグレーション）の改善
- バグ報告や修正
- コードレビューへの参加やフィードバック
- ドキュメントの作成や翻訳
- 新機能をいちはやく試して、フィードバックを送る
- 各 SIG の定例ミーティングに参加してみる
- もちろん、新機能の設計や実装も！
コードを書くことだけが貢献ではありません。 ドキュメントを分かりやすくしたり、フィードバックを送ったりすることも、プロジェクトにとっては非常に価値のある立派なコントリビュートと言えます。
No More Disruption: PSN’s Approaches To Avoid Outages on Kubernetes Platform
ここからは、メディア基盤開発部の片岡が、自身が行っているメディア配信基盤プラットフォームの構築に役立ちそうなセッションや、個人的に興味があったソニー・インタラクティブエンタテイメント社(以下SIE社)のセッションについて記載します。
本セッションは、SIE 社が提供するサービス、PSN のための Kubernetes プラットフォームが、どのようにエンドユーザへの可用性 99.995%を達成したかについて発表されていました。
はじめに SIE 社の Kubernetes プラットフォームは、以下のように極めて大規模であることが紹介されました。
- サービス数は100 以上
- 使用チームは数十チーム
- クラスタ数は50 以上
一般的にシステムは大規模になればなるほど、可用性を高く保つことが難しくなります。
SIE 社では高い可用性を維持するために、"Doing the Basics Right" "普通のことを普通にやる" という当たり前のようですが難しいことを進め、様々な課題を泥臭く潰していくことで高可用性を維持していました。
課題は下記の通り様々な軸にあり、どれも難易度の高い課題です。 しかし、それらに対して 1 つ 1 つ対応し、問題となっていた箇所を確実に潰していたことが印象的でした。
その課題の中で、特に興味深い 4 つの課題について細かく紹介します。
- 組織としての課題
- アーキテクチャの課題
- メンテナンスの課題
- Kubernetes 特有のトラブルについての課題
組織としての課題
SIE 社は 2020 年まで、US に 3 チーム、JP に 1 チームの 4 チームのプラットフォームエンジニアリングチームを抱えていました。 しかし、2021 年に "Platform Unification" と称してそれらのプラットフォームエンジニアリングチームを 1 チームに纏めます。
そしてこのチームが、複数の PSN のサービスを共有の Kubernetes クラスタ上で動かす、Unified Kubernetes Service (UKS) プラットフォーム を開発します。 このプラットフォームがAWS EKS 上に構築されていることも、合わせて紹介されました。
チームや部署どころか国籍まで違う中で、それらを 1 つにまとめると決断し、更にその後 4 年で大規模プラットフォームを高い可用性で運用するところまで達しているスピード感は、見習わなくてはならないと強く感じさせられました。
アーキテクチャの課題
PSN という大規模なシステムを共有の Kubernetes クラスタで動かすにあたって、様々な "Real-World Challenge" にぶつかります。 その中でも大規模 Kubernetes アーキテクチャにありがちな課題として、「特殊な要件や、より高い可用性が求められるサービス」の存在が挙げられます。
この問題に対し、SIE 社のプラットフォームチームは「分離」という手段を用いて解決しました。
分離には 2 つのレベルがあります。ノードレベルの分離と、クラスタレベルの分離です。
例えば重要なアドオン Pod は、特定のノードを占有させることで他の Pod によるノイジーネイバー問題を回避できます。 一方で、コンプライアンス上特殊な要件を持つサービスについては、そもそも共有クラスタに含めず、専用のクラスタに分けてクラスタレベルで分離したことが紹介されました。
ただし、クラスタ分離はKubernetes運用における銀の弾丸にはなりません。 "言うは易く行うは難し" なやり方で、運用・メンテナンスの負荷が増大する、いわば諸刃の剣となりうる手法です。
このクラスタ分離によって、新たにメンテナンスの課題が生まれます。
メンテナンスの課題
前述のアーキテクチャでお話したとおり、UKS プラットフォームはマルチクラスタを採用しました。 しかし、単体でも運用負荷の高い Kubernetes クラスタを複数運用するわけですから、当然運用負荷が大きく上がります。
SIE 社はこの問題に対して、クラスタ、ノード、アドオンのアップグレードの自動化という手段を取りました。
具体的には以下のような自動化を行い、運用負荷を低減したことが紹介されました。
- クラスタのアップグレードの妨げとなる非推奨 API の使用を回避するため、Helm Chart の自動更新システムを作成する
- ノードのアップグレード時のノード削除を妨げる不適切な PDB 設定を Kyverno のポリシーチェックで無効化する
Kubernetes 特有のトラブルについての課題
Kubernetes は大規模なアプリケーションのため、Kubernetes 特有の課題が存在します。 例えば以下のような課題が発表されていました。
- アップグレードやメンテナンス中の Pod 可用性低下
- ノードの起動遅延によるスケーリング速度の低下
- CoreDNS の CPU スロットリング
この中でも、特に面白いと感じたのが CoreDNS の CPU スロットリングの解消に、cpu limit を設定しない という手段を取ったことです。
この方法はたしかに仕様上可能ですが、一般に Kubernetes プラットフォームは、作り込まれているほど Pod ごとに limit/request を正しく設定している印象があったため、あえてそれを消す、という手段を取ったことには驚きました。
この点について質問したところ、CoreDNS の Pod が usage 上は limit を上限に達していなくとも、速度低下していることがあった、など興味深い内容をさらに聞くことができました。 Kubernetes は Pod 間通信など様々なところで DNS に頼っているため、DNS 周りの性能劣化はクラスタ全体に影響を及ぼします。
こういった視点は普段の運用だと中々身につかないもので、大変参考になりました。
まとめ
今回の記事で記述した SIE 社のセッション以外にも、2Node で HA クラスタを動かすために分散合意アルゴリズムの Raft を使って etcd を冗長化する、といった野心的なプロジェクトのセッションもあり、興味が尽きない 2 日間でした。
また技術だけでなく、組織設計の考え方など様々な視点からのインプットを得ることができ、とても勉強になるイベントでした。
さいごに
弊社では、クラウドネイティブなプラットフォームを作る仲間を募集しています。 パブリッククラウドはもちろん、プライベートクラウドに興味がある方も、ぜひお気軽にご応募ください！ dmm-corp.com
