なぜストレージがAIの性能を左右するのか

ここ数年、AIモデルの能力と学習データセットの規模は指数関数的に成長しています。特にこの1年ほどで、最先端モデルのリリース間隔は数ヶ月から数週間に短縮されました。こうしたイノベーションの速度に追いつくには、ストレージへの高速で信頼性の高いアクセスが不可欠です。AIを脳に例えるなら、ストレージは記憶に相当し、容量の大きさと検索速度がモデルの性能や学習速度を左右します。

しかし、AIコンピューティング性能が2年ごとに約3倍成長した一方で、ストレージとインターコネクトの性能向上は緩やかでした。その結果、ストレージボトルネックはAIワークロードにおけるGPUストールの主要因となり、コスト増加や市場投入遅延に直結しています。GPU利用率に加えて、ストレージアーキテクチャはAI研究の反復速度にも直接影響します。GPUが地理的に分散し、データセットが大規模化する中、研究者はデータを地域間で転送・取り込むのに多くの時間を費やしています。

本記事では、MetaがBLOBストレージアーキテクチャをどのように進化させ、以下の2つの課題を解決したのかを詳しく解説します。

  • GPU利用率の最大化
  • 研究の反復速度の最大化

この内容はMeta公式エンジニアリングブログに掲載された記事を基に、実務で活用できる洞察を追加して整理しました。

Meta AI storage clusters with GPU servers and high-speed network Coding Session Visual

GPU利用率を高めるための設計変更

なぜレイテンシが重要なのか

モデル学習中、数十万のGPUが膨大なデータを複数回（エポック）繰り返し読み取ります。GPUはバッチ単位でデータを処理し、一定ステップごとに状態を同期します。このとき、1台のGPUでも遅いと全体の学習が遅延します。下図のように、データローディングパイプラインでストレージフェッチの遅延が発生すると、GPUがI/O待ちでストールする現象が発生します。

# データローディングパイプラインの例（概念）
import time
import random

def load_next_batch():
    # ストレージから次のバッチを取得する関数
    # レイテンシが長いとGPUがストールする
    latency = random.uniform(0.001, 0.5)  # 1ms ~ 500ms
    time.sleep(latency)
    return f"batch_data_{latency:.3f}"

# GPU1: レイテンシが短く問題なし
# GPU2: レイテンシが長くストール発生
for step in range(10):
    batch = load_next_batch()
    print(f"Step {step}: {batch}")

従来のBLOBストレージの限界

従来のアーキテクチャは、従来型Webワークロードに最適化されていました。しかし、AIワークロードは以下の特性が異なるため、新しい設計が必要でした。

  • 性能とレイテンシ: AIはミリ秒単位の一貫したレイテンシを要求しますが、従来はメタデータ参照に数百ミリ秒かかることも珍しくありませんでした。
  • 信頼性と耐久性: 従来はデフォルトでグローバルレプリケーションを行っていましたが、AIワークロードではリージョン内の高い可用性がより重要です。
  • コスト効率: HDDベースの設計ではIOPSが不足しフラッシュが必要です。また、ストレージコストよりもGPUコストが圧倒的に大きくなります。
  • 電力効率: GPUデータセンターではスペースよりも電力に制約があり、ストレージの電力消費を最小限に抑える必要があります。

新しい基盤の構築

Metaは以下の主要な設計判断を行いました。

  1. 統合メタデータスキーマ: 複数レイヤーに分散していたメタデータをZippyDBベースの単一フラットスキーマに統合し、O(1)参照を実現。
  2. データプレーンプロキシの廃止: プロキシを廃止し、クライアントSDKがストレージサーバーから直接バイトをストリーミングする方式に変更。電力効率と性能を向上。
  3. リージョナルデプロイ: GPUと同一リージョンにBLOBストレージスタックを配置し、レイテンシを最小化。
# 新アーキテクチャのgetObjectフロー（概念）
def get_object(sdk, bucket, path):
    # 1. メタデータサーバーにread planリクエスト（O(1)参照）
    read_plan = sdk.get_read_plan(bucket, path)
    # 2. SDKに組み込まれたTectonic BlockClientが直接データをストリーミング
    data = sdk.stream_blocks(read_plan)
    return data

スパイクとホットスポットへの対応

AIワークロードでは、チェックポイントロード時に数百GPUが同時にデータを読み取り、スパイクが発生します。これに対処するため、以下の対策を実施。

  • 分散データキャッシュ: GPUホストの空きメモリを活用し、頻繁にアクセスされるデータをキャッシュ（平均80%のヒット率）
  • Readplanメタデータキャッシュ: 頻繁にアクセスされるBLOBのパス-アドレスマッピングを分散メモリストアにキャッシュし、1〜2msの応答を保証

プロトコル最適化

  • Laggards: 遅いストレージノードによるテールレイテンシをヘッジドリードで緩和
  • Egressスパイク: チェックポイント時のトラフィック急増をクライアントSDKの動的並行性制御で緩和

Data ingestion pipeline with tiered caching for AI training IT Technology Image

研究の反復速度を最大化: ティアードキャッシングとプリフェッチ

GPUが地理的に分散する中、研究者はデータをリージョン間で移動させる負担を強いられています。従来はデータスナップショットを対象リージョンにコピーするのに数時間かかり、研究の反復速度を大きく低下させていました。

MetaはOSのページキャッシュの概念を応用し、グローバルBLOBストレージを最終ソースとするティアードキャッシュアーキテクチャを導入しました。

  • L1キャッシュ: GPUホストのメモリ
  • L2キャッシュ: GPUホストのフラッシュ
  • L3キャッシュ: リージョン内の分離されたフラッシュストレージ（TTL/LRUポリシー）
# データローディングパイプラインの例（ティアードキャッシュ適用）
class Dataloader:
    def __init__(self, l1_cache, l2_cache, l3_cache):
        self.l1 = l1_cache
        self.l2 = l2_cache
        self.l3 = l3_cache

    def prefetch(self, path):
        # リモートデータをL3キャッシュにハイドレーション
        self.l3.hydrate(path)

    def load_batch(self, path):
        # L1 -> L2 -> L3の順にキャッシュを確認
        if path in self.l1:
            return self.l1[path]
        if path in self.l2:
            return self.l2[path]
        if path in self.l3:
            return self.l3[path]
        # L3にない場合はグローバルストレージから読み取り
        return self.read_global(path)

このアーキテクチャにより、データ取り込み時間は劇的に短縮されました。従来はリージョン間コピーに数時間かかっていましたが、オンデマンドハイドレーションとプリフェッチにより、数分でデータにアクセスできるようになりました。これは特に、大規模な学習ジョブよりも小規模な反復実験が多い研究環境で大きな利点となります。

日本における適用コンテキスト

日本国内でもAI学習インフラを運用する企業が増えています。特にNTT、富士通、ソニーなどの大手テック企業は独自のGPUクラスターを保有しており、今回のMetaの事例は以下の示唆を与えます。

  • GPU利用率の観点からストレージアーキテクチャを再検討する必要があります。GPUは高価ですが、ストレージボトルネックにより実際の利用率が低下するケースが多く見られます。
  • データ取り込みパイプラインを自動化し、ティアードキャッシングを導入することで、研究者の反復作業時間を大幅に削減できます。
  • 国内クラウド環境ではリージョン間データ転送コストが高いため、データをGPUと同じリージョンに配置する戦略が重要です。

この技術の限界と注意点

  • 初期構築コスト: 統合メタデータスキーマとファットクライアントSDKは初期開発・移行コストが大きい。既存レガシーシステムを運用中の場合は段階的な移行が必要です。
  • キャッシュ一貫性: 分散キャッシュはデータ一貫性の問題を引き起こす可能性があります。特にデータ更新が頻繁なワークロードでは注意が必要です。
  • リージョン制約: L3キャッシュはリージョン内でのみ動作するため、データが複数リージョンにまたがる場合は性能低下が発生する可能性があります。
  • ハードウェア依存性: フラッシュストレージと高速ネットワークが必須であり、インフラコストが増加する可能性があります。

次のステップの学習方向

Global BLOB storage architecture with regional deployment Development Concept Image

まとめ: 実務適用のための提言

Metaの事例は、AI時代においてストレージが単なるデータ保存場所ではなく、GPU利用率と研究生産性を左右する中核インフラであることを示しています。従来の前提が変わったとき、大胆に再設計することが重要であり、特に以下の原則を覚えておくと良いでしょう。

  • メタデータ参照をO(1)に単純化する。
  • データプレーンプロキシを廃止し、クライアントが直接データを読み取るようにする。
  • ティアードキャッシングとプリフェッチにより、リージョン間データ転送コストを削減する。
  • 動的並行性制御により、スパイクとテールレイテンシを緩和する。

これらの設計原則は、ハイパースケーラーだけでなく、AIインフラを運用するすべての組織にとって有用な指針となるでしょう。ストレージボトルネックを解消すれば、GPU投資対効果を最大化し、研究者はデータ移動に時間を浪費せずモデルチューニングに集中できます。

合わせて読みたい記事:

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。