Vertex AI 및 PostgreSQL용 AlloyDB를 사용하는 RAG 지원 생성형 AI 애플리케이션을 위한 인프라

이 문서에서는 검색 증강 생성(RAG)으로 생성형 인공지능(AI) 애플리케이션을 실행하기 위한 인프라 설계에 사용할 수 있는 참조 아키텍처를 제공합니다. 이 문서의 주요 대상에는 생성형 AI 애플리케이션 개발자 및 관리자와 클라우드 설계자가 포함됩니다. 이 문서는 AI, 머신러닝(ML), 대규모 언어 모델(LLM) 개념에 대한 기본 이해가 있다는 가정 하에 작성되었습니다. 이 문서에서는 생성형 AI 애플리케이션의 설계 및 개발 방법에 대한 안내를 제공하지 않습니다.

아키텍처

다음 다이어그램은 Google Cloud에서 RAG 지원 생성형 AI 애플리케이션의 아키텍처를 간략하게 보여줍니다.

이 아키텍처에는 다음과 같이 상호 연결된 구성요소가 포함됩니다.

구성요소	목적	상호작용 수
데이터 수집 하위 시스템	RAG 기능을 사용 설정하는 데 사용되는 외부 데이터를 준비 및 처리합니다.	데이터 수집 하위 시스템이 데이터베이스 계층을 통해 아키텍처에 있는 다른 하위 시스템과 상호작용합니다.
서빙 하위 시스템	생성형 AI 애플리케이션과 사용자 사이의 요청-응답 흐름을 처리합니다.	서빙 하위 시스템이 데이터베이스 계층을 통해 데이터 수집 하위 시스템과 상호작용합니다.
품질 평가 하위 시스템	서빙 하위 시스템이 생성하는 응답의 품질을 평가합니다.	품질 평가 하위 시스템이 서빙 하위 시스템과 직접 상호작용하고 데이터베이스 계층을 통해 데이터 수집 하위 시스템과 상호작용합니다.
데이터베이스	다음 데이터를 저장합니다. 프롬프트 RAG에 사용되는 데이터의 벡터화된 임베딩 데이터 수집 및 품질 평가 하위 시스템에서 서버리스 작업의 구성	아키텍처의 모든 하위 시스템이 데이터베이스와 상호작용합니다.

다음 다이어그램은 아키텍처를 세부적으로 보여줍니다.

다음 섹션에서는 아키텍처의 각 하위 시스템 내에서 구성 요소 및 데이터 흐름에 대해 자세히 설명합니다.

데이터 수집 하위 시스템

데이터 수집 하위 시스템은 파일, 데이터베이스, 스트리밍 서비스와 같은 외부 소스에서 데이터를 수집합니다. 업로드된 데이터에는 품질 평가를 위한 프롬프트가 포함됩니다. 데이터 수집 하위 시스템은 아키텍처에서 RAG 기능을 제공합니다. 다음 다이어그램은 아키텍처에서 데이터 수집 하위 시스템의 세부정보를 보여줍니다.

데이터 수집 흐름의 단계는 다음과 같습니다.

1. 데이터가 Cloud Storage 버킷에 업로드됩니다. 데이터 소스는 애플리케이션 사용자가 데이터를 업로드하거나, 데이터베이스에서 데이터를 가져오거나, 데이터를 스트리밍하는 것일 수 있습니다.
2. 데이터가 업로드되면 알림이 Pub/Sub 주제로 전송됩니다.
3. Pub/Sub가 업로드된 데이터를 처리하기 위해 Cloud Run 작업을 트리거합니다.
4. Cloud Run이 PostgreSQL용 AlloyDB 데이터베이스에 저장된 구성 데이터를 사용하여 작업을 시작합니다.
5. Cloud Run 작업이 Document AI를 사용해서 추가 처리를 위해 데이터를 준비합니다. 예를 들어 준비 작업에는 데이터 파싱, 필요한 형식으로 데이터 변환, 데이터 청크 분할이 포함될 수 있습니다.

6. Cloud Run 작업이 텍스트용 Vertex AI 임베딩 모델을 사용하여 수집된 데이터의 벡터화된 임베딩을 만듭니다.

7. Cloud Run은 pgvector 확장 프로그램이 사용 설정된 PostgreSQL용 AlloyDB 데이터베이스에 임베딩을 저장합니다. 다음 섹션에 설명된 대로 서빙 하위 시스템은 사용자 요청을 처리할 때 벡터 데이터베이스의 임베딩을 사용하여 관련 도메인 특정 데이터를 검색합니다.

서빙 하위 시스템

서빙 하위 시스템은 생성형 AI 애플리케이션과 사용자 사이의 요청-대답 흐름을 처리합니다. 다음 다이어그램은 아키텍처에서 서빙 하위 시스템의 세부정보를 보여줍니다.

다음은 서빙 하위 시스템에서 요청-응답 흐름의 단계입니다.

1. 사용자가 프런트엔드(예: 챗봇 또는 모바일 앱)를 통해 생성형 AI 애플리케이션에 요청을 제출합니다.

2. 생성형 AI 애플리케이션이 자연어 요청을 임베딩으로 변환합니다.

3. 애플리케이션이 RAG 방식의 검색 부분을 완료합니다.

   1. 애플리케이션이 데이터 수집 하위 시스템에서 유지 보수되는 PostgreSQL용 AlloyDB 벡터 저장소에서 임베딩에 대한 시맨틱 검색을 수행합니다. 시맨틱 검색은 텍스트 콘텐츠 대신 프롬프트의 인텐트를 기반으로 임베딩을 찾는 데 도움이 됩니다.
   2. 애플리케이션은 일치하는 임베딩을 기반으로 검색된 원시 데이터와 원래 요청을 조합하여 컨텍스트와 연결된 프롬프트를 만듭니다.

4. 애플리케이션이 컨텍스트와 연결된 프롬프트를 Vertex AI에서 실행되는 LLM 추론 스택으로 보냅니다.

5. LLM 추론 스택은 기반 LLM 또는 커스텀 LLM일 수 있는 생성형 AI LLM을 사용하고 제공된 컨텍스트로 제한되는 응답을 생성합니다.

   1. 애플리케이션이 요청-응답 활동의 로그를 Cloud Logging에 저장할 수 있습니다. Cloud Monitoring을 사용하여 모니터링에 대해 로그를 보고 사용할 수 있습니다. Google은 로그 데이터를 액세스하거나 사용하지 않습니다.
   2. 애플리케이션이 오프라인 분석을 위해 응답을 BigQuery에 로드합니다.

6. 애플리케이션이 책임감 있는 AI 필터를 사용하여 응답을 검사합니다.

7. 애플리케이션이 검사된 응답을 프론트엔드를 통해 사용자에게 보냅니다.

품질 평가 하위 시스템

다음 다이어그램은 아키텍처에서 품질 평가 하위 시스템의 세부정보를 보여줍니다.

품질 평가 하위 시스템은 요청이 수신되었을 때 다음을 수행합니다.

1. Pub/Sub가 Cloud Run 작업을 트리거합니다.
2. Cloud Run이 PostgreSQL용 AlloyDB 데이터베이스에 저장된 구성 데이터를 사용하여 작업을 시작합니다.
3. Cloud Run 작업이 PostgreSQL용 AlloyDB 데이터베이스에서 평가 프롬프트를 가져옵니다. 프롬프트는 이전에 데이터 수집 하위 시스템에 의해 데이터베이스로 업로드되었습니다.

4. Cloud Run 작업은 평가 프롬프트를 사용하여 서빙 하위 시스템이 생성하는 응답의 품질을 평가합니다.

   이 평가의 출력은 사실에 기반한 정확성 및 관련성과 같은 측정항목의 평가 점수로 구성됩니다.

5. Cloud Run은 평가 점수와 평가된 프롬프트 및 응답을 이후 분석을 위해 BigQuery에 로드합니다.

사용 제품

다음은 위 아키텍처에 사용되는 모든 Google Cloud 제품을 요약한 것입니다.

• Vertex AI: ML 모델 및 AI 애플리케이션을 학습 및 배포하고 AI 기반 애플리케이션에서 사용하도록 LLM을 맞춤설정할 수 있게 해주는 ML 플랫폼입니다.
• Cloud Run: Google의 확장 가능한 인프라에서 직접 컨테이너를 실행할 수 있게 해주는 서버리스 컴퓨팅 플랫폼입니다.
• BigQuery: 머신러닝 지리 정보 분석 및 비즈니스 인텔리전스와 같은 기본 제공 기능으로 데이터를 관리 및 분석하는 데 도움이 되는 엔터프라이즈 데이터 웨어하우스입니다.
• Cloud Storage: 다양한 데이터 유형에 적합한 저비용, 무제한 객체 스토어입니다. Google Cloud내부 및 외부에서 데이터에 액세스할 수 있고 중복성을 위해 여러 위치에 복제됩니다.
• PostgreSQL용 AlloyDB: 하이브리드 트랜잭션 및 분석 처리를 비롯한 가장 까다로운 워크로드를 위해 설계된 완전 관리형 PostgreSQL 호환 데이터베이스 서비스입니다.
• Document AI: 문서에서 비정형 데이터를 가져와서 정형 데이터로 변환하는 문서 처리 플랫폼입니다.
• Pub/Sub: 메시지 생성 서비스를 메시지 처리 서비스와 분리하는 비동기식의 확장 가능한 메시징 서비스입니다.
• Cloud Logging: 스토리지, 검색, 분석, 알림을 지원하는 실시간 로그 관리 시스템입니다.
• Cloud Monitoring: 애플리케이션 및 인프라의 성능, 가용성, 상태에 관한 정보를 제공하는 서비스입니다.

사용 사례

RAG는 LLM에서 생성되는 출력의 품질을 개선하는 데 효과적인 기법입니다. 이 섹션에서는 RAG 지원 생성형 AI 애플리케이션을 사용할 수 있는 사용 사례에 대한 예시를 제공합니다.

맞춤화된 제품 추천

한 온라인 쇼핑 사이트에서 LLM 기반 챗봇을 사용하여 고객의 제품 검색을 도와주거나 쇼핑 관련 도움을 제공하려고 합니다. 사용자의 질문은 사용자의 구매 행동 및 웹 사이트 상호작용 패턴에 대한 과거 데이터를 사용하여 증강될 수 있습니다. 이러한 데이터에는 구조화되지 않은 데이터 스토어에 저장된 사용자 리뷰와 피드백이 포함되거나 웹 분석 데이터 웨어하우스에 저장된 검색 관련 측정항목이 포함될 수 있습니다. 그런 다음 LLM이 증강된 질문을 처리해서 사용자에게 더 매력적이고 설득력 있게 보이는 맞춤화된 응답을 생성합니다.

임상 지원 시스템

병원의 의사는 적절한 치료와 처방을 결정하기 위해 환자의 의료 상태를 빠르게 분석하고 진단해야 합니다. Med-PaLM과 같은 의료용 LLM을 사용하는 생성형 AI 애플리케이션을 활용해서 임상 진단 과정 중 의사를 지원할 수 있습니다. 애플리케이션이 생성하는 응답은 병원의 전자 건강 기록(EHR) 데이터베이스 또는 PubMed와 같은 외부 기술 자료의 데이터와 함께 의사의 프롬프트를 컨텍스트에 맞게 조정함으로써 과거 환자 기록에서 근거를 확보할 수 있습니다.

효율적인 법률 조사

생성형 AI 기반의 법률 조사를 통해 변호사는 대량의 법령과 판례를 빠르게 검색하여 관련 법적 선례를 확인하거나 복잡한 법률 개념을 요약할 수 있습니다. 이러한 조사의 결과는 법률 회사의 독점 계약 모음, 과거 법률 소통 자료 및 내부 사건 기록에서 검색된 데이터로 변호사의 프롬프트를 증강함으로써 향상될 수 있습니다. 이러한 설계 접근 방식은 생성된 응답이 변호사의 전문 법률 도메인과 관련이 있도록 보장합니다.

설계 대안

이 섹션에서는 Google Cloud에서 RAG 지원 생성형 AI 애플리케이션에 대해 고려할 수 있는 대체 설계 접근 방식을 보여줍니다.

완전 관리형 벡터 검색

완전 관리형 벡터 검색 제품을 사용하는 아키텍처가 필요한 경우 대규모 벡터 검색을 위해 최적화된 서빙 인프라를 제공하는 Vertex AI 및 벡터 검색을 사용할 수 있습니다. 자세한 내용은 Vertex AI 및 벡터 검색을 사용하는 RAG 지원 생성형 AI 애플리케이션을 위한 인프라를 참조하세요.

오픈소스 도구 및 모델

오픈소스 도구 및 모델인 Ray, Hugging Face, LangChain을 사용하여 RAG 지원 생성형 AI 애플리케이션을 빠르게 빌드하고 배포하려면 GKE 및 Cloud SQL을 사용하는 RAG 지원 생성형 AI 애플리케이션을 위한 인프라를 참조하세요.

기타 옵션

Google Cloud에서 생성형 AI 애플리케이션에 사용할 수 있는 기타 인프라 옵션, 지원되는 모델, 그라운딩 기법에 대한 자세한 내용은 생성형 AI 애플리케이션을 위한 모델 및 인프라 선택을 참조하세요.

설계 고려사항

이 섹션에서는 Google Cloud 에서 보안 및 규정 준수, 안정성, 비용, 성능 측면의 특정 요구사항을 충족하는 RAG 지원 생성형 AI 아키텍처를 개발하는 데 도움이 되는 안내를 제공합니다. 이 섹션의 안내는 일부일 뿐 모든 내용을 포함하지는 않습니다. 사용되는 생성형 AI 애플리케이션과 Google Cloud 제품 및 기능의 특정 요구사항에 따라 추가적인 설계 요소와 장단점을 고려해야 할 수 있습니다.

보안 및 규정 준수

이 섹션에서는 Google Cloud 에서 보안 및 규정 준수 요구사항을 충족하는 RAG 지원 생성형 AI 애플리케이션을 설계 및 빌드할 때 고려할 사항에 대해 설명합니다.

제품	설계 고려사항
Vertex AI	Vertex AI는 데이터 상주, 데이터 암호화, 네트워크 보안, 액세스 투명성에 대한 요구사항을 충족하기 위해 사용할 수 있는 Google Cloud 보안 제어를 지원합니다. 자세한 내용은 Vertex AI의 보안 제어 및 생성형 AI의 보안 제어를 참조하세요.
Cloud Run	기본적으로 Cloud Run은 Google-owned and Google-managed encryption key를 사용하여 데이터를 암호화합니다. 사용자가 제어하는 키를 사용해서 컨테이너를 보호하려면 고객 관리 암호화 키(CMEK)를 사용하면 됩니다. 자세한 내용은 고객 관리 암호화 키 사용을 참조하세요. 승인된 컨테이너 이미지만 Cloud Run 작업에 배포되도록 하려면 Binary Authorization을 사용하면 됩니다. Cloud Run은 데이터 상주 요구사항을 충족하도록 도와줍니다. Cloud Run 컨테이너 인스턴스는 선택한 리전 내에서 실행됩니다.
PostgreSQL용 AlloyDB	기본적으로 PostgreSQL용 AlloyDB는 Google-owned and Google-managed encryption keys를 사용하여 암호화됩니다. 사용자가 제어하고 관리하는 암호화 키를 사용해야 하는 경우에는 CMEK를 사용하면 됩니다. 자세한 내용은 CMEK 정보를 참조하세요. PostgreSQL용 AlloyDB 데이터베이스에서 데이터 무단 반출 위험을 줄이려면 VPC 서비스 제어를 사용하여 서비스 경계를 만들 수 있습니다. 기본적으로 PostgreSQL용 AlloyDB 인스턴스는 SSL을 사용하는 연결만 허용합니다. PostgreSQL용 AlloyDB에 대한 연결을 추가로 보호하려면 PostgreSQL용 AlloyDB 인증 프록시 커넥터를 사용하면 됩니다. 인증 프록시 커넥터는 Identity and Access Management(IAM) 기반 연결 승인을 제공하고 256비트 AES 암호화를 지원하는 TLS 1.3 연결을 사용해서 클라이언트 및 서버 ID를 확인하고 데이터 트래픽을 암호화합니다. 자세한 내용은 PostgreSQL용 AlloyDB 인증 프록시 정보를 참조하세요. Java, Python 또는 Go를 사용하여 만든 연결의 경우 인증 프록시 커넥터 대신 적절한 언어 커넥터를 사용합니다. PostgreSQL용 AlloyDB는 데이터 상주 요구사항을 충족하도록 도와줍니다. 데이터는 사용자가 지정한 리전 내에 저장 또는 복제됩니다.
BigQuery	BigQuery는 데이터 액세스 제어, 민감한 정보 보호, 데이터 정확성 및 일관성 보장을 위해 사용할 수 있는 여러 기능을 제공합니다. 자세한 내용은BigQuery의 데이터 거버넌스 소개를 참조하세요. BigQuery는 데이터 상주 요구사항을 충족할 수 있게 도와줍니다. 데이터는 지정한 리전 내에 저장됩니다.
Cloud Storage	기본적으로 Cloud Storage에 저장되는 데이터는 Google-owned and Google-managed encryption keys를 사용하여 암호화됩니다. 필요한 경우 CMEK를 사용하거나 고객 제공 암호화 키(CSEK)와 같은 외부 관리 방법을 사용하여 관리하는 자체 키를 사용할 수 있습니다. 자세한 내용은 데이터 암호화 옵션을 참조하세요. Cloud Storage는 버킷과 객체에 액세스할 수 있는 권한을 사용자에게 부여하기 위해 IAM 및 액세스 제어 목록(ACL)의 두 가지 방법을 지원합니다. 대부분의 경우 버킷 및 프로젝트 수준에서 권한을 부여할 수 있는 IAM을 사용하는 것이 좋습니다. 자세한 내용은 액세스 제어 개요를 참조하세요. Cloud Storage를 통해 데이터 수집 하위 시스템에 로드하는 데이터에는 민감한 정보가 포함될 수 있습니다. 이러한 데이터를 보호하기 위해서는 Sensitive Data Protection을 사용하여 데이터를 검색, 분류, 익명화할 수 있습니다. 자세한 내용은 Cloud Storage에 Sensitive Data Protection 사용을 참조하세요. Cloud Storage는 데이터 상주 요구사항을 충족하도록 도와줍니다. 데이터는 사용자가 지정한 리전 내에 저장 또는 복제됩니다.
Pub/Sub	기본적으로 Pub/Sub는 Google-owned and Google-managed encryption keys를 사용하여 저장 중 및 전송 중인 모든 메시지를 암호화합니다. Pub/Sub에서는 애플리케이션 계층에서 메시지 암호화를 위해 CMEK를 사용할 수 있습니다. 자세한 내용은 메시지 암호화 구성을 참조하세요. 데이터 상주 요구사항이 있는 경우 메시지 데이터가 특정 위치에 저장되도록 하려면 메시지 스토리지 정책을 구성하면 됩니다.
Document AI	기본적으로 저장 데이터는 Google 관리 암호화 키를 사용하여 암호화됩니다. 사용자가 제어하고 관리하는 암호화 키를 사용해야 하는 경우에는 CMEK를 사용하면 됩니다. 자세한 내용은 Document AI 보안 및 규정 준수를 참조하세요.
Cloud Logging	관리자 활동 감사 로그는 이 참조 아키텍처에 사용되는 모든 Google Cloud 서비스에 대해 기본적으로 사용 설정됩니다. 이러한 로그는 Google Cloud 리소스의 구성 또는 메타데이터를 수정하는 API 호출 또는 기타 작업을 기록합니다. 데이터 액세스 감사 로그는 기본적으로 BigQuery에 대해 사용 설정됩니다. 이 아키텍처에 사용되는 다른 서비스에 대해 데이터 액세스 감사 로그를 사용 설정할 수 있습니다. 로그를 사용하면 리소스의 구성 또는 메타데이터를 읽는 API 호출 또는 사용자 제공 리소스 데이터 생성, 수정, 읽기에 대한 사용자 요청을 추적할 수 있습니다. 데이터 상주 요구사항을 충족하기 위해 지정한 리전에 로그 데이터를 저장하도록 Cloud Logging을 구성할 수 있습니다. 자세한 내용은 로그 리전화를 참조하세요.

AI 및 ML 워크로드와 관련된 보안 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 보안을 참조하세요.

안정성

이 섹션에서는Google Cloud에서 RAG 지원 생성형 AI 애플리케이션의 신뢰할 수 있는 인프라를 빌드하고 운영할 때 고려해야 하는 디자인 요소에 대해 설명합니다.

제품	설계 고려사항
Cloud Run	Cloud Run은 리전 서비스입니다. 데이터는 리전 내 여러 영역에 동기식으로 저장됩니다. 트래픽은 영역 간에 자동으로 부하 분산됩니다. 영역 중단이 발생해도 Cloud Run 작업이 계속 실행되고 데이터가 손실되지 않습니다. 리전 중단이 발생하면 Google에서 중단 문제가 해결될 때까지 Cloud Run 작업 실행이 중지됩니다. 개별 Cloud Run 작업 또는 태스크는 실패할 수 있습니다. 이러한 실패를 처리하려면 태스크 재시도 및 체크포인트 지정을 사용할 수 있습니다. 자세한 내용은 작업 재시도 및 체크포인트 권장사항을 참조하세요.
PostgreSQL용 AlloyDB	기본적으로 PostgreSQL용 AlloyDB는 자동 장애 조치가 포함된 고가용성(HA)을 제공합니다. 기본 인스턴스에는 리전 내 2개의 서로 다른 영역에 있는 중복 노드가 포함됩니다. 이러한 중복성은 영역 중단이 발생하더라도 클러스터가 운영되도록 보장합니다. 리전 중단 시 복구를 계획하려면 리전 간 복제를 사용하면 됩니다.
BigQuery	BigQuery에 로드하는 데이터는 지정된 리전 내의 2개 영역에 동기식으로 저장됩니다. 이러한 중복성은 영역 중단이 발생했을 때 데이터가 손실되지 않도록 보장하는 데 도움이 됩니다. BigQuery의 신뢰성 기능에 대한 자세한 내용은 신뢰성 이해를 참조하세요.
Cloud Storage	리전, 이중 리전, 멀티 리전의 세 가지 위치 유형 중 하나로 Cloud Storage 버킷을 만들 수 있습니다. 리전 버킷에 저장된 데이터는 리전 내 여러 영역에 동기식으로 복제됩니다. 더 높은 가용성을 위해서는 데이터가 리전 간에 동기식으로 복제되는 이중 리전 또는 멀티 리전 버킷을 사용하면 됩니다.
Pub/Sub	메시지 트래픽에서 일시적인 급증을 관리하려면 게시자 설정에서 흐름 제어를 구성하면 됩니다. 실패한 게시를 처리하려면 필요에 따라 재시도-요청 변수를 조정합니다. 자세한 내용은 재시도 요청을 참조하세요.
Document AI	Document AI는 리전 서비스입니다. 데이터는 리전 내 여러 영역에 동기식으로 저장됩니다. 트래픽은 영역 간에 자동으로 부하 분산됩니다. 영역 중단이 발생해도 데이터가 손실되지 않습니다. 리전 중단이 발생하면 Google이 중단을 해결할 때까지 Document AI를 사용할 수 없습니다.

AI 및 ML 워크로드와 관련된 안정성 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 안정성을 참조하세요.

비용 최적화

이 섹션에서는 Google Cloud에서 RAG 지원 생성형 AI 애플리케이션을 설정하고 운영하는 비용을 최적화할 수 있게 도와줍니다.

제품	설계 고려사항
Cloud Run	Cloud Run 작업을 만들 때 컨테이너 인스턴스에 할당할 메모리 및 CPU 양을 지정합니다. 비용을 줄이려면 기본(최소) CPU 및 메모리 할당으로 시작합니다. 성능을 향상시키려면 CPU 한도 및 메모리 한도를 구성하여 할당을 늘릴 수 있습니다. Cloud Run 작업의 CPU 및 메모리 요구사항을 예측할 수 있으면 약정 사용 할인을 통해 비용을 절약할 수 있습니다. 자세한 내용은 Cloud Run 악정 사용 할인을 참조하세요.
PostgreSQL용 AlloyDB	기본적으로 PostgreSQL용 AlloyDB 클러스터의 기본 인스턴스는 고가용성(HA)을 지원합니다. 인스턴스에는 활성 노드와 대기 노드가 있습니다. 활성 노드가 실패하면 PostgreSQL용 AlloyDB가 대기 노드로 자동으로 장애 조치를 수행합니다. 데이터베이스에 HA가 필요하지 않으면 클러스터의 기본 인스턴스를 베이직 인스턴스로 지정하여 비용을 줄일 수 있습니다. 베이직 인스턴스는 영역 중단 시 계속 실행되지 않으며 유지보수 작업 중 다운타임이 더 깁니다. 자세한 내용은 베이직 인스턴스를 사용하여 비용 감소를 참조하세요. PostgreSQL용 AlloyDB 인스턴스의 CPU 및 메모리 요구사항을 예측할 수 있으면 약정 사용 할인을 통해 비용을 절약할 수 있습니다. 자세한 내용은 PostgreSQL용 AlloyDB 약정 사용 할인을 참조하세요.
BigQuery	BigQuery를 사용하면 쿼리를 실행하기 전에 쿼리 비용을 예상할 수 있습니다. 쿼리 비용을 최적화하려면 스토리지 및 쿼리 계산을 최적화해야 합니다. 자세한 내용은 비용 예측 및 제어를 참조하세요.
Cloud Storage	데이터 수집 하위 시스템에 데이터를 로드하기 위해 사용되는 Cloud Storage 버킷에 대해 워크로드의 데이터 보관 및 액세스 빈도 요구사항에 따라 적합한 스토리지 클래스를 선택합니다. 예를 들어 표준 스토리지 클래스를 선택하고 객체 수명 주기 관리를 사용해서 객체를 저비용 스토리지 클래스로 다운그레이드하거나 설정한 조건에 따라 객체를 삭제하여 스토리지 비용을 관리할 수 있습니다.
Cloud Logging	로그 저장 비용을 관리하려면 다음을 수행하면 됩니다. 불필요한 로그 항목을 제외하거나 필터링하여 로그 볼륨을 줄입니다. 자세한 내용은 제외 필터를 참조하세요. 로그 항목이 보관되는 기간을 줄입니다. 자세한 내용은 커스텀 보관 구성을 참조하세요.

AI 및 ML 워크로드와 관련된 비용 최적화 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 비용 최적화를 참조하세요.

성능

이 섹션에서는 Google Cloud 에서 성능 요구사항을 충족하는 RAG 지원 생성형 AI 애플리케이션을 설계 및 빌드할 때 고려할 사항에 대해 설명합니다.

제품	설계 고려사항
Cloud Run	기본적으로 각 Cloud Run 컨테이너 인스턴스에는 CPU 1개와 512MiB 메모리가 할당됩니다. Cloud Run 작업의 성능 요구사항에 따라 CPU 한도 및 메모리 한도를 구성할 수 있습니다.
PostgreSQL용 AlloyDB	데이터베이스의 쿼리 성능을 분석 및 향상시키기 위해 PostgreSQL용 AlloyDB는 쿼리 통계 도구를 제공합니다. 이 도구를 사용하여 성능을 모니터링하고 문제가 있는 쿼리 소스를 추적할 수 있습니다. 자세한 내용은 쿼리 통계 개요를 참조하세요. 데이터베이스의 상태 및 성능 개요를 보고 최대 연결 및 최대 복제 지연과 같은 세부 측정항목을 보려면 시스템 통계 대시보드를 사용하면 됩니다. 자세한 내용은 PostgreSQL용 AlloyDB 시스템 통계 대시보드를 사용하여 인스턴스 모니터링을 참조하세요. 기본 PostgreSQL용 AlloyDB 인스턴스에서 부하를 줄이고 읽기 요청 처리 용량을 확대하려면 클러스터에 읽기 풀 인스턴스를 추가하면 됩니다. 자세한 내용은 PostgreSQL용 AlloyDB 노드 및 인스턴스를 참조하세요.
BigQuery	BigQuery는 쿼리성능을 분석하고 슬롯 경합 및 셔플 할당량 부족과 같은 문제에 대해 성능 통계를 얻는 데 사용할 수 있는 쿼리 실행 그래프를 제공합니다. 자세한 내용은 쿼리 성능 통계 가져오기를 참조하세요. 쿼리 성능 통계를 통해 식별된 문제를 해결한 후에는 입력 및 출력 데이터 볼륨 감소와 같은 기법을 사용해서 쿼리를 더 최적화할 수 있습니다. 자세한 내용은 쿼리 계산 최적화를 참조하세요.
Cloud Storage	대용량 파일을 업로드하려면 병렬 복합 업로드라는 방법을 사용할 수 있습니다. 이 전략을 사용하면 큰 파일이 청크로 분할됩니다. 청크가 Cloud Storage에 병렬로 업로드된 후 데이터가 클라우드에서 재구성됩니다. 병렬 복합 업로드는 네트워크 대역폭 및 디스크 속도가 제한적이지 않을 때 일반적인 업로드 작업보다 속도가 빠를 수 있습니다. 그러나 이 전략은 일부 제한사항과 비용 영향이 있습니다. 자세한 내용은 병렬 복합 업로드를 참조하세요.

AI 및 ML 워크로드와 관련된 성능 최적화 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 성능 최적화를 참조하세요.

배포

Google Cloud에서 RAG 지원 생성형 AI 애플리케이션을 위한 인프라를 빌드할 때 작업을 시작하고 실험을 진행하려면 점프 스타트 솔루션: Cloud SQL을 사용하는 생성형 AI RAG를 사용할 수 있습니다. 이 솔루션은 Cloud Run에 Python 기반 채팅 애플리케이션을 배포하고 벡터 검색을 위해 완전 관리형 Cloud SQL 데이터베이스를 사용합니다. 이 솔루션의 샘플 코드는 GitHub에서 제공됩니다.

다음 단계

• Google Cloud 데이터베이스로 엔터프라이즈 생성형 AI 앱 빌드 방법 알아보기
• 새로운 생성형 AI 데이터베이스 검색 앱으로 LLM 응답 개선 지원 방법 알아보기
• PostgreSQL용 AlloyDB AI 및 LangChain을 사용하여 LLM 및 RAG 기반 채팅 애플리케이션 빌드를 위한 Codelab 사용
• 생성형 AI 문서 요약 참조
• 지식 집약 NLP 태스크를 위한 검색 증강 생성 읽어보기
• 대규모 언어 모델을 위한 검색 증강 생성 읽어보기
• Google Cloud에서 AI 및 ML 워크로드와 관련된 아키텍처 원칙 및 권장사항에 대한 개요는 Well-Architected Framework의 AI 및 ML 관점을 참조하세요.
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 Cloud 아키텍처 센터를 확인하세요.

참여자

저자: 쿠마르 다나고팔 | 크로스 프로덕트 솔루션 개발자

기타 참여자:

• 앤드류 브룩 | 엔지니어링 이사
• 안나 베렌버그 | 엔지니어링 연구원
• 아사프 나메르 | 수석 클라우드 보안 설계자
• 발라찬다르 크리슈나무르티 | 수석 소프트웨어 엔지니어
• 다니엘 리 | 클라우드 보안 설계자
• 더렉 다우니 | 개발자 관계 엔지니어
• 에란 루이스 | 선임 제품 관리자
• 제오프레이 앤더슨 | 제품 관리자
• 글렙 오토흐킨 | Cloud 애드보킷, 데이터베이스
• 함사 부바라간 | AI 제품 관리자
• 이리나 시글러 | 제품 관리자
• 잭 워더스푼 | 소프트웨어 엔지니어
• 제이슨 데이벤포트 | Developer Advocate
• 조던 토튼 | 고객 엔지니어
• 줄리아 비징거 | 제품 관리자
• 카라 그린필드 | 고객 엔지니어
• 커티스 반 겐트 | 직원 소프트웨어 엔지니어
• 페르 야콥슨 | 소프트웨어 엔지니어
• 프라나브 남비아르 | 디렉터
• 리차드 핸드릭스 | 아키텍처 센터 직원
• 사피우딘 카자 | 클라우드 엔지니어
• 샌디 가이 | 그룹 제품 관리자
• 블라디미르 부스코비치 | 제품 관리 이사
• 스테렌 지아니니 | 그룹 제품 관리자
• 위체 베네마 | 개발자 관계 엔지니어