클라우드 관리형 데이터베이스(RDS/Aurora/Cloud SQL/Atlas/Azure SQL)
증상
목표: 클라우드 관리형 데이터베이스와 자체 관리 설치의 핵심 차이를 익히고, 클라우드에서 백업, 파라미터, 페일오버, 모니터링, 업그레이드, 연결이 어떻게 동작하는지 이해한다.
1. 사고방식 전환: 서버가 아니라 서비스에 접근한다
관리형 데이터베이스에서는 OS, 파일 시스템, 데이터베이스 프로세스에 대한 셸 접근이 없다. SSH 접속, 구성 파일 수동 편집, superuser 권한 획득이 불가능하다. 제공업체의 관리 API/콘솔과 일반 SQL 연결만 주어진다. AWS RDS/Aurora: 관리는 리소스(인스턴스/클러스터) 수준이며 서버는 숨겨져 있다. GCP Cloud SQL: 인스턴스 API만 있고 OS는 없다. MongoDB Atlas: 완전 관리형 클러스터로 mongod에 접근할 수 없다. Azure SQL Database: PaaS로 그 아래의 서버도 OS도 보이지 않는다(Managed Instance는 다소 더 많은 제어를 제공). 따라서 '파일을 본다', '프로세스를 종료한다', 'OS 도구를 실행한다' 같은 자체 관리 습관 대부분이 적용되지 않는다.
2. 백업: 자동 스냅샷 + 시점 복구(PITR)
백업을 직접 스케줄링하지 않으며 제공업체가 자동으로 수행한다. 복구는 대개 '특정 시점으로 복원'(PITR)하거나 스냅샷에서 새 인스턴스를 만드는 방식이며, 기존 인스턴스는 덮어쓰지 않는다. AWS RDS/Aurora: 자동 백업 + retention 기간. 초 단위 정밀도의 PITR 복원은 새 인스턴스/클러스터로 열린다. 수동 스냅샷도 가능하다. GCP Cloud SQL: 자동 백업 + binary log 기반 PITR, 복원은 새 인스턴스로 간다. MongoDB Atlas: 연속 클라우드 백업 + PITR(M10+), 스냅샷에서 복원. Azure SQL: 내장 자동 백업, 1-35일 보관, 임의 시점 PITR 및 삭제된 DB 복원. 공통 규칙: 백업 구성(시간대, 보관 기간)을 확인하고 정기적으로 복원 테스트를 실행한다.
3. 파라미터: 구성 파일이 아니라 parameter group / flag
postgresql.conf나 my.cnf를 직접 편집하는 대신 제공업체의 파라미터 추상화를 사용한다. 일부 파라미터는 잠겨 있고 일부는 재시작이 필요하다(static). AWS RDS/Aurora: DB parameter group(및 cluster parameter group)으로 설정하며, 동적 파라미터는 즉시, static 파라미터는 reboot 시 적용된다. GCP Cloud SQL: 콘솔/gcloud에서 'database flags'를 설정한다. MongoDB Atlas: 제한된 'Additional Settings' + oplog 크기 등, 대부분의 내부 파라미터는 관리형이다. Azure SQL: 대부분의 서버 수준 설정은 관리형이며, SCOPED CONFIGURATION과 서비스 티어 선택으로 동작이 바뀐다. 적용 전에 파라미터가 동적인지 static인지 확인한다.
4. 고가용성 / 페일오버: 관리형 Multi-AZ와 replica
페일오버를 직접 구축하지 않고 체크박스를 선택해 제공업체에 맡긴다. standby와 자동 페일오버는 관리형이며, 연결은 안정적인 endpoint를 통해 새 primary로 리디렉션된다. AWS RDS: Multi-AZ(동기 standby, 자동 페일오버). Aurora: 다중 사본 스토리지 + 자동 페일오버, cluster endpoint가 writer를 가리킨다. GCP Cloud SQL: 클릭 한 번으로 HA 구성(리전, 보조 존에 standby), read replica는 별도로 추가한다. MongoDB Atlas: replica set 내장, 멀티 리전/멀티 클라우드 배포 가능, 페일오버 자동. Azure SQL: 내장 HA(Business Critical의 로컬 replica), zone-redundant 옵션, 리전 간 active geo-replication / failover group. 애플리케이션은 고정 IP가 아니라 항상 endpoint에 연결해야 한다.
5. 모니터링: 제공업체의 지표 및 로그 서비스
OS 도구(top, iostat)를 실행할 수 없으므로 제공업체의 지표 플랫폼으로 모니터링한다. CPU, 연결 수, IOPS, 복제 지연, 스토리지 지표가 그곳에 있다. AWS: CloudWatch 지표 + Enhanced Monitoring + Performance Insights(쿼리 수준 분석). GCP Cloud SQL: Cloud Monitoring(구 Stackdriver) + Query Insights. MongoDB Atlas: 내장 Atlas 지표/차트 + Performance Advisor + 실시간 패널. Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight. 항상 임계값 알람(스토리지 사용량, CPU, 연결 한도, replica 지연)을 설정한다.
6. 버전 업그레이드와 유지보수: 콘솔에서, 유지보수 시간대에
바이너리를 직접 업데이트하는 대신 대상 버전을 선택한다. 마이너 버전 패치는 대부분 자동이며, 메이저 버전 업그레이드는 계획하여 수행하고 대개 다운타임/HA 페일오버를 수반한다. AWS RDS/Aurora: 엔진 버전 선택 + 자동 마이너 업그레이드 옵션 + Blue/Green Deployments를 이용한 저위험 메이저 업그레이드. GCP Cloud SQL: 유지보수 시간대 + 셀프서비스 메이저 버전 업그레이드. MongoDB Atlas: 클릭 한 번 버전 업그레이드, rolling 방식으로 거의 무중단. Azure SQL: 플랫폼이 자동으로 패치한다(버전 개념은 대부분 추상화됨). 동작은 compatibility level로 제어한다. 항상 테스트/staging 사본에서 먼저 시도하고 유지보수 시간대는 업무 시간 외로 잡는다.
7. 연결과 보안: endpoint + IAM/TLS
연결은 항상 제공업체가 제공하는 DNS endpoint를 통하며 암호화(TLS)된다. 네트워크 접근과 신원은 클라우드 ID 시스템에 연동할 수 있다. AWS RDS/Aurora: 인스턴스/클러스터 endpoint + 네트워크용 Security Group + 선택적 IAM 데이터베이스 인증 + TLS(rds-ca 인증서). GCP Cloud SQL: public IP + Authorized Networks 또는 private IP/VPC, Cloud SQL Auth Proxy, IAM 데이터베이스 인증, TLS. MongoDB Atlas: SRV 연결 문자열(mongodb+srv://), IP access list + private endpoint/peering, SCRAM 또는 IAM/X.509, TLS 필수. Azure SQL: 서버 FQDN endpoint + 방화벽/Private Link + Microsoft Entra ID(구 Azure AD) 인증 + TLS 필수. 규칙: 연결 문자열에는 고정 IP가 아니라 endpoint를 사용하고, TLS를 강제하며, 가능하면 클라우드 IAM ID로 연결한다.