서비스를 출시하기 전, 안정적인 운영을 위해 데이터 백업은 필수적이었다.
운영 환경에서 데이터베이스 장애가 발생하면 어떻게 복구할 것인가?
데이터 손실은 사용자 신뢰와 비즈니스에 심각한 영향을 미칠 수 있다.
AWS RDS를 사용하는 상황에서, 데이터 크기가 2MB 미만으로 작아 안정적이라 느낄 수 있었지만, 복구 전략이 없으면 치명적인 상황을 초래할 가능성이 있었다.
네트워크 문제로 RDS 접근이 불가능해지거나, 서버 부하로 데이터 무결성이 깨질 가능성을 고려해 데이터 손실 방지를 위한 백업 체계 구축이 필요했다.
결국, 간단하면서도 효과적인 복구 방법을 고민한 끝에 스케줄링 기반 덤프 파일 생성 방식을 선택하게 되었다.
1. 백업 주기 선정 배경
서비스 특성을 고려했을 때, 1시간 주기로 백업을 설정한 이유는 다음과 같다:
- 트랜잭션 중요도
- 거래 금액이 10만원~100만원 사이로, 데이터 유실 시 피해가 클 수 있다.
- 최대 1시간치 거래 데이터 손실도 비즈니스에 심각한 영향을 미칠 가능성이 있었다.
- 트래픽 패턴
- 초기에 예상되는 사용자는 약 500명 정도 예상된다.
- 1시간 이상의 데이터 유실은 복구 작업 및 고객 대응에 리소스가 필요하다고 판단했다.
- 운영 리스크 관리
- 금전적 거래가 포함된 서비스로, 데이터 정합성과 안정성이 매우 중요한 상황이다.
- 장애 발생 시 최소한의 데이터 손실로 복구할 수 있는 백업 주기가 필요하다.
2. RDS 스냅샷과 DB 덤프: 차이와 원리
AWS RDS 스냅샷과 DB 덤프는 백업을 수행하는 두 가지 주요 방식이다. 각각의 원리와 구조를 이해하면 최적의 방법을 선택할 수 있다.
1. AWS RDS 스냅샷
RDS 스냅샷은 Amazon RDS에서 제공하는 관리형 백업 기능이다. 이는 데이터베이스의 상태를 특정 시점에 저장하는 방식으로, AWS의 내부 스토리지 시스템에 저장된다.
원리
- RDS 스냅샷은 데이터베이스 볼륨의 블록 단위로 데이터를 캡처한다.
- 증분 방식으로 저장되며, 최초 스냅샷 이후 변경된 블록만 저장해 저장 공간을 절약한다.
- 복구 시, 저장된 블록 데이터를 기반으로 전체 데이터베이스를 특정 시점으로 복원한다.
장점
- AWS Management Console에서 몇 번의 클릭만으로 손쉽게 백업 가능.
- 증분 백업으로 저장 비용 절감.
- 자동 백업 스케줄링 지원.
단점
- 복구 시 데이터베이스 인스턴스를 새로 생성해야 하므로, 복구 시간이 상대적으로 길다.
- 데이터베이스 외부에서 데이터를 활용하려면 별도의 내보내기 작업이 필요하다.
2. DB 덤프
DB 덤프는 데이터베이스의 데이터를 SQL 파일 형태로 내보내는 방식이다. 데이터베이스의 구조와 데이터를 SQL 명령문으로 변환해 저장하며, pg_dump와 같은 도구를 사용한다.
원리
pg_dump는 데이터베이스와 연결해 데이터를 읽어들인다.- 테이블 구조 및 데이터를 SQL 스크립트로 변환해 파일로 저장한다.
- 저장된 덤프 파일을 복구 시, SQL 명령어를 사용해 데이터베이스를 재구성한다.
장점
- 로컬 환경에서 데이터를 복구하거나 분석할 수 있다.
- 다른 환경으로 데이터를 쉽게 이동하거나 복제 가능.
- 작은 데이터 크기와 빠른 백업 속도를 제공.
단점
- 데이터 크기가 커질수록 덤프 파일 생성 및 복구 시간이 증가.
- 데이터베이스의 잠금 이슈(locking)를 유발할 수 있음.
3. 백업 방식 검토
1. AWS 자체 백업 서비스
- 장점:
- AWS Management Console에서 간편하게 설정 및 관리 가능.
- 데이터베이스 전체를 특정 시점으로 복구하는 기능 제공.
- 안정적인 AWS 인프라를 활용해 높은 가용성과 데이터 내구성을 보장.
- 단점:
- 복구 시 새로운 데이터베이스 인스턴스를 생성해야 하므로 복구 시간이 비교적 길다.
- 최대 35일로 복구 가능한 시점이 제한적이다.
- 스냅샷 데이터를 로컬 환경에서 직접 분석하거나 활용하려면 별도의 내보내기 작업이 필요하다.
- 상대적으로 높은 스토리지 비용이 발생할 수 있다.
2. Lambda와 EventBridge를 활용한 자동 스냅샷
- 장점:
- 서버리스 환경에서 백업 자동화를 구현해 관리 부담이 적다.
- AWS S3와 결합하면 다중 리전 저장 및 데이터 내구성을 높일 수 있다.
- CloudWatch와 연동해 백업 상태를 실시간으로 모니터링하고 알림 설정이 가능하다.
- 단점:
- 초기 설정이 번거롭고, IAM 권한 관리와 Lambda 함수 작성, EventBridge 트리거 설정이 필요하다.
- Lambda 실행 시간 제한(15분)이 있어 대규모 데이터에서 타임아웃 발생 위험이 있다.
- 스냅샷 데이터를 로컬로 가져오려면 추가 작업과 비용이 발생한다.
- 유지보수 시 Lambda 코드 수정 및 구성 변경에 리소스가 필요하다.
3. pg_dump를 활용한 스케줄링 기반 덤프 생성
- 장점:
pg_dump를 통해 데이터베이스 덤프 파일을 생성하고 로컬에 저장할 수 있어 구현이 간단하다.- 작은 데이터 크기에서는 백업 및 복구 속도가 빠르다.
- 덤프 파일을 즉시 로컬에서 분석하거나 복구 목적으로 사용할 수 있다.
- 특정 테이블만 선택적으로 백업할 수 있어 유연성이 높다.
- 단점:
- 로컬 환경 의존도가 높아, 시스템이 중단되면 백업이 실패할 수 있다.
- 대규모 데이터베이스 환경에서는 성능 저하 가능성이 있다.
- 백업 파일의 장기 보관을 위해 추가적으로 S3 업로드나 외부 저장소 관리가 필요하다.
- 네트워크 문제나 시스템 부하가 백업 실패로 이어질 수 있다.
4. Lambda + EventBridge + dump
- 장점:
pg_dump와 Lambda의 조합으로 서버리스 환경에서 덤프 생성과 S3 업로드를 자동화할 수 있다.- 컴퓨터 의존성을 제거하고, S3를 활용해 높은 가용성과 데이터 보존성을 확보할 수 있다.
- 비용 효율적인 클라우드 스토리지와 덤프 파일을 결합해 유연하게 활용 가능하다.
- 단점:
- 초기 설정이 복잡하며, Lambda 환경에서
pg_dump를 실행하기 위한 네트워크 구성과 IAM 설정이 필요하다. - Lambda 실행 시간 제한(15분)으로 인해 대규모 데이터에서는 적합하지 않을 수 있다.
- 외부 네트워크 의존성이 있으므로 연결 문제가 발생하면 백업 실패 가능성이 있다.
- 초기 설정이 복잡하며, Lambda 환경에서
선택 이유 및 향후 계획
현재 데이터 크기(2MB 미만)와 빠른 구현이 요구되는 상황에서는 로컬 스케줄링 기반
pg_dump방식이 단순하면서도 효과적이다.이 방식은 초기 설정이 간단하고, 데이터 크기가 작을 경우 복구 및 분석이 빠르게 가능하다는 점에서 적합하다.
장기적으로 데이터 크기 증가 및 안정적인 장기 보관 요구가 생긴다면 Lambda + EventBridge + dump 방식으로 전환해 S3에 데이터를 저장하고, 서버리스 환경을 활용한 백업 자동화를 도입할 계획이다
또한, 복구 속도가 덜 중요하고 AWS RDS 인프라를 활용한 안정성을 중시하는 경우, AWS RDS 스냅샷 또는 Lambda + EventBridge 스냅샷 방식도 검토할 것이다
4. 스케줄링 기반 덤프 구현: 상세 원리
pg_dump를 활용한 덤프 생성은 데이터 크기가 작고 빠른 복구가 필요한 상황에서 적합하다. 덤프 파일은 데이터베이스 테이블의 구조와 데이터를 SQL 명령문으로 변환해 저장하며, 주요 과정은 다음과 같다:
- 데이터베이스 접속
pg_dump는 PostgreSQL 클라이언트를 통해 데이터베이스와 연결한다.- 인증을 위해 사용자 이름, 비밀번호, 호스트 주소를 사용한다.
- 테이블 및 데이터 읽기
- 데이터베이스의 메타데이터를 기반으로 테이블 구조를 읽는다.
- 테이블 데이터를 순차적으로 읽어 SQL INSERT 문으로 변환한다.
- SQL 파일 생성
- 읽어들인 데이터를 SQL 스크립트로 변환하고 파일로 저장한다.
- 기본 형식은 plain SQL, custom 형식(
F c) 등으로 지정 가능하다.
- 복구
- 저장된 덤프 파일은
psql또는pg_restore명령어를 사용해 복구할 수 있다. - 복구 시, 테이블 구조를 재생성한 뒤 데이터를 다시 삽입한다.
- 저장된 덤프 파일은
5. Python을 활용한 백업 자동화
import subprocess
import datetime
import schedule
import time
# 덤프 파일 생성 함수
def create_dump():
timestamp = datetime.datetime.now().strftime("%Y-%m-%d_%H-%M-%S")
dump_file = f"demo_backup_{timestamp}.dump"
command = [
"pg_dump",
"-h", "demo-instance.abcdefg12345.ap-northeast-2.rds.amazonaws.com",
"-p", "5432",
"-U", "test_user",
"-d", "test_db",
"-F", "c",
"-f", dump_file
]
try:
subprocess.run(command, check=True)
print(f"[{datetime.datetime.now()}] Dump created: {dump_file}")
except subprocess.CalledProcessError as e:
print(f"[{datetime.datetime.now()}] Error creating dump: {e}")
# 1시간마다 백업 실행
schedule.every(1).hours.do(create_dump)
print("Starting scheduled dump task...")
while True:
schedule.run_pending()
time.sleep(1)
5-1. 백업 작업 최적화
-
Retention Policy
오래된 백업 파일을 주기적으로 삭제해 저장 공간을 관리한다.
import os import glob import time def cleanup_old_dumps(directory, retention_days=7): now = time.time() for file in glob.glob(f"{directory}/*.dump"): if os.stat(file).st_mtime < now - retention_days * 86400: os.remove(file) print(f"Deleted old dump file: {file}") -
복구 테스트
덤프 파일의 복원 가능성을 검증하기 위해 주기적으로 테스트를 수행한다.
pg_restore -h localhost -U test_user -d test_db demo_backup_2024-11-22_10-58-27.dump -
스케줄 최적화
서비스 부하를 최소화하기 위해 백업 작업을 비활성 시간대(예: 새벽)에 실행한다.
결론
백엔드 개발자로서 서비스 안정성과 데이터 보호는 필수적인 책임이다.
이번 스케줄링 기반 백업 자동화 작업을 통해 데이터베이스 백업 시스템을 간단하고 효과적으로 구축했다.
다음 단계로는 로깅 및 모니터링 알림 시스템을 추가하여 서비스 운영 시작 전 대비를 더욱 철저히 할 계획이다.
Ref
