カリフォルニア大学バークレー校、米国の高等教育機関における最大規模の JupyterHub デプロイメントを Filestore で強化

※この投稿は米国時間 2024 年 7 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

複雑なプロジェクトに共同で取り組む研究者、学生、開発者の間では JupyterHub がコラボラティブ データ サイエンスに欠かせないツールとなっており、ユーザー グループが Jupyter Notebooks の力を活用するのを可能にしています。JupyterHub は、複数ユーザー環境を管理し、共有リソースへのアクセスを提供する機能により、データ サイエンスを大規模に実践する方法に革命をもたらしています。

しかし、大規模な JupyterHub デプロイメントに取り組んだことがある方なら誰もがわかるように、こうした利点はいくつかの課題を伴います。デプロイメントが拡大するにつれて、多種多様なユーザーやコンピューティング負荷の高いタスク用のファイル ストレージが管理しづらくなり、すぐに重大な問題に転じます。信頼性が高く、スケーラブルでパフォーマンスの高いストレージ ソリューションの必要性が、スムーズな運用と効率的なワークフローを確保するための鍵となります。

カリフォルニア大学バークレー校は、学生、講師、教職員、スタッフ、研究者のためのコラボラティブ データ サイエンス環境として JupyterHub を利用しており、それは米国の高等教育機関における最大規模のデプロイメントとなっています。同校のデプロイメントである Datahub は、高度にカスタマイズされた Zero to JupyterHub デプロイメントです。15,000 人のユーザーを抱え、100 以上のコースと 35 以上の学科にまたがる 15 を超えるハブを備えています。もちろん、課題やプロジェクトには期限があり、小テストや試験は学内の予定に縛られているため、稼働時間と可用性が最重要になります。

Google とカリフォルニア大学バークレー校が話し合いを始めた当初、同校は極めて率直に意見交換をしてくれました。特に、限られたリソースでこれほど大規模かつアクティブなユーザーベースをサポートすることの難しさについて話が及びました。多くの大学と同様に、カリフォルニア大学バークレー校も予算上の制約に直面しており、大規模な IT チームを編成することは困難でした。事実、わずか 2 人のフルタイム スタッフと、熱心なボランティアとパートタイムの協力者で構成される小規模なチームだけで、この大規模な JupyterHub デプロイメントを管理していました。

すぐに明らかになったことは、既存のインフラストラクチャでは安定した対応が困難であるということでした。既存のインフラストラクチャは、セルフマネージドのユーザー ホーム ディレクトリに依存している状況で、そのディレクトリは Google Compute Engine でホストされているセルフマネージドの NFS サービスにマウントされていました。ユーザーベースは拡大を続けており、より統合された信頼性の高いエクスペリエンスが必要でした。それは、パフォーマンスや使いやすさを犠牲にすることなく、増大する需要に対応できるソリューションを見つける必要があることを意味します。また、第一線の研究機関として、学科横断的な指導目標と IT 予算の制限という現実とのバランスを取る必要もありました。

その切り札となったのが、マネージド NFS ストレージ サービスである Google Cloud の Filestore でした。このブログ投稿でカリフォルニア大学バークレー校の Filestore 導入までの道のりを共有することで、同じような課題に直面しているすべての方に向けて貴重なインサイトと実用的なガイダンスを提供できればと考えています。

Filestore を選んだ理由

Knapp 氏が 2022 年 10 月にチームに加わったとき、チームはほとんど常に危機的な状況にありました。学期の途中で新しい Datahub ユーザーが流入したことにより、既存の GKE アーキテクチャが限界に達しました。さらに悪いことに、負荷によってセルフマネージドの NFS サービスが頻繁にクラッシュしていました。

チームはセットアップを再構築して、特定のコースハブと JupyterHub サポート インフラストラクチャを独自のノードプールに分離するという措置を講じることで、GKE のパフォーマンスの問題に対処しました。これによりユーザーのパフォーマンスは向上しましたが、根本的なストレージの問題は解決されませんでした。セルフマネージドの NFS サービスは重大な障害点となっていました。稼働を継続するために、チームは応急処置として、NFS サービスを 15 分ごとに自動的に再起動する systemd タイマーを導入しました。

これにより完全な停止は回避できましたが、セルフマネージド インフラストラクチャは依然として対応しきれていませんでした。それと同時に、ユーザーベースは急速に拡大を続け、ワークロードの要求もますます厳しくなるなかで、サーバーとストレージの継続的な増強のニーズに対応する予算が単純に不足していました。より効率的で費用対効果の高いソリューションをチームは必要としていました。

そこでチームは Google Cloud に連絡し、Filestore の担当者と話し合いました。Filestore が適切なソリューションであると確信するまでに 1 時間もかかりませんでした。チームが特に興味を持ったのは、インスタンスのサイズを柔軟に設定でき、予算に合った料金設定が可能な Filestore 基本 HDD ティアでした。

カリフォルニア大学バークレー校の移行について詳しく説明する前に、Filestore には 基本、Zonal、リージョンの 3 つのティアがあり、どれを選択するかは必ずしも簡単ではないことを述べておきます。基本インスタンスは安定したパフォーマンスを提供しますが、容量管理の制限があります（容量をスケールダウンすることはできません）。Zonal インスタンスは、レイテンシの影響を受けやすいデータ サイエンス指導ワークロードに最適な非常に高速のパフォーマンスを提供します。ただし名前が示すとおり、リージョン内の 1 つのゾーンに関連付けられます。そのゾーンで障害が発生すると、ワークロードが影響を受ける可能性があります。一方、リージョン インスタンスは、リージョン内の 3 つのゾーン間でデータを同期的に複製するため、1 つのゾーンがダウンしてもデータは保護されます。3 つのティア間のトレードオフは、パフォーマンス、費用、ストレージ管理の柔軟性、ストレージ SLA です。3 つのどれを選択するかを決める際には、パフォーマンスとダウンタイムの許容度について検討する必要があります。もちろん、予算と容量の要件も意思決定に大きな役割を果たします。

DIY NFS から Filestore への移行

Filestore について十分に理解したうえで、Knapp 氏率いるチームはそれをテストすることに注力しました。デモのデプロイメントをスピンアップし、Filestore インスタンスを比較的小規模な JupyterHub 環境に接続しました。実践派のテクニカル リードである Knapp 氏はすぐに作業に取り掛かり、システムを実際にテストするために、単一ユーザー サーバー ノートブック Pod から bonnie++ ベンチマークをいくつか実行しました。

カリフォルニア大学バークレー校の Filestore Volume を使用した nfsPVC デプロイメント用の YAML ファイル。完全な YAML ファイルについては、こちらの GitHub リンクを参照のこと

Filestore Persistent Volume Claim の作成

結果は素晴らしいものでした。Knapp 氏が意図的にテスト インスタンスの限界を押し上げたにもかかわらず、ハブ上の他のユーザーには目立った影響はありませんでした。ノートブックを開いて実行したり、データセットをダウンロードしたり、中断することなく全般的に作業したりすることができました。これは、厳しい条件の下でも、ワークロードを分離して一貫したパフォーマンスを確保する Filestore の能力を証明するものでした。

これによりカリフォルニア大学バークレー校は、より大規模なデプロイメントを運用していく自信を得ました。チームは、Filestore の読み取り / 書き込み / レイテンシのパフォーマンスに特に感銘を受けました。それらは期待以上のものでした。基本ティアではストレージ容量のスケールダウンはサポートされていませんが、リージョン ティアと Zonal ティアではストレージ容量のスケールダウンがサポートされています。しかし、費用とストレージ容量を考慮すると、後者の 2 つはチームのニーズに適していませんでした。

Filestore 基本ティアの導入を決定した後、Knapp 氏率いるチームは迅速に行動する必要がありました。その期限は厳しく、2023 年春学期の開始まで残り数週間しかありませんでした。これは、Filestore をストレージ ニーズの基盤として、GKE に JupyterHub 環境を完全に再デプロイすることを意味しました。慎重な計画と効率的な実行が不可欠でした。

Knapp 氏率いるチームは、いくつかの重要な意思決定を行う必要がありました。1 つ目は、Filestore デプロイメントの構成方法です。複数のハブに共有インスタンスを作成するのか、一つひとつのハブに専用のインスタンスを割り当てるのかを決めなければなりませんでした。

Datahub の規模と稼働時間の重要性を考慮して、チームは慎重を期すことにしました。この意思決定は間違いなく、ストレージ関連の障害に関する過去の経験に影響されています。チームは、Filestore インスタンスと JupyterHub デプロイメントの比率を 1 対 1 にし、実質的にオーバープロビジョニングして、パフォーマンスと信頼性を最大化しました。費用がかさむのはわかっていましたが、ストレージの使用状況を綿密にモニタリングし、2023 年春学期後に使用率の低いハブを共有インスタンスに統合する計画でした。

次の課題は、各 Filestore インスタンスの適切なサイズを決定することでした。過去のデータがないため、なんらかの知識に基づいた推測に頼るしかありませんでした。Datahub は柔軟性を重視して設計されているため、ユーザーの保存容量の上限を簡単に設定することはできません。これは、JupyterHub デプロイメントでよくある課題です。

チームは既存のデータに着目することにし、Cloud Storage にアーカイブされていたユーザーデータから前学期の使用パターンを確認しました。ざっと計算した結果、1 TB から 12 TB までのインスタンス サイズの範囲に落ち着きました。ここでも、将来的な成長に対応できるようにオーバープロビジョニングを考慮しました。

秋学期が終了し、ユーザーデータがアーカイブされると、実際の作業が始まりました。Filestore インスタンスを作成し、必要な構成（NFS エクスポートや ROOT_SQUASH オプションなど）を適用し、費用を効果的に追跡できるよう GKE ラベルも追加しました。費用の最適化も重要な課題です。

データが配置され、最終的な切り替えのタイミングが来ました。チームは新しい Filestore インスタンスを指すように JupyterHub の構成を更新し、古い NFS セットアップの残りを削除して、期待と安堵の入り混じった気持ちで Datahub を再起動しました。

Filestore の管理

Filestore に移行してから、カリフォルニア大学バークレー校の Knapp 氏率いるチームは、これまで考えられなかった水準の安定性とパフォーマンスを享受しています。チームの言葉を借りれば、Filestore はチームにとって「導入したら忘れる」サービスになったのです。ダウンタイムは 1 分たりとも発生しておらず、Datahub を利用する何千人もの学生のユーザーからもパフォーマンスの問題は報告されていません。

同時に、管理オーバーヘッドも大幅に削減されました。既存の PagerDuty システムと統合されたいくつかのシンプルな Google Cloud アラートを設定し、Filestore インスタンスの容量が 90% に達した時点で通知が送られるようにしました。ただし、こうしたアラートはめったに発生しません。必要に応じて簡単にストレージをスケールアップできるからです。

使用状況をさらに最適化し、費用を管理できるように、チームはシンプルかつ効果的な戦略を実装しました。各学期の終わりに、ユーザーデータを Cloud Storage にアーカイブし、使用パターンに基づいて Filestore インスタンスのサイズを適正なものに調整します。より小さなインスタンスを作成するか、ハブを共有インスタンスに統合して、必要なストレージに対してのみ料金を支払うようにします。Rsync は、インスタンス間でデータを移行するための頼りになる相棒であり続けています。このプロセスは時間がかかりますが、ワークフローの日常的な一部になっています。

良かったこと、課題、（時に）予測不能な出来事 - Knapp 氏の場合

カリフォルニア大学バークレー校の Filestore への道のりを振り返り、Knapp 氏は包み隠さず本音を話してくれました。すべてが順調だったわけではなく、チームは多くのことを学びました。透明性の精神に則って、Knapp 氏自身の言葉で、良かったこと、課題、そして（時に）予測不能な出来事に分けて、その体験を詳しくご紹介します。

良かったこと

心の平穏に勝るものはありません。特に各学期の最中は、それが必要です。Filestore への移行は画期的な出来事でした。デバッグ作業に追われていた深夜の時間帯にぐっすりと眠れるようになりました。サーバーのクラッシュや試験の予定変更があっても、慌てて電話する必要はもうありません。Filestore の稼働率は極めて安定しており、基本ティアのパフォーマンスでユーザーの需要に十分対応できます。

Filestore をさらに深く調査していくうちに、カリフォルニア大学バークレー校による運用を改善することでセットアップを最適化する方法がさらに見つかりました。

共有は思いやり（費用対効果も抜群！）: ストレージ要件の小さいハブを共有インスタンスに統合して、費用をさらに節約する複数の機会が見つかりました。

適正なサイズ設定が鍵: 私たちは必要な場合にのみ積極的にサイズを調整し、ストレージを追加するプロになりました。

• Filestore Multishare CSI ドライバの調査: ストレージ容量をスケールアップ / スケールダウンする機能と潜在的な費用差を合理化するために、Filestore Multishare 機能を積極的に検討しています。これにより、現在の Filestore デプロイメントと比較してさらに時間と労力を節約できる可能性がありますが、現在は基本 HDD ティアを使用しているため、これは望めません。

教職員の支援: 私たちは教職員や講師と緊密に連携して、データ マネジメントのベスト プラクティスを学生に教えられるよう支援しています。また、数メガバイト（テラバイトではなく）のデータをダウンロードするだけで非常に大きな効果が得られるということも伝えています。

よりスマートなアーカイブ: アーカイブ プロセスを最適化するために、ストレージ指標と使用状況を継続的に分析しています。目標は、必要なときに必要なものだけをアーカイブすることです。

課題

欠点がないわけではありません。Filestore は予算に優しい選択肢ではありません。クラウド ストレージの費用は増加しました。最適化の取り組みによって費用の増加をいくらか緩和できたとはいえ、料金が高いことは否定できません。しかし、チーム全体の健全性のことを考えると、クラウド費用の増加は十分価値に見合っています。

私たちが依然として苦労している点の一つは、Filestore 基本ティアでは簡単にスケールダウンできないことです。技術的に難しいというわけではありませんが、手動でインスタンスのサイズを調整すると時間がかかり、ユーザーに迷惑をかける可能性があります。これは当然避けたいところです。ストレージのニーズを予測する私たちの能力も向上しており、私たちが作成したヒント集、とりわけ適正なサイズ設定に関するヒント集は大きな違いをもたらしています。しかし、需要に応じてスケールダウンできる、より合理化された方法があれば、私たちにとって大きなメリットとなるでしょう。そうすれば、毎月数千ドルを節約でき、その資金を学生や教職員のための他の重要なリソースに振り向けることができます。

予測不能な出来事

データ サイエンスはその性質上、大量のデータを必要とします。現在直面している最大の課題の一つは、特定の時点でユーザーが必要とするストレージの量を予測することです。さまざまなプロジェクトに取り組んでいる何千人もの学生がいますが、そうしたプロジェクトには膨大なデータセットが関わることがあります。Filestore インスタンスが数時間でテラバイト単位で増大することも珍しくありません。

この予測不可能な需要に対して常にバランスを取る必要が生じます。SRE チームが大量のアラートに悩まされることがないようにしたい一方で、必要のないストレージに過剰な出費をしたくないとも考えています。これは微妙なバランスであり、私たちはしばしば慎重な姿勢をとります。短期的には費用が高くなるとしても、ユーザーに必要なリソースが確実に提供されるようにするためです。

現在、Filestore は私たちのクラウド支出全体の約 3 分の 1 を占めています。そのため、Filestore の有効活用に注力する一方で、使用率を最適化し、パフォーマンス、信頼性、費用のバランスを取ることができる方法を常に模索しています。

まとめ

カリフォルニア大学バークレー校の取り組みは、教育の強化手段として大規模な教育プラットフォームを導入するすべての人に関わる重要な教訓を浮き彫りにしています。それは、JupyterHub デプロイメントの数が増え、複雑さと規模が増すにつれて、サポート対象のインフラストラクチャに対する要求も増えるということです。成功を収めるには、技術的に優れているだけでなく、経済的にも持続可能なソリューションを見つけることが必要です。Filestore は料金が高い、Filestore 基本ティアの習得に多少時間がかかる、自動化ツールが不足しているなどの課題はありますが、Datahub にとって、パフォーマンス、信頼性、運用効率の魅力的な組み合わせを提供し、次世代のデータ サイエンティスト、統計学者、計算生物学者、天文学者、イノベーターに力を与えるソリューションであることが証明されました。

JupyterHub デプロイメントを改善したいとお考えですか？Filestore と GKE の詳細については、こちらをご覧ください。

ー ストレージ担当グループ プロダクト マネージャー Sean Derrington

ー カリフォルニア大学バークレー校、UC Berkeley Datahub 担当テクニカル リード Shane Knapp 氏