고객사 RDS 통합 모니터링 플랫폼 구축 — Part 4: 알림 체계 및 운영 부담을 줄이는 도구들

이번 편에서는 정말 필요한 알림만 선별하고, 운영 부담을 줄이는 관리 기능 다섯 가지를 차례로 풀어 봅니다.

알림 시스템을 만드는 일은 알람을 발송 하는 것만으로 끝나지 않습니다. 알람이 울린 뒤 의 시간이 더 길고, 그 동안 DBA 가 손으로 만지는 화면이 따로 있습니다. 같은 알람을 잠시 안 울리게 가려 두기, 인스턴스 하나에만 다른 임계치를 적용하기, 콘솔에 들어가야 할 때 빠르게 OTP 코드 받기, AWS 자체 장애를 알람 발생 직전에 감지하기. 어느 하나도 주인공 은 아니지만 없으면 매일 한 시간씩 더 일하게 되는 기능들입니다.

이 글에서는 그 다섯 가지 도구, 즉 알림 관리 UI, 파라미터 분석, 콘솔 접속, AWS Health, 이벤트 확인 처리를 차례로 적어 봅니다.

알림 관리 UI

알람이 발송 되는 부분은 2편에서 다뤘습니다. 이번 화면은 그 알람을 DBA 가 정말 필요한 것만 남도록 선별하는 영역입니다. 한 화면에 다음 다섯 가지를 모아 두었습니다.

• DBA 연락처 관리: 알람을 받을 사람 목록입니다. 이름, Telegram 채팅 ID, 이메일을 등록해 두고, 사람마다 활성 / 비활성 토글이 있습니다. 누군가 휴가를 가서 알람을 잠시 안 받게 하고 싶으면 그 사람만 OFF 로 두면 됩니다.
• 임계치 설정: CPU 사용률, 연결 수, 여유 메모리·스토리지, 읽기·쓰기 지연 여섯 가지 메트릭의 경고·심각 임계치를 화면에서 바로 수정할 수 있습니다. 전체 인스턴스에 공통으로 적용되는 기본 임계치 가 한 벌 있고, 특정 인스턴스만 다른 값 으로 두고 싶을 때는 그 인스턴스 전용 임계치를 따로 등록합니다. 예를 들어 원래부터 CPU 가 높게 도는 분석 DB 한 대만 임계치를 90% 로 올리는 식입니다.
• 4종 억제 관리: 1시간 자동 억제 / 영구 억제 / 유지보수 시간대 / 반복 억제 일정. 2편에서 동작 원리를 본 네 가지 억제 규칙을 등록·수정·삭제 하는 곳입니다. 예를 들어 매일 새벽 2시부터 4시까지 도는 ETL 잡 때문에 CPU 가 잠시 튀는 게 정상이라면, 반복 억제 에 그 시간대를 한 번 등록해 두는 식입니다.
• 알림 히스토리: 지금까지 발생한 알람을 언제 발생, 언제 해소, 어떻게 해소 (자연 해소 / DBA 조치 해소 / 억제 처리) 의 형태로 보여 줍니다. 고객사·심각도·기간으로 필터해 볼 수 있어서 지난주 우리 팀이 받은 알람이 몇 건이었는지 같은 질문에 바로 답이 나옵니다.
• Telegram 인라인 키보드: 알람 메시지 안에 바로 확인 / 1시간 억제 / 영구 억제 버튼을 같이 박아서 보냅니다. 폰만 보고 있어도 알람을 다듬을 수 있게 한 셈입니다.

영구 억제 규칙이 활성 알람도 함께 해소하는 이유

알림 관리의 억제 일정 탭 화면. 반복 억제 (요일·시간대) 와 일회성 유지보수 일정을 같이 관리합니다.

이 다섯 가지 중에 한 가지만 왜 그렇게 만들었는지 를 적어 두고 싶습니다. 영구 억제 규칙 의 동작입니다.

처음에는 영구 억제 규칙 을 앞으로 발생할 알람만 가리는 것 으로 만들었었습니다. 그런데 운영을 해 보니 그렇지 않았습니다. 사람들은 보통 지금 울려 있는 알람 을 한참 보다가 아, 이건 무시하기로 하자 결심하고 영구 억제를 거는 경우가 가장 많았습니다. 그런데 그 알람이 영구 억제 후에도 계속 활성 상태 로 남아 있으면, 사람이 또 가서 확인 버튼을 한 번 더 눌러야 했습니다. 그게 이상했습니다.

그래서 영구 억제 규칙을 등록하는 순간, 그 규칙에 매칭되는 활성 알람도 같이 닫고, 해소 알림까지 한 번 보내는 방식으로 바꿨습니다. 조용하게 만들고 싶어서 등록한 규칙이 마지막 한 번 더 시끄러운 알람을 내고 닫히는 셈이라 작은 이상함이지만, 한 번 닫힌 뒤로는 더 이상 안 울립니다. 받는 사람도 이건 우리가 안 보기로 결정해서 닫힌 알람이구나 라고 한눈에 알아볼 수 있도록 해소 메시지 앞에 🔕 이모지를 붙여서 보냅니다.

파라미터 분석

DBA 가 운영하면서 자주 보는 화면 중에 DB 파라미터 가 있습니다. 기본값에서 무엇이 바뀌었는지, 바뀐 값이 위험한 패턴은 아닌지, 현재 인스턴스 사양에 맞는 권장값은 얼마인지 같은 질문이 매번 같이 떠오릅니다. 이 질문에 답하려면 보통 AWS 콘솔에서 파라미터 그룹을 열고, 기본값과 비교하면서 몇 개나 바뀌었지? 를 손으로 세야 합니다. 인스턴스가 한두 대면 그럭저럭 견디지만, 30개 고객사 100여 대를 다니면서 그 작업을 매번 하는 건 비효율적이었습니다.

포털의 파라미터 분석 페이지가 이 답을 한 화면에 모아 줍니다. 인스턴스 하나를 누르면 다음 네 묶음이 위에서부터 차례로 보입니다.

• 사용자 변경 파라미터: 엔진 기본값과 다른 값을 적용한 항목 목록. 사람이 의도해서 바꾼 것들이 한눈에 잡힙니다. 같은 고객사라도 어떤 인스턴스는 비표준 설정인지 가 표 한 장에 보입니다.
• 메모리 파라미터 비율: innodb_buffer_pool_size (MySQL 계열) 또는 shared_buffers (PostgreSQL 계열) 같이 RAM 을 직접 쓰는 파라미터를 인스턴스 RAM 대비 비율 로 보여 줍니다. 예를 들어 RAM 8GB 인스턴스의 shared_buffers 가 6GB 라면 75%, 너무 큼.
• 위험 파라미터: 알면서도 가끔 잊는 위험 설정을 빨갛게 표시합니다. ACID 위험 (innodb_flush_log_at_trx_commit = 0/2), 복제 불일치 (sync_binlog = 0) 같은 패턴이 자동으로 잡힙니다.
• 연결 수 분석: 현재 max_connections 설정값, 인스턴스 사양 기준 추정 권장값, 그리고 최근 1시간 평균 실제 사용 연결 수 세 가지를 나란히 둡니다. 설정은 1000인데 실제로는 50밖에 안 쓰는 과한 설정이 한 줄에 보입니다.

내부적으로는 인스턴스가 Aurora 클러스터에 속해 있는지, RDS Read Replica 구성인지, 단독 인스턴스인지에 따라 적절한 파라미터 그룹을 자동으로 따라가서 가져옵니다. 같은 파라미터 그룹을 여러 인스턴스가 공유하는 경우는 한 번만 가져와 재사용하므로 AWS API 호출 비용도 적게 듭니다. 사용자가 신경 쓸 부분은 고객사 고르고 → 인스턴스 누르기 두 동작뿐입니다.

콘솔 접속 관리

고객사 AWS 콘솔에 직접 들어가야 할 일이 종종 있습니다. 포털에서 안 만들어 둔 기능, 예를 들어 manual snapshot 을 직접 뜨거나 새 파라미터 그룹을 만드는 일이 그런 경우입니다. 그럴 때마다 MFA OTP 코드 를 받는 게 매번 작은 마찰점이었습니다. 휴대폰 OTP 앱을 켜는 데 10초쯤 걸리고, 코드가 30초마다 바뀌는데 그동안 패스워드를 입력하다 보면 새 코드를 다시 받아야 했습니다. 그 짧은 시간이 30개 고객사에 누적되면 적지 않은 마찰입니다.

포털의 콘솔 접속 메뉴에서는 고객사 콘솔 계정 정보(아이디, 비밀번호, MFA 시크릿)를 안전하게 등록해 두고, OTP 보기 버튼만 누르면 지금 유효한 6자리 코드 와 남은 유효 시간 이 같이 표시됩니다. 클립보드 복사 버튼도 있어서 코드 확인 → 복사 → 콘솔 입력 이 한 호흡에 끝납니다. 남은 시간이 5초 이하면 곧 바뀐다는 시그널 로 색이 빨갛게 변해서 지금 복사하면 늦는다 는 게 한눈에 보입니다.

한 콘솔 계정에는 MFA 시크릿을 최대 세 개 까지 등록해 둘 수 있습니다. 메인·백업·임시 같이 운영 상황에 따라 같은 계정에 여러 MFA 기기가 묶이는 경우를 위해 여유를 두었습니다.

MFA 시크릿이 DB 에 저장된다는 점은 의식해 두어야 합니다. 사내에 한정된 포털이고 어드민 인증 뒤에서만 노출되지만, 사용자·조직 정책에 따라 추가 암호화나 외부 vault 연동이 필요할 수 있습니다.

AWS Health 배너

평소엔 "서울 정상 작동" 한 줄로 조용히 가려져 있고, 호버 시 영향받는 서비스 상세가 펼쳐집니다.

운영하다 보면 내 인스턴스의 문제 가 아니라 AWS 자체 의 문제일 때가 있습니다. 서울 리전 RDS 가 잠시 Degraded 상태에 들어가면 우리 알람이 폭주하는 것처럼 보이지만 실제로는 AWS 가 손쓰고 있는 중입니다. RDS 가 잠시 흔들리는 거라면 우리가 더 들여다보는 건 의미 없다 는 판단을 알람이 막 울리는 와중에 빠르게 내릴 수 있게 이 항목을 구현했습니다.

그래서 메인 대시보드 상단에 AWS Health 배너 를 띄워 두었습니다. 평소엔 조용히 가려져 있다가, 서울 리전 어딘가에 영향이 생기면 주황 또는 빨강 으로 색이 바뀌면서 어떤 서비스가 어떤 상태인지 같이 표시됩니다.

배너가 참고하는 정보는 AWS 가 공개하는 서비스 상태 페이지 입니다. 포털이 1분에 한 번씩 들여다보고 결과를 잠시 저장해 둡니다. 만약 AWS 상태 페이지 자체 가 응답하지 않으면 (어쩌면 AWS 가 정말 큰 사고를 당한 순간일 수도 있고, 단순 네트워크 문제일 수도 있고), 포털은 직전에 받아 둔 정보 를 그대로 보여 주고, 그것조차 없으면 일단 정상으로 가장 합니다. 외부 API 의 일시적인 실패 때문에 메인 대시보드 자체가 멈추는 일은 일어나지 않게 한 셈입니다.

이벤트 확인 처리

RDS의 여러 이벤트, 즉 페일오버 / 백업 시작 / 유지보수 시작 같은 메시지는 한 번 알람이 가면 사람의 확인이 필요 합니다. 그냥 두면 같은 이벤트 메시지가 화면에 계속 노출되어서 읽었는데 또 읽어야 하는 피로감이 생깁니다.

그래서 알람 메시지에는 확인 버튼이 같이 옵니다. 포털 UI 에서도, Telegram 인라인 키보드에서도 누를 수 있습니다. DBA 가 확인 을 누르면 그 이벤트는 확인됨 으로 표시되고, 누군가가 확인했다 는 한 줄짜리 알림이 같은 채널로 다시 한 번 발송됩니다. 다른 DBA 들이 이미 누군가가 보고 있다 는 신호를 받게 되는 셈입니다.

작은 디테일이지만 이게 의외로 효과가 컸습니다. 팀에서 중복으로 들여다보는 일이 자주 사라졌습니다. Telegram 메시지의 확인 버튼이 운영 중 가장 많이 눌리는 버튼 중 하나가 된 이유인 것 같습니다.

마무리

본 편에서는 각 패널에 대한 기능들을 한 번 정리해 두고 싶었습니다.

한 페이지를 만들기 위해 9개의 백그라운드 잡, 여러 갈래의 데이터 수집·평가, 다섯 가지 관리 화면이 한 자리에 모여 있는 셈입니다. 1편을 처음 쓸 때 이걸 풀어 쓰면 길어질 것 같다고 느꼈는데, 4편까지 와 보니 각 패널마다 한 편씩 가도 모자랐을 것 같다는 생각이 들만큼 정성과 노력이 든 결과물을 보니 상당히 뿌듯합니다.

이 글에서 다룬 다섯 가지 도구는 주인공 은 아니지만 없으면 불필요하게 시간을 낭비하게 되는 종류입니다. 알람을 발송하는 것보다 알람이 울린 뒤 의 사이클이 사실 더 길고, 그 사이클을 다듬는 도구들이 모니터링 시스템의 실용성 을 만드는 것 같습니다.

다음 5편에서는 사람이 손으로 안 쓰는 정기 보고서를 자동화 하는 영역, 즉 EOS 추적 (매주 AWS 문서 파싱) 과 정기점검 보고서 (15섹션 PDF 자동 합성) 를 풀어 볼 예정입니다.

×