[논의] 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 걸어서 스냅샷을 때리는 방법으로 정합성 챙기는 것도 괜찮아 보입니다!

[Hexeong]

형준님 의견 감사합니다! 말씀하신 부분도 맞는 말씀이신 것 같습니다. 특히 binlog 부분에 대해서도 저도 데이터 유실을 챙겨야 하는 부분에 대해서 크게 공감합니다 ㅎㅎ 근데 마침 RDS -> EC2 기반 MySQL 전환 작업을 마치고 나서 비용 절감을 해냈는데 EBS 스냅샷 유지에서 비용 측면이 아직 걸리긴 합니다.. 이 부분에 대해서 다른 분들 의견도 듣고 진행하겠습니다!

[Hexeong]

추가로 논의되면 좋을 부분이 mysqldump 작업을 cronJob을 어디서(api server? db ec2?) 진행할지도 고민입니다! 이 부분에 대해서도 의견 주시면 감사드리겠습니다!

[lsy1307]

Prod DB의 기본 백업 방식으로는 3번 일간 mysqldump + binlog → S3방식을 적용하는 것이 적절하다고 판단됩니당.

일간 dump만 사용하거나 EBS 스냅샷을 추가하는 방식은 구현이 단순하지만 잘못된 DELETE, UPDATE 또는 스키마 변경이 발생했을 때 최대 24시간의 데이터가 유실될 수 있습니다. EBS 스냅샷은 볼륨 전체 장애를 빠르게 복구하는 데는 도움이 되지만 장애 직전 시점으로 복구하는 기능은 제공하지 않습니다.

반면 dump와 binlog를 함께 보관하면 별도 백업 서버를 상시 운영하지 않고도 장애나 운영 실수 직전까지 복구할 수 있습니다. 현재 데이터 규모에서는 S3 저장 비용도 크지 않으므로 추가 운영 복잡도를 감수할 가치가 있다고 생각합니당.

제가 생각하는 권장 운영 기준은 다음과 같습니다.

• 일 1회 전체 mysqldump 생성 및 S3 보관
• binlog를 5~10분 이내 간격으로 S3에 아카이빙
• dump와 binlog를 30~35일간 보관
• 목표 RPO는 10분 이내로 설정
• 초기 목표 RTO는 1~2시간으로 설정하고 복구 테스트를 통해 확정
• 백업 실패, binlog 누락, 마지막 업로드 경과 시간에 대한 모니터링 및 알림 구성
• S3 Versioning과 Object Lock을 적용해 운영 실수에 의한 백업 삭제 방지
• 최소 분기 1회, 가능하면 월 1회 임시 Docker 환경에서 전체 복구 테스트 수행

다만 binlog 아카이빙과 복구 절차를 즉시 안정적으로 구현하기 어렵다면 우선 2번 일간 dump + EBS 스냅샷 방식부터 적용해 무백업 상태를 해소한 뒤 일정 기한을 정해 3번 방식으로 전환하는 단계적 접근도 가능할 것 같습니당

[lsy1307]

추가로 mysqldump 작업은 서버보다는 DB EC2에서 진행하는 방향이 더 좋을 것 같습니다! 서버에서 실행하면 배포나 재시작에 영향을 받을 수 있을 것 같습니당. DB EC2에서 실행하면 구성도 더 단순하고 서버와 백업 작업의 역할도 분리할 수 있을 것 같아요오

[Hexeong]

말씀하신 내용 듣고 DB EC2의 CPU 사용량을 모니터링해봤는데, 모의지원 기간에도 많이 사용하고 있지 않네요! 더욱이 위에 적어주신 방법도 아주 좋은 것 같습니다! 의견 감사합니다~

[Hexeong]

의견을 종합해봤을 때, 2번과 3번으로 좁혀지는 것 같습니다! 그래서 2번과 3번의 핵심을 비교해봤는데 다음과 같이 정리할 수 있었습니다!

구성	장점	복구 복잡도
EBS 스냅샷 + S3 dump	전체 DB를 빠르게 복구 가능	스냅샷과 dump 중 무엇을 사용할지 판단 필요
S3 dump + binlog	논리 백업 체계 하나로 통일되고 시점 복구 가능	dump와 binlog 연결 및 재생 순서 관리 필요

해당 상황에서 저는 S3 dump + binlog 방식이 옳게 느껴지긴 합니다. 그 이유는 아래와 같습니다!

1. 현재 DB 규모가 크지 않기 때문에 EBS 스냅샷으로 얻는 “빠른 물리 복구”의 장점이 아직 크지 않습니다.
2. 비용을 무시할 수는 없습니다. 저희가 RPO를 적어도 5분 정도로 해야 데이터 백업 전략을 도입하는 의미가 있습니다.
3. 반면 S3 논리 백업으로 통일하면 EBS 상태와 관계없이 복구 절차를 동일하게 가져갈 수 있습니다.
4. 특히 잘못된 쿼리가 발생한 경우, EBS 스냅샷은 스냅샷 생성 시점까지만 돌아갈 수 있지만 binlog는 문제가 된 쿼리 직전까지 복구할 수 있습니다.

[Hexeong]

해당 방식으로 작업 진행할 생각인데, 혹시 여기서 수정이 필요한 부분이 있을까요??