SLO 정의

이 문서는 온라인 서비스를 운영하는 팀이 서비스 수준 목표(SLO)를 이용하여 사이트 안정성 엔지니어링(SRE) 문화를 구축하고 채택하는 방법을 보여주는 2부로 구성된 시리즈 중 1부입니다. SLO는 서비스를 위한 안정성 목표 수준입니다.

Software as a service(SaaS)에서는 제품 개발 속도와 운영 안정성 사이에서 자연스럽게 갈등하게 됩니다. 시스템을 많이 변경할수록 시스템이 중단될 가능성이 커집니다. 모니터링 및 관측 도구를 사용하면 개발 속도를 높일 때 운영 안정성에 대한 확신을 유지할 수 있습니다. 하지만 애플리케이션 성능 관리(APM) 도구와 같은 도구도 중요하지만 이러한 도구의 가장 중요한 애플리케이션 중 하나는 바로 SLO를 설정하는 것입니다.

SLO를 올바르게 정의하면 팀은 안정성 저하 없이도 개발 속도를 높이는 데이터 기반의 운영 결정을 내릴 수 있습니다. 또한 SLO는 개발팀과 운영팀이 제품을 생성 및 반복(개발)과 시스템 무결성 유지(작업)라는 두 목표 사이에서 자연스럽게 갈등하는 것을 완화할 수 있는 서로 합의한 단일 목표에 부응하도록 개발과 운영을 조정할 수 있습니다.

SLO는 다른 SRE 방침과 함께 SRE 도서SRE 통합문서에 자세히 설명되어 있습니다. 이 시리즈에서는 사용자가 손쉽게 SLO를 채택할 수 있도록 SLO를 이해하고 개발하는 과정을 단순화합니다. 이러한 문서를 읽고 이해한 후에는 도서에서 더 많은 내용을 찾아볼 수 있습니다.

이 시리즈는 조직에 SLO를 구현하는 명확한 방법을 보여줍니다.

  • 이 문서에서는 SLO가 무엇인지와 서비스를 위한 SLO를 정의하는 방법을 검토합니다.
  • SLO 채택에서는 워크로드 유형에 따른 다양한 SLO 유형, 이러한 SLO를 측정하는 방법, 이를 기반으로 알림을 개발하는 방법에 대해 설명합니다.

이 시리즈는 SRE, 운영팀, DevOps, 시스템 관리자, 온라인 서비스의 안정성과 신뢰성을 담당하는 기타 사용자를 대상으로 합니다. 이 시리즈는 사용자가 인터넷 서비스에서 웹브라우저 및 휴대기기와 통신하는 방법을 이해하고 웹 서비스를 모니터링, 배포, 문제 해결하는 방법에 대한 기본적인 지식이 있다고 가정합니다.

State of DevOps 보고서에는 소프트웨어 제공 성능을 향상시키는 기능이 나와 있습니다. 이 시리즈에서는 다음 기능을 설명합니다.

용어

이 시리즈의 문서에는 다음과 같은 용어 및 정의가 사용됩니다.

  • 서비스 수준: 특정 서비스가 사용자의 예상 작업을 얼마나 잘 수행했는지에 대한 척도입니다. 이 척도를 사용자 만족도와 관련하여 설명할 수 있으며, 서비스에서 수행하는 작업과 사용자가 예상하는 서비스의 작업이나 알려진 수행 가능한 작업에 따라 다양한 방법으로 이를 측정할 수 있습니다.

    예: '사용자는 서비스가 사용 가능하며 속도가 빠를 것으로 예상합니다.'

  • 중요한 사용자 여정(CUJ): 단일 목표(예: 단일 클릭 또는 다단계 파이프라인)를 달성하기 위한 사용자와 서비스의 일련의 상호작용입니다.

    예: '사용자가 결제 버튼을 클릭한 다음 장바구니가 처리되고 영수증이 반환될 때까지 기다립니다.'

  • 서비스 수준 지표(SLI): 서비스 수준을 정량적으로 측정할 수 있는 사용자 만족도 기준입니다. 즉, 서비스 수준을 측정하려면 해당 서비스 수준(예: 서비스 가용성)으로 사용자 만족도를 나타내는 표시기를 측정해야 합니다. SLI는 서비스가 개선되거나 저하되는 과정에서 시간이 지남에 따라 변하는 그래프의 선으로 간주할 수 있습니다.

    예: '최근 10분 동안의 성공한 요청 수를 최근 10분 동안의 모든 유효한 요청 수로 나눈 값을 측정합니다.'

  • 서비스 수준 목표 (SLO): 서비스가 측정된 SLI에 비해 대부분의 시간을 달성할 것으로 예상하는 수준입니다.

    예: '서비스 응답이 14일 동안 측정된 모든 유효한 요청의 95%에 대해 400밀리초(ms)보다 빠릅니다.'

    SLO와 SLI 간의 관계를 보여주는 그래프

  • 서비스수준계약(SLA): SLO를 충족하지 못한 경우 발생하는 상황을 설명합니다. 일반적으로 SLA는 제공업체와 고객 간의 법적 계약이며 보상 조건을 포함할 수도 있습니다. SRE에 대한 기술적 토론에서는 이 조건이 기피되기도 합니다.

    예: '서비스가 한 달 동안 99.95%의 가용성을 제공하지 않는 경우 서비스 제공업체는 규정이 위반되는 1분마다 고객에게 보상을 제공합니다.'

  • 오류 예산: SLO를 위반하기 전에 견딜 수 있는 시간 또는 부정적인 이벤트의 수입니다. 이 측정값은 비즈니스에서 예상하거나 허용할 수 있는 오류의 수를 나타냅니다. 오류 예산은 위험한 결정을 내리는 데 도움이 됩니다.

    예: 'SLO를 99.9% 사용할 수 있는 경우 요청의 0.1%를 허용하여 이슈, 사고 또는 실험을 통해 오류를 처리합니다.'

SLO를 사용해야 하는 이유

SRE 문화를 구축할 때 SLO로 시작하는 이유는 무엇인가요? 간단히 말해 서비스 수준을 정의하지 않으면 고객이 서비스에 만족하는지 여부를 측정하기가 어렵습니다. 서비스를 개선할 수 있다고 해도 서비스 수준이 정의되지 않으면 어느 부분을 얼마나 개선해야 하는지 파악하기가 어렵습니다.

사용자에게 표시되는 여부에 관계없이 모든 서비스에 대해 별도의 SLO를 개발하고 싶을 수 있습니다. 예를 들어 흔히 범하는 실수는 사용자가 서비스(예: 프런트엔드 서비스 및 백엔드 Datastore)를 구분하지 않고 활용할 때 두 개 이상의 서비스를 별도로 측정하는 것입니다. 더 나은 접근 방식은 제품(서비스 모음)을 기반으로 하는 SLO를 개발하고 사용자의 가장 중요한 상호작용에 집중하는 것입니다.

따라서 효과적인 SLO를 개발하려면 중요한 사용자 여정(CUJ)이라고 하는 사용자의 서비스 상호작용을 이해하는 것이 좋습니다. CUJ는 사용자의 목표가 무엇인지, 사용자가 서비스를 사용하여 이러한 목표를 달성하는 방법을 고려합니다. CUJ는 서비스 경계를 고려하지 않고 고객의 관점에서 정의됩니다. CUJ가 충족되면 고객이 만족하게 되고 우수한 고객 만족도는 서비스 성공에 대한 주요 척도입니다.

서비스에 대한 고객 만족도의 주요 측면은 서비스의 안정성입니다. 서비스가 불안정하다면 서비스가 어떻게 작동하는지는 중요하지 않게 됩니다. 따라서 안정성이 모든 서비스의 가장 중요한 특징입니다. 안정성의 일반적인 측정항목은 기본적으로 시스템이 실행된 시간을 의미하는 업타임입니다. 하지만 더 유용하고 정확한 측정항목인 가용성을 사용하는 것이 좋습니다. 가용성은 시스템이 중단된 후 경과한 시간을 측정하는 것보다 정확한 방법으로 시스템이 가동 중인지에 대한 질문에 여전히 답합니다. 오늘날의 분산 시스템에서 서비스는 부분적으로 중단될 수 있으며 업타임이 잘 캡처하지 못하는 요소가 될 수 있습니다.

가용성은 종종 99.9%(9가 3개) 가용성 또는 99.99%(9가 4개) 가용성과 같이 9의 개수로 설명됩니다. 가용성 SLO를 측정하는 것은 시스템 신뢰성을 측정하는 가장 좋은 방법 중 하나입니다.

SLO는 운영 성공을 정의하는 것 외에도 어디에 리소스를 투자할지 선택하는 데 도움이 됩니다. 예를 들어 SRE 도서에서는 사용자가 엔지니어링하는 각 9로 인해 한계 유틸리티와 함께 비용 증가가 초래될 수 있다는 점을 말해줍니다. 일반적으로 가용성의 다음 자리 9를 달성하는 데 드는 비용이 이전 자리의 비용보다 10배나 더 많이 듭니다.

SLI 선택

SLO가 충족되었는지, 즉 성공적인지 확인하려면 측정이 필요합니다. 이러한 측정을 서비스 수준 지표(SLI)라고 합니다. SLI는 사용자가 고객에게 제공하는 특정 서비스의 수준을 측정합니다. 이상적으로 SLI는 허용되는 CUJ와 연결되어 있습니다.

최적의 측정항목 선택

SLI 개발의 첫 번째 단계는 초당 요청, 초당 오류, 큐 길이, 지정된 기간의 응답 코드 분포, 전송된 바이트 수와 같이 측정할 측정항목을 선택하는 것입니다.

이러한 측정항목은 일반적으로 다음과 같은 유형입니다.

  • 카운터. 예를 들어 지정된 측정 지점에서 발생한 오류 수입니다. 이러한 유형의 측정항목은 늘릴 수 있지만 줄일 수는 없습니다.
  • 분포. 예를 들어 지정된 기간에 특정한 측정 세그먼트를 채우는 이벤트 수입니다. 완료하는 데 0~10ms가 걸리는 요청 수, 11~30ms가 걸리는 요청 수, 31~100ms가 걸리는 요청 수를 측정할 수 있습니다. 결과는 각 버킷의 개수입니다(예: [0~10: 50], [11~30: 220], [31~100: 1,103]).
  • 게이지. 예를 들어 시스템 측정 가능 부분의 실제 값(예: 큐 길이)입니다. 이 유형의 측정항목은 늘리거나 줄일 수 있습니다.

이러한 유형에 대한 자세한 내용은 Prometheus 프로젝트 문서Cloud Monitoring 측정항목 유형 ValueTypeMetricKind를 참조하세요.

SLI에 대한 중요한 차이점은 모든 측정항목이 SLI인 것은 아니라는 점입니다. 실제로 SRE 워크북에는 다음 사항이 명시되어 있습니다(강조표시됨).

'... 일반적으로 SLI를 두 숫자의 비율로 처리하는 것이 좋습니다. 이 비율은 우수한 이벤트 수를 총 이벤트 수로 나눈 것입니다.'

'SLI의 범위는 0~100%입니다. 여기서 0%는 아무것도 작동하지 않음을, 100%는 아무런 문제가 없음을 의미합니다. 이 규모는 직관적이며 이 스타일은 오류 예산의 개념에 쉽게 부합한다는 사실을 발견했습니다.'

많은 소프트웨어 회사가 수백 또는 수천 개의 측정항목을 추적하며 일부 측정항목만 SLI로 인정됩니다. 그렇다면 우수한 이벤트 수와 전체 이벤트 수의 비율 이외에 어떤 것이 측정항목을 적합한 SLI의 자격이 있나요? 적합한 SLI 측정항목에는 다음과 같은 특성이 있습니다.

  • 이 측정항목은 사용자 만족도와 직접적으로 관련이 있습니다. 일반적으로 서비스가 예상하는 방식으로 작동하지 않거나, 실패하거나, 느려지는 경우 사용자는 만족하지 못합니다. 이러한 측정항목을 기반으로 하는 모든 SLO는 고객 불만 신고 수, 문의 전화량, 소셜 미디어 감정, 에스컬레이션과 같은 사용자 만족도의 다른 신호를 SLI와 비교하여 검증될 수 있습니다. 측정항목이 사용자 만족도의 다른 측정항목에 해당되지 않으면 SLI로 사용하기에 적합한 측정항목이 아닐 수 있습니다.
  • 측정항목 저하는 서비스 중단과 상관관계가 있습니다. 서비스 중단 중에 적합해 보이는 측정항목은 SLI에 대해 잘못된 측정항목입니다. 정상 작동 중에 부적합해 보이는 측정항목도 SLI에 대해 잘못된 측정항목입니다.
  • 측정항목은 적합한 신호대 잡음비를 제공합니다. 많은 수의 거짓음성 또는 거짓양성을 유발하는 측정항목은 적합한 SLI가 아닙니다.
  • 측정항목은 고객의 만족도를 통해 단조로우며 약 선형적으로 확장됩니다. 측정항목이 개선되면 고객 만족도도 향상됩니다.

다음 다이어그램에서 그래프를 살펴보세요. 서비스의 SLI로 사용할 수 있는 두 가지 측정항목은 시간 경과에 따라 그래프로 표시됩니다. 서비스가 저하되는 기간은 빨간색으로 강조표시되고 서비스가 양호한 기간은 파란색으로 강조표시됩니다.

이미지

부적합한 SLI의 경우 사용자의 불만족은 부정적인 이벤트(예: 서비스 성능 저하, 속도 저하, 중단)와 직접 대응하지는 않습니다. 또한 SLI는 사용자 만족도와는 독립적으로 변동합니다. 적합한 SLI의 경우 SLI 및 사용자 만족도는 상관관계가 있고, 다양한 만족도 수준이 명확하고, 관련 없는 변동이 훨씬 적습니다.

올바른 측정항목 수 선택

일반적으로 단일 서비스에는 여러 SLI가 있으며 특히 서비스가 여러 가지 유형의 작업을 수행하거나 여러 유형의 사용자에게 서비스를 제공하는 경우 더 그렇습니다. 예를 들어 쓰기 요청을 읽기 요청과 분리하는 것이 좋습니다. 이러한 요청은 서로 다른 방식으로 작동하기 때문입니다. 이 경우에는 각 서비스에 적합한 측정항목을 선택하는 것이 가장 좋습니다.

반대로 많은 서비스가 서비스 전반에서 유사한 유형의 작업을 수행하며, 이 경우 직접 비교할 수 있습니다. 예를 들어 온라인 마켓플레이스가 있는 경우 사용자가 홈페이지를 보거나 하위 카테고리 또는 상위 10개 목록을 보거나, 세부정보 페이지를 보거나, 항목을 검색할 수 있습니다. 이러한 각 작업에 대해 별도의 SLI를 개발하고 측정하는 대신 단일 SLI 카테고리(예: 서비스 탐색)로 결합할 수 있습니다.

실제로 고객의 기대는 유사한 카테고리의 작업 간에 크게 달라지지 않습니다. 고객의 만족도는 데이터가 프로모션 항목의 정적 목록에서 파생되는지 또는 대규모 데이터 세트에서 머신러닝 지원 검색의 동적 생성 결과인지의 여부와 관계없이 탐색 중인 데이터의 구조에 의존하지 않습니다. 고객 만족도는 '항목의 전체 페이지를 빠르게 보았나요?'라는 질문에 대한 답을 통해 수치화할 수 있습니다.

특정 서비스의 허용 범위를 정확하게 나타내기 위해 가능한 한 적은 수의 SLI를 사용하는 것이 좋습니다. 일반적으로 서비스에는 2~6개의 SLI가 있어야 합니다. SLI가 너무 적으면 중요한 신호를 놓칠 수 있습니다. SLI가 너무 많으면 대기하는 팀에서 한계 추가 유틸리티만으로 추적할 양이 너무 많아집니다. SLI는 프로덕션 상태에 대한 이해를 간소화하고 범위를 제공해야 합니다.

SLO 선택

SLO는 다음 값으로 구성됩니다.

  • SLI. 예를 들어 HTTP 코드 200이 있는 응답 수와 총 응답 수의 비율입니다.
  • 기간. 측정항목이 측정된 기간입니다. 이 기간은 캘린더 기반(예: 한 달의 첫째 날과 다음 달의 첫째 날) 또는 순환 기간(예: 지난 30일)입니다.
  • 목표. 예를 들어 특정 기간에 충족될 것으로 예상되는 총 이벤트 대비 적합한 이벤트의 목표 비율(예: 99.9%)입니다.

SLO를 개발할 때는 기간과 목표를 정의하기 어려울 수 있습니다. 프로세스를 시작하는 한 가지 방법은 SLI를 식별하고 시간에 따라 차트를 작성하는 것입니다. 사용할 기간 및 목표를 결정할 수 없다면 SLO가 처음부터 완벽하지 않아도 된다는 점을 기억하세요. 고객의 만족도와 일치시키고 비즈니스 니즈를 충족하도록 SLO를 반복할 가능성이 있습니다. 먼저 한 달에 2개의 9(99.0%)로 시작해보세요.

배포, 중단, 일일 트래픽 패턴 같은 이벤트 중에 SLO 규정 준수를 추적하면 어떤 목표가 적절한지, 부적절한지, 무난한지에 대한 정보를 얻을 수 있습니다. 예를 들어 백그라운드 프로세스에서는 75% 성공을 적절하다고 정의할 수 있습니다. 하지만 사용자에게 표시되는 중요 작업의 경우 99.95%와 같이 더 엄격한 목표를 정할 수 있습니다.

물론 모든 사용 사례에 적용할 수 있는 단일 SLO는 없습니다. SLO는 다음과 같은 몇 가지 요인에 따라 달라집니다.

  • 고객 기대치
  • 워크로드 유형
  • 제공, 실행, 모니터링을 위한 인프라
  • 문제 도메인

이 시리즈의 2부인 SLO 채택에서는 도메인 독립적 SLO을 주로 다룹니다. 도메인 독립적 SLO(예: 서비스 가용성)는 높은 수준의 지표(예: 분당 판매되는 위젯)를 대체하지는 않습니다. 그러나 비즈니스 사용 사례와 관계없이 서비스가 작동하는지 여부를 확인하는 데 도움이 될 수 있습니다.

도메인 독립적 표시기는 질문과 답변을 주기도 합니다(예: '서비스를 사용할 수 있나요?' 또는 '서비스 속도가 충분히 빠른가요?'). 그 답은 가용성 및 지연 시간이라는 두 가지 요소를 고려하는 SLO에서 가장 많이 발견됩니다. 다음 용어로 SLO를 기술할 수 있습니다. 여기서 X = 99.9%이고 Y = 800ms입니다.

유효한 요청의 X%가 성공적이며 Yms보다 빠르게 성공합니다.

다음 단계