SpringOne Platform 2018 - Six Simple Steps to Service Level Objectives (SLO)

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 해준다