Google Cloud SQL
Google Cloud SQL은 MySQL, PostgreSQL, SQL Server를 관리형으로 제공하는 관계형 데이터베이스입니다. 운영자가 패치와 백업, 복제를 직접 붙들지 않아도 되게 해 주면서, 트랜잭션이 중요한 애플리케이션의 표준 데이터 계층이 됩니다.
▶아키텍처 다이어그램
🔍 구조 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
관계형 DB를 직접 운영하면 설치, 패치, 백업, 복제, 장애 조치가 모두 운영자의 책임입니다. 서비스가 커질수록 DB를 지키는 일이 개발보다 더 큰 부담이 됩니다.
예전의 관계형 DB는 서버 한 대를 직접 돌리며 관리하는 방식이 기본이었습니다. 규모가 커질수록 패치와 백업, 복구 절차가 반복되면서 관리 작업 자체가 제품 개발을 잠식했고, 관리형 DB가 그 부담을 흡수했습니다.
애플리케이션은 SQL로 Cloud SQL 인스턴스에 연결합니다. 서비스가 엔진과 인스턴스 상태를 관리하고, 자동 백업과 복제본, 장애 조치가 운영 부담을 줄입니다. 애플리케이션은 익숙한 MySQL, PostgreSQL, SQL Server 모델을 그대로 사용합니다.
Cloud SQL과 Firestore는 둘 다 애플리케이션 데이터를 저장하지만, Cloud SQL은 테이블과 조인으로 정형 데이터를 다루고 Firestore는 문서 구조로 유연한 스키마와 실시간 동기화에 맞습니다. Cloud SQL과 Spanner는 둘 다 관계형 데이터를 다루지만, Cloud SQL은 한 리전에서 익숙한 DB 운영을 유지하는 쪽이고 Spanner는 여러 리전에 걸쳐 분산 합의로 확장하는 쪽입니다. 운영 데이터의 OLTP면 Cloud SQL, 화면 동기화 중심의 문서 모델이면 Firestore, 전 세계 단위의 일관성과 확장이 필요하면 Spanner가 맞습니다.
Firestore
실시간 문서 DB
둘 다 애플리케이션 데이터를 저장하지만, Cloud SQL은 테이블과 조인으로 정형 데이터를 다루고 Firestore는 문서 구조로 유연한 스키마와 실시간 동기화에 맞습니다.
BigQuery
대규모 분석 SQL
둘 다 SQL을 쓰지만, Cloud SQL은 트랜잭션 처리에 맞고 BigQuery는 대규모 집계와 분석에 맞습니다.
Spanner
분산 관계형 DB
둘 다 관계형 데이터를 다루지만, Cloud SQL은 한 리전 안에서 익숙한 운영을 유지하고 Spanner는 여러 리전에 걸쳐 일관성을 유지하며 확장합니다.
Cloud Storage
객체 저장소
둘 다 영속 저장소이지만, Cloud SQL은 행과 관계를 다루는 데이터베이스이고 Cloud Storage는 파일과 객체를 통째로 보관하는 저장소입니다.
Memorystore
인메모리 캐시
둘 다 애플리케이션이 읽는 데이터를 받지만, Cloud SQL은 원본 데이터를 보관하는 데이터베이스이고 Memorystore는 그 앞에서 읽기를 줄이는 캐시 계층입니다.
주문, 결제, 사용자 계정처럼 정확한 쓰기와 읽기 순서가 중요한 운영 데이터에 적합합니다. 기존 SQL 애플리케이션을 크게 바꾸지 않고 클라우드로 옮기려는 흐름에도 잘 맞습니다.