feat: prod환경의 DB EC2의 데이터 백업 전략 #64

어떤 기능인가요?

Prod EC2 MySQL에 RDS 수준의 기본 데이터 보호 체계를 마련합니다. 일간 전체 mysqldump와 binlog를 S3에 보관하고, 장애 유형별 복구 절차를 문서화한 뒤 검증된 절차를 수동 복구 워크플로우로 구성합니다.

배경

Prod DB는 RDS에서 단일 EC2의 MySQL 8.4.8 Docker 컨테이너로 전환되었으며, 데이터는 별도 12GiB gp3 EBS에 저장됩니다. 데이터 EBS를 분리했기 때문에 EC2 장애는 기존 EBS를 새 EC2에 연결해 복구할 수 있지만, EBS 손상·삭제, 잘못된 DELETE/UPDATE, 스키마 변경과 같은 데이터 장애는 별도 백업 없이는 복구할 수 없습니다.

현재 DB 규모와 비용을 고려하여 EBS 스냅샷 대신 S3 기반 논리 백업으로 통일합니다. 일 1회 전체 dump를 기준점으로 사용하고 binlog를 지속적으로 아카이빙하여 장애 또는 운영 실수 직전 시점까지 복구할 수 있도록 합니다.

운영 목표

• 목표 RPO: 5분
• 초기 목표 RTO: 1시간에서 2시간
• 전체 mysqldump: 일 1회
• binlog: 생성부터 S3 업로드 완료까지 5분 이내
• 보관 기간: 2주
• 백업 실패·누락·업로드 지연 시 Discord 알림
• 실제 복구 테스트 후 RTO와 세부 보관정책 확정

IAM 및 권한 관리 원칙

• IAM Role, IAM Policy, IAM User와 권한 연결 작업은 AWS에서 수동으로 관리합니다.
• Terraform 코드에는 IAM 권한 정의와 권한 연결 정보를 선언하지 않습니다.
• Terraform에서 권한이 필요한 경우 수동으로 생성된 리소스의 이름이나 식별자만 변수로 전달해 참조합니다.
• 구체적인 권한 내용은 저장소 이슈와 코드에 노출하지 않고 별도 운영 문서에서 관리합니다.

작업 상세 내용

• feat: S3 기반 MySQL 백업 및 모니터링 파이프라인 구성 #66 S3 기반 MySQL 백업 및 모니터링 파이프라인 구성
• docs: DB 장애 상황별 복구 매뉴얼 수립 #67 DB 장애 상황별 복구 매뉴얼 수립
• feat: Prod DB 인스턴스·볼륨 장애 복구 GitHub Actions 워크플로우 구성 #68 Prod DB 수동 복구 GitHub Actions 워크플로우 구성

완료 조건

• 전체 dump와 binlog가 복구 가능한 기준점으로 연결되어 S3에 저장됩니다.
• 최근 binlog 업로드가 5분을 넘기거나 백업이 누락되면 알림이 발생합니다.
• 논리적 데이터 장애, EBS 장애, EC2 장애별 복구 절차가 팀 합의를 거쳐 문서화됩니다.
• 복구 테스트를 통해 데이터 검증 기준과 RTO를 확인합니다.
• 검증된 절차를 승인 기반 수동 워크플로우로 실행할 수 있습니다.

참고 자료

• Discussion: [논의] Prod EC2 MySQL 데이터 백업 전략 #65
• 운영 기준 제안 댓글: [논의] Prod EC2 MySQL 데이터 백업 전략 #65 (comment)