Amazon Aurora 및 Amazon RDS for PostgreSQL 아키텍처와 기능 심층 분석
발행: (2025년 12월 12일 오후 09:49 GMT+9)
10 min read
원문: Dev.to
Source: Dev.to
Introduction
자체 호스팅 PostgreSQL 데이터베이스를 마이그레이션하거나 상용 데이터베이스를 AWS의 PostgreSQL로 전환하려는 경우, 요구 사항에 가장 잘 맞는 데이터베이스 서비스를 선택해야 합니다. AWS에서는 두 가지 관리형 PostgreSQL 데이터베이스 옵션을 제공합니다.
- Amazon Aurora PostgreSQL‑Compatible Edition
- Amazon Relational Database Service (Amazon RDS) for PostgreSQL
이 글에서는 Aurora PostgreSQL과 RDS PostgreSQL의 아키텍처와 기능을 자세히 살펴보고, 성능, 확장성, 장애 복구, 스토리지 옵션, 고가용성 및 재해 복구 메커니즘을 분석합니다.
Overview
Aurora PostgreSQL과 RDS for PostgreSQL 모두 완전 관리형 PostgreSQL 데이터베이스 서비스이며 다음을 제공합니다.
- 다양한 클래스의 DB 인스턴스 프로비저닝
- 여러 PostgreSQL 호환 버전 지원
- 백업 및 시점 복구(PITR) 관리
- 복제 및 모니터링
- Multi‑AZ 지원
- 스토리지 자동 확장
Key Differences
Aurora PostgreSQL은 빠른 분산 스토리지를 위해 맞춤화된 고성능 스토리지 서브시스템을 사용합니다. 기본 스토리지는 10 GiB 단위로 자동 확장되며 최대 128 TiB까지 지원합니다. Aurora는 대규모 처리량과 높은 동시성을 요구하는 워크로드에 최적화된 PostgreSQL을 제공합니다.
RDS for PostgreSQL은 최대 64 TiB의 스토리지를 지원하며, 데이터베이스와 로그 스토리지에 Amazon Elastic Block Store(EBS) 볼륨을 사용합니다. RDS는 PostgreSQL 설치, 업그레이드, 스토리지 관리, 복제 및 백업을 관리합니다.
Architecture Comparison
Aurora PostgreSQL Architecture
- 로컬에 부착된 SSD를 사용하는 스토리지 노드가 지원하는 단일 가상 클러스터 볼륨
- 데이터가 자동으로 세 개의 가용 영역에 복제됨
- 라이터와 리더가 공유하는 스토리지 모델
RDS PostgreSQL Architecture
- 단일 스탠바이 인스턴스를 갖는 클래식 Multi‑AZ
- 두 개의 읽기 가능한 스탠바이 DB 인스턴스를 갖는 Multi‑AZ DB 클러스터(반동기)
- 읽기 용량을 늘리기 위한 세 개의 별도 가용 영역
Feature Comparison Table
| Feature | Aurora PostgreSQL | RDS for PostgreSQL |
|---|---|---|
| Maximum Storage | 128 TiB | 64 TiB |
| Storage Type | Custom distributed storage (locally attached SSDs) | Amazon EBS (gp2/gp3, io1/io2) |
| Storage Growth | Automatic in 10 GiB increments | Auto‑scaling in 10 GiB or 10 % chunks |
| Storage Reduction | Automatic when data deleted | Manual |
| IOPS Limitation | No limitation based on storage size | Depends on storage type and size |
| I/O Charges | Separate (I/O‑Optimized available) | Included with storage type |
| Read Replicas | Up to 15 Aurora readers | Up to 155 read replicas (5 per instance, 3 levels of cascading) |
| Cross‑Region Replicas | Aurora Global Database | 5 cross‑Region read replicas |
| Typical Replica Lag | Few hundred milliseconds | Few seconds (optimal) to minutes (high load) |
| Backup Type | Continuous and incremental | Daily full + continuous WAL archiving |
| Backup Performance Impact | None | Slight impact on single‑AZ deployments |
| PITR Restore Time | Fast (incremental nature) | Slower (restore full + replay WALs) |
| Failover Time (Multi‑AZ) | 30 seconds (DNS: 10‑15 s, Recovery: 3‑10 s) | 1‑2 minutes (includes crash recovery) |
| Crash Recovery | Immediate (on‑demand parallel replay) | Depends on checkpoint interval (default 5 min) |
| Multi‑AZ Options | Single configuration | One standby or two readable standbys |
| Write Latency (Multi‑AZ) | Standard | Up to 2× faster with two standbys |
| Replication Method | Shared storage | PostgreSQL streaming replication |
| Write Impact on Replicas | Negligible | Significant (processes transaction logs) |
| Data Replication | 6 copies across 3 AZs | Synchronous to standby, async to replicas |
| Serverless Option | Aurora Serverless v2 | Not available |
| Fast Database Cloning | Yes | No (snapshot restore only) |
| Query Plan Management | Yes (QPM) | Not available |
| Cluster Cache Management | Yes (warm cache failover) | Not available |
| Machine Learning Integration | Yes (native SQL) | Not available |
Detailed Feature Analysis
Storage
Aurora PostgreSQL Storage
- 로컬에 부착된 SSD를 사용하는 스토리지 노드가 지원하는 단일 가상 클러스터 볼륨
- 10 GiB 단위로 자동 성장, 최대 128 TiB까지 지원
- 데이터 삭제 시 동적 축소
- 세 개의 가용 영역에 걸쳐 3배 복제 자동 수행
- 스토리지 크기에 따른 IOPS 제한 없음(인스턴스 규모에 따라 조정 필요)
- 사용량에 따라 별도 I/O 요금 부과
- I/O‑Optimized 구성은 I/O 비용이 전체 Aurora 비용의 25 %를 초과할 경우 최대 40 % 비용 절감 가능
RDS for PostgreSQL Storage
- Amazon EBS SSD 기반 스토리지 유형:
- General Purpose SSD (gp2): 프로비저닝된 GiB당 3 IOPS, 최대 3,000 IOPS까지 버스트
- General Purpose SSD (gp3): 용량과 무관하게 성능 커스터마이징 – 400 GiB 이하 스토리지에 대해 기본 3,000 IOPS 및 125 MiB/s 제공
- Provisioned IOPS (io1, io2): 1,000–256,000 IOPS 범위 지원
- 스토리지 자동 확장은 10 GiB 또는 현재 스토리지의 10 % 중 큰 단위로 진행
Backup
Aurora PostgreSQL Backup
- 지속적이며 증분된 자동 백업
- 백업 중 성능 영향이나 서비스 중단 없음
- 증분 방식 덕분에 빠른 PITR 가능
- 복구 시간은 볼륨 크기와 트랜잭션 로그 수에 따라 달라짐
RDS for PostgreSQL Backup
- 정의된 백업 창 동안 매일 자동 백업 수행
- 단일 AZ 배포 시 백업 시작 시 약간의 성능 저하 발생
- 지속적인 WAL 아카이빙 제공
- PITR 절차: 전체 백업 복원 후 원하는 시점까지 WAL 재생
- 쓰기 집약적인 워크로드에서는 WAL 재생 시간이 길어져 복구가 느려짐
- 팁: 빈번한 수동 스냅샷을 생성하면 PITR 소요 시간을 줄일 수 있음
Scalability
Aurora PostgreSQL Scalability
- 최대 15개의 리더를 통한 읽기 확장 및 고가용성 지원
- 공유 스토리지 모델 덕분에 높은 쓰기 워크로드가 복제에 미치는 영향 최소화
- 복제 지연은 보통 수백 밀리초(드물게 60 초까지) 수준
- 지연이 임계값을 초과하면 리더 자동 재시작
- 쓰기 용량은 단일 라이터 인스턴스에 의해 제한됨
RDS for PostgreSQL Scalability
- 최대 155개의 읽기 복제본(인스턴스당 5개, 3단계 캐스케이딩) 지원
- 캐스케이딩 아키텍처로 원본 인스턴스에 대한 부하 감소
- 캐스케이딩 단계가 늘어날수록 복제 지연이 점진적으로 증가
- 읽기 복제본을 독립적인 스탠드얼론 인스턴스로 승격 가능
- 5개의 크로스‑리전 읽기 복제본 제공
- PostgreSQL WAL 레코드를 이용한 스트리밍 복제
- 높은 쓰기 활동이나 스토리지/인스턴스 클래스 불일치 시 복제 지연 위험 증가
- Multi‑AZ 3‑AZ 배포에서는 두 개의 읽기 가능한 스탠바이가 HA와 확장성을 동시에 제공
Crash Recovery
Aurora PostgreSQL
- 전통적인 체크포인트가 없으며, 스토리지 시스템이 로그 레코드를 직접 적용
- 스토리지 세그먼트별 병렬 및 비동기 재실행 수행
- 장애 발생 시 즉시 가용
RDS for PostgreSQL
- 마지막 체크포인트 이후의 트랜잭션 로그를 재생(기본 체크포인트 간격 5 분)
- 체크포인트 과정에서 메모리의 더러운 페이지를 스토리지에 기록
- 트레이드오프: 체크포인트를 자주 수행하면 복구 시간은 짧아지지만 I/O 부하가 증가함
Failover
Aurora PostgreSQL Failover
- 평균 장애 복구 시간: 약 30 초
- DNS 전파: 10‑15 초
- 복구: 3‑10 초(동시 진행)
- 리더 중 하나가 자동으로 프라이머리로 승격
RDS for PostgreSQL Failover
- 평균 장애 복구 시간: 1‑2 분( DNS 전파와 크래시 복구 포함)
- 복구 시간은 크래시 복구 소요, DNS 전파, TTL 설정에 따라 달라짐
- 두 개의 스탠바이를 갖는 Multi‑AZ 구성에서는 35 초 이하로 장애 복구 가능하며, 트랜잭션 커밋 지연이 최대 2배까지 빨라짐
RDS Proxy Benefits
두 서비스 모두 Amazon RDS Proxy를 지원합니다.
- 연결 풀링 및 공유
- 빠른 장애 복구
- 새로운 프라이머리 인스턴스로 자동 연결 전환
- 장애 복구 중에도 유휴 연결 유지
High Availability and Disaster Recovery
(원본 기사에서 이 이후 내용이 계속됩니다. 필요에 따라 추가 섹션을 포함하세요.)