😎

CNCF-hosted Co-located Events Europe 2024 セッション参加メモ

2024/03/24に公開

Cilium 5
AI 3
WASM 5
ArgoCD 2
Applicarion Modernization 1

Deep Dive Into Cilium Resilient Architecture - Jussi Mäki & Martynas Pumputis, Isovalent

以下は、Ciliumシステムのエージェント部分の改善点について説明した内容の要約です。このリリースでは、Ciliumのエージェント部分であるSidecar Agentの耐障害性と信頼性を高める変更が行われました。主な変更点は以下の通りです。 1. desired stateの実装従来はハッシュマップを使用していましたが、トランザクション性や排他制御などの要件を満たすために、新たにin-memoryデータベースを導入しました。このデータベースはプレフィックスインデックスを用いることで、効率的な検索や変更の通知が可能になりました。 2. Reconcilerの導入 desired stateを実現するために、Reconcilerというコンポーネントが新たに導入されました。これは、データベースに格納されたstateとクラスタの実際の状態を照合し、必要な操作(BPF mapの更新など)を行うコンポーネントです。また、障害発生時のリトライ機能やメトリクスの収集など、堅牢性を高める機能が備わっています。 3. エージェントヘルス監視の強化新しいデータベースやReconcilerを使うことで、エージェントの状態をより詳細に監視できるようになりました。desired stateとreconcileの進捗状況、障害のログなどが把握できます。これらの変更により、Ciliumのエージェントは耐障害性と観察可能性が大幅に向上しました。サービスの追加・削除時の障害や、一時的なノードダウンへの対応力が高くなっています。また、障害発生時の原因特定が容易になり、復旧作業の効率化が期待できます。

Gen-AI at Scale: Simplifying Orchestration of Healthcare Applications Across Multi-Cluster Environme - Selvi Kadirvel, Elotl & Christopher Nuland, Red Hat

以下は、ヘルスケア分野におけるAIパイプライン構築とオーケストレーションについての内容を要約しました。ヘルスケアでは、データの可用性や規制の問題からマルチクラウド・ハイブリッドクラウド環境が不可欠となっています。このようなデータ重力の問題に対処するには、Kubernetesベースのマルチクラスタ・マルチクラウド対応のフリートマネージャーが有効です。フリートマネージャーは、複数のクラスターを1つのエンドポイントで抽象化し、ワークロードの配置、スケーリング、マイグレーションなどをポリシーベースで管理できます。ヘルスケア AI パイプラインでは、データ収集、前処理、モデルトレーニング、推論といった様々なコンポーネントがあり、それぞれ異なるリソース要件があります。フリートマネージャーを活用することで、各コンポーネントを最適なクラウド上に配置し、データ近くにデプロイできます。また、新しいデータが利用可能になったり、リソース需要が変わったりした場合に、ワークロードを別のクラウドにマイグレーションしたり、一時的にクラスターを起動するなど、柔軟な対応が可能です。クラウド上の異種環境でも、フリートマネージャーが統一的な視点からリソースを管理するため、ユーザーエクスペリエンスを維持できます。データ規制に配慮しながら、AIパイプラインをマルチクラウド・ハイブリッド環境で円滑に実行するためには、フリートマネージャーのようなオーケストレーションツールが不可欠となります。

Lightning Talk: Falco, Tracee and Tetragon: eBPF Runtime Observability and Security Tools Differences - Kyle Quest, AutonomousPlane

ここでは、Falco、Tracy、そしてeBPFベースのトレーシングツールの違いについて説明されています。 Falcoは高度な検出ルールを持つ侵入検知システムで、システムコール関連のイベントを監視します。一方、Tracyはメモリ、ネットワーク、ファイルなど、さまざまなイベントを収集する能力があり、eBPFベースのカスタムデータ収集オペレーターが特徴です。これらのツールはいずれもeBPFに依存しています。ただし、Falcoは従来のトレースポイントを使用し、カーネルのバージョンに縛られる一方で、Tracyは最新のBTF対応トレーシングを活用し、直接データ構造にアクセスできるため、高速で保守性の高いコードを実現できます。ライブラリの面でも違いがあり、FalcoはSlipknot BPFライブラリを使用し、Tracyは独自のGo BPFライブラリを使っています。使用するeBPFプログラムのタイプも異なり、FalcoはジェネリックeBPFプログラムを主に使うのに対し、Tracyは専用のeBPFプログラムを多数持っています。このように、それぞれのツールにはトレーディングデータ収集と監視の目的に応じた長所と短所があり、用途に合わせて使い分ける必要があることが述べられています。

Lightning Talk: Optimizing Cluster Workloads: Cilium Envoy on DPU - Shatakshi Mishra, Marvell Technology

以下は、クラウドネイティブコンピューティング環境におけるリソース最適化の取り組みについての要約です。この提案は、クラウドネイティブネットワークの機能をGPU(Graphics Processing Unit)などの専用ハードウェアにオフロードすることで、サーバーリソースを最適化することを目的としています。具体的には、Envoyのような層4負荷分散やMPLS処理などの機能をGPUに移行する構想です。最初の試みとして、EnvoyとCloudデフェンダーモジュール(CDM)をGPUとメタデバイスに展開するモデルを検証しました。ゲートウェイAPIのユースケースでは、トラフィックはGPUに送られ、そこでEnvoyとCDMによる処理が行われた後、バックエンドPodに渡されます。さらに進んだアーキテクチャでは、CDMエージェント、eBPFデータプレーン、Envoyプロキシがすべてデータ処理ユニット(DPU)にオフロードされる構成を想定しています。CNIオフロードレイヤーがCRIからのデータを受け取り、DPUのCNIプラグインに渡すことで実現します。このアーキテクチャのPoC(概念実証)モデルが既にあり、コミュニティでの議論を歓迎しています。最終的な目標は、共通インフラ系ワークロードをDPUに移行することで、サーバーのコンピューティング能力を解放し、アプリケーションワークロードに特化できるようにすることです。さらにDPUのハードウェアアクセラレーションも活用し、全体的なクラスタパフォーマンスと電力効率の向上を狙っています。!

Application Modernization: From Concept to Kubernetes - George Hantzaras, MongoDB

以下は、アプリケーションの近代化に関する内容の要約です。アプリケーションの近代化とは、レガシーなソフトウェアをより新しい設計や技術に置き換えることを指します。その目的は、システムの複雑さを減らし、デプロイを容易にし、サービスの品質と可用性を向上させることにあります。近代化の手法としては、リタイア(廃止)、置換(外部サービスへの移行)、リファクタリング(再設計)、リホスティング(インフラ移行)、再構築(書き直し)などがあります。特にリファクタリングは、モノリシック・アーキテクチャからマイクロサービスアーキテクチャへの移行を含み、大掛かりな作業が必要となります。マイクロサービスへの分割では、ドメイン駆動設計(DDD)、サービス指向アーキテクチャ(SOA)、イベント駆動アーキテクチャ(EDA)などの概念が役立ちます。これらを組み合わせることで、システムをよりサービス指向に再構築できます。しかし、マイクロサービスへの移行は常に適切とは限らず、プロジェクトの規模や性質によっては、モノリシックアーキテクチャのままモジュール化するなど、段階的なアプローチが賢明です。移行後は、Kubernetesなどの基盤の上にプラットフォームを構築し、開発者エクスペリエンスを向上させることが重要です。Kubernetesオペレーターなどのツールを活用し、インフラ管理を抽象化することで開発の生産性が上がります。

GitOps for the Edge: Delivering WebAssembly with Argo CD - Dan Norris & Joonas Bergius, Cosmonic

この資料は、WebAssemblyとwasmloudプロジェクトについて説明し、ArgoCDを使ってwasmloudアプリケーションをKubernetes上にデプロイする実演を行っています。 WebAssemblyは、もともとブラウザ向けに開発された、様々な言語で書かれたアプリケーションを実行可能な portableなバイナリフォーマットです。wasmloudはWebAssemblyコンポーネントを클라우드やエッジ環境に展開するためのアプリケーションプラットフォームです。講演者らは、wasmloudアプリケーションを記述するマニフェスト形式のカスタムリソースを定義し、ArgoCDがこれを認識してデプロイできるようKubernetes Operatorを実装しました。Rust言語で書かれたこのOperatorは、Argoからの指示を受け取り、wasmloudプロセスに対してコンポーネントの開始・停止などの命令を発行します。実際にデモでは、30を超えるエッジロケーションに分散してHTTPサーバー、アクター、データプロバイダーの3つのWebAssemblyコンポーネントから構成されるアプリケーションを、GitOpsツールのArgoCDからワンクリックでデプロイしています。WebAssemblyコンポーネントのコード量が小さいことから、高速でリソース効率の良いデプロイが実現できることを示しています。

Adobe/AWS: Key Takeaways from Scaling Adobe's CI/CD Solution to Support >50K Argo CD Apps - Andrew Lee, AWS & Vikram Sethi, Adobe

以下は要約です。アドビは、CI/CDソリューション「Flex」を大規模に拡張する過程で、さまざまな課題に直面しました。当初は単一のFlexboxアーキテクチャでしたが、APIサーバーの負荷集中や、バックエンドストレージ不足など、パフォーマンスとスケーラビリティの問題に見舞われました。そこで、複数のFlexboxを水平方向に拡張できる新しいアーキテクチャ「Flex in a Box」を導入しました。これにより、アプリケーションを複数のクラスターに分散させ、単一のFlexboxへの負荷を分散できるようになりました。さらに、ArgoCDやArgo Workflowsの設定の最適化、コンポーネントの分離、GitHubActionsとの統合なども検討されています。アドビはこの経験から、メトリクス監視、コンポーネントの限界の把握、水平/垂直スケーリングのタイミング判断、実験的アプローチの重要性を学びました。プロセスの改善も不可欠であることが分かりました。今後は、50,000を超えるレガシーアプリをサポートできる高度なスケーラビリティと安定性を目指して、アーキテクチャとプロセスの改善を重ねていく予定です。

Components, WebAssembly’s Docker’s Moment - Bailey Hayes, Cosmonic

はい、以下の要約になります。このプレゼンテーションは、WebAssemblyベースのコンポーネントモデルについて説明しています。コンポーネントモデルでは、あらゆるものがインターフェース駆動となります。開発者は開発時にインターフェースを使用し、プラットフォームオペレーターはインターフェースを通してプラットフォームを運用します。このモデルでは、SDKが自動的に生成されるメリットがあります。コンポーネントは、ローカル、合成、外部プロセス、分散の4つの方法で満たすことができます。デモでは、HTTPサーバー、キーバリューストア、カスタムインターフェースを組み合わせた構成を実演しました。コンポーネントをリンクして機能を組み合わせることで、アプリケーションの構築が可能になります。さらに、コンポーネントモデルでは、仮想的なプラットフォーム層を使ってコンポーネントの動作を抽象化できます。たとえばプロキシの設定や、ファイルシステムアクセスの制限などを実現できます。この抽象化により、開発者はそうした設定を意識せずにアプリケーションを作れます。最後に、デバッグの課題やサイドカーパターンの適用、ネットワーク通信などの質問がありましたが、コンポーネントモデルではそうした要件にも対応可能であることが示されました。

Pathfinder to GPU Offload in WASM - Atanas Atanasov & Aaron Dorney, Intel

ここでは、GPUをクラウドやサーバー環境で活用するための技術的アプローチについて説明しています。主な内容は以下の通りです。 1. GPUオフロードの動機: AIサービスやレンダリングサービスなどが背景にあり、WebGLやGPUオフロードの需要が高まっている。 2. 既存のGPUオフロードAPI: OpenGL、Vulkan、CUDA、OpenCLなど、さまざまな既存APIがあるが、WebAssembly(Wasm)と統合するのは難しい。 3. WasmのためのGPUオフロードAPI: 主に、CNNMLフレームワークのWasmサポートと、WebGPUAPIが注目されている。 4. CNNMLフレームワーク: 既存の機械学習モデルをWasmにインポートし、ハードウェアアクセラレーションが可能。ポータビリティと高性能が特徴。 5. WebGPUAPI: W3CがWebGLの後継として策定中。コンピュートシェーダーのサポートやバッファー制御が可能で、WebGLより高性能。 6. デモ: WebGPUを使ったベクトル演算やマトリックス計算のデモを実演。ブラウザやクラウド上でのGPU利用を示した。 7. 将来の展望: Apache TVMなどのフレームワークとの連携や、WebNNなどの新しいAPIの可能性についても言及している。全体として、クラウドやエッジデバイスにおけるGPU利用の重要性が高まる中で、WasmベースのGPUオフロードAPIが有力な選択肢になることが示唆されています。

Effortless Scalability: Orchestrating Large Language Model Inference with Kubernetes - Rohit Ghumare, devrelasservice.com & Joinal Ahmed, Navatech AI

この発表は、大規模な言語モデル(LLM)をクラウド上で効率的にデプロイするためのツール「Triton」について説明しています。LLMはパラメータ数が膨大で、高性能GPUを多数必要とするため、運用が非常に困難でコストがかかります。 Tritonは、Kubernetes上でLLMのインフラを自動でプロビジョニングし、効率的にデプロイすることができます。モデルのメモリ要件に応じて適切なGPUリソースを自動選択し、複数モデルで1つのGPUを共有することもできます。またモデルイメージをプリセットで用意しているので、コンテナ化する手間が不要です。デモでは、実際にTritonを使ってKubernetes上にLLMをデプロイする過程が紹介されました。Tritonを使えば、従来数週間かかっていたLLMのデプロイを数時間で済ませられ、コストも大幅に削減できるとされています。LLMのデプロイが簡単になり、製品化が加速すると期待されています。

Resource-Aware Scheduling for Production GenAI with RAG running on Multicluster Cloud Kubernetes - Anne Holler, Elotl & Dave Southwell, Deft Computing

はい、以下のように要約いたします。この発表では、GenAI(Generative AI)とRAG(Retrieval Augmented Generation)を組み合わせた大規模な製品向けAIワークロードをKubernetesクラスターに効率的にデプロイする手法について説明しています。従来のクラウドベンダーのサービスを利用する代わりに、オープンソースソフトウェアを活用してセルフホスティングすることで、コスト削減、スケーリング、パフォーマンス制御、プライバシー保護などのメリットがあります。ただし、複雑さの管理が課題となります。そこで、この手法では複数のKubernetesクラスターとクラスタースケジューラーのNovaを組み合わせています。アーキテクチャーの主要コンポーネントは、ベクトルデータベース、予測サービス、ユーザーインターフェース、LLMモデルサービングで構成されています。それぞれのコンポーネントにはリソース要件が異なるため、GPUクラスターやCPUクラスターなど適切なクラスターにデプロイする必要があります。 Novaを使うことで、ワークロードをリソース制約に基づいて適切なクラスターに自動的にスケジューリングできます。さらに、ノードの追加や削除によるオートスケーリング、クラスターの一時停止と再開、グローバル分散デプロイなども実現できます。デモでは、実際にモデルバージョン1と2を展開し、検証後にバージョン1を削除するプロセスを示しています。また、リソース不足時にクラスターをオートスケーリングする例も紹介されています。このようにNovaを活用することで、GenAI/RAGワークロードを効率的に運用できることが分かります。

CRI-O's WASM Adventure: Challenges, Strategies, and What Lies Ahead - Sohan Kunkerkar & Peter Hunt, Red Hat

以下は、KubernetesとWebAssembly(Wasm)の統合について説明した技術プレゼンテーションの要約です。このプレゼンテーションでは、コンテナランタイムであるWasmと、コンテナオーケストレーションツールであるKubernetesを組み合わせることで得られるメリットについて説明しています。 WasmはOSに依存しないバイナリ形式で、軽量で高速な実行が可能です。一方Kubernetesはコンテナ化されたアプリケーションを扱うことに適しています。両者を統合することで、言語に依存せずに高パフォーマンスでセキュアなコンテナ化されたワークロードをKubernetesで実行できるようになります。現状ではWasmをKubernetesで実行するには、WasmバイナリをOCIイメージに格納する必要がありました。しかし、将来的にはWasmバイナリをそのままレジストリから直接取得して実行できるようになる予定です。さらに、Kubernetesの拡張機構であるMRIの仕組みを活用し、Wasmをプラグインとして実行することも検討されています。このようにWasmとKubernetesの統合は、軽量でポータブル、そして高パフォーマンスなコンテナ化されたワークロードを実現する有力な選択肢となりつつあります。プレゼンターらは今後のさらなる発展に期待を寄せています。

WASI and the Cloud: A Game-Changing Duo - Bailey Hayes, Cosmonic & Jiaxiao Zhou, Microsoft

以下は、クラウドポータビリティと抽象化に関するプレゼンテーションの要約です。このプレゼンテーションでは、アプリケーションを特定のクラウドプロバイダーに縛られずに移植可能にする手法について説明されています。その中核となるのがWASI(WebAssembly System Interface)と呼ばれる提案で、WebAssemblyの上で動作するポータブルなシステムインターフェースを規定しようとするものです。プレゼンターは、ビジネスロジックをWASIコンポーネントにコンパイルすることで、クラウド間で移植可能になると主張しています。そしてデモでは、ブロブストレージサービスのコンポーネントを紹介し、Azureやローカルファイルシステムなど、異なるプロバイダー実装に対して同じコンポーネントを使用できることを示しました。 WASIには様々な提案があり、キーバリューストア、メッセージング、SQLなどのインターフェースが含まれる予定です。ただし、ポータビリティと機能の豊富さはトレードオフの関係にあり、標準的な機能セットを定義する必要があります。プレゼンターらはコミュニティに呼びかけ、WASIインターフェースの実装やレジストリ構築などへの参加を求めています。WASIがクラウドポータビリティの鍵になると期待されています。