Rust Workersの信頼性向上：wasm-bindgenにおけるパニックとアボートリカバリ

Rust Workers は、Rust を WebAssembly にコンパイルして Cloudflare Workers 上で動作しますが、私たちが確認したところ、WebAssembly にはいくつかの鋭い角（sharp edges）があります。panic や予期せぬ abort が発生すると、ランタイム（runtime）が未定義の状態に陥ることがあります。Rust Workers のユーザーにとって、panic は歴史的に致命的なものであり、インスタンスをポイズン（poisoning）し、場合によっては一定期間 Worker 自体が使用不能（bricking）になる可能性もありました。 私たちはこれらの問題を検出し軽減することができましたが、Rust Worker が予期せず失敗し、それに伴って他のリクエストも失敗する可能性がわずかに残っていました。1 つのリクエストに影響を与える未処理の Rust abort が、兄弟リクエスト（sibling requests）を含むより広範な障害にエスカレートしたり、新しい着信リクエストに影響を及ぼし続けたりするケースもありました。この根本原因は、Rust Workers が依存する Rust-to-JavaScript バインディング（Rust-to-JavaScript bindings）を生成するコアプロジェクトである wasm-bindgen にあり、組み込みのリカバリセマンティクス（recovery semantics）が欠如していたことにありました。 この記事では、最新の Rust Workers がこの abort 起因のサンドボックスポイズン（sandbox poisoning）を解決する包括的な Wasm エラーリカバリをどのように処理するかをご紹介します。この取り組みは、昨年設立された wasm-bindgen 組織内でのコラボレーションの一環として、wasm-bindgen プロジェクト本体にコントリビューションされました。まず panic=unwind サポートにより、1 つの失敗したリクエストが他のリクエストをポイズンしないことを保証し、その後 abort リカバリメカニズム（abort recovery mechanisms）により、Wasm 上の Rust コードが abort 後に再実行されないことを保証しています。 Initial recovery mitigations 私たちのこの分野での信頼性向上に向けた最初の試みは、本番環境の Rust Workers で発生する Rust panic および abort による障害を理解し、封じ込めることに焦点を当てていました。私たちは、Worker 内の失敗状態を追跡し、後続のリクエストを処理する前にアプリケーションの完全な再初期化をトリガーするカスタム Rust panic handler（panic ハンドラ）を導入しました。JavaScript 側では、すべてのエントリポイント（entrypoints）が一貫してカプセル化されるように、Proxy ベースのインディレクション（Proxy-based indirection）を使用して Rust-JavaScript の呼び出し境界をラップする必要がありました。また、障害発生後に WebAssembly モジュール（WebAssembly module）を正しく再初期化できるよう、生成されたバインディングに対して対象的な修正も施しました。 このアプローチはカスタム JavaScript ロジックに依存していましたが、信頼性の高いリカバリが可能であることを実証し、実際に観測されていた永続的な障害モードを排除しました。このソリューションはバージョン 0.6 から workers‑rs ユーザー全員にデフォルトで提供され、以降のセクションで説明するより一般的でアップストリームにマージされた abort リカバリメカニズム（abort recovery mechanisms）の基盤を築きました。 Implementing panic=unwind with WebAssembly Exception Handling 上記で説明したアボート（abort）回復メカニズムは、Workerが失敗から生き残ることを保証しますが、その代償としてアプリケーション全体を再初期化します。ステートレスなリクエストハンドラにとってはこれで問題ありません。しかし、Durable Objectsのようにメモリ内に意味のある状態を保持するワークロードでは、再初期化は状態の完全な消失を意味します。1つのリクエストでの単一のパニック（panic）が、他の並行リクエストで使用されているメモリ内状態をすべて消去してしまう可能性があります。 通常のネイティブなRust環境では、パニックをアンワインド（unwind）でき、デストラクタを実行して状態を失わずにプログラムを回復できます。しかしWebAssemblyでは、歴史的に状況は大きく異なっていました。wasm32-unknown-unknown経由でWasmにコンパイルされるRustはデフォルトでpanic=abort（アボート）設定になるため、Rust Worker内部でのパニックはunreachable命令による突然のトラップを引き起こし、WebAssembly.RuntimeErrorを返してWasmからJSへ終了します。 インスタンスの状態を破棄せずにパニックから回復するためには、wasm-bindgenにおけるwasm32-unknown-unknown向けのpanic=unwind（アンワインド）サポートが必要でした。これは2023年に主要なエンジンで広く採用されたWebAssembly例外処理提案（WebAssembly Exception Handling proposal）によって可能になったものです。 `RUSTFLAGS='-Cpanic=unwind' cargo build -Zbuild-std`でコンパイルを開始し、これによりアンワインドサポート付きで標準ライブラリを再構築し、適切なパニックのアンワインドを行うコードを生成します。例えば： ```rust struct HasDropA; struct HasDropB; extern "C" { fn imported_func(); } fn some_func() { let a = HasDropA; let b = HasDropB; imported_func(); } ``` はWebAssemblyに次のようにコンパイルされます： ```wasm try call catch_all call call rethrow end call call ``` これにより、imported_func()がパニックしてもデストラクタは確実に実行されます。同様に、`std::panic::catch_unwind(|| some_func())`は次のようにコンパイルされます： ```wasm try call ;; set result to Ok(return value) catch try call ;; set result to Err(panic payload) catch_all call unreachable end end ``` これらをエンドツーエンドで動作させるには、wasm-bindgenツールチェーンにいくつかの変更を加える必要がありました。WebAssemblyパーサーのWalrusはtry/catch命令を処理する方法を知っていなかったため、そのサポートを追加しました。また、ディスクリプタインタプリタにも例外処理ブロックを含むコードを評価する方法を教える必要がありました。これにより、panic=unwind設定でフルアプリケーションをビルドできるようになりました。 最後のステップは、wasm-bindgenが生成するエクスポートを修正し、RustとJavaScriptの境界でパニックをキャッチして、それらをJavaScriptのPanicError例外として表面化することでした。一点注意すべき点として：Rustはextern "C"関数をアンワインドする際に外部例外をキャッチしてアボートするため、境界を跨ぐアンワインドを明示的に許可するためにエクスポートにはextern "C-unwind"のマークが必要でした。Futuresの場合、パニックはPanicErrorを伴ってJavaScriptのPromiseを拒否します。 クロージャには特別な注意が必要でした。`panic=unwind`でビルドされた場合にのみ `UnwindSafe` をチェックする新しい `MaybeUnwindSafe` トレイトを通じて、unwind安全性（unwind safety）が適切に検証されるようにしました。しかし、これによりすぐに問題が露見しました。多くのクロージャはunwind後も存続する参照をキャプチャしており、本質的にunwind安全ではありません。コンパイラを満たすためにユーザーが誤ってクロージャを `AssertUnwindSafe` でラップすることを促してしまう状況を避けるため、unwind安全性が保証できない場合にunwindの代わりにパニック発生時にプロセスを終了する `Closure::new_aborting` バリアントを追加しました。 パニックunwind（unwinding）を有効にした場合： エクスポートされたRust関数内のパニックはwasm-bindgenによってキャッチされます パニックは `PanicError` 例外としてJavaScriptに表面化します 非同期エクスポートは、返されたプロミスを `PanicError` で拒否します Rustのデストラクタが正しく実行されます WebAssemblyインスタンスは有効かつ再利用可能であり続けます このアプローチの詳細およびwasm-bindgenでの使用方法は、Wasm Bindgenの最新ガイドページ「Catching Panics」で解説されています。 abortリカバリ（回復処理） `panic=unwind`のサポートがあっても、abort（強制終了）は依然として発生します。よくある原因の一つはメモリ不足エラーです。abortではunwindができないため、状態の完全な回復は不可能ですが、無効な状態が後続のリクエストでエラーを引き起こすのを防ぐため、少なくとも将来の操作に対してabortを検出し、リカバリすることは可能です。 パニックunwindのサポートは、abortリカバリにおいて新たな問題をもたらしました。Wasmからエラーを受信した際、それがextern "C-unwind" 外部例外（foreign exception）に起因するものか、それとも本物のabortなのかを判別できません。WebAssemblyにおけるabortには様々な形態があります。 これを技術的に解決する方法として、明確にabortであるエラーすべてにマークを付けるか、明確にunwindであるエラーすべてにマークを付けるかの2つの選択肢がありました。どちらでも機能しましたが、後者を選択しました。すでに外部例外処理で生のWATレベル（WebAssemblyテキスト形式）のException Handling命令を直接使用していたため、abortするunwind安全でない例外と区別するために、外部例外にexceptionタグを実装する方が容易だと判断しました。 WebAssembly Exception Handlingにおけるこの `Exception.Tag` 機能のおかげで回復可能エラーと回復不可能エラーを明確に区別できるようになったため、新たなabortハンドラおよびabort再入ガード（reentrancy guards）の両方を統合することができました。 初期化時に使用できる新しいabortフック `set_on_abort` を用いて、プラットフォーム組み込みのニーズに応じて適切にリカバリするハンドラをアタッチすることができます。 パニック（panic）とアボート（abort）のハンドリングを強化することは、無効な実行状態を回避する上で極めて重要です。WebAssembly（Wasm）では、Wasm が JavaScript（JS）を呼び出し、JavaScript（JS）が任意の深さで Wasm に再進入できるなど、深く交差するコールスタック（call stacks）が許可されます。同時に、複数のタスクが同じインスタンス内で動作することもあります。以前は、1つのタスクやネストされたスタックで発生したアボート（abort）が、JS を介して上位のスタックを無効化することが保証されておらず、未定義動作（undefined behavior）を引き起こす可能性がありました。実行モデル（execution model）を確実に保証するためには細心の注意が必要であり、この分野への貢献は現在も継続しています。 アボート（abort）は決して望ましいものではなく、失敗時のリ初期化（reinitialization）は絶対的な最悪シナリオですが、最後の防衛線として重要なエラーリカバリ（error recovery）を実装することで、実行の正確性を保証し、将来の操作が成功可能であることを確保します。無効な状態は永続化されないため、単一の失敗が複数の失敗に連鎖することが防がれます。 拡張機能：wasm-bindgen ライブラリ向けの abort リ初期化 これに取り組んでいる間に、wasm-bindgen でビルドされた JS によって使用されるライブラリにとってこれが共通の問題であり、リカバリを実行可能とするためにアボートハンドラー（abort handler）をアタッチすることでも恩恵を得られることに気づきました。 しかし、Wasm を ES モジュール（ES module）としてビルドして直接インポートする場合（例：`import { func } from ‘wasm-dep’`）、ユーザーの JS アプリケーション内にあるすでにリンクされ初期化されたライブラリに対して `func()` を呼び出す際に Wasm abort が発生した場合、そのリカバリメカニズムが何であるかは明確ではありません。 厳密には Rust Workers のユースケースではありませんが、私たちのチームは Rust 基盤の Wasm ライブラリ依存関係を実行する JS ベースの Workers ユーザーもサポートしています。もし同時にこの問題を修正できれば、それは間接的に Cloudflare Workers プラットフォームにおける Wasm 利用にも恩恵をもたらすでしょう。 Wasm ライブラリのユースケースにおける自動 abort リカバリをサポートするため、wasm-bindgen に実験的なリ初期化メカニズム `--reset-state-function` のサポートを追加しました。これにより、生成されたバインディングの消費者が再インポートしたり再生成したりする必要なく、Rust アプリケーションが次の呼び出しに向けて内部の Wasm インスタンスを初期状態にリセットするよう効果的に要求できる関数が公開されます。古いインスタンスからのクラスインスタンスは、そのハンドルが孤立するため例外をスローしますが、その後新しいクラスを構築することができます。Wasm ライブラリを使用する JS アプリケーションはエラー状態になりますが、完全に機能停止することはありません。 この機能の完全な技術詳細と wasm-bindgen での使用方法は、新しい wasm-bindgen ガイドセクション「Wasm Bindgen: Handling Aborts」で解説されています。 Rust Wasm 例外処理エコシステムの成熟 この取り組みにおけるアップストリームへの貢献は wasm-bindgen プロジェクトで止まりませんでした。`panic=unwind` での Wasm ビルドにはまだ実験的な nightly Rust ターゲットが必要であるため、私たちはこれを安定版 Rust に取り込むのを支援するため、WebAssembly Exception Handling に対する Rust の Wasm サポートを前進させる作業も続けています。 WebAssembly 例外処理（WebAssembly Exception Handling）の開発において、仕様の後期段階での変更により、2つのバリエーションが生まれました。従来の例外処理（legacy exception handling）と、最終的な現代的な例外処理「exnref付き」（modern exception handling "with exnref"）です。現在、Rust の WebAssembly ターゲットは依然として従来のバリエーション向けのコードをデフォルトで出力します。従来の例外処理は広くサポートされていますが、現在は非推奨となっています。 以下の JavaScript プラットフォームのリリース以降、現代的な WebAssembly 例外処理（WebAssembly Exception Handling）がサポートされています： ランタイム バージョン リリース日 v8 13.8.1 2025年4月28日 workerd v1.20250620.0 2025年6月19日 Chrome 138 2025年6月28日 Firefox 131 2024年10月1日 Safari 18.4 2025年3月31日 Node.js 25.0.0 2025年10月15日 サポートマトリックスの調査を進める中で、最大の懸念事項は Node.js 24 LTS のリリーススケジュールでした。このままでは、すべてのエコシステムが 2028年4月まで従来の WebAssembly 例外処理に縛られたままになってしまいます。 この不一致を発見した私たちは、現代的な例外処理を Node.js 24 リリースにバックポートし、さらにこのターゲットのサポートを確保するために Node.js 22 リリースラインで動作させるために必要な修正もバックポートすることができました。これにより、来年には現代的な例外処理の提案がデフォルトターゲットとなる見込みです。 今後数ヶ月にかけて、エンドユーザーにとって panic=unwind（パニックの巻き戻し）と現代的な例外処理への移行が可能な限り目立たないように、作業を進めていきます。 エコシステムに対するこれらの長期的な投資には時間がかかりますが、それによって Rust WebAssembly コミュニティ全体にとってより強固な基盤が築かれます。これらの改善に貢献できることを嬉しく思います。 Rust Workers における panic unwind の使用 Rust Workers のバージョン 0.8.0 では、ここで説明する手順に従ってビルドコマンドに追加できる新しい `--panic-unwind` フラグが導入されました。 このフラグを使用すると、パニックを完全に回復できるようになり、アボートリカバリ（abort recovery）は新しいアボート分類およびリカバリフックメカニズム（abort classification and recovery hook mechanism）を使用します。より安定した Rust Workers の体験を得るために、アップグレードして試すことを強く推奨します。また、次のリリースで panic=unwind をデフォルトにする予定です。panic=abort に留まるユーザーも、引き続き 0.6.0 から提供されているカスタムリカバリラッパー処理の恩恵を受け続けます。 Rust Workers の安定性へのコミット この作業は、Rust Workers の安定版リリースに向けた継続的な取り組みの一環です。Wasm プラットフォームの基盤にあるこれらの鋭いエッジ（問題点）を根本から解決し、意味のある箇所ではエコシステムへの貢献を行うことで、私たちのプラットフォームだけでなく、Rust、JS、Wasm の全体のエコシステムにとってより強固な基盤を築いています。 Rust Workers 向けには今後の改善計画が複数あり、チームの Guy Bedford が先月 Wasm.io で開催された「Rust & JS Interoperability」の講演でプレビューした wasm-bindgen ジェネリクス（wasm-bindgen generics）や自動 bindgen（automated bindgen）を含む、これらの追加作業に関する更新情報をまもなく共有する予定です。 Cloudflare Discordの #rust-on-workers でお会いください。また、workers-rs および wasm-bindgen の GitHub プロジェクトへのフィードバックや議論、特に新規コントリビューターからの参加を心より歓迎いたします。

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト