Cloud Computing On Demand

관찰 가능성을 다루다 보면 늘 나오는 용어들.
그 중에서도 SLI, SLO, SLA는 늘, 반드시 나옵니다.

SLI - Service Level Indicator

SLI는 단일하면서도 측정 가능한 서비스의 동작을 나타내는 지표입니다.
중요한 것은 SLI의 대상은 명확하게 의미를 갖고 있는 것이어야 합니다.

• 예시
  
  • Availability (%)
  • Response time (ms)

SLA - Service Level Agreement

SLA는 여러 SLI를 조합한 형태로 보통 표현되는 지표입니다. 
특히 계약 관계가 얽혀 있을때는 패널티 Penalty 나 크레딧 Credit 을 부여하는 기준이 되기도 합니다. 
때문에 벤더 제품이나 플랫폼을 사용할 때 늘 첨예한 충돌이 일어나는 지점이기도 합니다. 
사내에 제공되는 내부 개발 플랫폼이라 하더라도 
SLA를 명확하게 정의해 두는 것이 정신건강을 위해 좋습니다.

SLA의 내용은 보통 (1) 보장하고자 하는 것과, 이를 위해 제시되는 (2) 제약 조건으로 구성됩니다.

• 예시
  • 매일 99% 이상의 요청이 200ms 이내의 응답시간으로 응답되어야 하며, 이 때 응답 Body 크기는 1MB 이하여야 합니다. 이보다 큰 Body를 응답하는 경우 응답시간을 보장할 수 없습니다

가만히 보면 SLA를 구성하는 요소들이 바로 SLI입니다. 

• 예시 SLA에 포함된 SLI들
  • Availability (% of requests)
  • Latency (ms)
  • Content Length (MB)

SLA는 서비스에 대한 SLA가 일반적으로 이야기되지만 
컴포넌트 단위의 SLA도 정의할 수 있습니다. 

SLO - Service Level Objective

SLO는 내용상으로보면 SLA와 거의 동일합니다. 
따라서 구성 요소도 SLA와 마찬가지로 여러 SLI가 됩니다. 
다만 SLA가 "꼭 지켜야만 하는 수준"을 나타낸다면 
SLO는 "우리가 달성하고자 하는 수준"을 나타냅니다.

구글이 NEXT 2018의 IO116 세션으로 발표했던
Improving Reliability with Error Budgets, Metrics and Tracing in Stackdriver를 읽으면서  일부 내용을 요약해 봤습니다. 

내용을 읽으면서 한번 요약을 해보고
이후에는 제가 생각하는 SRE의 R&R에 대해서 
이야기 해볼까 합니다. 

Agile이 동작하는 구간은 Business to Development 의 구간 
DevOps는 Development to Operations 구간에서 동작

DevOps = Practices, Guidelines, Culture
Site Reliability Engineering = Practices, Beliefs for Practices, Job role

SRE가 Operation을 대하는 자세는 
- 자동화에 큰 관심과 노력을 기울여야 하고 
- sysadmin 들이 보통 해오던 일들과 도구를 통해 같은 역할을 수행 
- 신뢰성 있는, 운영하기 좋은 서비스 아키텍쳐를 from the scratch 로 디자인

SRE = 시스템 엔지니어링과 소프트웨어 개발의 교차로

SRE가 신경써야 하는 Practices들.
오너십의 분산, 에러 예산 내에서의 에러 수용 -> 실패 비용 줄이기, 자동화, 측정

인터렉션은 어떻게 정의해야 하는가?
분산되어 있는 서비스 전반에 걸쳐 요청과 응답이 문제 없는가?

결국 이런것, 즉 정상 여부를 판별할 수 있는 기준이 필요하고
SLI (Service Level Indicator) = 좋은 상태인지 구분할 수 있는 측정치
SLO (Service Level Objective) = SLI가 도달해야 하는 최상단 목표 수치
SLA (Service Level Agreement) = SLO 추구의 결과
의 3종 셋트를 정의할 수 있어야 한다.

(To be continued...)