AI를 활용한 장애 분석
데이터베이스 mcp는 써 볼수록 활용도가 다양한 것 같습니다. 이번에는 장애 상황을 만들고 조치하는 시나리오를 테스트 해봤습니다. 모델은 이전과 동일하게 sonnet 4.6으로 진행했으며 별다른 프롬프트 없이 간단히 분석을 요구했습니다.
❯ 지금 돌아는 쿼리 분석좀 해줄래? 위험한애야?
Called mcp_server_mysql 6 times (ctrl+o to expand)
● 분석 결과: 위험하지 않습니다. 잘 짜인 쿼리예요.
---
실행 중인 쿼리
SELECT c.grade, COUNT(*), SUM(o.total_amount)
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.grade
고객 등급별 주문 수 / 주문 총액 집계 쿼리입니다.
---
EXPLAIN 분석
┌───────────┬───────────┬──────────────┬───────────────────────────────┐
│ 테이블 │ 접근 방식 │ 사용 인덱스 │ 평가 │
├───────────┼───────────┼──────────────┼───────────────────────────────┤
│ customers │ index │ idx_grade │ 인덱스만 읽음 (커버링 인덱스) │
├───────────┼───────────┼──────────────┼───────────────────────────────┤
│ orders │ ref │ idx_customer │ customer_id로 인덱스 조인 │
└───────────┴───────────┴──────────────┴───────────────────────────────┘
- 풀스캔 없음
- 두 테이블 모두 인덱스 정상 활용
- customers는 인덱스만 읽고 디스크 데이터 블록 접근 안 함 (Extra: Using index)
- orders는 customer당 평균 9행만 조회
---
그런데 왜 오래 걸리냐?
인덱스는 잘 쓰고 있지만, 집계 대상 자체가 큼:
- customers: 99만 행
- orders: 970만 행
버퍼풀이 128MB밖에 안 되다 보니 데이터가 캐시에 없어 디스크 I/O 때문에 느린 것입니다. 쿼리 자체 문제가 아니라 버퍼풀 부족이 원인입니다.
결론: 쿼리는 정상, 버퍼풀 증설이 근본 해결책입니다.
질의 후 10초 정도만 있으면 위 내용처럼 분석 결과를 출력합니다.
- 실행중인 쿼리확인
- 실행 계획 조회
- 실행 계획 분석
- 분석을 통한 원인 파악
- 해결책 제시
저가형 모델로 테스트를 진행했음에도 불구하고 합리적인 사고 과정을 통해 좋은 결과를 내놨습니다. ai가 sql실행 권한만 가져도 얼마나 능숙하게 일을 해낼 수 있는지 알 수 있습니다. 이걸 모니터링과 연동하면 아주 편리한 기능이 될 것 같습니다.
+============+ +------------+
| DB | -- | Monitoring |
+============+ +------------+
^ /
\ (장애 분석) / (장애 상황 전달)
\ /
\ v
+----------+ +----------+
| MCP | <----> | User |
+----------+ +----------+
모니터링 서버가 alert을 감지하는 시점 그 내용을 mcp 서버에 전달하면, ai가 실시간으로 db의 상태를 체크하고 alert 발생 원인을 분석합니다. 이후 사용자가 분석 결과를 바탕으로 추가적인 조치를 진행할 수 있으며, 장애 시점 즉각적인 상호작용 또한 가능합니다. 얼마 전 참석한 당근 db 밋업에서 ai 분석 기능을 추가한 자체 모니터링 서비스를 소개했었는데, mcp 연동까지 된다면 더 좋은 도구가 되지 않을까 생각합니다.