Cloud SQL과 AlloyDB, 무엇이 다른가
GCP에서 관계형 데이터베이스를 운영할 때 선택지는 세 가지로 좁혀진다. Cloud SQL, AlloyDB, 그리고 GKE 위에서 직접 운영하는 자체 관리형 PostgreSQL/MySQL이다.
Cloud SQL은 MySQL, PostgreSQL, SQL Server를 지원하는 범용 매니지드 데이터베이스 서비스다. 2024년 기준으로 두 에디션으로 나뉜다. Enterprise와 Enterprise Plus가 있고, Plus는 데이터 캐시·99.99% SLA·무중단 유지보수를 추가한다.
AlloyDB는 PostgreSQL 전용이다. Google이 스토리지 레이어를 직접 재설계했다. Aurora가 MySQL/PostgreSQL 엔진을 AWS 분산 스토리지 위에 올린 것처럼, AlloyDB는 PostgreSQL 엔진 아래에 Google의 분산 스토리지와 인텔리전트 캐시 레이어를 배치했다. OLTP 성능과 분석 쿼리 가속을 동시에 목표로 한다.
이 두 선택지의 차이를 이해하려면 내부 아키텍처부터 봐야 한다.
Cloud SQL 아키텍처와 HA
리전 영구 디스크 기반 HA
Cloud SQL의 HA는 리전 영구 디스크(Regional Persistent Disk) 위에서 동작한다. 2025년 1월 이후 레거시 HA 설정은 공식 Deprecated 되었고, 현재 모든 HA 인스턴스는 이 방식을 사용한다.
동작 방식은 간단하다. 하나의 리전 안에서 두 개의 존에 걸쳐 디스크를 동기 복제한다. Primary 인스턴스가 트랜잭션을 커밋하기 전에, 두 존의 디스크 모두에 쓰기가 완료되어야 응답을 돌려준다. 이것이 RPO = 0을 보장하는 이유다.
페일오버 절차는 다음과 같다.
- heartbeat 시스템이 1초 간격으로 Primary 상태를 확인한다.
- 여러 번 연속으로 heartbeat가 누락되면 페일오버를 시작한다.
- Standby 인스턴스가 새 Primary로 전환된다.
- 기존 Primary와 읽기 복제본의 연결이 끊기고, ~60초 후에 재연결된다.
- 전환 완료 후 Cloud SQL이 DNS를 업데이트하여 새 Primary를 가리킨다.
중요한 점: Standby는 읽기 트래픽을 받지 않는다. HA 구성에서 읽기를 분산하려면 별도로 읽기 복제본을 생성해야 한다. 읽기 복제본은 페일오버 기능이 없고, HA Standby는 읽기 트래픽을 받지 않는다. 두 역할은 명확히 분리되어 있다.
Enterprise vs Enterprise Plus
| 항목 | Enterprise | Enterprise Plus |
|---|---|---|
| SLA | 99.95% (유지보수 제외) | 99.99% (유지보수 포함) |
| 데이터 캐시 | 없음 | 로컬 SSD 기반, 읽기 최대 4배 향상 |
| 유지보수 다운타임 | 표준 | 서브초(< 1초) |
| 쓰기 처리량 | 표준 | 최대 2배 향상 |
| 쿼리 인사이트 | 기본 | 고급 (Wait Event, 실행계획 샘플) |
| 스토리지 | 일반 네트워크 블록 | Hyperdisk Balanced |
| 가격 (us-central1) | ~$0.0413/vCPU-hr | Enterprise 대비 약 30% 높음 |
Enterprise Plus의 데이터 캐시는 hot working set이 shared_buffers를 초과하는 워크로드에서 실질적 개선을 가져온다. 플래시 메모리를 DRAM 캐시의 확장으로 사용하는 방식으로, 읽기 지연을 줄이고 대용량 데이터셋의 처리량을 높인다.
스토리지 한도: 전용 코어 인스턴스 기준 최대 64 TB. 자동 증가 기능이 켜져 있으면 30초마다 여유 공간을 확인하고, 임계값(통상 25 GB) 미만 시 자동으로 25 GB를 추가한다.
MySQL vs PostgreSQL: HA와 복제의 차이
두 엔진 모두 동일한 리전 영구 디스크 기반 HA 메커니즘을 사용한다. 차이는 읽기 복제본의 복제 방식에 있다.
MySQL 복제본: 바이너리 로그(binlog) 기반 복제. sync_binlog=1, innodb_support_xa=true 설정으로 내구성을 보장한다. 위치 기반(Binlog Position) 복제는 페일오버 시 binlog 히스토리가 달라져 복제가 깨질 수 있다. 프로덕션 HA 환경에서는 GTID 기반 복제를 권장한다.
PostgreSQL 복제본: WAL 스트리밍 복제. Primary가 WAL 레코드를 실시간으로 Replica에 전송하고, Replica가 이를 재생하여 동기화한다. 재해 복구(DR) 시나리오에서는 읽기 복제본을 Primary로 수동 승격(Promote)할 수 있다.
두 엔진 공통: 읽기 복제본은 자동 페일오버를 제공하지 않는다. HA Standby가 자동 페일오버를 담당한다.
AlloyDB 아키텍처: 세 레이어 분리
AlloyDB는 PostgreSQL 컴퓨트 레이어와 스토리지 레이어를 물리적으로 분리했다. Aurora가 AWS 분산 스토리지(6-way 복제)를 사용하는 것과 구조적으로 유사하지만, 인텔리전트 캐시와 컬럼형 엔진이 통합된 점이 다르다.
스토리지 레이어 세 가지 서비스
스토리지 레이어는 역할이 분리된 세 서비스로 구성된다.
Log Storage Service: Primary가 WAL을 커밋할 때 먼저 이 서비스에 저장된다. 저지연이 목표다. 3개 존이 리전 로그 스토리지 시스템을 통해 지속적으로 업데이트된다.
Log Processing Service: Log Storage에서 WAL 레코드를 가져와 비동기로 실제 데이터 블록으로 변환한다. 이 처리가 컴퓨트 레이어와 분리되어 있기 때문에 AlloyDB의 Primary는 체크포인트 I/O 부하가 없다. Read Pool 노드는 이 서비스로부터 최신 데이터 블록을 받는다.
Block Storage Service: 최종 데이터 블록을 3개 존에 걸쳐 내구성 있게 저장한다. 존 단위 샤딩과 복제를 병행한다.
이 구조 덕분에 Primary, Hot Standby, Read Pool 노드들이 동일한 스토리지를 공유한다. Read Pool 추가 시 데이터를 복제할 필요가 없다. 스토리지 비용이 한 번만 발생한다는 의미다.
컬럼형 엔진 (Columnar Engine)
AlloyDB의 컬럼형 엔진은 PostgreSQL 쿼리 플래너와 통합된 인메모리 컬럼 스토어다.
작동 방식:
- 인스턴스 메모리의 기본 30%를 컬럼 스토어로 할당한다. 인스턴스 크기를 변경하면 자동으로 재조정된다.
- 컬럼 데이터를 열 지향 포맷으로 재구성해 메모리에 올린다.
- 자동 컬럼화(Auto-columnarization): 쿼리 패턴을 모니터링하여 자주 스캔되는 컬럼을 자동으로 컬럼 스토어에 추가한다. 수동 지정도 가능하다.
- 벡터화 조인: 컬럼형 데이터에 벡터화 처리를 적용. PostgreSQL 해시 조인 대신 벡터화 조인 연산자를 선택할 수 있다. 쿼리 플래너가 비용을 비교해 결정한다.
- 메모리가 부족하면 Ultra-fast Cache 디스크로 스필오버한다.
구글이 주장하는 분석 쿼리 가속: 표준 PostgreSQL 대비 최대 100배. 이 수치는 집계·조인·스캔이 집중된 OLAP 패턴에서 측정된 것이다. 단순 OLTP 쿼리에는 영향이 없다.
HA와 페일오버
AlloyDB HA의 핵심은 Hot Standby다. Standby 노드가 항상 PostgreSQL을 실행하면서 WAL을 지속적으로 재생한다. 페일오버 시 PostgreSQL 기동 단계가 없다.
- 탐지: 장애 감지 약 30초 이내
- 전환: PostgreSQL 18+ 기준 약 15초 (Hot Standby 적용 시)
- 공식 RTO: 60초 미만 (데이터베이스 크기·부하 무관)
- RPO: 1초 미만 (스토리지 레이어가 3존에 걸쳐 동기 업데이트)
- SLA: 99.99% (유지보수 포함)
버퍼 캐시도 warm 상태로 유지된다. Hot Standby는 Primary와 동일한 스토리지에 접근하며 WAL을 재생하므로, 페일오버 후 새 Primary의 캐시가 이미 어느 정도 워밍업된 상태다.
읽기 풀 (Read Pool)
Read Pool은 AlloyDB의 읽기 확장 단위다. Cloud SQL의 읽기 복제본과 비교되지만 구조적으로 다르다.
- 동일한 스토리지 레이어를 공유하므로 복제 지연이 최소화된다.
- 노드 2개 이상이면 HA 구성: 존 간에 노드가 분산되고, 장애 시 리전 로드 밸런서가 정상 노드로 트래픽을 우회한다.
- Primary와 독립적으로 스케일 인/아웃 가능하다.
- 읽기 풀에 노드를 추가할 때 데이터 복사가 불필요하다.
연결 관리
Cloud SQL Auth Proxy v2
Cloud SQL Auth Proxy는 IAM 기반 인증과 TLS 1.3 암호화를 제공하는 사이드카 프로세스다. v2는 Go로 재작성되었고 관측성이 강화되었다.
동작 방식:
- 애플리케이션이 localhost:5432(또는 지정 포트)로 일반 연결을 보낸다.
- Auth Proxy가 이를 수신하고, Cloud SQL API에서 단기 인증서를 발급받아 암호화된 터널로 인스턴스에 전달한다.
- 인증서는 자동으로 갱신된다. 애플리케이션이 인증서 관리를 직접 할 필요가 없다.
연결 모드:
- TCP (기본):
localhost:<port>수신 - Unix 도메인 소켓:
--unix-socket플래그 (MySQL 8.4에서 caching_sha2_password 버그 있음) - Private IP:
--private-ip플래그 (네트워크 접근은 별도 구성 필요)
주요 설정:
--auto-iam-authn # IAM 자동 데이터베이스 인증
--lazy-refresh # 서버리스 환경용, 필요 시 연결 정보 로드
--impersonate-service-account # 다른 서비스 계정으로 위임
--telemetry-project # Cloud Monitoring, Cloud Trace 활성화설정은 CLI 플래그, 환경 변수(CSQL_PROXY_ 접두사), TOML/JSON/YAML 파일로 관리한다.
권장: 하나의 Auth Proxy를 여러 애플리케이션이 공유하지 말 것. IAM Principal이 불분명해진다.
Cloud SQL Language Connectors
Go, Java, Python, Node.js 환경에서는 Auth Proxy 대신 Language Connector 라이브러리를 직접 삽입하는 것이 권장된다.
Auth Proxy와 동일한 IAM 인증 + TLS 1.3 기능을 인프로세스로 제공한다. 별도의 사이드카 프로세스가 불필요하다. SSL 인증서를 직접 배포할 필요도 없다.
별도 프로세스 필요
사이드카 불필요
AlloyDB 관리형 커넥션 풀
AlloyDB는 PgBouncer 호환 관리형 커넥션 풀(Managed Connection Pooling)을 내장한다. 별도 PgBouncer 인스턴스를 배포·관리할 필요가 없다.
- 포트: 5432 (직접 연결), 6432 (풀을 통한 연결)
- 모드:
- Transaction Mode (기본): 트랜잭션 단위로 연결 할당. 최대 동시성 제공. SET, 세션 Advisory Lock, LISTEN, 프로토콜 레벨 Prepared Statement 등 세션 상태 의존 기능과 비호환. - Session Mode: 세션 전체에 연결 유지. 모든 PostgreSQL 기능 호환. 멀티플렉싱 효율은 낮음.
- 효과: 클라이언트 연결 3배 증가, 트랜잭션 처리량 최대 5배 향상
- PgBouncer
SHOW STATS,SHOW POOLS,SHOW CLIENTS명령 지원 - AlloyDB Auth Proxy, Language Connector와 함께 사용 가능
권장 설정: vCPU당 15~20개 풀러 연결. 애플리케이션 풀(HikariCP 등)은 각 인스턴스당 5~10개 연결을 풀러로 보내고, 풀러가 소수의 실제 DB 연결로 멀티플렉싱한다.
2024년 11월 이전에 생성된 AlloyDB 인스턴스는 관리형 풀 활성화를 위해 네트워크 설정을 1회 업데이트해야 한다. 약 15초의 일시적 연결 중단이 발생한다.
Cloud Monitoring 핵심 메트릭
Cloud SQL 메트릭 타입 앞에는 cloudsql.googleapis.com/ 접두사가 붙는다.
컴퓨트·메모리
| 메트릭 | 설명 | 권장 임계값 |
|---|---|---|
database/cpu/utilization | CPU 사용률 (0~1) | 0.8 (80%) 이상 경고 |
database/memory/utilization | 메모리 사용률 | 0.8 이상 경고 |
database/memory/quota | 할당된 메모리 (bytes) | 용량 계획 참고 |
디스크·I/O
| 메트릭 | 설명 | 비고 |
|---|---|---|
database/disk/utilization | 디스크 사용률 | 자동 증가 미설정 시 주의 |
database/disk/bytes_used | 사용 중인 디스크 바이트 | 급증 패턴 모니터링 |
database/disk/read_ops_count | 디스크 읽기 I/O 수 | |
database/disk/write_ops_count | 디스크 쓰기 I/O 수 |
연결·복제
| 메트릭 | 엔진 | 설명 |
|---|---|---|
database/postgresql/num_backends | PostgreSQL | 현재 활성 연결 수 |
database/postgresql/num_backends_by_state | PostgreSQL | 상태별 연결 수 |
database/network/connections | MySQL, SQL Server | 현재 연결 수 |
database/replication/replica_lag | 공통 | 복제 지연 (초). 읽기 복제본 스테일 데이터 감지 |
database/replication/network_lag | 공통 | 네트워크 지연 (최대 25초 보고, 실제 지연은 더 클 수 있음) |
주의: network_lag는 실제 복제 지연이 25초를 초과해도 최대 25초로 표시한다. 정확한 복제 지연은 replica_lag를 함께 확인해야 한다.
AlloyDB는 자체 System Insights 메트릭을 별도로 제공한다 (alloydb.googleapis.com/ 접두사).
비용 구조
가격 구성 비교 (us-central1 기준, 2025년)
| 항목 | Cloud SQL Enterprise | AlloyDB |
|---|---|---|
| vCPU | ~$0.0413/시간 | ~$0.0661/시간 |
| RAM | ~$0.007/GB-시간 | ~$0.0112/GB-시간 |
| SSD 스토리지 | ~$0.17/GB-월 | ~$0.34/GB-월 |
| 백업 스토리지 | ~$0.08/GB-월 | ~$0.113/GB-월 |
| I/O 요금 | 없음 (포함) | 없음 (별도 청구 안 함) |
| 네트워크 (교차 리전) | $0.02~0.14/GB | $0.02~0.14/GB |
Open question: 위 가격은 2025년 중반 기준 참고치다. 실제 과금은 공식 Google Cloud 가격 계산기에서 확인 필요.
커밋된 사용 할인 (Committed Use Discounts)
Cloud SQL과 AlloyDB 모두 동일한 구조를 적용한다.
| 약정 기간 | 할인율 | 실지불 비율 |
|---|---|---|
| 1년 약정 | 25% | 75% |
| 3년 약정 | 52% | 48% |
AlloyDB CUD는 컴퓨트(vCPU, RAM)에만 적용된다. 스토리지, 백업, 네트워크 이그레스는 CUD 대상이 아니다.
비용 분기점
AlloyDB 컴퓨트 비용은 Cloud SQL Enterprise 대비 약 60% 높다. 그런데 스토리지 측면에서는 다른 계산이 적용된다.
Cloud SQL에서 HA + 읽기 복제본을 구성하면 스토리지 비용이 세 배로 쌓인다. Primary 스토리지 + Standby 스토리지 + 복제본 스토리지 각각이 별도로 과금된다.
AlloyDB는 Primary, Standby, Read Pool 모두가 하나의 분산 스토리지를 공유한다. 스토리지 비용은 단 한 번 발생한다.
스토리지 규모가 약 1.75 TiB를 넘어가는 시점부터 AlloyDB의 스토리지 절감이 높은 컴퓨트 비용을 상쇄하기 시작한다는 분석이 있다. 단, 워크로드에 따라 분기점은 달라진다.
Cloud SQL vs AlloyDB vs GKE 자체 운영 비교
| 항목 | Cloud SQL Enterprise | Cloud SQL Enterprise Plus | AlloyDB | 자체 운영 (GKE) |
|---|---|---|---|---|
| 지원 엔진 | MySQL, PG, SQL Server | MySQL, PG, SQL Server | PostgreSQL 전용 | MySQL, PG, 그 외 모두 |
| SLA | 99.95% | 99.99% | 99.99% | 사용자 책임 (SLA 없음) |
| HA 방식 | Regional Disk 동기 복제 | Regional Disk + Hyperdisk | 분산 스토리지 + Hot Standby | Patroni/Pacemaker 등 직접 구성 |
| RTO | ~60초 | ~60초 | < 60초 (PG18+: ~15초) | 구성에 따라 수분~ |
| 분석 가속 | 없음 | 데이터 캐시 (OLTP 중심) | 컬럼형 엔진 (최대 100x) | 없음 (직접 구성 가능) |
| 커넥션 풀 | Auth Proxy / Connector | Auth Proxy / Connector | 내장 관리형 풀(PgBouncer) | PgBouncer 직접 운영 |
| 스토리지 한도 | 64 TB (전용 코어) | 64 TB (전용 코어) | 별도 제한 (Open question) | GKE PVC 크기 제한까지 |
| 운영 부담 | 낮음 (패치·백업 자동) | 낮음 | 낮음 | 높음 (패치, 백업, HA 직접) |
| 컨트롤 수준 | 제한적 (OS 접근 불가) | 제한적 | 제한적 | 완전 제어 (OS, 커스텀 빌드) |
| 컴퓨트 단가 | ~$0.0413/vCPU-hr | ~$0.054/vCPU-hr (추정) | ~$0.0661/vCPU-hr | GCE 단가 (더 낮음) |
선택 기준 정리
Cloud SQL Enterprise가 적합한 경우:
- MySQL이 필요한 경우 (AlloyDB는 PostgreSQL만 지원)
- 표준 OLTP 워크로드, 분석 가속 불필요
- 비용을 최소화해야 하는 스타트업, 소규모 서비스
Cloud SQL Enterprise Plus가 적합한 경우:
- 99.99% SLA가 필요하지만 AlloyDB의 PostgreSQL 전용 제약이 맞지 않는 경우
- Hot working set이 shared_buffers를 자주 초과하는 읽기 중심 OLTP
- 유지보수 다운타임 허용 범위가 매우 좁은 경우
AlloyDB가 적합한 경우:
- PostgreSQL 전용, 고성능 OLTP + 분석 혼합 워크로드 (HTAP)
- 읽기 확장이 중요하고 복제 지연 최소화가 필요한 경우
- 데이터가 수 TiB 이상으로 성장하여 스토리지 공유 이점이 발생하는 경우
- 관리형 커넥션 풀을 추가 인프라 없이 사용하고 싶은 경우
GKE 자체 운영이 적합한 경우:
- OS 수준 접근, 커스텀 PostgreSQL 빌드, 지원되지 않는 Extension이 필요한 경우
- 매니지드 서비스 벤더 종속이 허용되지 않는 경우
- 엔지니어링 역량이 충분하고 운영 비용보다 컴퓨트 단가 절감이 우선인 경우
운영자 체크리스트
Cloud SQL 신규 구성 시:
- [ ] Enterprise vs Enterprise Plus 에디션 선택 (SLA, 데이터 캐시 필요 여부)
- [ ] HA 활성화: 리전 영구 디스크 방식 확인 (레거시 방식 미사용)
- [ ] 읽기 복제본: 별도 생성 필요, 페일오버 역할과 분리 인식
- [ ] 자동 스토리지 증가 설정 및 알림 임계값 구성
- [ ] Auth Proxy 또는 Language Connector 선택 (Go/Java/Python → Connector 권장)
- [ ] MySQL: GTID 기반 복제 활성화 (binlog 위치 기반 복제 지양)
AlloyDB 신규 구성 시:
- [ ] Read Pool 노드 2개 이상으로 구성 (존 장애 내성)
- [ ] 관리형 커넥션 풀 활성화 (포트 6432, Transaction Mode 기본)
- [ ] 2024년 11월 이전 인스턴스: 네트워크 설정 업데이트 필요 (15초 중단)
- [ ] 컬럼형 엔진 활성화 후 Auto-columnarization 동작 확인
- [ ] vCPU당 풀러 연결 15~20개로 조정
모니터링 공통:
- [ ] database/cpu/utilization > 0.8 알림
- [ ] database/memory/utilization > 0.8 알림
- [ ] database/replication/replica_lag 기저선 설정 및 이상 알림
- [ ] database/postgresql/num_backends → max_connections의 80% 초과 알림References
- Google Cloud Documentation, "About high availability | Cloud SQL for MySQL": https://docs.cloud.google.com/sql/docs/mysql/high-availability
- Google Cloud Documentation, "About high availability | Cloud SQL for PostgreSQL": https://docs.cloud.google.com/sql/docs/postgres/high-availability
- Google Cloud Blog, "Understanding Cloud SQL high availability": https://cloud.google.com/blog/products/databases/understanding-cloud-sql-high-availability
- Google Cloud Documentation, "AlloyDB overview": https://docs.cloud.google.com/alloydb/docs/overview
- Google Cloud Documentation, "About the AlloyDB columnar engine": https://docs.cloud.google.com/alloydb/docs/columnar-engine/about
- Google Cloud Documentation, "AlloyDB high availability overview": https://docs.cloud.google.com/alloydb/docs/high-availability
- Google Cloud Blog, "AlloyDB Hot Standby: Faster Failovers & Consistent Performance": https://cloud.google.com/blog/products/databases/alloydb-hot-standby-faster-failovers-and-consistent-performance
- Google Cloud Blog, "AlloyDB for PostgreSQL intelligent scalable storage": https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage
- Google Cloud Documentation, "Configure managed connection pooling | AlloyDB": https://docs.cloud.google.com/alloydb/docs/configure-managed-connection-pooling
- InfoQ, "Google Introduces Managed Connection Pooling for AlloyDB": https://www.infoq.com/news/2026/01/alloydb-managed-connection-pool/
- GoogleCloudPlatform/cloud-sql-proxy (GitHub README): https://github.com/GoogleCloudPlatform/cloud-sql-proxy
- Google Cloud Documentation, "AlloyDB pricing": https://cloud.google.com/alloydb/pricing
- Google Cloud Documentation, "Committed use discounts | AlloyDB": https://docs.cloud.google.com/alloydb/cud
- Google Cloud Documentation, "Cloud SQL editions overview (PostgreSQL)": https://docs.cloud.google.com/sql/docs/postgres/editions-intro
- Bytebase, "AlloyDB vs. Cloud SQL: engineering guide (2025)": https://www.bytebase.com/blog/alloydb-vs-cloudsql/
- Medium/Google Cloud, "Cloud SQL Enterprise Plus vs. AlloyDB: pgbench Showdown": https://medium.com/google-cloud/cloud-sql-enterprise-plus-vs-alloydb-a-pgbench-showdown-for-high-performance-oltp-20a3fe75d9ff