KubeCon + CloudNativeCon Europe 2024 Day 3

はじめに

ZIPAIRの技術チームメンバーでKubeCon + CloudNativeCon Europe 2024へ参加しています。この記事ではDay 3に参加したセッションのレポートをお届けします。Day 1、Day 2もありますのでぜひご覧ください。Day 1、Day 2と同様に詳細は各担当者が追って記事を投稿いたしますが、本ブログでは概要だけお伝えいたします。
また、Day 3ではセッションの終了後、KubeCon+CloudNativeCon 2024 EU 日本交流会@パリイベントにも参加させていただきました。パリに集結した日本のCloudNativeに携わる技術者の方々と楽しいひと時を過ごすことができ、大きな刺激を受けることができました。

参加したセッション

Day 3にて次のセッションへ参加しました。

How Spotify Re-Created Our Entire Backend Without Skipping a Beat

SpotifyにてKubernetesクラスタを無停止にて再作成した事例が紹介されていました。クラスタをバージョンアップするのではなく、再作成する動機としては次のとおりです。

• 4,900回のプロダクションデプロイメント/日、3,200以上のマイクロサービスが存在します。大規模なスケールと、そのインフラストラクチャを効率的に管理し続けるために最適化が必要であることを示しています。
• SpotifyではGolden pathsと呼ばれるデプロイ方法が用いられ、多くのサービスがGolden pathsを利用しています。しかしながら、Golden pathsを使用しないサービスも徐々に増えており、それがクラスタの運用を難しくする一因となっているようです。

実際の作業にはHeadless Serviceが用いられクラスタ間にてサービスのロードバランシングを行っていたようです。アプリケーションの開発者が不自由を感じることなく、大規模クラスタを再作成した稀有な事例でした。

The Rustvolution: How Rust Is the Future of Cloud Native

Rustがクラウドネイティブの未来を担うというテーマで、Rustの基本的な言語デザインについて発表されていました。Rustが持つ変数の所有権やライフタイムといった仕様により、他言語と比較してよりランタイムエラーに強いコーディングが可能であると強調されていました。CloudNativeの文脈においてもRustの開発環境が整っているといった内容もありました。盛り上がりを見せているWASMエコシステムにおいてもRustの存在感が際立っており、今後の開発において無視できない言語になっていると感じました。

Keeping the Bricks Flowing: The LEGO Group's Approach to Platform Engineering for Manufacturing

レゴグループは、レゴブロック製造向けのプラットフォームエンジニアリングの事例を紹介しました。ヨーロッパ、北米、東アジアにわたり、大規模な処理基盤が展開されているとのことです。紹介された技術スタックには、RabbitMQ、Redis、PostgreSQLなどの一般的なものが含まれていました。また、プラットフォームの耐性を確認するために、詳細に計画されたカオスエンジニアリングが実施されているという点は特に印象的でした。

Securing 900 Kubernetes Clusters Without PSP

メルセデス・ベンツが管理する900以上のKubernetesクラスタにおいて、ポリシー制御ツールをどのように選定したが述べられていました。メルセデス・ベンツでは、ポリシー制御においてPodSecuirtyPolicyを使用していました。しかし、Kubernetesのバージョン1.25から削除されたためツールの移行先を探す必要に迫られたようです。候補としてKyverno、Open Policy Agent、Validating Admission Policyが挙げられました。柔軟性と実行パフォーマンスの観点からValidation Admission Policyが選定されていました。

Leveling up Wasm Support in Kubernetes

WebAssemblyをデプロイすることにより動作するサーバレスサービスSpin、及びWebAssemblyをKubernetesへデプロイして動作させるSpinKubeが紹介されていました。実際のデモでは100台以上のPodが瞬時に立ち上がっており、コンテナ以上に軽量な動作が期待できそうでした。

Maximizing Go's Capabilities with the WebAssembly System Interface

このセクションではGo言語がWASI Preview 1へ対応するまでの経緯について述べられていました。WebAssembly自体は1.11からサポートされており、WASI自体は1.21からサポートされているようです。WebAssemblyのコンパイルという観点にてTiny GoとGoの違いについても述べられており、TinyGoはGoでコンパイルされたバイナリよりもサイズが小さくなる傾向のようです。逆にTinyGoはGoと比較して実装されていない機能があるようです。

Multijuicer - OSS tooling for running web app sec training on k8s

ペンテストの練習やWebアプリケーションのぜい弱性を体感するための有名なOSSであるJuice ShopをKubernetesで運用するためのMultijuicerについて紹介されました。本来、Juice Shopでは各ユーザーが個別にコンテナを立ち上げる必要がありますが、Kubernetesを使用することでこれを一括管理できるようになりました。DevSecOpsの適用において、開発者がWebアプリケーションのセキュリティについて基本的な知識を持つことは必要不可欠です。このOSSはその学習を容易にするため、非常に優れていると言えるでしょう。

Cloud Native Security: Cell-Based Architecture & K8s

Cell-Based Architecture (CBA)とそれを実際に実装しているBooking.comのケーススタディに関するセッションでした。CBAとはビジネス機能ごと、もしくはシステム機能ごとに1つの「セル」にデータベース, ロギング, セキュリティインフラ, サーバーレスファンクションをまとめてデプロイするという概念です。セルコミュニケーション自体はセントラルAPIゲートウェイで行い、そこを厳重に守っているということでした。マイクロサービスと似ている印象を受けましたが、データベースやセキュリティインフラなどがまとめられている点, セルごとにまとめられている上層での分類が大きな特徴であると感じました。特にPCI DSSなどのコンプライアンス要件がありその適用範囲を明確化する必要があります。マイクロサービスなシステム構築を計画されている場合は、この新しいアーキテクチャを考慮にいれてみてもよいのではないのでしょうか?
ビジネス機能単位、またはシステム機能単位に1つの「セル」へデータベース、ロギング、セキュリティインフラ、サーバーレス機能を統合してデプロイするという概念について述べられていました。加えてCell-Based Architecture (CBA)についての説明、そしてそれを実際に導入しているBooking.comのケーススタディについて発表が行われました。
Booking.comではセル間のコミュニケーションは中央のAPIゲートウェイを通じて行われ、そのゲートウェイは厳重に保護しているとのことでした。CBAはマイクロサービスと似た印象を受けましたが、データベースやセキュリティインフラなどが一つにまとめられ、それぞれのセルが上層で分類されている点が大きな特徴であると感じました。特に、PCI DSSなどのコンプライアンス要件の適用範囲を明確化しなければならず、かつマイクロサービスのシステム構築を計画している場合、この新しいアーキテクチャを検討する価値があると感じました。

Keep Hackers out of your cluster with these 5 simple tricks

Kubernetesの脅威モデリングから始まり、どのような攻撃が実際にハニーポット上で試行されたのか、それらからシステムを守るためのベストプラクティスを紹介するセッションでした。Webアプリケーションのぜい弱性対策は、Kubernetesでも重要です。特にコンテナイメージ自体の汚染（コンテナイメージの書き換え、不正なコンテナイメージのクラスタに混入/ホストへの侵入）がKubernetesに特有のぜい弱性として挙げられます。ハニーポット上で確認された攻撃は、Webアプリケーションのぜい弱性からコマンドインジェクションを行い、Kubernetes APIやSecretへのアクセスを試みるものが多かったとのことです。ベストプラクティスとしては、APIサーバー上での認証、アタックサーフェスの削減、メタデータへのアクセスをワークロードから行えないようにするなどが挙げられていました。さらに、イメージのハードニング、ランタイムプロテクションの導入（Falco）、攻撃パスの可視化（Kubehound）、デプロイされるイメージの署名確認など、追加的な対策も推奨されました。

Running PCI-DSS Certified Kubernetes Workloads in the Public Cloud

PCI DSSは多くの企業やエンジニアを悩ませる複雑なコンプライアンス要件です。このセッションではK8Sを用いた一例が紹介されました。具体的には、Ciliumを使用したネットワーク（Ingress/Egress）の制御と監視、外部のシークレット管理ソリューションの活用（例えばAWS KMS）。さらにTetragonを用いたeBPFベースのランタイム保護、そしてCiliumのTransparent Encryptionを用いて全ノード間の通信を暗号化する方法を説明しました。セッションの担当者によれば、モニタリングについてもPrometheusを使用して実施しているとのことでした。

Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing

AZ間を跨ぐ通信は同一AZ内の通信よりもコストが高いため、極力同一AZ内の通信に留めるための方法が紹介されていました。gRPCのロードバランシングにはラウドロビンなどが用意されていますが、標準のアルゴリズムでは異なるAZへリクエストが送信される頻度を抑えることができません。Spotifyではロードバランシングとしてレイテンシを推定するアルゴリズムを実装していました。異なるAZである場合はレイテンシを過大評価するため、同一AZへリクエスト送信が多くなるよう設計されていました。結果として異なるAZへのリクエストの頻度が少なくなり、コスト削減につながったようです。

まとめ

KubeCon + CloudNativeCon Europe 2024のDay 3の各セクションの内容を速報形式にてお伝えしました。各セッションの詳細は後日また記事として投稿する予定です。お見逃しのないようフォローのほど、よろしくお願いいたします。