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. 기획자 / 개발자 / 기타 이해관계자 모두가 같은 언어와 맥락으로 프로덕트를 이해할 수 있을 때.