KubeCon + CloudNativeCon Japan 2025 参加レポート

イベント概要

2025年6月16日～17日に、ヒルトン東京ベイで開催された「KubeCon + CloudNativeCon Japan 2025」に参加してきました。
日本での開催は初となり、チケットもソールドアウトとなるなど、大盛況となった本イベントの参加レポートをお届けします。

登壇は基本的に英語で行われましたが、「Wordly」という同時翻訳ツールを通じて日本語でもリアルタイムに内容を把握できる環境が提供されていました。

気になった登壇内容をピックアップ

Keynote: From ECS To Kubernetes (and Sometimes Back Again): A Pragmatist's Guide To Migration - Marc Hildenbrand, Canva

Canva社が、ECS上で動作していたアプリケーションをKubernetes（EKS）へ移行する過程と、その中で得られた知見を紹介するセッションでした。

特に印象的だったのは、Lesson 1「Capabilities Analysis」です。
Jupyterノートブックを用いて、ECS上で稼働しているサービスやタスクをカタログ化するアプローチが紹介されました。このカタログ化によって、下位レベルのサービス選定や、サービスごとの移行可否判断がより明確になったとのことです。

また、Lesson 3「Have a Way Back」では、移行中にダウンタイムを発生させない工夫として、ECSとEKSを並行稼働させ、トラフィックを徐々にEKSに切り替えるカナリアリリース手法を採用していた点が紹介されました。
ECSへのロールバック保証期間は2週間で、経営陣とのコスト交渉が非常に難しかったのではないかと感じました。

Multi Cluster Magics With Argo CD and Cluster Inventory or Don't Get Lost in the Clusterverse - Kaslin Fields, Google

- Part 1「A Tale as Old as Kubernetes」では、Kubernetesユーザーが利用する「名前空間」が、複数クラスター管理における問題解決に十分役立っていない点が指摘されました。
- その上で、マルチクラスターのユースケースを具体化し、必要な機能を明確にする重要性が語られました。
- Part 2「Exposing a Multi Cluster Use Case」では、実際のユースケースが紹介されました。

一例として「ワークロードの分離」が挙げられました。ワークロードを分離するには新たな名前空間だけでなく、クラスターリストの管理が必要となります。
現状ではOSSを含むツールが存在しているものの、Google Cloudはこれをさらに進め、クラスタリストの標準化を目指しているとのことです。

- APIによる統一的なクラスタ管理
- ベンダー独自実装の削減とツール間の互換性強化

標準APIの整備が進むことで、断片化されたツールや運用方法を統合的に扱える未来が期待されます。

No More Disruption: PlayStation Network’s Approaches To Avoid Outages on Kubernetes Platform - Tomoyuki Ehira & Shuhei Nagata, Sony Interactive Entertainment

本セッションは最も人気が高く、立ち見が最も多い盛況ぶりでした。
- 内容は、PlayStation Network（PSN）を支えるKubernetesのプラクティスについてです。
- PSNは昨年度、Kubernetesプラットフォームにおいて **99.995% の可用性** を達成したそうです。

その秘訣として強調されていたのは「Doing the Basics Right」（普通のことを普通にやる）という姿勢でした。

以前の環境では可用性が低く、特にCoreDNS周りで障害が多発していたとのことです。これに対し、以下のような改善が行われました。

可用性向上の取り組み

- PDB（Pod Disruption Budget）、PTSAの適切な設定
- スケジューリング偏りへの対策として Disruptive Scheduler を活用
- トラフィック急増時には Karpenter によるノードスケーリング

DNS安定化の取り組み

- CoreDNS Pod の分散をアンチアフィニティで徹底
- HPA（Horizontal Pod Autoscaler）の最小Pod数を増加し、不安定なスケールを抑制

さらに、技術的側面だけでなく、インシデント対応体制やドキュメント整備も徹底。
こうした「地味な基本の徹底」が、結果として高可用性を実現しているのだと強く感じました。

気になったスポンサーブースをピックアップ

ZOZOTOWN

[参考リンク: Gatling OSS vs Enterprise]

- ZOZOTOWNのブースでは、社内OSSから派生した「Gatling Operator」について説明を受けました。
- 開発のきっかけは、年末年始にトラフィックが急増するというプロダクト特性から、負荷試験の自動化が求められたことです。
- 当初はECS Fargate上で動作していましたが、Fargateはタスク実行ごとにリソース確保・準備が必要で、EC2と比べ起動時間が長くなる課題がありました。そのためKubernetesへの移行を進めたとのことです。

AWS

[参考リンク: Getting Started with Amazon EKS Auto Mode]

- AWSのブースでは **EKS Auto Mode** について紹介されました。
- 従来のEKS（Fargate）はプレーンなKubernetes環境に近い構成で、開発者がアドオンの設定やリソース管理を行う必要がありました。
- また、コスト管理のためには、想定されるCPU・メモリ使用量を基にインスタンスタイプを手動で選定する必要がありました。

一方でEKS Auto Modeでは以下が特徴として挙げられます。
- ノード管理が完全自動化され、Node GroupやLaunch Templateの管理が不要
- リージョンとVPCの指定のみでクラスタ作成が可能
- 自動でインスタンスタイプが選定され、コスト最適化が実現

Kubernetes初学者にとっても扱いやすく、導入のハードルを下げてくれるサービスだと感じました。

最後に（所感）

Canvaの登壇では、ECSからEKSへの移行にあたり、まず既存サービスの棚卸しを行い、Jupyterノートブックでの可視化を通じて移行可否の判断を行っていた点が印象的でした。一般的にはデータマネジメントの領域で用いられることが多い手法を、移行戦略に応用していた点が非常に興味深かったです。

また、PSNの事例からは、AIやクラウドネイティブといった派手な話題に目を奪われがちな中で、地味ながらも基本的なプラクティスを徹底することが、最終的には「99.995% の高可用性」という大きな成果につながるという教訓を得ました。

さらにAWSのEKS Auto Modeは、現在Kubernetes学習のコストに苦戦している自分にとって、「まずは簡単に触れてみる」ための有力な選択肢になると感じました。学習のモチベーションを大きく高めてくれるサービスだと思います。

おまけ

スポンサーブースで頂いたノベルティたち。かわいいです。