こんにちは、ウォンテッドリーでインフラエンジニアをしている田中です。ついに KubeCon + CloudNativeCon Japan 2025 が始まりました。

ウォンテッドリーでは2016年に Kubernetes を本番導入し、2025年現在も運用を続けています。Kubernetes や CloudNative 技術に関する一大イベントである KubeCon + CloudNativeCon が今回初めて国内で開催されるとあって、早期から Kubernetes を導入してきたコミュニティの一員としてこの大きな波に積極的に関わり、経験や知見の共有ができればと思い参加をしています。

昨日の Japan Community Day の記事に引き続き、 Infra Squad の田中（@bgpat）、加藤（@kkato）、巨畠（@donkomura）の3名から現地の盛り上がりの様子と、肌で感じた最新の技術トレンドをブログ形式でお届けします。

印象に残ったセッション

まずはメインコンテンツであるセッションの中から、各自が特に印象に残ったと感じた発表について紹介します。

New Cache Hierarchy for Container Images and OCI Artifacts in Kubernetes (巨畠)

Kubernetes の内部実装に依らないケーススタディではワークロードに固有でない学びが多いのではないかと思い探していたところ興味深い発表があったのでご紹介します。

Kubernetes を運用しているとコンテナの起動に時間がかかることが往々にしてあります。 ある調査によると、コンテナ起動時間の 76% がイメージ取得に費やされており、そのうちの 6.4% の時間しかデータを読んでいなかったことが報告されています。 つまり、コンテナ起動にかかる時間のうち大半がイメージのダウンロードにかかっているということです。

この発表の登壇者が所属する Preferred Networks（以下、PFN）は AI/ML ワークロードを主としたスーパーコンピュータを開発・運用している日本の企業で、PFN の計算クラスタでは基盤に Kubernetes を利用しています。 AI/ML ではイメージサイズが大きい傾向にあり、PFN で利用しているイメージサイズはなんと 20GB もあるようです。

この発表では、コンテナイメージのプルにかかる時間を改善するために開発した CIRC というクラスタキャッシュを解説しています。また、CIRC を運用している中で出てきた問題とその対処についても紹介されました。結果として、Pod 起動時間を20%削減し、週当たりのデータ転送量を23TB削減したというインパクトのある発表でした。

CIRC は PFN で開発・運用されている、イメージのクラスタ間キャッシュを実現するためのシステムです。 アーキテクチャは下図のようになっており、OCI Distribution Specification と containerd をバックボーンに設計・実装されています。 仕組みとしてはイメージをオリジンであるレジストリからプルしようとしたときに、CIRC 経由でプルするように containerd に実装しておきます。 CIRC にキャッシュがあればそれを利用し、キャッシュがなければレジストリに問い合わせてイメージをキャッシュします。

スライド資料より抜粋

CIRC には以下のような機能・特徴があります。

• 透過性
• • マニフェストを変更する必要がない
  • 任意のレジストリを扱える
• マルチテナンシー
• • クラスタ内でのキャッシュの共有
  • 安全に共有するための認可の仕組み
• Preheating
• • イメージをプッシュする際にキャッシュにもイメージを入れる
  • 初回キャッシュ時の遅延を最小化できる
• OCIアーティファクト
• • KEP-4639 VolumeSource: OCI Artifact and/or Image
  • Pod 間で OCI artifacts を共有することでAI モデルを効率的に読む

ここでは個人的に気になった透過性を実現するための仕組みについて説明します。 Containerd のコンテナレジストリ設定を追加することで CIRC 経由でイメージをプルすることができます。

# /etc/containerd/certs.d/_default/hosts.toml
[host."http://circ.internal"]
capabilities = ["pull", "resolve"]

また、複数のコンテナレジストリに対応するために、コンテナレジストリのドメインをクエリパラメータとして受け取るように実装しています。 マニフェストの image の値を分析して、このパラメータの値を設定することができます。 こうすることで、マニフェストごとに異なるレジストリのイメージを使っていても適切にオリジンからプルすることができますし、キャッシュも適切に選ぶことができます（バージョンについても同様と思われます）。

GET http://circ.internal/v2/NAME/blobs/DIGEST?ns=quay.io

これらを OCI Distribution Specification を標準として実装し、マニフェストには手を加えずにキャッシュを導入することを可能にしていました。

CIRC の解説に加えて、セッションでは CIRC を運用してわかった課題とそのために何をやったかについても紹介がありました。

• Bootstrap Problem
• • CIRC の bootstrap 時のフォールバックが非常に遅い（20分以上かかる）
• Thundering Herd Problem
• • 複数の Pod が起動時に同時にプルするとオリジンへのアクセスが複数走ってしまう
  • キャッシュが完了するまで待ってもらう

ここでは bootstrap problem について紹介します。 CIRC の起動が遅れた状態で Pod が先に起動してしまうと、Pod は CIRC に接続を試みるものの応答がないためタイムアウトします。タイムアウトするとフォールバック先のオリジンのレジストリからイメージプルが実施されます。数分でフォールバックしてほしいところですが、運用していく中でフォールバック先に切り替わるまでに20分以上かかるケースが見つかりました。調査すると containerd の hostConfig でタイムアウト設定が30秒でハードコードされていたことが要因だとわかったそうです。

私はこのことを始めて知ったのですが、確かにレジストリが Kubernetes で提供されていて、CNI の準備ができていない場合などではフォールバックに時間がかかりそうです。 今まで困らなかったのでしょうか...？ともあれこの問題は Youki でおなじみの utamoku さんによって起票・修正され、hostConfig からタイムアウトの秒数を設定できるようになりました。これによってフォールバックまでの時間を調整することでブートストラップ時の待ち時間を短縮することができたそうです。

• Allow timeouts to be set in hostConfig in Configure Image Registry #10660

本発表ではコンテナ起動時間を短縮するために PFN で開発した CIRC の紹介と CIRC を運用する中で出てきた課題をどうやって解決したかについて解説されました。 ウォンテッドリーを含めたウェブサービスを提供する企業でこの規模のイメージを日常的に扱うことは稀かもしれません。しかし、開発を頻繁に行っている場合にはその分デプロイする回数も多くなり、そうなればイメージをプルする回数も増え、コンテナ起動にかかる時間も全体として多くなると推測できます。 したがって、プルの最適化はウェブサービスの開発者であっても価値のあるものだと思います。 また今回のキャッシュシステムは、High Performance Computing 分野ではストレージノードがあることが一般的なのでこうしたストレージレイヤをオーバーレイするようなストレージシステムをクラウドネイティブの文脈でうまく活用している良い実例だと思います。AI/ML のコンテナイメージは巨大化しているので、こうしたキャッシュ機構やデータの効率利用のためのケーススタディは今後も発展するものと思われます。

Never Underestimate Memory Architecture (田中)

田中からは Kubernetes 上で稼働するアプリケーションのパフォーマンス改善に役立つ知見を得ようと聴講した Grafana Labs の Bryan Boreham 氏による NUMA (Non-Uniform Memory Access) に関する発表を紹介します。

NUMA は、複数の CPU を搭載するシステムにおいて採用されている物理的なメモリ設計です。この設計では、各 CPU が直接アクセスできるメモリ領域（ローカルメモリ）を持つ一方で、他の CPU に接続されたメモリ領域（リモートメモリ）には間接的にしかアクセスできません。本セッションでは、このような設計がとられる理由の具体的な説明はありませんでしたが、CPU とメモリを結ぶバスの共有を制限することで動作クロックを向上させる技術として用いられているようです。

この「直接アクセス可能な CPU とメモリの対」（= NUMA ノード）について実際のコンピューター内部の写真を用いて、各 NUMA ノード間に物理的な距離が存在することを視覚的に説明していました。さらに同じ NUMA ノード内のメモリアクセスと異なるノード間のメモリアクセスでは、ベンチマーク結果で明確なレイテンシー差が見られることが示され、これがクラウド上で動作するアプリケーションのパフォーマンスにも影響を及ぼすと強調されていました。

スライド資料 より抜粋

NUMA は各社クラウドベンダーが採用しているサーバーにも採用されていますが、 NUMA に関するスペックはドキュメントに書かれていないことも少なくありません。例として挙げられていた AWS のインスタンスではドキュメントの記載がなく、実際に起動した後に lscpu コマンドを用いて NUMA ノードの配置について確認する方法が紹介されていました。例えば m5a.12xlarge では3ノード、m7g.16xlarge では1ノードといった具体的な情報が共有されました。NUMA ノードの数は、CPU のアーキテクチャや利用するインスタンスのサイズによって異なるため、利用するインスタンスの選定においても NUMA の特性を意識する必要があることを喚起していました。

セッションの後半は Kubernetes 上でサービスを運用する際の注意点や対処法が説明されました。

何も考慮せずにサービスをデプロイした場合、Pod が複数の NUMA ノードを跨いで配置されてしまいパフォーマンス劣化を招く可能性があります。これを効率よく適切に取り扱うための CPU Manager や Topology Manager といった Kubernetes の機能が紹介され、これらの機能を活用することで NUMA の影響を軽減できることが説明されました。

また、大きいインスタンスを使用すると NUMA ノードも増加する傾向にあるため、NUMA ノードを跨ぐことによるパフォーマンス劣化のリスクが高まります。OS カーネルや  kubelet などのオーバーヘッドも考慮しつつ、可能な限り小さいインスタンスの利用を推奨していました。

このセッション全体を通して、普段私たちが利用している AWS のようなクラウド環境でも NUMA のような低レイヤーな技術を意識する必要があるという事実に改めて驚かされました。NUMA という効率良く高速化を行うためのハードウェア設計に触れることで、CPU やメモリの設計技術そのものにも興味が湧きました。また、クラウドを利用しているからといってこれらの技術が完全に抽象化・隠蔽されるわけではなく、むしろパフォーマンスを最大限に引き出すためには、そうした特性を理解し、適切に対処すべきであるという重要な気付きを得られました。実際に Kubernetes で運用する際の具体的な対処法も学ぶことができたため、今後、より効率的にコンピューティングリソースを利用できるプラットフォームを目指して取り組んでいきたいと思います。

No More Disruption: PlayStation Network's Approaches To Avoid Outages on Kubernetes Platform (加藤)

このセッションでは PlayStation Network (PSN) がいかにして 99.995% という高い稼働率を実現しているのか、その具体的な取り組みが紹介されました。

PSNは、Amazon EKS + Karpenterを基盤に、50以上のクラスターが稼働しています。この大規模なインフラを、米国に50名、日本に10名というグローバルチーム体制で運用しています。

まず Pod の可用性に関しては、ノードの起動が遅いという問題に対し、従来の Cluster Autoscaler に代わり Karpenter を導入することで、ノードの起動時間を大幅に短縮し、迅速なスケーリングを実現しました。また、CoreDNS の Pod が頻繁に CPU Throttling を起こしていた問題に対しては、CPU Limit を設定しないという大胆なアプローチを採用し、 CoreDNS の Pod の安定稼働が可能になったとのことでした。

続いてメンテナンスに関しても、多数のアドオンを手動でアップグレードしていたため運用負荷が高いという問題がありました。スモークテストを実施し、正常であれば次のステップへ進み、異常があれば自動でロールバックする仕組みを導入し、アドオンのアップグレードをほぼ自動化することで、運用負荷を大幅に軽減することができました。また、Managed Node Group (MNG) で管理するとノードの再起動が必要となる課題に対しは、Karpenter を導入することで、ロールアウトやアップグレードの自動化と無停止での実行を可能にしました。

アーキテクチャの部分でも課題がありました。高い可用性や安定性が求められるアプリケーションが、他のワークロードの影響で意図せず削除されるケースがあり、これに対し、他のワークロードの影響を受けないように専用ノードを割り当てることで、重要アプリケーションの安定性を確保しました。

組織と運用の改善にも取り組まれたようです。チーム内の知識や情報のギャップを解消するため、ナレッジ共有会を定期的に開催し、組織全体のスキルアップを図りました。また、多くのオペレーションミスが発生していた問題に対し、Kyverno ポリシーを導入することで誤操作を防げるようにしました。そして、属人化していた運用を改善するため、Architecture Decision Record (ADR) や Runbook などを整備し、標準化を進めました。

このセッションの中で何度も強調されていたのが、「普通のことを普通にやる」という言葉でした。既存の OSS やベストプラクティスにしっかりと従い、地道に、丁寧に、着実に運用を積み重ねていく。その一つ一つの積み重ねこそが、99.995%という高い稼働率を支えているのだと強く感じました。ウォンテッドリーでも参考にできそうな取り組みが多くあり、多くの学びが得られたセッションでした。

参考: スライド資料

会場の様子

セッション以外の会場の様子も紹介します。

会場の入口です。イベントが始まる前のバッジピックアップには長蛇の列ができていました。

Keynote セッション後の Coffee Break です。スポンサーブースを回る人も多くいました。

昼食は2種類のお弁当が用意されていました。私は偶然隣になった台湾の学生さんとコミュニケーションを取りながら過ごしました。

全セッション後のレセプションでは美味しい食事が提供され、各社の取り組みや運用上の課題について踏み込んだ話を聞くことができ非常に有意義な時間となりました。過去にウォンテッドリーのインターンシップに参加してくれた方や、勉強会で知り合った方に声をかけていただくなど、嬉しい再会も多数ありました。

まとめ

KubeCon + CloudNativeCon Japan 2025 のDay1が終了しました。

インターネット上ではなかなか得られない、最新の技術設計思想やコミュニティの動向を直接聞けたことは非常に大きな収穫でした。関連する複数のセッションを聞くことで、それぞれの技術に対する理解がより一層深まり、点と点が線でつながるような感覚を得られるのも現地参加の魅力だと思います。また、海外からの参加者が多いこともありますが、私が聴講したセッションはすべて英語で行われており、日本にいながら世界を肌で感じることができました。

Day0 (Community Day), Day1 に引き続き Day2 も同じメンバーで参加しています。会場でウォンテッドリーのメンバーを見かけた方はぜひ声をかけていただけると嬉しいです。