[SRE] 실전에서 배우는 SLI: CloudWatch와 Grafana로 신뢰성 확보하기

ㅁ 들어가며

 SRE는 시스템의 신뢰성(Availability)을 수치로 측정하고 유지하기 위해 SLI(Service Level Indicator)를 정의하고 관리한다.
이 글에서는 제가 직접 경험한 CloudWatch 및 Grafana 기반의 모니터링 환경 구축과, 그를 통해 얻은 인사이트와 문제 해결 사례를 공유하고자 한다. 현실적인 운영 상황과 개선 과정을 중심으로,  SRE의 시선에서 SLI를 어떻게 "정의하고, 모니터링하고, 개선"했는지를 설명하고자 한다. 

 

ㅁ SLI는 무엇이 기준이 되어야 하는가?

SRE로 일하면서 가장 먼저 고민한 것은 "우리는 무엇을 측정해야 하는가?"였다.

처음에는 AWS CloudWatch에 내장된 지표들로 시작했다.

• EC2 인스턴스의 CPU 사용률
• RDS의 쿼리 지연 시간 및 CPU Credit
• EBS IOPS 및 대기 시간
• 네트워크 트래픽

하지만 문제는 단순했다.
CloudWatch에서 Redis 사용량, Queue 지연, Elasticsearch의 Rejected Request, 애플리케이션 처리 상태 같은 핵심 SLI 지표를 제대로 추적할 수 없다는 점이었죠.

 

---

ㅁ CloudWatch로 모니터링 지표 기반 마련

• 📄 CloudWatch Dashboard 쉽게 생성하기
  여러 AWS 서비스들을 태그로 정리하고, 필요한 지표만 추려 효율적인 대시보드를 구성했다.
• 🛠 RDS 성능개선도우미 도입
  RDS의 쿼리 성능 저하 현상은 단순 CPU 문제로 보였지만, 인덱스 및 실행 계획의 문제였음을 도우미로 파악했다.
• 🔍 Elasticsearch rejected 예외 분석
  rejected execution exception을 통해, Data Node의 큐 적체와 EBS I/O 병목이 문제임을 확인했다.
• Elasticsearch 클러스터의 높은 메모리 사용률에 대한 원인 분석 방법 정리
  Elasticsearch 클러스터의 메모리 사용률 문제의 원인을 파악하고, 적절한 최적화 방안을 수립

이러한 경험을 통해 어떤 지표를 SLI로 삼아야 할지 방향이 잡히기 시작했다.

 

---

ㅁ CloudWatch로는 부족하다 — Redis + Grafana 도입

  Redis는 저희 시스템에서 비동기 큐의 핵심이었지만, CloudWatch에서는 Redis의 CPU, 메모리 외에 중요한 내부 지표를 볼 수 없었다.
AWS 인스턴스 요청은 예산 문제로 어려워, 회사에서 제공된 VDI 환경에 직접 Redis Exporter + Grafana를 설치했다.

🔗 관련 글 모음:

• Grafana 설치 및 Redis 모니터링 구성
• Redis scan의 지연 원인 분석
• Redis LREM 지연 정리
• Redis KEYS보다 SCAN 명령어를 써야하는 이유?
• Redis slowlog, bigkey 모니터링

 

슬로우로그와 bigkey, latency 지표를 수집하며 Scan 명령어의 부하와 LREM 명령의 처리 순서에 따른 지연을 정확히 파악하고 개선할 수 있었다.

 

 

ㅁ 지표 → 원인 파악 → 개선

모니터링을 통해 단순 수치만 보는 것이 아니라 패턴을 파악하고, 실제 서비스 지연의 원인을 찾아내며, 개선까지 이루는 것이 중요하다.

 

📍 사례:

• Redis의 scan 명령으로 인해 발생한 CPU 부하를 발견하고, scan 사용 주기(pageSize up)를 줄이고 KEYS와 분리 운영하도록 개선
  - Redis scan의 지연 원인 분석
  - [Redis] KEYS보다 SCAN 명령어를 써야하는 이유?
• Elasticsearch에서 index queue의 rejected 증가 → EBS gp3 마이그레이션 + Index 최적화
  - [AWS] Amazon EBS gp2 vs gp3 비교
  - [AWS] EBS gp2 생성, gp3 업그레이드, 포퍼먼스 테스트
• AWS Direct Connect 지표를 기반으로 네트워크 병목 파악 및 알람 세분화 설정
  - [AWS] AWS Direct Connect 리소스 모니터링

 

ㅁ 실전에서 느낀 인사이트

• CloudWatch의 기본 지표는 시작일 뿐이다
  핵심 서비스(예: Redis, MongoDB, ES)의 내부 상태는 별도 Exporter 기반 지표를 통해 확인해야 한다.
• SLI는 단순 수치가 아닌, 장애 징후의 조기경보 역할을 해야 한다.
  예: “Redis CPU 60% 이상 + 큐 대기 5초 초과 → 장애 전조 신호”
• 조직 예산이 부족해도, 작은 시도는 가능하다
  개인용 장비나 VDI 환경에서 Exporter와 Grafana를 직접 구성함으로써 정확한 모니터링 체계를 확보할 수 있었다.

 

ㅁ CloudWatch를 구성해서 지표를 생성하고 이를 통해 알게 된 문제점을 해결해 나가는 과정을 작성한 블로그

ㅇ [CloudWatch] 지표를 통해 CloudWatch Dashboard 쉽게 생성하기(https://peterica.tistory.com/170)

ㅇ [AWS] AWS RDS 성능개선도우미를 도입(https://peterica.tistory.com/217)

ㅇ [EBS] EKS 생성, MongoDB 구성, gp2에서 gp3 EBS 볼륨으로 마이그레이션(https://peterica.tistory.com/240)

ㅇ [Elasticsearch] Elasticsearch rejected exception 분석(https://peterica.tistory.com/232)

ㅇ [AWS] EC2: 태그를 기반으로 인스턴스 시작 또는 중지(https://peterica.tistory.com/166)

ㅇ [AWS] AWS Direct Connect 리소스 모니터링(https://peterica.tistory.com/214)

ㅇ [Elasticsearch] Data Node 볼륨 병목현상 확인 및 처리(https://peterica.tistory.com/294)

ㅇ [AWS] Amazon EBS 볼륨 증설 및 kubenetes PV, PVC 볼륨 수정 과정 정리(https://peterica.tistory.com/158)

 

ㅁ Redis + Grafana 모니터링환경 블로그 글

ㅇ [Grafana] 보안클라우드에  Grafana 설치 및 Redis 모니터링(https://peterica.tistory.com/137)

ㅇ [Redis] LREM의 큐처리방향에 따른 처리속도지연 정리(https://peterica.tistory.com/149)
ㅇ [Redis] Redis 간단하게 모니터링 하는 방법(bigkey, latency, slowlog)(https://peterica.tistory.com/150)

ㅇ [Redis] Redis scan의 지연발생 원인 분석(https://peterica.tistory.com/153)

ㅇ [Redis] KEYS보다 SCAN 명령어를 써야하는 이유?(https://peterica.tistory.com/154)

 

ㅁ 마무리

SRE가 정의하는 SLI는 곧 시스템의 건강지표이다.
CloudWatch와 Grafana를 적절히 활용한 모니터링 환경은, 서비스 신뢰성 유지의 핵심 수단이다.

🎯 "지표를 수집하지 않으면, 개선도 없다"
이것이 제가 현장에서 느낀 가장 큰 교훈이었다.