Part 2: Kiro로 RDS/Aurora 장애 분석 자동화하기 — 터미널에서 분석하기

이 글은 “Kiro로 RDS/Aurora 장애 분석 자동화하기” 시리즈의 두 번째 글입니다.

Part 1: “Kiro로 RDS/Aurora 장애 분석 자동화하기 — IDE에서 분석하기”
Part 2 (해당글): “Kiro로 RDS/Aurora 장애 분석 자동화하기 — 터미널에서 분석하기”
Part 3: “Kiro로 RDS/Aurora 장애 분석 자동화하기 — 매일 자동으로 보고서 받기”

시리즈에서 구성하는 자동화 솔루션은 편의상 KIDA(Kiro Database Analyzer)라고 부릅니다. 이 시리즈에서는 Kiro, Steering, Hook, MCP 서버를 조합해 구성한 활용 예시입니다. 시리즈는 총 3부로 구성됩니다.

이 편에서 다루는 것

Part 1에서는 Kiro IDE의 Hook 버튼 하나로 Amazon RDS/Amazon Aurora 장애 분석을 실행하는 방법을 소개했습니다. 하지만 IDE를 띄우기 어려운 환경이 있습니다.

• EC2 인스턴스 위의 SSH 세션 — 로컬 IDE 없이 점검을 돌려야 할 때
• Bastion / 운영 서버 — 콘솔 접근은 막혀 있고 SSH만 열려 있을 때
• CI/CD·cron 자동화 연동 — 사람이 버튼을 누르지 않아도 분석이 돌아야 할 때

따라서 이 글에서는 Kiro CLI를 사용하여 터미널에서 Amazon RDS/Amazon Aurora 분석을 수행하는 방법을 다룹니다. Part 1에서 만든 Steering 파일과 MCP 서버 설정은 그대로 재사용하고, 새롭게 Custom Agent 두 개(kida-daily, kida-issue)를 정의하여 일일 점검과 이슈 원인 분석을 각각 전용 Agent로 실행합니다. 마지막으로 Aurora MySQL에서 Replication Lag 시나리오를 재현하여 실제 보고서가 생성되는 과정을 확인합니다.

사전 준비

Step 1: Kiro CLI 설치

curl -fsSL https://cli.kiro.dev/install | bash

참고: MCP 서버 실행에 필요한 `uvx`가 설치되어 있지 않은 경우, 아래 명령으로 설치합니다. (Amazon Linux 2023 등 일부 환경에서는 기본 설치되어 있지 않을 수 있습니다.)

curl -LsSf https://astral.sh/uv/install.sh | sh

Step 2: 첫 실행 시 인증

EC2 등 헤드리스 환경에서 Kiro CLI를 처음 실행하면 브라우저 인증이 필요합니다:

$ kiro-cli chat --agent kida-daily

Confirm the following code in the browser
Code: XXXX-XXXX
Open this URL: https://view.awsapps.com/start/#/device?user_code=XXXX-XXXX

표시된 URL을 로컬 PC의 브라우저에서 열고 인증 코드를 입력하면 됩니다. 한 번 인증하면 이후에는 자동으로 로그인됩니다.

Step 3: MCP 서버 구성

CLI에서도 IDE와 동일한 mcp.json을 사용합니다. ~/.kiro/settings/mcp.json에 3개 MCP 서버를 설정합니다:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": ["mcp-proxy-for-aws@latest", "https://aws-mcp.us-east-1.api.aws/mcp", "--metadata", "AWS_REGION=us-east-1"],
      "disabled": false,
      "autoApprove": ["aws___call_aws", "aws___search_documentation"]
    },
    "cloudwatch-mcp": {
      "command": "uvx",
      "args": ["awslabs.cloudwatch-mcp-server@latest"],
      "env": { "AWS_REGION": "us-east-1", "FASTMCP_LOG_LEVEL": "ERROR" },
      "disabled": false,
      "autoApprove": ["get_metric_data", "analyze_metric", "get_recommended_metric_alarms", "get_active_alarms", "get_alarm_history", "describe_log_groups", "analyze_log_group", "execute_log_insights_query", "get_logs_insight_query_results"]
    },
    "aws-knowledge-mcp-server": {
      "command": "uvx",
      "args": ["fastmcp", "run", "https://knowledge-mcp.global.api.aws"],
      "disabled": false,
      "autoApprove": ["*"]
    }
  }
}

Step 4: Steering 파일 구성

CLI에서는 ~/.kiro/steering/에 글로벌 Steering 파일을 저장하면 모든 프로젝트에 자동 적용됩니다. Steering 파일(rds-troubleshoot.md)은 Part 1에서 정의한 그대로 재사용합니다. 이 파일은 MCP 도구 사용 구분(cloudwatch-mcp 우선, aws-mcp 보조), 인스턴스/클러스터 레벨 메트릭 구분 등 분석 가이드를 담고 있습니다. 상세 설명은 Part 1: Kiro로 RDS/Aurora 장애 분석 자동화하기 — IDE에서 분석하기을 참고하세요.

mkdir -p ~/.kiro/steering
# Part 1의 rds-troubleshoot.md를 복사 (CloudWatch MCP 도구 가이드 + 인스턴스/클러스터 레벨 메트릭 구분 포함)

cp .kiro/steering/rds-troubleshoot.md ~/.kiro/steering/

Steering 파일의 핵심은 두 가지입니다:
1. MCP 도구 사용 구분 — cloudwatch-mcp의 analyze_metric, get_recommended_metric_alarms, analyze_log_group 등 전용 도구를 우선 사용하고, aws-mcp는 RDS API, CloudTrail 등 CloudWatch MCP가 커버하지 않는 영역에 사용
2. 인스턴스/클러스터 레벨 메트릭 구분 — CPU, Memory, Connections, Swap, ReplicaLag → 인스턴스별 수집, VolumeBytesUsed → 클러스터 레벨 수집

Custom Agent 구성

kida-daily: 일일 점검 Agent

Agent 설정 파일 (.kiro/agents/kida-daily.json):

{
  "name": "kida-daily",
  "description": "KIDA - RDS/Aurora 일일 점검 보고서 자동 생성 에이전트",
  "tools": ["read", "write", "shell", "aws"],
  "allowedTools": ["read", "write", "shell", "aws"],
  "resources": ["file://.kiro/steering/**/*.md"],
  "includeMcpJson": true,
  "prompt": "You are KIDA. First list all clusters with numbered list, then wait for selection. After selection, collect 9 items, generate HTML report with Tailwind CSS, and open in browser.",
  "model": "claude-sonnet-4-6"
}

kida-issue: 이슈 원인 분석 Agent

일일 점검과 별도로, 특정 시간대의 이슈를 심층 분석하는 전용 Agent입니다.

Agent 설정 파일 (.kiro/agents/kida-issue.json):

{
  "name": "kida-issue",
  "description": "KIDA - RDS/Aurora 이슈 원인 분석 에이전트. 특정 시간대의 장애/성능 이슈를 심층 분석합니다.",
  "tools": ["read", "write", "shell", "aws"],
  "allowedTools": ["read", "write", "shell", "aws"],
  "resources": ["file://.kiro/steering/**/*.md"],
  "includeMcpJson": true,
  "prompt": "You are KIDA Issue Analyzer. First list all clusters with numbered list, then wait for selection. After selection, ask for the time range to analyze (e.g., 2026-04-10 20:00~21:00 KST). Then collect CloudWatch Metrics, Logs, RDS Events, CloudTrail, Database Insights (Wait Events, Top SQL), RDS Recommendations. Generate HTML report with Tailwind CSS including root cause analysis and recommended actions, then open in browser.",
  "model": "claude-sonnet-4-6"
}

Agent 실행 방법

1. 대화형 모드:

kiro-cli chat --agent kida-daily 
or
kiro-cli chat --agent kida-issue 

//일일 보고서 생성 혹은 장애 보고서를 생성하실 수 있습니다.

2. 스크립트 자동 실행 (--no-interactive 모드)

아래의 명령어를 입력시 자동으로 보고서까지 생성합니다.

kiro-cli chat --agent kida-daily --no-interactive -- 'kida-test 클러스터에 대해 일일 점검 보고서를 생성해줘'

CLI Agent는 IDE Hook과 동일한 MCP 서버와 Steering 파일을 사용하므로 분석 품질이 동일합니다.

Agent 설정의 model 필드에서 claude-sonnet-4-6, claude-sonnet-4, claude-opus-4 등 Kiro에서 지원하는 모델을 선택할 수 있습니다.

실제 테스트: Replication Lag 원인 분석 (Aurora MySQL)

Writer 인스턴스에 대량 쓰기 부하를 발생시켜 Reader의 Replication Lag을 유발하고, Kiro로 원인을 분석했습니다.

테스트 환경

• 클러스터: kida-test (Aurora MySQL 8.0.mysql_aurora.3.10.3)
• Writer: kida-test-instance-1-us-east-1d (db.t4g.large, vCPU 2)
• Reader: kida-test-reader-us-east-1a (db.t4g.large)
• Database Insights: Advanced 모드 활성화 (465일 보존)
• Enhanced Monitoring: 1초 간격

kida-issue Agent 실행

kiro-cli chat --agent kida-issue

[kida-issue] kida-test 클러스터에 대해 2026-04-17 14:00~14:10 KST 시간대의 이슈를 분석해줘

kida-test 클러스터를 us-east-1에서 찾았습니다.
Writer: kida-test-instance-1-us-east-1d
Reader: kida-test-reader-us-east-1a

✅ CloudWatch Metrics 수집 완료 (CPU, Memory, Connections, IOPS, WriteLatency, ReadLatency)
✅ AuroraReplicaLag 수집 완료
✅ Database Insights Data 수집 완료 (DB Load, Wait Events, Top SQL)
✅ RDS Events / CloudTrail 조회 완료
✅ Error/Slow Query 로그 조회 완료
✅ RDS Recommendations 조회 완료

HTML 보고서가 /tmp/kida-report.html 파일로 저장되었습니다.

Kiro가 수집한 메트릭

Writer 메트릭 (kida-test-instance-1-us-east-1d)

Kiro의 근본 원인 분석

장애 타임라인

1. 14:05 KST — 대량 쓰기 워크로드 유입. WriteIOPS: 3.5/s → 818/s (234배 급증), DatabaseConnections: 3 → 135 (45배 급증)
2. 14:05~14:08 KST — InnoDB Index RW Lock 경합 폭발. wait/synch/sxlock/innodb/index_tree_rw_lock wait event가 DB Load의 89% 차지. Peak DB Load: 132.8 (vCPU 2개 대비 66배 초과). 다수의 세션이 동일 인덱스 B-Tree에 동시 접근하면서 SX Lock 경합 발생
3. 14:08 KST — Binlog 동기화 지연. MYSQL_BIN_LOG::COND_done wait가 DB Load 13.4까지 상승. WriteLatency 38.8ms로 급등
4. 14:09 KST — 자동 회복. 워크로드 종료 후 DB Load 0으로 복귀. 장애 지속 시간: 약 4분

Database Insights — Wait Events

AuroraReplicaLag 분석

• Replica Lag이 15ms → 75ms로 증가 (5배)
• Aurora의 스토리지 레이어 공유 아키텍처 덕분에 Lag이 ms 단위로 유지됨
• Writer의 WriteIOPS가 1,231/s까지 급증했음에도 Reader의 CPU는 15.3%로 안정적

Kiro의 권장 조치

정리

이 글에서는 Kiro CLI를 설치하고, Custom Agent(kida-daily, kida-issue)를 구성하여 터미널에서 RDS/Aurora 분석을 수행하는 방법을 다뤘습니다. 대화형 모드와 –no-interactive 모드를 모두 지원하며, IDE와 동일한 MCP 서버와 Steering 파일을 사용하므로 분석 품질이 동일합니다. 실제 Aurora MySQL 클러스터에서 대량 쓰기 부하로 Replication Lag을 유발하고, kida-issue Agent가 InnoDB Index RW Lock 경합(DB Load 132.8, vCPU 대비 66배)을 근본 원인으로 식별하는 과정도 확인했습니다.

Kiro CLI를 설치하고 이 글의 Agent 설정을 적용하면, EC2나 SSH 환경에서도 바로 RDS/Aurora 분석을 시작할 수 있습니다. Kiro에 대한 자세한 내용은 Kiro 공식 사이트에서, Amazon RDS와 Amazon Aurora에 대한 자세한 내용은 각 제품 페이지에서 확인할 수 있습니다.

다음 글에서는 EC2 + cron + SES/Slack을 조합하여 매일 아침 자동으로 점검 보고서를 받는 방법을 다룹니다.