SRE - 서비스 수준(SLI, SLO) 목표 설정 및 활용

Dec 28, 2018

요즘 서비스 수준의 목표 설정의 필요성을 많이 느끼고 있다. 여기서 말하는 서비스 수준의 목표는 기능적인 요구사항이 아닌 응답 속도, 가용성, 처리량 등 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정할수 있는 척도를 의미한다. 서비스 수준의 목표가 확실하게 도출되지 않으면, 서비스가 만족해야할 성능 수준 정의가 애매하게 되어버리고, 그 여파로 모니터링시에 어떠한 지표 위주로 모니터링을 해야할지 정확한 판단이 서지 않을것이다. 결국 어딘가에 문제가 생기면 올바른 지표를 참고하지 못해 해결하는데 어려움에 직면하게 될것이다.

서비스 수준의 목표를 명확히하면 서비스를 운영하는데 있어 중요한 지표를 정의할수 있게 되고, 이 지표들을 측정하고 평가하여, 기대했던 수준의 서비스를 제공하지 못했을 때의 대처 방안들을 강구하는데 도움을 줄 수있게 된다.

마침 SRE(Site Reliability Engineering) 스터디에서 서비스 수준 목표 설정과 관련된 내용을 공부하게 되어, 여기서는 이에 대한 내용을 포스팅할 것이다. SLA는 개발과 거리가 멀다고 생각하여 그 내용은 제외하였다.

SLI(Service Level Indicator) - 서비스 수준 척도

SLI는 서비스 수준 척도를 의미하며, 서비스 수준을 판단할 수 있는 기준 몇가지를 정량적으로 측정한 값이다. 모니터링 시스템을 통해 추적할 수 있는 모든 지표를 SLI로 취급할 필요는 없다. 너무 많은 지표를 선택한다면 정작 중요한 것에 집중하기가 어렵고, 너무 적은 수의 척도를 선택한다면 오히려 중요한 부분을 놓칠 수 있다.

적절한 SLI의 선정과 관련해 시스템들을 다음 몇 가지로 나누어 분류할수 있다.

  • 사용자가 직접 대면하는 시스템
    • 주로 가용성, 응답 시간, 처리량이 중요하다.
    • 요청에 올바르게 응답할 수 있는지, 응답 시간은 얼마나 오래 걸리는지, 얼마나 많은 요청을 처리할 수 있는지가 중요하다는 것이다.
  • 저장소 시스템
    • 주로 응답 시간, 가용성, 내구성을 중요하다.
    • 데이터를 읽고 쓰는 데 어느 정도의 시간이 걸리는지, 필요할 때 데이터에 액세스할 수 있는지, 데이터는 안전하게 저장되어 있는지가 중요하다.
  • 빅데이터 시스템
    • 주로 처리량, 종단간 응답 시간이 중요하다.
    • 얼마나 많은 데이터를 처리할 수 있는지, 데이터가 유입된 이후로 작업을 완료하기까지 얼마나 걸리는지가 중요하다.

척도는 보통 서버측에서 수집이되지만, 일부 시스템들은 클라이언트 측의 수집이 이루어져야 하기도 한다. 웹같은 경우 페이지의 자바스크립트 때문에 발생하는 지연응답은 서버측에서 판단하기 어렵기 때문이다.

그리고 대부분의 지표들의 경우 평균 보다는 분포가 중요하다. 예를들어 평균 응답시간을 기준으로 모니터링과 알람을 설정하면 겉보기에는 아무런 변화가 없는 것처럼 보일수 있겠지만, 분포를 보면 느리게 유입된 요청들의 응답시간을 알수있게 된다. 또한 분포와 더풀어 백분위 수를 사용하면 최악의 경우(99 백분위수) 또는 일반적인 경우(50 백분위수)에서의 상황을 알수 있게 된다. 50 백분위수의 값이 높아질수록 응답 시간의 변동이 크며, 이런 경우가 많아질수록 꼬리를 무는 요청들에 의해 더 악화될수 있음을 알수 있다.

SLO(Service Level Objectives) - 서비스 수준 목표

SLO는 서비스 수준 목표를 의미하며, SLI에 의해 측정된 서비스 수준의 목표 값 혹은 일정 범위의 값을 의미한다. 그래서 SLO는 SLI <= 목표치 또는 최솟값 <= SLI <= 최댓값으로 표현할 수 있다. 명확성을 극대화 하기 위해 SLO는 측정 방식과 유효한 기준이 반드시 명시되어야 한다.

예를 들어, 응답시간이 중요하다면 다음과 같이 SLO를 설정할 수 있다.

  • Get RPC 호출의 99%(1분 간의 평균)는 100밀리초 이내에 수행되어야 한다.(모든 백엔드 서버에서 측정된 평균 시간이여야 한다.)

SLO를 설정하고 고객에게 이를 공개하는 것은 서비스의 동작에 대한 예측을 가능하게 한다. 이런 전략을 통해 서비스 소유자들의 서비스가 느려지고 있다는 등의 근거 없는 불평을 줄일 수 있다. 또한 사용자가 실제 서비스가 제공할 수 있는 것의 가용성을 기대해서 지나치게 서비스에 의존하는 현상과 잠개 고객들이 서비스를 실제보다 저평가하는 현상을 방지할 수 있다.

다음은 적절한 SLO를 선택하는데 도움을 주는 몇가지 권고안이다.

  • 현재의 성능을 기준으로 목표치를 설정하지 말 것
    • 시스템의 장점과 한계를 이해한 후 목표치를 설정하라.
  • 최대한 단순하게 생각할 것
    • SLI를 복잡하게 집계하면 시스템의 성능 변화를 명확하게 반영하지 못하고 그 원인을 파악하기 어렵게 된다.
  • 현실성 있는 목표치를 설정할 것
  • 시스템의 특성을 잘 확인할 수 있는 가능한 적은 수의 SLO를 설정할 것
  • 처음부터 완벽하게 하려고 하지 말 것
    • 처음부터 지나치게 높은 목표를 설정해서 나중에 가서야 달성이 불가능한 것을 발견하고 목표를 완화시키는 것보다, 우선은 조금 느슨한 목표를 설정한 후 조금씩 강화하는게 낫다.

SLI, SLO를 활용한 모니터링 & 대응 루프

  1. 시스템의 SLI들을 모니터하고 측정하기
  2. SLI를 SLO와 비교해서 별도의 대응이 필요한지 판단하기
  3. 대응이 필요한 경우 목표치를 달성하기 위해 어떻게 대응할지 파악하기
  4. 대응하기
  5. 1~4 반복

예를 들어, 두 번째 단계에서 요청의 응답에 대한 지연 시간이 증가하고 있어 SLO를 달성하지 못하게 될 것이라고 판단하면 세 번째 단계에서 그 원인을 찾아 어떻게 대응할지 계획을 세우고 대응한다.