GPU学習クラスタの大規模メトリクス監視はどうする？Adobe FireflyのAmazon Managed Prometheus移行記

はじめに: GPU学習インフラ監視の難しさ

生成AIモデルを学習させるGPUインフラは、従来のCPUベースのアプリケーション監視とは比較にならないほど複雑なテレメトリを生成します。単純にCPU使用率だけを見ていればよかった時代とは異なり、GPU学習ジョブはコンピューティング、メモリ、ネットワークレイヤー間の相互作用を立体的に観察しなければ、ボトルネックを正確に特定することができないからです。

例えば、2,000ノード、16,000基のGPUで学習を実行するシナリオを考えてみましょう。30秒間隔でメトリクスを収集すると、単一のクエリウィンドウだけで数十億のデータポイントが生成される可能性があります。このような環境で「なぜGPUが50%しか使われていないのか」「特定ノードのメモリ使用量がなぜ急増したのか」という問いに答えるには、高カーディナリティ(High-Cardinality)なメトリクスを高速にクエリできる可観測性システムが不可欠です。

Adobe Fireflyチームも同様の課題を抱えていました。Fireflyは、PhotoshopやIllustratorなどAdobeの中核製品群のクリエイティブな機能を支える生成AIモデルです。このモデルを学習させるために、AdobeはAmazon EKSベースのGPU学習インフラを運用しており、初期段階ではセルフホスト型Prometheusを使用していました。しかし、Fireflyの採用が拡大し、学習ジョブの規模が大きくなるにつれて、既存の監視システムの限界が顕著になりました。

この記事では、Adobe Fireflyチームがセルフマネージド型PrometheusからAmazon Managed Service for Prometheusへ移行したプロセスと、それによって得られた具体的な成果(クエリ性能の最大28.8倍向上)を分析します。単なるサービス移行の事例ではなく、大規模GPUインフラで可観測性アーキテクチャを設計する際に考慮すべき重要な要素とは何かについても考察します。

問題の本質: セルフホスト型Prometheusのスケーラビリティ限界

Adobe Fireflyチームが直面した問題は、単に「メトリクスが多い」ということではありませんでした。問題の本質は、GPU学習ジョブの特性上、高カーディナリティなメトリクスが発生し、それを既存のアーキテクチャでは高速にクエリできなかったという点にあります。

セルフホスト型Prometheusは、収集、保存、クエリという3つの役割をすべて自前で実行する必要がありました。メトリクスのボリュームが増加するにつれて、クエリのパフォーマンスは急激に低下し、特に長期間(例: 12時間、24時間)のデータを参照する際に問題が顕著になりました。60秒以内に完了すべきクエリがタイムアウトしたり、2分かかっても部分的な結果しか返ってこないといった状況が発生したのです。

この問題を解決するために、AdobeチームはAmazon Managed Service for Prometheusを導入しました。フルマネージド型サービスであるため、スケーラビリティと可用性の問題をAWSに委任でき、既存のセルフホスト型Prometheusを置き換えるのではなく、**段階的に移行(Incremental Migration)**できるという点が重要な戦略でした。

移行戦略: 段階的導入 (Incremental Adoption)

Adobeチームの移行方法は非常に現実的で実用的です。監視システム全体を一度に置き換えるのではなく、**Amazon Managed Prometheus Collector(マネージドスクレイパー)**を導入し、Amazon EKSベースの学習クラスターからのメトリクス収集を担当させました。既存のセルフホスト型Prometheusは維持しつつ、Amazon Managed Prometheusに送信する重要なメトリクスのみを選別して二重に収集する方式です。

# Amazon Managed Prometheusへメトリクスを送信するためのRemote Write設定例
# この設定は既存のPrometheusサーバーに追加し、特定のメトリクスのみをフィルタリングして送信できます。
remote_write:
  - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-xxxxxxxx/api/v1/remote_write
    # AWSシグネチャ認証のための設定 (例: sigv4)
    sigv4:
      region: us-east-1
    # 送信するメトリクスを選択するクエリ (例: GPU関連メトリクスのみを選択)
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'DCGM_FI_DEV_GPU_UTIL|DCGM_FI_DEV_MEM_COPY_UTIL|container_gpu_usage_seconds_total'
        action: keep

このようにすることで、既存のワークフローを中断することなく、最も重要なメトリクスをAmazon Managed Prometheusのスケーラブルなインフラで管理できます。これは、**「ビッグバン移行」よりも「ストラングラーパターン(Strangler Pattern)」**が大規模なインフラ変更においていかに効果的であるかを示す好例です。

移行効果: 数値で証明されたパフォーマンス向上

Adobe Fireflyチームが発表した結果は、Amazon Managed Prometheus導入の効果を数値で明確に示しています。GPU使用率メトリクスを基準に、クエリ時間範囲(Time Range)ごとのパフォーマンスを比較した結果は次の通りです。

最も劇的な変化は24時間ウィンドウで見られました。 以前は60秒のタイムアウトが発生したり、2分かかっても部分的な結果しか返されなかったクエリが、移行後は約10秒で完了します。これは単に「速い」ということを超え、運用方法そのものを変えるイノベーションです。

運用観点での変化

クエリパフォーマンスの向上は、単にダッシュボードが速くなるという以上の意味を持ちます。Adobeチームはこれにより、**学習ジョブの可観測性ウィンドウ(Observability Window)**を、以前の6時間の限界から24時間へと拡張することができました。

これは、256ノード以上を使用する大規模な長期学習ジョブにおいて特に重要です。エンジニアはジョブの全ライフサイクルを一目で把握でき、パフォーマンスが低下した時点を正確に特定し、インフライベントとの相関関係を分析できます。例えば、特定の時点でGPUメモリ使用量が急増した場合、その時点で他のジョブが開始されたのか、ネットワーク遅延が発生したのかなどを併せて追跡し、問題の根本原因を迅速に特定できます。

まとめと示唆: 可観測性の未来のための設計原則

Adobe Fireflyの事例は、単に「AWSサービスが優れている」ということを超え、大規模GPUインフラを運用する開発者やアーキテクトにとって重要な教訓を提供します。

1. スケーラビリティは選択ではなく必須です。 GPUクラスターの規模が大きくなると、メトリクスのカーディナリティとボリュームは制御不能なレベルまで増加します。最初からスケールを考慮した設計が必要です。
2. 段階的な移行が成功の鍵です。 一度にすべてを変更することはリスクが伴います。Adobeの事例のように、重要なメトリクスから始めて段階的に移行する戦略が実務ではるかに効果的です。
3. パフォーマンス向上は運用方法を変えます。 クエリパフォーマンスが28倍向上したことで、以前は不可能だった24時間全体のデータ分析が可能になりました。これは、障害対応、パフォーマンス最適化など、運用プロセス全体の革新につながります。

日本の開発現場での適用文脈

日本国内でも、大規模なGPUクラスターを運用する企業が増えています。特に、LLM(大規模言語モデル)の学習やヘルスケアAI、自動運転など、ハイパフォーマンスコンピューティングが必要な分野で同様の課題を抱えていることでしょう。今回の事例は、「可観測性」インフラを設計する際に、自社構築よりもクラウドのマネージドサービスを優先的に検討することが、長期的には運用負担を軽減する近道であることを示しています。オンプレミス環境が中心の日本企業では、レガシーシステムとの互換性の問題で移行が難しい場合もありますが、Adobeのように重要なメトリクスから段階的に適用する方法をお勧めします。

この技術の限界または注意点

Amazon Managed Prometheusは、費用が発生する有料サービスです。コストは収集(Ingested)、保存(Stored)、クエリ(Queried)されるメトリクスの量に基づいて決定されます。したがって、むやみにすべてのメトリクスを送信するのではなく、Adobeが行ったように重要なメトリクスを選別し、ラベルを最適化してカーディナリティを下げる努力が必要です。また、Amazon Managed Grafanaも別途費用が発生するため、予算を考慮した設計が必要です。詳細は、Amazon Managed Service for PrometheusのドキュメントとAmazon Managed Grafanaのドキュメントを参照してください。

次のステップの学習方向性

この記事の内容を基に、より深く学びたい場合は、次のトピックをお勧めします。

• メトリクスのカーディナリティ最適化: Prometheusのカーディナリティがなぜ問題になるのか、それを減らすためのリラベリング戦略を学んでみてください。
• GPUメトリクス収集ツール: NVIDIA DCGM(Data Center GPU Manager)を活用した詳細なGPUヘルスチェック方法を習得しましょう。
• マルチテナント可観測性: Adobeが次の段階として進めているマルチテナント対応の可観測性アーキテクチャを設計する方法を考えてみましょう。

合わせて読みたい記事

• ゲーム内AIエージェントの推論コスト削減: NVIDIA IGI SDKコードエージェント実践ガイド
• NVIDIA Vera CPU: エージェンティックAI時代の新たなCPU標準を提示