Observability 플랫폼의 SLO는 어떻게 만들어야 할까?

Observability 플랫폼을 운영하면 로그가 느리다거나 메트릭이 안 보인다는 이야기를 자주 듣는다.

플랫폼 서버가 모두 실행 중이어도 사용자는 실패를 경험할 수 있다. 로그 수집이 늦어서 방금 발생한 장애를 찾지 못할 수 있다. 쿼리가 성공해도 결과를 받는 데 너무 오래 걸리면 장애 대응에는 사용할 수 없다.

그래서 서버의 가동률이 아니라 사용자가 로그와 메트릭을 조회할 수 있는지를 서비스 수준 목표(SLO)로 만들기로 했다.

처음에는 수집기와 저장소 및 쿼리 컴포넌트의 상태를 봤다. 각 컴포넌트가 정상이고 에러가 적으면 플랫폼도 정상이라고 판단했다.

하지만 분산된 로그 파이프라인에서는 한 컴포넌트의 정상 상태만으로 전체 성공을 설명할 수 없다. 수집 요청을 받아도 뒤쪽 버퍼가 밀리면 로그가 늦게 보인다. 쿼리 요청이 성공해도 일부 데이터가 빠졌다면 사용자가 원하는 결과는 아니다.

메트릭도 같았다. 저장에는 성공했지만 조회 구간에서 타임아웃이 발생할 수 있었다. 평균 응답시간이 짧아도 무거운 쿼리를 실행한 사용자는 계속 실패할 수 있었다.

플랫폼 내부의 건강 상태와 사용자가 경험하는 성공을 따로 봐야 했다.

수집과 조회 지표

로그와 메트릭은 수집 경로(Write Path)와 조회 경로(Read Path)의 성격이 다르다. 하나의 가용성 점수로 합치면 어느 경로에서 문제가 발생했는지 알기 어렵다.

로그 플랫폼에는 다음 질문을 적용했다.

메트릭 플랫폼도 수집 성공과 조회 성공을 나눴다. 조회 경로에는 성공률과 응답시간을 함께 사용했다.

성공률만 보면 느린 요청을 놓친다. 응답시간만 보면 빠르게 실패한 요청이 정상처럼 보일 수 있다. 두 지표를 같이 봐야 사용자가 쿼리를 완료했는지 판단할 수 있었다.

Observability 플랫폼의 쿼리 부하는 고르게 분포하지 않는다. 짧은 시간 범위를 조회하는 가벼운 쿼리가 대부분이고 넓은 범위를 스캔하는 쿼리가 일부 섞인다.

평균 응답시간은 가벼운 쿼리의 수에 영향을 많이 받는다. 일부 사용자가 수십 초를 기다리고 있어도 평균은 정상 범위에 남을 수 있다.

그래서 로그 조회 응답시간은 요청의 99%가 그 시간 안에 끝나는 값인 P99를 중심으로 봤다. 20초가 넘던 구간을 한 자릿수 초까지 낮추자 사용자 문의도 줄었다. 평균값만 봤다면 이 지연을 놓칠 수 있었다.

P99 목표를 무조건 낮게 잡지는 않았다. 넓은 시간 범위를 조회하는 쿼리까지 같은 시간 안에 처리하려면 많은 용량이 필요하다. 자주 사용하는 조회 패턴에서 장애 대응에 필요한 속도를 제공할 수 있는지를 기준으로 정했다.

처음 만든 지표는 결과를 보여줬지만 무엇을 바꿔야 하는지는 알려주지 못했다. 특정 시간에 응답시간이 느려졌다는 사실만으로는 쿼리를 수정할지 용량을 늘릴지 결정하기 어려웠다.

무거운 쿼리의 호출처를 알 수 없었다. 어떤 서비스와 사용자가 같은 패턴을 반복하는지도 확인할 수 없었다.

내부 컴포넌트에 호출처 정보를 남기도록 바꿨다. 이후에는 느린 쿼리를 패턴별로 묶고 실제 사용자와 함께 조회 범위와 필터를 조정할 수 있었다. 용량을 먼저 늘려야 하는 문제와 쿼리를 바꿔야 하는 문제도 구분할 수 있었다.

SLO를 벗어난 이유를 확인하려면 실패하거나 느려진 요청을 다시 찾을 수 있어야 했다. 호출처 정보는 그 요청의 사용 목적을 확인하는 데 썼다.

측정 주기를 한 시간 단위로 줄이고 현재 SLI를 볼 수 있게 했다. 목표를 벗어나면 어떤 경로에서 성공률이나 응답시간이 나빠졌는지 바로 확인했다.

보고서에는 주간 가용성 숫자가 필요했다. 운영자는 사용자가 문제를 제보하기 전에 조회 실패를 발견할 기준이 필요했다. 같은 SLI를 두 목적에 맞는 주기로 나눠서 봤다.

Observability 플랫폼은 다른 시스템을 관찰하는 도구다. 그 플랫폼이 실패하면 장애를 분석할 수 있는 범위도 함께 줄어든다.

서버가 실행 중인지 확인하는 것만으로는 부족하다. 로그가 제시간에 들어오고 쿼리가 성공하며 필요한 시간 안에 결과가 나오는지를 봐야 한다. 메트릭도 같은 기준으로 수집과 조회를 나눠야 한다.

SLO를 검토할 때 마지막에는 이 질문을 확인한다.

이 지표가 나빠졌을 때 사용자가 무엇을 할 수 없게 되는지 설명할 수 있는가?

설명할 수 없다면 플랫폼 내부 지표일 가능성이 높다. 사용자 행동과 연결할 수 있을 때 SLO는 운영 우선순위를 정하는 기준이 된다.