개요

이 섹션에서는 서비스 수준 지표(SLI) 개념을 검토하고 좋거나 유용한 SLI를 만드는 항목을 정의하고 선택한 서비스의 SLI 구현 예시를 제공합니다. 이 페이지는 서비스별 SLI를 구현하는 예시가 필요한 사용자를 대상으로 합니다.

SLI 소개

서비스 안정성은 추상적인 개념입니다. 안정성은 서비스 및 사용자 니즈에 따라 다릅니다. 서비스 수준 지표(SLI)는 서비스 안전성을 이해하고 서비스에 대한 결정을 내리는 데 사용되는 안정성의 척도입니다.

SLI는 기간을 통해 측정됩니다. 일반적으로 기간 크기는 정보가 사용되고 있는지 여부에 따라 다릅니다. 예를 들어 다음과 같은 방법으로 단일 SLI를 측정할 수 있습니다.

  • 최근 1시간 동안 알림 정책 생성
  • 몇 주간 전술적 결정 내림
  • 몇 개월 동안 전략적 결정 내림

SLI를 측정하기 위한 시작점으로 28일을 권장합니다. 이 값은 전략적 사용 사례와 전술적 사용 사례 사이에 적절한 균형을 유지합니다.

자세한 내용은 사이트 안정성 엔지니어링 통합문서의 다음 장을 참조하세요.

양호한 SLI의 속성

'양호한' SLI는 다음 기준을 충족하는 것으로 간주합니다.

  • SLI는 사용자 만족을 위한 양호한 프록시 측정입니다.

    양호한 SLI는 사용자 만족과 밀접한 상관 관계를 유지합니다. SLI를 SLI에 설정한 임곗값인 서비스 수준 목표(SLO) 기준으로 사용합니다. SLI가 정의된 범위에 있으면 대부분의 사용자가 만족할 수 있도록 SLO를 설정합니다. 이 관계를 유지하려면 SLI가 사용자 만족을 위한 양호한 프록시 척도가 되어야 합니다.

    SLI가 사용자 만족을 위한 양호한 프록시인 경우 사용자 만족에 영향을 미치는 이벤트가 발생하면 SLI는 일부 방향으로 변경됩니다. 마찬가지로 사용자 만족에 영향을 미치는 이벤트가 없으면 SLI는 변경되지 않습니다.

  • SLI는 사용자 만족을 통해 단조로우며 약 선형적으로 확장됩니다.

    양호한 SLI는 사용자 만족을 통해 단조로우며 약 선형적으로 확장됩니다. SLI가 개선되면 사용자 만족이 개선되며 그 반대의 경우도 마찬가지입니다. 양호한 SLI의 가치 개선 정도는 사용자 만족의 개선 정도에 해당합니다.

  • SLI는 0%~100% 범위 내에서 측정값을 생성합니다.

    양호한 SLI는 0%~100% 범위 내에서 성능 측정을 생성하며 이 범위는 직관적이며 사용하기 쉽습니다. 예를 들어 SLI 성능이 100%인 경우 이는 모든 것이 정상적으로 작동하고 있으며 SLI 성능이 0%인 경우 이는 아무 것도 작동하지 않고 있다는 의미입니다.

    SLI가 0%~100% 범위 내에 있으면 SLI에서 SLO를 간편하고 분명하게 설정할 수 있습니다. 99.9%와 같은 비율 목표를 할당하며 SLI 성능은 SLO가 충족되도록 서비스의 목표 이상하거나 이하가 되어야 합니다.

프라미스

이러한 속성이 있는 SLI를 구현하는 한 가지 방법은 사용자에게 제공되는 프라미스 측면에서 SLI를 고려하는 것입니다. 특정 기간 동안 만들고 유지한 프라미스를 계산하면 0%~100% 범위의 숫자를 도출할 수 있습니다. 이러한 SLI는 오류 예산으로도 변환됩니다. 특정 SLO의 경우 오류 예산은 특정 기간 동안 SLO를 여전히 충족하지만 유지할 수 없는 프라미스 수입니다.

프라미스 예시는 다음과 같습니다.

  • HTTP 200 상태 코드가 포함된 응답을 고객의 요청에 반환
  • 100ms 이내로 gRPC 요청에 응답
  • '가상 머신 만들기' 워크플로를 성공적으로 완료
  • 지난 10분 이내로 새로고침된 데이터 제공
  • 대상 시작 시간부터 1분 이내에 예약된 일괄 작업 실행 시작

프라미스는 HTTP 및 gRPC 예시와 같은 하위 수준이거나 워크플로 예시와 같은 상위 수준일 수 있습니다.

SLI 사양 및 구현

SLI 사양은 측정할 항목입니다. 사양에는 측정 방법에 대한 정확한 기술 세부정보가 포함되지 않습니다. 예를 들어 다음은 페이지 로드 시간의 SLI 사양입니다.

  • 100ms 이내로 로드되는 홈페이지 요청 비율

SLI를 측정하는 데 다양한 방법을 사용할 수 있지만 각각 장단점이 있습니다. SLI를 측정하는 방법은 SLI 구현입니다. 예를 들어 페이지 로드 사양을 다음 중 하나로 구현할 수 있습니다.

  • 애플리케이션 서버 요청 로그의 지연 시간 필드
  • 애플리케이션 서버에서 내보낸 측정항목
  • 애플리케이션 서버 앞에 있는 부하 분산기에서 내보낸 측정항목
  • 시스템에 인위적인 요청을 보내고 유효한 응답을 받는 데 걸리는 시간을 알려주는 블랙박스 모니터링 서비스
  • 고객의 브라우저에서 실행되고 타이밍 정보를 기록하고 수집 서비스에 다시 전송하는 애플리케이션별 코드

각 선택사항에는 다음 특성 간의 절충사항이 포함됩니다.

  • 품질: 사용자 환경을 얼마나 정확하게 포착하는지 보여줍니다.
  • 노출 범위: 사용자 상호작용을 측정한 비율입니다.
  • 비용: 솔루션을 빌드하고 유지보수하는 데 필요한 비용과 엔지니어링 시간의 양입니다.

사용자 환경에 대한 품질은 일반적으로 SLI가 사용자와 더 가깝게 측정되면 향상됩니다. 예를 들어 사용자의 브라우저에서 코드를 사용하는 구현으로 인해 다른 구현 선택사항에 비해 실제로 사용자가 인지한 지연 시간을 더욱 정확하게 측정할 수 있습니다.

하지만 브라우저 기반 측정에는 사용자의 서비스 연결로 인한 지연 시간도 포함됩니다. 공개 인터넷을 통해 사용되는 서비스의 경우 이 지연 시간이 지리적 위치나 네트워크 조건에 따라 크게 달라질 수 있습니다.

그 결과, 브라우저 기반 신호는 사용자 만족을 위한 적절한 프록시지만 이 신호는 서비스의 안정성을 개선하는 데 사용할 수 있는 조치 가능한 정보를 제공하지 않을 수 있습니다.

이러한 절충점 간의 균형을 맞추도록 여러 측정을 결합하는 방법에 대한 자세한 내용은 이 텔레그래프의 게시물을 참조하세요.

버케팅

서비스가 사용자에 따라 다른 종류의 작업을 수행하거나 서로 다른 결과를 사용하여 특정 태스크를 수행하는 경우 서비스에 여러 SLI가 필요할 수 있습니다.

다른 태스크

여러 SLI의 이점을 제공하는 서비스 유형 중 하나는 사용자 범주마다 여러 유형의 작업을 수행하고 각 유형의 작업이 사용자 만족에 잠재적으로 다른 영향을 미치는 서비스입니다.

예를 들어 서비스가 읽기 및 쓰기 요청을 모두 처리하는 경우 태스크를 수행하는 사용자는 다음과 같은 다른 요구사항을 가질 수 있습니다.

  • 읽기 요청이 빨라야 합니다.
  • 쓰기 요청이 성공해야 합니다.

이러한 다양한 요구사항을 캡처하려면 SLI에서 이러한 두 가지 사례를 구분할 수 있어야 합니다. 일반적으로 SLI 측정항목에는 여러 버킷 중 하나로 값을 분류하는 데 사용할 수 있는 라벨이 있습니다.

태스크 하나로 다른 결과 도출

여러 SLI의 이점을 제공하는 또 다른 유형의 서비스는 단일 유형의 작업을 수행하지만 응답에 따라 사용자 기대가 다른 서비스입니다.

예를 들어 서비스가 데이터에 대한 읽기 액세스만 제공하는 경우 사용자는 요청 결과에 따라 지연 시간에 다른 내결함성을 가질 수 있습니다.

  • 사용자는 요청을 즉시 재시도할 수 있으므로 빠르게 반환되는 오류에 대한 내결함성을 가질 수 있습니다.
  • 사용자는 오랜 시간이 걸리는 성공적인 요청에 대한 낮은 내결함성을 가질 수 있습니다.
  • 사용자는 요청에서 오류를 반환하는 데 오랜 시간이 걸리는 최악의 시나리오에 대한 최소 내결함성을 가집니다.

이 경우 지연 시간 SLI에서 성공한 요청과 실패한 요청을 구분할 수 있어야 합니다.

다음 단계

Google Cloud 측정항목을 사용하여 Google Cloud 서비스의 SLI를 구현하는 방법은 다음을 참조하세요.

애플리케이션별로 SLI를 구현하는 방법은 다음을 참조하세요.