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

어떤 기능인가요?

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

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

배경

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

알릴 주체가 사라지면 알림도 사라지므로, 백업이 멈춘 것을 아무도 모르는 구간이 남습니다. 목표 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를 조회할 때의 추정입니다.

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