Hugging Face 本番インフラストラクチャ アラート戦略

Hugging Face 本番インフラストラクチャ アラート戦略

Hugging Face は、本番インフラストラクチャの安定性とスケーラビリティを確保するために、堅牢な監視およびアラートシステムを導入しています。ネットワークトラフィック、ログパイプライン、オーケストレーション API のヘルスに対するターゲット型アラートを実装することで、チームは潜在的な問題を大規模なインシデントにエスカレートする前に特定できます。

高 NAT ゲートウェイスループットとコスト最適化

Hugging Face は、プライベートネットワークからパブリックインターネットへのアウトバウンドトラフィックを集中させるために NAT（Network Address Translation）ゲートウェイを使用し、セキュリティとコスト分析のための戦略的な視点を提供しています。クラウド費用を管理するために、チームはスループットが事前に定義された上限を超えたときに発動する静的閾値アラートを用いてネットワークトラフィック量を監視しています。

このアラート機構は主に二つの機能を果たします：

  • Early Warning System: 異常なトラフィックスパイクを検出し、予期しないシステム動作を示す可能性があります。
  • Infrastructure Review: インフラストラクチャの成長を変化するニーズに合わせるため、トラフィックトレンドの定期的なレビューを促します。

実際には、サードパーティのセキュリティおよびオートスケーリングツールがテレメトリーデータの送出量を増加させた際に、チームはこのアラートを活用して構成を最適化しました。また、トラフィックが誤って低コストのプライベートパスを回避しているケースも特定します。例えば、LFS リポジトリストレージからオブジェクトを直接取得する方が、CDN 配信資産を使用するよりもコスト効果が高いです。このような問題を解決するため、Hugging Face は CDKTF AWS プロバイダーを介した DNS オーバーライドを利用し、トラフィックをプライベートネットワークパスへルーティングしています。

エンドツーエンド ログアーカイブ検証

Hugging Face は、Hub モデルの使用データを取得するために高度なロギングパイプラインを活用しています。パイプラインは Filebeat（ログ収集）から Logstash（変換と強化）へ、次に Elasticsearch（保存と分析）へ、最終的に AWS object storage（Parquet 形式での長期アーカイブ）へと流れ、Amazon Athena を介してクエリが可能です。

設計上は堅牢ですが、パイプラインは以下のような障害に対し脆弱です：

  • Elasticsearch Backpressure: 高いインバウンドや集中的なクエリにより、ログの拒否や遅延が発生する可能性があります。
  • Schema Mismatches: アプリケーションログフィールドの型が大幅に変更されると、オートスキーマ検出が失敗し、書き込みエラーが発生します。
  • Memory Exhaustion: Logstash と Filebeat のメモリリソースが限られているため、バックプレッシャーが発生した際に Out-of-Memory（OOM）クラッシュが起こることがあります。
  • Archival Failures: リソース集中的なアーカイブジョブは、ノードの容量制限や異常に大きなログエントリにより失敗することがあります。

これらのリスクを軽減するため、Hugging Face は Application Load Balancer (ALB) が受信したリクエスト数と、正常にアーカイブされたログ数を比較 するアラートを実装しました。この比率により、システムに流入するデータ量とアーカイブされたデータ量が一致していることが保証され、インフラのリファクタリングやアーカイブジョブの失敗時にログロスを検出できます。

Kubernetes API のヘルスとレートリミット

Kubernetes API はコンテナ管理の中心的なオーケストレーションポイントであるため、Hugging Face は API エラー率とレートリミット指標を監視し、連鎖的な障害を防止しています。インフラは kube-rs ライブラリに大きく依存しており、リフレクタ、コントローラ、ウォッチャ、ファイナライザの Rust ベース抽象化を提供します。

Hugging Face における kube-rs の主な活用例は次のとおりです：

  • Automated Certificate Management: kube::api:: モジュールを使用して、Spaces 製品のカスタムドメイン向け HTTPS 証明書を管理します。
  • Custom Controllers: kube::runtime:: モジュールを使用して課金管理用のコントローラを構築し、ウォッチャとファイナライザで顧客ポッドを追跡し、正確なリソース課金を実現します。
  • Maintenance Operations: インフラ更新時のノードドレインや終了を支援します。

Kubernetes API の監視は重要です。障害が発生すると顧客ポッドやクラウドネットワークリソースの管理に影響を及ぼす可能性があります。例えば、チームはこれらのアラートを利用して、サードパーティツールのバグによりノードのドレイン要求が繰り返し行われ、ユーザー体験が低下する前に API のレートリミットが発動したケースを特定しました。

サイレント クラスターメトリック障害の検出

クラスターが頻繁に作成・削除される動的環境を管理するため、Hugging Face は特定の Prometheus クエリを使用して、中央の Grafana Mimir ストアへメトリクスを送信していないクラスターを検出します。

このアラートはローカルの Prometheus インスタンスから取得した container_network_transmit_packets_total メトリックを監視します。クエリは以下の場合に発火します：

  1. 新しいクラスターが追加されたが、まだメトリクスを送信していない。
  2. クラスターが 48 時間以上存在しているが、メトリクスを一度も送信していない。

これは、現在のパケット送信レートを 48 時間前の履歴レートと比較することで実現します。現在と過去のレートがともにゼロの場合にアラートが発火し、メトリクスインフラのクラッシュやクラスター設定時の失敗をチームに通知します。

Sources