Datadog을 활용한 SLI/SLO 모니터링 및 Burn Rate 알람 적용기

1. 왜 SLI와 SLO가 필요한가?

Yapp 26기 활동이 끝나고 Eatda라는 맛집 리뷰 플랫폼 서비스를 출시했습니다.
신규 기능 개발에만 집중하던 시기와 달리 이제는 로그를 확인하거나 모니터링을 보는 일이 훨씬 줄어들었습니다.
 
현재 개발팀은 신규 기능 개발보다는 미뤄왔던 리팩터링 작업등 개선에 집중하고 있습니다.
이와는 별개로 PD팀에서는 현재 서비스의 마케팅 집행을 준비하고 있는 상태입니다.
 
마케팅을 집행하고 실제 신규 유저들이 들어올 때 서비스 품질이 낮다면 사용자 리텐션을 보장할 수 없습니다.
따라서 장애가 발생하기 전에 방지하고, 개발팀이 상시 서비스를 모니터링하지 않아도 일정 임계점을 넘으면 즉시 대응할 수 있는 알람 체계가 필요했습니다.
 
하지만 단순히 에러가 몇 번 발생하면 개발팀을 호출하거나, 100번 중 1번 정도 응답이 느린 것으로 호출하는 것은 비효율적입니다.
SLI, SLO를 명확히 정의하고 해당 기준을 넘으면 개발팀을 호출하는 기준을 세워 효율적으로 운영하고 싶었습니다.
그리고 사용자들에게 MVP 단계임에도 신뢰를 줄 수 있는 서비스를 만들고자 했습니다.
 
SLI, SLO를 이전부터 알고 있었지만, 명시적으로 설정해본 적이 없어 어려움을 겪었는데,
Google SRE Book 을 많이 참고하면서 기준을 세워나갔습니다.

---

2. 무엇을 측정할 것인가? (SLI)

SLI를 정의하기 위해 먼저 사용자 경험에 가장 큰 영향을 미치는 지표가 무엇인지 고민해보았습니다.

• 가용성/에러율: 사용자가 우리 서비스를 '사용할 수 있느냐 없느냐'를 결정하는 가장 기본적인 지표입니다.
• 응답 레이턴시: 사용자가 서비스를 '쾌적하게 느끼느냐 느리다고 느끼느냐'를 결정하는 핵심적인 경험 지표입니다. 게시글 목록을 불러오는데 5초가 걸린다면, 아무리 좋은 콘텐츠라도 사용자는 기다리지 않을 것이라고 생각했습니다.

이외에도 처리량(Throughput), 포화도(Saturation) 등 다양한 지표를 고려할 수 있습니다. 하지만 현재 MVP 단계에서는 위 두 가지 SLI가 가장 중요하다고 판단했습니다. 사용자 경험에 직접적으로 영향을 미치고, 측정하기도 명확하기 때문입니다.
 
핵심 지표 정의

• 가용성(Availability): 전체 요청 중 성공한 요청의 비율
• 응답 시간(Latency): 특정 시간 내에 처리된 요청의 비율 (P95 기준)

측정 범위 모든 API를 대상으로 하되, 특히 사용자가 가장 많이 사용하는 핵심 기능들을 우선순위로 두었습니다.

• 응원 조회 API
• 스토리 조회 API
• 사용자 인증 API

이렇게 기준을 세우고 나니, 다음 단계인 SLO 목표 설정에 대한 방향성이 보이기 시작했습니다.

---

3. 우리의 목표는 무엇인가? (SLO)

SLO 설정에서 가장 어려운 부분은 얼마나 높은 목표를 세울 것인가? 였습니다.
 
대부분의 서비스는 가용성 SLO를 99.9% 이상으로 목표로 한다고 알고 있습니다.
그러나 저희 서비스에서는 99.9%는 너무 높고, 그보다 아래인 99%라는 수치도 매우 높고 까다로운 기준처럼 느껴졌습니다.
하지만 월 단위 허용 장애 시간으로 환산해보니 생각이 달라졌습니다.

 
99% 가용성은 월 7시간 20분의 장애를 허용한다는 의미이며 MVP 단계에서 충분히 현실적인 목표라고 생각했습니다.
 
현재 성능 기준선 확인
목표 설정 전에 현재 서비스의 성능을 측정해보았습니다.

• 가용성: 99.91%
• 응답시간: P95 기준 500ms 이하 비율이 99.791%

현재 성능으로는 99.5%도 가능하지만, MVP 특성상 새로운 기능 추가와 사용자 증가로 언제든 성능이 저하될 수 있기 때문에 99%를 목표로 설정하는 것이 현실적이라고 판단했습니다.
 
최종 SLO

• 가용성: 99%
• 응답시간: P95 기준 500ms 이하 응답 비율 99%

---

4. 언제 알려줄 것인가?

SLO를 정의했다면 이제 언제 개발팀에게 알림을 보낼지 결정해야 했습니다.
Datadog 알람 설정에는 크게 두 가지 접근 방식이 있습니다.

• • Error Budget Alerts
    • SLO의 전체 에러 예산 중에서 얼마나 소비되었는지(%)를 기준으로 경고를 보내는 방식입니다. 예를 들어 "이번 달 에러 예산의 80%를 소모했습니다"와 같은 알림입니다.
  • Burn Rate Alerts
    • 에러 예산을 소비하는 속도를 기준으로 알림을 보내는 방식입니다. 지금의 추세(시간당, 분당 등)로 가면 SLO를 지킬 수 없는 속도로 예산을 태우고 있는지를 감지합니다.

Error Budget Alerts는 월말로 갈수록 별로 중요하지 않은 상황에서도 지속적으로 알람이 울리기 쉽기 때문에, 정말 개발팀 개입이 필요할 때만 알람을 확인하고 조치를 취하게 하기 위해서 Burn Rate Alerts를 선택했습니다.
 
여기서 가장 어려웠던 부분은 에러를 소비하는 속도의 기준을 설정하는 부분이었는데요.
이 또한  Google SRE Book Alerting on SLOs   을 참고하여 1시간당 소모율이 14.4배 이상으로 설정하였습니다.
이는 현재 속도로 에러가 발생하면 1시간 만에 전체 에러 예산의 2%를 소모한다는 의미이기에 심각한 상황에서만 알람이 발생하면서도 대응할 시간은 충분히 확보할 수 있는 균형점입니다.
 
설정된 SLO를 기반으로 다음과 같은 알람을 구성했으며, 문제 발생 시 Discord 채널로 알림이 전송됩니다.

• 에러 버짓 소진 알람: 에러 버짓 소진 속도가 1시간 기준 목표치의 14.4배를 초과할 경우 경고 발생
• 인프라 자원 사용량 알람:
  • CPU: 5분 평균 사용량 70% 초과 시 '주의', 90% 초과 시 '경고'
  • Memory: 5분 평균 사용량 70% 초과 시 '주의', 90% 초과 시 '경고'

---

5. 결과 및 개선점

결과

해당 작업들을 Github Issues 에 등록해두었기에 완료 처리를 하고 작업 내용을 팀원들에게 공유했습니다.
SLI/SLO 설정 작업을 완료하고 팀원들과 공유한 지 며칠 후, 새벽에 레이턴시 경고 알림을 받게 되었습니다.

 
원인을 분석해보니 외부에서 ms 단위로 연속된 API 호출을 통해 취약점 스캐닝과 크롤링이 이루어지고 있었습니다. 이로 인해 불필요한 패치 조인이 반복 실행되면서 전체 응답 시간이 지속적으로 저하되고 있었습니다.
더 심각한 문제는 .env, api/.git/config 등 민감한 설정 파일에 대한 무차별 대입 공격도 함께 진행되고 있다는 점이었습니다.

 
이전 프로젝트에서도 유사한 공격을 경험한 바 있어, ALB의 직접 IP 접근을 차단하고 도메인을 통한 접근만 허용하는 핫픽스를 적용했습니다. 이를 통해 일시적으로 공격을 차단할 수 있었지만, 도메인이 노출될 경우 재공격 가능성이 높다는 근본적인 문제는 여전히 남아있었습니다.

 
따라서 팀 논의를 통해 ALB 앞단에 AWS WAF를 배치하여 다층 보안을 구축하기로 결정했습니다.
현재 MVP 단계에 맞게 아래와 같은 보안 규칙을 적용했습니다.
 

• Rate Limit Rule: 단일 IP당 요청 수 제한으로 DDoS 공격 방어
• Common Rule Set: 일반적인 웹 공격 패턴 차단
• Known Bad Inputs Rule Set: 최신 취약점 공격 시그니처 탐지
• Amazon IP Reputation List: 악성 IP 블랙리스트 적용
• Bot Control Rule Set: 자동화된 봇 트래픽 식별 및 차단
• Anonymous IP List: VPN, 프록시, 호스팅 서비스 IP 제한
• SQLi Rule Set: SQL 인젝션 공격 전문 방어

 
WAF 적용 후 1시간 만에 56건의 악성 요청을 성공적으로 차단했으며,
로그 분석 결과 아르헨티나, 네덜란드, 리투아니아 등 전 세계 다양한 지역에서 오는 공격임을 확인할 수 있었습니다.
 

 

 
 
기존 보안 조치만으로도 대부분의 악성 요청을 차단할 수 있었겠지만, 이번 사건을 통해 외부 공격이 우리가 설정한 SLO에 직접적인 위협이 될 수 있음을 확인했습니다.
 
ms 단위로 반복되는 스캐닝 공격은 응답 지연을 유발했고, 이는 곧 P95 500ms 응답시간 목표 달성을 어렵게 만드는 요인이었습니다. 보안 사고 한 번으로 전체 시스템이 위험해질 수 있을 뿐만 아니라, 99% 가용성 목표마저 위협받을 수 있는 상황이었습니다.
 
WAF 도입으로 사용자 데이터 보호와 일관된 서비스 품질을 제공한다는 두 가지 목표를 모두 달성할 수 있었습니다. 
 
이번 작업을 통해 서비스 신뢰성을 수치로 정의하고, 그 기준을 운영에 녹여내는 경험을 할 수 있었습니다. 
특히 예상치 못한 외부 공격이 곧바로 SLO 위반으로 이어질 수 있다는 사실을 확인하면서
보안과 신뢰성은 별개가 아니라는 점을 다시 한 번 실감했습니다.

---

개선점

이번 작업을 하며 새롭게 발견한 것이 있는데요.
Datadog이 GUI 기반의 툴이기 때문에 APM 대시보드와 여러 설정들을 수동으로 만들어서 적용해야 했습니다.
 
이런 방식의 문제점은 휴먼 에러나 계정 문제로 설정이 날아갈 위험이 있다는 점입니다.
그래서 IaC로 관리할 방법을 찾아보니 Terraform에서 Datadog 프로바이더를 지원하고 있었습니다.
 
따라서 다음 작업 목표로 Datadog 대시보드와 설정을 모두 임포트해서 Terraform으로 관리하려고 합니다.