멋진 운영 경험을 위하여: Prometheus 레코딩 룰로 SLI 정하기 (SRE 밋업 4회)

주요 구간

• 02:00 SRE 팀의 일과 장애 때 겪는 혼란
• 06:00 메트릭과 SLI의 차이
• 08:00 팀 설문으로 Redis SLI 합의하기
• 09:30 시도 1: PromQL과 HTTP API
• 12:00 시도 2: 레코딩 룰과 스키마
• 20:00 얻은 교훈

장애 때 함께 볼 기준의 부재

당근 SRE 팀은 컨테이너와 배포, 클러스터와 트래픽, 클라우드 인프라를 분야별 전문가가 맡고 있습니다. 장애가 나면 각자 전문 분야의 관점에서 원인을 설명했지만, 개발자와 다른 분야의 전문가는 그 설명을 이해하기 어려웠다고 합니다. 복잡한 구성과 많은 운영 맥락, 사람마다 다른 노하우 탓에 운영 방향이 모이지 않았고 경험을 쌓아 갈 구심점도 없었다고 합니다.

발표자는 장애 때 모두가 같은 곳을 빠르게 보도록 SLI를 도입하고자 했습니다. 발표자는 조회할 수 있는 모든 지표를 메트릭, 그중 서비스 상태 판단에 쓰는 중요한 지표를 SLI로 구분했습니다. 무엇을 정상으로 볼지부터 의견이 달랐으므로 SLI를 고르는 일에는 팀의 합의가 필요했습니다.

Redis SLI 합의와 레코딩 룰 구현

당근은 Redis를 시험 대상으로 정하고 슬랙 설문으로 정상 상태의 기준과 중요하게 보는 지표를 모았습니다. 팀원마다 답이 달라, 설문 결과를 공유하고 논의한 뒤 SLI를 확정했습니다. 슬라이드에는 구동 여부, CPU와 메모리 사용률, 네트워크 송수신, 네트워크 대역폭 초과, 연결 수, 커맨드 유입량, 커맨드 레이턴시, 퇴거 아이템 수, 복제 지연이 올라 있습니다. 이 SLI를 제공하는 구현은 자원 API가 쿼리를 만드는 방식에서 Prometheus 레코딩 룰로 바뀌었습니다.

처음에는 개발자 포털 뒤의 자원 API가 자원 ID로 PromQL을 생성해 Prometheus에 질의했습니다. 결과를 모아 가용성 점수와 사용률 점수로 보여 주는 방식이라 PoC는 빠르게 만들 수 있었습니다. 조회하려면 API 스펙을 알아야 해 확장성이 낮았고 코드도 복잡해졌습니다. 모든 Redis 자원의 SLI를 조회하는 쿼리는 Prometheus에 부담을 줬으며, Grafana에서 값이 다르게 보이는 문제도 있었습니다.

레코딩 룰로 옮길 때는 회사, 담당 팀, 자원, 지표 분류 등의 스키마를 정하고 자주 쓸 레이블을 포함했습니다. label_replace로 원본 메트릭의 필드를 원하는 키로 바꾸고, max 같은 집계로 라벨 전용 info 메트릭을 만든 뒤 실제 지표와 조인해 SLI 메트릭을 구성했습니다. 발표자는 이 과정의 PromQL이 복잡해 계속 운영할 수 있을지 걱정했다고 합니다.

조회와 활용에서 달라진 점

• 포털이 SLI를 조회하려고 자원 API에서 만들던 쿼리 코드가 사라짐. Prometheus API 스펙만 알면 조회 가능
• Grafana에서도 같은 쿼리로 SLI 메트릭을 확인하고, 같은 SLI 지표로 알림 규칙 설정 가능
• 슬라이드의 레코딩 룰 수 그래프에는 4월과 8월의 새 SLI 추가가 반영됨. 발표자는 팀원들이 참여해 주어 지속 가능하다고 설명

적용할 때 확인할 점

레코딩 룰을 써도 시도 1에서 겪은 PromQL의 복잡함은 남습니다. 발표자는 SLI를 정해도 지표가 새로 생기지는 않으며, 기존 메트릭을 중요한 의사결정 지표로 삼는 데 의미가 있다고 설명했습니다. 원하는 지표가 Datadog에도 Prometheus 익스포터에도 없다면 직접 만들어 보기를 권했습니다.

같은 밋업의 당근에서 Loki 1년간 운영기는 Loki 운영을 다룹니다. 함께 읽으면 당근의 모니터링 구성을 이해하는 데 도움이 됩니다.