SLA, SLO, SLI

안녕하세요. 오늘은 사용자에게 품질의 보장하는 합의에 대한 용어에 대해 설명하겠습니다.

1.SLA(Service Level Agreement/서비스 수준 협약)

정의

• 서비스 제공자와 클라이언트 또는 사용자 간의 협의
• 가용성, 성능, 데이터 내구성, 시스템 장애 발생 시 응답에 소요되는 시간 등 품질 서비스 관련해서 사용자들과 체결하는 일종의 합의를 뜻하는 법적 제약
• SLA에는 우리가 해당 협의를 이행하지 못하고 계약을 위반했을 시 부여되는 패널티와 금전적 보상도 명시적으로 언급되어 있음

SLA가 필요한 이유

• 서비스 이용자와 합의를 통한 가이드를 줘 원반한 처리
• 합의가 불명확할 경우 서비스 제공자와 서비스 이용자간의 혼란이 발생함

2. SLO(Service Level Objectives/서비스 수준 목표)

정의

• 시스템과 과련해서 설정하는 개별 목표에 해당
• 각 SLO는 서비스가 충족해야 하는 목표값이나 또는 목표 값의 범위를 의미
  ex) 문제 해결 시간은 24시간에서 48시간 사이로 설정
• 설계 프로세스의 초반에 설정하는 모든 품질 속성 조건은 물론이고 시스템에 설정하는 다른 목표나 서비스 제공자의 책임으로 설정하는 다른 목표도 모두 한개나 그 이상의 SLO로 만들어지게 됨

SLO and SLA

만약 시스템에 SLA가 있다면 각 SLO는 시스템 내의 특정 척도에 대한 SLA 내에서의 개별 협의를 뜻함
따라서 SLA는 모든 서비스 수준 목표를 하나의 법적 문서로 통합한 것에 해당

하지만 SLA가 없는 시스템일지라도 SLO는 꼭 필요함
왜냐면 이런 목표가 따로 설정되어 있지 않다면 내부나 외부 사용자가 우리 시스템을 사용함으로써 얻을 수 있는 기대치가 무엇일지 불명확 할수 밖에 없음

3. SLI(Service Level Indicator/서비스 수준 척도)

정의

• 서비스 수준 척도는 서비스 수준 목표를 이행하는 데 관련된 양적 척도를 의미
  ex) 모니터링 시스템을 사용해서 측정하거나 로그에서 계산해서 나온 실제 숫자값

• 일단 이 서비스 수준 척도에 따라 숫자를 계산하게 되면 그 산출된 값을 나중에 서비스 수준 목표를 정할 때 설정한 목표치와 비교
  ex) 성공적인 응답을 받은 사용자 요청의 퍼센티지를 산출해서 그 값을 시스템의 가용성을 측정하는 척도로 사용하여 서비스에 대해 설정한 가용성 서비스 수준 목표인 99.9%와 비교

ex)각 요청의 반응 시간을 수집해서 그 값을 시간대 별로 버킷화한 다음 사용자가 경험한 반응 시간의 평균이나 백분위 분포를 계산할 수도 있음 그리고 나중에 그 산출값을 기존에 설정한 백분위 90에 100밀리초라는 종단간 지연 시간 SLO와 비교할 수 있답니다

4. 고려 사항

1. 사용자 관심 지표

   • 모든 측정할 수 있는 서비스 수준 척도를 가져다가 이 척도와 관련된 목표를 정하면 안 됨
   • 대신에 사용자가 가장 신경을 쓸 법한 척도가 무엇일지 고민한 후에 해당 척도와 관련해서서비스 수준 목표를 정해야 함
   • 그래야 해당 서비스 수준 목표를 추적할 서비스 수준 척도를 마련할 수 있음

2. SLO의 갯수

   • 서비스 수준 목표를 더 적게 설정할수록 우리에게는 더 낫음
   • SLO가 너무 많아지면 모든 목표를 동일한 수준으로 우선시하기가 어렵움
   • SLO가 적으면 해당 목표와 관련된 전체 소프트웨어 아키텍처에 집중을 해서 목표를 달성하기가 훨씬 쉬워짐

3. 현실적인 SLO 설정

   • 오류에 대비한 예산을 포함해 현실적인 목표를 설정

   • 99.9%의 가용성을 제공할 수 있다고 해서 반드시 언제나 그래야만 한다는 건 아님 대신에 제공 가능한 더 낮은 수준의 가용성을 보장하는 데 집중해야 함 그래야 비용도 절감하고 예상치 못한 문제에 대비할 여력도 생김

   • 서비스 수준 목표가 외부의 서비스 수준 협의로 구현되어 있는 경우에는 더욱

   • 이런 경우 회사는 공격적인 성향의 내부 서비스 수준 목표와는 별개로 더 느슨한 수준의 외부 서비스 수준 목표를 따로 설정

     예를 들어 외부적으로는 가용성을 99.9%로 설정하더라도 내부적으로는 99.99%의 가용성으로 설정 내부적으로 더 좋은 품질의 서비스를 위해 노력하는 동시에 클라이언트 측으로는 신경을 조금 덜 써도 됨

4. 복구 계획

   • 다시 말해서 만약에 갑자기 시스템이 오랫동안 다운되거나 또는 짧은 시간 안에 성능이 내려가고 갑자기 문제 발생 리포트를 너무 많이 받게 되는 그런 경우엔 어떻게 대처할 건지 미리 결정해야 한다는 거죠