Google CloudがAlloyDB AIの埋め込みモデル移行手順を紹介、旧列削除と容量見積もりを支援

AlloyDB AIのモデル更新でできること

新しいモデルへの切り替えを終え、機能と安定性に問題がないと判断できた段階で、旧モデル用の資源を廃止できます。対象は旧モデルの埋め込み列や旧インデックス、旧列の自動埋め込み設定で、目的はディスク領域の回収です。^[2]

図1　切り替え後に廃止できる旧モデルの資源

Google Cloudは、AlloyDBならメンテナンスによる停止やアプリケーション側の複雑な変更なしに、本番環境の埋め込みモデルを更新できるとしています。組み合わせるのは、AlloyDB AIの自動埋め込みやModel Endpoint Management、PostgreSQLの標準的な運用制御です。

AlloyDB AIの旧モデル用構成の削除手順

Google Cloudは、始め方としてAlloyDBの試用クラスタの起動やAlloyDB AIの公式ドキュメントの参照を挙げています。新しいモデルへの切り替えを完了し、機能と安定性に問題がないと判断した後、旧列の自動埋め込み設定と旧ベクトルインデックスを削除します。^[2]

図2　旧埋め込み列と設定、インデックスの廃止手順

旧モデル用の構成の削除手順

旧列の自動埋め込み設定はai.drop_embedding_configで削除し、旧ベクトルインデックスはDROP INDEX CONCURRENTLYで削除します。削除の時期は、新しいモデルへの切り替えを完了し、機能と安定性に問題がないと判断した後です。

図3　旧列の構成を削除する順序

新しいモデルへの切り替えを完了し、機能と安定性に問題がないと判断した後に実行する、ecomm.product_reviewsテーブルを例にした削除のコードは、以下の通りです。

-- 1. Drop auto embedding configuration on old column 
-- NOTE: 'embedding_col_old' assumes Pattern A was followed above. Use 'embedding_col' if you following Pattern B.
CALL ai.drop_embedding_config(table_name => 'ecomm.product_reviews', embedding_column => 'embedding_col_old');

-- 2. Drop old vector index concurrently (update to match the name of your previous index)
DROP INDEX CONCURRENTLY ecomm.product_reviews_embedding_col_scann_old;

公式資料からの抜粋：How to upgrade embedding models in AlloyDB AI with zero downtime（Step-by-step migration walkthrough / Step 7: Retire the legacy model and reclaim storage）。対象版・範囲：AlloyDB AI（ブログ記事の手順、版の指定なし）。

上記のコードは、新しいモデルへの切り替えを完了し、機能と安定性に問題がないと判断した後に実行します。旧列の自動埋め込み設定を削除してから、旧インデックスをCONCURRENTLY付きで削除する内容です。

旧列名はPattern Aに沿った場合の名前で、Pattern Bならembedding_colを指定します。インデックス名も、以前のインデックス名に合わせて書き換えます。

TOAST領域の回収手順

ALTER TABLE DROP COLUMNで列をPostgreSQLのカタログテーブルから外しても、TOAST領域はデータページが書き直されるまでディスク上に残ります。列の削除前に旧ベクトル列をバッチ単位でNULLにすると、そのディスク領域を今後の操作で再利用可能にできます。

図4　TOAST領域を回収する手順

Google Cloudが10万行で検証した結果では、列の削除前に旧ベクトルをNULLにしてVACUUMを実行し、381 MBのTOAST領域を回収できました。回収した領域は、その後のモデル更新で再利用できる状態です。

旧ベクトルのNULL化から列の削除までのコードでは、CALLを明示的なトランザクションブロックの外で実行します。

-- Helper procedure to nullify old vectors in small committed batches
CREATE OR REPLACE PROCEDURE retire_embedding_column(
    p_table regclass, 
    p_column name, 
    p_batch_rows integer DEFAULT 1000
)
LANGUAGE plpgsql AS $$
DECLARE
    n bigint;
BEGIN
    LOOP
        EXECUTE format(
            'UPDATE %1$s SET %2$I = NULL 
             WHERE ctid = ANY (ARRAY(SELECT ctid FROM %1$s WHERE %2$I IS NOT NULL LIMIT %3$s))',
            p_table, p_column, p_batch_rows
        );
        GET DIAGNOSTICS n = ROW_COUNT;
        EXIT WHEN n = 0;
        COMMIT;
    END LOOP;
END;
$$;

-- Run the batched cleanup outside an explicit transaction block
CALL retire_embedding_column('ecomm.product_reviews', 'embedding_col_old', 1000);

-- Run VACUUM to place the freed TOAST pages on the table free space map (FSM)
VACUUM (PROCESS_MAIN false) ecomm.product_reviews;

-- Drop the column definition
SET lock_timeout = '2s';
ALTER TABLE ecomm.product_reviews DROP COLUMN embedding_col_old;

公式資料からの抜粋：How to upgrade embedding models in AlloyDB AI with zero downtime（Step-by-step migration walkthrough / Step 7: Retire the legacy model and reclaim storage / Reclaiming disk space）。対象版・範囲：AlloyDB AI（ブログ記事の手順、版の指定なし）。

上記のコードでは、retire_embedding_columnプロシージャが旧ベクトルを1,000行ずつNULLにし、バッチごとにコミットします。続くVACUUM (PROCESS_MAIN false)は、解放したTOASTページを空き領域マップに載せる処理です。

AlloyDB AIの埋め込みモデル移行前の確認

AlloyDB AIのうち、AI関数と自然言語機能はプレビュー版で、pre-GAサービスに当たります。編集部では、埋め込みモデルを移行する前に、自動埋め込みの更新方式や新旧のベクトル列が共存する間のディスク使用量を確かめることを勧めます。^[1][2]

図5　AlloyDB AIで埋め込みモデルを移行する前の確認項目

自動埋め込みのtransactional

incremental_refresh_modeが'transactional'の自動埋め込みでは、各書き込みトランザクションの中でベクトルが同期的に生成されます。この場合の移行も同じ順序で進めますが、異なる点が3つあります。

図6　transactionalモードの移行で異なる3点

Step 3のai.refresh_embeddings()は、新しい書き込みが両方の列を更新するため実行する必要がありません。列の入れ替えの手法は使えず、自動埋め込みが管理するトリガーに影響しないGUC + SRFの抽象化方式を使う必要があります。

書き込み遅延の確認点

transactionalモードの自動埋め込みで両方のモデルを設定している間は、1行の書き込みごとにリモートの埋め込み呼び出しが2回実行されます。Google Cloudの検証で、transactionalモードの自動埋め込みで1行をUPDATEした場合の書き込み遅延の中央値は以下の通りです。

Google Cloudの検証で、transactionalモードの自動埋め込みにより1行をUPDATEした場合の値

gemini-embedding-001は3072次元の埋め込みを生成するため、リモート推論の呼び出しに、より長い時間がかかります。Google Cloudは、特に高次元のモデルで自動埋め込みのtransactionalモードを選ぶ前に、アプリケーションの書き込み遅延の許容範囲を見直すよう求めています。

図7　自動埋め込みのtransactionalモードの書き込み遅延

ディスク使用量の確認点

移行中は新旧のベクトル列が共存するため、テーブルのストレージは使用量のピークに合わせて増えます。Google Cloudは、検証で得た1行あたりの平均保存量をもとに、ディスク使用量の見積もり式を示しています。

図8　移行中のディスク使用量の見積もり式

Google Cloudの検証では、1行あたりの平均保存量がtext-embedding-005で約4.5 KB、gemini-embedding-001で約13.3 KBでした。1,000万行のテーブルでは、新しいベクトル列に約133 GB、ScaNNインデックスに6 GBが必要で、さらに余裕分を加えます。

モデル更新時に領域回収手順を選ぶ判断基準

旧ベクトル列をNULLにして領域を回収する手順は、テーブルの全行で新しい行バージョンを作るため、古い行バージョンを片付けるVACUUMが必要です。Google Cloudは、同じテーブルで領域をすぐに再利用するか、通常運用で古い行バージョンが自然に消えるのを待つかを、優先度で判断するよう求めています。^[2]

図9　TOAST領域の回収時期の判断

後に続くモデル更新のために同じテーブルの領域をすぐ使いたい場合は、NULL化とVACUUMを含む手順を選ぶ方法があります。すぐの再利用を優先しない場合は、古い行バージョンが通常運用で消えるのを待つことも選択肢です。

AlloyDB AIの新旧モデルの比較

Google Cloudの検証では、gemini-embedding-001の書き込み遅延や1行あたりの保存量がtext-embedding-005を上回りました。書き込み遅延はtransactionalモードの自動埋め込みで1行をUPDATEしたときの中央値で、保存量は1行あたりの平均です。^[2]

図10　モデル切り替えで変わる点（Google Cloudの検証）

transactionalモードのまま高次元のモデルへ移る場合は、移行中から切り替え後までの書き込み遅延を、アプリケーションの許容範囲と照らし合わせて確かめます。編集部では、新旧の列が並ぶ移行でのディスクの空きを、ピーク時の使用量を基準に見積もることを勧めます。