멀티 리전 고가용성

고가용성 배포

us 멀티 리전에서 에이전트 검색 서비스를 사용하면 더 강력한 서빙 가용성 SLA와 리전 서비스 중단 시에도 지속적인 업타임의 이점을 누릴 수 있습니다.

us 멀티 리전은 에이전트 검색의 나머지 부분과 동일한 API를 제공하지만 몇 가지 제한사항이 있습니다. us 멀티 리전 위치의 데이터는 미국 본토 전역의 리전에 복제되며 us 멀티 리전의 모든 활성 색인에는 이러한 각 리전에 프로비저닝된 중복 서버가 있습니다. 정상적인 운영 조건에서는 네트워크 클라이언트의 지연 시간이 최적인 리전에서 쿼리가 제공됩니다. 서비스 중단 또는 서빙 용량 손실이 발생하면 Google 부하 분산기가 쿼리를 가장 가까운 사용 가능한 리전으로 리디렉션합니다. 부하 분산 및 복제의 설정 및 유지보수는 에이전트 검색에서 전적으로 관리합니다.

참고: 고가용성으로 에이전트 검색을 지원하는 데 필요한 하드웨어 및 엔지니어링 리소스의 투입을 고려할 때 고객 프로젝트는 구체적으로 검토되고 허용 목록에 추가된 후에만 고가용성 멀티 리전에 온보딩될 수 있습니다. 고가용성 멀티 리전에 대한 액세스 권한을 요청하려면 연결된 요청 양식을 작성하세요.

온보딩

고가용성 멀티 리전에 액세스하려면 허용 목록에 추가해 달라고 요청해야 합니다.

고가용성 멀티 리전에 액세스할 수 있도록 프로젝트가 허용 목록에 추가되었다는 확인을 받은 후 us 멀티 리전 위치에 새 컬렉션, 데이터 객체, 색인을 만들 수 있습니다. 표준 Agent Retrieval API 참고 리소스를 따르고, 일반적으로 단일 리전 (예: us-central1 또는 europe-central2)을 지정하는 위치에 us를 대체합니다.

us 멀티 리전에서 업로드된 모든 데이터와 수행된 작업은 향상된 복제, 중복성, 더 높은 가용성의 이점을 누릴 수 있습니다.

결제

멀티 리전 위치의 청구 요금은 표준 단일 리전보다 높으며, 이는 복제 비용 증가와 운영 우선순위가 더 높음을 반영합니다.

자세한 내용은 가격 책정을 참조하세요.

제한사항

스토리지 최적화가 구현되지 않았습니다. 성능 최적화 등급 색인만 멀티 리전 위치에 배포할 수 있습니다.

멀티 리전 위치에서 정규화되지 않은 임베딩 벡터에 대한 색인에 대한 SearchDataObjects 호출은 예기치 않은 거리 측정항목을 보고할 수 있습니다. 이러한 색인에서 데이터 포인트를 검색하고 순위를 매기는 작업은 올바르게 수행됩니다 (근사 최근접 이웃 색인의 제한사항 내에서). 항상 정규화된 임베딩 벡터를 제공하거나 자동 임베딩 생성에 의존하는 것이 좋습니다.

멀티 리전 위치에서는 DOT_PRODUCT_DISTANCE만 지원됩니다.

멀티 리전 위치에서는 희소 임베딩이 지원되지 않습니다. 특정 필드에 특정 토큰이 있어야 하는 벡터 검색 요청의 경우 요청의 필터 표현식에 $search 연산자를 사용할 수 있습니다.

멀티 리전 위치에서는 CreateIndex 및 UpdateIndex 요청의 Index.dedicated_infrastructure.autoscaling_spec 필드가 사용되지 않습니다.

멀티 리전 위치에서는 SearchDataObjectsRequests의 SearchHint.IndexHint.dense_scann_params 필드가 사용되지 않습니다. 멀티 리전 ANN 색인은 약 95% 의 재현율을 제공하도록 조정되지만 재현율은 데이터의 세부사항에 따라 달라질 수 있습니다.

리전 배포에서 마이그레이션

리전 에이전트 검색 컬렉션에 데이터가 있는 경우 다음 상위 수준 워크플로를 사용하여 해당 데이터를 us 위치에 클론할 수 있습니다.

  • 컬렉션을 호스팅하는 리전의 버킷으로 컬렉션 데이터를 내보내고 etag를 삭제합니다.
  • 버킷에서 us 위치에 호스팅된 컬렉션으로 가져옵니다.

시작하기 전에

필요한 항목:

  • 내보내기 스테이징 영역으로 사용할 소스 리전의 버킷입니다.
  • gcloud CLI 설치.
  • 소스 컬렉션에 대한 IAM 읽기 권한, 대상에 대한 쓰기 권한, 버킷에 대한 읽기 및 쓰기 권한
  • 소스와 동일한 스키마를 사용하여 us에 이미 생성된 대상 컬렉션입니다.

PROJECT_ID: 마이그레이션할 컬렉션이 포함된 프로젝트입니다. 다음 명령어는 소스 및 대상 프로젝트가 동일하다고 가정합니다.

SOURCE_LOCATION: 소스 컬렉션의 위치입니다(예: us-central1).

SOURCE_COLLECTION: 마이그레이션할 컬렉션의 이름입니다.

STAGING_BUCKET: 컬렉션 데이터를 내보낼 버킷 내 디렉터리의 경로입니다(예: gs://your-bucket-id).

단계

각 스니펫은 복사하여 붙여넣을 수 있습니다. 각 블록 상단의 자리표시자를 프로젝트, 소스 위치, 컬렉션, 버킷과 관련된 값으로 바꿉니다.

1. 소스 리전에서 내보내기

cat > request.json <<EOF
{
  "gcsDestination": {
    "exportUri": "STAGING_BUCKET/export/",
    "format": "JSONL"
  },
  "field_filter": {
    "excluded_fields": {
      "fields": ["etag"]
    }
  }
}
EOF

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d @request.json \
  "https://vectorsearch.googleapis.com/v1/projects/PROJECT_ID/locations/SOURCE_LOCATION/collections/SOURCE_COLLECTION:exportDataObjects"

응답에는 projects/.../locations/us-central1/operations/operation-...과 같은 작업 이름이 포함됩니다. "done": true까지 폴링합니다.

EXPORT_OPERATION_NAME

gcloud vector-search operations describe "EXPORT_OPERATION_NAME" \
  --location="SOURCE_LOCATION"

2. 미국으로 수입

DEST_COLLECTION: 마이그레이션 후 컬렉션 이름입니다 (원래 이름과 동일할 수 있음).

gcloud vector-search collections import-data-objects "DEST_COLLECTION" \
  --location="us" \
  --project="PROJECT_ID" \
  --gcs-import-contents-uri="STAGING_BUCKET/export/" \
  --gcs-import-error-uri="STAGING_BUCKET/import-errors/" \
  --gcs-import-output-uri="STAGING_BUCKET/import-output/" \
  --async

내보내기와 동일한 방식으로 반환된 작업을 폴링합니다.

IMPORT_OPERATION_NAME

gcloud vector-search operations describe "IMPORT_OPERATION_NAME" \
  --location="us"

3. 가져오기 확인

  • gs://your-bucket-uscentral1/import-errors/에서 거부된 레코드가 있는지 확인합니다.
  • 소스와 대상 간의 레코드 수를 비교합니다.
  • 두 데이터베이스에 대해 알려진 쿼리를 몇 개 실행하고 결과를 비교합니다.