限界の原因は製品の選択ではなく、30 年前のアーキテクチャにあります
• AI のパイプラインが本番で遅くなる原因は、製品の性能差ではなく shared nothing というレガシーアーキテクチャという前提
• ノードがデータを分け持つ設計では、結合のたびにノード間の通信が増え、全体の速度が最も混んだ 1 台に引っ張られることになる
• VAST の Disaggregated Shared Everything（DASE）はノードがデータを分け持たない構造を取り、取り込み・ベクトル・データ変換の 3 つのサイロをまとめられる
GPU は届いた。モデルも決まった。それでも本番に乗らない。
理由を追っていくと、たいてい構成図に行き着きます。取り込みに Kafka、変換に Spark、生データにデータレイク、埋め込みに専用のベクトルデータベース。箱と箱をつなぐ線が、そのまま待ち時間と重複したコピー、そしてガバナンスの空白になっています。
この記事では、箱を増やすほど遅くなる理由を 30 年前の前提まで遡って分解し、VAST が DASE でその前提をどう外したかを説明します。
箱を増やすほど、AI パイプラインは遅くなる
ここ数年、データ基盤の標準的な設計図はレゴの箱をひっくり返した床のようになっていました。基本的な AI パイプラインを 1 本組むだけでも、性質の違う技術を継ぎ足す必要があったからです。取り込みに Kafka クラスタ、ETL（extract, transform, load）に Spark クラスタ、生データを置くデータレイク、そして埋め込みを扱う専用のベクトルデータベース。
構成図の線は、単なる接続ではありません。線 1 本ごとに、次の 3 つが積み増されます。
系統をまたぐたびに増える待ち時間
同じデータを複数のシステムで持つための重複したインフラ
システムごとに分かれた権限管理と、その間に生まれるガバナンスの空白
この積み増しが、データ税です。効いてくるのは、実験的な生成 AI から本番規模のワークロードに移る段です。データを動かす複雑さが、データそのものの価値を上回る地点に届くからです。
原因は、ノードがデータを分け持つ設計にある
原因は、ネットワークが遅いからでも、ノードの台数が足りないからでもありません。30 年にわたって前提とされてきた shared nothing というアーキテクチャそのものです。 従来型の shared nothing MPP（Massively Parallel Processing）データベースでは、各ノードがデータの特定の一部を持ちます。2000 年代の静的な BI レポートには、この分担がよく効きました。しかし AI の時代には、構造的に脆くなります。
訳者注: MPP は、複数のノードで問い合わせを分担して処理するデータベースの構成です。shared nothing では、データをあらかじめ分割し、それぞれの断片を特定のノードに分け持たせます。各ノードは自分のメモリとディスクだけを見ており、隣のノードの中身は見えません。処理する範囲が静的で、分割を事前に設計できる用途では、この分担が効率よく働きます。
このモデルではノードが互いのメモリやディスクを見られないため、複雑な AI のクエリは大量の East-West トラフィックを引き起こします。結合の相手を見つけるために、データがネットワークを横方向に流れるからです。
AI パイプライン全体の速度は、いちばん遅く、いちばん混んでいる 1 台の速度になります。
「ある規模を超えると、こうしたクラスタは単純に倒れます」。VAST でソリューションエンジニアリングを統括する VP、Fouad Teban の言葉です。Teban は、必要なのは統合を増やすことでも統合の質を上げることでもなく、層をまとめて減らすことだと述べています。
訳者注: 分け持つことの費用は、クエリの遅さだけではありません。ノードを追加すれば、どのノードが何を持つかの割り直しが走ります。ロックとキャッシュの整合を取るために、ノード同士が会話し続けます。台数が増えるほど、この会話の量が増えていきます。増設した分がそのまま使えない差分は、ここから出てきます。
まとめられるサイロは 3 つ ある
Teban が挙げたのは、いま多くの構成に残っている 3 つのサイロです。取り込み、ベクトル、そして変換処理。順に見ていきます。
取り込み層を別に建てる理由がなくなる
Teban が最初に取り上げたのは、ストリーミングとストレージの間にある壁です。リアルタイムの AI システムの多くは、Kafka のようなストリーミング基盤に依存しています。そのため、トピックからテーブルにデータを移すためだけにコネクタを保守し続ける状態が生まれます。
Teban が明言しなかった含意は、こうです。ストリーミング基盤が存在するのは、ストレージがリアルタイムのデータを十分な速さで取り込み、すぐに見せられなかったからです。
VAST が 10 年前に導入した DASE は、ストリーミングでの取り込みと永続的な共有ストレージの境界を、その多くをなくします。切り離されたシステムの間でデータを運び続けるのではなく、高速な書き込みと即時の可用性に最適化された 1 つの基盤に対して、取り込み、永続化、クエリ、提供を実行できます。取り込んだデータは分析クエリ向けに列指向へ変換されるため、Teban の言うとおり OLTP（Online Transaction Processing）と OLAP（Online Analytical Processing）の境界も曖昧になります。
訳者注: DASE が境界をなくせる理由は、ノードがデータを分け持たない点にあります。ステートレスな計算ノード（CNode）と、NVMe フラッシュを収めた筐体（DBox）を分けたうえで、メタデータとシステム状態のすべてを NVMe 上に置き、クラスタ内のどの CNode からも直接アクセスできるようにしています。分け持つ前提が最初からないため、取り込んだデータはそのまま全ノードから読めます。
ストレージとコンピュートが独立にスケールする点も効きます。取り込みのスループットを、クエリ側の基盤と固く結びつけずに伸ばせるからです。これによりストリーミング層を別に持つ必要がなくなり、届いたばかりのテレメトリと数年分の履歴を 1 つのクエリで結合できます。データ基盤の担当者から見れば、Kafka トピックの「無限保持」がネームスペースの標準的な性質になります。保持期間のためにチューニングを続ける必要もありません。
ベクトルは列の型のひとつになる
ストリーミング層をまとめることがデータの「いつ」を単純にするのに対して、ベクトル検索の統合はデータの「何を」を単純にします。
いま業界にあるのは、専用データベース疲れと呼べる状態です。専用のベクトルストアが次々に登場しましたが、技術の意思決定者から見れば、守る対象と統制する対象がもう 1 つ増えたことになります。Teban の見方では、ベクトルは列の型のひとつにすぎません。
「埋め込みは、メタデータや非構造化データと同じクラスタに置かれます。それによって、多くのサイロと重複を避けられます」
VAST DASE アーキテクチャを土台にした列指向データベースの中で埋め込みをネイティブなデータ型として扱えば、Postgres に置いたメタデータと外部ベクトルストアのベクトルを同期し続ける必要がなくなります。構造化されたメタデータで絞り込みながら、同時に意味的な検索をかける SQL も書けます。ノードがデータを分け持たないため、shared nothing のデータシャッフルに由来する性能低下も起きません。
変換処理はデータのある場所で実行する
継続的な AI 規模のパイプラインでは、クラウドの従量課金モデルが崩れやすくなります。常駐するコンピュート、データの移動、止まらない変換ジョブが積み上がるためです。Teban は、データが流れ続ける結果として終了しない Spark ジョブと、それが引き起こすクラウド請求の膨張を挙げています。
ここにも答えがあると Teban は言います。VAST クラスタのストレージ層の上に位置するコンピュートノードで、Managed Spark (on CNode) と Managed Trino (on CNode) をネイティブに動かせます。これにより、medallion lakehouse アーキテクチャで言う Bronze から Gold までの変換パイプラインを、共有されたデータに対してその場で実行できます。別の分析システムの間でデータセットをコピーする必要はありません。
訳者注: medallion lakehouse は、生データを Bronze、整えたデータを Silver、分析用に集約したデータを Gold と段階で分ける設計方針です。段階ごとに別の分析システムへデータセットをコピーするのが一般的でした。
これは zero migration の考え方です。データサイエンティストがすでに使っている Jupyter、Spark、Python がそのまま動くため、コストの膨らんだクラウドネイティブな構成を戻す作業は、コードの書き換えではなく、重心の移動になります。
実際どうなるか
原文は、この構成の性能として次の 2 つを挙げています。
VAST DataBase が毎秒 1,000 クエリを超える処理を維持し、クライアントの同時実行を 75 スレッドから 375 スレッドに増やしてもほぼ線形に伸びた
類似検索が兆行規模でサブ秒のレイテンシまでスケールした
まとめ ネイティブなストリーミング、統合されたベクトル、そして戻ってきた ETL。この 3 つが重なることは、best-of-breed による分断の終わりを意味します。AI で動く企業に、分断されたスタックの待ち時間を負担する余裕はないと Teban は言います。
次の 1 年の問いは、これらのばらばらなシステムをどうつなぐかではありません。どのサイロを最初に手放すかです。ノードとノードの間に橋を架けるのをやめ、データと洞察の距離をまとめて詰めはじめた設計者が、最も成果を出すことになります。
訳者注: 原文の数値をそのまま自社に当てはめるより、次の 4 点を自分の環境で測るほうが判断の材料になります。ノードがデータを分け持つ構成との差がでます。
・ノードを追加した直後の性能。割り直しが走る構成では、追加した直後に一度落ちる
・同時実行を増やしたときの伸び方。線形から外れる点が、その構成の実質的な上限
・取り込みから検索できるようになるまでの時間。層をまたぐ構成では、ここにコネクタの遅延が乗る
・同じデータの実体が何箇所にあるか。容量とガバナンスのコストは、この数に比例する
他社製品を検討する場合は、次の 3 点で構造の違いが見えます。取り込み層を別に建てずに取り込んだデータをそのままクエリできるか。ベクトルと構造化されたメタデータを同じクエリで扱えるか。変換処理をデータのある場所で実行できるか。いずれも「できない」場合、コネクタの保守か、コピーの分の容量とガバナンスのコストが残り続けます。
本ブログ記事はhttps://www.vastdata.com/blog/the-data-stack-is-breaking-under-ai-scaleの翻訳記事となります。
