feat: 백업 freshness 외부 모니터링 방식 논의 및 도입 여부 결정

[Hexeong]

어떤 기능인가요?

백업이 조용히 멈추는 상황을 외부에서 감지하는 freshness 모니터링을 검토합니다.

이 이슈는 도입을 확정한 작업이 아닙니다. 방식과 비용, 운영 부담을 논의한 뒤 도입 여부를 결정합니다. 결정 전까지 구현하지 않습니다.

배경

#66에서 백업 실패 알림을 구성했습니다. DB EC2의 백업 스크립트가 실패를 감지하면 API 서버를 거쳐 Discord로 알립니다. 다만 이 경로는 스크립트가 실행되고 있을 때만 동작합니다.

상황	현재 감지 가능 여부
업로드가 계속 실패	가능
binlog 누락, 번호 역행	가능
덤프 실패	가능
DB EC2 정지 또는 종료	불가능
systemd 타이머 자체가 멈춤	불가능
네트워크 단절	불가능

알릴 주체가 사라지면 알림도 사라지므로, 백업이 멈춘 것을 아무도 모르는 구간이 남습니다. 목표 RPO가 5분인 것을 감안하면 이 사각을 방치하기 어렵습니다.

검토한 방식

A. DB EC2에 exporter를 두고 Prometheus가 스크래핑

백업 스크립트가 기록하는 last-binlog-success를 textfile collector로 노출합니다.

• 구현이 가장 단순합니다. 이미 파일이 존재합니다.
• 관찰 주체가 관찰 대상 안에 있습니다. EC2가 멈추면 up == 0으로 감지되지만, 백업이 실제로 S3에 도달했는지는 확인하지 못합니다.
• DB EC2 보안 그룹이 현재 API 서버만 신뢰하므로 모니터링 서버도 허용해야 합니다.

B. 모니터링 서버가 S3를 직접 조회

모니터링 서버에서 주기적으로 버킷의 최신 객체 시각을 읽어 메트릭으로 노출하고, Prometheus가 수집한 뒤 Grafana Alerting으로 Discord에 알립니다.

time() - mysql_backup_last_binlog_upload_timestamp_seconds > 900
time() - mysql_backup_last_dump_upload_timestamp_seconds > 108000

• DB EC2 상태와 무관하게 "백업이 S3에 도달했는가"라는 최종 사실만 관찰합니다. 이 이슈가 요구하는 외부 관찰에 부합합니다.
• 기존 Grafana 대시보드에 백업 상태를 함께 표시할 수 있습니다.
• 모니터링 서버에 백업 버킷 s3:ListBucket 권한이 필요합니다. 권한 관리 원칙에 따라 수동으로 구성합니다.
• 모니터링 서버가 멈추면 알림도 멈춥니다.

C. EventBridge Scheduler와 Lambda

Lambda가 주기적으로 S3를 확인하고 임계를 넘으면 Discord로 직접 알립니다.

• 우리 인프라가 모두 멈춰도 동작합니다. 관찰 독립성이 가장 높습니다.
• Lambda 코드와 배포 경로가 추가되고 Grafana 대시보드에는 나타나지 않습니다.

비용 검토

전제를 확인한 결과 데이터 전송 비용은 발생하지 않습니다.

• 모니터링 서버는 퍼블릭 서브넷에서 IGW로 직접 통신하며 VPC에 NAT Gateway가 없습니다.
• S3에서 같은 리전의 AWS 서비스로 전송하는 트래픽은 무료입니다.
• 서울 리전 S3 Standard의 LIST 요청 단가는 1,000건당 0.0045 USD입니다.

5분 주기로 날짜 prefix를 조회할 때의 추정입니다.

항목	값
실행 빈도	8,640회/월
실행당 LIST	4회
월 LIST 요청	34,560회
월 비용	약 0.16 USD

C안도 Lambda와 EventBridge가 프리티어 범위이거나 소액이라 월 0.19 USD 수준으로, 비용은 방식 선택의 기준이 되지 못합니다.

버킷 전체를 조회하면 보관 기간 14일 기준 약 8,100개를 페이지네이션하게 되어 비용이 2.5배가 됩니다. 날짜 prefix로 좁히면 하루치가 한 페이지에 들어옵니다.

논의가 필요한 사항

• 어느 방식을 선택할지 결정합니다. 관찰 독립성과 운영 부담의 균형이 기준입니다.
• 모니터링 서버의 리소스 여유를 확인합니다. 현재 t4g.micro(2 vCPU, 1 GiB)에 Grafana, Prometheus, Loki가 함께 떠 있고 루트 볼륨은 8 GiB입니다. 여유가 없다면 인스턴스 상향이 선행되어야 하며 이 경우 월 6 USD 수준의 실제 비용이 발생합니다.
• 감시자를 누가 감시할지 정합니다. B안은 모니터링 서버가 멈추면 침묵하므로, 외부 헬스체크를 두거나 C안을 최후 방어선으로 함께 둘지 판단이 필요합니다.
• 임계값을 정합니다. 초기 후보는 binlog 15분, dump 30시간입니다.
• 알림 채널과 심각도를 정합니다. 기존 백업 실패 알림과 같은 채널을 쓸지, 별도로 둘지 결정합니다.
• 도입하지 않기로 할 경우 이 사각을 어떻게 감수할지 기록합니다.

결정 이후 진행할 작업

도입하기로 결정한 뒤에 아래를 진행합니다.

• 선택한 방식으로 메트릭 수집 또는 감시 경로를 구성합니다.
• 필요한 IAM 권한을 AWS에서 수동으로 구성합니다.
• 알림 규칙과 임계값을 설정합니다.
• 백업을 의도적으로 멈춰 알림이 발생하는지 검증합니다.
• 운영 문서에 감지 범위와 한계를 기록합니다.

참고할만한 자료(선택)

• feat: prod환경의 DB EC2의 데이터 백업 전략 #64
• feat: S3 기반 MySQL 백업 및 모니터링 파이프라인 구성 #66
• feat: MySQL 백업 실패 알림 연동 및 신규 AMI 반영 #73