博士

ロボ子、KoyebがLight Sleepっていうすごい技術を発表したみたいじゃぞ！CPUワークロードのコールドスタートがたったの200msになるらしい。

ロボ子

200msですか！それはすごいですね。従来のコールドスタートに比べて、どれくらい速くなったんですか？

博士

それがじゃな、Light Sleepを実現するために、アプリケーションのデプロイ方法からネットワークスタックの挙動、スナップショット、eBPFまで、全部見直したらしいぞ。

ロボ子

全部ですか！かなり大規模な変更ですね。具体的には、どのような技術が使われているんですか？

博士

以前はFirecrackerを使ってたみたいじゃが、GPUインスタンスとの連携に課題があったから、Cloud Hypervisorに移行したらしい。さらに柔軟性を高めるために、Kata Containersを導入して、VMMの抽象化レイヤーとして利用してるみたいじゃな。

ロボ子

Cloud HypervisorとKata Containersですか。コンテナとVMを連携させるために、どのような工夫がされているんですか？

博士

Kata Containersのshim（containerd-shim-kata-v2）を介して、コンテナとVMを連携させてるみたいじゃ。さらに、スナップショット機能（pause_with_snapshot、resume_from_snapshot）をKata shimに追加したらしいぞ。

ロボ子

スナップショット機能ですか。VMの状態を保存して、高速に復元できるんですね。

博士

ところがじゃな、Cloud Hypervisorのvirtio-fsに、スナップショットからの復元時に問題があることが判明して、virtio-fsを一時的に廃止したらしいぞ。

ロボ子

それは残念ですね。他に何か問題はありましたか？

博士

Cloud Hypervisorのネットワーク復元機能は、ファイル記述子の受け渡しにSCM_RIGHTSを使用するんじゃが、HTTP APIでは対応してないから、Kata内部を修正して、プロセス間通信（IPC）を実装したらしい。

ロボ子

なるほど。HTTP APIの制約を回避するために、IPCを実装したんですね。

博士

さらにじゃ、eBPFプログラムを各ノードに注入して、インバウンドパケットを監視して、インスタンスのアイドル状態を検出してるらしいぞ。Consulのヘルスチェックによるトラフィックを、iptablesとeBPFプログラムで除外してるのもポイントじゃな。

ロボ子

eBPFを使って、アイドル状態を効率的に検出しているんですね。ヘルスチェックのトラフィックを除外することで、誤検出を防いでいるんですね。

博士

scaletozero-agentが、containerd APIを呼び出してVMを一時停止（pause_with_snapshot）するんじゃ。VM一時停止中、Nomadがヘルスチェック失敗と判断しないよう、scaletozero-agentがダミーHTTPサーバーで200 OKを返すらしい。

ロボ子

Nomadのヘルスチェックを欺くために、ダミーサーバーで応答を返すんですね。面白い工夫ですね。

博士

eBPFプログラムが、スリープ状態のサービスへのトラフィックを検知すると、scaletozero-agentがresume_from_snapshotを実行して、サービスを復帰させるんじゃ。TCPの再試行により、最初のパケットが失敗しても、次の試行時にはサービスが起動している状態を実現してるらしいぞ。

ロボ子

TCPの再試行を利用して、サービス起動の遅延を吸収しているんですね。よく考えられていますね。

博士

現在はCPUベースのサービスにScale-to-Zeroが実装されてて、今後はGPUベースのサービスにも拡張予定らしいぞ！

ロボ子

GPUベースのサービスへの拡張、楽しみですね！

博士

しかしロボ子よ、これだけ色々やって200msって、まるで私がカップラーメンにお湯を入れる時間と変わらないじゃないか！

ロボ子

博士、それは少し違いますよ！カップラーメンは3分待ちますから！