pile·
인프라 / DevOps·AWS KoreaAWS Korea Tech·

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

AWS Kiro CLI 시리즈 2부로, IDE 를 띄울 수 없는 운영 환경(SSH 세션·bastion·CI/CD·cron)에서 터미널만으로 RDS/Aurora 를 분석하는 방법을 다룬다. Part 1 의 steering·MCP 설정을 그대로 이식하고 Custom Agent 2개를 더해, 실제 Aurora MySQL 의 replication lag 장애를 수치까지 짚어내는 과정을 보여준다.

핵심 포인트
  • IDE 가 안 되는 환경을 겨냥해 Kiro CLI + Custom Agent + MCP 서버 조합으로 분석을 CLI 로 이식했다.
  • Part 1 의 steering 파일(rds-troubleshoot.md)과 mcp.json 을 재사용하고, kida-daily·kida-issue 두 Custom Agent 를 새로 정의했다.
  • --no-interactive 모드로 cron·자동화 연동이 가능하고, IDE 와 같은 MCP·steering 을 써 분석 품질이 동일하다.
  • 테스트로 Aurora MySQL 에 대량 쓰기 부하를 줘 Reader replication lag 을 유발하고 Kiro 가 근본 원인을 자동 분석하게 했다.
  • Kiro 는 InnoDB index lock 경합(DB Load 132.8, vCPU 2개 대비 66배)을 약 4분짜리 장애의 핵심 원인으로 짚었다.
상세 정리
  • 문제: Part 1 의 IDE 분석은 EC2 SSH 세션, 콘솔 차단된 bastion, cron 자동화처럼 IDE 를 못 띄우는 환경에선 쓸 수 없었다.
  • 전략: IDE 에서 통한 방식을 CLI 로 옮기되 steering·MCP 설정은 재사용하고, 실행 단위만 Custom Agent 로 정의했다.
  • 설치: curl 로 Kiro CLI 를 깔고 MCP 실행용 uvx 를 추가하며, 헤드리스 환경은 브라우저 디바이스 코드로 한 번 인증하면 이후 자동 로그인된다.
  • MCP 구성: ~/.kiro/settings/mcp.json 에 aws-mcp(AWS_REGION 지정), cloudwatch-mcp(로그 레벨 ERROR), aws-knowledge-mcp 를 등록하고 cloudwatch 도구들을 자동 승인했다.
  • steering: ~/.kiro/steering/rds-troubleshoot.md 를 글로벌 적용해, cloudwatch-mcp 우선·aws-mcp 보조 구분과 인스턴스/클러스터 레벨 메트릭 구분을 가이드했다.
  • Custom Agent: kida-daily(일일 점검)와 kida-issue(특정 시간대 심층 분석)를 claude-sonnet-4-6 모델로 정의하고, 클러스터 선택·시간 범위 입력을 프롬프트로 유도했다.
  • 실행: 대화형은 kiro-cli chat --agent 로, 자동은 --no-interactive 로 클러스터·작업을 인자로 넘긴다.
  • 테스트 환경: Aurora MySQL 8.0.mysql_aurora.3.10.3, Writer/Reader 모두 db.t4g.large(vCPU 2), Database Insights Advanced, Enhanced Monitoring 1초 간격이다.
  • 장애 타임라인: 14:05 에 WriteIOPS 가 3.5→818/s, DatabaseConnections 가 3→135 로 급증하며 대량 쓰기가 시작됐다.
  • 근본 원인: 14:05~14:08 에 wait/synch/sxlock/innodb/index_tree_rw_lock 경합이 DB Load 의 89%를 차지하고 peak DB Load 132.8(vCPU 대비 66배)에 달했다.
  • 후속 영향: 14:08 에 binlog 동기화 지연(MYSQL_BIN_LOG::COND_done)으로 WriteLatency 가 38.8ms 로 튀고, AuroraReplicaLag 은 15ms→75ms 로 5배 올랐다 14:09 에 회복됐다.
  • Aurora 특성: 스토리지 공유 아키텍처 덕에 lag 이 ms 단위로 유지되고 Reader CPU 는 15.3%로 안정적이었다.
  • Kiro 권장: 인스턴스 스케일업과 대량 INSERT 를 1,000행 청크로 분할, 인덱스 설계 검토, RDS Proxy·커넥션 풀 제한, CloudWatch 알람을 우선순위로 제시했다.
왜 읽나IDE 없이 SSH·bastion·cron 환경에서 RDS/Aurora 장애를 분석해야 하는 운영 엔지니어에게, Kiro CLI 설정과 실제 lock 경합 진단 사례를 함께 보여주는 실전 가이드.
AWS Korea
AWS Korea Tech 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

    Amazon Bedrock AgentCore의 VPC egress 기능(2026년 4월 추가)을 활용해 온프레미스 LLM·사내 IdP·사내 MCP 서버에 인터넷 노출 없이 연결하는 방법을 다룬다. 규제 산업 엔터프라이즈가 기존 사내 자산을 그대로 유지하면서 Bedrock AgentCore를 안전하게 구축하기 위한 구성 가이드다.

    요약 이어보기
    #mcp#amazon-bedrock#vpc+2
  2. 인프라 / DevOps·gitlab-engGitLab Blog·

    OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

    GitLab을 단일 제어 플레인으로 삼아 OpenTofu로 AWS 인프라를 프로비저닝하고, Argo CD로 GitOps 기반 애플리케이션 배포까지 자동화하는 엔드투엔드 튜토리얼이다. VPC·EKS 클러스터 구성부터 Helm 기반 툴 설치, 샘플 앱 배포까지 모든 과정이 GitLab CI/CD 파이프라인으로 연결된다.

    요약 이어보기
    #kubernetes#aws-eks#gitops+2
  3. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례

    패션 기업 F&F가 Amazon Bedrock과 LiteLLM 프록시를 결합해 구축한 사내 LLM 플랫폼 운영 사례다. API 키 셀프서비스 발급, 모델별 접근 승인 워크플로, 사용자·프로젝트별 예산 자동 차단까지 전 과정을 직접 구현한 아키텍처 결정과 운영 교훈을 공유한다.

    요약 이어보기
    #kubernetes#amazon-bedrock#litellm+2