서비스 수준 목표(SLO) 선택

Last reviewed 2024-03-29 UTC

Google Cloud 아키텍처 프레임워크의 이 문서에서는 사용자 환경에서 안정성을 정의하는 방법과 해당 안정성 수준을 충족하는 적절한 서비스 수준 목표를 선택하는 방법을 정의합니다. 이 문서는 SLO 구성요소에 정의된 개념을 기반으로 합니다.

사이트 안정성 엔지니어링(SRE) 문화는 안정적인 서비스와 고객 만족(또는 고객 만족도)에 중요한 가치를 둡니다. 정의된 서비스 수준과 측정항목 수집 방법이 없으면 개선을 위해 어디에, 얼마를 투자해야 할지 파악하기가 어렵거나 불가능할 수 있습니다.

서비스 수준을 측정하는 데 우선 사용되는 측정항목은 서비스 수준 목표(SLO)입니다. SLO는 다음 값으로 구성됩니다.

  • 서비스 수준 지표(SLI): SLI 선택에 설명된 대로 서비스의 특정 측면에 대한 측정항목입니다.
  • 기간: SLI가 측정된 기간입니다. 캘린더 기반 또는 순환 기간일 수 있습니다.
  • 목표: 정상 서비스에서 지정된 기간 동안 SLI가 충족해야 하는 값(또는 값 범위)입니다. 예를 들어 서비스가 충족할 것으로 예상되는 총 이벤트 대비 적합한 이벤트의 비율입니다(예: 99.9%).

프로세스로는 서비스에 적합한 SLO를 선택하는 것이 있습니다. 먼저 안정성을 정의하고 궁극적으로 SLO를 정의하는 사용자 경험을 정의합니다. 선택한 SLO는 전체 시스템을 측정하면서 기능 개발 요구사항과 운영 안정성의 균형을 맞춰야 합니다. SLO를 선택한 후에는 반복적으로 개선하고 오류 예산을 사용하여 관리해야 합니다.

사용자 경험 정의

SLI와 SLO는 중요한 사용자 여정(CUJ)을 기반으로 하는 것이 이상적입니다. CUJ는 사용자 목표를 고려하고 사용자가 서비스를 통해 이러한 목표를 달성하는 방법을 고려합니다. 서비스 경계를 고려하지 않고 CUJ를 정의합니다. CUJ가 충족되면 고객이 만족하게 되고 이는 성공적인 서비스임을 나타냅니다.

고객 만족 또는 해당 사안에 대한 불만족은 안정성을 결정하며 모든 서비스의 가장 중요한 기능입니다.

따라서 대부분의 사용자가 서비스에 만족할 정도로만 SLO를 설정하고 그 이상으로는 설정하지 마십시오. 100% 가용성이 올바른 목표가 아닌 것처럼 SLO에 '9'를 더 추가하는 것은 크게 비용이 증가하고 고객에게는 중요하지 않을 수 있습니다.

업타임 및 기타 중요한 측정항목의 경우 목표를 100% 미만이되 100%에 가깝게 설정합니다. 필요한 최소 수준의 서비스 성능 및 가용성을 평가합니다. 외부 계약 수준에 따라 목표를 설정하지 마세요.

CUJ를 사용하여 SLO 개발

회사에서 가장 중요한 CUJ를 선택하고 다음 단계에 따라 SLO를 개발합니다.

  1. SLI 사양을 선택합니다(예: 가용성 또는 최신 상태).
  2. SLI 사양을 구현하는 방법을 정의합니다.
  3. 계획에 모든 CUJ가 포함되어 있는지 확인합니다.
  4. 이전 성능 또는 비즈니스 요구사항에 따라 SLO를 설정합니다.

CUJ는 단일 서비스나 단일 개발팀 또는 조직으로 제한되지 않아야 합니다. 서비스가 수십 개 이상의 다른 서비스에 종속될 수 있습니다. 또한 이러한 서비스가 99.5% 작동하기를 바랄 수도 있습니다. 그러나 엔드 투 엔드(전체 시스템) 성능이 추적되지 않으면 안정적인 서비스를 실행하기가 어렵습니다.

목표 및 기간 정의

목표 및 기간(SLO의 이전 정의 참조)을 정의하기 어려울 수 있습니다. 프로세스를 시작하는 한 가지 방법은 SLI를 식별하고 시간에 따라 차트를 작성하는 것입니다. SLO가 처음부터 완벽할 필요는 없습니다. SLO를 반복하여 고객의 만족도와 일치시키고 비즈니스 니즈를 충족하는지 확인합니다.

배포, 중단, 일일 트래픽 패턴 같은 이벤트 중에 SLO 규정 준수를 추적하면 목표에 대한 유용한 정보를 얻을 수 있습니다. 이러한 통계를 통해 목표 및 기간 동안 무엇이 좋고, 나쁘거나, 용인할 수 있는지를 더 명확히 파악할 수 있습니다.

기능 개발, 코드 개선, 하드웨어 업그레이드, 기타 유지보수 작업을 통해 서비스의 안정성을 높일 수 있습니다. 이렇게 빈번하게 조금씩 변경할 수 있는 기능을 통해 더 빠르고 더 나은 품질을 제공할 수 있습니다. 하지만 서비스 변경 속도가 안정성에 영향을 미칩니다. 달성 가능한 안정성 목표는 고객이 허용하고 활용할 수 있는 변경 속도와 범위(기능 개발 속도라고 함)를 정의합니다.

고객 경험을 측정하고 측정 결과에 따라 목표를 정의할 수 없는 경우 외부 소스 및 벤치마크 분석을 수행할 수 있습니다. 비교 가능한 벤치마크가 없다면 목표를 아직 정의할 수 없더라도 고객 경험을 측정합니다. 시간이 지남에 따라 고객 만족도의 합리적인 기준에 도달할 수 있습니다. 그 기준은 SLO입니다.

전체 시스템 이해

서비스는 업스트림 및 다운스트림 처리를 모두 지원하는 긴 일련의 서비스로 존재할 수 있습니다. 단편적으로(서비스 단위로) 분산 시스템의 성능을 측정하는 것은 고객의 경험을 정확하게 반영하지 않으며 과도하게 해석될 수 있습니다.

그 대신에 프로세스의 프런트엔드에서 SLO를 기준으로 성능을 측정하여 사용자 환경을 파악해야 합니다. 사용자는 쿼리가 자동으로 성공적으로 재시도되면 쿼리가 실패하도록 하는 구성요소 오류에 대해 걱정하지 않습니다.

공유된 내부 서비스가 있는 경우 각 서비스는 연결된 SLO에 대해 성능을 개별적으로 측정할 수 있으며, 사용자 대상 서비스가 고객 역할을 합니다. 이러한 SLO는 별도로 처리합니다.

스마트 재시도, 캐싱, 큐에 추가 등의 복원력 요소를 활용하여 가용성이 낮은 서비스(예: 99.9%) 위에 가용성이 높은 서비스(예: 99.99%)를 구축할 수 있습니다. 통계에 대한 실무 지식이 있는 사용자라면 누구든지 Conway의 법에 설명된 대로 기본 서비스 또는 조직 레이아웃을 이해하지 않고도 SLO를 읽고 이해할 수 있어야 합니다.

올바른 SLO 선택

제품 개발 속도와 운영 안정성 사이에서 자연스럽게 갈등하게 됩니다. 시스템을 많이 변경할수록 시스템이 중단될 가능성이 커집니다. 모니터링 및 관측 도구는 기능 속도를 높일 때 운영 안정성에 매우 중요합니다. 이러한 도구를 애플리케이션 성능 관리(APM) 도구라고 하며 SLO를 설정하는 데도 사용할 수 있습니다.

SLO를 올바르게 정의하면 팀은 안정성 저하 없이도 개발 속도를 높이는 데이터 기반의 운영 결정을 내릴 수 있습니다. 또한 SLO는 합의된 단일 목표에 따라 개발팀과 운영팀을 조율할 수 있습니다. 단일 목표를 공유하면 제품을 만들고 반복하는 개발팀의 목표와 시스템 무결성 유지를 위한 운영팀의 목표라는 앞에서 언급한 자연스러운 갈등이 완화됩니다.

이 문서와 아키텍처 프레임워크의 기타 안정성 문서를 사용하여 SLO를 이해하고 개발합니다. 이러한 문서를 읽고 이해한 후에는 SRE 도서 및 SRE 통합문서에서 SLO(및 다른 SRE 관행)에 대한 더 자세한 정보로 넘어가세요.

엄격한 내부 SLO 사용

외부 SLA보다 엄격한 내부 SLO를 사용하는 것이 좋습니다. SLA 위반 시 재무 크레딧 또는 고객 환불을 요구하는 경우가 많으므로 재무에 영향을 미치기 전에 문제를 해결해야 합니다.

비난 없는 소급 프로세스 및 이슈 검토와 함께 더 엄격한 내부 SLO를 사용하는 것이 좋습니다. 자세한 내용은 아키텍처 센터 안정성 카테고리의 공동작업 이슈 관리 프로세스 빌드를 참조하세요.

SLO를 반복적으로 개선

SLO를 설정한 대로 계속 두어서는 안 됩니다. 분기별 또는 연 1회 이상 SLO를 주기적으로 다시 검토하여 SLO가 사용자 만족도를 정확하게 반영하고 서비스 중단과 상관관계가 있는지 확인합니다. 현재 비즈니스 요구사항과 새로운 중요한 사용자 여정을 충족하는지 확인합니다. 검토 후 필요에 따라 SLO를 수정하고 보강합니다.

오류 예산을 사용하여 개발 속도를 관리할 수 있습니다.

오류 예산은 특정 기간 동안 서비스의 안정성이 필요 이상인지 이하인지 여부를 표시합니다. 오류 예산은 30일 등의 일정 기간 동안 100% – SLO로 계산됩니다.

오류 예산에 남은 용량이 있으면 계속해서 개선 또는 새로운 기능을 빠르게 실행할 수 있습니다. 오류 예산이 거의 소진된 경우에는 서비스 변경을 줄이거나 중단하고 안정성 기능을 개선하기 위해 엔지니어링 리소스를 투입합니다.

Google Cloud Observability에는 SLO 및 오류 예산을 설정하는 데 필요한 노력이 최소화되도록 SLO 모니터링이 포함되어 있습니다. 운영 제품군에는 SLO를 수동으로 구성하는 데 도움이 되는 그래픽 사용자 인터페이스, SLO의 프로그래매틱 방식 설정을 위한 API, 오류 예산의 소진율을 추적하기 위한 기본 제공 대시보드가 포함됩니다. 자세한 내용은 SLO 만들기를 참조하세요.

SLO 권장사항 요약

  • 고객 중심의 SLI(예: 서비스 가용성 또는 지연 시간)를 정의하고 측정합니다.
  • 외부 SLA보다 엄격한 고객 중심 오류 예산을 정의합니다. 프로덕션 중단과 같은 위반의 결과를 포함합니다.
  • 지연 시간 SLI를 설정하여 가장 느린 응답을 감지하기 위한 이상점 값(예: 90번째 또는 99번째 백분위수)을 캡처합니다.
  • 1년에 1회 이상 SLO를 검토하고 사용자 만족도 및 서비스 중단과 상관관계가 높은지 확인합니다.

다음 단계