SLO 대시보드로 효과적인 옵저버빌리티 시작하기

옵저버빌리티를 구축할 때 어떤 툴을 사용해야 할지 비교하는 것도 중요하지만, 팀이 모니터링 대시보드를 통해 알아야 할 것을 정의하는 것 역시 무척 중요합니다.

그래서 지난 글에서 SLI(Service Level Indicator)와 SLO(Service Level Object), Error Budget에 대해 소개해드렸는데요. 옵저버빌리티의 나침반 역할을 하는 이 지표들은 아래와 같이 정리할 수 있습니다.

• SLI: 지금 우리 서비스가 사용자 관점에서 제공하고 있는 품질의 수준
• SLO: 우리 팀이 설정한 SLI의 목표치 (지속적인 업데이트 필요)
• Error Budget: SLO을 충족하지 않아도 괜찮은 여유 공간
  • 예: 가용성 SLO가 97%라면, 해당 Error Budget은 100 - 97 = 3%

그리고 이런 지표를 실제 모니터링 도구로 구현한 시각화 대시보드를 SLO 대시보드라고 하는데요.

이번 글에서는 SLO 대시보드를 구현할 때 유용히 사용할 수 있는 메트릭 선택 방법과, Error Budget 기반으로 개발 전략을 수립하는 가이드, SLO 대시보드 도입 효과를 살펴보겠습니다.

---

SLO 대시보드 구현은 어디서부터 시작해야 할까?

옵저버빌리티의 대상이 되는 데이터로는 메트릭, 로그, 트레이스 등이 있습니다. 그 중에서도 SLO 대시보드를 구현할 때 필요한 데이터는 메트릭 데이터입니다.

그렇다면 어떤 메트릭으로 시작하면 좋을까요? 메트릭 데이터는 정말 다양하지만, 다행히 우리에게 필요한 메트릭을 고르는 방법론이 존재합니다. 물론 SLO 대시보드에도 적용가능한 걸로요.

이번 글에선 총 2가지 방법론을 소개해드릴 건데요. 바로 서비스 관점에서 측정하는 RED와 리소스 관점에서 측정하는 USE 방법론입니다. 각 방법론을 정리하면 아래와 같습니다.

RED 방법론

• Rate: 서비스에 얼마나 많은 트래픽이 들어오는가?

  • 예: 초당 처리되는 요청 수(Throughput)

• Errors: 서비스에 대한 얼마나 많은 요청이 실패하는가?

  • 예: HTTP 5XX 반응 수로 측정

• Duration: 서비스에 대한 요청이 얼마나 오래 걸리는가?

  • 요청에 대한 지연시간

• 서비스의 가용성에 대한 SLI인 경우

  • RED의 Errors 지표와 Rate 지표 활용
  • 예: 지난 28일 동안 A 서비스의 {요청 오류 수 / 총 요청 수} 백분율

• 서비스의 지연시간에 대한 SLI인 경우

  • RED의 Duration 지표 활용
  • 예: 지난 28일 동안 A 서비스의 {100ms 미만 요청 수 / 총 요청 수} 백분율

USE 방법론

• Utilization: 리소스가 얼마나 사용되고 있는가?

  • 예: CPU, 디스크 I/O 사용률

• Saturation: 처리되어야 할 작업이 얼마나 쌓이고 있는가?

  • 예: 큐 길이

• Errors: 리소스에서 얼마나 오류가 발생하고 있는가?

  • 예: 네트워크 패킷

• 리소스 부하에 대한 SLI인 경우

  • USE의 Saturation 지표와 Utilization 지표 활용
    • S와 U가 모두 높다면 → 요청이 몰려 리소스가 과부하 상태
    • S만 높다면 → 비효율적인 프로세스로 인한 병목현상 또는 버그가 발생한 상황

• 리소스 오류에 대한 SLI인 경우

  • USE의 Errors 지표 활용

그리고 메트릭 데이터로 구현하는 SLO 대시보드에 대해 좀 더 쉽게 이해할 수 있도록, OpenTelemetry와 Grafana를 이용해서 제가 직접 구축해본 SLO 대시보드를 함께 살펴보겠습니다.

위 SLO 대시보드는 Cart라는 이름의 서비스에 대해 4주 동안의 가용성과 지연시간 SLI/Error Budget을 메트릭 데이터로 시각화한 것인데요.

SLI와 SLO뿐만 아니라, 총 Error Budget 중 소진되고 남은 Error Budget과 특정 기간 동안(위 대시보드에서는 지난 3시간으로 설정되어 있습니다.) SLI의 변화를 시계열로 나타낸 SLI 추세도 함께 구현했습니다. 참고로, 여기에 Error Budget 소진량의 추세도 함께 시각화하는 경우도 있습니다.

지금까지 살펴본 것처럼 RED/USE 지표는 SLO 대시보드를 구현하는 데에 좋은 시작점이 됩니다.

---

Error Budget 기반으로 행동하기

SLO 대시보드를 구현했다면 이제 서비스에 대한 Error Budget을 파악할 수 있을 텐데요. 이 Error Budget은 앞으로의 개발 계획을 수립하거나 어떤 행동을 취해야 할지 결정하는 데에 좋은 기준이 됩니다.

Error Budget의 상태에 따라 총 3개의 시나리오로 나눠서 각 경우에 어떻게 대응할 수 있을지 정리해봤습니다.

시나리오 1: Error Budget이 여유로울 때

Error Budget이 여유롭다는 것은 우리가 정의한 사용자 관점의 품질이 준수하다는 뜻입니다.

• 신규 기능 개발
• 신규 버전 배포

이럴 땐 위와 같이 좀 더 도전적인 개발 계획을 세울 수 있겠죠.

시나리오 2: Error Budget이 꾸준히 소진될 때

하지만 만약 Error Budget이 완만하지만 꾸준히 소진될 땐 이야기가 달라집니다. Error Budget이 소모되고 있다는 것은 사용자 관점에서의 품질이 떨어지고 있다는 뜻이므로, Error Budget이 더 소진되기 전에 조치가 필요합니다.

• 신규 기능 개발 및 신규 버전 배포 중단
• SLO 관련 안정화 작업(버그 수정, 성능 최적화) 수행

위와 같이 신규 개발이나 배포는 줄이고 기존 서비스에 영향을 주는 버그와 성능 이슈를 찾아서 해결해야 하는데요. 이런 경우를 실제로 크리티컬한 문제가 발생하기 전에 미리 조치를 취한다고 해서 선제적 조치라고 합니다.

시나리오 3: Error Budget이 급격히 소진될 때

마지막으로 Error Budget이 급격히 소진된다는 것은 우리가 미처 찾아내지 못한 크리티컬한 이슈가 발생해서 사용자 관점의 서비스 품질이 빠르게 악화되고 있다는 뜻입니다. 역시 빠른 조치가 필요하겠죠.

• 신규 기능 개발 및 신규 버전 배포 중단 (필요하다면 이전 버전으로 롤백)
• Error Budget이 소진된 Root Cause 분석 및 문제 해결
  1. 트레이스 데이터를 통해 요청 경로 중 어디서 문제가 발생하는지 확인 (ex: cart-service에서 응답까지 3초가 소요됨)
  2. 문제가 발생한 서비스의 로그 데이터를 통해 원인 파악 및 문제 해결

위와 같이 신규 개발이나 배포를 멈추고, Error Budget을 소진시키는 Error Budget을 분석해야 합니다. 각 서비스별로 SLO 대시보드를 구현했다면 문제가 발생한 서비스를 바로 파악할 수 있겠지만, 필요하다면 트레이스 데이터를 통해 요청 경로 중 문제가 발생한 지점을 파악한 다음 해당 지점에서 발생되는 로그 데이터로 문제의 원인을 파악하고 해결해야 할 것입니다.

이렇게 Error Budget은 우리 서비스에 문제가 발생했거나 혹은 문제 발생 여지가 있을 때 직관적으로 알려주기 때문에, 우리가 어떤 행동을 취해야 할지 더 객관적으로 파악할 수 있는 기준점이 되어줍니다.

---

SLO 대시보드 도입으로 우리가 얻을 수 있는 이점

SLO 대시보드를 도입하게 되면 우리 팀과 구성원들에 어떤 변화가 있을까요? Before/After 형식의 표로 정리해봤습니다.

<팀 관점>

Before	After
문제가 발생하면 그때그때 급한 불부터	Error Budget 동향을 통해 선제적으로 개선 및 조치
신규 버전을 배포해도 될지 막연함	Error Budget 상황에 따라 신규 버전 배포 또는 안정화 작업 수행
배포에 대한 두려움	신규 버전 배포에 대한 자신감
추측 기반 시스템 운영	데이터 기반 시스템 운영

<엔지니어 관점>

Before	After
수동적 디버깅	능동적 문제 해결
기능 중심 사고	사용자 관점 사고
애매한 추측	데이터 기반 진단
배포에 대한 두려움	배포 영향에 대한 자신감

실제 SLO 대시보드 도입과 관련된 사례도 있어 정리했습니다.

2024년 Lenovo는 SLO 대시보드 도입으로 트래픽이 300% 이상 급증하는 상황에서 MTTR(평균 복구 시간)이 30분에서 5분으로 줄었다고 합니다. SLO 기반으로 문제를 정의하고 대시보드로 추적함으로써 서비스에 발생한 에러나 지연시간의 급격한 증가가 한눈에 파악이 되기 때문에 MTTR이 감소한 것으로 보이는데요. MTTR의 감소는 사용자의 신뢰와 직결되므로 유의미한 사례입니다.

그리고 2023년 nobl9의 조사에 따르면, 설문에 응한 조직의 27%가 SLO 도입으로 50만 달러 이상의 운영비용을 절약할 수 있었다고 합니다. SLO와 Error Budget을 활용한 직관적인 옵저버빌리티를 통해 문제를 빠르게 파악하고 선제적으로 해결할 수 있음을 보여주는 사례죠.

Splunk의 Error Budget 기반 선제 알림 기능을 사용한 조직의 76%가 SLO를 시스템 안정성에 필수요소로 인지했다는 조사도 있습니다. Error Budget 기반으로 알림을 설정하고 추적하면, 사용자 경험에 직결되는 문제를 미리 파악하고 해결 가능하기 때문에 SLO의 중요성이 드러난 사례입니다.

SLO는 시스템의 안정화 여부를 조직 내에서 쉽게 공유하고 결정할 수 있도록 도와주는 공통된 언어 역할도 수행하는데요. 각 영역별로 SLO와 Error Budget의 활용 예시를 정리하면 아래와 같습니다.

• 프로덕트 관리 관점: SLO 정의 후 파생되는 Error Budget은 리스크 관리 툴로서 활용 가능
• 엔지니어 리드 관점: Error Budget을 통해 ‘이번 스프린트에서 새로운 기능을 개발할지’, 아니면 ‘안정화 작업 또는 기술 부채 해소 작업을 수행할지’ 결정 가능
• 비즈니스 관점: ‘우리 서비스가 사용자 경험과 직결되는 내부 목표(SLO)를 지키고 있는가’ 판단 가능

조직의 규모가 커질수록 팀 간의 커뮤니케이션은 복잡해집니다. 이때 지속가능한 옵저버빌리티 도입으로 측정되는 SLO는 팀 사이에 더욱 효율적으로 소통하는 것을 도와줍니다.

---

마무리

지금까지 살펴본 SLO 정의와 메트릭 선택법, Error Budget 기반 행동은 제가 지속가능한 옵저버빌리티를 위한 프레임워크로 정리하고있는 내용인데요.

해당 프레임워크의 핵심만 다시 요약하면 아래와 같습니다.

1. 우리 시스템에 필요한 질문을 SLO로 정의
2. SLO 측정은 RED와 USE 메트릭을 먼저 활용
3. Error Budget에 따라 행동
4. 문제 해결 후 더 나은 질문 정의(지속적인 SLO 업데이트)

이번 글을 읽고 SLO 대시보드 도입에 관심이 생기셨나요?

그렇다면 사용자 입장에서 가장 크리티컬할 SLO 하나를 정의하고(가용성 혹은 지연시간 SLO), RED/USE 메트릭으로 측정해보세요.

만약 옵저버빌리티를 처음 도입하신다면 작은 서비스나 컴포넌트부터 시작하는 것을 추천드립니다. 처음부터 바다를 끓이려고 하기보다는 지금 당장 필요한 물 한 컵을 먼저 끓이는 것이 중요하거든요. 그 다음 점진적으로 확장해나가면 됩니다.

혹시 요청이 있거나 기회가 된다면, OpenTelemetry의 데모 프로젝트와 Grafana로 SLO 대시보드를 만드는 튜토리얼 가이드도 공유해보도록 하겠습니다.

그 외에도 옵저버빌리티나 모니터링에 대해 궁금한 주제가 있다면 아래 피드백 폼을 통해 알려주세요.

여러분들의 제안과 피드백 덕분에 Aiden’s Lab의 콘텐츠가 더욱 풍성해지고 있답니다.

그럼 저는 다음에 더 흥미롭고 유익한 주제로 돌아오겠습니다. 감사합니다😸

---

참고 자료

• https://techvzero.com/top-5-tools-for-real-time-slo-calculations
• https://www.nobl9.com/hubfs/PDF/Nobl9%202023%20State-Of-SLOs%20Report.pdf
• https://www.inspirisys.com/blog-details/The-Three-Types-of-Observability-A-Comprehensive-Overview/172

---

✨이번 아티클은 어떠셨나요?

이번 글의 주제에 대해 어떻게 생각하는지 알려주세요! 더 나은 아티클을 전달해드리기 위해 아래 폼에서 짧은 피드백을 받고 있어요.

👉 피드백 보내기 (1~2분 소요)

여러분들의 소중한 의견은 Aiden’s Lab에 큰 힘이 됩니다!