> [!abstract] 概要 > 現代のクラウドネイティブシステムでは、軽量性と高速起動を理由に WebAssembly(Wasm)コンテナへの依存が高まっている。しかし、避けがたい障害に直面しても高可用性を保つことは依然として重要な課題である。従来のセルフヒーリング機構は多くの場合単純なコンテナ再起動に基づいており、サービス中断と性能劣化を招く。本論文は、ランタイム中立チェックポイントフレームワークを活用することで、Wasm コンテナオーケストレーションにおけるシームレスなセルフヒーリングを実現する新しいアプローチを提案する。このフレームワークは著者らの先行研究で開発されたものであり、特定のランタイム実装に依存せずにアプリケーションの完全な実行状態を捕捉する。 > この基盤の上に、ホットリスタートと動的ランタイム切り替えという 2 つの重要な機能を実現する。ホットリスタートにより、障害が発生したコンテナをミリ秒単位でチェックポイントから復元でき、コールドスタートのオーバーヘッドを排除する。さらに重要なことに、本論文は Pod 退避(eviction)なしでメモリ圧力を緩和する新しいパラダイムを導入する。ランタイム中立チェックポイントを活用することで、オーケストレーションシステムはリソースが制約された際に、実行中のアプリケーションを高性能ランタイム(例: WasmEdge)からよりメモリ効率の良いランタイム(例: WAMR)へ円滑に切り替えることができる。実証評価の結果、このアプローチはメモリ圧力を効果的に緩和し、わずかで一時的な性能影響にとどまることが確認され、破壊的な退避ベースの方法に優る代替手段であることが示された。 ## 論文情報 - **タイトル**: Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing - **著者・所属**: Katsuya Matsubara, Yuzuki Saito, Daigo Fujii(Future University Hakodate)、Yuki Nakata(Future University Hakodate / SAKURA internet Inc.) - **媒体**: 2025 Thirteenth International Symposium on Computing and Networking Workshops (CANDARW) - **発表年**: 2025 - **DOI**: [10.1109/CANDARW68385.2025.00013](https://doi.org/10.1109/CANDARW68385.2025.00013) - **ページ数**: 7 pages - **キーワード**: Dependable System, Fault Tolerance, Cloud Computing, Edge Computing, Live Migration, Kubernetes - **関連先行研究**: ランタイム中立チェックポイントの基盤として、著者らの先行研究 [6]「Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations」(EdgeSys ’24)を利用している。 ## 概要 Wasm コンテナは軽量・高速起動・強力なサンドボックス化により、クラウドネイティブシステムの有望な実行基盤となっている。しかし、分散システムでは障害が避けられず、従来のコンテナ再起動ベースのセルフヒーリングはサービス中断や性能劣化を招く。本論文は、ランタイム中立チェックポイントを活用して Wasm コンテナの実行状態を保存・復元し、ホットリスタートと動的ランタイム切り替えという 2 つの機能を通じて、シームレスなセルフヒーリングを実現する。(Source: §1) ## 問題設定 - **入力**: Kubernetes 上で動作する Wasm コンテナの実行状態、および Prometheus で収集されるリソース使用状況。 - **出力**: 障害発生時にはチェックポイントからのホットリスタート、メモリ圧力時には WasmEdge から WAMR への動的ランタイム切り替え。 - **前提**: Wasm ランタイム(WasmEdge, WAMR)の内部表現は異なるが、実行状態(プログラムカウンタ、スタック、メモリ、グローバル変数など)をランタイム非依存表現に変換できる。本論文ではインタプリタ実行を対象とする。 - **制約**: ネットワークソケットやファイルディスクリプタなどの OS レベル状態は、本フレームワークの対象外である。WASI API は進化途中であり、標準化されたネットワーク API が限定的である。 ## 提案手法 ### ランタイム中立チェックポイントと復元 本論文の基盤となるランタイム中立チェックポイントは、著者らの先行研究 [6] で開発されたものである。Wasm ランタイムの内部表現(プログラムカウンタ、バリュースタック、コントロールスタック、フレームスタックなど)を中間形式に変換し、異なるランタイム間で復元可能にする。線形メモリとグローバル変数も保存対象に含まれる。(Source: §2) ### ホットリスタートによるシームレスなフェイルオーバ 従来のフェイルオーバでは、障害が発生すると新しいコンテナが起動し、アプリケーションの初期化や状態再構築を行うコールドスタートが発生する。本論文では、定期的に取得したチェックポイントからアプリケーション状態を復元することで、このコールドスタートを回避する。新しいコンテナを起動した後、チェックポイントを用いて実行状態を復元し、障害直前の状態から処理を再開する。(Source: §3-A) **図 1: Pod 再スケジュールのためのシステムアーキテクチャとフロー** ![[_attachments/Seamless_Self-Healing_in_WebAssembly_Container_Orchestration_with_Runtime-Neutral_Checkpointing/fig01-architecture.png]] (Figure 1. Prometheus による監視、Descheduler による移動対象 Pod の特定、Custom Scheduler による配置、Webhook によるランタイム切り替え判定を組み合わせたシステムアーキテクチャ。緑の矢印は periodic なチェックポイント(3)と復元(8)を示し、赤の矢印は障害やリソース圧力をトリガとした移行フローを示す。Source: §4) ### 動的ランタイム切り替えによるメモリ圧力緩和 Kubernetes はノードのメモリ使用率が高まると Pod を強制終了してリソースを解放する Pod eviction を行う。これはステートフルなアプリケーションにとって破壊的である。本論文では、ランタイム中立チェックポイントを用いて実行中のアプリケーションの状態を保持したまま、高性能だがメモリ消費の大きい WasmEdge からメモリ効率の良い WAMR へ切り替える。これにより、Pod eviction を伴わずにメモリ圧力を緩和する。(Source: §3-B) ### 実装: Wasm shim、カスタムスケジューラ、Prometheus モニタリング 本システムは、Kubernetes Kubelet と Wasm ランタイムの間に入るカスタム Wasm shim を中核とする。この shim は CRI(Container Runtime Interface)に準拠し、以下の機能を提供する。(Source: §4) - **コンテナライフサイクル管理**: CRI 呼び出しを WasmEdge または WAMR の API 呼び出しに変換する。 - **チェックポイントと復元**: カスタム API エンドポイントを提供し、実行中の Wasm コンテナのチェックポイント取得と復元を行う。 - **ランタイム切り替え**: WasmEdge と WAMR の間で動的にランタイムを切り替える機能を提供する。 さらに、以下のコンポーネントが連携する。(Source: §4) - **Prometheus**: Wasm コンテナの CPU・メモリ使用量を監視する。 - **Descheduler**: ノード障害・高負荷・手動要求などのイベントをトリガに、移動が必要な Wasm Pod を特定し、停止前に最終状態をチェックポイント化する。 - **Custom Scheduler**: チェックポイントファイルの存在を考慮して最適なターゲットノードを選び、Webhook を用いてランタイム切り替えの必要性を判定する。 ## 新規性 本研究の新規性は以下の 3 点にある。(Source: §1, §3, §4) 1. **ホットリスタート機能**: ランタイム中立チェックポイントからの復元により、コールドスタートを回避し、障害後もアプリケーション状態を保持する。 2. **Pod eviction なしのメモリ圧力緩和**: 動的ランタイム切り替えにより、サービス中断を最小限に抑えながらメモリ効率を改善する。 3. **Kubernetes オーケストレーションへの統合**: カスタム shim・descheduler・scheduler・Prometheus モニタリングを組み合わせた実用的なプロトタイプを提示する。 ## 実験設定 ### ホットリスタート評価 エッジクラウド環境を模した 3 ノードクラスタ(1 DC クラウドノード、2 エッジサーバノード)を構築した。エッジサーバノード上のキャッシュ付きキーバリューストアアプリケーションを、Edge Serv. Node A から Edge Serv. Node B へ移行するシナリオを評価する。比較対象は、状態を保持しない通常再起動(Normal Restart)と、本手法のホットリスタート(Hot Restart)である。クライアントは 10 req/s で 150 クエリを送信し、その後移行を行う。(Source: §5-A) **図 2: ホットリスタート評価用の実験的エッジクラウドシステム** ![[_attachments/Seamless_Self-Healing_in_WebAssembly_Container_Orchestration_with_Runtime-Neutral_Checkpointing/fig02-experimental-setup.png]] (Figure 2. DC クラウドノード上のバックエンドデータベースと、2 つのエッジサーバノード上のキャッシュサーバを Wi-Fi・GbE LAN・Internet で接続した実験環境。Source: §5-A) ### ランタイム切り替え評価 単一ホスト上に 2 つの VM(2 CPU core / 4 GB RAM)を構築し、k3s クラスタを形成する。3 秒ごとに SQLite アプリケーションを動かす WasmEdge Pod をデプロイし、ワーカーノードのメモリ使用率が 80% に達した時点で、WasmEdge から WAMR へランタイム切り替えを行う。各測定値は 5 回の平均である。(Source: §5-B) ## 実験結果 ### ホットリスタートの影響 **図 3: エッジサーバ再起動前後の応答時間** ![[_attachments/Seamless_Self-Healing_in_WebAssembly_Container_Orchestration_with_Runtime-Neutral_Checkpointing/fig03-response-time.png]] (Figure 3. 通常再起動(Normal Restart)とホットリスタート(Hot Restart)の応答時間比較。ホットリスタートはキャッシュヒット率を維持し、再起動直後の応答時間劣化を抑制する。Source: §5-A) 通常再起動では、Edge Serv. Node B 上で Pod が空のキャッシュ状態で再起動したため、再起動直後にキャッシュヒット率が急落し、クラウドからのデータ取得が増加して応答時間が 100 ms 悪化した。一方、ホットリスタートでは移行時間が約 800 ms と通常再起動(約 400 ms)の約 2 倍になったが、チェックポイントからキャッシュ状態を復元したためキャッシュヒット率が維持され、応答時間の劣化が抑制された。生成されたスナップショットファイルサイズは約 220 KiB と軽量であった。(Source: §5-A) ### ランタイム切り替えの影響 **図 4: 段階的にレプリケートされた SQLite アプリケーション実行時のノードメモリ使用量** ![[_attachments/Seamless_Self-Healing_in_WebAssembly_Container_Orchestration_with_Runtime-Neutral_Checkpointing/fig04-memory-usage.png]] (Figure 4. 新規 Pod デプロイによって増加するワーカーノードのメモリ使用量(RSS)。WasmEdge から WAMR へのランタイム切り替えにより、メモリ使用率が 80% 閾値を下回り、Pod 退避を回避する。Source: §5-B) 新規 Pod を継続的にデプロイしていくと、ワーカーノードのメモリ使用率は上昇し、80% を超えた。本システムがランタイム切り替えを WAMR に対して開始すると、ノード全体のメモリ使用量は即座に減少し、80% 閾値を下回った。これにより、Pod 退避を発生させることなくメモリ圧力を緩和できたことが確認された。(Source: §5-B) **図 5: 100 回 SELECT クエリあたりのアプリケーション性能** ![[_attachments/Seamless_Self-Healing_in_WebAssembly_Container_Orchestration_with_Runtime-Neutral_Checkpointing/fig05-app-performance.png]] (Figure 5. ランタイム切り替え前後の SQLite アプリケーション性能(100 クエリあたりの実行時間)。切り替え時に一時的な性能低下が見られるが、すぐに復元状態から処理を再開する。Source: §5-B) WAMR への切り替え後、WAMR の classic interpreter を使用したことで WasmEdge と比較して性能が低下した。また、切り替え処理そのものでも一時的な性能低下が発生した。ただし、これは極めて短時間であり、アプリケーションは復元状態から処理を再開した。著者らは、WAMR の fast interpreter への対応により性能を改善できると述べている。(Source: §5-B) ## 考察 本論文は、ランタイム中立チェックポイントを活用することで、Wasm コンテナのセルフヒーリングを「単純な再起動」から「状態を保持したホットリスタート」と「リソース適応型の動的ランタイム切り替え」へ拡張する。ホットリスタートは移行時間が長くなる場合があるが、キャッシュ状態などを保持することで、ユーザー体感のサービス品質劣化を抑える。動的ランタイム切り替えは、一時的な性能低下を伴うものの、Pod eviction によるサービス中断を回避するという大きな利点がある。(Source: §5, §7) ## 強み / 弱点・課題 **強み**: - ランタイム中立チェックポイントにより、異なる Wasm ランタイム間で実行状態を移行できる。(Source: §2) - ホットリスタートにより、コールドスタートを回避し、ステートフルなアプリケーションの可用性を高められる。(Source: §5-A) - 動的ランタイム切り替えにより、Pod eviction なしにメモリ圧力を緩和できる。(Source: §5-B) - チェックポイントファイルサイズが軽量(約 220 KiB)であり、転送オーバーヘッドが小さい。(Source: §5-A) **弱点・課題**: - 対象はインタプリタベースの Wasm ランタイムに限定されており、JIT/AOT コンパイル済みコードのマイグレーションは未対応である。(Source: §2, §7) - ファイル I/O やネットワークソケットなど、WASI 越しの OS レベル状態は完全には保存・復元できていない。(Source: §2) - WAMR への切り替えでは classic interpreter の性能制限により実行性能が低下する。(Source: §5-B) - 実験規模は限定的(3 ノードクラスタ、2 VM クラスタ)であり、大規模環境での有効性は今後の検証が必要である。 ## 関連 - 概念: [[WebAssembly]] / [[ランタイム中立チェックポイント]] / [[ホットリスタート]] / [[動的ランタイム切り替え]] / [[セルフヒーリング]] / [[コンテナオーケストレーション]] / [[チェックポイント]] - エンティティ: [[WasmEdge]] / [[WAMR]] / [[Kubernetes]] / [[Prometheus]] / [[Katsuya Matsubara]] / [[Yuzuki Saito]] / [[Daigo Fujii]] / [[Yuki Nakata]] / [[Future University Hakodate]] / [[SAKURA internet Inc.]] - 先行研究: [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]] - 関連 MOC: [[System Engineering - MOC]] / [[Software Engineering - MOC]] / [[SRE - MOC]]