SLA/SLO/SLI

SLA/SLO/SLI

SLI 란 서비스의 성능 또는 안정성에 대한 정량적 측정이다. SLI 는 하나 이상의 모니터 기반 또는 메트릭 기반이다.

SLO 란 특정 기간 동안의 SLI 에 대한 목표 백분율이다.

SLA 란 클라이언트의 신뢰성 기대와 이를 충족하지 못한 서비스 제공자의 결과를 규정하는 클라이언트와 서비스 제공자 간의 명시적 또는 묵시적 합의

KPI(Key Performance Indicator)

KPI 는 성공을 측정하는데 사용될 수 있는 메트릭이다.

KPI 는 목표나 목적과는 다른, 목표를 달성하는 과정 중에 있는지 측정하는 메트릭이다. 따라서 수반하는 목표가 필요하다. 또한 KPI 를 모니터링하는 것은 목표를 달성하기 위해 필수적이다.

• SMART 법칙
  • Specific: KPI 는 구체적이어야 한다.
  • Measurable: 모니터링하기 위해서 KPI 는 측정 가능해야 한다.
  • Acheivable: 100% 는 성취하기 어렵다.
  • Relevent: 관련있지 않은 KPI 는 목표 달성을 이끌어 낼 수 없다.
  • Time-bound: 99% available-Per Year? Per month? Per day?

종류

• Business KPI
  • Return on Investment (ROI)
  • Earning before interest and taxes (EBIT)
  • Employee turnover, Customer churn
• Technical or Software KPI
  • Page view, User registration, Clickthroughs, Checkouts

Service Level

Indicators → Objectives → Agreement

SLI(Service Level Indicators)

Link

서비스의 측정 가능한 특성, A KPI

SLI 는 시간이 정해지고 측정 가능해야 한다.

ex) availability (i. e., how many requests are succeeding), latency (i.e., how long a request takes), throughput, correctness, data freshness, etc.)

적절한 SLI 설정

• 사용자가 직접 대면하는 서비스의 경우 주로 가용성, 응답 시간 그리고 처리량이 중요하다. 즉, 요청에 올바르게 응답할 수 있는지, 응답 시간은 얼마나 오래 걸리는지, 얼마나 많은 요청을 처리할 수 있는지가 중요하다는 뜻이다.
• 저장소 시스템의 경우 주로 응답 시간, 가용성 그리고 내구성이 중요하다. 즉, 데이터를 읽고 쓰는 데 어느 정도의 시간이 걸리는지, 필요할 때 데이터에 액세스할 수 있는지, 데이터는 안전하게 저장되어 있는지 등이 중요하다.
• 데이터 처리 파이프라인 같은 빅데이터 시스템은 처리량과 종단 간 응답 시간이 중요하다. 즉, 얼마나 많은 데이터를 처리할 수 있는지, 데이터가 유입된 이후로 작업을 완료하기까지의 시간은 얼마나 걸리는지(일부 파이프라인은 개별 처리 단계별로 목표 응답 시간을 설정하기도 한다.) 등이 중요하다.
• 모든 시스템은 정확성(correctness) 역시 중요하다. 올바른 응답이 리턴되었는지, 올바른 데이터를 조회했는지, 분석은 정확히 이루어졌는지 등을 고려해야 한다. 정확성은 시스템의 상태를 추적하기 위한 척도로서 매우 중요하지만 인프라스트럭처보다는 시스템의 데이터에 대한 것이므로 이를 달성하기 위해 SRE 가 관여하지는 않는다.

What to Measure: Using SLIs

• 성공 HTTP request 수 / 총 HTTP request (성공률) (Number of successful HTTP requests / total HTTP requests)
• 속도가 100ms 미만인 성공한 gRPC request / 총 gRPC request (Number of gRPC calls that completed successfully in < 100 ms / total gRPC requests)
• 전체 corpus 를 사용한 검색 결과 수 / 총 검색 결과 수, (Number of search results that used the entire corpus / total number of search results, including those that degraded gracefully)
• 10분 이내의 최신 재고 데이터를 사용한 상품 검색의 “재고 확인 횟수” request / 총 재고 확인 request (Number of “stock check count” requests from product searches that used stock data fresher than 10 minutes / total number of stock check requests)
• 사용자가 서비스 에러 없이 사용한 시간[분] / 총 사용자 사용 시간[분] (Number of “good user minutes” according to some extended list of criteria for that metric / total number of user minutes)

SLI 범위는 0% ~ 100% 이며, 0% 는 아무 것도 작동하지 않는 것이고, 100% 는 아무것도 손상되지 않은 것이다. 이 척도를 통해 매우 직관적으로 오류 예산(error budget)을 계산할 수 있다. SLO 는 목표로 하는 백분율이고 오류 예산은 100%에서 SLO 를 뺀 값이다.

 

예를 들어, SLO 가 99.9% 인 경우에, 한달 동안 3백만 개의 요청을 수신하는 서비스의 경우 한달 동안 3,000(0.1%) 개의 오류 예산(error budget) 을 가질 수 있다.

SLI 에서 I 는 측정 방법과 관계없이 사용자에게 중요하다고 생각하는 값이다.

 

SLI 사양

ex) Ratio of home page requests that loaded in < 100 ms

 

SLI 구현

단일 SLI 사양에는 여러 SLI 구현이 있을 수 있으며 각각은 품질(고객의 사용 경험을 얼마나 정확하게 포착하는지), 적용 범위(모든 경험을 얼마나 잘 포착하는지) 등에서 장단점(비용 등..)이 있다.

 

SLI 및 SLO 에 대한 첫 번째 시도가 정확할 필요는 없다. 가장 중요한 목표는 무언가를 제자리에 놓고 측정하고 피드백 루프를 설정하여 개선할 수 있도록 하는 것이 중요하다.

 

SLI 측정 방법 선택

이상적인 측정 방법으로는 고객 서비스 환경과 가장 근접하며 최소한의 노력만으로 측정할 수 있는 측정 방법을 선택해야 한다. 다음은 시간이 지남에 따라 구현하는 데 필요한 노력을 들여야 하는 순으로 나열한 것이다.

1. 애플리케이션 서버 exports 및 인프라 metric 사용. 일반적으로 이런 metric 은 바로 접근할 수 있고 값을 빠르게 제공한다. 몇몇 툴에서는 기본적으로 SLO 를 설정해주는 도구가 포함되어 있다.
2. 클라이언트 계측 사용(APM). 기존 시스템에는 일반적으로 내장된 클라이언트 계측이 없으므로 클라이언트 계측을 제공하는 APM 제품군 또는 FE 프레임워크를 사용하면 고객 만족도에 대한 유용한 정보를 빠르게 얻을 수 있다.
3. 로그 처리 사용. 만약 로그가 있는 경우 로그 처리가 가장 좋은 방법이 될 수 있다. 
4. 합성 테스트 구현. 고객이 서비스를 사용하는 방법에 대한 기본 사항을 이해한 상태에서 서비스 수준을 테스트한다. 이 테스트는 트래픽이 적은 서비스처럼 쉽게 관측할 수 없는 장애들을 찾는데 도움이 될 수 있다.

SLI 구성 요소 유형

SLI 설정을 시작하는 가장 쉬운 방법은 시스템을 몇 가지 일반적인 유형의 구성 요소로 추상화하는 것입니다. 그런 다음 각 구성 요소에 대해 제안된 SLI 목록을 사용하여 서비스와 가장 관련성이 높은 항목을 선택할 수 있습니다. 요청 기반, pipelinem, Storage Type 이 존재.

 

해당 앱은 사용자의 핸드폰에서 클라우드 상의 HTTP API 와 상호작용 한다. 이 API 는 영구적인 스토리지 시스템에 변동사항을 작성하고, 파이프라인은 주기적으로 API 를 실행하여 데이터를 일자별로 쿼리하여 가장 높은 점수를 리그 테이블에 데이터를 저장한다.

이 점수 데이터는 3개의 분리된 DB 중 리그 테이블 DB 에 create 된다. 그리고 이 저장된 데이터들을 모바일 앱이나 웹사이트에서 사용할 수 있다.

 

또한, API 를 통해 게임이나 웹사이트에서 사용하는 사용자 정보를 유저 DB 에 저장 및 업로드한다.

이러한 아키텍쳐 구조에서, 우리는 사용자가 시스템과 어떻게 상호작용하는지 생각해 볼 수 있다. 그리고 어떤 종류의 SLI 가 다양한 관점의 유저 경험을 측정할 것인지 생각해야 한다.

 

사용자에게 가장 중요한 기능을 나타내는 SLI 타입을 선택하는 것이 좋다.

일반적인 사용자 경험과 long tail 법칙을 모두 포착하기 위해 여러 등급의 SLOs 로 여러 타입의 SLIs 를 사용하는 것이 좋다.

예를 들어, 90% 의 사용자들이 100ms 안으로 request 를 처리할 때, 10% 의 사용자들은 request 를 처리하는데 10초가 걸린다.

latency 기반 SLO 는 다양한 임계값을 설정하여 user base 를 포착한다. 90% 의 request 는 100ms 보다 빠르고 99% 의 request 는 400ms 보다 빠르다.

 

이런 원칙은 사용자의 서비스 경험을 측정하는 매개변수가 있는 모든 SLI 에 적용된다.

아래 테이블 2-1 은 다양한 유형의 서비스에서 사용할 수 있는 공통 SLIs 이다.

SLI 구현

첫 SLI 를 구현할 때는 최소한의 작업이 필요한 SLI 를 구현한다. 

SLI 를 측정하기 위한 정보로는 availability, latency 를 사용할 수 있고, availability 를 측정하기 위해서는 성공/실패 상태를 알아야 하고, slow requests 의 경우 request 를 처리하는 시간을 알아야 한다. 즉, SLI 를 위해서는 해당 정보를 알기 위한 충분한 metric 들을 계측할 수 있어야 한다는 것이다.

 

클라우드 기반의 서비스를 사용할 경우 availability, latency 를 클라우드 기반의 모니터링 대시보드에서 사용할 수도 있다.(CloudWatch 메트릭을 바탕으로 자동 생성해주는 대시보드 등..)

이제 각각의 장단점이 존재하는 예제 아키텍쳐의 SLI 구현을 위한 다양한 옵션들을 확인해보자.

API and HTTP server availability and latency

HTTP status code 기반으로 SLI 를 구현할 수 있다.  쉽게 말하자면 availability SLI 는 successful 한 requests 의 비율이고, latency SLI 는 정의된 임계값보다 빠른 requests 의 비율이다.

 

SLI 는 구체적이고 측정가능해야 한다. What to Measure: Using SLIs 에 있는 잠재적인 SLI 후보군들을 요약하자면, SLI 로 아래와 같은 sources 를 하나 이상 사용할 수 있다.

• Application server logs
• Load balancer monitoring
• Black-box monitoring
• Client-side instrumentation

첫 SLI 를 구현할 때는 최소한의 작업이 필요한 SLI 를 구현하는 것이 좋다.

Pipeline freshness, coverage, and correctness

리그 DB 의 테이블을 업데이트하는 파이프라인의 경우, 데이터에 데이터가 업데이트 된 시간의 timestamp 를 포함한 watermark 가 기록된다. 아래 몇가지 SLI 구현 예제를 확인하자.

• 리그 DB 에서 주기적으로 새로운 레코드의 총합과 모든 레코드의 총합을 계산하는 쿼리를 실행한다. 이렇게 쿼리를 실행할 경우 얼마나 많은 사용자가 데이터를 확인하든 상관 없이 오래된(stale) 레코드를 확인할 수 있고 처리할 수 있다(의역).(This will treat each stale record as equally important, regardless of how many users saw the data.)
• 리그 DB 의 모든 클라이언트가 새로운 데이터를 Read 할 때 timestamp 가 적힌 watermark 를 확인하고 데이터가 request 됐음을 알리는 metric counter 를 증가시킨다. 만약 데이터가 미리 정의된 임계값보다 최신일 경우 다른 카운터를 증가시킨다.

위 두가지 options 들은 client-side 에서 구현이다. 그렇기 때문에 사용자 경험과 훨씬 더 밀접하게 연관된 SLI 를 제공한다.  

해당 파이프라인은 처리해야 하는 레코드 수와 성공적으로 처리한 레코드 수를 exports 한다. 만약 파이프라인이 잘못 구성되었다면 이로 인해 올바른 메트릭을 잃을 수 있다.

 

correctness 를 측정하기 위한 몇 가지의 접근법이 존재한다.

• known outputs 를 시스템 상에 밀어 넣었을 때 나오는 출력값이 기댓값과 일치하는 비율을 계산한다. 즉, 올바른 응답값을 받았는지에 대한 비율을 계산한다.(Inject data with known outputs into the system, and count the proportion of times that the output matches our expectations.)
• 데이터를 입력 받아 정확한 결과를 계산하기 위한 방법으로 파이프라인 자체의 중복을 제거하는 방법이 있다.(가격이 비싸기 때문에 적합하지 않다.)입출력 쌍을 사용하여 올바른 응답값의 비율을 계산한다. (Use a method to calculate correct output based on input that is distinct from our pipeline itself (and likely more expensive, and therefore not suitable for our pipeline). Use this to sample input/output pairs, and count the proportion of correct output records. This methodology assumes that creating such a system is both possible and practical.)

척도의 표준화

우리는 각각의 척도들의 최우선 원칙이 무엇인지를 매번 고민할 필요가 없도록 SLI 들에 대한 일반적인 정의를 표준화하기를 권장한다. 표준화된 정의 템플릿을 따르는 모든 수치들은 개별 SLI 의 명세서에서 생략해도 무방하다. 예를 들어보자.

• 집계 간격: '평균 1분'
• 집계 범위: '하나의 클러스터에서 수행되는 모든 태스크들'
• 측정 빈도: '매 10초'
• 집계에 포함할 요청들: '블랙박스 모니터링 잡이 수집한 HTTP GET 요청들'
• 데이터의 수집 방식: '모니터링 시스템에 의해 서버에서 수집'
• 데이터 액세스 응답 시간: '데이터의 마지막 바이트가 전송된 시간'

이처럼 모든 범용 지표에 대해 재사용 가능한 SLI 템플릿을 설정해두면 많은 노력을 절감할 수 있다. 또한 모든 사람들이 특정 SLI 가 의미하는 바를 좀 더 쉽게 이해할 수 있다.

SLO(Service Level Objectives)

Link

SLOs allow you to quantifiably measure customer happiness ⇒ 사용자 경험을 정량적으로 측정할 수 있게 해준다.

주어진 SLI 로 성취하고 싶은 목표나 숫자 지표 ex) 95%, 99% or 99.99% availability

 

SLO 는 성취 가능하고 관련 있어야 한다. 가능한 높은 목표를 세우는 것이 아니라, 사용자를 만족시킬 만큼에서 가격 효율적인 SLO 를 선택해야 한다. SLO 가 높을수록 높은 비용과 노력을 초래하기 때문이다.

 

SLO process overview

1. 사용자 경험과 결제같은 비즈니스 측면에서 악영향을 끼칠 수 있는 metric 리스트를 뽑는다.
2. 사용자 경험을 가장 정확하게 추적하기 위해서 SLI 로 사용할 metric 을 정한다.
3. SLO 목표 값과 SLO 측정 기간을 정한다.
4. SLI, SLO 및 오류 예산(error budget) 콘솔을 생성한다.
5. SLO 알람을 생성한다.

 

Step 1: 사용자 경험과 결제같은 비즈니스 측면에서 악영향을 끼칠 수 있는 action 리스트를 뽑는다.

사용자들이 서비스를 사용할 때 어떤 action 들이 있는지 생각한다. 온라인 이커머스 서비스이기 때문에 사용자들이 실제로 어떤 action 들을 하는지 생각해보면 아래와 같다.

• 상품 목록
• 결제
• 장바구니 추가

해당 액션들의 중요도를 따라 리스트 순위를 정해야 한다. 이커머스 서비스이기 때문에 사용자가 물건을 구매하는 것이 가장 중요하다.

1. 결제
2. 장바구니 추가
3. 상품 목록

상품 목록의 우선 순위가 제일 밑인 것이 의아할 수 있다. 하지만 상품 목록은 결국 결제와 장바구니 추가에 의존하기 때문이다(아마 비즈니스에 대한 뜻 인 듯). 결제나 장바구니 추가보다 상품 목록이 더 중요하다고 말할 수 있을까?

 

중요하다고 생각한다면 상품 목록이 있어야 물건을 장바구니에 추가하고, 결제를 할 수 있다고 생각하는 것일 수 있다.

상품 목록은 하루종일 띄워져 있다. 그러나 장바구니에 물건을 추가하고 결제를 하는 작업은 그렇지 않다. 그렇기 때문에 구매 흐름에 따라 물건을 장바구니에 담고 결제를 하는 작업은 비즈니스 상 매우매우 중요한 작업이다.

 

step 2: 사용자 경험을 가장 정확하게 추적하기 위해 SLI 로 사용할 indicators 를 결정한다.

SLI 를 위한 다양한 indicators 중에 하나를 선택한다.

availability(request 성공 횟수), latency(request 지연율), 처리량, correctness, data freshness 등이 있다.

 

SLI 등식은 올바른 이벤트 / 유효한 이벤트 * 100 이다.

 

결제라는 중요한 이벤트에 대해서 SLI 를 측정하기 위해서는 어떤 과정들이 일어나는지 확인할 필요가 있다. 

고객이 매장에서 제품을 구매하는 과정을 상상해보자. 먼저, 고객들은 어떤 물건을 살지 탐색하고 찾는다. 그 후에 물건을 카트에 담는다. 마지막으로 결제를 진행한다.

 

만약 고객들이 결제하는 과정까지 진행했다면 고객의 비즈니스를 확보했다고 할 수 있다. 그렇기 때문에 고객이 물건을 결제할 수 있도록 하는 것이 무척이나 중요하다.

 

Availability SLI

우리는 고객이 우리 서비스의 결제 기능을 사용하는 것을 목표로 하기 때문에 Availability SLI 를 선택할 것 이다. 우리가 원하는 것은 가용성 측면에서 결제 서비스가 얼마나 잘 수행되고 있는지를 알려주는 메트릭이다.

 

이커머스 플랫폼의 경우, 얼마나 많은 사용자가 결제를 시도했고 얼마 만큼의 request 가 실제로 성공했는지 모니터링 하기를 원한다. 즉, 성공한 request 의 수가 "good(올바른, 양호한)" 메트릭이다.

 

구체적으로 무엇을 측정하고 어디서 측정할 것인지가 중요하므로 availability SLI 는 다음과 같아야 한다.

(전체 요청 - HTTP Status 5XX 오류) / 전체 요청 * 100 

 

3XX, 4XX 가 제외되는 이유는 서비스(서버)의 오류를 나타내는 이벤트를 계산하려 하기 때문에 전체 request 에서 3XX 리다이렉션, 4XX 오류를 제외한 5XX 만 체크한다.

 

Latency SLI

Link

고객들이 결제할 때 임계값 안의 시간으로 주문에 대한 response 가 오는지 체크한다. 즉, successful response 를 받는데 걸리는 시간을 측정하여 latency SLI 로 설정한다. 결제 비즈니스 상 response 가 반환되는 임계값을 500ms 로 설정한다. 즉, response latency 의 99% 는 500ms 이내에 수행되어야 한다.

 

"일반적으로 99번째 백분위수 지연 시간(p99)은 중앙값 지연 시간(median, p50)의 3~5배를 초과해서는 안 된다"

이전 백분위수를 기준으로 지연 시간 임곗값을 결정한 다음 각 버킷에 속하는 요청 수를 측정하는 것이 좋다.

 

Step 3: SLO 목표 설정 및 SLO 측정 기간 결정

예를 들어 한 달 동안 10,000개의 HTTP 요청이 있고 그 중 9,990개만 SLI 설정에 따라 성공적인 response 를 반환하는 경우 해당 월의 가용성은 9,990/10,000 or 99.9% 이다.

 

alert 가 의미 있도록 달성 가능한 SLO 를 설정하는 것이 중요하다. 보통 SLO 를 설정할 때는 historical trends 에서 시작하여 대다수의 고객들이 서비스에 만족하고 있다고 가정하는 것이 좋다. 즉, 비즈니스 상에서 원하는 목표와 수치를 설정하는 것이 이상적이다.

 

SLO 를 100% 만족하는 것은 현실성이 없으며 기대할 수도 없다. 이를 충족하려 하면 혁신과 배포의 속도가 저하되며 높은 비용을 소비하거나 지나치게 보수적인 솔루션이 된다. 그래서 오류 예산(error budget: SLO 를 만족하지 못하는 비율)을 산정하고 이를 일단위 혹은 주단위로 추적하는 것이 훨씬 더 나은 방안이다. 오류 예산(error budget) 역시 다른 SLO 들을 만족하기 위한 또 다른 SLO 일 뿐이다.

 

어떤 SLO 를 달성하지 못한 비율은 사용자가 인지한 서비스의 상태에 대한 유용한 척도가 된다. SLO 들을 일단위 혹은 주단위로 추적해서 트렌드를 파악하고 잠재적인 문제가 실제로 발생하기 전에 미리 그 조짐을 파악하는 것은 매우 유용하다.

 

목표치, 즉 SLO 를 설정하는 것은 순수한 기술적 활동이라고 보기는 어렵다. 그 이유는 SLI 와 SLO 를 어떻게 설정하는지가 제품과 사업에 영향을 미치기 때문이다. 

 

현재의 성능을 기준으로 목표를 설정하지 말 것

시스템의 장점과 한계를 이해하는 것이 기본이므로 이것을 고려하지 않고 목표치를 설정하면 목표치를 달성하기 위해 시스템에 엄청난 노력을 투입하게 되고 결국 방대한 재설계 없이는 시스템의 향상이 불가능하게 된다.

 

최대한 단순하게 생각할 것

SLI 를 복잡하게 집계하면 시스템의 성능 변화를 명확하게 반영하지 못하고 그 원인을 파악하기 어렵게 된다.

 

자기 만족에 얽매이지 말 것

응답 시간의 저하 없이 시스템의 부하를 '무한정' 확장하는 것은 상당히 매력적인데다 '언제든지' 가능하기는 하지만 이런 요구는 현실성이 없다. 이런 이상을 실현 가능한 시스템은 디자인하고 구축하는 데 긴 시간을 필요로 할 뿐 아니라 운영 비용도 엄청나다. 게다가 십중팔구 사용자가 만족할 수 있는 수준을 필요 이상으로 초과할 것이다.

 

가능한 적은 수의 SLO 를 설정할 것

시스템의 특성을 잘 확인할 수 있는 최소한의 SLO 를 선택하는 것이 중요하다. 그리고 선택한 SLO 를 옹호할 수 있어야 한다. 만일 특정 SLO 를 인용했음에도 불구하고 우선순위에 대한 논의에서 밀린다면 그 SLO 는 굳이 설정할 필요가 없는 것이다. 그러나 제품의 모든 특성이 SLO 로 선정하기에 적합한 것은 아니다. SLO 를 이용해서 '사용자의 만족'을 정의하는 것은 상당히 어렵다.

 

처음부터 완벽하게 하려고 하지 말 것

SLO 정의와 목표는 시간이 지남에 따라 시스템의 동작을 살피면서 언제든지 다시 정의할 수 있다. 처음부터 지나치게 높은 목표를 설정해서 나중에 가서야 달성이 불가능한 것을 발견하고 그 목표를 완화하는 것보다는 우선은 조금 느슨한 목표를 설정한 후 조금씩 강화하는 것이 낫다.

SLA(Service Level Agreements)

만약 서비스가 특정 기대를 못 미쳤을 때, 고객 보상을 제공해주는 구속력있는 계약 = more restrictive version of SLO

SLA 에는 만약 서비스가 특정 가용성을 또는 퍼포먼스 기준을 유지하지 못했을 때 제공자에 가해지는 penalty 에 대해 적는다. 그리고 SLA 가 깨지면 고객은 제공자로부터 보상을 받는다.

 

모든 서비스에 SLA 가 있어야 하는 것은 아니지만 SLO 는 있어야 하며 SLO 의 기준은 SLA 보다 높아야 한다.

만약 SLA 가 95% availabilty 일 경우 SLO 는 95% availabilty 보다 높아야 한다는 것이다.

 

아래는 SLI, SLO, SLA 에 대한 예시이다.

SLI 로는 200 응답에 대한 latency 를 잡았고 SLO 로는 99% 의 latency(p99) 가 200ms 보다 작아야 한다. 또한, SLA 로는 99% latency 가 300ms 를 초과할 경우 보상을 지불하도록 설정됐다.