AI解説

情報源：著者版PDF（手元）の全文を精読。実装 Elastic Kernel: https://github.com/MRyutaro/ElasticKernel。 図について：原論文の図（Fig.1–7）は著者版PDF内のもので、PDF自体はリポジトリ非公開（.gitignore で除外）。ここでは要点をAI生成SVGで補足し、数値は本文 §4 の値をそのまま記す。 （本ノートは著者自身の論文。# 自分のコメント 欄に研究の位置づけを書き足していく前提。）

一言で

オンプレとクラウドにまたがる JupyterHub を、需要に応じて自動スケールさせ、クラウドが空いたら走行中のノートブックサーバを“状態ごと”オンプレへ移行してクラウドノードを早く止めることで、応答性を保ちつつクラウド利用料を下げるプラットフォーム ElasticHub の提案。2 つの部品 ElasticHub Orchestrator（EHO＝スケール判定・移行の制御） と Elastic Kernel（セッション状態の自動 checkpoint/restore） からなる。シミュレーション評価で、オンプレのみ構成より待ち時間を削減しつつ、移行によりクラウド稼働を 153→134 node-hours（約12%） 削減、移行時間も最適化で 8.4s→6.2s（−26.2%） に短縮した。

背景・問題

JupyterHub は Jupyter Notebook を PaaS として複数ユーザに提供し、Jetstream・TACC・コペンハーゲン大・NERSC Cori など多くの学術計算機センターで使われている（本リポジトリの Scaling JupyterHub・TACC・corc・NERSC Cori を参照）。

ここでの問題は次の連鎖にある。

• 授業や講習でアクティブユーザ数が急増すると、オンプレ資源の容量を需要が超え、待ち時間が増えて体験が悪化する。
• 事前の需要予測は難しく、先回りの増設は資源の無駄になりやすい。需要増時に動的に資源を足す cloud bursting（Endo et al.、Noguchi et al.）が有望。
• ただしクラウド資源はオンプレより高額で、料金はノード稼働時間に比例する。よってクラウドは「オンプレが限界のときだけ」割り当て、できるだけ早く解放したい。
• しかも割り当て／解放はユーザ透過でなければならない。走行中の single-user notebook server をクラウド→オンプレに移すと、カーネル内のセッション状態（ユーザ定義変数・import 済みモジュール）が失われ、ユーザは中断点から再開できない（移行中はそもそも操作できず、これはダウンタイムになる）。

→ したがって本研究の課題（やること）は、「オンプレが限界のときだけクラウドを使い、移行時にはセッション状態を保ったまま、ユーザ透過に自動スケールする JupyterHub」を作ること。著者はこれを ElasticHub として実装する。

押さえるべき2つの技術課題

1. 動的スケール：オンプレ容量の変化に応じて計算資源を scale-out / scale-in する必要がある。素の Cluster Autoscaler は「サーバがどのノードにも置けなくなって初めて」増設するため、クラウドノードの起動に数分かかる遅延がそのまま待ち時間になる。→ オンプレの空きを見て前もってクラウドノードを起動したい。
2. 状態保存：移行時にカーネル内セッション状態を checkpoint/restore し、かつダウンタイムを短く保つ必要がある。

既存 checkpoint/restore 手法の限界（なぜ新機構が要るか）

• CRIU（venkatesh2019criu も参照）は OS プロセスの全メモリ領域をダンプするため、カーネル内セッション状態が大きいほどチェックポイントが肥大化し、CR 時間が伸びる。Elsa はこの CRIU を JupyterHub に適用したもの。
• StoreMagic / Dill / CloudPickle / ElasticNotebook はいずれも明示的なユーザ操作を要し、自動移行に対応しない。さらに ElasticNotebook ライブラリを single-user notebook server に import する際の遅延が、移行時間を押し上げうる。

→ 「ユーザ関与なしで動き、CR 時間を低く保つ」新しい機構が必要、というのが提案の動機。

提案：ElasticHub

ElasticHub は ElasticHub Orchestrator（EHO） と Elastic Kernel の 2 部品からなる。クラスタは control node（オンプレ）と複数の worker node（オンプレ＝優先度10／クラウド＝優先度1）で構成し、優先度によりオンプレが先にスケジュールされる。control node に JupyterHub と EHO を、各 worker node に「single-user notebook server＋Elastic Kernel」のコンテナを置く。home／notebook ファイルは共有 NFS で両系から同一参照する。

補足図（AI生成）：control node の EHO が Kubernetes API でクラスタを監視し、① RAM 占有率がしきい値を超えるとクラウドノードを起動（scale-out）、② オンプレに空きが出ると走行中サーバを状態ごとオンプレへ移行してクラウドノードを停止（scale-in with migration）。Elastic Kernel が各コンテナ内でセッション状態の CR を担う。

ElasticHub Orchestrator（EHO）— §2.2 の課題に対応

EHO は control node 上の常駐サービスで、ノードのスケールとサーバ移行を行う。

制御フロー（Fig.4）：EHO は Tmon（=15s）ごとにクラスタ資源使用率を監視する。頻繁なスケールを避けるため、前回スケールからクールダウン Tcool（=580s）が経過した場合のみスケールを許可する。両条件を満たしたとき、まず scale-out 条件を、満たさなければ scale-in 条件を評価する。

Scale-out（しきい値ベース）：ノード i・資源種別 k∈{CPU, RAM} について、占有量 Ok_i(t)（そのノードで走るコンテナの resource request 合計）と割当可能量 Ck_i を定義し、ノード集合 S 上の占有率を

Rk(S,t) = ( Σ_{i∈S} Ok_i(t) ) / ( Σ_{i∈S} Ck_i ) × 100 [%] …(1)

とする。全アクティブ worker ノード集合 Ntotal(t) の RAM 占有率がしきい値 θout を超えたら（RRAM(Ntotal(t),t) > θout …(2)）scale-out する。RAM を主指標にするのは「Jupyter ワークロードでは RAM が律速になりやすい」ため。条件成立時、EHO はクラウドプロバイダ API で未起動ノードを立ち上げ、ready になったら Kubernetes uncordon でスケジュール可能にする。

Scale-in（2段階判定）：(1) アクティブなクラウドノードから載っている single-user notebook server が最も少ないノードを移行対象に選ぶ（影響ユーザ数を最小化する方針。同数ならRAM占有が最小のもの）。(2) そのノード上の全サーバが他ノードへ移行可能かを、現行 Kubernetes スケジューリングをシミュレートして判定する。サーバは RAM 要求の降順に処理し、宛先ノード h が

Ck_h − Ok_h(t) ≥ Dk_j (∀k∈K) …(3)　（Dk_j＝サーバ j の資源要求）

を満たせば feasible とする（オンプレ優先、同優先なら使用率が高いノードを選ぶ）。1 台でも宛先が無ければその周期では scale-in しない。全サーバが仮割当できたら、対象ノードを cordon（再配置の出戻り防止）→ JupyterHub API で RAM 降順にサーバを再起動して他ノードへ再スケジュール → 最後にクラウドノードを停止する。制御を単純・安定に保つため、1 監視周期で外すクラウドノードは最大1台。

なお予備実験では、移行時間はサーバ／コンテナの再起動によるほぼ一定のオーバーヘッドが支配的で、ノートブックのメモリサイズの影響は相対的に小さかった、とされる（だから「載っているサーバ数が少ないノード」を優先する設計になっている）。

Elastic Kernel — §2.3 の課題に対応

CR をユーザ関与なしで行うため、ElasticNotebook を Jupyter カーネルに統合した Elastic Kernel を開発。ElasticNotebook はセル再実行＋ファイルベースの変数 save/load を組み合わせるので、状態が大きい／計算が長い場合でも CR 時間を短く保てる。

問題は ElasticNotebook の import が遅いこと。プロファイルすると PyTorch・Pandas・LightGBM など外部ライブラリの import が時間を食っていた。これらは変数の型チェックのためだけに使われている。Python はオブジェクトのクラスのメタデータを見れば import せずに型判定できるので、ライブラリ import を「メタデータベースの型チェック」に置き換える最適化を入れた（§4.2 で効果を測定）。

評価

2 つの観点で評価：(1) ユーザ待ち時間とクラウドノード稼働時間、(2) Elastic Kernel による移行時間のプロファイルと最適化。

(1) 待ち時間とクラウド稼働時間（シミュレーション）

EHO の制御フローを模すシミュレータを作り、2 日間・1 秒刻みで評価（主なパラメータ：オンプレ 8 ノード×50 RU、1 RU＝0.5 vCPU/1 GiB、クラウドノード起動 290s、サーバ寿命 平均60分(SD15)、サーバ起動 6s、移行ダウンタイム 11–22.2s、Tmon=15s、Tcool=580s）。Day1 を通常、Day2 をバースト的負荷とした手作りワークロードを使用。

• クラウド利用の効果：θout を十分大きくしてクラウドを使わない設定（実質オンプレのみ）は、需要急増時に最大待ち時間が急上昇し 1000s 超に張り付いた。→ バースト需要下ではクラウドノードが待ち時間削減に有効。
• θout の効果：θout を下げるとクラウドノードを早めに起動でき待ち時間を抑えられる（ある設定では待ち時間ゼロ）一方、下げすぎると余剰クラウド容量が長く残り稼働時間＝コストが増える。
• 移行の効果：移行ありは無し（＝サーバが載っていないクラウドノードしか scale-in できない）に比べ、クラウドノードを早く解放でき、総クラウド稼働を 153 → 134 node-hours（19 node-hours 減、約 12.4%。結論部では 12.2% と記載） 削減。ただし Day2 の一部区間では、早く scale-in した直後に需要が再上昇すると起動遅延の分だけ待ち時間が増える場面もあり、θout は待ち時間とクラウドコストのトレードオフを左右する。

補足図（AI生成）：右側＝Elastic Kernel の import 時間、左側＝移行時間の内訳（数値は §4.2）。クラウド稼働 153→134 node-hours の詳細は原論文 Fig.5 を参照。

(2) Elastic Kernel による移行時間

Podman＋runc でコンテナを動かし（Ubuntu 24.04 / Xeon Silver 4214R / 8 vCPU / 16 GiB）、”Hello World!” だけのノートブックで移行時間を各5回計測。デフォルトの Jupyter カーネルを baseline とした。

• ボトルネック：Elastic Kernel は ElasticNotebook を import する分、移行時間が baseline の 5.6s → 8.4s（+2.8s, +50.0%） に増加。差分はまさに import 時間。
• import の内訳と最適化：-X importtime＋tuna で測ると PyTorch・LightGBM・Pandas 等の外部ライブラリ import が支配的。メタデータベース型判定への置換で import 時間は 2.28±0.023s → 0.58±0.021s に短縮。
• 結果：最適化により移行時間は 8.4s → 6.2s（−2.2s, −26.2%）。最適化後は baseline（5.6s）との差が +0.6s（+10.7%） まで縮小した。

関連研究との関係（本リポジトリ内）

ElasticHub は ElasticNotebook を CR エンジンとして取り込み、それを「JupyterHub の自動運用」という上位レイヤに組み込んだ仕事と読める。状態保存の系譜（Kishu・Chipmink 等）とは「効率的な状態保存をどう運用・移行に活かすか」で接続し、OS レベル CR の Elsa／CRIU とは「粗粒度で重い CR を避ける」点で対照的。cloud bursting の運用観点（Endo・Noguchi）と JupyterHub デプロイ（Scaling JupyterHub・TACC）の交点に位置する。

将来課題として、(1) コンテナ再起動時間を隠してダウンタイムをさらに短縮すること、(2) GPU を使うノートブックの移行対応（現状は非対応）が挙げられている。

Q&A

自分のコメント