SLO

Service Level Objectives(SLO, 서비스 수준 목표)의 약자.

개발자가 클라우드 서비스에 대한 더 세부적인 안정성 목표를 모델링할 수 있게 해주는 수학 기반의 원칙. 애플리케이션 소유자에게 클라우드 서비스에서 기대되는 항목을 가져오고 결과를 측정(서비스 수준 지표를 통해)하고 장기적으로 튜닝이 가능하도록 코드화할 수단을 제공하는데 활용.

구글의 SRE에서 유래된 SLO는 애플리케이션 성능 모니터링 및 로깅 툴 위에 위치하며, 이 텔레메트리 데이터를 고객 성과의 맥락에 집어넣는다. 즉, 이제 모니터링 시스템에 이상 현상이 감지될 때마다 공황 상태에 빠지지 않고 정해 놓은 서비스 상태 임계값 및 목표 맥락에서 공유된 데이터를 사용해 정보에 근거한 의사 결정을 내릴 수 있다.

SLO는 안정성을 가장 중요한 고객 대면 클라우드 서비스의 중심에 두는 끊임없는 과정을 진행해 나가기 위한 수단이다. 로그, 메트릭, 트레이스 등 과거에 필요했던 모든 것이 여전히 필요하지만, SLO는 클라우드 서비스에 대해 기대되는 사용자 경험의 모델링 관점에서 이를 보강해준다. 개발자, 운영자, 비즈니스 부서가 서비스의 안정성 저하가 실제로 문제가 되는 시점에서 파악해야 하는 맥락과 SLA(너무 구체적인), 모니터링 데이터(노이즈가 너무 많음) 사이에 존재하는 중대한 공백 문제를 SLO가 해결해준다.

1. 사용자 스토리를 공유한다. 예를 들어 사용자가 장바구니에 상품을 추가하고 즉시 체크아웃할 수 있기를 기대하는 전자상거래 사용자 스토리가 있다고 가정해 보자. 이 사용자에게는 체크아웃 시 지연을 참는 임계치가 있으며, 체크아웃이 이 임계치보다 길어지는 경우 기분이 상해 장바구니를 버린다.
2. 이 고객 경험을 SLO로 더 정확하게 표현한다. 장바구니에 상품을 추가하고 X(시간) 이내에 체크아웃할 수 있는 사용자의 비율이 얼마나 되어야 하는가?
3. 위험을 식별해 정량화한다. 고객이 이 시간 안에 체크아웃할 수 없다면 어떻게 되는가? SLO를 충족하지 못하는 경우 어떤 비용이 발생하는가?
4. 위험 범주에 대해 브레인스토밍한다. SLO 미충족을 유발할 수 있는 상황은 무엇인가? 팀에서 다양한 위험에 대한 답이 나올 것이다. 예를 들어 “기반 인프라가 다운되는 경우”, “푸시한 업데이트에 버그가 있는 경우”, “그 정도의 동시 수요가 몰릴 것을 예상하지 못한 경우” 등의 답이 나온다.
5. “그 위험을 낮추려면 어떻게 해야 하는가?”라고 묻는다. 위험을 낮추기 위해 필요한 자원 및 비용과 장애 발생 시 비용을 비교할 때 어떤 위험을 그냥 두고 어떤 위험에 사전에 대처하겠는가? 이 정보를 사용해서 SLO 충족 능력을 측정하고 추적하는 데 사용할 서비스 수준 지표(SLI)를 결정한다.

(링크)