안녕하세요, 하루들 팀입니다. 이번 글에서는 인프라 개선 과정을 공유하고자 합니다.
하루들의 실제 인프라 청구서를 분석했을 때, 10월 1일부터 22일까지 발생한 팀 전체 AWS 비용(44.30달러) 중 약 47%(20.80달러)를 관리형 데이터베이스 서비스인 RDS가 차지하고 있었습니다.
트래픽 대비 데이터베이스 고정 지출이 지나치게 높았고, 개발 환경과 운영 환경의 인스턴스 사양이 달라 부하 테스트 결과를 신뢰하기 어려운 문제도 있었습니다.
한정된 예산 안에서 인프라를 효율적으로 운영하기 위해, RDS를 걷어내고 EC2 환경에 PostgreSQL을 직접 구축하기로 결정했습니다. 이번 글에서는 데이터베이스를 옮기는 과정에서 고민한 아키텍처 설계와 백업 메커니즘을 정리하겠습니다.
다룰 내용: 1개월(30일) 동일 기준 RDS와 EC2 비용 비교, t4g.small 4대로의 물리적 격리 설계, pg_dump와 pgBackRest의 사용 목적 차이, WAL의 기록 원리, S3 백업 압축 방식으로 Zstandard 수준 1을 선택한 이유
대상 독자: 관리형 데이터베이스 비용을 줄이고 싶거나, EC2 환경에서 PostgreSQL과 자체 백업 체계를 처음 구축하려는 백엔드 및 인프라 개발자
하루들 팀 인프라 비용은 월 중간에 새로운 리소스가 추가되거나 개발과 운영 환경의 인스턴스 사양이 달라 단순 비교하기 어려웠습니다. 특히 기존에는 비용 부담으로 개발 앱 서버는 t4g.micro, 운영 앱 서버는 t4g.small을 사용하여, 개발 서버에서 수행한 쿼리 튜닝과 부하 테스트 결과를 운영 환경에 그대로 대입하기 어려웠습니다.
따라서 부하 테스트의 신뢰도를 확보하려면 데이터베이스를 바꾸지 않더라도 개발 앱 서버를 t4g.small로 올려 환경을 일치시켜야만 했습니다. 이에 "RDS를 유지한 채 개발 서버 사양만 운영과 동일하게 올린 체제(RDS 유지안)"와 "RDS를 걷어내고 4대 모두 t4g.small로 직접 구축한 체제(EC2 직접 구축안)"를 한 달(30일, 720시간 상시 가동) 동일 기준으로 정밀하게 예측하고 비교해 보았습니다.
구분 | 전환 전 기준 (RDS 유지안) | 전환 후 (EC2 4대 직접 구축안) | 차이 및 비고 |
|---|---|---|---|
개발 환경 구성 | 앱 EC2 1대 ( | 앱 EC2 1대 + DB EC2 1대 (모두 | DB 사양 1GB에서 2GB RAM으로 2배 확장 |
운영 환경 구성 | 앱 EC2 1대 ( | 앱 EC2 1대 + DB EC2 1대 (모두 | DB 사양 1GB에서 2GB RAM으로 2배 확장 |
환경 간 사양 일치 | 개발과 운영 앱 사양 일치 (총 메모리 6GB) | 4대 모두 | 전체 메모리 33% 증설 (DB는 2배 확장) |
컴퓨팅 인스턴스 비용 | 약 $54.15 (앱 2대 $24.19 + RDS 2대 $29.96) | 약 $48.38 ( | 관리형 마진 제거로 월 $5.77 절감 |
스토리지 (EBS / gp3) | 약 $8.89 (앱 OS 2개 + RDS 디스크 2개) | 약 $10.94 (OS 디스크 4개 + DB 데이터 디스크 2개) | 서울 리전 단가 적용 시 스토리지 약 $2.05 증가 |
백업 스토리지 (S3) | 기본 포함 (자동 백업 7일) | 약 $0.10 미만 (압축 물리 백업과 WAL 보관) | Zstandard 압축 적용으로 비용 영향 미미 |
월 총합 예상 비용 | 약 $63.04 | 약 $59.42 | DB 스펙 2배 올리고도 월 약 $3.62 순절감 |
※ 참고: 위 수치는 AWS 서울 리전 온디맨드 단가와 30일(720시간) 상시 가동을 기준으로 산출한 기본 인프라 예측치입니다. 실제 청구 금액은 사용자 접속에 따른 네트워크 데이터 전송량(트래픽)이나 S3 API 요청 횟수 등에 따라 소폭 차이가 발생할 수 있습니다.
부하 테스트 환경을 맞추기 위해 RDS 체제를 유지하면서 개발 앱 서버를 t4g.small로 올리면, 컴퓨팅 비용만 매달 약 $54.15(앱 2대 $24.19 + RDS 2대 $29.96)가 발생합니다. 특히 1GB 메모리에 불과한 db.t4g.micro 2대에 관리형 서비스 요금 때문에 매달 약 $29.96이 고정 지출되는 구조였습니다.
반면 RDS를 걷어내고 4대 인스턴스를 모두 t4g.small로 통일하면 순수 컴퓨팅 비용은 약 $48.38로 줄어듭니다. 관리형 서비스에 지불하던 비용을 덜어낸 덕분에, DB 인스턴스의 메모리를 1GB에서 2GB로 2배 올리고도 순수 컴퓨팅 비용은 매달 약 $5.77를 절감할 수 있다는 계산이 나왔습니다.
단순히 "RDS를 끄면 DB 비용이 전액 사라진다"고 가정하면 오차가 생깁니다. 앱 서버 2대와 DB 서버 2대에는 각각 운영체제를 구동하기 위한 루트 볼륨이 있고, DB 서버 2대에는 데이터와 로그를 별도로 관리하기 위한 데이터 볼륨을 붙였기 때문입니다.
DB 데이터 볼륨은 dev와 prod 모두 gp3 20 GiB입니다. 루트 볼륨 4개도 모두 20 GiB라고 가정하면 전환 후 총 EBS 사용량은 120 GiB이며, AWS 서울 리전 gp3 공식 단가(GB당 월 $0.0912)로 계산한 월 비용은 약 $10.94입니다.
기존 RDS 저장 공간을 각각 20 GiB Single-AZ gp3(약 $5.24)로 가정하면, 앱 서버 루트 볼륨 2개(약 $3.65)를 합친 전환 전 저장 비용은 약 $8.89입니다. 이 가정에 따르면 전환 후 스토리지 비용은 약 $2.05 늘어납니다. DB 전용 볼륨 분리는 EC2에서 PostgreSQL을 운영할 때 필수 사항은 아니지만, 데이터베이스 안정성과 I/O 관리를 위해 이번 구성에서 선택해 추가한 것입니다.
서버가 늘어나며 스토리지 비용이 약 $2.05 증가했지만, 컴퓨팅 비용에서 약 $5.77를 절감한 덕분에 전체 인프라 예상 지출은 기존 약 $63.04에서 약 $59.42로 오히려 매달 약 $3.62(약 5.7%) 순절감된다는 결론을 얻었습니다.
단순한 금액 절감보다 더 값진 성과는 "비용을 줄이면서도 데이터베이스의 가용 메모리를 1GB에서 2GB로 2배 확장하고, 개발과 운영의 환경을 완벽하게 일치시켰다"는 점입니다. DB 메모리가 2배로 늘어나면서 버퍼 풀을 훨씬 여유롭게 확보할 수 있게 되었고, 개발 환경에서 측정한 쿼리 튜닝과 부하 테스트 결과를 운영 환경의 실제 성능 지표로 신뢰할 수 있는 개발 환경을 구축했습니다.
초기에는 개발과 운영에 각각 t4g.medium(4GB RAM) 1대씩 총 2대만 두고, 컨테이너로 앱과 DB를 함께 띄우려 했습니다. 하지만 이 구조는 세 가지 치명적인 결함이 있었습니다.
공동 장애 전파: 웹 애플리케이션에 장애가 나거나 배포를 진행할 때 데이터베이스까지 함께 멈추는 단일 장애점이 생깁니다.
메모리 경합: 애플리케이션의 JVM 힙 메모리, 프론트엔드 Nginx, PostgreSQL 공유 버퍼, 호스트 OS 프로세스가 한 인스턴스 안에서 메모리를 동시에 점유하면 가용 자원이 쉽게 고갈됩니다. 부족한 메모리를 디스크 스왑 영역으로 메우려 하면 극심한 디스크 입출력 병목이 발생하고 CPU 사용량이 치솟아 시스템 전체가 멈출 위험이 있습니다.
독립 스케일업 불가: 웹 트래픽만 늘어나도 무거운 DB가 묶여 있는 큰 서버 전체의 사양을 올려야 합니다.
따라서 총 메모리 용량은 8GB로 유지하면서 역할을 물리적으로 분리하는 t4g.small 4대 구성을 최종 채택했습니다. 앱 서버와 DB 서버를 물리적으로 격리함으로써 웹 애플리케이션 재시작이나 배포 작업이 데이터베이스 가용성에 일체 영향을 주지 않도록 만들었습니다.
데이터베이스를 다룰 때 백업 도구의 특성을 이해하는 것은 매우 중요합니다. 하루들은 초기 데이터 이관에는 pg_dump를 사용했고, 상시 정기 백업에는 pgBackRest를 도입했습니다.
두 도구의 핵심 차이를 백업 방식, 장단점, 하루들의 활용 사례로 나누어 정리했습니다.
방식: 데이터베이스 내부의 테이블 구조, 인덱스 생성문, 실제 행 데이터를 SQL 쿼리 형태나 압축 바이너리로 추출합니다.
장점: 텍스트나 표준 포맷으로 출력되므로 버전이 다른 데이터베이스 간 이동이 쉽고, 특정 테이블만 골라 복원하기 편리합니다.
단점: 데이터 양이 많아지면 덤프 추출과 적재 속도가 느려지며, 백업이 완료된 시점 이후의 변경 내역을 반영하는 특정 시점 복구가 불가능합니다.
하루들의 활용: RDS에서 EC2로 데이터를 처음 넘길 때 1회성 데이터 이관 도구로 활용했습니다.
방식: PostgreSQL의 데이터 디렉터리에 있는 실제 파일을 직접 복사하고, 트랜잭션 로그(WAL)를 실시간으로 저장소에 수집합니다.
장점: 대용량 데이터도 빠른 속도로 백업과 복원이 가능하며, 이전 백업 이후 바뀐 파일만 저장하는 증분 백업을 지원합니다. 또한 베이스 백업본에 WAL 로그를 이어 붙여 원하는 특정 시점으로 되돌릴 수 있는 시점 복구(PITR, Point-In-Time Recovery) 기반을 마련할 수 있습니다.
단점: 파일 시스템 단위로 복사하므로 동일한 운영체제 아키텍처와 동일한 PostgreSQL 주 버전에서만 동작합니다.
하루들의 활용: 운영 데이터베이스(prod)의 상시 백업 엔진으로 채택했습니다. 매일 백업을 수행하되 일요일에는 전체 백업을, 나머지 요일에는 바뀐 파일만 저장하는 증분 백업을 실행하며 WAL 파일을 S3에 지속 보관합니다. (개발 데이터베이스는 정기 백업 대상에서 제외했습니다.)
PostgreSQL의 신뢰성을 지탱하는 가장 핵심적인 메커니즘이 바로 WAL(Write-Ahead Logging, 로그 선행 기입)입니다.
데이터베이스 시스템은 성능을 위해 클라이언트가 보낸 데이터를 디스크에 즉시 쓰지 않고, 먼저 메모리의 공유 버퍼에 적재합니다. 만약 이 상태에서 갑자기 정전이 발생하거나 서버가 재부팅되면 메모리에 있던 최신 데이터가 영구 유실됩니다.
그렇다고 매 트랜잭션마다 무거운 데이터 파일 디스크 전체를 무작위로 갱신하면 성능이 크게 저하됩니다. 이 문제를 해결하기 위해 등장한 규칙이 "실제 데이터 파일을 디스크에 수정하기 전에, 변경 내역을 순차적인 로그 파일(WAL)에 먼저 단단히 기록한다"는 원칙입니다.
WAL 버퍼와 세그먼트: 변경 내역은 메모리의 WAL 버퍼를 거쳐 디스크의 pg_wal 디렉터리에 16MB 크기의 세그먼트 파일 단위로 순차 기록됩니다.
체크포인트: 주기적으로 체크포인트가 발생하면 메모리에 머물던 변경 데이터가 실제 디스크 테이블 파일에 일괄 반영되며, 완료된 옛 WAL 파일은 덮어쓰기 위해 재사용됩니다.
하루들의 아카이빙 전략: 세그먼트 파일이 재사용되어 사라지기 전에 외부 S3로 빼돌려 안전하게 보관해야 합니다. 이를 WAL 아카이빙이라고 부릅니다.
기본 설정에서 WAL 파일은 16MB 용량이 가득 차야만 다음 파일로 전환되며 아카이빙 명령이 실행됩니다. 하지만 새벽 시간대처럼 트래픽이 적은 시간대에는 16MB를 채우는 데 몇 시간 이상 걸릴 수 있습니다. 그 사이에 서버가 고장 나면 아직 채워지지 않은 WAL 내역이 유실될 위험이 있습니다.
하루들 팀은 PostgreSQL 설정에 archive_timeout = 60s를 적용했습니다. 데이터 변경이 발생하면 16MB가 다 차지 않더라도 60초가 지나면 현재 작성 중인 WAL 파일을 강제로 닫고 새 파일로 전환(switch)하여 pgBackRest의 S3 아카이브 명령을 실행하도록 유도합니다.
다만 이 설정이 곧바로 "데이터 유실 최대 1분 보장"을 뜻하지는 않습니다. PostgreSQL의 아카이브 명령은 파일이 완전히 닫힌 뒤에 순차적으로 실행되며, 네트워크 전송 지연이나 일시적 오류에 따른 재시도 시간까지 60초 안에 끝난다고 확정할 수 없기 때문입니다.
하루들 팀이 설정한 실제 운영 복구 목표는 데이터 유실 최대 5분 이내입니다. 60초 단위의 WAL 전환 설정은 이 목표를 달성하기 위한 최소한의 출발점일 뿐이며, 진정한 복구 신뢰성은 WAL의 실제 S3 전송 지연 감시와 정기적인 시점 복구(PITR) 모의훈련을 통해 계속해서 검증해 나가야 합니다.
하루들은 pgBackRest를 통해 운영 데이터베이스의 물리 백업본과 전환된 WAL 파일을 S3로 지속 업로드합니다. 이때 압축 방식을 무엇으로 지정하느냐에 따라 CPU 자원 소모량과 네트워크 전송 비용이 크게 달라집니다.
알고리즘 | 특징 | 장점 | 단점 |
|---|---|---|---|
gzip (수준 6) | 전통적인 업계 표준, pgBackRest 기본값 | 높은 호환성과 안정적인 압축률 | CPU 사용량이 매우 높아 DB 연산에 간섭 발생 |
LZ4 (수준 1) | 초고속 압축 해제 특화 | CPU 부하가 극도로 낮고 처리 속도가 빠름 | 압축률이 낮아 S3 저장 공간 및 전송 비용 증가 |
Zstandard (수준 1) | Meta가 개발한 최신 압축 알고리즘 | 낮은 압축 레벨에서도 압축 속도와 용량 압축률의 균형 우수 | 환경에 따라 별도 패키지 설치 필요 |
글로벌 오픈소스 데이터베이스 전문 기업 Percona의 벤치마크 실험 자료(Percona pgBackRest Compression Report)를 분석하여 정량적 근거를 도출했습니다.
gzip 수준 6: 데이터 원본 1GB당 54.5 CPU초를 소모하며 61.6% 용량을 줄였습니다.
Zstandard 수준 1: 데이터 원본 1GB당 단 9.1 CPU초만 소모하면서도 59.9% 용량을 줄였습니다.
gzip 수준 6은 Zstandard 수준 1에 비해 저장 공간을 1.7%포인트 더 줄이는 데 그쳤지만, CPU 연산 시간은 약 6배나 더 소모했습니다.
하루들이 사용하는 t4g.small 인스턴스는 2개의 가상 코어(vCPU)를 제공하는 버스터블(T 시리즈) 인스턴스입니다. T 시리즈는 평소 CPU 사용량이 낮을 때 일종의 사용 포인트인 'CPU 크레딧'을 적립해 두었다가 순간적인 부하를 처리하는 방식입니다.
특히 T4g 인스턴스는 기본적으로 무제한(Unlimited) 모드로 동작합니다. 크레딧이 모두 소진되어도 기준 성능을 넘어 계속 연산할 수 있지만, 초과 사용한 만큼 추가 요금이 과금됩니다. 만약 스탠다드(Standard) 모드로 설정되어 있다면 크레딧 고갈 시 CPU 성능이 기준선 수준으로 강제 제한됩니다.
어느 쪽이든 백업을 할 때마다 무거운 압축 작업으로 CPU를 낭비하면, 데이터베이스 쿼리 처리가 지연되거나 예상치 못한 CPU 초과 과금이 발생하게 됩니다. 사용자 쿼리를 신속히 처리해야 할 데이터베이스에서 디스크 용량 1~2%포인트를 더 아끼겠다고 소중한 연산 자원을 무리하게 소모할 수는 없었습니다.
따라서 가장 적은 CPU 자원으로 빠르게 압축을 끝낼 수 있는 Zstandard 수준 1을 pgBackRest의 기본 압축 방식으로 결정하고 설정 파일(/etc/pgbackrest/pgbackrest.conf)에 반영했습니다.
# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-region=ap-northeast-2
compress-type=zst
compress-level=1
개발과 운영의 사양을 일치시킨 1개월 비용 예측 결과, RDS 유지 대비 EC2 t4g.small 4대 격리 구조로 전환하여 DB 메모리를 1GB에서 2GB로 2배 확장하면서도 월 인프라 비용을 약 $3.62 순절감했습니다.
1회성 데이터 이관에는 논리 덤프인 pg_dump를, 운영 데이터베이스(prod)의 상시 백업에는 물리 백업 엔진인 pgBackRest를 채택해 일요일 전체 백업과 주중 증분 백업 체계로 역할을 명확히 분리했습니다. (개발 데이터베이스는 정기 백업 제외)
60초 주기의 WAL 파일 강제 전환과 Zstandard 수준 1 압축을 조합하여 유실 위험을 크게 낮추었으며, 실제 복구 목표(데이터 유실 최대 5분)를 안정적으로 달성하기 위해 전송 감시와 복원 시험으로 지속 검증해 나가고 있습니다.
관리형 서비스가 대신 처리해주던 백업과 압축 과정을 직접 구성하며, 데이터베이스가 데이터를 안전하게 지키기 위해 내부에서 어떤 물리적 과정을 거치는지 명확히 이해할 수 있었습니다.
추후에는 동일 사양으로 일치시킨 환경에서 진행한 부하 테스트 결과와, 개발 서버에서 고의로 데이터를 손상시킨 뒤 시점 복구(PITR)로 되살려본 재해 복구 훈련 과정을 공유하겠습니다.
앞으로의 하루들도 기대해주세요! 읽어주셔서 감사합니다!