AirtableがMilvusでベクトルインフラを構築し、スケールさせた方法
低レイテンシのクエリ
予測可能なパフォーマンスはユーザーの信頼にとって不可欠です
高スループットの書き込み
基盤は絶えず変化し、埋め込みは同期を保つ必要があります
水平スケーラビリティ
システムは何百万もの独立した基地をサポートしなければならない
この記事はもともと the Airtable Medium チャンネルで公開され、許可を得てここに再掲載されています。
Airtable におけるセマンティック検索が、概念からコアなプロダクト機能へと進化するにつれ、Data Infrastructure チームはそれをスケールさせるという課題に直面しました。Building the Embedding System に関する以前の記事で詳述したように、私たちはすでに、埋め込みのライフサイクルを処理するための堅牢で結果整合性のあるアプリケーション層を設計していました。しかし、アーキテクチャ図にはまだ 1 つ重要なピースが欠けていました。それはベクトルデータベースそのものです。
私たちには、数十億の埋め込みをインデックス化して提供でき、大規模なマルチテナンシーをサポートし、分散クラウド環境でパフォーマンスと可用性の目標を維持できるストレージエンジンが必要でした。これは、私たちがどのようにベクトル検索プラットフォームを設計し、堅牢化し、進化させ、Airtable のインフラストラクチャスタックの中核的な柱にしていったかの物語です。
背景
Airtable での私たちの目標は、顧客が自分たちのデータを強力かつ直感的な方法で扱えるようにすることです。ますます強力で正確な LLM の登場により、データのセマンティックな意味を活用する機能は、私たちのプロダクトの中核になりました。
セマンティック検索の活用方法
Omni（Airtable の AI Chat）が大規模データセットから実際の質問に回答する
50 万行あるあなたの base（データベース）に自然言語の質問をして、正確で文脈に富んだ回答を得ることを想像してみてください。たとえば：
「最近、顧客はバッテリー寿命について何と言っていますか？」
小規模なデータセットでは、すべての行を直接 LLM に送ることが可能です。スケールすると、それはすぐに現実的ではなくなります。代わりに、私たちには次のことができるシステムが必要でした。
- クエリのセマンティックな意図を理解する
- ベクトル類似検索によって最も関連性の高い行を取得する
- それらの行をコンテキストとして LLM に提供する
この要件は、その後のほぼすべての設計判断を形作りました。Omni は、非常に大きな base であっても、瞬時で知的に感じられる必要がありました。
リンクされたレコードのレコメンデーション：完全一致よりも意味
セマンティック検索は、Airtable の中核機能であるリンクされたレコードも強化します。ユーザーは、完全なテキスト一致ではなく、コンテキストに基づく関係性の提案を必要としています。たとえば、プロジェクトの説明が、その具体的なフレーズを一度も使っていなくても、「Team Infrastructure」との関係を示唆している場合があります。
こうしたオンデマンドの提案を提供するには、一貫性があり予測可能なレイテンシで、高品質なセマンティック検索が必要です。
私たちの設計上の優先事項
これらの機能やその他の機能をサポートするために、私たちは 4 つの目標を中心にシステムを据えました。
- 低レイテンシのクエリ（500ms p99）： 予測可能なパフォーマンスは、ユーザーの信頼にとって重要です
- 高スループットの書き込み： base は絶えず変化し、埋め込みは同期された状態を保つ必要があります
- 水平スケーラビリティ： システムは数百万の独立した base をサポートする必要があります
- セルフホスティング： すべての顧客データは、Airtable が管理するインフラストラクチャ内にとどまる必要があります
これらの目標が、その後のすべてのアーキテクチャ上の判断を形作りました。
ベクトルデータベースベンダーの評価
2024 年後半、私たちはいくつかのベクトルデータベースの選択肢を評価し、最終的に 3 つの主要要件に基づいて Milvus を選定しました。
- 第一に、データプライバシーを確保し、インフラストラクチャを細かく制御し続けるために、セルフホスト型ソリューションを優先しました。
- 第二に、書き込みの多いワークロードとバースト的なクエリパターンには、低く予測可能なレイテンシを維持しながら弾力的にスケールできるシステムが必要でした。
- 最後に、私たちのアーキテクチャには、数百万の顧客テナントにわたる強力な分離が必要でした。
Milvus は最適な選択肢として浮上しました。その分散型の性質は大規模なマルチテナンシーをサポートし、取り込み、インデックス作成、クエリ実行をそれぞれ独立してスケールできるため、コストを予測可能に保ちながらパフォーマンスを提供できます。
アーキテクチャ設計
テクノロジーを選定した後、次に Airtable の独自のデータ形状、つまり異なる顧客が所有する数百万もの個別の「bases」を表現するためのアーキテクチャを決定する必要がありました。
パーティショニングの課題
私たちは主に 2 つのデータパーティショニング戦略を評価しました。
オプション 1: 共有パーティション
複数の bases が 1 つのパーティションを共有し、クエリは base id でフィルタリングすることでスコープされます。これによりリソース利用率は向上しますが、追加のフィルタリングオーバーヘッドが発生し、base の削除がより複雑になります。
オプション 2: 1 つの Base に 1 つのパーティション
各 Airtable base は Milvus 内の独自の物理パーティションにマッピングされます。これにより強力な分離が提供され、base の削除を高速かつシンプルに行うことができ、クエリ後フィルタリングによるパフォーマンスへの影響を回避できます。
最終戦略
私たちは、そのシンプルさと強力な分離性からオプション 2 を選択しました。しかし、初期テストでは、単一の Milvus コレクション内に 100k のパーティションを作成すると、大幅なパフォーマンス低下が発生することが分かりました。
- パーティション作成レイテンシが約 20 ms から約 250 ms に増加
- パーティションのロード時間が 30 秒を超過
これに対処するため、コレクションあたりのパーティション数に上限を設けました。各 Milvus クラスターごとに 400 個のコレクションを作成し、それぞれ最大 1,000 個のパーティションを持つようにしています。これにより、クラスターあたりの bases の総数は 400k に制限され、追加の顧客がオンボーディングされるにつれて新しいクラスターがプロビジョニングされます。
インデックス作成とリコール
インデックスの選択は、私たちのシステムにおける最も重要なトレードオフの 1 つであることが分かりました。パーティションがロードされると、そのインデックスはメモリまたはディスクにキャッシュされます。リコール率、インデックスサイズ、パフォーマンスのバランスを取るため、複数のインデックスタイプをベンチマークしました。
- IVF-SQ8: メモリフットプリントは小さいものの、リコールは低めでした。
- HNSW: 最高のリコール（99%-100%）を実現しますが、メモリを多く消費します。
- DiskANN: HNSW と同様のリコールを提供しますが、クエリレイテンシは高くなります
最終的に、優れたリコールとパフォーマンス特性から HNSW を選択しました。
アプリケーション層
大まかに言うと、Airtable のセマンティック検索パイプラインには 2 つの中核的なフローがあります。
- 取り込みフロー: Airtable の行を embeddings に変換し、Milvus に保存する
- クエリフロー: ユーザーのクエリを embed し、関連する行 ID を取得して、LLM にコンテキストを提供する
どちらのフローも、大規模環境で継続的かつ信頼性高く動作する必要があり、以下でそれぞれ説明します。以下でそれぞれ説明します。
取り込みフロー: Milvus を Airtable と同期し続ける
ユーザーが Omni を開くと、Airtable はその base を Milvus に同期し始めます。パーティションを作成し、その後、行をチャンク単位で処理して embeddings を生成し、Milvus に upsert します。それ以降は、base に加えられたすべての変更をキャプチャし、それらの行を再度 embed して upsert することで、データの一貫性を保ちます。
クエリフロー: データの使い方
クエリ側では、ユーザーのリクエストを embed し、それを Milvus に送信して最も関連性の高い行 ID を取得します。その後、それらの行の最新バージョンを取得し、LLM へのリクエストにコンテキストとして含めます。
運用上の課題とその解決方法
セマンティック検索アーキテクチャを構築すること自体も 1 つの課題ですが、それを数十万の bases に対して信頼性高く運用することは、また別の課題です。以下では、その過程で学んだいくつかの重要な運用上の教訓を紹介します。
デプロイメント
私たちは Milvus operator を使って Kubernetes CRD 経由で Milvus をデプロイしており、クラスターを宣言的に定義・管理できるようにしています。構成更新、クライアント改善、Milvus アップグレードなど、あらゆる変更は、ユーザーにロールアウトする前に、ユニットテストと、本番トラフィックをシミュレートするオンデマンドの負荷テストを通過します。
バージョン 2.5 では、Milvus クラスターは以下の中核コンポーネントで構成されています。
- Query Node はベクトルインデックスをメモリ内に保持し、ベクトル検索を実行します
- Data Node は取り込みとコンパクションを処理し、新しいデータをストレージに永続化します
- Index Node は、データが増加しても検索を高速に保つためにベクトルインデックスを構築・維持します
- Coordinator Node は、すべてのクラスター活動とシャード割り当てをオーケストレーションします
- Proxy node は API トラフィックをルーティングし、ノード間で負荷を分散します
- Kafka は、内部メッセージングとデータフローのためのログ／ストリーミング基盤を提供します
- Etcd は、クラスターのメタデータと調整状態を保存します
CRD 駆動の自動化と厳格なテストパイプラインにより、更新を迅速かつ安全にロールアウトできます。
可観測性: システムの健全性をエンドツーエンドで理解する
セマンティック検索が高速で予測可能な状態を保つよう、私たちはシステムを 2 つのレベルで監視しています。
インフラストラクチャレベルでは、すべての Milvus コンポーネントにわたって CPU、メモリ使用量、Pod の健全性を追跡しています。これらのシグナルにより、クラスターが安全な範囲内で稼働しているかどうかが分かり、リソースの飽和や不健全なノードといった問題がユーザーに影響する前に検知できます。
サービスレイヤーでは、各 base が取り込みワークロードとクエリワークロードにどれだけ追従できているかに注目しています。コンパクションやインデックス作成のスループットのようなメトリクスにより、データがどれだけ効率的に取り込まれているかを可視化できます。クエリの成功率とレイテンシにより、データをクエリするユーザー体験を理解でき、パーティションの増加によりデータの増え方を把握できるため、スケールが必要になった場合にアラートを受け取れます。
ノードローテーション
セキュリティおよびコンプライアンス上の理由から、私たちは Kubernetes ノードを定期的にローテーションしています。ベクトル検索クラスターでは、これは単純ではありません:
- Query Node がローテーションされると、Coordinator はメモリ内データを Query Node 間で再バランスします
- Kafka と Etcd はステートフルな情報を保存し、クォーラムと継続的な可用性を必要とします
私たちは、厳格な disruption budget と 1 度に 1 ノードずつのローテーションポリシーでこれに対応しています。次のノードを入れ替える前に、Milvus Coordinator に再バランスのための時間を与えます。この慎重なオーケストレーションにより、私たちの速度を落とすことなく信頼性を維持できます。
コールドパーティションのオフロード
運用上の最大の成果の 1 つは、私たちのデータには明確なホット／コールドのアクセスパターンがあると認識したことでした。利用状況を分析したところ、Milvus 内のデータのうち、特定の週に書き込みまたは読み取りが行われるのは約 25% にすぎないことが分かりました。Milvus ではパーティション全体をオフロードでき、Query Node のメモリを解放できます。そのデータが後で必要になった場合は、数秒以内に再ロードできます。これにより、ホットデータをメモリ内に保持し、残りをオフロードできるため、コストを削減し、時間の経過とともにより効率的にスケールできるようになります。
データ復旧
Milvus を広範に展開する前に、どのような障害シナリオからでも迅速に復旧できるという確信が必要でした。ほとんどの問題はクラスターに組み込まれた耐障害性でカバーされますが、データが破損したり、システムが復旧不能な状態に陥ったりするまれなケースにも備えました。
そうした状況での復旧手順はシンプルです。まず新しい Milvus クラスターを立ち上げ、ほぼ即座にトラフィックの処理を再開できるようにします。新しいクラスターが稼働したら、最もよく使用される base を先行して再埋め込みし、その後、残りはアクセスされた時点で遅延処理します。これにより、システムが一貫性のあるセマンティックインデックスを徐々に再構築している間も、最もアクセスされるデータのダウンタイムを最小限に抑えられます。
次の展開
Milvus を用いた私たちの取り組みにより、Airtable におけるセマンティック検索の強固な基盤が築かれました。高速で意味のある AI 体験を大規模に支えるものです。このシステムが整ったことで、私たちは現在、プロダクト全体でよりリッチな検索パイプラインと、より深い AI 統合を模索しています。今後も刺激的な取り組みが数多く控えており、私たちはまだ始まったばかりです。
このプロジェクトに貢献した、Data Infrastructure および組織全体の過去および現在のすべての Airtablet に感謝します: Alex Sorokin、Andrew Wang、Aria Malkani、Cole Dearmon-Moore、Nabeel Farooqui、Will Powelson、Xiaobing Xia。
Airtable について
Airtable は、組織がカスタムアプリを構築し、ワークフローを自動化し、共有データをエンタープライズ規模で管理できるようにする、主要なデジタルオペレーションプラットフォームです。複雑で部門横断的なプロセスを支援するよう設計された Airtable は、チームが単一の信頼できる情報源に基づいて、計画、調整、実行のための柔軟なシステムを構築するのを支援します。Airtable が AI 搭載プラットフォームを拡張する中で、Milvus のようなテクノロジーは、より高速でスマートな製品体験を提供するために必要な検索インフラストラクチャを強化するうえで重要な役割を果たします。