こんにちは。SREチームの吉澤です。インフラコストマネジメントというプロジェクトも兼務している関係で、最近はAWSのCost Explorerを眺めることが多い毎日です。
KubeCon + CloudNativeConが、6/16(月)〜17(火)に日本初開催されました!アンドパッドからはSREチームから2名(私と角井)が参加しました。
今回は、このKubeCon + CloudNativeCon Japan 2025の様子と、現地参加したメンバーによるおすすめセッションをご紹介します。これから発表資料や動画で、セッションの内容を確認する方の参考になれば幸いです。
- 会場の様子
- SREメンバーがおすすめするセッション
- SREチーム吉澤のおすすめ
- Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms - Puja Abbassi, Giant Swarm
- Multi Cluster Magics With Argo CD and Cluster Inventory - Kaslin Fields, Google
- Keynote: From ECS To Kubernetes (and Sometimes Back Again): A Pragmatist's Guide To Migration - Marc Hildenbrand, Canva
- Never Underestimate Memory Architecture - Bryan Boreham, Grafana Labs
- SREチームマネージャー角井のおすすめ
- No More Disruption: PlayStation Network’s Approaches To Avoid Outages on Kubernetes Platform - Tomoyuki Ehira & Shuhei Nagata, Sony Interactive Entertainment
- Kubernetes SIG Node Intro and Deep Dive - Narang Dixita Sohanlal, Google; Paco Xu, DaoCloud; Hironori Shiina, Independent
- Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms - Puja Abbassi, Giant Swarm
- Standardizing on Multi-Cluster App Topologies for Platforms With Linkerd - William Rizzo, Mirantis & Erick Bourgeois, Independent
- SREチーム吉澤のおすすめ
- イベント全体を通しての感想
- 7月開催イベントのお知らせ
- We are hiring!
会場の様子
会場はヒルトン東京お台場の1F。自分の名前が書かれたバッジを受け取って会場へ。
会場が広い分、スポンサーブースもかなり多く、様々な展示がありました。スポンサーブースの場所はホワイエや専用の部屋に分散していたにも関わらず、どこも盛況でした。
国内企業は自社事例紹介、海外企業はKubernetesユーザー向けの製品紹介が多いように見えました。私は後者のブースを中心に回りました。国内のSREイベントでは見ない製品も多く、勉強になりました。
1日目の夜にはWelcome Receptionがありました。1Fすべてが会場で、そのあちこちで大勢のエンジニアが熱心に話し合う姿は圧巻でした!
SREメンバーがおすすめするセッション
ここからは、現地参加したSREメンバーによる、おすすめセッションのご紹介です。現地で聴講したセッションのなかから、1人あたり数本に厳選しました。
なお、ほとんどのセッションは、発表資料が公式サイト上で公開されています。例えば、CNCFのCTOであるChris Aniszczyk氏のキーノートの場合は、下図の赤丸の部分からダウンロードできます。
KubeCon + CloudNativeCon Japan 2025の動画は、すでにYouTubeのCNCFチャンネルで公開されています。公式サイトの各セッションのページからも視聴できます。
SREチーム吉澤のおすすめ
Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms - Puja Abbassi, Giant Swarm
登壇者がVPoPを務めるGiant Swarmは、企業向けのKubernetesプラットフォーム管理のアウトソーシングを受け持つ企業。その中での経験に基づくセッションと思われます。Platform Engineeringで意識すべきことがまとまった、面白いセッションでした。
Platform EngineeringにおけるDay 1とは、Backstageのようなセルフサービスポータルを使ってサービスを作るまで。Day 2とはプロダクトがリリースされたあとのすべて。このセッションでは、Day 2のよくある苦労を紹介したのち、そのような苦労を避けるためにすべきこと、Day 0から心がけるべきことを紹介していました。
資料p.29の "Strategies for Avoiding Day 2 Hell" にあった、バージョニングをサポートするツール(Helm Charts、OCI、CRDs、GitOps、Crossplane revisions)の重要性には強く共感しました。
また、最後に示された結論(Lessons Learned & Best Practices)もよくわかる内容だったのですが、どれも徹底が難しそうな項目で、Platform Engineeringの範囲の広さを改めて感じました。
Multi Cluster Magics With Argo CD and Cluster Inventory - Kaslin Fields, Google
登壇者は、Google CloudのCloud Runtimes DevRel Manager兼Co-Chair of SIG Contributor Experience in Open Source Kubernetes。マルチクラスタが必要になる理由、これまでの経緯、標準化状況のわかりやすい解説でした。
複数のKubernetesクラスタをまたがってワークロードをデプロイ・管理したいというニーズは昔からあり、発表ではそのニーズを以下のように整理していました。
- 地理的位置の考慮:レイテンシや、データグラビティ(特定のデータの近くでワークロードを動かす必要がある)
- 分離の必要性:コスト、セキュリティ、組織
また、Cluster Managerの機能を持つOSSや、クラウドプロバイダーからの提供機能はすでに多数存在することを、リストで示されていました。類似機能の再発明を防ぐために、Kubernetes SIG Multiclusterでは以下の標準化が進められているとのこと。
- Multicluster Services (MCS) API
- 2020年に提案・実装。クラスタを超えたサービスへのアクセスを目的としたAPI。ServiceExport、ServiceImport、ClusterSet CRD
- ClusterProfiles API
- 2023年に提案。マルチクラスタ環境でKubernetesクラスタを表現するための標準。”Cluster Inventory” conceptとClusterProfile CRD
セッションの最後には、Google製OSSのMulticluster Orchestrator(MCO)の紹介がありました。
ちなみに、他のセッション(Project Lightning Talk: Open Cluster Management turns 1.0.0 - Hip Hip Hooray!)ではRed Hat Advanced Cluster Management for KubernetesをもとにしたOSSが紹介されており、マルチクラスタ管理の関心の高さを感じました。
Keynote: From ECS To Kubernetes (and Sometimes Back Again): A Pragmatist's Guide To Migration - Marc Hildenbrand, Canva
浮世絵をうまく使いながら、ECSからEKSへの移行の苦労を楽しく紹介してくれたキーノートセッションでした。
Canvaでは移行当初、バーンダウンチャートが理想(6ヶ月以内の完了)から大きく乖離していたとのこと。この遅れを取り戻した経験から得られた教訓(Lesson)と苦労(Villain)を以下のようにまとめていました。
- Lesson 1: Capabilities analysis
- Lesson 2: Gain (real) confidence
- Villain 1: Scaling
- Villain 2: Evictions
- Lesson 3: Have a way back
- Lesson 4: When ready, migrate quickly
個人的には、特にLesson 1の内容が興味深かったです。設定(configuration)はワークロードがそのプラットフォームに求める能力(capability)を暗に示していると考え、すべてのサービスが求めるcapabilityをリスト化し、最も多くのワークロードが求めるcapabilityから優先的に実装したそうです。
会場では文字が小さくてよく見えなかったのですが、後日発表資料を確認したところ、優先度の高いCapabilityにはAuto scaling、Traditional Canaries、Helm Release、Direct Scaling (CPU/Mem)、Release Branch Strategy、Slow Startなどが書かれていました。
Never Underestimate Memory Architecture - Bryan Boreham, Grafana Labs
Kubernetesのワーカーノードのパフォーマンス問題と、Non-Uniform Memory Access(NUMA)の関係を解説するセッション。普段意識しない話題で、興味深く聞きました。
セッションはまずNUMAの説明をした後で、クラウドサービスで実際に起こった問題が紹介されました。
AWS上で動作する複数のEC2インスタンスのうち、一部のインスタンスのCPU使用率が急上昇するという問題が起こり、原因を調べたところ、NUMA Node(CPUとメモリのグループ)をまたいだメモリアクセスが原因だとわかったそうです。
このようにパフォーマンス問題を考えるうえではNUMAの設定が重要ですが、例えばAWSの公式サイトにあるインスタンスタイプの一覧にはNUMAの設定が記載されていません。このセッションでは、NUMAの設定をlscpu
コマンドで確認する方法が示されていました。
また、NUMA boundaryを考慮した割り当てをさせるためのオプション(参考:Node Resource Managers)や、Topology Managerのsingle-numa-nodeポリシー(参考:Control Topology Management Policies on a node)が紹介されました。
EC2インスタンス内でのNUMA Nodeの分割を避けたいなら小さいインスタンスタイプを選べばよいが、そうするとインスタンス数が増えてインスタンス間の通信やインスタンスごとの余剰リソースが増える。パフォーマンスを突き詰めようとすると、なかなか難しい問題があるのだな、と理解しました。
SREチームマネージャー角井のおすすめ
No More Disruption: PlayStation Network’s Approaches To Avoid Outages on Kubernetes Platform - Tomoyuki Ehira & Shuhei Nagata, Sony Interactive Entertainment
こちらのセッションは非常に人気で、セッションルームが混雑しており私は立ち見になってしまいました。
PlayStation Network(PSN)が世界規模で50以上のKubernetesクラスタを運用し、99.995%という高い可用性を実現している事例紹介でした。印象的だったのは「普通のことを普通にやる」というメッセージです。特別なテクニックではなく、日々発生する課題を一つひとつ丁寧に解決し、ad-hocな対応を避けるという基本を徹底している点が強調されていました。
また、グローバルなチーム連携のためのドキュメント整備や、オーバープロビジョニングによるスケーリング高速化など、運用現場のリアルな工夫も多く紹介されており、規模の大小を問わず参考になる内容でした。「普通のこと」を大規模環境でやり切る難しさと、その重要性を再認識しました。
アンドパッドもベトナムにオフィスを2つ開設しており、グローバルなチーム連携が必要な環境なので、とても参考になりました。
Kubernetes SIG Node Intro and Deep Dive - Narang Dixita Sohanlal, Google; Paco Xu, DaoCloud; Hironori Shiina, Independent
KubernetesのコアコンポーネントであるNodeにフォーカスしたSIG(Special Interest Group)によるイントロ&ディープダイブセッションでした。今回は特に、Kubernetes 1.33や1.34で導入・強化された新機能が多数紹介されていました。
例えば、1.33でGAとなったサイドカーコンテナや、Podリソースのインプレース更新(In-Place Pod Resize)、Podのライフサイクル制御の強化(Sleep Action preStop hook)、CrashLoopBackOffの調整機能など、運用現場で役立つ実践的なアップデートが多く取り上げられていました。
中でもDynamic Resource Allocation(DRA)は、ストレージやGPUなど外部リソースの動的割り当てを柔軟に行える仕組みとして、今後の活用機会が非常に多そうな注目機能だと感じました。
DRAにより、リソース要求の多様化や自動化がさらに進み、SREやプラットフォームエンジニアの運用負荷軽減やコストコントロールに有用であることが期待できます。また、ブースでもこのDRAを活用しているであろう製品が紹介されており、印象的でした。
Platform Engineering Day 2: Why Service Iterations Are the Crux of Developer Platforms - Puja Abbassi, Giant Swarm
吉澤もこのセッションをおすすめとして紹介していますが、私も良いと思ったので別観点から紹介文を書きます。アンドパッドにかなり刺さっていそうですね!
このセッションでは、開発者プラットフォームの本質と、サービスのイテレーション(反復的な改善)がなぜ「Day 2」の運用フェーズで最重要となるのかが深く掘り下げられていました。 特に印象的だったのは、開発者とプラットフォームエンジニアの視点の違いが明確に示されていた点です。
App Developer wants to change the configuration
アプリケーション開発者は、しばしばKubernetesやプラットフォームの仕組み自体を深く理解していません。 それでも、アプリの設定変更やリソースの調整など、日々の運用に必要な作業は発生します。 こうした現場では、開発者は「何をどうすればいいのか分からない」「インフラの知識がなくて怖い」と感じることが多いのが実情です。
Platform engineer wants to roll out a new iteration of the platform product
一方でプラットフォームエンジニアは、プラットフォーム自体の新しいバージョンや機能を安全かつスムーズに展開し、開発者に素早く価値を届けたいと考えています。 ここで最も重要なのが「Enable self service」――すなわち、開発者が自分で必要な操作をセルフサービスで完結できる仕組みを提供することです。 この「セルフサービス化」こそがDay 2の本質であり、プラットフォームエンジニアリングの価値の源泉だと強調されていました。
このメッセージを受けて、私自身も現場で「開発者がプラットフォームの複雑さに悩まされず、本来の開発に集中できる環境」を作ることの重要性を再認識しました。セルフサービスの仕組みが整うことで、開発者はインフラやKubernetesの知識がなくても安全かつ迅速に設定変更やリソース追加などのDay 2オペレーションを実現できます。プラットフォームチームは、運用負荷を下げつつ継続的な改善(サービスイテレーション)を高速で回すことが可能になります。
また、セッションでは「Golden Path(推奨フロー)」の設計や、セルフサービスを支える内部開発者ポータルの役割、ガードレール(組織の標準やセキュリティ基準)の自動化など、実践的なノウハウも多数紹介されていました。
アンドパッドでもプラットフォームエンジニアリングに取り組んでおり、「開発者の自律性(セルフサービス)」と「継続的なサービスイテレーション」を両立させる仕組み作りを推進しているので、とても参考になるセッションでした。
Standardizing on Multi-Cluster App Topologies for Platforms With Linkerd - William Rizzo, Mirantis & Erick Bourgeois, Independent
公式サイト(この記事の公開時点で、発表資料の公開なし)
アンドパッドではサービスメッシュとしてLinkerdを採用しています。このセッションは、Linkerdユーザとして特に印象深く、多くの学びがありました。Cluster-API(CAPI)などの宣言型ツールとLinkerdを組み合わせて、社内開発プラットフォーム(IDP)のマルチクラスタトポロジを標準化・簡素化する方法をテーマにしたセッションでした。
大規模・マルチリージョン環境でのセキュリティ(mTLSによる暗号化)、トレーサビリティ、HA/DRなどの課題に対し、Cluster-API、Sveltos、k0rdent、Linkerdを組み合わせてインフラ構成やアドオン、ポリシーを一元管理する事例が紹介されていました。LinkerdのMulti-Cluster Extensionを活用することで、クラスター間通信のセキュリティやサービスディスカバリが容易になる点、Helmチャートによるライフサイクル管理の効率化など、実践的なノウハウが多く共有されていました。
Istioと比較した場合のLinkerdのシンプルさと導入容易性についても触れていました。Istioではマルチクラスタ構成が複雑になりがちですが、Linkerdは公式の拡張やコマンドで比較的シンプルに実現でき、ロードバランサーやGatewayを必須としません。ルーティング対象に含まれるクラスターがダウンしても、メトリクスベースでルーティングする設定により簡単にルートから外せます。
また、モニタリングや認証情報管理、サービスミラーリングなど、実際の運用で直面する課題とその解決策が具体的に語られており、自分の現場でも即活用できそうなアイデアが多く得られました。現場でLinkerdを使っている身として、とても興味深かったです。今後のマルチクラスタ運用やサービス拡張の設計に大いに役立つ内容でした。
イベント全体を通しての感想
KubeCon + CloudNativeConは日本初開催でしたが、1〜2日目とも、セッション・ブースとも常にほぼ満員で、過去に自分が参加したSRE関連のイベントを超える熱気を感じました。主催者発表によると、参加者1,500名分のチケットが売り切れたとのことでした。
発表内容はKubernetesの最新動向から、特定トピックの技術的な詳細、Kubernetesコミュニティへの参加方法など、多岐に渡っていました。私は主にKubernetesクラスタの運用管理やコスト削減に関係するセッション・スポンサーブースを回りましたが、それ以外の話題にも多く触れることができて、大きな刺激になりました。
アンドパッドからはSREチームから2名参加しましたが、会場で会った他社の知り合いから話を聞くと、勉強のためにSREだけでなく開発者も積極的に参加させていた企業もあったようです。
来年のKubeCon + CloudNative Con Japan 2026の開催もすでに発表されました。私は来年も是非参加したいですし、アンドパッドからの参加者もさらに増やせたらと思います!
最後に、KubeCon + CloudNativeConの日本への誘致に尽力された関係者の皆様に心から感謝申し上げます。また、このイベントに先立って開催されたKubernetes Novice Tokyo #ex KubeCon2025 & CNDS2025で初心者向けのアドバイスがあり、とても参考になりました。次回も同様のイベントを開催していただけると、私のような初心者の助けになると思います。
7月開催イベントのお知らせ
アンドパッドは、7/11(金)〜12(土)にTOC有明で開催されるSRE NEXT 2025に、コーヒースポンサーとして参加します!
コーヒーと一緒に、アンドパッドのxREチームの最新トピックをまとめたチラシも配布します。SREチームからは私と角井が参加しますので、ぜひお声がけください!チラシの内容よりもっと詳しいこともお答えします。
一般販売チケットは、この記事の公開時点ではまだ販売中です。もしご都合が合いましたら、当日は是非会場にお越しください。
We are hiring!
アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのマルチプロダクト戦略を支えるSREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。