KubeDay Japan 2024

はじめに

ZIPAIRの技術チームとして、私たちは常日頃から新しいチャレンジに挑戦しています。その一環として最新のクラウドネイティブ技術トレンドに触れるため、KubeDay Japan 2024へ参加しました。
本記事では、参加したセッションのレポートをお届けします。

参加したセッション

Towards a World Without Dependency Consideration

Kubernetesにおけるリソース依存関係の削除に関する課題を取り上げていました。Kubernetesは宣言型のアプローチに基づいてリソース管理しますが、リソースの削除時に依存関係を無視して削除するとシステム全体の一貫性に悪影響を及ぼす可能性があります。この問題への対処として提案されているのが「KEP-2839（Lien）」という機能です。Lienは特定のリソースが依存関係にある場合そのリソースの削除を防ぐための仕組みで、誤ったリソース削除による問題を回避できます。

CrossplaneというKubernetesの拡張機能も紹介されており、Lienは実用段階に至っていませんが、それと同様に「Usage」機能を使用してリソースの削除保護を実現しています。CrossplaneはKubernetesクラスターを拡張してAWSやAzureなどの非KubernetesリソースをKubernetesオブジェクトとして管理できるようにするためのツールです。Usage機能を使用することでリソースが他のリソースに使用されている場合、そのリソースの削除がブロックされ、依存関係に基づいて安全にリソースを削除できるようになります。

この機能により管理者はシステム全体の整合性を保ちながら安全にリソースを削除できるため、大規模なクラウドインフラやマルチテナント環境での管理が容易になるとのことでした。

Expedia Group's Downtime-Free Shift: Transitioning from Instance to IP-Based NLB

Expediaグループが取り組んだ移行プロジェクトについて共有されました。移行前のExpediaグループのアーキテクチャでは、オートスケーラーにてスケールインされる際のノードの頻繁な再起動による問題が発生していました。この問題を解決するため、ネットワーク負荷分散（NLB）のターゲットタイプをインスタンスベースからIPベースに移行することで、ダウンタイムゼロの実現を目指しました。

外部リクエストでのみ発生するタイムアウト問題が報告され、調査の結果Istio Ingress Autoscaling Group内での中間ノードの頻繁な切り替わりが根本原因であると特定されました。そのため、サービスメッシュの影響を最小限に抑えつつ、NLBのIPモード移行をシームレスに行うことを目指しました。
ロールアウトの準備段階では信頼性エンジニアリングの観点から、影響範囲の制限、スケールに応じた観測性の確保、ロールバック計画の策定、Go/No-Goの明確な基準設定が設けられたそうです。

最後に、プロジェクトの成功要因としてコラボレーションとレジリエンスの重要性が強調されています。多大な努力とチームワークが必要であり、その結果としてダウンタイムゼロの運用が実現されました。

A Tale of Two Plugins: Safely Extending the Kubernetes Scheduler with WebAssembly

KubernetesスケジューラをWebAssembly（Wasm）を使って安全に拡張するための新しいアプローチを取り上げていました。Kubernetesスケジューラはポッドを実行するために最適なノードを選定する役割を持つコントロールプレーンのコンポーネントで、複数のプラグインを利用して拡張性を持たせています。このセッションでは既存のGolangプラグインやWebhook（Extender）に加え、Wasmプラグインのそれぞれの特徴と利点が紹介されました。

Wasmプラグインの導入は従来のGolangプラグインのように柔軟でありながら、設定や再ビルドの手間が少ないという利点があります。また、Wasmプラグインは複数の言語で記述可能（現状はTinyGo SDKのみ）で、TinyGo SDKを使用することで非Wasm開発者でも比較的簡単にプラグインを作成できるようになっています。しかし、Wasmプラグインにはスケジューリング遅延の増加やWasmサンドボックスの制限、ガーベジコレクションのオーバーヘッドといった課題も存在します。

Wasmは拡張性を高める有望なオプションである一方で、パフォーマンスへの影響や設計上の配慮が求められるとのことでした。

Towards Effortless Transaction Management in Microservices

このセッションではマイクロサービス環境におけるトランザクション管理の課題と、その解決策について取り上げていました。マイクロサービスアーキテクチャは疎結合で細分化されたサービスの集合体として設計されており、各サービスが独立して開発・デプロイできるという利点があります。一方で複数のデータベース間で一貫性を保つことが難しいという問題があります。この問題を解決するために、主に3つのアプローチが取り上げられました。

まず、Sagaパターンは非同期メッセージングを用いて各サービス間のトランザクションを連携させる手法です。Sagaパターンの利点としてロックやリソースの予約が不要であり、複数のデータベースに適用可能である点が挙げられます。デメリットとしては各サービスで補償トランザクションを定義する必要があり、実装やデバッグが難しい点です。

次に、2PC（Two-Phase Commit）パターンはグローバルトランザクションを調整するための古典的なプロトコルです。この手法は完全なACID特性を提供しアプリケーション開発者にとって実装が容易であるという利点があります。一方で遅延が発生しやすくコーディネータのクラッシュがプロトコル全体をブロックする可能性があるなどの欠点があります。

最後に、TCC（Try-Confirm/Cancel）パターンはビジネス層で2PCを実装する手法で、リソースのロック粒度を柔軟に選択できる点が特徴です。しかし、補償トランザクションを定義する必要があり、サービスがべき等性を持つことを要求されるため実装が難しいというデメリットがあります。

SagaパターンやTCCパターンのデメリットを補うことは難しいとされています。一方で、2PCパターンを高可用性かつスケーラブルにすることで、最終的にはマイクロサービスのメリットを損なうことなく複数データベース間のトランザクション管理を容易にできるようです。

eBPF Strengthens SR-IOV to Be Powerful

eBPFがSR-IOV（Single-Root Input/Output Virtualization）のパフォーマンスを大幅に向上させる方法について取り上げていました。SR-IOVはハードウェアの仮想化技術であり、これにより単一の物理機能（PF）を複数の仮想機能（VF）に分割できます。そうすることで、KubernetesのPodがノードのネットワークスタックをバイパスして直接ネットワークへアクセスできるようになります。この技術によりホストのネットワークスタックを迂回しノード自体と同等のパフォーマンスが実現されます。特にネットワークI/Oが集中的に求められるアプリケーションに有効です。

しかしながら、SR-IOVの展開にはいくつかの課題が伴います。現在のエコシステムではどのリソースがどのように管理されるべきかが明確に定義されていない場合が多く、メンテナンスやトラブルシューティングが困難です。そこでeBPFが導入され、その高性能により従来のkube-proxyに代わるものとして注目されています。特にSpiderpoolとcgroup eBPFを統合したサービス実装は従来のiptablesベースの手法に比べて25％のネットワーク遅延改善、さらには50％のスループット向上が実現可能です。これにより、Kubernetesクラスター内の複数のPodやノード間でよりスムーズで高速な通信が可能になるようです。

Discover Your Tailored Platform Strategy with Real World Practice

プラットフォームエンジニアリングの概念とその実践方法に関して取り上げていました。現代のIT環境ではリリースサイクルの短縮やデリバリースピードの向上が求められており、その結果として開発者は多くのツールやインフラ技術の習得を強いられるという問題が発生しています。これを解決するために内部開発者向けのプラットフォーム（Internal Developer Platform）が導入され、開発者がビジネスと直接関連する価値創造に集中できます。

このセッションでは「プラットフォームエンジニアリングの成熟度モデル」を使って企業がどのようにしてプラットフォームを評価し、成長させるべきかについて説明していました。このモデルはプラットフォームの「投資」、「採用」、「インターフェース」、「戦略」、「計測」の5つの要素に基づいて構成されています。それぞれの要素についてプラットフォームが「暫定段階」から「最適化段階」までどのレベルにあるかを評価し、次のステップを計画するための枠組みを提供します。

プラットフォームを効果的に成長させるためには、組織のリソースやビジネスゴールに応じて適切な中間目標を設定することでプラットフォームの成長を計画的に進めることが重要とのことでした。

Our Journey from in-House CD System to Open Source

このセッションではCyberAgentが社内で使用していた継続的デリバリー（CD）システムをオープンソース化した経緯が述べられていました。

CyberAgentでは技術選定においてチームの独立性が高く、プロダクトの性質に合わせて使用するクラウドプラットフォームが選択されているようです。そのため、以前はCDシステムも統一されていませんでした。CDシステムが統一されていないことで新規メンバーのオンボーディングコストが高く、ツールの習得に時間を要していたという課題が共有されました。これに対応するため共通のCDシステムのPipeCDを開発し、内部での導入が進められました。PipeCDは様々なアプリケーションやプラットフォームに対応可能で、AWSなどのクラウドサービスや異なる環境でのデプロイをサポートしています。

さらに、PipeCDをオープンソース化することで外部コミュニティとの協力を促進し、技術ブランドの向上や人材確保を図る狙いが説明されました。外部のフィードバックを受けることで機能の向上やバグ修正のスピードも向上し、会社全体のエンジニアリング文化の醸成にもつながっているようです。

Leveraging Wasm for Portable AI Inference Across GPUs, CPUs, OS & Cloud-Native Environments

Wasmを利用してGPU、CPU、異なるOS、クラウド環境にまたがるAI推論をどのように実現するかが共有されました。

異なるハードウェアや環境におけるAI推論処理の課題に対し、それを解決するためにWasmが有用であると強調されていました。特に、Wasmのポータビリティによりさまざまな環境やプラットフォームでのAIモデルの推論が可能となり、エッジデバイスやクラウドなどで柔軟に使用できる点が述べられました。具体的なツールとしてはWasmEdgeRuntimeやLlamaEdgeが紹介されていました。

さらに、Wasmの利点としてセキュアなサンドボックス環境を通じた実行や簡単なデプロイプロセス、コードの移植性が挙げられました。これにより特定のオペレーティングシステムやハードウェア環境に縛られることなく、幅広い環境でのAIアプリケーションのデプロイが容易になります。

クラウドネイティブの文脈においてWasmを活用する機運の高まりを感じることのできるセッションでした。

Scaling Time-Series Data to Infinity: A Kubernetes-Powered Solution with Envoy

このセッションではKubernetesとEnvoyを使用して、タイムシリーズデータのスケーリングを無制限に行うことができるようになった事例が紹介されました。
LY Corporationが運用するタイムシリーズデータベースはAPIを通じてデータを収集し、膨大なメトリクスデータを処理しています。しかしコスト、スケーラビリティ、容量の問題があり、既存のインフラでは対応しきれないという課題が発生していました。これらの課題に対処するためオブジェクトストレージを活用した新しいデータ構造を採用し、データの保存や読み取りを効率化しました。インデックス機能を導入し、データのシャーディングを行いオブジェクトストレージの容量制限に対応していました。また、ワークロード管理においてKubernetesによるインフラの自己修復機能を活用し、システム全体の耐障害性を向上させています。

さらに、データの書き込みや読み込みのパフォーマンス向上のために圧縮やEnvoyを使用したページキャッシュを無効にするなどの最適化を行い、CPU使用率の低減を図りました。
結果としてスケーラビリティの問題は解決され、ユーザーが自分のオブジェクトストレージを使用できる新機能も提供される予定です。

最後に、このプロジェクトがオープンソースコミュニティに貢献できることを期待しており、タイムシリーズデータベースのさらなる成熟と拡大を目指していると締め括られました。

まとめ

本記事では、KubeDay Japan 2024の各セッションの概要についてお伝えしました。各セッションのアーカイブ動画は後日公開が予定されているようなので、本記事を読んでご興味を持たれた方は後日アーカイブ動画の方もご確認ください。
本ブログでも引き続きカンファレンスのレポートなどを投稿していきますので、お見逃しのないようフォローのほどよろしくお願いいたします。