[SLA] 서비스 안전성의 주요 지표 SLI, SAO + SLA

최근 회사에서 장애 상황이 있었다. 장애가 발생할 수 있지만 장애 처리가 미흡하여 장애 기준, 절차에 대해 재정의를 하려고 한다.

 

장애를 정의하기 앞서서 당사 서비스의 SLI, SLO 를 좀 살펴보았는데, 딱히 정의되어 있지 않은것 같다. 그래서 SLI, SLO가 무엇이고, 타사에서 많이들? 정의하는것을 기반으로 벤치마킹하고자 한다.

 - 아직 공부를 하는 단계이고, 최대한 이해하고 게시물을 작성하였지만, 일부 작성된 내용이 있을 수 있다.

 

SLA 계약 또는 공표하기 위해서는 SLO가 사전 정의가 되어 있어야 하고, SLO를 정의하기 위해서는 SLI로 지표를 정의해야 한다.

SLI(Service Level Indicator)

서비스 수준 척도라고도 불리며, 자세하게 말하면 서비스에 대한 수준을 측정하고 정량적으로 평가하기 위한 지표이다.

SLI로 사용할 수 있는 지표는 다양하지만, 일반적으로 아래의 지표를 많이 사용한다.

• 응답 시간 : API 호출에 대한 Response 응답속도를 뜻한다.
• 에러율 : 요청에 대한 에러 비율을 나타낸다. 일반적으로 5xx 또는 4xx의 비율을 뜻한다.
• 처리량 : 초당 처리량을 뜻한다. BlockChain 또는 API를 제공하는 서비스는 처리량이 보통 정의되어 있다.
• 가용성 : 시스템 Uptime을 뜻한다. 24시간 중 시스템이 Shutdown 되는 비율이다.
• 내구성 : Storage 시스템에만 해당하는데, 데이터의 안전성을 나타내는 지표이다.

물론 이외에도 다양한 지표가 있고, SLI는 회사마다 정의하기 나름이다. 처음 SLI를 정의할 때는 위 5가지를 기반으로 정의를 하면 된다.

 

그리고 SLI 지표를 정했다면, 해당 SLI 지표에 대한 구현과 SLO를 정의해야 한다.

만약, A 서비스에 대한 응답 시간을 SLI 지표로 정했다면, 응답 시간을 어떻게 정의할것인가?가 SLI 지표에 대한 구현이 된다.

 - 예를들어) HTTP Response 200 OK 요청 응답 시간만 측정 또는 HTTP Response 4xx이 아닌 요청 응답 시간만 측정

 

모니터링 시스템을 통해 추적할 수 있는 모든 지표를 SLI로 취급할 필요는 없다. 사용자 입장에서 직접 영향을 받는 지표를 명확히하고, 이것을 측정할 수 있는 지표만 있으면 된다.

 

SLI 지표를 정하고 SLO를 측정하고자 할 때는 평균보다는 분포가 중요하다.

위의 예시를 보면 특정 요청에 대한 50, 85, 95, 99%의 응답 시간에 대한 분포도이다.

일반적인 요청은 대부분 50ms 응답 시간을 가진다. 하지만 느린 응답 시간 즉, 99 또는 95%에 해당하는 응답 시간은 일반적인 요청 대비 매우 느린 속도(5s)이다. 그리고 일반적으로 문제가 되는 것은 99%와 같은 구간에 속도는 응답 시간이 문제가 된다.

 

이처럼 요청에 대한 평균값을 SLI 지표로 삼는 경우에는 99%, 95%와 같이 문제가 되는 요소는 정확한 인지가 불가능하다.

 - 왜냐하면 X분 동안 느린 응답 속도가 많이 발생하지 않고, 평균값으로 생각하는 경우 실제 응답 속도보다 훨씬 낮은 값을 가지게 된다.

 

그래서 분포도로 고려할 때도 99%, 95%와 같이 문제가 되는 구간을 주요 SLI로 삼는것이 좋다.

 

SLO(Service Level Objective)

위에서 SLI를 정했다면, 해당 SLI에 대한 목표점 즉, SLO가 필요하다.

 

SLO = SLI + SLI의 목표값

 

SLO는 서비스 수준 목표라고 불리며, SLI에 의해 측정된 수준 지표의 목표값 또는 일정 값 범위의 값을 뜻한다.

그래서 SLO는 SLI <=목표치 또는 최소값<=SLI<=최대값으로 표현하기도 한다.

 

SLO는 말그대로 서비스에서 제공해주는 서비스 수준의 목표점이기에 외부에 공개하기 애매한 부분이 있다. 하지만 공개하지 않는다면 고객과 기업에서 생각하는 서비스 수준에 차이점이 발생할 수 있고, 이로인해 문제점이 발생할 수 있다.

 

통상 무료서비스인 경우에는 SLO를 따로 공개하지 않지만, 유료서비스인 경우네는 SLA 계약을 하게되고 SLA 계약을 하기위해서는 SLO를 알아야한다.

 

SLA(Service Level Agreement)

SLA는 서비스 수준 협약의 약자이다. 말 그대로 SLO를 기반으로 특정 서비스 수준 이상을 제공하고, 서비스 수준이 SLO 이하로 하락하였을 경우에 월 비용 절감 등으로 보상을 받는 계약을 뜻한다.

 

SLA는 통산 영업 또는 서비스 사업부서에서 고객과 체결하며, SRE 또는 개발팀에서는 계약 체결에 직접적인 연관은 없다.

다만, SLO가 SLA 계약 이하의 임계치로 하락했을 경우는 대응 및 조치를 하기 위해서 SRE/개발팀의 지원이 필요할 수 있다.

 

그렇다면 SLA 계약을 할 때만 또는 SLA 계약에 있는 지표만 SLO 설정을 하면 되는것인가? 답은 그렇지 않다.

SLI 지표를 정하고, SLO를 정의하는것은 서비스에 대한 안전성을 보장하기 위해 첫단계이다.

 

SLI, SLO를 각 서비스마다 정의하지 않게 되면 해당 서비스 가용성 제공이 애매해지고, 개발이 우선인지 안전성이 우선인지 내부 논의 시에 많은 혼란을 불러올 수 있다. 또한 직접적으로 고객과의 SLA 계약은 없지만 서비스 안전성이 떨어지면 서비스에 대한 신뢰성과 이미지가 하락하기 때문에 대고객 서비스를 제공하고 있다면 SLI, SLO를 정의하고 유지보수하는것은 필수이다.

 

 

일반적으로 위의 SLI, SLO 지표를 정의하고 측정하고 유지보수하는 것은 SRE 직무의 사람이 하는 경우가 많다.

 

하지만 대기업이 아닌 이상 SRE, Devops, 개발팀으로 구분하는 조직이 많지 않을것 같고, Devops는 구분 하더라도 SRE가 구분되어 있지 않을 확률이 높다.

 - 지금 다니고 있는 회사가 그렇습니다 ㅜㅜ SRE가 없어서 그런지.. SLI, SLO가 전혀 정의되어 있지 않네요.

 

 

해외 게시물을 읽다가 Devops 와 SRE에 대한 차이점을 나타내는 아래의 그림을 보았다.

아직 회사마다 Devops, SRE를 정의하는 기준이 명확하지 않고, 회사마다 차이가 있다. 그래서 SLI, SLO를 정의하는것이 SRE만의 업무라고 보기보다는 Devops에서 진행하는 한 카테고리의 업무로 봐도 될것 같다.

 

아직 모르는것이 많고, 많이 배우고 있는 직장인의 정리였습니다.

 

끄읏!