軽量・高速なエミュレーター内蔵コンテナランタイム

• コンテナは様々な場面で用いられるようになってきている
  • Dockerfileを書いてアプリケーションをデプロイ
  • Kubernetesでオートスケール
  • 環境構築を迅速に
  • 環境間の差異を少なくする
  • etc...
• アプリケーションを安全かつ軽量に動かせるため重宝されている
  • これはコンテナランタイムが裏で様々な処理をしている

• 低級ランタイムがホストカーネルと実際に通信してリソースの隔離などを行う
  • Linuxではnamespaceやcgroupといった機能を用いることで実現可能
• ホストとカーネルを共有しているのでアーキテクチャが異なるアプリケーションは直接動かせない

→ 両者の"いいとこどり"をしたようなものは考えられないか?

• コンテナの上でホストと異なるアーキテクチャのアプリケーションを動かしたい場面はある
  • 例えばエッジコンピューティング環境など
    • コンテナマイグレーションの文脈ではH-container$^1$というバイナリをデコンパイルして他アーキテクチャにコンパイルするアプローチの先行研究がある
  • ナイーブにはコンテナの上でQEMUなどのエミュレーターを動かせば良い
    • しかしこれには余計なオーバーヘッドがかかる
    • Linuxにはbinfmt_miscのような他アーキテクチャバイナリを実行できる仕組みがあるが，これも実際には指定したエミュレーターを呼んで実行しているだけ

コンテナランタイムとエミュレーターを統合してしまえば良いのでは?

1: Xing, Tong, et al. "H-container: Enabling heterogeneous-ISA container migration in edge computing." ACM Transactions on Computer Systems (TOCS) 39.1-4 (2022): 1-36.

• ホストと異なるアーキテクチャのアプリケーションは実行がエミュレーターに移譲
• エミュレーションターゲットを増やしていけば理論上アーキテクチャフリーなコンテナランタイムができる（ラボユース期間中ではRISC-Vエミュレーターを作成）

• microVM
  • 仮想マシンを用いてコンテナを動かしてホストと異なるアーキテクチャのアプリケーションを実行できる
  • 基本的にKVM等のハードウェアレベルでのエミュレーションなのでオーバーヘッド減少は見込めない（セキュリティ向上が主眼）
• gVisor
  • システムコールがコンテナから出るとそれをインターセプトして独自のシステムコールインターフェースで処理するコンテナランタイム
  • システムコールが多いアプリケーションだとオーバーヘッドが顕著
• WebAssembly
  • 広義アーキテクチャフリー枠
  • 利用できる計算リソースに大きな制限がある
  • WASIを用いたとしても使えるシステムコールにも制限

• 仮にコンテナランタイムとエミュレーターを統合してもエミュレーションが遅ければ意味が薄れる
  • 単に既存のコンテナの上でQEMUのような速いエミュレーターを使う方が速いかもしれないから
• そこでQEMUにも用いられているTiny Code Generatorを用いたエミュレーションの高速化を実装

• Tiny Code Generator (TCG)
  • QEMU内部で用いられている，特定のISAに依存しない中間表現

https://msyksphinz.hatenablog.com/entry/2020/08/05/040000より

• TCG Block Chaining（高速化の工夫）
  • ジャンプが含まれない単位で，複数個のゲスト命令をまとめてホスト命令に変換する
  • 命令ごとにデコードして実行するよりも高速に動作する可能性が高い

• DONE: Linux向けの低級コンテナランタイムの作成
• DONE: TCGによる高速化を実装したRISC-Vエミュレーターの作成
• TODO：ランタイムとエミュレーターの統合部分を作成
  • 現在は別個のリポジトリで独立して開発しているため
• TODO：RISC-Vの対応命令セットや対応アーキテクチャの拡充
  • AArch64などに対応できるとモバイル端末などのテスト環境を用意できて嬉しい