DevOpsDay 2018 - Implementing SRE practices: SLI/SLO deep dive

https://youtu.be/dplGoewF4DA?si=C8n-a4KMDFDa8QVh

 
발표자

• David Blank Edelman: Microsoft CloudOps Advocate - SRE

Site Reliability Engineering

 
Site Reliability Engineering

• 조직에서 운영하는 프로덕트, 비즈니스, 시스템이
• 적절한 수준의 안정성을
• 지속적으로 유지할 수 있도록 하는 Engineering Discipline.

SRE라는 정의에서 필요한 핵심 키워드

• reliability: 암만 열심히 앱 만들어도, 앱이 떠 있지 않으면 쓸모가 없다. 안정적으로 앱이 떠서 서비스 유지될 수 있도록 하는 것.
• Appropriate: goal로 100% 설정하는 건 불가능하다. '적절한 수준'
• Sustainably: 문제해결을 위해 사람이 항시 대기하는 구조가 아니어야 한다.

 

• 이 분야는 '새로운 기능을 개발하려는' 세력과 '안정성을 유지하려는' 세력의 영원한 줄다리기이며
• 개발자의 최종 진화형태도 아니다. Operation 문제 해결을 위한 Parallel Step중 하나임.

Brief Overview

 
진짜 간단하게 요약하면

• Figure out your System - What do you want to measure.
  • "Reliable" 판단할 수 있는 기준을 정한다. == Service Level Indicator (SLI)
• SLI를 설정했다면, 목표 수치를 정한다. == Service Level Objective (SLO)
• SLO 기준을 Monitoring System에 적용한다.

이게 되면, 특정 배포가 있을 때마다 Service Level에 어떤 변화가 있는지 확인하고 대응할 수 있다.

Why SLIs / SLOs / Error Budgets important?

 

• 누구라도 이해할 수 있는 Ground Rule 역할.
  • internal Developer / Stakeholders / VC 모두에게 동일한 언어와 동일한 의미 전달이 된다.
• Focus on Objective Data.
• virtuous cycle - 무엇을 어떤 방법으로 개선할 것인지가 명확한 채 개발 사이클 진행이 가능

cf. 이게 조직 성과를 높여주는 지표는 아니다. (not magic)

SLI

 
핵심 단어는 Reliability. 다만 이 단어는 많은 뜻을 내포하고 있다.

• Availability: 서비스 떠 있나? 접근되나?
• Latency: 서비스 느림
• Throughput: batch processing이나 pipeline에서 중요함
• Coverage: How much of the data have I processed
• Correctness: Did my System Do the right thing when they process the data?
  • 일반적으로 포함되는 뜻은 아니지만, 특정 도메인에서는 매우 중요함
• Quality: What's the fidelity of what I've just delivered to you. (얼마나 충실한 품질의 서비스를 제공하는가)
  • 예컨대 넷플릭스의 추천 엔진에 문제가 생겼다면, 서비스 내리는 게 아니라 Degraded fashion으로라도 제공하기 마련. '최신 영화' 라던가..
  • 이런 형태의 서비스 품질 저하는 user experience에 얼마나 영향을 미칠 것인가? 같은.
• Freshness: 실시간성이 중요한 서비스의 경우.
• Durability: Database / Storage 시스템의 경우

이 중에서 뭘 고를 생각하면 안 된다. 서비스 사용자 (Customer) 와 관련된 것들을 생각해야 한다.

• No one cares about your CPU.
• Serve Something to Customer가 목적이므로, Customer가 체감할 수 있는 서비스 metric을 정해야 한다.

 
SLI는 Ratio / Proportion으로 정의하는 게 일반적. Metric 수집 방법도 포함하는 게 일반적이다.

• 전체 http call 중 successful 비율
  • measured in Load Balancer
• 전체 Operation 중 10ms 내에 완료된 operation
  • measured at the client
• 전체 response 중 "full quality response"
  • measured in the server log
• 전체 record 중 processed된 것들
  • determined by the app

 
server / client / app / monitoring & infra 등...

SLO

 
SLO는 이름에서도 알 수 있듯 Objective - 목표. 들어가야 할 세 가지 키워드.

• The Thing
  • Http Request? Storage Checks? Operation?
• SLI proportion
  • Successful 50% of the time
  • can read the data 99.9% of the time
  • return in 10ms 90% of the time
• Time statement
  • in the last 10 minutes
  • during last quarter
  • in the previous rolling 30 day period

예시: 90% of HTTP request, as reported by load balancer succeeded, in the last 30 day window.

 
Compound 조합

• 90% of reads last week took place in < 10ms (as reported by the disk checker)
• 95% of reads last week took place in < 20ms (as reported by the disk checker)

Segmented

• Percentile 적용할 수도 있음 (백분율 말고 백분위)

 
숫자 기준은 어떻게 정하나?

• Customer Expectation
• Some other data...
• Based on Current System State

Error Budgets

 
SLO에서 정의한 기준치 바깥을 의미함. 예컨대 SLO가 70%라면, 나머지 30%에 해당하는 부분.

• Portion that I don't care if the system is down, because I have already met my objective.
• Error budget 초과 / 미달했을 때의 Policy / Plan 정보를 포함한다.

 
Make a Plan, Follow the plan. 정답은 없고, 각 조직이나 팀 처한 상황에 따라 결정하면 된다.

• Exceed Error Budget: SLO 기준치 충족
  • 신규 기능을 개발하거나
  • 테스트하거나
  • 아무것도 안 한다거나
  • ...
• Exhaust Error Budgets: SLO 기준치 미달
  • 배포 빈도를 줄이거나
  • 로직의 reliability 신경쓰거나
  • ...

---

Q. How do you know when you've got the right SLO essentially?

• through conversation. 기획자 / 개발자 / 기타 이해관계자 모두가 같은 언어와 맥락으로 프로덕트를 이해할 수 있을 때.