ハブを200万モデルで支える：Hugging Faceのスケール戦略

ハブを200万モデルで支える：Hugging Face のスケール戦略とインフラ再設計

1400 万人のユーザー、300 万もの公開モデル、そして 100 万のデータセット。世界最大級のオープンソース AI プラットフォーム「Hugging Face」は、過去数年で急激な成長を遂げました。しかし、この爆発的な拡大は単なる数字の上昇ではなく、既存のインフラでは耐えられないほどの負荷を生み出しました。本記事では、同社のデータベースエンジニアである Ar Borutki 氏が語る、検索パフォーマンスの維持とコスト効率を保ちながらスケールするための具体的な技術戦略を解説します。

メタデータとアートの分離：独立したスケーリングの鍵

Hugging Face のアーキテクチャで最も重要かつ意外な決断の一つが、「メタデータ」と「モデルファイル」の完全な分離です。多くの人が MongoDB にすべてのデータを保存していると思いがちですが、実際には役割が明確に分かれています。

MongoDB には、モデル名、ユーザー情報、リポジトリ設定、アクセス制御、課金データなどのメタデータのみが格納されます。一方、実際のモデルファイル（アーティファクト）、トークナイザー、設定ファイルなどは、AWS S3 のようなオブジェクトストレージに保存されています。

「この分離により、メタデータの処理とバイナリストレージの管理を独立してスケーリングできるようになりました。」

これにより、検索やリスト表示が重くなることを恐れずにストレージ容量を増やしたり、逆にメタデータへのアクセス負荷が高まっても計算リソースを最適化したりすることが可能になります。それぞれのコンポーネントをワークロードに合わせた形で個別にチューニングできる点が、大規模運用の成功要因です。

検索パフォーマンスの転換点：正規表現から Lucene へ

モデル数が 2 万個だった頃なら、正規表現（regex）を使った検索でも問題ありませんでした。しかし、300 万モデルに達した現在、同じアプローチでは P99 レイテンシ（上位 1% の遅いクエリ）が許容できないレベルまで悪化します。

「ユーザーは即座の結果を期待しています。1400 万人のユーザーのうち 1% でも検索が遅ければ、それは 14 万人の離脱につながります。」

この課題解決のために導入されたのが、Apache Lucene ベースのAtlas Searchです。同社は「クエリ実行時にトークン化する」従来の手法を捨て、「インサート（登録）時に事前計算する」アプローチを採用しました。

例えば、「meta-llama/Llama-3.1-8b」というモデル名が登録された際、システムはこれを自動的に「meta」「llama」「3.1」「8b」といったトークンの配列に分解し、検索用コレクションに保存します。ユーザーが検索バーで「llama」と入力すると、この事前計算されたインデックスを参照して瞬時に結果を返すことができます。

また、検索対象はメインのレポジトリコレクションではなく、読み取りとリスト表示に特化した非正規化された読み取りコレクション（denormalized read collection）です。これにより、主要な書き込み処理への影響を最小限に抑えつつ、高速な検索を実現しています。

MongoDB クラスター構成：負荷分散の巧みな工夫

Hugging Face は 7 ノードからなる MongoDB クラスターを運用していますが、単にノードを増やすだけでなく、役割分担を厳格に行っています。

1. プライマリノード: 書き込み（挿入、削除、更新）はすべて集中させます。これによりデータの整合性を保ちつつ、単一の書き込みポイントとして最適化しています。
2. セカンダリノード: 読み取りクエリや集計処理を分散します。最新のデータが必須でないクエリや、大量データをスキャンする複雑なアグリゲーションパイプラインは、すべてセカンダリへ転送されます。
3. ヒドゥンノード（隠しノード）: 分析用やレポート作成のために用意された、アプリケーションからは見えないノードです。生産トラフィックから完全に隔離されており、重いクエリや実験的なクエリをここで処理します。

「プライマリは書き込みだけに集中させ、それ以外のすべてを他のマシンに押し出すというシンプルなパターンが機能しています。」

この構成により、単一ノードのボトルネックを防ぎながら、データの整合性を損なうことなく高負荷なクエリも処理可能になっています。

Kubernetes 上の二層スケーリング戦略

アプリケーションレベルとインフラレベルを分けた「二層構造」のスケーリングが、Hugging Face のコスト効率を支えています。

第一層：デプロイメントレベル（HPA）

Kubernetes の標準機能である Horizontal Pod Autoscaler (HPA) が、CPU やメモリの使用率に基づいてポッド数を自動調整します。トラフィックの急増時には最大 500 ポッドまでスケールアップし、低下すれば縮小します。

第二層：インフラレベル（Cast AI）

HPA が新しいポッドを起動しようとしても、Kubernetes クラスターに空きノードがない場合、スケールは止まってしまいます。そこで登場するのがCast AIです。ポッドがPending（待機中）になった瞬間を検知し、自動的に新しいノードを追加してスケジューリングを可能にします。

「HPA でリソース不足時の自動スケールを実現し、Cast AI でコスト最適化とインフラの柔軟性を両立させています。」

将来的には、CPU やメモリといったリソース指標だけでなく、「1 秒あたりのリクエスト数」や「イベントループの利用状況」といったアプリケーションメトリクスに基づいてスケーリングする KEDA (Kubernetes Event-driven Autoscaler) への移行も計画されています。これにより、リソース使用率が低くても負荷が高いケースをより正確に検知し、無駄なスケールアップを防ぐことが期待されます。

将来の展望：シャーディングとさらに大きなスケールへ

現在のアーキテクチャは強力ですが、1400 万人ユーザーと 300 万モデルという規模において、単一のレプリカセットには限界が近づいています。今後の戦略として、シャーディング（データ分割）の実装が挙げられています。

シャーディングでは、データを複数のシャードに分割し、それぞれを独立したレプリカセットとして運用します。これにより、CPU、メモリ、ストレージ、読み書きのすべてを水平方向に拡張可能になります。シャードキーの選定は重要な課題ですが、このアプローチを採用することで、将来的なさらなるデータ量の増加にも対応できる基盤が整いつつあります。

まとめ

Hugging Face のスケール戦略は、単なる技術の導入ではなく、「メタデータとストレージの分離」「検索インデックスの事前計算」「役割分担されたクラスター構成」「二層スケーリング」といった、大規模システムにおける本質的な課題に対する体系的な解決策です。生成 AI エコシステムの基盤として成長する同社の取り組みは、今後さらに規模を拡大するプラットフォーム運営者にとって、極めて重要な参考事例となるでしょう。