에이전트 시대를 위한 타협 없는 새로운 데이터베이스 아키텍처

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

데이터베이스 엔지니어링 분야에 종사하는 모든 이들은 단 하나의 질문에 매달려 왔습니다. 데이터를 보유한 레코드 시스템을 손상시키지 않으면서 OLTP 워크로드를 확장하려면 어떻게 해야 할까요?

Exadata는 데이터베이스 아래의 수평 확장 스토리지 계층으로 쿼리를 오프로드하여 네트워크 병목 현상을 제거하는 방식으로 이 문제를 해결했습니다. Azure SQL Hyperscale은 공유 블록 서버를 사용하여 수십 개의 읽기 복제본으로 수평 확장했습니다. Aurora는 로그 애플리케이션을 분산 스토리지 노드로 오프로드하여 수십 개의 PostgreSQL 노드에서 읽기 작업을 확장했습니다. 한편, 새로운 아키텍처는 프로비저닝된 캐시 계층을 앞에 두고 기존 객체 스토리지에 데이터를 유지합니다. 이를 통해 핫 데이터의 지연 시간은 줄일 수 있지만 캐시 부적중이 발생할 때마다 긴 지연 시간이 발생하는 문제는 여전히 남습니다.

이러한 각 아키텍처는 본질적으로 규모, 지연 시간, 격리라는 세 가지 특성 중 적어도 하나, 경우에 따라서는 두 가지 특성의 제약을 받습니다. 예를 들어 공유 블록 서버를 기반으로 구축된 아키텍처는 블록 서버에서 I/O 병목 현상이 불가피하게 발생하기 때문에 확장성이 저하됩니다. 또한 복제본 트래픽이 급증할 때마다 프로덕션 워크로드가 제한되므로 격리 측면에서도 손해를 감수해야 합니다. 

이러한 절충안 중 일부는 당시에는 합리적인 선택이었으며, 지난 40년 동안 엔터프라이즈 데이터베이스 워크로드의 요구사항을 충족해 왔습니다. 그러나 에이전트 시대에는 이러한 타협이 더 이상 용납되지 않습니다. 에이전트형 워크로드는 동적으로 생성되며 사전에 검증할 수 없으므로 비즈니스 연속성을 위해 미션 크리티컬 시스템과 격리하는 것이 필수적입니다. 또한 에이전트형 워크로드에는 데이터베이스 엔진과 모든 색인의 성능을 온전히 활용해야만 달성할 수 있는 짧은 지연 시간이 필요합니다. 이와 동시에 단일 데이터베이스에서는 지금껏 시도된 적 없는 완전히 새로운 수준의 탄력적 확장성도 요구됩니다. 예를 들어 수많은 에이전트가 한꺼번에 단일 데이터베이스를 처리하기 위해 불과 몇 초 만에 1,000개의 컴퓨팅 노드를 사용하고 1분도 채 되지 않아 작업을 완료할 수도 있습니다.

진정한 에이전트형 데이터베이스 아키텍처에 필요한 세 가지 원칙

에이전트 시대에는 세 가지 기본 원칙으로 정의되는 새로운 에이전트형 데이터베이스 아키텍처가 필요할 것입니다. 에이전트형 데이터베이스 아키텍처라면 이 세 가지를 모두 충족해야 하며, 그렇지 않다면 진정한 의미의 에이전트형이라고 할 수 없습니다.

1. 원칙: 격리 — 설계 단계부터 격리하되, 실시간 데이터 액세스 보장. 에이전트는 기본 클러스터와 데이터베이스 구성요소를 공유하지 않는 데이터 경로를 통해 1초 미만의 최신 상태가 보장되는 실시간 프로덕션 데이터를 읽을 수 있어야 합니다. 실시간이란 오래된 사본이나 브랜치가 아니라 초 단위로 최신 상태를 유지하는 것을 의미합니다. 이는 할당량을 통한 제한이 아닌 물리적인 분리입니다. 할당량 공유는 운명 공동체를 의미하기 때문입니다. 경계는 스토리지 레이어를 통해 바로 확장되므로 설계 단계부터 리소스 경합을 방지됩니다. 

2. 원칙: 지연 시간 — 1밀리초 미만의 기준 I/O. 운영 워크로드에는 1밀리초 미만의 블록 I/O가 필요하며, 에이전트의 경우에도 이 기준은 낮아지지 않습니다. 컴퓨팅 노드는 가속화를 위해 DRAM과 로컬 SSD를 활용하지만, 원격 스토리지에 도달하는 캐시 부적중은 애플리케이션이든 에이전트든 1밀리초 이내에 완료되어야 합니다. 성능이 10배 이상 급격히 저하되는 아키텍처는 근본적으로 에이전트가 사용하기에 적합하지 않습니다.

3. 원칙: 확장성 — 에이전트 규모의 컴퓨팅 및 I/O. 에이전트의 확장성은 즉각적이고, 변동성이 크며, 그 규모도 방대합니다. 데이터베이스 컴퓨팅 노드는 몇 초 만에 가동되어 수천 개로 확장되고, 짧은 버스트 중에 실행된 후, 에이전트가 작업을 완료하면 자동으로 0까지 축소될 수 있어야 합니다. 지금까지 프로덕션에 영향을 주지 않으면서 데이터베이스가 컴퓨팅과 I/O를 수천 개의 노드로 동적으로 확장할 수 있을 것이라고는 아무도 생각하지 못했습니다. 에이전트는 본질적으로 동적으로 작동하므로 컴퓨팅이든, 스토리지 I/O이든, 그 사이의 캐싱 계층이든 전체 스택에서 사전 프로비저닝하는 방식은 애초에 불가능합니다.

중요한 것은 에이전트형 아키텍처가 이 세 가지 원칙을 동시에 준수해야 한다는 점입니다. 이를 통해 에이전트는 프로덕션 안정성을 저해하지 않으면서 실시간 운영 데이터, 즉 기업 지식을 직접 활용해 작업할 수 있습니다. 그 결과로 다음과 같은 획기적인 이점을 얻을 수 있습니다.

• 관련 장애 방지: 비즈니스를 운영하는 엔진과 이를 기반으로 추론하는 에이전트 Fleet을 완전한 분리하여 에이전트가 프로덕션에 영향을 미칠 수 있는 경로를 차단합니다.

• 용량 예측 불필요: 진정한 탄력성을 통해 예측할 수 없는 에이전트 규모에 대비하여 사전 프로비저닝해야 하는 부담을 없앱니다.

• 기능 타협 불필요: 에이전트가 사용할 수 있는 기능을 제한하지 않습니다. 에이전트는 모든 추론 단계에서 관계형 SQL, 하이브리드 검색(벡터, 전체 텍스트, 공간), 색인의 모든 기능을 활용할 수 있습니다.

AlloyDB의 에이전트형 아키텍처

AlloyDB의 새로운 에이전트형 데이터베이스 아키텍처는 이 세 가지 원칙을 모두 충족하는 최초의 시스템입니다. Google은 처음부터 스토리지, 네트워크, 컴퓨팅, 데이터베이스 전반을 고려하여 설계했기 때문에 다음과 같은 이점을 제공합니다.

• 설계 단계부터 격리하여 공동 운명 방지: 트랜잭션 프로덕션 클러스터는 에이전트 워크로드와 완전히 격리된 전용 사전 프로비저닝 인프라에서 실행됩니다. 에이전트는 모델 컨텍스트 프로토콜(MCP)을 통해 독립적이고 일시적인 microVM 기반 AlloyDB 노드 풀과 상호작용합니다. 이러한 노드는 프로덕션용 스토리지 세그먼트와 분리된 전용 Colossus 스토리지 세그먼트에서 데이터를 직접 읽습니다.

• 예측 가능한 1밀리초 미만의 스토리지 I/O: 모든 스토리지 읽기는 Google의 Colossus 스토리지 시스템에서 직접 처리되므로 이 시스템의 기본적인 1밀리초 미만 지연 시간이 그대로 적용되며 콜드 캐시 부적중이 발생할 때 성능이 급격히 저하되는 현상을 방지합니다. 

• 0에서 수천 개까지 지원하는 진정한 컴퓨팅 확장: 에이전트 활동이 급증하면 에이전트 풀이 0개에서 수천 개의 노드로 빠르게 확장되고, 작업이 완료되는 즉시 다시 0개로 축소됩니다.

에이전트는 1초 미만의 최신 상태가 보장되는 프로덕션 데이터를 쿼리할 수 있으며 완전한 PostgreSQL 엔진을 자유롭게 사용하여 포인트 조회, 색인 순회, 벡터, 전체 텍스트 및 공간 검색, 열 기반 스캔, 레이크하우스 전반의 페더레이션 쿼리 등 추론 루프를 실행할 수 있습니다.

에이전트용 AlloyDB PostgreSQL 프리뷰에 참여하여 규모에 관계없이 모든 프로덕션 데이터에 대해 에이전트를 실행하세요.  전체 기능에 대한 자세한 내용은 함께 제공되는 공지 블로그에서 확인할 수 있습니다.

기존 아키텍처가 세 가지 원칙을 모두 충족할 수 없는 이유

기존 운영 데이터베이스와 새로운 운영 데이터베이스는 모두 세 가지 아키텍처 패러다임 중 하나를 사용하여 확장하려고 합니다. 자율 AI 에이전트의 요구사항을 기준으로 평가하면 각 패러다임에는 근본적인 구조적 한계가 있으며, 세 가지 원칙을 모두 동시에 충족하는 아키텍처는 없습니다.

독립적인 복제본(공유되지 않는 스토리지)

기존 관계형 아키텍처는 기본 인스턴스에서 전용 복제본 데이터베이스로 복제 로그를 스트리밍하여 읽기 작업을 확장하며, 각 복제본에는 자체 로컬 또는 연결된 블록 스토리지가 있습니다. 이러한 방식은 원칙: 격리를 충족합니다. 복제본은 기본 클러스터와 물리적 리소스를 공유하지 않으며, 지속적인 로그 복제를 통해 거의 실시간으로 최신 상태를 유지합니다. 또한 전용 로컬 스토리지를 통해 예측 가능한 1밀리초 미만의 읽기 지연 시간을 보장하므로 원칙: 지연 시간도 충족합니다. 그러나 원칙: 확장성은 충족하지 못합니다. 확장하려면 새 복제본을 프로비저닝하고 수백 기가바이트에서 수백 테라바이트에 이르는 스토리지를 리하이드레이션해야 하기 때문입니다. 이 모든 과정에는 몇 시간이 걸리므로 몇 초 단위로 빠르게 이루어지는 에이전트 추론 작업의 요구사항과는 전혀 맞지 않습니다. 또한 정적으로 프로비저닝된 컴퓨팅 및 스토리지는 에이전트가 실행을 완료한 후에도 오랫동안 유휴 비용을 계속 발생시킵니다. 

분리된 공유 스토리지 서버 

두 번째 접근 방식은 지속성, 복제를 관리하고 블록 쓰기를 오프로드할 수 있는 커스텀 스토리지 서버의 공유된 멀티 테넌트 계층에서 스테이트리스(Stateless) 컴퓨팅 노드를 분리합니다. 이 접근 방식은 원칙: 지연 시간을 충족합니다. 최적화된 스토리지 서버에 도달하는 읽기 작업에 일관적이고 낮은 운영 지연 시간을 제공하기 때문입니다. 그러나 원칙: 격리는 충족하지 못합니다. 모든 복제본이 기본 인스턴스와 동일한 서버에서 데이터를 읽으므로 에이전트 I/O가 프로덕션 I/O와 직접 경합하게 되어 운명을 공유하기 때문입니다. 또한 원칙: 확장성도 충족하지 못합니다. 데이터가 복사되지 않으므로 스테이트리스(Stateless) 컴퓨팅 복제본이 빠르게 가동되지만 총 스토리지 I/O 대역폭은 사전 프로비저닝된 스토리지 계층으로 고정됩니다. 기본 I/O 용량을 확장하지 않은 채 컴퓨팅 노드만 추가하면 스토리지 포화와 제한이 가속화될 뿐입니다.

공유 블록 서버를 사용하는 객체 스토리지

새롭게 등장한 세 번째 접근 방식은 범용 객체 스토리지에 데이터를 영구적으로 보관하고 공유 블록 서버 계층을 통해 블록 읽기를 처리합니다. 객체 스토리지에서 무작위 읽기 작업을 수행하는 데 수십 밀리초가 걸리기 때문에(기존 데이터베이스 스토리지보다 훨씬 느리고, 적어도 지난 25년 동안 사용되어 온 엔터프라이즈 디스크 어레이보다도 느림) 블록 서버는 핫 데이터를 보관하여 짧은 지연 시간으로 제공할 수 있도록 합니다. 이 접근 방식은 원칙: 지연 시간을 충족하지만 한 가지 주의할 점이 있습니다. 블록 서버에서 캐시 부적중이 발생하면 결국 객체 스토리지에 액세스해야 하므로 지연 시간이 허용하기 어려운 수준으로 높아집니다. 원칙: 격리는 충족하지 못합니다. 복제본이 프로덕션과 블록 서버를 공유하기 때문입니다. 에이전트 I/O와 프로덕션 I/O가 동일한 용량을 사용하므로 해당 용량이 소진되거나 제한되면 에이전트 뿐만 아니라 프로덕션도 영향을 받습니다. 또한 공유 스토리지 서버와 동일한 이유로 원칙: 확장성도 충족하지 못합니다. 복제본은 빠르게 가동할 수 있지만 블록 서버의 I/O는 버스트가 발생해도 그에 맞춰 확장되지 않습니다.

이 계열의 일부 아키텍처는 Apache Spark와 같은 분석 엔진이 데이터베이스 엔진을 우회하여 기본 객체 스토리지를 직접 읽을 수 있도록 하기도 합니다. 분석 워크로드의 경우 이는 가치 있고 실용적인 접근 방식입니다. 그러나 에이전트에는 짧은 지연 시간의 검색이 필요합니다. 색인, 포인트 조회, 벡터 검색을 사용할 수 없게 되면 무차별 대입 테이블 스캔이 강제되어 지연 시간이 폭발적으로 증가하고, 그 결과, 에이전트가 검색-추론 루프를 실행하는 능력이 손상됩니다. 

기존 아키텍처 평가

Google은 사용 가능한 DRAM보다 큰 데이터 세트에 대해 동시 색인 조회를 실행하는 방식으로 공유 블록 서버와 함께 객체 스토리지 아키텍처를 사용하는 상용 서비스를 평가하고 확장 한도와 프로덕션 격리를 모두 테스트했습니다. 단일 리더 인스턴스로 시작하여 최대 8개의 읽기 복제본을 추가하여 워크로드를 확장했습니다.

물리적 리소스를 공유하는 아키텍처에서는 읽기 복제본을 통해 에이전트를 확장하면 복제본과 기본 성능이 모두 빠르게 저하됩니다. 아래 차트에서 볼 수 있듯이 Google의 테스트에서는 복제본을 추가해도 처리량은 2배도 채 늘지 않았으며, 복제본 4개에서 정점을 찍은 후 공유 블록 서버 대역폭이 포화 상태에 이르면서 오히려 감소했습니다.

기본 데이터베이스에 미치는 영향은 즉각적이고 심각했습니다. 복제본이 추가되면서 기본 처리량이 75% 이상 급감했습니다.

요컨대, 기존 아키텍처든 새로운 아키텍처든 모두 에이전트가 요구하는 규모를 충족할 수 없으며, 프로덕션 시스템의 안정성을 위협하지 않으면서 이러한 규모를 지원하는 것은 사실상 불가능합니다.

원칙에 따른 평가

* 부분 충족: 핫 데이터는 블록 서버에서 짧은 지연 시간으로 제공되지만, 블록 서버에서 캐시 부적중이 발생하면 객체 스토리지에 액세스하게 되어 수십 밀리초의 지연 시간이 발생합니다.

각각의 경우 이러한 격차는 단순히 조정으로 해결할 수 있는 문제가 아니라 구조적으로 발생하는 문제입니다. 복제는 각 복제본에 자체 스토리지를 제공하여 격리하므로 해당 스토리지를 채우는 것보다 빠르게 복제본을 추가할 수 없습니다. 공유 스토리지 서버는 스토리지를 공유하여 컴퓨팅을 빠르게 추가하므로 I/O를 격리하거나 확장할 수 없습니다. 객체 스토리지 기반 블록 서버는 프로비저닝된 계층을 통해 지연 시간을 복구하므로 격리할 수도 없고 버스트할 수도 없으며, 모든 캐시 부적중이 발생할 때마다 여전히 객체 스토리지에 액세스해야 합니다. 각각의 접근 방식은 한 레이어의 문제를 해결하고 다른 레이어에서 그에 따른 대가를 치릅니다. 이 세 가지 원칙을 모두 동시에 모두 충족하려면 컴퓨팅, 네트워크, 스토리지를 아우르는 데이터베이스 아키텍처를 새롭게 설계해야 합니다.

스택 전반에서 AlloyDB를 설계한 방법

AlloyDB의 에이전트형 데이터베이스 아키텍처는 Google의 데이터, AI, 인프라 스택 전반에 걸쳐 수직적으로 통합되어 있습니다. 여기에는 AI 모델, 데이터베이스 엔진, 분석 엔진뿐만 아니라 스토리지, 네트워킹, 컴퓨팅 인프라도 포함됩니다.

스토리지: Colossus를 기반으로 사용

지속성 레이어에서 AlloyDB는 Google 검색, YouTube, Gmail, Google Drive, Spanner, Bigtable을 뒷받침하는 Google의 엑사바이트 규모 분산 스토리지 시스템인 Colossus를 기반으로 합니다. 단일 Colossus 클러스터는 엑사바이트 규모의 스토리지와 수만 대의 머신으로 확장됩니다. Google은 Spanner를 통해 Colossus에서 직접 설계된 트랜잭션 데이터베이스가 수천 개의 노드로 확장될 수 있음을 입증했습니다. 새로운 AlloyDB 아키텍처는 에이전트라는 새로운 과제에 동일한 기반을 적용합니다.

Colossus에는 AlloyDB가 세 가지 원칙을 충족할 수 있도록 하는 세 가지 특성이 있습니다.

1. 직접적인 1밀리초 미만의 I/O: Colossus는 읽기 지연 시간을 최소화하도록 설계되었습니다. Colossus 스트림을 여는 데이터베이스 노드는 데이터가 물리적으로 상주하는 위치를 설명하는 핸들을 수신합니다. 승인 및 메타데이터 확인은 스트림이 생성될 때 한 번만 수행됩니다. 이후의 모든 읽기 작업은 최적화된 네트워크 프로토콜을 통해 데이터가 저장된 디스크로 직접 이동합니다. 그 결과 데이터베이스의 모든 데이터에서 1밀리초 미만의 지연 시간이 발생하며, 중간에 워밍할 필요가 없고 계층에서 캐시 부적중도 발생하지 않습니다.

2. 대규모 처리량: Colossus는 대역폭을 프로비저닝할 필요 없이 무제한의 호스트가 동시에 액세스할 수 있으며 단일 AlloyDB 데이터베이스에 최대 15TB/s의 합산 처리량과 초당 2,000만 개의 쿼리 처리 성능을 제공합니다. Colossus 규모에서는 AlloyDB 에이전트 노드 Fleet의 부하를 처리하기 위한 별도의 스토리지가 필요하지 않습니다. AlloyDB 에이전트 노드 Fleet이 발생시키는 부하는 스토리지가 이미 처리하고 있는 부하의 일부이기 때문입니다.

3. 물리적 세그먼트 파티셔닝: AlloyDB는 별도의 Colossus 세그먼트 집합에서 에이전트의 요청을 처리하므로 에이전트 I/O는 프로덕션 데이터 경로와 경합하지 않도록 의도적으로 별도의 경로에 분산됩니다. 

컴퓨팅, 네트워크, 스토리지 등 데이터 경로의 어느 지점에서도 에이전트는 데이터베이스 구성요소를 프로덕션과 공유할 수 없습니다.

네트워크: Jupiter를 통한 확장 가능한 대역폭

컴퓨팅과 스토리지는 Google의 대용량 데이터 센터 네트워크인 Jupiter를 통해 결합됩니다. 단일 Jupiter 패브릭은 10만 대 이상의 서버를 초당 13페타비트의 바이섹션 대역폭으로 연결합니다. 이는 지구상의 모든 사람이 영상 통화를 할 수 있을 만큼 충분한 대역폭입니다.

Jupiter는 네트워킹 패브릭 전반에서 예측 가능한 짧은 지연 시간으로 높은 바이섹션 대역폭을 제공하므로 에이전트 노드를 클러스터 내 어디에든 유연하게 예약하고 중앙 집중식 스토리지에 일관되게 액세스할 수 있습니다. 에이전트 풀이 0에서 수천 개로 확장되더라도 기본 상호 연결 용량이 배치 병목 현상을 일으키지 않고 증가하는 트래픽을 수용합니다.

컴퓨팅: 탄력적인 서버리스 PostgreSQL 및 분석

컴퓨팅 레이어에서 에이전트는 MCP를 통해 AlloyDB의 에이전트 풀에 연결됩니다. 에이전트 풀은 데이터베이스의 최신 상태에 대한 읽기 전용 액세스 권한이 있는 AlloyDB 에이전트 노드로 구성됩니다. 이 레이어는 다음을 제공합니다.

• MicroVM 격리: 각 에이전트 노드는 가볍고 안전한 MicroVM 내에서 실행되는 완전한 기능을 갖춘 PostgreSQL용 AlloyDB 데이터베이스 엔진입니다. 이러한 인스턴스는 서로 완전히 격리되며 전용 기본 클러스터와도 완전히 격리됩니다.

• 빠른 가동 및 확장: 에이전트 노드는 에이전트의 요청에 따라 프로비저닝되며 에이전트의 작업이 완료되면 자동으로 중지됩니다. 버스트에 대응하여 AlloyDB는 수천 개의 에이전트 노드를 빠르게 프로비저닝하여 수백만 개의 동시 에이전트를 처리하고 에이전트가 작업을 완료되면 이를 해제합니다. 에이전트 노드가 활동한 시간을 기준으로 초 단위의 요금이 청구되므로 버스트가 발생하여 수십 초 동안 수천 개의 노드를 사용하더라도 해당 작업에서 실제로 사용한 리소스에 대해서만 요금이 청구됩니다.

한편 프로덕션 클러스터는 현재와 동일하게 유지됩니다. 즉, 레코드 시스템의 용량에 맞춰 사전 프로비저닝된 전용 인프라에서 그대로 운영됩니다. 에이전트 노드는 Colossus에서 직접 읽으며, 1초 미만의 최신 상태가 보장되는 일관된 프로덕션 상태를 확인합니다.

에이전트 풀 뿐만 아니라 BigQuery와 Spark도 프로덕션 클러스터와 동일한 격리 상태로 Colossus에서 AlloyDB 데이터를 읽을 수 있습니다. 따라서 에이전트는 레이크하우스 페더레이션을 사용하여 실시간 운영 데이터를 대규모 레이크하우스 데이터 세트와 조인할 수 있습니다.

Google 규모의 스토리지, 네트워크, 컴퓨팅 레이어를 기반으로 구축된 AlloyDB의 새로운 에이전트형 데이터베이스 아키텍처는 놀라운 목표를 달성합니다. 바로 데이터 공유입니다. 그 외에는 아무것도 공유하지 않습니다.

AlloyDB의 에이전트형 데이터베이스 아키텍처 평가

Google은 사용 가능한 DRAM보다 큰 데이터 세트에서 동시 색인 조회를 실행하여 전체 스택에 걸친 AlloyDB의 확장성을 테스트했습니다. 기존의 읽기 복제본이 아닌 에이전트 풀의 독립적인 데이터베이스 인스턴스인 단일 에이전트 노드로 시작하여 에이전트 워크로드를 실행하고, 단일 데이터베이스에서 수천 개의 노드로 동적으로 확장하여 총 에이전트 처리량과 프로덕션에 미치는 영향을 모두 측정했습니다.

이 테스트에서는 에이전트 노드를 1개에서 10개로 확장하자 처리량이 3,900QPS에서 41,000QPS로 선형적으로 증가했습니다. 여기에서 두 자릿수 더 확장한 결과 최대 1,000개 노드까지 거의 선형적인 성능 확장을 달성했습니다. 테스트 결과는 다음과 같습니다. 

• 기본 클러스터 성능 저하 없음: 에이전트 노드를 1개에서 1,000개로 확장해도 기본 클러스터의 성능에는 측정 가능한 영향이 없었습니다.

• 대규모 처리량: 합산 처리량이 동적으로 773배 증가하여 300만 QPS에 도달했으며, 1,000개의 컴퓨팅 노드에서 Colossus를 통해 800만 IOPS가 넘는 성능을 달성했습니다.

2,100개의 에이전트 노드에서 동시 전체 테이블 스캔을 실행하는 유사한 벤치마크에서는 합산 스캔 처리량이 초당 1테라비트를 초과했습니다.

에이전트 풀은 프로덕션 클러스터와 물리적 인프라를 공유하지 않으므로 팀은 프로덕션 시스템을 위험에 빠뜨리지 않고 추론 Fleet을 수천 개의 노드로 확장할 수 있습니다.

설계 단계부터 세 가지 원칙을 모두 고려한 엔지니어링

아래 표는 AlloyDB의 아키텍처가 세 가지 원칙을 각각 어떻게 충족하는지 보여줍니다.

모든 에이전트형 데이터베이스 아키텍처에는 Colossus의 특성을 갖춘 스토리지, 컴퓨팅과 해당 스토리지를 제약 없이 연결하는 네트워크, 에이전트 규모에 맞춰 프로비저닝하고 해제할 수 있는 컴퓨팅이라는 세 가지 기본 요소가 필요합니다. 

Google은 Google 검색, YouTube, Gmail을 실행하기 위해 20년 넘게 바로 이러한 기반을 구축해 왔습니다. 그리고 이제 그 기반이 에이전트형 데이터베이스 아키텍처의 기반이 되었습니다.

프로덕션에 영향을 주지 않고 에이전트에 실시간 데이터 제공

AI를 활용해 빌드하는 모든 조직은 동일한 근본적 딜레마에 직면합니다. 바로 비즈니스를 운영하는 시스템을 위험에 빠뜨리지 않으면서 에이전트가 실시간 운영 데이터에 완전히 액세스할 수 있게 하려면 어떻게 해야 하는가입니다. 지금까지는 애플리케이션 요구사항이 아니라 아키텍처가 이러한 선택을 좌우했습니다. 에이전트에 데이터베이스에 대한 직접 액세스 권한을 부여한다는 것은 미션 크리티컬 시스템을 예측할 수 없는 부하, 심각한 리소스 경합, 프로덕션 중단의 위험에 노출한다는 것을 의미했습니다.

이 세 가지 원칙을 기반으로 빌드된 아키텍처는 이러한 타협을 완전히 없애줍니다. 에이전트는 1초 미만의 최신 상태를 유지하는 실시간 프로덕션 데이터를 기반으로 추론합니다. 또한 1밀리초 미만의 I/O 지연 시간으로 모든 색인, 벡터, 전체 텍스트 및 공간 검색, SQL의 전체 기능을 비롯한 완전한 엔진을 자유롭게 활용할 수 있습니다. 이 아키텍처는 에이전트가 필요로 할 때 수천 개의 격리된 노드로 동적으로 확장되고, 에이전트가 작업을 완료하면 다시 0으로 축소됩니다. 이 과정에서 핵심 트랜잭션 워크로드는 전혀 영향을 받지 않습니다. 공유되는 구성요소도 할당량도 없으며, 관련 장애도 나타나지 않습니다. 따라서 에이전트는 비즈니스 연속성을 저해하지 않으면서 혁신을 실현할 수 있습니다.

이러한 특성은 프로덕션 데이터를 읽는 다른 모든 워크로드로 확장됩니다. 보고, 분석, 애플리케이션은 프로덕션을 위험에 빠뜨리지 않고 실시간 데이터를 자유롭게 읽을 수 있으므로 지난 50년 동안 운영 데이터베이스를 좌우해 온 제약에서 벗어날 수 있습니다.

기업의 레코드 시스템에 있는 데이터는 기업이 보유한 가장 소중한 자산입니다. 이러한 기반을 바탕으로 마침내 그러한 데이터의 가치를 온전히 활용할 수 있습니다.

데이터베이스가 드디어 제약에서 벗어난 것입니다.

자세히 알아보려면 문서 페이지를 방문하고 여기에서 가입하여 시작하세요.