4. 서비스 수준 목표
07 Jun 2023 | Site Reliability Engineering
4. 서비스 수준 목표
서비스 수준 관련 용어
척도
- Service Level Indicator (SLI): 서비스 수준 척도, 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값
- 핵심 SLI
- 응답 속도 : 요청에 대한 응답이 리턴되기까지의 시간
- 에러율 : 시스템이 수신한 전체 요청 수 대비 에러
- 시스템 처리양 (system throughput) : 초당 처리할 수 있는 요청 수
- 측정 된 값들은 합산되기도 한다. 즉, 일정 기간 동안 측정한 값들을 모아 비율이나 평균 혹은 백분율 등을 계산함
- SRE가 중요하게 생각하는 SLI 중 하나는 가용성, 서비스가 사용 가능한 상태로 존재하는 시간의 비율
- 100% 가용성은 실현 불가능
- 여러개의 ‘9’를 이용해서 백분율로 표현 (99%, 99.99% …)
- GKE는 three and half nine (99.95%)를 목표로 한다
목표
- Service Level Objectives (SLO): 서비스 수준 목표, SLI에 의해 측정된 서비스 수준의 목표 값 또는 일정 범위의 값
- SLO는 SLI <= SLO or 최소값 <= SLI <= 최대값 으로 표현 가능
- ex) 셰익스피어의 검색 결과를 “빠르게” 리턴하기로 결정했다면, 평균 검색 요청의 응답 시간에 대한 SLO는 100ms 이하로 설정할 수 있다
- 적절한 SLO를 성정하는 것은 생각보다 복잡하다. 무엇보다, 필요한 값을 항상 얻어낼 수가 없다
- ex) 외부에서 서비스로 유입되는 HTTP 요청의 경우, 기본적으로 QPS라는 지표는 사용자가 서비스를 얼마나 사용하느냐에 따라 결정되므로 이 지표에 대한 SLO를 설정하는 것은 말이 되지 않는다
- 반면, 요청당 평균 응답 시간을 100ms 이내로 달성하겠다는 목표는 설정가능. 또한 이 목표를 달성하기 위한 다양한 노력을 해볼 수 있다
- SLO를 설정하고 고객에게 이를 공개하는 것은 서비스의 동작에 대한 예측을 가능하게 한다.
- SLO가 공개되어있지 않다면, 서비스를 디자인하고 운영하는 사람들의 생각과는 전혀 다른, 자신들이 희망하는 성능을 기대하곤 한다.
- 이는 잠재 고객들이 서비스를 실제보다 저평가하는 현상을 유발하게 된다.
- 글로벌 처비의 경우 연간 SLO를 달성하면 예정된 장애를 일으켜서 의존성을 없애는 방식을 사용함
협약
- Service Level Agreements (SLA) : 서비스 수준 협약, SLO를 만족했을 경우 (혹은 그렇지 못할 때)의 댓가에 대한 사용자와의 명시적 혹은 암묵적인 계약
- SLA는 사업부의 영역, SRE는 관여하지 않음
- 구글 검색은 중요한 서비스임에도 불구하고 SLA가 존재하지 않는 서비스
- 기업용 구글 앱스 등 다른 서비스는 SLA 체결하고 있음
- SLA 체결 여부와는 무관하게 서비스마다 SLI와 SLO를 설정하고 이를 토대로 서비스를 관리해야 함
지표 설정
정말 중요한 것은 무엇인가?
- 너무 많은 지표를 선택한다면 정작 중요한 것에 집중하기가 어렵고, 너무 적은 수의 척도를 선택한다면 오히려 중요한 부분을 놓칠 수 있다
- 적절한 SLI의 선정과 관련해 시스템들을 다음 몇가지로 분류 가능
- 사용자가 직접 대면하는 시스템 : 가용성, 응답 시간, 처리량
- 저장소 시스템 : 응답 시간, 가용성, 내구성
- 빅데이터 시스템 : 처리량, 종단 간 응답 시간
- 모든 시스템 : 정확성
척도 수집하기
- 많은 척도들은 기본적으로 Borgmon이나 Prometheus, 또는 전체 요청 대비 HTTP 500 오류가 발생한 비율 등을 파악하기 위해 일정 기간에 대해 실행하는 로그 분석 등의 방법을 통해 주로 서버 측에서 수집된다.
- 그러나 일부 시스템은 클라이언트에서 측정될 필요도 있다
합산하기
- 단순함과 유용함을 위해 측정된 원본 데이터를 합산하는 경우가 있다 하지만 주의를 기울여야 함
- 대부분의 지표들의 경우 평균보다는 분포(distribution)가 중요하다
- 그림 4-1 이해가 잘 안됨… 어떻게 보는건지 질문
- 척도에 백분위 수(percentile)를 사용하면 분포와 더불어 독특한 특징을 알아볼 수 있다.
- 99번째나 99.9번째 백분위 수 같은 높은 수 들은 최악의 경우의 상황을 보여줌
- 50번째 (emdian)은 일반적인 경우의 상황을 보여줌
- 사용자에 대한 연구에 의하면 사람들은 응답 시간의 변동이 큰 경우보다는 살짝 느리게 동작하는 시스템을 더 선호하므로, 99.9 번째 백분위 수의 값이 양호하다면 사용자 경험이 훨씬 나아질 거라는 근거를 가짐
척도의 표준화
- SLI들에 대한 일반 적인 정의를 표준화하기를 권장함
- 집계 간격 : 평균 1분
- 집계 범위 : 하나의 클러스터에서 수행되는 모든 태스크들
- 측정 빈호 : 매 10초
- 집계에 포함할 요청들: 블랙박스 모니터링 잡이 수집한 HTTP GET 요청들
- 데이터의 수집 방식 : 모니터링 시스템에 의해 서버에서 수집
- 데이터 액세스 응답 시간 : 데이터의 마지막 바이트가 전송된 시간
목표 설정에 대한 실습
- 중요한 것은 어떤 값을 측정할 수 있는지가 아니라 사용자가 중요하게 생각하는 것이 무언인지에 대해 생각해보는 것
- 사용자가 중요하게 생각하는 것은 대부분 측정하기 어렵거나 불가능 한 것
- 단순히 어떤 값을 측정할 수 있는지만을 생각하면 쓸모없는 SLO를 설정하게 됨
- 목표를 먼저 설정한 후 적절한 척도를 찾는 것이 더 낫다
목표 설정하기
- 명확성을 극대화하기 위해 SLO는 측정 방식과 유효한 기준이 반드시 명시되어야 함
- Get RPC 호출의 99%(1분 간의 평균)는 100ms 이내에 수행되어야 한다 (모든 백엔드 서버에서 측정된 평균 시간이어야 한다).
- Get RPC 호출의 99%sms 100밀리초 이내에 수행되어야 한다.
- 만일 성능 그래프가 중요하다면 다음과 같이 여러 개의 SLO를 설정할 수 있다
- Get RPC 호출의 90%는 1ms 이내에 수행되어야 한다
- Get RPC 호출의 99%는 10ms 이내에 수행되어야 한다
- Get RPC 호출의 99.9%는 100ms 이내에 수행되어야 한다
- 만일 사용자의 작업 부하가 처리량을 중시하는 대량 처리 파이프라인과 응답 시간을 중시하는 대화형 클라이언트로 분산되다면 각 부하의 종류에 따라 개별적인 목표를 설정하는 것이 좋다
- 처리량 중시 : Set RPC 호출의 95%sms 1초 이내에 수행되어야 한다
- 응답 시간 중시 : 페이로드(payload) 크기 1kb 미만의 Set RPC호출은 10초 이내에 수행되어야 한다.
- SLO를 100% 만족하는 것은 현실정도 없고 혁신과 배포의 속도가 저하되며 높은 비용을 소비하거나 지나치게 보수적인 솔루션이 됨
- 그래서 에러 예산 (SLO를 만족하지 못하는 비율)을 산정하고 이를 일단위 혹은 주단위로 추적하는 것이 훨씬 낫다
- 어떤 SLO를 달성하지 못한 비율은 사용자가 인지한 서비스의 상태에 대한 유용한 척도가 됨
- SLO들을 일단위 혹은 주단위로 추적해서 트렌드를 파악하고 잠재적인 문제가 실제로 발생하기 전에 미리 그 조짐을 파악하는 것은 매우 유용
- 상위 관리자한테는 월/분기 단위 보고가 좋다
- SLO 위반율을 에러 예산과 비교해서 그 차이를 프로세스를 대입해보면 언제 새로운 릴리즈를 출시할 수 있는지를 판단할 수 있음
목표치 선택하기
- SLO를 선택하는 것은 순수한 기술적 활동은 아님, 사업적 선택이 필요함
- SRE는 이런 논의에 반드시 참여해야 하며, 발생 가능한 위험과 여러 선택 사항들의 실행가능성(viability)에 대해 조언을 할 수 있어야 함
현재의 성능을 기준으로 목표치를 설정하지 말것
최대한 단순하게 생각할 것
자기 만족에 얽매이지 말 것
- 응답 시간의 저하 없이 시스템의 부하를 ‘무한정’ 확장하는 것은 상당히 매력적인데다가 ‘언제든지’ 가능하기는 하지만 사실 이런 요구는 현실성이 없음
- 이런 시스템은 디자인하고 구축하는데 엄청난 시간이 들고 운영비용도 엄청남
가능한 적은 수의 SLO를 설정할 것
- 시스템의 특성을 잘 확인할 수 있는 최소한의 SLO를 선택하는 것이 중요함
처음부터 완벽하게 하려고 하지 말 것
- SLO의 정의와 목표는 시간이 지남에 따라 시스템의 동작을 살피면서 언제든지 다시 정의 할 수 있음
- 우선은 조금 느슨한 목표를 설정한 후 조금씩 강화하는 것이 낫다
측정하기
- 시스템들의 SLI들을 모니터하고 측정하기
- SLI를 SLO와 비교해서 별도의 대응이 필요한지 판단하기
- 대응이 필요한 경우 목표치를 달성하기 위해 어떻게 대응할지 파악하기
- 대응하기
SLO는 기대치를 설정하는 것
- 안전 제한선을 지킬 것
- 사용자에게 광고한 SLO보다는 내부적으로 더 보수적으로 설정된 SLO를 지키면 만성적으로 발생하는 문제들이 외부로 노출되기 전에 적절하게 대응할 수 있는 여력을 가질 수 있음
- 지나친 목표를 설정하지 말 것
- 만일 서비스의 실제 성능이 공개된 SLO를 훨씬 웃돈다면 더 많은 서비스의 현재 성능에 계속 의존하게 될 것이다.
- 이 경우 의도적으로 시스템이 다운되게 하거나, 요청 수를 제한하거나 또는 부하가 낮은 상황에서도 아주 빠르게 동작하지 않도록 시스템을 디자인해서 전체적으로 서비스에 대한 의존도가 높아지는 것을 방지할 수 있음
- 이러한 설정은 시스템에 대한 투자 방향을 결정하는데 도움이 됨
협약에 대한 실습
- SLA를 수립하려면 사업부와 법무팀이 위반하는 경우에 대한 적절한 보상과 댓가를 수립해야 한다
- 사용자에게 공개하는 내용은 조금 보수적으로 설정하는 편이 좋다. 왜냐하면 사용자 층이 두터워질수록 SLA를 변경하거나 삭제하기가 더 어려워지기 때문이다.
4. 서비스 수준 목표
서비스 수준 관련 용어
척도
- Service Level Indicator (SLI): 서비스 수준 척도, 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값
- 핵심 SLI
- 응답 속도 : 요청에 대한 응답이 리턴되기까지의 시간
- 에러율 : 시스템이 수신한 전체 요청 수 대비 에러
- 시스템 처리양 (system throughput) : 초당 처리할 수 있는 요청 수
- 측정 된 값들은 합산되기도 한다. 즉, 일정 기간 동안 측정한 값들을 모아 비율이나 평균 혹은 백분율 등을 계산함
- SRE가 중요하게 생각하는 SLI 중 하나는 가용성, 서비스가 사용 가능한 상태로 존재하는 시간의 비율
- 100% 가용성은 실현 불가능
- 여러개의 ‘9’를 이용해서 백분율로 표현 (99%, 99.99% …)
- GKE는 three and half nine (99.95%)를 목표로 한다
목표
- Service Level Objectives (SLO): 서비스 수준 목표, SLI에 의해 측정된 서비스 수준의 목표 값 또는 일정 범위의 값
- SLO는 SLI <= SLO or 최소값 <= SLI <= 최대값 으로 표현 가능
- ex) 셰익스피어의 검색 결과를 “빠르게” 리턴하기로 결정했다면, 평균 검색 요청의 응답 시간에 대한 SLO는 100ms 이하로 설정할 수 있다
- 적절한 SLO를 성정하는 것은 생각보다 복잡하다. 무엇보다, 필요한 값을 항상 얻어낼 수가 없다
- ex) 외부에서 서비스로 유입되는 HTTP 요청의 경우, 기본적으로 QPS라는 지표는 사용자가 서비스를 얼마나 사용하느냐에 따라 결정되므로 이 지표에 대한 SLO를 설정하는 것은 말이 되지 않는다
- 반면, 요청당 평균 응답 시간을 100ms 이내로 달성하겠다는 목표는 설정가능. 또한 이 목표를 달성하기 위한 다양한 노력을 해볼 수 있다
- SLO는 SLI <= SLO or 최소값 <= SLI <= 최대값 으로 표현 가능
- SLO를 설정하고 고객에게 이를 공개하는 것은 서비스의 동작에 대한 예측을 가능하게 한다.
- SLO가 공개되어있지 않다면, 서비스를 디자인하고 운영하는 사람들의 생각과는 전혀 다른, 자신들이 희망하는 성능을 기대하곤 한다.
- 이는 잠재 고객들이 서비스를 실제보다 저평가하는 현상을 유발하게 된다.
- 글로벌 처비의 경우 연간 SLO를 달성하면 예정된 장애를 일으켜서 의존성을 없애는 방식을 사용함
협약
- Service Level Agreements (SLA) : 서비스 수준 협약, SLO를 만족했을 경우 (혹은 그렇지 못할 때)의 댓가에 대한 사용자와의 명시적 혹은 암묵적인 계약
- SLA는 사업부의 영역, SRE는 관여하지 않음
- 구글 검색은 중요한 서비스임에도 불구하고 SLA가 존재하지 않는 서비스
- 기업용 구글 앱스 등 다른 서비스는 SLA 체결하고 있음
- SLA 체결 여부와는 무관하게 서비스마다 SLI와 SLO를 설정하고 이를 토대로 서비스를 관리해야 함
지표 설정
정말 중요한 것은 무엇인가?
- 너무 많은 지표를 선택한다면 정작 중요한 것에 집중하기가 어렵고, 너무 적은 수의 척도를 선택한다면 오히려 중요한 부분을 놓칠 수 있다
- 적절한 SLI의 선정과 관련해 시스템들을 다음 몇가지로 분류 가능
- 사용자가 직접 대면하는 시스템 : 가용성, 응답 시간, 처리량
- 저장소 시스템 : 응답 시간, 가용성, 내구성
- 빅데이터 시스템 : 처리량, 종단 간 응답 시간
- 모든 시스템 : 정확성
척도 수집하기
- 많은 척도들은 기본적으로 Borgmon이나 Prometheus, 또는 전체 요청 대비 HTTP 500 오류가 발생한 비율 등을 파악하기 위해 일정 기간에 대해 실행하는 로그 분석 등의 방법을 통해 주로 서버 측에서 수집된다.
- 그러나 일부 시스템은 클라이언트에서 측정될 필요도 있다
합산하기
- 단순함과 유용함을 위해 측정된 원본 데이터를 합산하는 경우가 있다 하지만 주의를 기울여야 함
- 대부분의 지표들의 경우 평균보다는 분포(distribution)가 중요하다
- 그림 4-1 이해가 잘 안됨… 어떻게 보는건지 질문
- 척도에 백분위 수(percentile)를 사용하면 분포와 더불어 독특한 특징을 알아볼 수 있다.
- 99번째나 99.9번째 백분위 수 같은 높은 수 들은 최악의 경우의 상황을 보여줌
- 50번째 (emdian)은 일반적인 경우의 상황을 보여줌
- 사용자에 대한 연구에 의하면 사람들은 응답 시간의 변동이 큰 경우보다는 살짝 느리게 동작하는 시스템을 더 선호하므로, 99.9 번째 백분위 수의 값이 양호하다면 사용자 경험이 훨씬 나아질 거라는 근거를 가짐
척도의 표준화
- SLI들에 대한 일반 적인 정의를 표준화하기를 권장함
- 집계 간격 : 평균 1분
- 집계 범위 : 하나의 클러스터에서 수행되는 모든 태스크들
- 측정 빈호 : 매 10초
- 집계에 포함할 요청들: 블랙박스 모니터링 잡이 수집한 HTTP GET 요청들
- 데이터의 수집 방식 : 모니터링 시스템에 의해 서버에서 수집
- 데이터 액세스 응답 시간 : 데이터의 마지막 바이트가 전송된 시간
목표 설정에 대한 실습
- 중요한 것은 어떤 값을 측정할 수 있는지가 아니라 사용자가 중요하게 생각하는 것이 무언인지에 대해 생각해보는 것
- 사용자가 중요하게 생각하는 것은 대부분 측정하기 어렵거나 불가능 한 것
- 단순히 어떤 값을 측정할 수 있는지만을 생각하면 쓸모없는 SLO를 설정하게 됨
- 목표를 먼저 설정한 후 적절한 척도를 찾는 것이 더 낫다
목표 설정하기
- 명확성을 극대화하기 위해 SLO는 측정 방식과 유효한 기준이 반드시 명시되어야 함
- Get RPC 호출의 99%(1분 간의 평균)는 100ms 이내에 수행되어야 한다 (모든 백엔드 서버에서 측정된 평균 시간이어야 한다).
- Get RPC 호출의 99%sms 100밀리초 이내에 수행되어야 한다.
- 만일 성능 그래프가 중요하다면 다음과 같이 여러 개의 SLO를 설정할 수 있다
- Get RPC 호출의 90%는 1ms 이내에 수행되어야 한다
- Get RPC 호출의 99%는 10ms 이내에 수행되어야 한다
- Get RPC 호출의 99.9%는 100ms 이내에 수행되어야 한다
- 만일 사용자의 작업 부하가 처리량을 중시하는 대량 처리 파이프라인과 응답 시간을 중시하는 대화형 클라이언트로 분산되다면 각 부하의 종류에 따라 개별적인 목표를 설정하는 것이 좋다
- 처리량 중시 : Set RPC 호출의 95%sms 1초 이내에 수행되어야 한다
- 응답 시간 중시 : 페이로드(payload) 크기 1kb 미만의 Set RPC호출은 10초 이내에 수행되어야 한다.
- SLO를 100% 만족하는 것은 현실정도 없고 혁신과 배포의 속도가 저하되며 높은 비용을 소비하거나 지나치게 보수적인 솔루션이 됨
- 그래서 에러 예산 (SLO를 만족하지 못하는 비율)을 산정하고 이를 일단위 혹은 주단위로 추적하는 것이 훨씬 낫다
- 어떤 SLO를 달성하지 못한 비율은 사용자가 인지한 서비스의 상태에 대한 유용한 척도가 됨
- SLO들을 일단위 혹은 주단위로 추적해서 트렌드를 파악하고 잠재적인 문제가 실제로 발생하기 전에 미리 그 조짐을 파악하는 것은 매우 유용
- 상위 관리자한테는 월/분기 단위 보고가 좋다
- SLO 위반율을 에러 예산과 비교해서 그 차이를 프로세스를 대입해보면 언제 새로운 릴리즈를 출시할 수 있는지를 판단할 수 있음
목표치 선택하기
- SLO를 선택하는 것은 순수한 기술적 활동은 아님, 사업적 선택이 필요함
- SRE는 이런 논의에 반드시 참여해야 하며, 발생 가능한 위험과 여러 선택 사항들의 실행가능성(viability)에 대해 조언을 할 수 있어야 함
현재의 성능을 기준으로 목표치를 설정하지 말것
최대한 단순하게 생각할 것
자기 만족에 얽매이지 말 것
- 응답 시간의 저하 없이 시스템의 부하를 ‘무한정’ 확장하는 것은 상당히 매력적인데다가 ‘언제든지’ 가능하기는 하지만 사실 이런 요구는 현실성이 없음
- 이런 시스템은 디자인하고 구축하는데 엄청난 시간이 들고 운영비용도 엄청남
가능한 적은 수의 SLO를 설정할 것
- 시스템의 특성을 잘 확인할 수 있는 최소한의 SLO를 선택하는 것이 중요함
처음부터 완벽하게 하려고 하지 말 것
- SLO의 정의와 목표는 시간이 지남에 따라 시스템의 동작을 살피면서 언제든지 다시 정의 할 수 있음
- 우선은 조금 느슨한 목표를 설정한 후 조금씩 강화하는 것이 낫다
측정하기
- 시스템들의 SLI들을 모니터하고 측정하기
- SLI를 SLO와 비교해서 별도의 대응이 필요한지 판단하기
- 대응이 필요한 경우 목표치를 달성하기 위해 어떻게 대응할지 파악하기
- 대응하기
SLO는 기대치를 설정하는 것
- 안전 제한선을 지킬 것
- 사용자에게 광고한 SLO보다는 내부적으로 더 보수적으로 설정된 SLO를 지키면 만성적으로 발생하는 문제들이 외부로 노출되기 전에 적절하게 대응할 수 있는 여력을 가질 수 있음
- 지나친 목표를 설정하지 말 것
- 만일 서비스의 실제 성능이 공개된 SLO를 훨씬 웃돈다면 더 많은 서비스의 현재 성능에 계속 의존하게 될 것이다.
- 이 경우 의도적으로 시스템이 다운되게 하거나, 요청 수를 제한하거나 또는 부하가 낮은 상황에서도 아주 빠르게 동작하지 않도록 시스템을 디자인해서 전체적으로 서비스에 대한 의존도가 높아지는 것을 방지할 수 있음
- 이러한 설정은 시스템에 대한 투자 방향을 결정하는데 도움이 됨
협약에 대한 실습
- SLA를 수립하려면 사업부와 법무팀이 위반하는 경우에 대한 적절한 보상과 댓가를 수립해야 한다
- 사용자에게 공개하는 내용은 조금 보수적으로 설정하는 편이 좋다. 왜냐하면 사용자 층이 두터워질수록 SLA를 변경하거나 삭제하기가 더 어려워지기 때문이다.
Comments