1. 쓰기 노드(Primary)의 부담 해소
가장 즉각적인 변화는 쓰기 노드의 CPU와 메모리 여유가 생긴다는 점입니다.
부하 분산: 복잡한
SELECT쿼리, 통계 작업, 대량의 데이터 조회를 복제본으로 돌리면 쓰기 노드는 본연의 업무인INSERT,UPDATE,DELETE에만 전념할 수 있습니다.성능 체감: 쓰기 트랜잭션의 처리 속도(Throughput)가 향상되고 지연 시간(Latency)이 안정화됩니다.
2. 복제 오버헤드 최소화 (Shared Storage의 승리)
일반 RDS는 복제본을 만들면 쓰기 노드가 로그를 보내고 복제본이 이를 다시 실행(Replay)하는 과정에서 성능 저하가 발생합니다. 하지만 Aurora는 다릅니다.
로그 기반 복제: Aurora는 모든 복제본이 동일한 하위 스토리지 레이어를 바라봅니다.
낮은 지연 시간(Lag): 데이터 자체를 복사할 필요 없이 스토리지 업데이트 알림만 보내기 때문에, 복제 지연 시간(Replica Lag)이 보통 10~20ms 미만으로 유지됩니다. 이는 일반 RDS보다 압도적으로 빠른 수치입니다.
3. 고가용성(High Availability)과 페일오버
성능뿐만 아니라 '안정성' 면에서도 성능 향상이 있습니다.
즉시 승격: 쓰기 노드에 장애가 발생하면, 읽기 복제본 중 하나가 즉시 새로운 쓰기 노드로 승격됩니다.
복구 시간(RTO) 단축: 이미 스토리지를 공유하고 있기 때문에 데이터를 복구할 필요가 없어 페일오버 시간이 수십 초 내외로 매우 짧습니다.
4. 읽기 전용 엔드포인트(Reader Endpoint) 활용
Aurora는 최대 15개의 읽기 복제본을 지원하며, 이를 하나의 주소로 묶어주는 '읽기 전용 엔드포인트'를 제공합니다.
자동 로드밸런싱: 애플리케이션에서 읽기 전용 주소 하나만 연결하면, AWS가 알아서 여러 대의 복제본으로 트래픽을 골고루 뿌려줍니다. 개발자가 개별 서버 IP를 관리할 필요가 없습니다.
일반 RDS 복제 vs Aurora 복제 비교
항목 | 일반 RDS (MySQL/PostgreSQL) | Amazon Aurora |
복제 방식 | Binlog/WAL 스트리밍 (데이터 복사) | 공유 스토리지 (로그 업데이트) |
복제 지연(Lag) | 수 초 이상 발생 가능 | 보통 20ms 미만 |
최대 복제본 수 | 5개 (기본) | 15개 |
쓰기 노드 영향 | 복제본이 늘어날수록 부하 증가 | 복제본 수와 관계없이 부하 거의 없음 |
운영 고려 사항
인스턴스 사양 일치: 페일오버 시 읽기 복제본이 쓰기 노드로 승격되어야 하므로, 가급적 쓰기 노드와 동일한 사양(Tier)으로 구성하는 것이 좋습니다. 사양이 낮은 복제본이 승격되면 갑작스러운 운영 트래픽을 견디지 못할 수 있습니다.
비용: 읽기 복제본 역시 인스턴스 비용이 발생합니다. 트래픽이 적은 시간에는 Auto Scaling을 통해 복제본 개수를 자동으로 조절하도록 설정하세요.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.