[논의] Prod EC2 MySQL 데이터 백업 전략

[Hexeong]

논의 배경

Prod 환경의 데이터베이스를 RDS에서 EC2 기반 MySQL 8.4.8로 전환했습니다. 현재 MySQL은 단일 EC2에서 Docker 컨테이너로 실행되며, 데이터는 인스턴스의 루트 볼륨과 분리된 12GiB gp3 EBS에 저장하고 있습니다. EBS에는 Terraform의 prevent_destroy가 적용되어 있지만, 이는 Terraform을 통한 삭제만 방지할 뿐 데이터 손상이나 운영 실수에 대한 복구 수단은 아닙니다.

RDS를 사용할 때 제공되던 자동 백업과 특정 시점 복구 기능도 더 이상 사용할 수 없으므로, EC2 환경에 맞는 백업 정책을 별도로 마련해야 합니다. 다만 백업을 위해 별도 서버를 상시 운영하기보다는 S3 및 EBS 스냅샷 저장 비용 정도로 관리할 수 있는 방안을 우선 검토하고자 합니다.

문제

현재 Prod DB에는 정기적으로 생성되는 백업이 없습니다. 이 상태에서는 EBS 장애나 파일 시스템 손상뿐 아니라 잘못된 배포, 스키마 변경, 실수로 실행한 DELETE 또는 UPDATE 쿼리로 데이터가 변경되었을 때 정상 상태로 되돌리기 어렵습니다. 별도 EBS를 사용하고 있어 EC2 인스턴스 장애에는 어느 정도 대응할 수 있지만, EBS 내부 데이터 자체가 손상되거나 삭제되면 복구할 수 없습니다.

따라서 비용을 낮게 유지하면서도 허용 가능한 데이터 유실 범위, 복구에 걸리는 시간, 운영 및 복구 절차의 복잡도를 함께 고려해 백업 방식을 선택해야 합니다.

해결 방안 후보 세 가지

1. 일간 mysqldump → S3

• 예상 비용: 압축 dump가 10MB에서 100MB이고 30개를 보관할 경우 월 약 10원에서 105원입니다.
• 장점: 비용이 가장 낮고 구현이 단순하며, DB 또는 테이블 단위로 복구할 수 있습니다.
• 단점: 하루 한 번 백업하면 최대 24시간의 데이터가 유실될 수 있으며, DB가 커질수록 백업과 복원 시간이 늘어납니다.

2. 일간 mysqldump → S3 + EBS 스냅샷

• 예상 비용: S3는 월 약 10원에서 105원, EBS 스냅샷은 월 약 300원에서 1,000원으로 예상됩니다.
• 장점: 논리적인 데이터 오류는 dump로 복구하고, EC2 또는 EBS 전체 장애는 스냅샷으로 대응할 수 있어 복구 범위가 가장 균형적입니다.
• 단점: 스냅샷 비용과 관리 항목이 추가됩니다. 실행 중 생성한 스냅샷은 crash-consistent 방식이므로 DB 정합성을 완전히 보장하지는 않습니다.

3. 일간 mysqldump + binlog → S3

• 예상 비용: 현재 규모에서는 월 수백 원 이내로 예상되며, 실제 쓰기량에 따라 증가합니다.
• 장점: 별도 DB 서버 없이도 장애나 운영 실수 직전의 수분 단위 시점까지 복구할 수 있습니다.
• 단점: dump와 binlog의 기준점을 함께 관리해야 합니다. binlog 누락 여부를 감시하고 복구 절차를 정기적으로 검증해야 하므로 구현과 운영 난도가 가장 높습니다.

[sukangpunch]

저는 2번째 방식이 좋은 것 같습니다!
현시점에서 db의 변경 자체가 잦지는 않아서 유실량이 작을 것 같다는 생각이 듭니다.
만약 binlog 를 추가 할 시, 동기화 관리 부담은 변경량이 적어도 존재할 것이라 판단이 됩니다.
만에라도 소량 유실에도 치명적인 데이터가 있으면 binlog 를 고려하는것도 좋을 것 같습니다!

EBS 스냅샷에서 발생하는 crash-consistent 는 스냅샷 직전에 디스크 상태를 flush 하고 lock 걸어서 스냅샷을 때리는 방법으로 정합성 챙기는 것도 괜찮아 보입니다!