アーキテクチャ

// ARCHITECTURE

3 つの実行レイヤー。

あなたのバグに合うレイヤーはどれか——Layer 1 のブラウザネイティブ WebAssembly、Layer 2 のコンテナ、Layer 3 の record-replay。それぞれ得意なバグの種類が違います。

// 01 · LAYER 1

WebAssembly、ページの中で。

ユーザーのブラウザタブの中で再現が直接実行される層です。 アカウントもインストールも不要、ページを開けばすぐ動きます。

このレイヤーが向くバグ

  • アルゴリズムバグ(ソート、パース、テキスト処理)。
  • データ処理のリグレッション(pandas / polars / numpy のシェイプバグなど)。
  • データベースの動作バグ(SQLite のクエリ異常、JSON パスのエッジケースなど)。
  • ファイルシステム・ネットワーク・プロセスモデルに触れない、ライブラリ内部のロジックバグ。

起動時間

  • 初回(キャッシュなし): 1〜10 秒。ランタイムのダウンロード(Pyodide なら ≈ 10 MB 圧縮)とインスタンス化が支配的。
  • 2 回目以降: ブラウザのキャッシュが効いて 1 秒未満で起動。
  • 再現スクリプトの実行自体: ミリ秒〜数秒。

このレイヤーで届かないこと

  • メモリ。 ブラウザタブはピーク 1 GB 超で性能が劣化、4 GB が実質上限。本番規模のデータは Layer 2 へ。
  • システムコール。 本物の fork/exec、本物のソケットは使えない。WASI シムが一般的なケースをカバー。
  • 並行性バグ。 デフォルトはシングルスレッド。データレースやハイゼンバグは Layer 3 へ。
  • コンパイラ自体のビルド。 Rust のバグはブラウザ内で再現できますが、Rust コンパイラ自体のビルドは Layer 2。

対応ランタイム

言語ランタイム
PythonPyodide
SQLitesqlite-wasm(Pyodide 経由)
Rustwasm32-wasip1
RubyRuby.wasm
PHPphp-wasm

// 02 · LAYER 2

Docker / microVM、訪問者のマシン上で。

本物のファイルシステム、本物のプロセス、本物のネットワークが必要なバグのための層です。 Vivarium 側で再現を実行するのではなく、訪問者自身の Docker(または Codespaces)で動かす カタログ型の配信モデルを採用しています。

このレイヤーが向くバグ

  • プロジェクト全体の再現——実際のパッケージインデックスへの依存解決を要するバグ。
  • システムコール依存のバグ——本物の fork、ソケット、ファイルロック、シグナル。
  • ツールチェーン固有のバグ——特定の GCC、特定の glibc、特定のカーネル ABI の癖。
  • プロセス間の相互作用が原因のマルチプロセスバグ。

使い方

各レシピページにはピン留めされた Dockerfile と、コピペ可能な docker run … コマンド、そして ghcr.io/aletheia-works/vivarium-<slug> に公開された ビルド済みイメージへのリンクが揃っています。CI で取得した verdict スナップショットがページ上に表示され、訪問者自身の docker run がライブ再現になります。Codespaces 対応のレシピには「Open in Codespaces」 バッジも提供されます。

このレイヤーで届かないこと

  • ページ内では実行されない。 訪問者がローカルか Codespaces で実行します。
  • Docker(または Codespaces アカウント)が必要。 どちらもない場合は、レシピと verdict スナップショットの閲覧のみ可能。
  • 並行性そのものをデバッグするバグ。 Layer 2 は本物のスレッドで動きますが、ハイゼンバグの再現性確保は Layer 3 の領分。

// 03 · LAYER 3

トレースを同梱、どこでも再生。

数回再実行しても再現する保証がないハイゼンバグのための層です。 Vivarium 側であらかじめ録音したトレースを GHCR イメージに焼き込み、 訪問者は再生だけすれば済むようにしています。

このレイヤーが向くバグ

  • データレース、メモリ順序バグ、単純な再実行では再現しない use-after-free。
  • 長時間 replay シナリオ:何時間ものキャプチャ実行を数分で巻き戻す。
  • 特定のメッセージインターリーブに依存する分散システムバグ。
  • 事後フォレンジック分析——録音済みトレースを後ろに戻る形のデバッグ。

使い方

各 Layer 3 レシピは、トレースを焼き込んだ自己完結 GHCR イメージとして配布されます。 rr replay は PMU を必要としないため、訪問者と CI の再生はどちらも コモディティな Linux ホストで動作します。録音そのものは PMU を 備えた Linux/x86_64 環境を要するため、レシピ追加時のオフライン作業として Vivarium 側で済ませてあります。

このレイヤーで届かないこと

  • 環境制約。 訪問者のマシンは Linux/x86_64 が前提。ARM Mac や Windows の場合は Codespaces または WSL2 + Docker にフォールバック。
  • カバレッジの形が違う。 rr は単一プロセス Linux x86_64、分散シミュレーションツールは分散システムを対象。互いの領域はカバーしない。
  • トレースが大きい。 レシピあたり数十 MB から一桁 GB のオーダー。

どのレイヤーで動くかは、レシピ側があらかじめ宣言しています。あなたが選ぶ必要はなく、 レシピを開けば自動的にそのレイヤーで動作します。

// 次のページ

実例を見る

3 つのレイヤーがそれぞれどんなバグを再現しているか、再現一覧で実物を確認できます。

VIVARIUM は ALETHEIA-WORKS の一部 · GitHub でソースを見る →