구글 SRE(Site Reliability Engineering)
SRE는 SLA의 체결에는 관여하지 않는다.
왜냐하면 SLA는 사업부 및 제품에 대한 의사 결정과 관련이 있기 때문이다. 그러나 SLO를 달성하지 못하는 경우를 피하기 위해서는 SRE의 도움이 필요하다. 또한 SLI를 정의할 때도 도움을 줄 수 있다.
협약에서 언급하는 SLO는 반드시 객관적인 방법으로 측정되어야 하며, 그렇지 않다면 누구도 그 협약에 동의하지 않을 것이기 때문이다.
구글 검색은 중요한 서비스임에도 불구하고 SLA가 존재하지 않는 서비스의 좋은 예다.
우리는 누구든지 검색을 자유롭고 효율적으로 사용하기를 원하지만 전 세계의 모든 사용자와 계약을 맺기를 원하지는 않는다.
그렇다 하더라도 당연히 검색 기능이 제대로 동작하지 않으면 그 댓가를 치러야 한다. -- 서비스가 동작하지 않음으로써 평판도 좋지 않은 영향을 받을 것이며 광고 수입도 줄어들 것이다.
반면, 기업용 구글 앱스 등 구글의 다른 서비스들은 사용자들과 명확한 SLA를 체결하고 있다. 하지만 SLA 체결 여부와는 무관하게 서비스마다 SLI와 SLO를 설정하고 이를 토대로 서비스를 관리해야 한다.
지표 설정서비스나 시스템에 있어 중요한 지표가 무엇인지를 어떻게 판단할 수 있을까?정말 중요한 것은 무엇인가?
사실 모니터링 시스템을 통해 추적할 수 있는 모든 지표를 SLI로 취급할 필요는 없다. 사용자가 무엇을 원하는지를 이해한다면 적절한 척도들을 현명하게 선택할 수 있다.
너무 많은 지표를 선택한다면 정작 중요한 것에 집중하기가 어렵고, 너무 적은 수의 척도를 선택한다면 오히려 중요한 부분을 놓칠 수 있다. 우리는 주로 시스템의 상태를 평가하기에 부족함이 없는 적절한 수의 척도들을 선택한다.적절한 SLI의 선정과 관련해 시스템들은 다음 몇 가지로 분류할 수 있다.
- 세익스피어 검색 프론트엔드 처럼 사용자가 직접 대면하는 시스템들은 주로 가용성, 응답 시간, 그리고 처리량이 중요하다. 다시 말하면, 요청에 올바르게 응답할 수 있는지, 응답 시간은 얼마나 오래 걸리는지, 얼마나 많은 요청을 처리할 수 있는지가 중요하다는 뜻이다.
- 저장소 시스템은 주로 응답 시간, 가용성, 그리고 내구성을 중요시한다. 다시 말하면, 데이터를 읽고 쓰는 데 어느 정보의 시간이 걸리는지, 필요할 때 데이터에 액세스할 수 있는지, 데이터는 안전하게 저장되어 있는지 등이 중요하다. 이런 이슈들에 대한 좀 더 자세한 내용을 확인할 수 있다.
- 데이터 처리 파이프라인 같은 빅데이터 시스템은 종단 간 응답 시간이 중요하다. 즉, 얼마나 많은 데이터를 처리할 수 있다. 데이터가 유입된 이후로 작업을 완료하기까지의 시간은 얼마나 걸리는지(일부 파이프라인은 개별 처리 단계별로 목표 응답 시간을 설정하기도 한다.) 등이 중요하다.
- 모든 시스템은 정확성(correctness) 역시 중요하게 생각해야 한다. 올바른 응답이 리턴되었는지, 올바른 데이터를 조회했는지, 분석은 정확히 이루어졌는지 등을 고려해야 한다. 정확성은 시스템의 상태를 추적하기 위한 척도로서 매우 중요하지만 인프라스트럭처보다는 시스템의 데이터에 대한 것이므로 이를 달성하기 위해 SRE가 관여하지는 않는 경우가 대부분이다.
척도 수집하기많은 척도들은 기본적으로 보그몬(Bogmon)이나 프로메테우스(Prometheus), 또는 전체 요청 대비 HTTP 500 오류가 발생한 비율 등을 파악하기 위해 일정 기간에 대해 실행하는 로그 분석 등의 방법을 통해 주로 서버 측에서 수집된다. 그러나 일부 시스템들은 클라이언트 측의 수집이 이루어져야 하기도 한다. 왜냐하면 클라이언트 측에서 행위를 측정하기 않으면 서버 상의 지표에는 나타나지 않지만 사용자에게는 보여지는 문제들을 놓칠 수 있기 때문이다.
예를 들어 세익스피어 검색 백엔드의 응답 속도만으로는 페이지의 자바스크립트 때문에 발생하는 지연응답을 판단할 수 없다.
이런 경우 페이지가 로드되기까지 걸리는 시간을 브라우저에서 측정하면 사용자의 실제 경험을 판단할 수 있다.합산하기단순함과 유용함을 위해 측정된 원본 데이터를 합산하는 경우도 있다.
다만 이 경우 상당한 주의를 기울여야 한다.초당 요청 수 같은 일부 지표들은 보기에는 직관적이지만, 측정 방식에 따라 직관적으로 보이는 지표들도 일정 시간을 놓고 보면 은연중에 합산되어 있다.
측정 자체가 일초에 한 번 수행되는가 아니면 일분에 걸쳐 발생한 요청들의 평균 값인가? 후자의 경우라면 단 몇 초 동안에 폭발적으로 증가한 요청 비율을 제대로 분석해낼 수 없다. 어떤 시스템은 짝수 초마다 200개의 요청을 처리하는 반면, 나머지는 0개의 요청을 처리했다고 가정해보자.
이때 그 시스템은 평균적으로 초당 100개의 요청을 처리한 셈이지만 순간적인 부하는 평균 값의 두 배에 달할 수 있다. 마찬가지로 평균 응답 속도에 별 문제가 없어 보일지 몰라도 중요한 세부 내용이 모호하다. 대부분의 요청들이 빠르게 처리되었을 수는 있지만, 한 번 느리게 처리된 요청이 이후에 처리된 요청들은 그보다 더 느려지게 된다.
대부분의 지표들의 경우 평균보다는 분포(distribution)가 중요하다. 예를 들어 응답 시간 SLI의 경우, 일부 요청은 빠르게 처리되었을 수 있지만 나머지는 균일하게 더 느리게
- 어쩌면 그보다 더 느리게 처리되었을 수도 있다. 단순히 평균만을 집계하면 이렇게 느리게 처리된 요청 뒤에 유입된 요청들의 처리 속도는 알 수 없다.그림: 50번째, 85번째, 95번째 그리고 99번째 백분위 수에 대한 시스템 응답 시간 비율을 표시한 그래프, Y축은 대수 시간 비율(logarithmic scale)이다.
대부분의 요청들이 50밀리 초 안에 처리되었지만 5%의 요청들은 20배나 느리게 처리된 것을 볼 수 있다. 평균 응답 시간을 기준으로 모니터링과 알림을 설정하면 하루 동안 아무런 변화가 없는 것처럼 보이겠지만, 그림에서 보듯이 뒤따르는 요청들에 대한 처리 속도에는 심각한 변화가 있었다는 사실을 볼 수 있다.(가장 위쪽 줄)척도에 백분위 수(percentile)를 사용하면 분포와 더불어 독특한 특징을 알아볼 수 있다. 즉, 99번째나 99.9번째 백분위 수 같은 높은 수들은 최악의 경우의 상황을 보여주는 반면, 50번째 백분위 수(중간값(median)이라고도 한다.)는 일반적인 경우의 상황을 보여준다.
이 값이 높을 수록 응답 시간의 변동이 크며, 이런 경우가 많아질수록 꼬리를 무는 요청들에 의해 높아진 부하 때문에 사용자의 경험은 갈수록 악화된다.
사용자에 대한 연구에 의하면 사람들은 응답 시간의 변동이 큰 경우보다는 살짝 느리게 동작하는 시스템을 더 선호하므로 99.9번째 백분위 수의 값이 양호하다면 일반적인 사용자 경험 역시 훨씬 나아질 것이라는 점을 근거로 일부 SRE는 높은 백분위 수 값들에 더 주목하기도 한다.
통계적 오류에 대한 단상우리는 주로 평균 값(mean value, 수학적 평균 값)보다는 백분위 수를 다루는 것을 선호한다. 그렇게하면 측정점(data point)이 늘어지는 경우, 즉 측정된 값이 평균값과 상당히 다른(그래서 더 관심이 가는)경우를 함께 고려할 수 있기 때문이다.
컴퓨터 시스템의 수학적 본질 때문에 측정점이 왜곡되는 경우도 있다. 예를 들어 응답 시간이 0밀리초 이하인 이하인 요청이 있다거나, 1,000밀리초의 타임아웃이 설정되어 있는데 타임아웃 값보다 응답 시간이 긴 요청이 있는 경우 등이 발생할 수 있다. 그렇게 때문에 우리는 평균값과 중간값이 같거나 두 값 사이에 큰 차이가 없다고 생각할 수 없다.
우리는 데이터가 통상적으로 검증을 거쳐 분포되었을 것이며 어떤 감이나 예측에 의한 것이 아니라고 간주한다. 예를 들어 분포가 기대한 것과 다르다면 프로세스가 동작할 때 예상치 못한 상황(많은 수의 요청이 유입될 때 서버를 재시작하는 등)이 너무 자주 발생했거나 혹은 충분히 자주 발생하지 않았을 것이다.척도의 표준화우리는 각각의 척도들의 최우선 원칙이 무엇인지를 매번 고민할 필요가 없도록 SLI들에 대한 일반적인 정의를 표준화하기를 권장한다. 표준화된 정의 템플릿을 따르는 모든 수칙들은 개별 SLI의 명세에서 생략해도 무방하다.
예를 들어보자.
- 집계 간격: '평균 1분'
- 집계 범위: '하나의 클러스터에서 수행되는 모든 태스크들'
- 측정 빈도:'매 10초'
- 집계에 포함할 요청들: '블랙박스 모니터링 잡이 수집한 HTTP GET 요청들'
- 데이터의 수집 방식: '모니터링 시스템에 의해 서버에서 수집'
- 데이터 액세스 응답 시간: '데이터의 마지막 바이트가 전송된 시간'
이처럼 모든 범용 지표에 대해 재사용 가능한 SLI템플릿을 설정해두면 많은 노력을 절감할 수 있다. 또한 모든 사람들이 특정 SLI가 의미하는 바를 좀 더 쉽게 이해할 수 있다.목표 설정에 대한 실습중요한 것은 어떤 값을 측정할 수 있는지가 아니라 사용자가 중요하게 생각하는 것이 무엇인지에 대해 생각해보는(아니면 찾아내는) 것이다.
사용자가 중요하게 생각하는 것은 대부분 측정하기 어렵거나 심지어 불가능한 것이므로 결국은 어떤 방법으로든 사용자의 수요를 예측해내게 된다. 그러나 단순히 어떤 값을 측정할 수 있는지만을 생각한다면 그다지 유용하지 않은 SLO들을 설정하게 될 것이다.
그래서 우리는 척도를 먼저 선택하고 목표를 설정하는 것보다는 목표를 먼저 설정한 후 적절한 척도를 찾는 것이 더 낫다는 것을 알아냈다.목표 설정하기명확성을 극대화하기 위해 SLO는 측정 방식과 유효한 기준이 반드시 명시되어야 한다.
아래의 문장들을 살펴보자(두 번째 항목은 첫 번째 항목과 동일하시만 중복을 제거하기 위해 이전 절에서 설명한 SLI의 공통 속성을 사용해 정의한 항목이다.)
- Get RPC 호출의 99%(1분 간의 평균)는 100밀리초 이내에 수행되어야 한다.(모든 백엔드 서버에서 측정된 평균 시간이어야 한다.)
- Get RPC 호출의 99%는 100밀리초 이내에 수행되어야 한다.만일 성능 그래프가 중요하다면 다음과 같이 여러 개의 SLO 목표를 설정할 수 있다.
- Get RPC 호출의 90%는 1밀리초 이내에 수행되어야 한다.
- Get RPC 호출의 99%는 10밀리초 이내에 수행되어야 한다.
- Get RPC 호출의 99.9%는 100밀리초 이내에 수행되어야 한다.
만일 사용자의 작업 부하가 처리량을 중시하는 대량 처리 파이프라인과 응답 시간을 중시하는 대화형 클라이언트로 분산된다면 각 부하의 종료에 따라 개별적인 목표를 설정하는 것이 좋다.
- 처리량이 중요한 클라이언트로부터 발생한 Set RPC 호출의 95%는 1초 이내에 수행되어야 한다.
- 응답 시간이 중요한 클라이언트로부터 발생한 페이로드(payload) 크기 1kb 미만의 Set RPC 호출은 10초 이내에 수행되어야 한다.
SLO를 100% 만족하는 것은 현실성이 없는 것은 물론이거니와 기대할 수도 없는 상황이다. 이를 충족하려 하면 혁신과 배포의 속도가 저하되며 높은 비용을 소비하거나 지나치게 보수적인 솔루션이 된다.
그래서 에러 예산(SLO를 만족하지 못하는 비율)을 산정하고 이를 일단위 혹은 주단위로 추적하는 것이 훨씬 나은 방안이다.
물론 조직 내의 상위 관리자들에게는 월단위 혹은 분기단위로 평가를 보고하는 편이 낫다(에러 예산은 역시 다른 SLO들을 만족하기 위한 또 다른 SLO일 뿐이다)어떤 SLO를 달성하지 못한 비율은 사용자가 인지한 서비스의 상태에 대한 유용한 척도가 된다.
SLO들을 일단위 혹은 주단위로 추적해서 트렌드를 파악하고 잠재적인 문제가 실제로 발생하기 전에 미리 그 조짐을 파악하는 것은 매우 유용하다. 마찬가지로 상위 관리자들에게는 이에 대한 월단위 혹은 분기 단위 평가를 보고하는 것이 좋다.
SLO 위반율을 에러 예산과 비교해서("에러 예산 활용해보기"참조) 그 차이를 프로세스에 대입해보면 언제 새로운 릴리즈를 출시할 수 있는지를 판단할 수도 있다.에러 예산 활용해보기제품 개발팀과 SRE팀 사이의 서로 다른 업무의 특성으로 인해 발생할 수 있는 의견의 대립에 대해 언급하고 있다.
제품 개발 실적에서는 제품의 개발 속도가 차지하는 비중이 크기 때문에 새로운 코드를 가능한 한 빨리 배포하는 것이 중요하다. 반면, SRE의 실적은 서비스의 신뢰성이 차지하는 비중이 크다. 그래서 많은 양의 변경 사항을 배제하려는 경향이 있다.
두 팀 간의 정보의 불균형은 이와 같은 대립을 더욱 두드러지게 만든다. 제품 개발자들은 코드를 작성하고 릴리즈하는 데 드는 시간과 노력에 대한 정보에 밝은 반면, SRE는 서비스의 신뢰성(그리고 프로덕션 환경의 일반적인 상태)에 대한 정보에 밝다. 이와 같은 차이점은 종종 실제 엔지니어링에 투입되어야 하는 노력의 정도를 측정할 때의 의견 충돌로 이어지기도 한다. 주로 발생하는 의견 대립은 다음과 같다.소프트웨어 결함 허용예상치 못한 이벤트가 발생했을 때 소프트웨어이 유연성을 어느 정도나 확보해야 할까?
너무 경직되어 있다면 융통성 없고 사용성이 떨어지는 제품이 될 것이고, 너무 유연하다면(너무나 안정적으로 동작하지만) 아무도 사용하려 하지 않는 제품이 될 것이다.테스트마찬가지로 충분히 테스트하지 않으면 생각지도 못한 결함, 개인정보 유출, 그 외 여러 언론에 언급될 만한 사건들을 마주하게 될 것이다. 반면, 테스트를 너무 많이 하면 오히려 시장에 나설 기회를 잃을 수도 있다.
출시 빈도새로운 코드를 출시하는 것은 언제나 위험을 감수하는 일이다. 그렇다면 이 위험 부담을 줄이는 것과 다른 작업을 수행하는 것의 균형을 어떻게 맞출 수 있을까?
카나리 테스트 빈도와 규모보통 카나리 테스트(Canarying)라고 부르는 기법은 새로운 코드를 릴리즈하기 전에 일부 구간에만 시범적으로 도입하여 테스트하는 방법으로, 이미 모범 사례로 널리 알려진 방법이다. 그렇다면 카나리 테스트는 얼마나 오래 해야 하며, 카나리 테스트 규모의 어느 정도나 되어야 할까?보통 이미 활동 중인 팀들은 자신들의 위험과 노력 간의 경계에서 나름대로 균형을 맞춰왔을 것이다. 안타깝게도 이러한 균형이 사실은 엔지니어들의 협상 능력이 발동한 것이 아니라 실제로 최적화된 균형인지를 증명하기란 어려운 일이다.
게다가 그렇게 이루어진 결저이 정치, 협박, 혹은 헛된 희망(사실 구글SRE의 비공식 구호는 "희망은 전략이 아니다."이다)으로 인해 이루어진 것이 아니라는 것을 증명하는 것 또한 쉽지 않은 일이다.
그래서 우리의 목표를 양쪽이 모두 동의할 수 있는 목표 지표를 설정해서 이를 협상의 토대로 사용하는 것이다. 의사 결정은 데이터에 기반한 것일수록 더 나은 결정이 될 수 있다.
에러 예산 산정하기목표 데이터를 도출하기 위해서는 두 팀이 함께 서비스의 서비스 수준 목표 혹은 SLO(Sercie Level Objectives, 서비스 수준 목표)에 따라 분기별 에러 예산을 산정해야 한다. 에러 예산을 산정하면 한 분기 내에 서비스가 불안정한 상태로 존재할 수 있는 시간이 얼마나 되는지에 대한 명확한 목표 지표를 설정할 수 있다. 이 지표를 활용하면 SRE팀과 제품 개발팀이 얼마만큼의 위험을 감수할 것인지를 결정할 때 협상 과정에서 발현될 수 있는 정치적 요소들을 제거할 수 있다.
그 다음에 할 일들은 다음과 같다.
- 제품 관리자들이 서비스의 분기별 예상 업타임을 의미하는 SLO를 산정한다.
- 실제 업타임은 제3자, 즉 우리가 보유한 모니터링 시스템으로 측정한다.
- 이 두 숫자 사이의 차이점이 분기별로 얼마만큼의 '불안정성'을 허용할 것인지를 의미하는 '예산'이 된다.
- 업타임이 SLO를 초과한다면(에러 예산이 남아있다면) 새로운 릴리즈를 출시할 수 있다.예를 들어 서비스의 SLO가 분기별로 모든 쿼리를 99.999% 성공적으로 실행하는 것으로 설정되어 있다고 생각해보다. 이는 서비스의 에러 예산이 분기당 실패율 0.001%로 산정되어 있다는 뜻이다.
만일 어느 한 분기에 쿼리의 실행이 0.0002% 실패했다면 이 실패를 유발한 문제점을 해결하기 위해 서비스의 분기별 에러 예산의 20%를 사용하는 셈이다.
장점
에러 예산을 도입할 때의 가장 큰 장점은 제품 개발팀과 SRE팀이 혁신과 신뢰성 사이의 올바른 균형을 찾는 데 필요한 기준을 제공한다는 점이다.사실 많은 제품들이 출시 속도를 관리하기 위해 이런 컨트롤 루프(control loop)를 많이 사용한다.
즉 시스템이 SLO 기준에 부합한다면 계속해서 새로운 기능을 릴리즈하는 것이다. 만일 에러 예산을 모두 써버릴 정도로 SLO를 위배하는 일이 빈번한다면 새로운 릴리즈는 일시적으로 중단하고 시스템의 탄력성과 성능을 향상시키기 위한 개발과 테스트에 자원을 투입해야 한다.
하지만 지금처럼 단순리 릴리즈 여부를 결정하는 방식이 아니라 조금 거 세밀하면서도 효과적인 방법이 있다. 예를 들면 SLO 위배에 따라 에러 예산이 고갈되어가면 릴리즈나 롤백(rollback) 주기를 늦추는 방법도 있다.
예를 들어 제품 개발팀이 테스트에 투입하는 수고를 조금 덜고 싶다거나 배포를 조금 더 빨리 진행하고 싶은데 SRE가 반대한다면, 에러 예산이 의사 결정에 보탬을 줄 수 있다. 예산이 넉넉하다면 제품 개발팀은 조금 더 많은 위험을 감수할 수 있다.
반면, 예산이 바닥났다면 제품 개발팀 스스로가 예산을 초과하는 위험을 감수하는 바람에 점심도 못 먹고 일하게 되는 상황은 피하고 싶을 것이므로 더 많은 테스트를 수행하거나 혹은 배포 속도를 조금 늦추게 될 것이다. 즉, 제품 개발팀은 예산이 어느 정도인지, 그리고 자신들이 관리해야 하는 위험이 어느 정도인지를 알고 있으므로 스스로 조정을 하게 될 것이다.(물론 전체적인 결과는 SLO의 준수 여부에 따라 실제로 배포를 중단할 수 있는 권한을 가지고 있는 SRE팀에 달려있기는 하다.)
에러 예산은 신뢰성에 대한 목표치가 필요 이상으로 높게 설정된 경우 소비하게 되는 비용, 특히 경직성(inflexibility)과 느린 혁신을 드러나게 하는 데 일조한다.
팀이 새로운 기능을 출시하는 데 어려움을 겪고 있다면 아마도 혁신을 위해 SLO를 희생하는(그래서 에러 예산을 늘리려는) 결정을 할지도 모른다.
목표치 선택하기목표치(즉, SLO)를 선택하는 것은 순수한 기술적 활동이라고 보기는 어렵다. 그 이유는 SLI와 SLO를 (SLA도 포함해서) 어떻게 설정하는지가 제품과 사업에 영향을 미치기 때문이다. 마찬가지로 참여 인력, 시장에 출시한 시기, 하드웨어 가용성, 그리고 재정 상태 등의 제약을 바탕으로 제품의 특성 간에 반대급부를 고려해야 할 수도 있다. SRE는 이런 논의에 반드시 참여해야 하며, 발생 가능한 위험과 여러 선택 사항들의 실행가능성(viability)에 대해 조언을 할 수 있어야 한다. 우리는 이런 논의들을 더욱 생산적으로 실행하는 데 도움이 되는 몇 가지 권고안을 도출할 수 있었다.
현재의 성능을 기준으로 목표치를 설정하지 말 것시스템의 장점과 한계를 이해하는 것이 기본이므로 이것을 고려하지 않고 목표치를 설정하면 목표치를 달성라기 위해 시스템에 엄청난 노력을 투입하게 되고 결국 방대한 재설계 없이는 시스템의 향상이 불가능하게 된다.최대한 단순하게 생각할 것
SLI를 복잡하게 집계하면 시스템의 성능 변화를 명확하게 반영하지 못하고 그 원인을 파악하기 어렵게 된다.자기 만족에 얽매이지 말 것응답 시간의 저하 없이 시스템의 부하를 '무한정' 확장하는 것은 상당히 매력적인데다가 '언제든지' 가능하기는 하지만 사실 이런 요구는 현실성이 없다. 이런 이상을 실현 가능한 시스템은 디자인하고 구축하는 데 긴 시간을 필요로 할 뿐 아니라 운영 비용도 엄청나다.
게다가 십중팔구 사용자가 만족할 수 있는 수준을 필요 이상으로 초과할 것이다.가능한 적은 수의 SLO를 설정할 것시스템의 특성을 잘 확인할 수 있는 최소한의 SLO를 선택하는 것이 중요하다. 그리고 선택한 SLO를 옹호할 수 있어야 한다.
만일 특정 SLO를 인용했음에도 불구하고 우선순위에 대한 논의에서 밀린다면 그 SLO는 굳이 설정할 필요가 없는 것이다.(SLO에 대한 논의에서도 계속 밀린다면 그 SLO는 SRE팀이 제품에 대해 설정할 가치가 없는 것일 수도 있다.)
그러나 제품의 모든 특성이 SLO로 선정하기에 적합한 것은 아니다. SLO를 이용해서 '사용자의 만족'을 정의하는 것은 상당히 어렵다.
처음부터 완벽하게 하려고 하지 말 것SLO의 정의와 목표는 시간이 지남에 따라 시스템의 동작을 살피면서 언제든지 다시 정의 할 수 있다.
처음부터 지나치게 높은 목표를 설정해서 나중에 가서야 달성이 불가능한 것을 발견하고 그 목표를 완화하는 것보다는 우선은 조금 느슨한 목표를 설정한 후 조금씩 강화하는 것이다.SLO는 사용자가 어떤 점을 중요하게 생각하고 있는지를 반영하므로 SRE와 제품 개발자들의 작업 우선순위를 결정하는 중요한 토대로 사용할 수 있다.
- 그리고 반드시 사용되어야 한다. 잘 설정된 SLO는 유용하며, 개발팀에 어떤 기능을 정당하게 요구할 수 있는 토대가 된다. 하지만 SLO를 제대로 설정하지 못하면 지나치게 높은 SLO를 달성하기 위해 팀이 엄청난 노력을 투자하게 될 수도 있고, 너무 낮은 수준의 SLO 때문에 형편없는 제품이 만들어질 수도 있어서 결국 모두의 노력을 허사로 만들기도 한다.
SLO는 엄청난 지렛대다. 현명하게 활용해야 한다.
측정하기
SLI와 SLO는 시스템을 관리하는 데 사용되는 제어 루프(control loop)의 핵심 요소다.
1. 시스템의 SLI들을 모니터하고 측정하기
2. SLI를 SLO와 비교해서 별도의 대응이 필요한지 판단하기
3. 대응이 필요한 경우 목표치를 달성하기 위해 어떻게 대응할지 파악하기
4. 대응하기예를 들어 두 번째 단계에서 요청의 응답에 대한 지연 시간이 증가하고 있어서 아무런 대응을 하지 않을 경우 몇 시간 내에 SLO를 달성하지 못하게 될 것이라고 보여지면 세 번째 단계에서는 서버가 CPU 집약적인 작업을 하고 있어서 부하는 분산시키기 위해 CPU를 더 추가해야 한다는 결정을 내리기 위한 테스트가 포함되어야 한다.
SLO를 설정하지 않았다면 대응을 해야 할지 말아야 할지(한다면 언제 해야 할지) 판단할 수 없을 것이다.
SLO는 기대치를 설정하는 것SLO를 공개한다는 것은 시스템의 동작에 대한 기대치를 설정하는 것이다. 사용자(잠재적 사용자를 포함해서)는 특정 서비스가 자신들에게 적합한 것이지를 판단하기 위해 서비스에 어떤 것을 기대할 수 있는지를 알고 싶어한다.
예를 들어 사진 공유 웹사이트를 개발하기 원하는 팀은 비용이 저렴하면서도 내구성이 좋지만 상대적으로 낮은 가용성을 제공하는 서비스를 사용하려 하지는 않겠지만 이런 서비스는 오히려 기록 보관 및 관리 시스템에는 적합할 수 있다.
사용자의 현실적인 기대치를 설정하려면 아래 두 가지 중 하나 혹은 모두를 고려해야 한다.안전 제한선을 지킬 것사용자에게 광고한 SLO보다는 내부적으로 더 보수적으로 설정된 SLO를 지키면 만성적으로 발생하는 문제들이 외부로 노출되기 전에 적절하게 대응할 수 있는 여력을 가질 수 있다.
SLO에 여력을 남겨두면 사용자에게 영향을 미치지 않으면서 성능을 조금 상쇄하더라도 비용이나 유지보수의 용이성을 확보할 수 있는 재구현(reinplementationn)의 기회를 가질 수 있다.지나친 목표를 설정하지 말 것사용자 층의 확보는 서비스 제공자가 제공하겠다는 공약한 것이 아니라 실제 사용자들이 경험한 것에 의해 이루어진다. 특히 인프라스트럭처 서비스는 더욱 그런 경향이 강하다. 만일 독자가 제공하는 서비스의 실제 성능이 공개된 SLO를 훨씬 웃돈다면 더 많은 서비스의 현재 성능에 계속 의존하게 될 것이다.
이런 경우 의도적으로 시스템이 다운되게 하거나(구글의 처비 서비스는 가용성에 대한 의존도가 지나치게 증가하는 것을 방지하기 위해 의도적으로 서비스를 중단하고 있다.) 요청 수를 제한하거나 또는 부하가 낮은 상황에서도 아주 빠르게 동작하지 않도록 시스템을 디자인해서 전체적으로 서비스에 대한 의존도가 높아지는 것을 방지할 수 있다.
시스템이 기대치를 얼마나 충족하는지를 이해하는 것은 시스템을 더 빠르고, 더 가용성이 뛰어나며, 더 탄력적으로 만들기 위한 투자를 할 것인지를 판단하는 데 도움이 된다. 아니면 시스템이 잘 동작하고 있을 경우, 참여 인력의 시간을 기술 부채를 해결하거나 새로운 기능을 추가하거나 혹은 다른 제품을 개발하는 등 우선순위가 더 높은 작업에 투입할 수도 있다.협약에 대한 실습SLA를 수립하려면 사업부와 법무팀이 위반하는 경우 적절한 보상과 댓가를 수립해야 한다.
SRE의 역할은 SLA에 명시된 SLO를 달성하는 데 있어서의 어려움과 가능성을 이해하도록 돕는 것이다. SLO 수립에 대한 조언의 대부분은 SLA에도 그대로 통용된다. 사용자에게 공개하는 내용은 조금 보수적으로 설정하는 편이 좋다.
왜냐하면 사용자 층이 두터워질수록 SLA를 변경하거나 삭제하기가 더 어려워지기 때문이다.
- 사이트 신뢰성 엔지니어링, Site Reliability Engineering, 크리스 존스, 제니퍼 팻오프 -
Posted from my blog with SteemPress : http://internetplus.co.kr/wp/?p=505