https://youtu.be/953xaxqApGY?si=oyvcImAGN5UtXhrO
발표자: Marie Cosgrove-Davis
- Google Cloud PM. work on Stackdriver suite;
- encompassing logging, monitoring, application performance monitoring tools, incident response management tools
해결해야 할 문제
- System이 제대로 동작하고 있는지.
- 의도한 기능을 사용자에게 제대로 제공하고 있는지.
- SLI: "Metric" whether a user is having success with a specific workflow they're trying to do with your product.
- SLO: "Threshold" you apply to an indicator metric that defines when you think users are happy or sad.
- SLA: Contractual Agreement that a certain level of service will be provided, or there are some sort of penalties (typically financial ones).
SLI와 SLO는 penalty 개념이 없다. 일반적으로 internal Measurement.
1. Think like a PM
프로덕트 사용자 관점 (사용자가 human / computer 뭐든 상관없음. 중요하지 않다)
- What are they doing?
- How are they interacting with my product?
- What do they need to accomplish?
그러려면, 세 가지 질문을 하게 됨.
- What does 'working' mean for my Service?
- How can I measure it?
- How can I alert it?
2. Identify your users
3. Identify User journeys
사용자가 서비스 사용하는 flow를 최대한 많이 나열해본다.
- What they do, What their goals are, What their experiences를 알게 됨
- 이 중에서 Critical User Journey를 2~5개 정도 확인한다. 여기에 집중할 것.
4. Track User Journey success with SLIs
Successful user journey를 추적할 수 있는 Metric을 정의한다. (SLIs)
예컨대 이미지 서빙하는 사이트라면
- 랜딩페이지에서 이미지가 로딩 완료되기까지의 시간 (Latency)
- measured by instrumentation on the page
- 정확한 metric 확보 방법은 엔지니어와 논의하면 된다. 난이도 / 정확도 등 여러 선택지에서 적절한 타협점을 찾게 되기 마련임
Side Note 1. measuring Reliability
간단한 몇 가지 측정 방법
Availability = Fraction of time when service is working. (good minutes / total minutes)
- 인간에게 직관적. 서비스의 Up / Down이 명확한 경우 유용
- Distributed Request / Response 구조일 경우 기준 잡기 어려움.
Availability = Fraction of real users for whom service is working.
- Distributed Request / Response 시스템에서 유용함. 서버의 Up / down 상태와는 무관하게, 사용자 경험에 문제 없으면 gooe interaction.
- user-focused 방식. 트래픽 몰리는 때에도 정상적인 사용자 경험을 보장할 수 있는지? 정보가 Metric에 포함된다.
Step 5. Pick SLOs and Iterate
한 번 결정한 SLO 영원히 유지하는 거 아님.
- 수집된 Metric, 사용자 경험이 SLO의 개선점을 알려줄 것이다.
- 시작은 높게 가져갈 필요 없다.
예시: 90% of pageViews have cat photos load within 1 sec.
Useful tools: Error Budgets
일반적으로 SLO는 99%, 99.5%, 99.9%, 99.99%... 처럼 9로 점철되어 있음.
- 그리고, 숙련된 사람들이 아니라면 소숫점 아래 9의 개수가 무슨 의미인지 직관적으로 깨닫기는 쉽지 않음.
- Error Budgets: 숫자가 어떤 의미인지 알려줄 수 있는 tool
Step 6. Operational Shift: Update Monitoring
목표: Have monitoring that tells you if users are sad.
- SLI - service가 정상임을 측정할 수 있는 Metric 설정 완료.
- SLO - users sad 판단할 수 있는 Threshold 설정 완료.
- Error budgets - user에게 안내한, 언제까지 sad해도 되는지 기준치.
이 조건을 조합해서 Alert를 만들면 된다.
- Configure alerting to fire, if more than x% of error budget has been consumed in the past hour.
위 조건이 다 되어 있다면, CPU 사용량 100% 같은 수치는 중요하지 않다. 그게 사용자 경험에 영향을 미치지 않는다면.
SLI-based Monitoring을 바로 전환하기 부담스럽다면, 기존 로직과 병행해보는 걸 추천한다.
- SLI-based alert가 실제 actual downtime을 잡아냈는지?
- false positive는 없었는지?
평가해보고, 문제가 있다면 SLI를 다시 설정하면 된다. (최초 단계로)
Operational Shift: Below SLO
SLO 기준치보다 낮은 상태일 경우? - users are sad. 발생할 수 있는 상황임.
- Reduce your non-reliability releases. (당연하게도, 배포를 자주 할수록 SLO 하락을 마주할 가능성이 높다.)
- Reliability Feature 신경써라
- Pay down tech Debt. (기술부채 신경써라)
cf. Stackdriver SLO Monitoring in GCP
google StackDriver Monitoring 소개
- SLI Type: Latency (ms) or Availability
- Period: Week or Month
- Goal: 99.9% ~ 99.999% (소수점 9 하나 추가될 때마다 비용은 10배 증가한다고 이해하면 된다)
설정하면 Monitoring 해준다