[SRE] Ch04. 서비스 수준 목표

이번 장에서는 사용자에게 필요한 서비스의 적정 수준을 정의하고 제공하는 방법에 대해서 이야기하고자 합니다.

 

1. 서비스 수준 관련 용어

1.1 척도

SLI는 서비스 수준 척도(Service Level Indicator)를 의미하며, 서비스 수준을 판단할 수 있는 몇 가지를 정량적으로 측정한 값입니다. 대부분의 서비스들은 핵심 SLI로서 요청에 대한 응답 속도를 말합니다. 그 외에도 시스템이 수신한 전체 요청 수 대비 에러율, 그리고 초당 처리할 수 있는 요청 수를 의미하는 시스템 처리량 등이 있습니다.

 

알고자 하는 서비스 수준의 SLI를 직접 측정하는 것이 이상적이기는 하지만 경우에 따라서는 필요한 값을 얻어내거나 해석하기가 어려워 그에 준하는 대체 값을 사용하는 경우도 있습니다. (클라이언트 측의 응답 속도가 아닌 서버의 응답 속도만을 측정)

 

SRE가 중요하게 생각하는 SLI 중 하나는 가용성, 즉 서비스가 사용 가능한 상태로 존재하는 시간의 비율입니다. 이 값은 주로 올바른 형태의 요청이 성공적으로 처리된 비율을 의미하며 수율(yield, 생상된 전체 제품 중 불량이 없는 제품의 비율)이라고도 합니다.

 

1.2 목표

SLO는 서비스 수준 목표(Service Level Objectives)를 의미하며, SLI에 의해 측정된 서비스 수준의 목표 값 혹은 일정 범위의 값을 의미합니다. 따라서 SLO는 SLI <= 목표치 또는 최솟값 <= SLI <= 최댓값으로 표현할 수 있습니다.

 

SLO를 설정하고 고객에게 이를 공개하는 것은 서비스의 동작에 대한 예측을 가능하게 합니다. 이런 전략을 통해 서비스 소유자들의 서비스가 느려지고 있다는 등의 근거 없는 불평을 줄일 수 있습니다. 명확한 SLO가 설정되어 있지 않다면 서비스를 디자인하고 운영하는 사람들의 생각과는 전혀 다른 자신들이 희망하는 성능을 기대하곤 합니다. 그리고 이렇게 생겨난 다양한 기대치 때문에 사용자가 실제 서비스가 제공할 수 있는 것 이상의 가용성을 기대해서 지나치게 서비스에 의존하는 현상과 잠재 고객들이 서비스를 실제보다 저평가하는 현상 모두를 유발하게 됩니다.

 

최근에 웹에서 조건을 설정하면 이를 바탕으로 쿼리를 수행한 후 결과를 보여주는 플랫폼을 구현하였습니다. 쿼리를 수행하는 데 적어도 3분이 소요되었기 때문에 입력한 조건의 결과를 즉각적으로 볼 수 없다는 점을 웹에 공지하였습니다. 이를 통해 사용자의 기대치를 낮췄고 결론적으로  속도가 느리다 혹은 결과가 나오지 않는다라는 피드백은 오지 않았습니다.

 

참고로 100 밀리초는 빠른 응답 속도로 설정하기에 적절한 값이라고 합니다. 그리고 목표 설정에 가장 중요한 것은 어떤 값을 측정할 수 있는지가 아니라 사용자가 중요하게 생각하는 것이 무엇인지에 대해 생각해 보는 것입니다.

 

목표 예시

• Get RPC 호출의 90%는 1밀리 초 이내에 수행되어야 한다.
• Get RPC 호출의 99%는 10밀리 초 이내에 수행되어야 한다.
• Get RPC 호출의 99.9%는 100밀리 초 이내에 수행되어야 한다.

 

1.3 협약

SLA는 서비스 수준 협약(Service Level Agreements)의 약자로, SLO를 만족했을 경우 혹은 그렇지 못한 경우의 댓가에 대한 사용자와의 명시적 혹은 암묵적인 계약을 의미합니다. 댓가란 대부분 경제적인 것으로 대변되지만, 다른 형태로 나타나기도 합니다.

 

SLO와 SLA의 차이점을 쉽게 파악하려면 'SLO를 달성하지 못하면 어떻게 될 것인가?'를 생각해 보면 됩니다. 이 질문에 대한 명확한 결론이 없는 경우라면 대부분 SLO라고 생각해도 무방합니다.

 

2. 지표 설정

지금까지 서비스를 측정하기 위해 적절한 지표를 선택하는 것이 왜 중요한지에 대해 알아보았습니다. 그렇다면 서비스나 시스템에 있어 중요한 지표가 무엇인지를 어떻게 판단할 수 있을까요?

 

사용자가 직접 대면하는 시스템들은 주로 가용성, 응답 시간, 그리고 처리량이 중요합니다. 다시 말하면, 요청에 올바르게 응답할 수 있는지, 응답 시간은 얼마나 오래 걸리는지, 얼마나 많은 요청을 처리할 수 있는지가 중요하다는 뜻입니다.

 

저장소 시스템은 주로 응답 시간, 가용성, 그리고 내구성을 중요시합니다. 다시 말하면, 데이터를 읽고 쓰는 데 어느 정도의 시간이 걸리는지, 필요할 때 데이터에 액세스 할 수 있는지, 데이터는 안전하게 저장되어 있는지 등이 중요합니다.

 

데이터 처리 파이프라인 같은 빅데이터 시스템은 처리량과 종단 간 응답 시간이 중요합니다. 즉, 얼마나 많은 데이터를 처리할 수 있는지, 데이터가 유입된 이후로 작업을 완료하기까지의 시간은 얼마나 걸리는지 등이 중요합니다.

 

2.1 척도 수집하기

많은 척도들은 기본적으로 보그몬이나 프로메테우스 또는 전체 요청 대비 HTTP 500 오류가 발생한 비율 등을 파악하기 위해 일정 기간에 대해 실행하는 로그 분석 등의 방법을 통해 주로 서버 측에서 수집됩니다.

 

일부 시스템들은 클라이언트 측의 수집이 이루어져야 하기도 합니다. 왜냐하면 클라이언트 측에서 행위를 측정하지 않으면 서버 상의 지표에는 나타나지 않지만 사용자에게는 보여지는 문제들을 놓칠 수 있기 때문입니다.

 

2.2 합산하기

단순함과 유용함을 위해 측정된 원본 데이터를 합산하는 경우도 있습니다. 다만 이 경우 상당한 주의를 기울여야 합니다.

 

대부분의 지표들의 경우 평균보다 분포가 중요합니다. 예를 들어 SLI의 경우, 일부 요청은 빠르게 처리되었을 수 있지만 나머지는 균일하게 더 느리게 어쩌면 그보다 더 느리게 처리되었을 수도 있습니다. 단순히 평균만을 집계하면 이렇게 느리게 처리된 요청 뒤에 유입된 요청들의 처리 속도를 알 수 없습니다. 예를 들어 대부분의 요청들이 50밀리 초 안에 처리되었지만 5%의 요청들은 20배나 느리게 처리되었을 때 평균 응답 시간을 기준으로 모니터링과 알림을 설정하면 하루 동안 아무런 변화가 없는 것처럼 보일 수 있습니다.

 

사용자에 대한 연구에 의하면 사람들은 응답 시간의 변동이 큰 경우보다는 살짝 느리게 동작하는 시스템을 더 선호하므로 99.9번째 백분위 수의 값이 양호하다면 일반적인 사용자 경험 역시 훨씬 나아질 것이라는 점을 근거로 일부 SRE는 높은 백분위 수 값들에 더 주목하기도 합니다.

 

2.3 척도의 표준화

각각의 척도들의 최우선 원칙이 무엇인지를 매번 고민할 필요가 없도록 SLI들에 대한 일반적인 정의를 표준화하기를 권장합니다. 표준화된 정의 템플릿을 따르는 모든 수치들은 개별 SLI의 명세에서 생략해도 무방합니다. 아래는 템플릿 예시입니다.

 

 

3. 결론

사용자에게 필요한 서비스의 적정 수준을 정의하고 제공하기 위해서 서비스 수준과 관련된 용어 그리고 지표를 설정하는 방법에 대해서 알아보았습니다. 프로젝트 개발을 하면서 SLI, SLO, SLA 용어를 사용해서 목표를 설정한 경험이 없어서 이번 장의 대부분의 내용이 인상 깊었습니다. 특히 SLO를 설정하고 고객에게 이를 공개하는 것은 서비스의 동작에 대한 예측을 가능하게 한다는 점이 가장 기억에 남습니다. 앞으로는 지나친 목표가 아닌, 프로젝트에 적합한 목표를 세운 후 안전한 서비스를 제공하는 경험을 해보도록 하겠습니다.