AI推論は異なるルールで動く：エージェント型AIが求めるものにクラウドストレージアーキテクチャは設計されていない

NVIDIAのCEOであるJensen Huang氏は最近、私たちは「AIファクトリー」の時代に入りつつあり、グローバルテック経済の主要な産出物はソフトウェアではなく知能であると宣言しました。彼の言う通りです。しかし、世界がGPUクラスターと兆パラメーターモデルに夢中になっている間、AWS、Azure、Google Cloud環境のさらに下のレイヤーで、大規模で静かな危機が醸成されています。AIエージェントがあなたのデータインフラに押し寄せ、あなたの基盤となるストレージとデータアクセス層を圧倒しようとしています。私たちはAIデータ津波の瀬戸際に立っています。

単純なチャットボットから自律的なマルチステップAIエージェントへの移行は、推論がもはやステートレスな計算問題ではないことを意味します。それは大規模で予測不可能かつ前例のないデータ問題です。人間の速度のアプリケーション用に構築された基盤データインフラは、次に起こることに対して準備ができていません。AIを可愛らしい概念実証からエンタープライズグレードの本番環境に移行する際の厳しい真実を以下に示します。

推論はOLTP++：前例のない並列性を計画せよ 過去20年間、私たちは人間の行動に合わせてデータシステムとストレージ層を調整してきました。人間は遅いです。ボタンをクリックし、ページの読み込みを待ち、画面を読み、30秒後にもう一度クリックするかもしれません。たとえ大規模であっても、人間のトラフィックは予測可能な日内パターンに従います。キャッシュして平均化できます。一方、AIエージェントはコーヒーをすすったり、読むのに時間をかけたりしません。自律エージェントがReAct（推論と行動）ループを実行すると、クエリを発射し、コンテキストを取り込み、さらに情報が必要だと認識し、ミリ秒以内にさらに3つのクエリを並行して発射します。今度はそれを、EC2フリート全体で動作する数千の同時エージェントに掛け合わせてみてください。私たちの顧客は、AI推論がOLTP++のように振る舞うのを目の当たりにしています。前例のない並列性、大規模な読み取りスパイク、予測不可能なアクセスパターンを示します。CloudWatchの経営陣に優しい平均値と過去のCPU使用率に基づいてキャパシティ計画を立てているなら、あなたは目隠しして飛んでいるようなものです。あなたは突然の極端なI/O需要のスパイクに備えてアーキテクチャを設計しなければなりません。エージェント時代においては、ピーク負荷が唯一重要な負荷だからです。

ベクトルDBとRAG：プロンプトだけでなくデータパスを設計せよ 現在、AIエコシステムはプロンプトエンジニアリングとモデルのファインチューニングに夢中です。しかし、検索拡張生成（RAG）アプリケーションをローカルのJupyterノートブックからAWS本番環境に移行すると、すぐに厳しい現実に気付きます。ボトルネックはPythonではなく、LLMでもありません。ボトルネックは、データがどのように保存、アクセス、移動されるか、つまりインデックススキャン、埋め込み取得、スキャッターギャザーレイテンシにあります。階層的ナビゲーションワールド（HNSW）やフラット量子化を備えた転置ファイル（IVFFlat）のようなベクトル類似性検索をリレーショナルメタデータフィルタリングと組み合わせて実行する場合、データアクセス層に高度に複雑でメモリ集約的な操作を強制することになります。AWSホスト環境の場合、ホットベクトルに対するサブミリ秒の読み取りと、データセットが数億行に成長しても予測可能なスループットを目指す必要があります。あまりにも多くのエンジニアリングチームが、AWS Relational Database Service（RDS）の読み取りレプリカを主要なスケーリング戦略として扱っています。明確にしましょう。レプリカは最後の手段であり、戦略ではありません。さらに重要なことに、基盤となるストレージとデータアクセス層に対処せずにデータベース層をスケーリングすることは、ボトルネックを取り除くのではなく、単に移動させるだけです。あなたのアーキテクチャ計画が「リーダーを追加して祈る」に要約されるなら、トラフィックピークから壊滅的なポストモーテムまであと一歩です。リスクなしでベクトル検索を既存のアプリに追加することでAIイノベーションを解き放つ必要があります。それには、高次元の数学の物理を処理できるデータパスを設計する必要があります。

AWS EBSの現実確認 AWSは素晴らしいプラットフォームであり、Elastic Block Store（EBS）は現代のクラウドの主力です。しかし、EBSは物理法則とクラウド経済の法則に縛られています。EBSボリュームはバーストバケットと厳格なボリュームごとのIOPSおよびスループット上限に依存しています。これらのメカニズムはマルチテナントクラウド環境を保護するために存在し、アプリケーションのSLAを気にしません。AIエージェントが暴走したり、突然の推論トラフィックの急増がデータ層を直撃したりすると、EBSバーストクレジットは数分で使い果たされます。バケットが空になると、ストレージのパフォーマンスは急落します。レイテンシは1ミリ秒から50ミリ秒に跳ね上がります。アプリケーションはストレージを待って停止し、アプリケーションサーバーはワーカースレッドを使い果たし、スタック全体がロックアップします。この問題は、スライダーをスライドさせてより多くのIOPSをプロビジョニングするだけでは解決できません。ある時点で、単一のEC2インスタンスとその接続されたストレージが物理的にプッシュできるハードリミットに達します。

AWSストレージ制限からの解放 たとえAWSが恒久的な拠点であっても、AI推論はエンタープライズアーキテクチャへの需要を再形成しています。推論ワークロードは極限のパフォーマンスを要求し、データアーキテクチャがネイティブEBS SKUのハードリミットに密接に結合されている場合、あなたは閉じ込められています。この罠から抜け出すには、AWSインフラの上に位置するソフトウェア定義のストレージ抽象化が必要で、それにより大きなレバレッジを得られます。アプリケーションとデータのパフォーマンスをネイティブのAWSストレージ制限から切り離すことで、EC2キャパシティ危機、IOPS価格の高騰、インスタンスタイプのロックインからアプリケーションを保護できます。

唯一重要なKPI：混合負荷下のp99/p999 平均レイテンシを見るのはやめましょう。平均値は、私たちが自分自身とリーダーシップに対してインフラについて気分を良くするために語る嘘です。ユーザーとAIエージェントは異常値を感じます。クエリの1%が3秒かかり、エージェントの推論チェーン全体をブロックする場合、平均レイテンシが2ミリ秒であることは何の意味もありません。テールレイテンシ（p99とp999）をハードなリリースブロッカーにしなければなりません。問題が発生する場所、特にストレージとデータアクセス層でのテールレイテンシを追跡する必要があります。アイドルシステムのベンチマークは無意味です。現実世界の高ストレス条件下でp99を測定する必要があります：同時OLTP+推論+メンテナンスジョブ：大規模なバッチ更新やバキュームプロセスが開始されたときに、ベクトル検索はどうなるか？AZ間の変動：フェイルオーバーイベントやAWSがプレースメントグループを変更したときに、レイテンシはどのように劣化するか？オートスケーリングイベントとキャッシュウォームアップ：新しいEC2ノードが起動したとき、キャッシュがウォームアップするまでにどのくらい時間がかかり、その間にストレージ層はどの程度影響を受けるか？プラットフォームがこれらの混合負荷条件下でテールをしっかりと維持できない場合、ステージ上のデモがどれほど良くても、推論に対してプロダクション対応ではありません。

顧客の悪夢：成功の災害 今まさに業界全体で展開されているシナリオを見てみましょう。その会社を「FinRetail」と呼びます。FinRetailは組み込みフィンテックを備えた大規模なeコマースプラットフォームです。FinRetailは素晴らしいAIショッピングアシスタントを構築しました。RAGを使用して、ユーザーの購入履歴、リアルタイム在庫、ライブ価格データを相互参照しました。概念実証は完璧でした。取締役会は大喜びでした。火曜日にローンチしました。火曜日の午後までに、「成功の災害」を経験していました。AIエージェントはあまりにも徹底的でした。「大学生に最適な1000ドル以下のノートパソコンは？」という単純な質問に答えるために、エージェントは40ステップの推論ループを実行し、PostgreSQLデータベースに対して数百のベクトル類似性検索を発射し、同時にリアルタイムの在庫レベルをチェックしていました。その並列性は前例のないものでした。15分以内に、FinRetailはEBSバーストクレジットを使い果たし、読み取りレイテンシが0.8ミリ秒から120ミリ秒に急上昇しました。システムは飽和し、I/O待ち状態の管理だけでサイト全体がダウンし、中核となる収益を生み出すOLTPシステムも巻き込まれました。読み取りレプリカを追加しようとしましたが、基盤となるストレージの制約は残り、AIエージェントは古い在庫データに基づいて幻覚を起こし始め、数時間前に売り切れた製品を推奨しました。それは完全なポストモーテムシナリオであり、すべては現代の推論ワークロードを処理できないストレージ層が原因でした。

Silkがこのリスクを異なる方法で解決する方法 より多くのマネージドディスクを投入してもAIデータ問題は解決できません。根本的なアーキテクチャのシフトが必要です。パフォーマンスとキャパシティを切り離す必要があります。これこそがSilkが行うことです。Silkは、EC2コンピュートと基盤インフラの間に位置するソフトウェア定義のクラウドストレージです。複数の基盤クラウドリソースのパフォーマンスを加速し、それらを単一の、想像を絶するほど高速で高弾力性のあるデータ層として提示します。高速と言うとき、それはわずかな改善のことではありません。クラウド物理の絶対限界を押し上げることです。最近、データベースの専門家であるTanel Poder氏がSilkをテストし、その処理能力を確認しました。結果は驚くべきもので、20 GiB/sのI/Oスループットを実現しました。Silkを使用すれば、単一のEBSボリュームのIOPS上限に縛られることはありません。Silkの対称型アクティブ-アクティブアーキテクチャと大規模分散キャッシング層は、AI推論の前例のない並列性を吸収します。ホットベクトルをメモリから直接提供し、重いOLTPワークロードとメンテナンスジョブを同時に実行している場合でも、一貫したサブミリ秒のp99レイテンシを提供します。私たちはこれを、世界で最も要求の厳しいデータ集約型アプリケーション全体で実証しています。Postgres on Silkで高性能AIベクトル検索の限界を押し上げる場合でも、Google AlloyDBでPostgres AIワークロードをさらに拡張する場合でも、結果は同じです：極端なスケールでのエンタープライズグレードの予測可能性。Silkは、より多くのストレージパフォーマンスを得るためにEC2コンピュートを過剰プロビジョニングする必要を排除し、コアデータパスに脆弱な読み取りレプリカに依存する必要を排除します。AWS上でAIワークロードを、まったく同じエンタープライズデータサービスとパフォーマンス保証で実行する自由を与えます。

祈るのをやめてエンジニアリングを始めよう AI推論の津波はすでに到来しています。生き残るシステムは、激しい並列性、大規模なスループット、妥協のないテールレイテンシのために設計された、現代のソフトウェア定義クラウドストレージアーキテクチャ上に構築されたシステムです。自分自身の「成功の災害」を待って、AWSストレージがボトルネックであることに気づかないでください。今こそ、ボンネットの下を覗いて、AI対応のデータプラットフォームがどのように見えるかを確認する時です。証拠を見る準備はできましたか？Microsoftの最高データ＆AI責任者Eduardo Kassner氏とSilkの製品担当バイスプレジデントTom O'Neill氏から、なぜAI推論がシステム動作を再形成しているのか、そして解決策が単にレプリカの追加、新しいストレージシステムの採用、またはアプリケーションの書き換えではない理由を聞いてください。ウェビナーを今すぐご覧ください："AI Inference Didn’t Break Your Architecture - It Reveals What Comes Next"。Silk提供。