모니터링 & 자동화 5
고객사 RDS 통합 모니터링 플랫폼 구축 — Part 5: EOS 추적과 정기점검 보고서
고객사 내 EOS 관리 및 월 정기점검 보고서에 대한 자동화를 고민한 내용을 다룹니다. 이전까지의 글들은 실시간 모니터링 에 가까운 기능들이었습니다. 이번에는 매주 또는 매월 한 번 사람이 손으로 정리해야 했던 작업, 그래서 결국 안 하게 되는 작업을 포털이 대신 해 주는 영역을 고민하고 자동화한 내용에 대해서 다루었습니다. 이번에는 각 고객사 ...
고객사 RDS 통합 모니터링 플랫폼 구축 — Part 4: 알림 체계 및 운영 부담을 줄이는 도구들
이번 편에서는 정말 필요한 알림만 선별하고, 운영 부담을 줄이는 관리 기능 다섯 가지를 차례로 풀어 봅니다. 알림 시스템을 만드는 일은 알람을 발송 하는 것만으로 끝나지 않습니다. 알람이 울린 뒤 의 시간이 더 길고, 그 동안 DBA 가 손으로 만지는 화면이 따로 있습니다. 같은 알람을 잠시 안 울리게 가려 두기, 인스턴스 하나에만 다른 임계치를 ...
고객사 RDS 통합 모니터링 플랫폼 구축 — Part 3: 어떤 지표를 어떻게 보는가
DBA 가 매일 들여다보는 세 가지 화면 을 정리합니다. CloudWatch 시계열, Performance Insights 패널, 그리고 PI 상대 비교 분석입니다. 화면을 만들기 전에 더 일찍 결정해야 했던 질문이 있었습니다. 무엇을 볼 것인가 입니다. AWS RDS 의 CloudWatch 가 노출하는 메트릭만 해도 20개가 넘고, 같은 정보를 ...
고객사 RDS 통합 모니터링 플랫폼 구축 — Part 2: APScheduler 와 알림 매커니즘
1편에서 소개한 인프라 위에 9개의 주기 작업과 알림 매커니즘이 한 프로세스 안에서 어떻게 돌아가는지를 짚어 봅니다. 1편의 마지막에 APScheduler 9개 잡 이라는 표현이 한 번 등장했고, 알림 지연을 1분 이내로 묶었습니다 라는 한 문장도 있었습니다. 이 글은 그 한 줄들을 풀어 쓰는 글입니다. 어떤 잡들이 어떤 주기로 돌아가는지, 한 고...
고객사 RDS 통합 모니터링 플랫폼 구축 — Part 1: 배경
사내 DB 모니터링 포털 시리즈 1편입니다. Grafana + VictoriaMetrics 풀스택을 한 달 만에 접고 AWS API + 자체 포털로 갈아엎은 의사결정, 현재 아키텍처로 회귀한 배경, 그리고 이를 Claude Code 의 도움을 받아 5주 만에 완성한 기록을 담았습니다. 30개 고객사 100여 대의 RDS 가 한 화면에 들어와 있...