pile·
DB / 데이터·클라우드메이트클라우드메이트·

Database Insights, 메트릭 대시보드 사용자 정의 지원 추가

AWS CloudWatch Database Insights가 2025년 3월 26일 메트릭 대시보드 사용자 정의 기능을 추가한 내용을 소개하며, 기존 기능과 신규 위젯 추가 방법, DB 엔진별 지원 지표 수, 유료 티어 비용을 구체적으로 다룬다. Performance Insights·Enhanced Monitoring·CloudWatch를 개별 확인하던 방식을 단일 대시보드에서 통합 조회하고 원하는 지표를 추가할 수 있다.

핵심 포인트
  • Database Insights는 RDS/Aurora의 성능 문제·장애 원인 파악을 위해 Performance Insights, Enhanced Monitoring, CloudWatch를 한 화면에서 통합 제공한다.
  • 2025년 3월 26일부터 기본 제공 지표 외에 원하는 지표를 위젯으로 추가할 수 있다.
  • DB 엔진별로 기본 제공 지표 수가 다르다: SQL Server 13개, Oracle 14개, PostgreSQL 19개, MariaDB·MySQL 각 23개.
  • 유료 티어 비용은 서울 리전 기준 프로비저닝 인스턴스 vCPU-시간당 $0.0125, Aurora Serverless v2 ACU-시간당 $0.003125다.
  • 같은 AWS 계정 내 리소스만 지원하며, 유료 티어 활성화 시 Performance Insights 보존 기간이 15개월로 연장된다.
상세 정리
  • 배경: 기존에는 DB 성능 문제를 파악할 때 Performance Insights, Enhanced Monitoring, CloudWatch를 각각 별도로 확인해야 해서 컨텍스트 전환 비용이 컸다.
  • Database Insights 위치: CloudWatch → 인사이트 → Database Insights에서 접근한다.
  • 통합 제공 정보: 상위 SQL, 상위 대기, 상위 호스트 등 Performance Insights 정보가 통합된다.
  • 신규 사용자 정의 기능: Database Insights → 데이터베이스 인스턴스 → 데이터베이스 원격 분석 → 지표 → Create widget 경로로 원하는 지표를 추가한다. 한 번에 하나의 위젯만 추가 가능하지만 위젯 하나에 여러 지표를 담을 수 있다.
  • 엔진별 기본 지표: SQL Server 13개, Oracle 14개, PostgreSQL 19개, MariaDB·MySQL 각 23개로 엔진마다 다르다.
  • 로그 통합: RDS 인스턴스 수정에서 로그 내보내기를 설정해야 Database Insights에서 로그를 볼 수 있다. 지원 로그 유형은 엔진마다 다르다.
  • 느린 SQL: Aurora MySQL, MariaDB, MySQL, PostgreSQL에서 느린 SQL 쿼리 통합 조회가 가능하다.
  • OS 프로세스: RDS Enhanced Monitoring의 OS 프로세스 목록을 Database Insights에서 함께 조회할 수 있다.
  • 비용 계산 예시: t3.micro SQL Server에서 2주간 유료 티어 운영 시 2 vCPU × 336시간 × $0.0125 = $8.40.
  • Performance Insights 보존: 유료 티어 활성화 시 Performance Insights 보존 기간이 15개월로 연장되며 이에 대한 추가 비용은 없다.
왜 읽나RDS/Aurora 성능 모니터링을 Database Insights로 통합하려는 DBA나 인프라 엔지니어에게 신규 사용자 정의 기능의 사용 방법과 엔진별 지원 범위, 비용을 한눈에 파악할 수 있게 해준다.
클라우드메이트
클라우드메이트 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

    여기어때 데이터 분석팀(UB팀)이 개발 경험 없이 AI 에이전트 바이브 코딩으로 마케팅 자동화 시스템 '오디언스 빌더'를 구축한 과정이다. SQL 없이 UI에서 타겟 조건을 설정하면 BigQuery에서 수천만 행 대상자를 추출해 Kafka·S3를 통해 마케팅 도구로 전달하는 파이프라인을 직접 만들어, 캠페인 준비 시간을 2~3일에서 10분으로 단축했다.

    요약 이어보기
    #data-pipeline#kafka#postgres+2
  2. DB / 데이터·vercel-blogVercel Blog·

    모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

    Vercel이 빌드 웜 풀(warm pool) 상태 데이터를 Redis에서 DynamoDB로 마이그레이션한 과정을 다룬다. 빌드 풀의 청구 매핑 데이터가 Redis 장애 시 복구 불가능하다는 구조적 위험이 이주를 결정한 핵심 이유였고, 24/7 프로덕션 트래픽 속에서 다운타임 없이 5단계 점진적 전환을 완료했다.

    요약 이어보기
    #database-migration#zero-downtime#redis+2
  3. DB / 데이터·channel-talk채널톡·

    DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기

    채널톡이 DynamoDB 핫 파티션을 해결하려 GSI를 별도 인덱스 테이블로 떼어낸 연재의 마지막 편으로, 조회 경로를 GSI에서 인덱스 테이블로 옮긴 과정을 다룬다. 2편에서 쓰기 파이프라인이 완성돼 WriteThrottleEvents가 월 110만 회에서 0회가 됐지만, 조회 코드가 여전히 GSI를 읽고 있어 GSI를 지울 수 없었다. GSI가 읽기에서 대신해주던 키 해석·정확 일치·삭제 필터·페이지 채우기를 사내 공통 라이브러리의 조회 규칙으로 흡수해, 호출부는 GSI든 인덱스 테이블이든 같은 코드를 쓰게 만들었다.

    요약 이어보기
    #migration#dynamodb#hot-partition+5