<Reowns>rlaeowns
Admin

AI를 활용한 장애 분석

Reowns · 77 days ago

데이터베이스 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초 정도만 있으면 위 내용처럼 분석 결과를 출력합니다.

  1. 실행중인 쿼리확인
  2. 실행 계획 조회
  3. 실행 계획 분석
  4. 분석을 통한 원인 파악
  5. 해결책 제시

저가형 모델로 테스트 했음에도 불구하고 합리적인 사고 과정과 좋은 결과를 내놨습니다. ai가 sql실행 권한만 가져도 얼마나 능숙하게 일을 해낼 수 있는지 알 수 있습니다. 이걸 모니터링과 연동하면 아주 편리한 기능이 될 것 같습니다.

+============+    +------------+
|     DB     | -- | Monitoring |
+============+    +------------+
    ^                   /
     \ (장애 분석)     / (장애 상황 전달)
      \              /  
       \            v
        +----------+        +----------+ 
        |    MCP   | <----> |   User   |
        +----------+        +----------+
← Back