300GB PostgreSQL, Heroku 탈출기: AWS로의 마이그레이션 성공!
Heroku Postgres의 제한된 유연성(Limited Flexibility), 성능 및 비용 문제로 인해 AWS로의 마이그레이션 결정
EC2를 중간 서버로 활용하여 Heroku에서 EC2로, EC2에서 RDS로의 2단계 마이그레이션(Two-Step Migration) 수행
논리적 복제(Logical Replication)를 활용하여 RDS로의 데이터 동기화, 시퀀스 값 동기화(Sequence Synchronization) 문제 발생
철저한 테스트(Thorough Testing)와 롤백 옵션(Rollback Options) 준비를 통해 다운타임을 최소화하고 안정적인 마이그레이션 성공
Heroku 탈출의 기술적 배경
Heroku Postgres는 제한된 설정(Limited Configuration)과 업그레이드 제약(Upgrade Restrictions)으로 인해 대규모 데이터베이스 운영에 어려움이 있었다. 특히, 300GB에 달하는 데이터와 2억 5천만 행의 스크린샷 테이블은 Heroku의 번들형 스케일링 모델(Bundled Scaling Model)로 인해 불필요한 비용을 발생시켰다. 또한, Heroku Enterprise 판매 중단 발표는 AWS로의 이전을 가속화하는 결정적 요인이 되었다.
2단계 마이그레이션 전략: EC2 브리지 활용
마이그레이션은 EC2 인스턴스(EC2 Instance)를 중간 서버로 활용하는 2단계 방식으로 진행되었다. 1단계에서는 Heroku 백업을 EC2에 복원하고, EC2를 primary로 승격시켜 다운타임을 최소화했다. 2단계에서는 PostgreSQL 논리적 복제(Logical Replication)를 사용하여 EC2에서 RDS로 데이터를 동기화했다. 이 방식은 RDS가 WAL 스트리밍 복제를 지원하지 않기 때문에 선택되었다.
논리적 복제(Logical Replication)의 함정: 시퀀스 동기화
RDS로의 데이터 복제 과정에서 시퀀스 값(Sequence Values)의 불일치 문제가 발생했다. 논리적 복제는 시퀀스 값을 자동으로 복제하지 않기 때문에, 수동으로 시퀀스 값을 동기화하는 Node.js 스크립트를 실행해야 했다. 이는 논리적 복제에서 흔히 발생하는 주의해야 할 사항(Common Pitfall)이며, 데이터 무결성을 보장하기 위한 필수적인 단계였다.
마이그레이션 성공을 위한 핵심 요소
성공적인 마이그레이션을 위해 PostgreSQL의 WAL 아카이빙(WAL Archiving)과 복구 프로세스(Recovery Process)에 대한 깊이 있는 이해가 필수적이었다. Heroku의 sentinel 데이터를 활용하여 backup_label 및 tablespace_map 파일을 재구성하는 과정은 PostgreSQL 백업 및 복원(Backup and Restore)에 대한 전문 지식을 요구했다. 또한, 철저한 테스트와 롤백 옵션 준비는 다운타임을 최소화하는 데 기여했다.