AI解説

Tech Report（公開）: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2018/EECS-2018-81.html 著者: Vinitra Swamy（指導: Dean David E. Culler、委員 John DeNero）。UC Berkeley の入門データサイエンス科目 Data 8 とその MOOC 版 Data 8X の運用記録（修士論文・全46頁）。

一言で

UC バークレーの入門データサイエンス科目 Data 8（毎学期約1000人）と、その edX MOOC 版 Data 8X を支える計算基盤を、教育法（pedagogy）・インフラ・学習アナリティクスの3面からまとめた修士論文。学生はブラウザだけでノートブック環境を使える（datahub.berkeley.edu）。基盤は JupyterHub + Kubernetes + Docker で、教育用途で JupyterHub を初めて10万ユーザ規模へスケールさせた事例。ハブ／クラスタのシャーディングでスケールし、OK（OkPy）と Gradescope による自動採点、さらに学生コードを使った Deep Knowledge Tracing の改変まで扱う。

背景・問題

プログラミング入門の需要が世界的に急増する中、困りごとは「環境構築の壁」だ。Data 8 は統計・計算の前提知識を問わず、約1000人・70以上の専攻の学生（男女比 50:50、前提科目なし）が受講する。こうした多様な初学者にとって、ローカルに Python・エディタ・各種パッケージを入れる作業で出る謎のインストール エラーは、多様な学生を計算教室から締め出す主要な障壁になる。

問題は2層ある。

• 教室規模（〜1000人）：環境構築をさせず、全員に同一の動く環境を配りたい。
• MOOC 規模（数万〜10万人）：同じことを、桁違いの同時利用者に、限られた予算と人手で提供したい。MOOC は登録は数万でも完了率が 7〜15% 程度と低く（Coursera 2012 で 7〜9%、Jordan 2015 で平均15%）、ピークと実稼働の差が激しい。

本論文は「ブラウザだけで使える DS 教育環境を、教室から MOOC 規模まで破綻させずに運用するには何が要るか」という問題に、Berkeley の実運用で答える。

提案手法（やったこと）

1. ユーザ ワークフローと基盤（Data 8 / Data 8X）

• Data 8（教室）：学生が datahub のリンクをクリック → proxy が OAuth 認証 → Kubernetes が Docker の Jupyter インスタンスを生成し、ユーザ専用ディスクをマウント → ブラウザで編集開始。culler（idle culler）が非アクティブなノードを削除する。
• Data 8X（MOOC）：edX 上の「launch」ボタンで、(1) LTI（Learning Tools Interoperability）標準で認証して任意のユーザ番号を割当、(2) nbgitpuller（旧 nbinteract）が公開 Git リポジトリからノートブックと依存ファイルをユーザのハブに複製、(3) 正しいノートブックをブラウザで開く——数秒でライブ サーバが立つ。
• 教員ワークフロー：nbgitpuller が GitHub リポジトリの特定パスをユーザの Jupyter サーバへ複製する。教員は課題（.ipynb・CSV・.py）を GitHub に置き、複製用 URL を配るだけで全員に同一環境を配れる。

直感：認証（OAuth/LTI）・起動（K8s + Docker）・教材配布（nbgitpuller + GitHub）を疎結合な部品に分け、学生側の要件をブラウザ1つに圧縮するのが核。

2. スケーリング — シャーディングの三段進化

性能試験で、単一ハブは約5,000ユーザで限界に達し、単一 NFS と相まって単一障害点になることを突き止めた。そこで段階的にシャーディングする。

1. 単一ハブ：proxy + hub + NFS。〜5,000で頭打ち。
2. ユーザをハブ分割：inner edge proxy で複数ハブに割り振る。
3. ハブをクラスタ分割：outer edge proxy が HTTP リクエストを正しい Kubernetes クラスタへ、続いて inner edge proxy が正しいハブへルーティング。home ディレクトリも複数 NFS サーバにシャードする。

シャーディング vs ロード バランシング：シャーディングは「初回ログインでハブを固定割当し、以降そのユーザは常に同じハブ」。ロード バランシングは「毎回最も空いているハブへ」。後者の方が効率的だが、ライブのユーザ数集計が高コストで相関した一斉起動（correlated starts）の混雑も招くため、実装が容易なシャーディングを初期採用した（ロード バランシングは future work）。

3. キャパシティ計画とコスト

• 想定：同時2万〜5万、登録10万〜20万。実績は登録約45,000・週次アクティブ約8,000。
• 資源単位：1ユーザ 1GB RAM、ノード当たり 100 pod 上限のため GCP n1-highmem-16（16 CPU / 104GB）を採用。
• コスト目標：登録者あたり週 $2。
• ハブ/クラスタ上限：ハブ毎 1,000 ユーザ・クラスタ毎 10,000 ユーザに制限。2クラスタ×10ハブ = 同時2万を初期構成に。NFS は n1-highcpu-8・1TB を2台、Postgres を「NFS シャーディング/ハブ シャーディング/ハブ DB」で別インスタンス化。
• 監視：Prometheus + Grafana。最重要指標は走行 pod のエラー率。
• オートスケール：K8s autoscaler を下限〜10%・上限100%で設定。ただし100%でも予算内のため初回は注力せず（future work）。

4. 採点（OK / Gradescope / LTI）

• OK（OkPy）自動採点：Jupyter の Python セル内で ok.score() を呼ぶと即時にスコアが出る。書いたコードの文字列一致ではなく、変数の中身を検査するので、正解への到達経路が無数でも採点できる。可視テスト＋隠しテストを教員が書ける。
• 記述式 → Gradescope：仮説検定・信頼区間などの記述回答は Gradescope に送り（AI 支援のグルーピングで採点を高速化）、採点結果を OK へ戻す。
• edX への成績投稿：LTI 標準で edX に成績を返す。OAuth は本人確認が短時間しか持たないのに対し、LTI なら提出から1週間後でも成績を投稿でき、再認証も不要。

5. 学習アナリティクス — Deep Knowledge Tracing の改変

最終章は、学生のコード提出から学びを予測する Deep Knowledge Tracing（DKT） の改変（最終版は AIED 2018 に短論文として採録）。

• 動機：従来の知識追跡は「各問を1回だけ解く」前提だが、プログラミング教育では同じ問題を解けるまで何度も試行する。これを活かす。
• 改変点：(1) 自由記述のコードをベクトル化して入力（scikit-learn のトークナイザで分割し、語彙サイズ K の tf-idf ベクトル化）、(2) 問題を複数スキルに対応付け、スキル毎に別々の LSTM を学習、(3) Jupyter + OkPy からデータを収集するワークフロー、(4) リアルタイム介入点の予測。
• 入出力：入力は one-hot の（匿名化した学生 ID・問題番号・試行番号）＋コードのベクトル表現。出力は同一スキルの各問について「残り試行回数」の予測。
• 使い道：ある学生の予測残り試行が他より一貫して多い（上位 k%）ときに教員が介入する、コードを少し変えて残り試行が最も減るキーワードをヒント生成に使う、など。

数式・アルゴリズム

最適化の提案というより運用設計と適用が中身。要点を記号で：

• 単一ハブ限界：capacity(single hub) ≈ 5,000。これを超えるため users → shard → hubs → shard → clusters。
• コスト表（n1-highmem-16・1GB/user）：稼働率と同時ユーザ・台数・1人当たり週コストの対応は概ね線形。8.75% / 1000人 / 10台 / $0.11、25% / 3000 / 30 / $0.40、50% / 6000 / 60 / $0.83、100% / 12000 / 120 / $1.25。最大見積りで $1.25/人・週（120台、$14k/週＋サポート$1k）、期待見積り（25%稼働）で $0.40/人・週。2018年4月実績は週次アクティブ約6,970人・計算費 ≈ $2.8k/週 → $0.40/アクティブ学習者・週で見積りと一致。
• DKT：各コード提出を v ∈ R^K（K=語彙、tf-idf）に featurize。スキル s 毎に LSTM f_s を学習し、時刻 t で「同一スキル各問の残り試行回数ベクトル」を予測。試行数のばらつきは最大試行数へ padding（任意の上限、例 100 試行で truncate）。

実験・結果

• 教育用途で JupyterHub を初めて10万ユーザ規模に対応させた基盤を実証。Data 8.1X は登録45,000超・週次アクティブ6,500〜8,000で初回開講を完走。
• 利用解析：pod の起動/停止をハッシュ化ユーザ ID で集計し、時間毎のアクティブ pod を可視化。Data 8 では水〜金のラボ集中で週次スパイク、Project 1 締切直前には最大約900人が同時利用。クラスタ合計では launch 後に同時1000人超を観測。
• コスト一致：期待見積り $0.40/人・週が実績で裏付けられ、キャパシティ計画の妥当性を確認。
• DKT 予備結果：モック データでは、自由記述コードを入れた DKT がベースライン DKT より誤差を有意に低減（本実験は IRB 承認待ちとして将来作業）。
• 主成果は単一システムの性能数値より、「教室から MOOC へ DS 教育をスケールさせる設計図と運用知見」の共有。

関連研究との関係（メモ）

• sarajlic（sarajlic2018scaling）/ zonca（zonca2018deploying）：同時期の「JupyterHub on Kubernetes でスケール」系。あちらは研究／ワークショップ、本報告は全学規模の正規授業＋10万人 MOOCという規模・継続性の違い。シャーディング戦略・NFS・proxy 多段といった作り込みが具体的。
• stubbs（TACC）（stubbs2020integrating）/ blankburian（blankburian2021onpremises）：本番 JupyterHub の大規模運用知見という点で同系。本報告は教育法・自動採点・学習アナリティクスまで統合するのが独自。
• corc（munk2021corc）：大学教育プラットフォームを支える JupyterHub という共通文脈。corc はクラウド バーストで GPU を補う方向で、本報告のオンプレ／学内 K8s ＋ idle culler 運用と対比できる。
• idle culler（jupyter2026idleculler）：本報告の「非アクティブ pod を culler が削除」は、まさにアイドル セッションの資源回収。アイドル時の効率という自分の関心の典型シナリオ。

Q&A

（自分がAIに実際に質問したことだけを Q/A 形式で残す。まだなし。）

自分のコメント

（ここは自分で都度書く欄。例：「1学生=1 pod を常時確保」＋「idle culler で回収」という構成は、アイドル資源の無駄とオーバーサブスクライブ（NotebookOS 的）が効く典型。シャーディングを load balancing に変えると相関一斉起動の混雑をどう捌くか、という論点も自分の資源スケジューリングに通じる。）