AIエージェントの検証環境を共通化、Orchard導入前の制約
AI・自動化 2
AlloyDBがAI処理を本番系から分離、ただし提供はプレビュー
Google Cloudは2026年9月24日の発表で、AlloyDBの「PostgreSQL for agents」をプレビューとして公開した。AIエージェントによるデータベースの読み取りを、本番のトランザクションを担うプライマリ、スタンバイ、既存のリードレプリカから分離する。エージェント用のインスタンスは読み取り専用で、更新が続く本番データを参照できる。
国内技術メディアのPublickeyの報道は、専用インスタンスを数秒で用意し、処理後にはゼロまで縮退させる仕組みと、利用登録を受け付けるプレビュー段階であることを伝えている。既存のリードレプリカと異なるのは、突発的な読み取り需要に合わせて計算資源を増減させる点だ。本番側への負荷を分ける仕組みは、インスタンスの配置だけでなく、保存層へのアクセス経路にも及ぶ。
エージェントは何を共有し、何を分けるのか
この構成では、エージェントに本番データの新しい状態を見せながら、問い合わせを実行する計算資源を独立させる。起動する各ノードにはAlloyDBのPostgreSQLエンジンがあり、SQLと索引を使ってデータを読む。検索用に別のデータベースを定期的に作り直す構成とは、データの鮮度と読み取り処理の置き場所が異なる。
エージェント向けノードが属するのは、本番クラスタとは別のagent poolだ。ノードは必要に応じて立ち上がり、処理が終わると停止する。本番側は継続的なトランザクション処理のために確保された環境を使い続けるため、エージェントの問い合わせが増えても、その実行先をプライマリや既存のリードレプリカに追加する必要はない。
分離の対象にはストレージの読み取り経路も含まれる。エージェント用ノードは、Googleの分散ストレージ基盤Colossusにある本番データの新しい状態を参照するが、本番処理とは別のストレージセグメントから読む設計だ。同じデータを見せることと、同じ読み取り資源を取り合うことを切り離している。計算ノードだけを別にしても保存層が混雑すれば本番に影響が及ぶため、この違いが分離の核心となる。
読み取り専用であっても、使えるのは単純な行検索だけではない。各ノードは索引を利用した検索に加え、ベクトル検索、全文検索、空間検索を実行できる。エージェントが一つの処理の途中で複数の条件を試す場合も、検索機能のためだけに本番側へ問い合わせを戻す必要がない。一方、この経路は本番データを書き換えるためのものではない。
通常のリードレプリカと共有ストレージ型との違い
一般的な独立型リードレプリカは、プライマリから変更を複製し、それぞれの計算資源と保存領域で読み取りを処理する。資源を分けやすい構成だが、新たなレプリカには保存データを用意する時間がかかる。短い間だけ多数の問い合わせが来る場合、その増減に合わせてレプリカを用意するのは難しく、待機中の資源も維持することになる。
共有ストレージ型は、読み取りノードが既存の保存層を使えるため、データの複製を待たずに計算資源を追加しやすい。ただし、プライマリと読み取りノードが同じストレージサーバーやキャッシュ層を使う設計では、問い合わせが集中すると保存層の帯域を奪い合う。ノードの起動が速いことだけでは、本番処理から負荷を分離できたとは言えない。
今回のagent poolは、独立した読み取りノードを短時間で増やしながら、Colossus内の読み取り経路も本番側と分ける。従来型レプリカが持つ資源分離と、共有ストレージ型が持つ素早い起動を、別の構成で両立させようとするものだ。比較すべき点はレプリカという名前ではなく、ノードの起動時間、参照できるデータの鮮度、保存層での競合、待機中の費用である。
毎秒300万クエリはGoogleの測定値
Google Cloudのアーキテクチャ解説によると、メモリー容量を超えるデータ集合への並列インデックス検索で、agent poolを1,000ノードまで拡張した際の合計処理量は毎秒300万クエリに達し、プライマリの性能に測定可能な低下はなかった。これはGoogleが選んだ構成と負荷で行った試験の結果であり、独立機関による測定値ではない。
処理量の主体はノード一台ではなく、agent poolと保存基盤を組み合わせた構成全体だ。試験に使われたのも並列インデックス検索で、任意のSQLや複雑な結合が同じ処理量に達するという意味ではない。読み取りの条件や索引、同時実行の偏りが変われば、応答時間と必要なノード数も変わる。
分離に関する試験結果にも同じ範囲がある。測定可能な低下がなかったというのは、公開された試験中のプライマリについての報告だ。設計上は計算資源とストレージ経路を分けているが、個々の利用環境でどの程度の応答時間になるかは、公表値だけでは決まらない。公称性能を読む際は、読み取り専用の検索負荷と本番のトランザクション負荷を区別する必要がある。
プレビューでの利用条件と課金の見方
提供段階はプレビューで、利用には登録が必要だ。一般提供済みの機能と同じ条件で、既存のリードレプリカを直ちに置き換えられるという発表ではない。継続的な読み取りを受け持つレプリカと、短時間の増減が大きいエージェント向けノードでは、想定する負荷の形も異なる。
料金の考え方では、agent poolのノードが稼働した時間に応じて課金し、処理後はゼロまで縮退させるとしている。常時確保するレプリカとの費用差は、問い合わせが集中する時間と、待機時間がどれだけあるかによって変わる。単価を含む具体的な利用費用まで、この発表から算出することはできない。
本番データを新しい状態で読ませたい一方、短い読み取りの集中に備えてレプリカを常時増やしたくない場合、今回の設計は異なる選択肢になる。正式な提供条件と料金が示されれば、継続稼働するリードレプリカとの費用と性能を、同じ問い合わせ負荷で比較できるようになる。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0