에이전트 플랫폼 및 Spanner Graph를 사용하는 생성형 AI용 GraphRAG 인프라

Last reviewed 2026-10-16 UTC

이 문서에서는 Google Cloud에서 GraphRAG 생성형 AI 애플리케이션의 인프라를 설계하는 데 도움이 되는 참조 아키텍처를 제공합니다. 대상에는 지능형 정보 검색 시스템을 빌드하고 관리하는 설계자, 개발자, 관리자가 포함됩니다. 이 문서는 AI, 그래프 데이터 관리, 지식 그래프 개념에 대한 기본적인 이해가 있다는 가정 하에 작성되었습니다. 이 문서에서는 GraphRAG 애플리케이션 설계 및 개발에 대한 구체적인 안내를 제공하지 않습니다.

GraphRAG는 검색 증강 생성 (RAG)에 대한 그래프 기반 접근 방식입니다. RAG는 벡터 검색을 사용하여 검색된 문맥상 관련성 있는 데이터로 프롬프트를 보강하여 AI 생성 응답을 그라운딩하는 데 도움이 됩니다. GraphRAG는 벡터 검색과 지식 그래프 쿼리를 결합하여 다양한 소스의 데이터 상호 연결성을 더 잘 반영하는 문맥 데이터를 검색합니다. GraphRAG를 사용하여 증강된 프롬프트는 더 상세하고 관련성 높은 AI 응답을 생성할 수 있습니다.

아키텍처

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

아키텍처의 데이터 수집 및 서빙 흐름

위 다이어그램의 아키텍처는 데이터 수집과 서빙이라는 두 가지 하위 시스템으로 구성됩니다. 다음 섹션에서는 하위 시스템의 목적과 하위 시스템 내 및 하위 시스템 간의 데이터 흐름을 설명합니다.

데이터 수집 하위 시스템

데이터 수집 하위 시스템은 외부 소스에서 데이터를 수집한 후 GraphRAG용 데이터를 준비합니다. 데이터 수집 및 준비 흐름에는 다음 단계가 포함됩니다.

  1. 데이터가 Cloud Storage 버킷으로 수집됩니다. 이 데이터는 데이터 분석가가 업로드하거나 데이터베이스에서 수집하거나 모든 소스에서 스트리밍할 수 있습니다.
  2. 데이터가 수집되면 메시지가 Pub/Sub 주제로 전송됩니다.
  3. Pub/Sub가 업로드된 데이터를 처리하기 위해 Cloud Run 함수를 트리거합니다.
  4. Cloud Run Functions는 Gemini API와 LangChain의 LLMGraphTransformer와 같은 도구를 사용하여 입력 파일에서 지식 그래프를 빌드합니다.
  5. 함수는 지식 그래프를 Spanner Graph 데이터베이스에 저장합니다.
  6. 이 함수는 LangChain의 RecursiveCharacterTextSplitter 또는 Document AI의 레이아웃 파서와 같은 도구를 사용하여 데이터 파일의 텍스트 콘텐츠를 세분화된 단위로 분할합니다.
  7. 이 함수는 Gemini Enterprise Agent Platform Embeddings API를 사용하여 텍스트 세그먼트의 벡터 임베딩을 만듭니다.
  8. 함수는 벡터 임베딩과 연결된 그래프 노드를 Spanner Graph에 저장합니다.

벡터 임베딩은 시맨틱 검색의 기반이 됩니다. 지식 그래프 노드를 사용하면 복잡한 데이터 관계와 패턴을 탐색하고 분석할 수 있습니다.

서빙 하위 시스템

서빙 하위 시스템은 생성형 AI 애플리케이션과 사용자 사이의 쿼리-응답 수명 주기를 관리합니다. 서빙 흐름에는 다음 단계가 포함됩니다.

  1. 사용자가 Gemini Enterprise Agent Platform의 Agent Runtime에 배포된 AI 에이전트에 자연어 쿼리를 제출합니다.
  2. 에이전트는 다음과 같이 쿼리를 처리합니다.
    1. Agent Platform Embeddings API를 사용하여 쿼리를 벡터 임베딩으로 변환합니다.
    2. 임베딩 데이터베이스에서 벡터 유사성 검색을 수행하여 쿼리와 관련된 그래프 노드를 검색합니다.
    3. 지식 그래프를 순회하여 쿼리와 관련된 데이터를 검색합니다.
    4. 원본 쿼리를 검색된 그래프 데이터와 결합하여 프롬프트를 보강합니다.
    5. 에이전트 검색 순위 API를 사용하여 결과를 순위 지정합니다. 이 결과는 그래프 데이터베이스에서 검색된 노드 및 에지로 구성됩니다. 순위는 쿼리와의 시맨틱 관련성을 기반으로 합니다.
    6. Gemini API를 호출하여 결과를 요약합니다.
  3. 그런 다음 에이전트는 요약된 결과를 사용자에게 전송합니다.

Cloud Logging에서 쿼리-응답 활동 로그를 저장하고 볼 수 있으며 Cloud Monitoring을 사용하여 로그 기반 모니터링을 설정할 수 있습니다.

사용 제품

이 참조 아키텍처에는 다음과 같은 Google 제품 및 도구가 사용됩니다.

  • Spanner Graph: Spanner의 확장성, 가용성, 일관성 기능을 제공하는 그래프 데이터베이스입니다.
  • Gemini Enterprise Agent Platform: 엔터프라이즈급 AI 에이전트를 빌드, 확장, 제어, 최적화할 수 있는 포괄적인 플랫폼입니다.
  • Cloud Run Functions: Google Cloud에서 직접 단일 목적 함수를 실행할 수 있는 서버리스 컴퓨팅 플랫폼입니다.
  • Cloud Storage: 다양한 데이터 유형에 적합한 저비용, 무제한 객체 스토어입니다. Google Cloud내부 및 외부에서 데이터에 액세스할 수 있고 중복성을 위해 여러 위치에 복제됩니다.
  • Pub/Sub: 메시지 생성 서비스를 메시지 처리 서비스와 분리하는 비동기식의 확장 가능한 메시징 서비스입니다.
  • Cloud Logging: 스토리지, 검색, 분석, 알림을 지원하는 실시간 로그 관리 시스템입니다.
  • Cloud Monitoring: 애플리케이션 및 인프라의 성능, 가용성, 상태에 관한 정보를 제공하는 서비스입니다.

사용 사례

GraphRAG는 다양한 업종의 사용 사례에 대해 지능형 데이터 검색을 지원합니다. 이 섹션에서는 의료, 금융, 법률 서비스, 제조 분야의 몇 가지 사용 사례를 설명합니다.

헬스케어 및 의약품: 임상 의사 결정 지원

임상 의사 결정 지원 시스템에서 GraphRAG는 의학 문헌, 환자 전자 건강 기록, 약물 상호작용 데이터베이스, 임상 시험 결과의 방대한 데이터를 통합 지식 그래프로 통합합니다. 임상의와 연구원이 환자의 증상과 현재 복용 중인 약물을 쿼리하면 GraphRAG는 지식 그래프를 순회하여 관련 질환과 잠재적인 약물 상호작용을 식별합니다. 또한 환자의 유전적 프로필과 같은 다른 데이터를 기반으로 맞춤형 치료 추천을 생성할 수 있습니다. 이러한 유형의 정보 검색은 키워드 검색 유형보다 맥락이 더 풍부하고 증거에 기반한 답변을 제공합니다.

금융 서비스: 금융 데이터 통합

금융 서비스 기업은 지식 그래프를 사용하여 분석가 보고서, 실적 발표, 위험 평가와 같은 다양한 소스의 데이터를 통합되고 구조화된 뷰로 분석가에게 제공합니다. 지식 그래프는 회사 및 임원과 같은 주요 데이터 항목을 식별하고 항목 간의 중요한 관계를 매핑합니다. 이 접근 방식은 풍부하고 상호 연결된 데이터 웹을 제공하여 더 심층적이고 효율적인 재무 분석을 가능하게 합니다. 분석가는 복잡한 공급망 종속성, 경쟁사 간에 겹치는 이사회 구성원, 복잡한 지정학적 위험에 대한 노출 등 이전에는 숨겨져 있던 인사이트를 발견할 수 있습니다.

법률 분야에서는 GraphRAG를 사용하여 판례, 법령, 판례법, 규제 업데이트, 내부 문서를 기반으로 맞춤형 법률 추천을 생성할 수 있습니다. 변호사는 사건을 준비할 때 특정 법적 주장, 유사한 사건에 대한 이전 판결 또는 새로운 법률의 영향에 대해 미묘한 질문을 할 수 있습니다. GraphRAG는 사용 가능한 법률 지식의 상호 연결성을 사용하여 관련 판례를 식별하고 적용 가능성을 설명합니다. 또한 법적 개념, 법령, 사법 해석 간의 관계를 추적하여 반론을 제안할 수도 있습니다. 이 접근 방식을 사용하면 법률 실무자는 기존의 지식 검색 방법보다 더 철저하고 정확한 인사이트를 얻을 수 있습니다.

제조 및 공급망: 기관 지식 활용

제조 및 공급망 운영에는 높은 수준의 정밀도가 필요합니다. 필요한 수준의 정밀도를 유지하는 데 필요한 지식은 수천 개의 밀도 높은 정적 표준 운영 절차 (SOP) 문서에 묻혀 있는 경우가 많습니다. 공장의 생산 라인이나 기계가 고장 나거나 물류 문제가 발생하면 엔지니어와 기술자는 문제를 진단하고 해결하기 위해 연결되지 않은 PDF 문서를 검색하는 데 중요한 시간을 낭비하는 경우가 많습니다. 지식 그래프와 대화형 AI를 결합하면 숨겨진 기관 지식을 대화형 진단 파트너로 전환할 수 있습니다.

설계 대안

이 문서에서 설명하는 아키텍처는 모듈식입니다. 요구사항에 따라 대체 제품, 도구, 기술을 사용하도록 아키텍처의 특정 구성요소를 조정할 수 있습니다.

지식 그래프 빌드

LangChain의 LLMGraphTransformer 도구를 사용하여 처음부터 지식 그래프를 빌드할 수 있습니다. allowed_nodes, allowed_relationships, node_properties, relationship_properties와 같은 LLMGraphTransformer 매개변수로 그래프 스키마를 지정하면 결과 지식 그래프의 품질을 개선할 수 있습니다. 하지만 LLMGraphTransformer는 일반 도메인에서 항목을 추출할 수 있으므로 의료 또는 제약과 같은 틈새 도메인에는 적합하지 않을 수 있습니다. 또한 조직에 이미 지식 그래프를 빌드하는 강력한 프로세스가 있는 경우 이 참조 아키텍처에 표시된 데이터 수집 하위 시스템은 선택사항입니다.

지식 그래프 및 벡터 임베딩 저장

이 문서의 아키텍처는 Spanner를 지식 그래프와 벡터 임베딩의 데이터 스토어로 사용합니다. 엔터프라이즈 지식 그래프가 이미 다른 곳 (예: Neo4j와 같은 플랫폼)에 있는 경우 임베딩에 벡터 데이터베이스를 사용하는 것이 좋습니다. 하지만 이 접근 방식은 추가 관리 노력이 필요하며 비용이 더 많이 들 수 있습니다. Spanner는 그래프 구조와 벡터 임베딩 모두에 대해 통합되고 전역적으로 일관된 데이터 스토어를 제공합니다. 이러한 데이터 스토어는 통합 데이터 관리를 지원하여 비용, 성능, 보안 거버넌스, 운영 효율성을 최적화하는 데 도움이 됩니다.

에이전트 런타임

이 참조 아키텍처에서 에이전트는 AI 에이전트에 관리형 런타임을 제공하는 Agent Runtime에 배포됩니다. 고려할 수 있는 다른 옵션으로는 Cloud Run 및 Google Kubernetes Engine (GKE)이 있습니다. 이러한 옵션에 대한 설명은 이 문서에서 다루지 않습니다.

RAG를 사용한 그라운딩

사용 사례 섹션에서 설명한 것처럼 GraphRAG는 다양한 시나리오에서 그라운딩을 위한 지능형 데이터 검색을 지원합니다. 하지만 프롬프트 증강에 사용하는 소스 데이터에 복잡한 상호 관계가 없는 경우 RAG가 생성형 AI 애플리케이션에 적합한 선택일 수 있습니다.

다음 참조 아키텍처는 벡터 지원 관리형 데이터베이스 또는 특수 벡터 검색 제품을 사용하여 Google Cloud 에서 RAG에 필요한 인프라를 빌드하는 방법을 보여줍니다.

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 보안, 안정성, 비용, 성능 관련 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려해야 하는 설계 요소, 권장사항, 권장사항을 설명합니다.

이 섹션의 안내는 일부일 뿐 모든 내용을 포함하지는 않습니다. 워크로드의 요구사항과 사용하는 Google Cloud 및 서드 파티 제품과 기능에 따라 추가로 고려해야 할 설계 요소와 장단점이 있을 수 있습니다.

보안, 개인 정보 보호, 규정 준수

이 섹션에서는 워크로드의 보안 및 규정 준수 요구사항을 충족하는 Google Cloud 에서 토폴로지를 설계하기 위한 설계 고려사항과 권장사항을 설명합니다.

Agent Platform 보안 고려사항

에이전트 플랫폼 구성 및 사용이 보안 요구사항을 충족하는지 확인하려면 다음 권장사항을 고려하세요.

  • 보안 제어: Agent Platform은 데이터 레지던시, 데이터 암호화, 네트워크 보안, 액세스 투명성에 대한 요구사항을 충족하기 위해 사용할 수 있는 Google Cloud 보안 제어를 지원합니다. 자세한 내용은 다음 문서를 참조하세요.

  • 안전: 생성형 AI 모델은 특히 유해한 대답을 생성하도록 명시적으로 프롬프트가 작성되는 경우 유해한 대답을 생성할 수 있습니다. 안전을 강화하고 잠재적인 오용을 완화하기 위해 유해한 대답을 차단하는 장벽 역할을 하도록 콘텐츠 필터를 구성할 수 있습니다. 자세한 내용은 안전 및 콘텐츠 필터를 참고하세요.

Spanner Graph 데이터 암호화

기본적으로 Spanner Graph에 저장되는 데이터는 Google-owned and Google-managed encryption keys를 사용하여 암호화됩니다. 사용자가 제어하고 관리하는 암호화 키를 사용해야 하는 경우에는 고객 관리 암호화 키(CMEK)를 사용하면 됩니다. 자세한 내용은 CMEK 정보를 참조하세요.

Cloud Run Functions 보안 고려사항

Cloud Run Functions 구현이 보안 요구사항을 충족하도록 하려면 다음 권장사항을 고려하세요.

  • 데이터 암호화: 기본적으로 Cloud Run은 Google-owned and Google-managed encryption keys를 사용하여 데이터를 암호화합니다. 사용자가 제어하는 키를 사용하여 컨테이너를 보호하려면 CMEK를 사용하면 됩니다. 자세한 내용은 고객 관리 암호화 키 사용을 참조하세요.
  • 컨테이너 이미지 보안: 승인된 컨테이너 이미지만 Cloud Run에 배포되도록 하려면 Binary Authorization을 사용하면 됩니다.
  • 데이터 레지던시: Cloud Run은 데이터 레지던시 요구사항을 충족하도록 도와줍니다. Cloud Run Functions는 선택한 리전 내에서 실행됩니다.

Cloud Storage 보안 고려사항

Cloud Storage 구성이 보안 요구사항을 충족하는지 확인하려면 다음 권장사항을 고려하세요.

  • 데이터 암호화: 기본적으로 Cloud Storage에 저장되는 데이터는Google-owned and Google-managed encryption keys를 사용하여 암호화됩니다. 필요한 경우 CMEK를 사용하거나 고객 제공 암호화 키 (CSEK)와 같은 외부 관리 방법을 사용하여 관리하는 자체 키를 사용할 수 있습니다. 자세한 내용은 데이터 암호화 옵션을 참조하세요.
  • 액세스 제어: Cloud Storage는 버킷과 객체에 액세스할 수 있는 권한을 사용자에게 부여하기 위해 Identity and Access Management (IAM) 및 액세스 제어 목록 (ACL)의 두 가지 방법을 지원합니다. 대부분의 경우 버킷 및 프로젝트 수준에서 권한을 부여할 수 있는 IAM을 사용하는 것이 좋습니다. 자세한 내용은 액세스 제어 개요를 참조하세요.
  • 데이터 보호: Cloud Storage를 통해 데이터 수집 하위 시스템에 로드하는 데이터에는 민감한 정보가 포함될 수 있습니다. Sensitive Data Protection을 사용하여 민감한 정보를 검색, 분류, 익명화할 수 있습니다. 자세한 내용은 Cloud Storage에 Sensitive Data Protection 사용을 참조하세요.
  • 데이터 레지던시: Cloud Storage는 데이터 레지던시 요구사항을 충족하도록 도와줍니다. 데이터는 사용자가 지정한 리전 내에 저장 또는 복제됩니다.

Pub/Sub 보안 고려사항

Pub/Sub 구성이 보안 요구사항을 충족하는지 확인하려면 다음 권장사항을 고려하세요.

  • 데이터 암호화: 기본적으로 Pub/Sub는Google-owned and Google-managed encryption keys를 사용하여 저장 중 및 전송 중인 모든 메시지를 암호화합니다. Pub/Sub에서는 애플리케이션 계층에서 메시지 암호화를 위해 CMEK를 사용할 수 있습니다. 자세한 내용은 메시지 암호화 구성을 참조하세요.
  • 데이터 레지던시: 데이터 레지던시 요구사항이 있는 경우 메시지 데이터가 특정 위치에 저장되도록 하려면 메시지 스토리지 정책을 구성하면 됩니다.

Cloud Logging 보안 고려사항

Cloud Logging 구성이 보안 요구사항을 충족하는지 확인하려면 다음 설계 요소와 권장사항을 고려하세요.

  • 관리 활동 감사: 관리자 활동 감사 로그는 이 참조 아키텍처에 사용되는 모든 Google Cloud 서비스에 대해 기본적으로 사용 설정됩니다. 이러한 로그는 Google Cloud 리소스의 구성 또는 메타데이터를 수정하는 API 호출 또는 기타 작업을 기록합니다.
  • 데이터 액세스 감사: 이 아키텍처에 사용되는 Google Cloud 서비스에 대해 데이터 액세스 감사 로그를 사용 설정할 수 있습니다. 이러한 로그를 사용하면 리소스의 구성 또는 메타데이터를 읽는 API 호출 또는 사용자 제공 리소스 데이터 생성, 수정, 읽기에 대한 사용자 요청을 추적할 수 있습니다.
  • 데이터 레지던시: 데이터 레지던시 요구사항을 충족하기 위해 지정한 리전에 로그 데이터를 저장하도록 Cloud Logging을 구성할 수 있습니다. 자세한 내용은 로그 리전화를 참조하세요.

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

안정성

이 섹션에서는 Google Cloud에서 배포를 위한 안정적인 인프라를 빌드하고 운영하기 위한 설계 고려사항과 권장사항을 설명합니다.

Agent Platform 용량 및 엔드포인트 가용성

요청 수가 할당된 용량을 초과하면 오류 코드 429가 반환됩니다. 비즈니스에 중요하고 지속적으로 높은 처리량이 필요한 워크로드의 경우 프로비저닝된 처리량을 사용하여 처리량을 예약할 수 있습니다. 여러 리전 또는 국가에서 데이터를 공유할 수 있는 경우 전역 엔드포인트를 사용할 수 있습니다.

Spanner Graph 데이터 가용성 및 재해 복구

Spanner는 높은 데이터 가용성과 전역 확장성을 위해 설계되었습니다. 리전 서비스 중단 중에도 가용성을 보장하기 위해 Spanner는 여러 리전의 여러 영역에 데이터를 복제하는 멀티 리전 구성을 제공합니다. 이러한 기본 제공 복원력 기능 외에도 Spanner는 포괄적인 재해 복구 전략을 지원하는 다음 기능을 제공합니다.

  • 데이터베이스 삭제 방지
  • 예약 및 리전 간 복사를 포함한 강력한 백업 및 복원 기능
  • 최대 7일 동안 논리적 데이터 손상, 운영자 오류 또는 실수로 인한 쓰기로부터 보호하는 PITR (point-in-time recovery)

자세한 내용은 재해 복구 개요를 참조하세요.

인프라 중단에 대한 Cloud Run Functions의 견고성

Cloud Run은 리전 서비스입니다. 데이터는 리전 내 여러 영역에 동기식으로 저장됩니다. 트래픽은 영역 간에 자동으로 부하 분산됩니다. 영역 서비스 중단이 발생해도 Cloud Run이 계속 실행되고 데이터가 손실되지 않습니다. 리전 서비스 중단이 발생하면 Google에서 서비스 중단을 해결할 때까지 서비스 실행이 중지됩니다.

Cloud Storage 데이터 가용성

리전, 이중 리전, 멀티 리전의 세 가지 위치 유형 중 하나로 Cloud Storage 버킷을 만들 수 있습니다. 리전 버킷에 저장된 데이터는 리전 내 여러 영역에 동기식으로 복제됩니다. 더 높은 가용성을 위해서는 데이터가 리전 간에 동기식으로 복제되는 이중 리전 또는 멀티 리전 버킷을 사용하면 됩니다.

Pub/Sub 안정성 고려사항

Pub/Sub 구성이 안정성 요구사항을 충족하는지 확인하려면 다음 권장사항을 고려하세요.

  • 비율 제어: 메시지 트래픽이 일시적으로 급증하는 기간 동안 오류를 방지하려면 게시자 설정에서 흐름 제어를 구성하여 게시 요청 비율을 제한하면 됩니다.
  • 실패 처리: 실패한 게시 시도를 처리하려면 필요에 따라 재시도 요청 변수를 조정합니다. 자세한 내용은 재시도 요청을 참조하세요.

아키텍처의 모든 제품에 대한 안정성 권장사항

Google Cloud에 워크로드를 배포한 후에는 Active Assist의 관련 권장사항을 적용하여 클라우드 리소스의 안정성을 더욱 최적화합니다.

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

비용 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 빌드하는 Google Cloud 토폴로지의 설정 및 운영 비용을 최적화하는 방법을 안내합니다.

Agent Platform 비용 고려사항

Agent Platform 구성 및 사용량이 비용 요구사항을 충족하도록 하려면 다음 권장사항을 고려하세요.

  • 비용 분석 및 관리: Agent Platform 비용을 분석하고 관리하려면 초당 쿼리 수 (QPS) 및 초당 토큰 수 (TPS)의 기준을 만들고 배포 후 이러한 측정항목을 모니터링하는 것이 좋습니다. 기준은 용량 계획에도 도움이 됩니다. 예를 들어 기준은 프로비저닝된 처리량이 필요한 시점을 결정하는 데 도움이 됩니다.
  • 모델 선택: 생성형 AI 애플리케이션에 적합한 모델을 선택하는 것은 비용과 성능 모두에 직접적인 영향을 미치는 중요한 결정입니다. 특정 사용 사례에 대해 성능과 비용 간의 최적의 균형을 제공하는 모델을 식별하려면 모델을 반복적으로 테스트하세요. 가장 비용 효율적인 모델부터 시작하여 점차 더 강력한 옵션으로 진행하는 것이 좋습니다.
  • 프롬프트 엔지니어링: 프롬프트(입력) 및 생성된 응답 (출력)의 길이는 성능과 비용에 직접적인 영향을 미칩니다. 짧고 직접적이며 충분한 컨텍스트를 제공하는 프롬프트를 작성합니다. 모델에서 간결한 대답을 얻을 수 있도록 프롬프트를 설계합니다. 예를 들어 '2문장으로 요약' 또는 '핵심 사항 3개 나열'과 같은 문구를 포함합니다. 자세한 내용은 프롬프트 설계 권장사항을 참조하세요.
  • 컨텍스트 캐싱: 입력 토큰 수가 많은 반복 콘텐츠가 포함된 요청의 비용을 줄이려면 컨텍스트 캐싱을 사용합니다.
  • 일괄 요청: 콘텐츠 생성 및 오프라인 분석과 같이 비동기식으로 수행할 수 있는 대규모 처리 태스크의 경우 일괄 추론을 사용하는 것이 좋습니다. 일괄 요청은 표준 요청보다 저렴한 가격으로 청구됩니다.

Spanner Graph 비용 고려사항

Spanner Graph 구성이 비용 요구사항을 충족하는지 확인하려면 다음 권장사항을 고려하세요.

  • 컴퓨팅 용량 자동 확장: 비용을 제어하기 위해 관리형 자동 확장 처리를 사용하여 CPU 사용률 및 스토리지 요구사항에 따라 Spanner Graph 데이터베이스의 컴퓨팅 용량을 동적으로 조정합니다. 소규모 워크로드의 경우에도 최소 용량이 필요한 경우가 많습니다.
  • 요금 최적화: 예측 가능하고 안정적이거나 기준 컴퓨팅 용량의 경우 약정 사용 할인 (CUD)을 구매합니다. CUD는 컴퓨팅 용량에 대한 특정 시간당 지출을 약정하는 대가로 상당한 할인을 제공합니다.
  • 백업 복제: 재해 복구 또는 규정 준수를 위해 백업을 다른 리전에 복사할 때는 네트워크 이그레스 비용을 고려하세요. 비용을 줄이려면 필수 백업만 복사하세요.

Cloud Run Functions 비용 고려사항

Cloud Run Functions 구현이 비용 요구사항을 충족하도록 하려면 다음 권장사항을 고려하세요.

  • 리소스 할당: Cloud Run Functions를 만들 때 할당할 메모리 및 CPU 양을 지정할 수 있습니다. 비용을 줄이려면 기본 (최소) CPU 및 메모리 할당으로 시작합니다. 성능을 향상시키려면 CPU 한도 및 메모리 한도를 구성하여 할당을 늘릴 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

  • 비율 최적화: CPU 및 메모리 요구사항을 예측할 수 있으면 CUD를 통해 비용을 절감할 수 있습니다.

Cloud Storage 스토리지 클래스 및 수명 주기 관리

데이터 수집 하위 시스템의 Cloud Storage 버킷에 대해 데이터 보관 및 액세스 빈도에 대한 워크로드 요구사항에 따라 적합한 스토리지 클래스를 선택합니다. 예를 들어 스토리지 비용을 관리하려면 Standard 클래스를 선택하고 객체 수명 주기 관리를 사용하면 됩니다. 이 방법을 사용하면 지정된 조건에 따라 객체를 더 저렴한 스토리지 클래스로 자동으로 다운그레이드하거나 객체를 자동으로 삭제할 수 있습니다.

Cloud Logging 비용 고려사항

로그 저장 비용을 관리하려면 다음 권장사항을 고려하세요.

  • 불필요한 로그 항목을 제외하거나 필터링하여 로그 볼륨을 줄입니다. 자세한 내용은 제외 필터를 참조하세요.
  • 로그 보관 기간을 최적화합니다. 자세한 내용은 커스텀 보관 구성을 참조하세요.

아키텍처의 모든 제품에 대한 비용 최적화 권장사항

아키텍처가 비용 요구사항을 충족하도록 하려면 다음 일반 권장사항을 고려하세요.

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

성능 최적화

이 섹션에서는 Google Cloud 에서 워크로드의 성능 요구사항을 충족하는 토폴로지를 설계하기 위한 설계 고려사항과 권장사항을 설명합니다.

Agent Platform 성능 고려사항

에이전트 플랫폼 구성 및 사용량이 성능 요구사항을 충족하는지 확인하려면 다음 권장사항을 고려하세요.

  • 모델 선택: 생성형 AI 애플리케이션에 적합한 모델을 선택하는 것은 비용과 성능 모두에 직접적인 영향을 미치는 중요한 결정입니다. 특정 사용 사례에 대해 성능과 비용 간의 최적의 균형을 제공하는 모델을 식별하려면 모델을 반복적으로 테스트하세요. 가장 비용 효율적인 모델부터 시작하여 점차 더 강력한 옵션으로 진행하는 것이 좋습니다.
  • 프롬프트 엔지니어링: 프롬프트(입력) 및 생성된 응답 (출력)의 길이는 성능과 비용에 직접적인 영향을 미칩니다. 짧고 직접적이며 충분한 컨텍스트를 제공하는 프롬프트를 작성합니다. 모델에서 간결한 대답을 얻을 수 있도록 프롬프트를 설계합니다. 예를 들어 '2문장으로 요약' 또는 '핵심 사항 3개 나열'과 같은 문구를 포함합니다. 자세한 내용은 프롬프트 설계 권장사항을 참조하세요.
  • 프롬프트 최적화: 에이전트 플랫폼 프롬프트 최적화 도구를 사용하면 프롬프트 성능을 대규모로 빠르게 개선하고 최적화할 수 있으며 수동으로 다시 작성할 필요가 없습니다. 최적화 도구를 사용하면 다양한 모델에서 프롬프트를 효율적으로 조정할 수 있습니다.

Spanner Graph 스키마 설계 및 쿼리 조정

Spanner Graph 성능을 최적화하기 위한 권장사항은 다음 문서를 참조하세요.

Cloud Run Functions 리소스 할당

기본적으로 각 Cloud Run Functions 인스턴스에는 CPU 1개와 256MiB 메모리가 할당됩니다. 성능 요구사항에 따라 CPU 및 메모리 한도를 구성할 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

성능 최적화에 대한 자세한 내용은 일반적인 Cloud Run 개발 팁을 참조하세요.

Cloud Storage 동시 복합 업로드

대용량 파일을 업로드하려면 병렬 복합 업로드를 사용하면 됩니다. 이 전략을 사용하면 큰 파일이 청크로 분할됩니다. 청크가 Cloud Storage에 병렬로 업로드된 후 데이터가 클라우드에서 재구성됩니다. 네트워크 대역폭과 디스크 속도가 병목 요인이 되지 않는 경우, 병렬 복합 업로드는 일반 업로드 작업보다 더 빠를 수 있습니다. 그러나 이 전략은 일부 제한사항과 비용 영향이 있습니다. 자세한 내용은 동시 복합 업로드를 참조하세요.

아키텍처의 모든 제품에 대한 성능 최적화 권장사항

Google Cloud에 워크로드를 배포한 후에는 Active Assist의 관련 추천을 적용하여 클라우드 리소스의 성능을 더욱 최적화합니다.

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

배포

Google Cloud에서 GraphRAG가 작동하는 방식을 살펴보려면 GitHub에서 다음 Jupyter 노트북을 다운로드하고 실행하세요. Gemini Enterprise Agent Platform에서 Spanner Graph 및 Agent Runtime을 사용하는 Google Cloud 의 GraphRAG

다음 단계

참여자

저자:

기타 참여자: