平田機工株式会社 情報システムPublicationへの投稿
⚙️

Amazon Aurora PostgreSQL Serverless v2 を使用して複数のナレッジベースを管理する

中野
に公開
AWS
Aurora
Bedrock
ナレッジベース
RAG
tech

はじめに

Amazon Bedrock でナレッジベースを構築しようとした際、ベクトルストアに Amazon OpenSearch Serverless を選択するという記事が多いですが、同時に費用が高額になるという情報も目にするかと思います。実際、Amazon OpenSearch Serverless でスタンバイレプリカを無効化した場合でも、最低 1OCU が請求されるため 0.24 × 1 × 730 = $175.2/月 程度の料金が発生します。

そのため、検証が目的でもナレッジベース毎に Amazon OpenSearch Serverless が必要になると費用が高額になるため、躊躇することがあるかもしれません。そこで、あまり費用をかけずに複数のナレッジベースを作成（検証）したいという場合は、Amazon Aurora PostgreSQL Serverless でナレッジベース毎にスキーマを分けて管理する方法を紹介します。

注意点として、Amazon Aurora PostgreSQL Serverless を使用する際は、ネットワークリソース（VPC やゲートウェイなど）や踏み台サーバなど、様々なリソースが必要になります。これらのリソースがすでにある環境であれば安価に構築できますが、一から作成するとなった場合、最も安いケースとならない可能性があるためご注意下さい。また、Amazon OpenSearch Serverless を使用しない場合、選択できるデータソースが制限されるため、データソースには Amazon S3 しか使用しないという方が対象です。

Amazon Aurora PostgreSQL Serverless を利用するメリットと注意点

メリット

  • コスト: 従量課金で使用した分しか費用が発生しません。また、アイドル時に最小容量まで自動スケールダウンする設定にしておくと、使用していない時間は費用も発生しません。
  • 利便性: AWSのマネージドサービスであるため、Pinecone などを自前で運用するよりも運用負荷は軽減されます。
  • セキュリティ: VPC 内のプライベートサブネットに作成することができ、IAM によるアクセス制御も可能です。
  • 学習: pgvector エクステンションによる PostgreSQL の拡張であるため、PostgreSQL を使用したことがある方であれば難しくありません。

注意点

「はじめに」でも触れていますが、既存の環境がない場合はトータルコストは低くならない可能性があります。また、スケーリングはデータベース全体で行われるため、データの容量や負荷状況には注意する必要があります。本番で使用する場合は、ナレッジベース毎に独立したデータベースを用意することを検討して下さい。

ベクトルデータベースの作成

ナレッジベースの作成画面のベクトルデータベースから、「新しいベクトルストアをクイック作成」で Aurora を作成した場合、ここでは詳しくは述べませんがいくつか問題があります。そこで、本記事では別途 Aurora を作成しナレッジベースのベクトルデータベースとして使用します。

弊社のAWS環境にはすでに VPC とサブネットが存在し、自分の端末から AWS Direct Connect でこのサブネットのリソースに接続することができます。そのため、以下の手順はこの前提となっています。

サブネットグループの作成

  1. Aurora and RDS のダッシュボードのメニューから「サブネットグループ」を選択します。
  2. 「DB サブネットグループを作成」から、データベースを作成する VPC とサブネットを選択して、サブネットグループ（bedrock-groupとします）を作成して下さい。

Aurora PostgreSQL の作成

  1. 「データベースの作成」画面の設定値です。参考にして下さい。

    メニュー 設定項目 設定値 備考
    データベース作成方法を選択 標準作成
    エンジンのオプション エンジンのタイプ Aurora (PostgreSQL Compatible)
    エンジンのオプション 利用可能なバージョン 17.5 使用できるバージョンがAWSの公式ページに書かれています。検証目的であれば最新版で問題ありませんが、本番環境では互換性を確認し、安定版の利用を推奨します
    テンプレート 本番稼働用
    設定 DBクラスター識別子 bedrock-rag-db 任意
    DBインスタンス識別子 bedrock-rag-db01 任意
    マスターユーザ名 postgres 任意
    認証情報管理 セルフマネージド 一旦、自分でパスワードを設定しておいて、後で AWS Secrets Manager に変更します
    クラスターストレージ設定 設定オプション Aurora スタンダード 検証でしか使用しないのであれば、スタンダードでよいです
    インスタンスの設定 DBインスタンスクラス t3.db.medium テーブル作成までは、Tシリーズでよいですが、RDS Data API が使用できない点に注意が必要です。後で Serverless v2 に変更します
    可用性と耐久性 マルチ AZ 配置 Aurora レプリカを作成しない 検証目的であればシングル AZ でよいです
    接続 コンピューティングリソース EC2 コンピューティングリソースに接続しない 自分の端末から直接接続可能であれば、設定不要です
    ネットワークタイプ IPv4
    VPC bedrock-rag-vpc DBを作成するVPC
    DB サブネットグループ bedrock-group 作成したサブネットグループ
    パブリックアクセス なし 直接アクセスしたいのであれば「あり」にし、適切なセキュリティを設定して下さい
    VPC セキュリティグループ 新規作成 既存のセキュリティグループがあれば、それを適用してもかまいません
    新しい VPC セキュリティグループ名 bedrock-rag-db-sg インバウンドルールに自分の端末のサブネットを設定しています。各自適切なセキュリティを設定して下さい

データベースの作成

  1. Aurora PostgreSQL への接続
    以下は、pgAdmin からの接続例となります。PostgreSQL のクライアントであれば、お使いのものでかまいません。
    ※この時点では、RDS Data API を設定していないため、Aurora クエリエディタは使用できません。

    設定項目 設定値 備考
    ホスト名/アドレス bedrock-rag-db01.XXXXXX.ap-northeast-1.rds.amazonaws.com ライターインスタンスの「接続とセキュリティタブ」からエンドポイントをコピーします
    ポート番号 5432 変更していなければデフォルト
    管理用データベース postgres
    ユーザ名 postgres マスターユーザ名
    パスワード ***** 認証情報管理で自分で設定したパスワード

  2. ロールの作成

    --- 管理用のロール（任意）
CREATE ROLE pj_group WITH
  NOLOGIN
  NOSUPERUSER
  NOINHERIT
  CREATEDB
  CREATEROLE
  ;
COMMENT ON ROLE pj_group IS 'all project group role.';
 
--- 管理者（任意）
CREATE USER pj_admin WITH
  LOGIN
  ;
ALTER USER pj_admin ENCRYPTED PASSWORD '[pj_admin のパスワード]'; --- 実際のパスワードに置き換えてください
GRANT pj_group TO pj_admin;
COMMENT ON ROLE pj_admin IS 'project admin user.';
 
--- プロジェクトのロール（任意）
CREATE ROLE bedrock_pj WITH
  NOLOGIN
  NOSUPERUSER
  NOINHERIT
  NOCREATEDB
  NOCREATEROLE
  NOREPLICATION
;
COMMENT ON ROLE bedrock_pj IS 'bedrock_pj project role.';
 
--- bedrock_cs ユーザを作成（必須）
CREATE ROLE bedrock_cs WITH
  LOGIN
  ;
ALTER USER bedrock_cs ENCRYPTED PASSWORD '[bedrock_cs のパスワード]'; --- 実際のパスワードに置き換えてください
GRANT bedrock_pj TO bedrock_cs;
COMMENT ON ROLE bedrock_cs IS 'bedrock_cs role.';

    作成後、一旦接続を切断します。

  3. データベースの作成

    • Aurora PostgreSQL の接続情報の変更
      先ほど作成したロールの管理者（pj_admin）とパスワードを使用して、管理用データベース（postgres）に接続するように変更します。
      管理者を作成していない場合は、接続情報を変更する必要はありません。以下の手順でロールの切替も不要です。

    • DDLの実行
      データベース名は何でもよいですが、以下 bedrock とします。

      SET ROLE pj_group;

CREATE DATABASE bedrock
  WITH
  ENCODING = 'UTF8'
  TEMPLATE = template0
  LC_COLLATE = 'C'
  LC_CTYPE = 'C'
  CONNECTION LIMIT = -1
;
GRANT ALL ON DATABASE bedrock TO bedrock_pj;
REVOKE ALL ON DATABASE bedrock FROM pj_group;

RESET ROLE;

      一旦接続を切断します。

  4. pgvector の有効化

    • Aurora PostgreSQL の接続情報の変更
      必ずマスターユーザ（この例ではpostgres）で、作成したデータベース（bedrock）に接続します。

    • pgvector の有効化
      pgvector は、0.6.0 以降を使用する必要があります。

      CREATE EXTENSION IF NOT EXISTS vector;
SELECT extversion FROM pg_extension WHERE extname='vector';

      一旦接続を切断します。

スキーマの作成

  1. Aurora PostgreSQL の接続情報の変更
    bedrock_csユーザで、bedrockデータベースに接続します。

  2. DDLの実行
    AWSのナレッジベースでは、解析戦略をオプションで使用できます。検証するシステム（ナレッジベース）名と、解析戦略を組み合わせてスキーマ名にしておくとわかり易いかと思います。
    例）coresys_claude4: 基幹システムのナレッジベースに、解析戦略として Claude 4 を使用

    CREATE SCHEMA coresys_claude4;

テーブルの作成

  1. 使用する埋め込みモデルのベクトルの次元の確認
    「Amazon Bedrock > モデルカタログ」から Embeddings で使用できる埋め込みサイズ（以下の例では256,512,1024）を確認しておきます。
    埋め込みモデル

  2. DDLの実行
    coresys_claude4 スキーマに、bedrock_kb テーブルを作成します。ここで、事前に確認しておいた埋め込みモデルのベクトルの次元を設定します。別のナレッジベースを追加する場合も、スキーマが違うだけで、テーブル名・カラム名（ベクトルの次元の数値には注意する）は同じでよいです。

    CREATE TABLE coresys_claude4.bedrock_kb (
    id                 uuid PRIMARY KEY,
    embedding          vector(1024),     -- 埋め込みモデルのベクトルの次元を設定する
    chunks             text,
    metadata           json,
    custom_metadata    jsonb             -- カスタムメタデータ用
);

  3. インデックスの作成

    • embedding列にコサインインデックスを作成する
      精度を上げたい場合は、ef_constructionに256より大きな値を設定してもよいですが、構築コスト（メモリ・時間）が増加します。

      CREATE INDEX ON coresys_claude4.bedrock_kb USING hnsw (embedding vector_cosine_ops) WITH (ef_construction=256);

    • テキストデータをクエリするために Bedrock で使用できるインデックスを作成

      CREATE INDEX ON coresys_claude4.bedrock_kb USING gin (to_tsvector('simple', chunks));

    • カスタムメタデータをクエリするために Bedrock で使用できるインデックスを作成

      CREATE INDEX ON coresys_claude4.bedrock_kb USING gin (custom_metadata);

Aurora PostgreSQL の設定変更

  1. インスタンスの変更
    使用している Aurora PostgreSQL のインスタンスを Serverless v2 に変更します。リージョン別クラスターの変更から、設定を変更して下さい。

  2. Serverless v2 容量の設定
    最小キャパシティを0にすることで、コールドスタンバイにできます。利用者や利用時間が限られている場合は、コストを抑えるため0にすることをおすすめします。最大キャパシティは、使用状況をみて変更して下さい。非アクティブ後に一時停止する時間を設定することで、誰も使用していない場合は一時停止することができます（最小キャパシティを0にする必要がある）。

    最小キャパシティ (ACU) 最大キャパシティ (ACU) 非アクティブ後に一時停止
    0 ACU (0 GiB) 2 ACU (4 GiB) 00:30:00

  3. RDS Data API の有効化
    上記と同様に、リージョン別クラスターの変更から、RDS Data API を有効化します。

  4. AWS Secrets Manager の有効化
    上記と同様に、リージョン別クラスターの変更から、AWS Secrets Manager を有効化します。AWS Secrets Manager 有効化後も、引き続き PostgreSQL のクライアントから接続することができます。Aurora クエリエディタも使用できるようになりますが、使い慣れた PostgreSQL のクライアントから管理した方が運用しやすいと思います。

ナレッジベースの作成

IAMの作成

今回の主旨から外れるため、詳細は割愛します。ナレッジベースに関する他の記事を参照して下さい。
以下、注意点のみあげておきます。

  1. ポリシーの定義で注意すること

    • Embeddings で使用するモデルに対し、bedrock:InvokeModelが実行できること
    • 解析戦略で使用するモデルに対し、bedrock:GetInferenceProfile,bedrock:InvokeModelが実行できること
    • rerank を行う場合、rerank で使用するモデルに対し、bedrock:Rerankが実行できること
    • Amazon Aurora PostgreSQL Serverless のリソースは、クラスタのリソースを設定すること
    • 解析戦略で使用する出力バケットに対し、s3:PutObject,s3:DeleteObjectが実行できること
    • 作成した AWS Secrets Manager のリソースを設定すること

  2. ロールの定義で注意すること

    • bedrock.amazonaws.comとの信頼関係を設定すること

データソースの作成

データソースに、Amazon S3 を使用する前提とします。解析戦略を使用する場合は、出力先のバケットも必要になることも注意して下さい（データソースと同じバケットでオブジェクトを分けて管理しようとしましたが、うまくいきませんでした）。

データソースの保存先 マルチモーダルストレージの保存先
bedrock-knowledge-base-[アカウントID] bedrock-knowledge-base-destination-[アカウントID]

ベクトルストアでナレッジベースを作成

  1. ナレッジベースの詳細を指定
    IAM許可に作成したサービスロールを設定し、データソースに Amazon S3 を選択します。

  2. データソースを設定

    • S3のURI に、データソースの保存先のバケットを入力
      検証が目的の場合は、以下のようにオブジェクトとスキーマを関連づけておいた方がよいかと思います。ナレッジベース毎にバケットを作成しても問題ありませんし、ナレッジベース（スキーマ）間で同じデータソースを共有してもよいです。
      s3://bedrock-knowledge-base-[アカウントID]/coresys_claude4/
    • 解析戦略
      「Amazon Bedrock デフォルトパーサー」を選択しても動作上問題ありませんが、性能の問題上、「パーサーとしての基盤モデル」を選択することが必須です。
    • 解析用の基盤モデルを選択
      ドキュメントをベクトル化する際に費用が発生しますが、必要経費と割り切ってできる限り性能のよいモデルを選択して下さい。モデルを変更すると再ベクトル化の処理が必要となります。
    • チャンキング戦略
      デフォルトチャンキングでよいです。

  3. データストレージと処理を設定

    • 埋め込みモデル
      事前に確認した埋め込みモデルを選択します。「ベクトルの次元」が、作成したテーブルのembeddingの値と一致する必要があります。

    • ベクトルデータベース
      ベクトルストアの作成方法から、「既存のベクトルストアを使用」を選択し、ベクトルストアのリストからAuroraを選択します。以下、Amazon Aurora DB の設定を行います。

      設定項目 設定値 備考
      Amazon Aurora DB クラスター ARN arn:aws:rds:ap-northeast-1:アカウントID:cluster:bedrock-rag-db DBクラスター識別子のARNを設定します
      データベース名 bedrock 作成したデータベース名
      テーブル名 coresys_claude4.bedrock_kb スキーマ名.テーブル名 を設定します
      シークレット ARN arn:aws:secretsmanager:ap-northeast-1:アカウントID:secret:rds!cluster-xxx-xxx-xxx-xxx-xxx AWS Secrets Manager のARNを設定します

    • インデックスフィールドマッピング
      作成したテーブル（bedrock_kb）の項目を設定します。

      設定項目 設定値
      ベクトルフィールド名 embedding
      テキストフィールド名 chunks
      Bedrock マネージドメタデータフィールド metadata
      カスタムメタデータ custom_metadata
      プライマリキー id

      テーブル名以外は、スキーマが違っても同じ設定となります。

    • マルチモーダルストレージの保存先

      s3://bedrock-knowledge-base-destination-[アカウントID]/coresys_claude4/

  4. 確認して作成
    設定を確認し、問題なければ作成します。ナレッジベースが正常に作成されたら、「同期」を行って、ベクトル化が実行されることを確認して下さい。

ナレッジベースのテスト

  • Amazon Bedrock のメニューのナレッジベースから、作成したナレッジベースを選択します。
  • 「ナレッジベースをテスト」から、意図する結果が返却されるか確認して下さい。

おわりに

本記事では、Amazon Aurora PostgreSQL Serverless v2 を使用して、複数のナレッジベースを同じデータベースで管理する方法を解説しました。AWSのナレッジベースを導入するにあたり、複数のモデルで解析戦略を含めて検証したいという場合、Amazon OpenSearch Serverless を採用するよりも安価に構築することができます。また、最初にデータベースを作成すれば、後はナレッジベース毎にスキーマとテーブルを追加するだけで、ベクトルデータベースの追加費用なしに運用できるのもメリットだと思います。

平田機工株式会社 情報システム
平田機工株式会社 情報システムPublication

平田機工株式会社 情報システムの技術ブログです。

Discussion