SLO 측정

Last reviewed 2024-03-29 UTC

Google Cloud 아키텍처 프레임워크의 이 문서에서는 일반적인 서비스 워크로드와 관련하여 측정의 대상과 방법을 살펴보고 앞에서 설명한 서비스 수준 목표(SLO)를 바탕으로 합니다. 이 문서는 서비스 수준 목표의 구성요소에 정의된 개념을 기반으로 합니다.

측정 대상 결정

도메인에 관계없이 많은 서비스가 공통 기능을 공유하고 일반 SLO를 사용할 수 있습니다. 이 섹션에서는 여러 서비스 유형의 일반 SLO를 설명하고 각 SLO에 적용되는 SLI에 대해 자세히 설명합니다.

다음 각 하위 섹션은 특정 서비스 유형을 식별하고 해당 서비스에 대한 간단한 설명을 제공합니다. 그런 다음 각 서비스 유형 아래에 가능한 SLI, 표시기 정의, SLI와 관련된 기타 정보가 나열됩니다.

요청 기반 서비스

이 서비스 유형은 클라이언트(사용자 또는 다른 서비스)로부터 요청을 수신하고, 계산을 수행하고, 네트워크 요청을 백엔드로 보낸 후 클라이언트에게 응답을 반환합니다.

SLI로서의 가용성

가용성은 성공적으로 처리된 유효한 요청의 비율입니다. 다음 목록에는 가용성을 SLI로 사용할 때 고려해야 할 정보가 나와 있습니다.

  • 서비스 소유자는 유효한 요청이 무엇인지 결정합니다. 일반적인 정의에는 길이가 0이 아님 또는 클라이언트-서버 프로토콜을 준수하는 것이 포함됩니다. 유효성을 검사하는 한 가지 방법은 HTTP(또는 RPC) 응답 코드를 검토하는 것입니다. 예를 들어 HTTP 5xx 코드는 SLO에 합산되는 서버 관련 오류이고 4xx 코드는 계산되지 않는 클라이언트 오류입니다.
  • 서비스에서 반환하는 각 응답 코드를 검사하여 애플리케이션이 해당 코드를 원활하고 일관되게 사용하는지 확인해야 합니다. 코드가 사용자의 서비스 환경을 정확하게 나타낼 수 있나요? 예를 들어 사용자가 재고가 없는 상품을 주문하려고 할 때 전자상거래 사이트는 어떻게 응답해야 할까요? 요청이 실패하고 오류 메시지가 반환되나요? 사이트에서 유사한 제품을 제안하나요? 오류 코드는 사용자 예상과 연결되어야 합니다.
  • 개발자는 실수로 오류를 오용할 수 있습니다. 이전 글머리 기호의 재고 없음 시나리오를 사용할 경우 개발자가 실수로 오류를 반환할 수 있습니다. 하지만 시스템은 올바르게 작동하고 있으며 오류 상태가 아닙니다. 사용자가 상품을 구매할 수 없더라도 코드는 성공을 반환해야 합니다. 서비스 소유자에게는 재고 부족에 대한 알림이 전송되어야 하지만, 판매 불가능은 고객의 입장에서 오류가 아니므로 SLO로 포함되지 않습니다.
  • 보다 복잡한 서비스의 예로는 비동기식 요청을 처리하거나 고객을 위한 장기 실행 프로세스를 제공하는 서비스가 있습니다. 다른 방식으로 가용성을 노출할 수도 있지만 성공적인 유효한 요청의 비율로 가용성을 표현하는 것이 좋습니다. 가용성은 고객의 워크로드가 실행되는 시간(분)으로 정의될 수도 있습니다(양호 시간(분) 접근 방식이라고도 함).
  • 가상 머신(VM)을 제공하는 서비스를 가정해 보겠습니다. VM을 사용자에게 제공할 수 있도록 한 초기 요청 후 분 단위로 가용성을 측정할 수 있습니다.

SLI로서의 지연 시간

지연 시간(또는 속도)은 기준점보다 빠르게 처리되는 유효한 요청의 비율입니다. 따라서 지연 시간은 서비스 빠른 속도를 나타내며, 지정된 요청 유형에 대해 시작 및 중지 시간 차이를 계산하여 측정할 수 있습니다. 이는 지연 시간에 대한 사용자의 인식이며 서비스 소유자는 일반적으로 이 값을 지나치게 미세하게 측정합니다. 실제로 사용자는 100밀리초(ms)와 300밀리초(ms) 새로고침 사이의 응답을 구별할 수 없으며 300밀리초에서 1,000밀리초 사이의 응답도 수용할 수 있습니다. 자세한 내용은 레일 모델을 참조하세요.

사용자에게 초점을 맞추는 활동 중심 측정항목을 개발합니다. 다음은 이러한 측정항목의 몇 가지 예시입니다.

  • 대화형: 사용자가 요소를 클릭한 후 결과를 1,000ms 동안 기다립니다.
  • 쓰기: 기본 분산 시스템을 변경하는 데 1,500ms가 걸립니다. 이 시간은 느리다고 간주되지만 대부분 사용자는 수용합니다. 측정항목에서는 쓰기와 읽기를 명시적으로 구분하는 것이 좋습니다.
  • 백그라운드: 데이터의 정기적인 새로고침 또는 기타 비동기식 요청과 같이 사용자에게 표시되지 않는 작업은 완료하는 데 5,000ms 이하가 걸립니다.

지연 시간은 일반적으로 분포로 측정되며 SLI 선택에 설명된 대로 측정됩니다. 분포를 사용하여 다양한 백분위수를 측정할 수 있습니다. 예를 들어 이전 99번째 백분위수보다 느린 요청 수를 측정할 수 있습니다. 이 기준점보다 빠른 이벤트는 양호한 것으로 간주됩니다. 느린 요청은 좋지 않은 것으로 간주됩니다. 제품 요구사항에 따라 이 기준점을 설정합니다. 여러 지연 시간 SLO도 설정할 수도 있습니다(예: 일반적인 지연 시간과 꼬리 지연 시간 비교).

평균(또는 중앙값) 지연 시간만 SLI로 사용하지 마세요. 중앙값 지연 시간이 너무 느리면 사용자의 절반이 이미 불만족스러워한 것입니다. 또한 문제가 발견되기 전에 며칠 동안 서비스의 지연 시간이 잘못 발생할 수 있습니다. 따라서 꼬리 지연 시간(95번째 백분위수) 및 중앙값 지연 시간(50번째 백분위수)에 대한 SLO를 정의합니다.

ACM 문서 Metrics That Matter에서 벤자민 트레이너 슬로스는 다음과 같이 말합니다.

  • "제 경험칙에 따르면... 일반적으로 99번째 백분위수 지연 시간은 중앙값 지연 시간의 3~5배를 초과해서는 안 된다."
  • "서비스의 50번째, 95번째, 99번째 백분위수 지연 시간 측정값은 각각 개별적으로 가치가 있으며 각 값을 중심으로 SLO를 이상적으로 설정할 것이다."

이전 백분위수를 기준으로 지연 시간 기준점을 결정한 다음 각 버킷에 속하는 요청 수를 측정합니다. 이 접근 방식을 따르는 것이 좋습니다.

SLI로서의 품질

품질은 서비스를 저하시키지 않고 제공된 유효한 요청의 비율입니다. 예를 들어 품질은 정상적으로 실패하도록 설계된 복잡한 서비스에 유용한 SLI입니다. 예를 들어 하나의 Datastore에서 기본 콘텐츠를 로드하고 100개의 다른 서비스와 Datastore에서 선택적 애셋을 로드하는 웹페이지를 가정해 보겠습니다. 선택적 요소 중 하나가 서비스가 중단되거나 너무 느린 경우 웹페이지는 여전히 선택적 요소 없이 렌더링됩니다. 이 시나리오에서는 SLI를 사용하여 다음을 수행할 수 있습니다.

  • 성능 저하된 응답(하나 이상의 백엔드 서비스에서 응답이 누락된 응답)을 측정하여 잘못된 요청의 비율을 보고할 수 있습니다.
  • 단일 백엔드 또는 여러 백엔드에서 응답이 누락된 응답 수를 추적할 수 있습니다.

데이터 처리 서비스

이러한 서비스는 입력에서 데이터를 사용하고 해당 데이터를 처리하며 출력을 생성합니다. 중간 단계의 서비스 성능은 최종 결과만큼 중요하지 않습니다. 가장 강력한 SLI는 최신 상태, 적용 범위, 정확성, 처리량입니다. 지연 시간과 가용성은 유용하지 않습니다.

SLI로서의 최신 상태

최신성은 기준점보다 최근에 업데이트된 유효한 데이터의 비율입니다. 다음 목록은 최신 상태를 SLI로 사용하는 몇 가지 예시를 제공합니다.

  • 일괄 시스템에서 최신 상태는 주어진 출력의 처리 실행이 성공적으로 완료되는 동안 경과된 시간으로 측정됩니다.
  • 실시간 처리 또는 더 복잡한 시스템에서 최신 상태는 파이프라인에서 처리된 가장 최근 레코드의 기간을 추적합니다.
  • 실시간으로 지도 타일을 생성하는 온라인 게임에서 사용자는 지도 타일이 얼마나 빨리 생성되는지는 알아차리지 못할 수 있지만, 지도 데이터가 누락되거나 최신 상태가 아닌 경우에는 알아차릴 수 있습니다. 이 경우 최신 상태는 누락되거나 오래된 데이터를 추적합니다.
  • 추적 시스템에서 레코드를 읽어 전자상거래 웹사이트의 '상품 재고 X개 있음' 메시지를 생성하는 서비스에서 새로고침 SLI는 다음에 (지난 1분간) 새로고침된 재고 정보를 반환합니다.
  • 또한 최신이 아닌 데이터를 제공하는 측정항목을 사용하여 품질 SLI 정보를 업데이트할 수도 있습니다.

SLI로서의 적용 범위

노출 범위는 성공적으로 처리된 유효한 데이터의 비율입니다.

적용 범위를 정의하려면 다음 단계를 따르세요.

  1. 입력을 유효한 것으로 수락할지 아니면 건너뛸지 결정합니다. 예를 들어 입력 레코드가 손상되었거나 길이가 0이며 처리될 수 없는 경우 이 레코드를 측정항목으로 간주할 수 있습니다.
  2. 유효한 레코드 수를 계산합니다. 이 수는 간단한 *count() *메서드를 수행할 수 있으며 총 레코드 수를 나타냅니다.
  3. 마지막으로 성공적으로 처리된 레코드 수를 계산하고 총 유효한 레코드 수와 비교합니다. 이 값은 적용 범위에 대한 SLI입니다.

SLI로서의 정확성

정확성은 올바른 출력을 생성한 유효한 데이터의 비율입니다. 정확성을 SLI로 사용할 때는 다음 사항을 고려하세요.

  • 경우에 따라 출력의 정확성을 확인하는 방법을 사용하여 출력 처리의 유효성을 검사합니다. 예를 들어 이미지를 회전하거나 색상을 지정하는 시스템은 0바이트 이미지나 길이 또는 너비가 0인 이미지를 생성해서는 안 됩니다. 이 검증 로직을 처리 로직 자체에서 분리하는 것이 중요합니다.
  • 정확성 SLI를 측정하는 한 가지 방법은 알려진 정상 테스트 입력 데이터를 사용하는 것입니다. 이 유형의 데이터는 알려진 올바른 출력을 생성하는 데이터입니다. 입력 데이터는 사용자 데이터를 나타내야 합니다.
  • 다른 경우에는 앞의 이미지 회전 예와 같이 출력에 대해 수학적 또는 논리적 검사를 사용할 수 있습니다.
  • 마지막으로 트랜잭션 전후 잔액의 차이를 확인하여 트랜잭션 유효성을 결정하는 결제 시스템을 생각해 보세요. 이 값이 트랜잭션 자체의 값과 일치하면 유효한 트랜잭션입니다.

SLI로서의 처리량

처리량은 데이터 처리 속도가 기준점보다 빠른 시간의 비율입니다. 처리량을 SLI로 사용할 때 고려해야 할 몇 가지 사항은 다음과 같습니다.

  • 데이터 처리 시스템의 처리량은 특정 작업에 대한 단일 지연 시간 측정보다 사용자 만족도에 더 크게 반영되는 경우가 많습니다. 각 입력의 크기가 크게 다른 경우 각 요소가 완료되는 데 걸리는 시간을 비교하는 것은 별 의미가 없을 수 있습니다(모든 작업이 허용 속도로 진행된 경우).
  • 초당 바이트 수는 데이터 세트의 크기에 관계없이 데이터를 처리하는 데 걸리는 작업량을 측정하는 일반적인 방법입니다. 하지만 처리 비용과 관련하여 대략 선형적으로 확장되는 측정항목은 모두 작동하게 됩니다.
  • 예상 처리 속도를 기준으로 데이터 처리 시스템의 파티션을 나누는 것이 좋습니다. 또는 우선순위가 높은 입력을 처리하고 낮은 우선순위 입력이 큐에 추가되도록 하는 서비스 품질 시스템을 구현합니다. 어느 쪽이든 이 섹션에 정의된 처리량을 측정하면 시스템이 SLO 내에서 작동하는지 확인할 수 있습니다.

예약된 실행 서비스

Kubernetes 크론 작업 같이 일정한 간격으로 작업을 수행해야 하는 서비스의 경우 편향 및 실행 기간을 측정하세요. 다음은 예약된 Kubernetes 크론 작업의 예시입니다.

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"

SLI로서의 편향

편향 - 예상 시작 시간의 허용 가능한 기간 안에 시작되는 실행 비율입니다. 편향을 사용할 때는 다음을 고려하세요.

  • 편향은 작업이 시작되도록 예약된 시점과 실제 시작 시간 사이의 시간 차이를 측정합니다. 앞의 Kubernetes 크론 작업 예시를 살펴보세요. 매시간 0분에 시작하도록 설정되었지만 매시간 3분 후에 시작된다면 편향은 3분입니다. 작업이 일찍 실행되면 음의 편향이 있는 것입니다.
  • 양호한 편향을 정의하는 해당 허용 범위를 사용하여 편향을 시간 경과에 따른 분포로 측정할 수 있습니다. SLI를 결정하려면 양호한 범위 내에 있는 실행 수를 비교합니다.

SLI로서의 실행 기간

실행 기간은 허용 가능한 기간 내에 완료되는 실행의 비율입니다. 다음은 실행 기간 사용과 관련된 중요한 개념을 설명합니다.

  • 실행 기간은 작업이 완료되는 데 걸리는 시간입니다. 특정한 실행에서 일반적인 장애 모드는 실제 기간이 예약된 기간을 초과하는 경우입니다.
  • 흥미로운 경우는 이 SLI를 끝이 없는 작업에 적용하는 것입니다. 이러한 작업이 완료되지 않았으므로 작업이 완료될 때까지 기다리는 대신 특정 작업에 소요된 시간을 기록합니다. 이 방식은 최악의 시나리오에서도 작업 완료에 걸리는 시간에 대한 정확한 분포를 제공합니다.
  • 편향과 마찬가지로 실행 기간을 분포로 추적하고 적합한 이벤트에 대한 허용 상한 및 하한을 정의할 수 있습니다.

다른 시스템 유형의 측정항목

다른 많은 워크로드에는 SLI 및 SLO를 생성하기 위한 자체 측정항목이 있습니다. 다음 예를 고려하세요.

  • 스토리지 시스템: 내구성, 처리량, 첫 번째 바이트까지의 시간, blob 가용성
  • 미디어/동영상: 클라이언트 재생 지속성, 재생 시작 시간, 트랜스코딩 지연 실행 완료
  • 게임: 활성 플레이어 매칭 시간, 지도 생성 시간

측정 방법 결정

이전 섹션에서는 측정 항목을 다뤘습니다. 측정할 대상을 결정한 후에는 측정 방법을 결정할 수 있습니다. SLI 측정항목은 여러 방법으로 수집할 수 있습니다. 다음 섹션에서는 다양한 측정 방법을 식별하고, 메서드에 대한 간단한 설명을 제공하고, 메서드의 장단점을 나열하고, 메서드에 적합한 구현 도구를 설명합니다.

서버 측 로깅

서버 측 로깅 메서드에는 요청의 서버 측 로그 또는 처리된 데이터를 처리하는 과정이 포함됩니다.

서버 측 로깅 세부정보
장점
  • 기존 로그를 다시 처리하여 이전 SLI 레코드를 백필합니다.
  • 교차 서비스 세션 식별자를 사용하여 여러 서비스에서 복잡한 사용자 여정을 재구성합니다.
단점
  • 서버에 도달하지 않은 요청은 기록되지 않습니다.
  • 서버 충돌을 일으키는 요청은 기록되지 않습니다.
  • 로그를 처리하는 데 시간이 걸리면 SLI의 비활성 상태를 초래하여 운영 응답의 데이터가 불충분할 수 있습니다.
  • 로그 처리를 위한 코드를 작성하면 오류가 발생하기 쉽고 시간이 오래 걸릴 수 있습니다.
구현 방법 및 도구

애플리케이션 서버 측정항목

애플리케이션 서버 측정항목 방법에는 사용자 요청을 처리하거나 데이터를 처리하는 코드에서 SLI 측정항목을 내보내는 작업이 포함됩니다.

애플리케이션 서버 측정항목 세부정보
장점
  • 코드에 새 측정항목을 추가하는 것은 일반적으로 빠르고 저렴합니다.
단점
  • 애플리케이션 서버에 도달하지 않는 요청은 기록되지 않습니다.
  • 다중 서비스 요청은 추적하기 어려울 수 있습니다.
구현 방법 및 도구

프런트엔드 인프라 측정항목

프런트엔드 인프라 측정항목 메서드는 부하 분산 인프라(예: Google Cloud의 전역 레이어 7 부하 분산기)의 측정항목을 활용합니다.

프런트엔드 인프라 측정항목 세부정보
장점
  • 측정항목과 이전 데이터가 이미 존재하기 때문에 엔지니어링 작업을 줄일 수 있습니다.
  • 측정은 고객과 가장 가까우면서도 아직 서비스 인프라 내에 있는 지점에서 이루어집니다.
단점
  • 데이터 처리 SLI에는 사용할 수 없습니다.
  • 대략적인 다중 요청 사용자 여정만 가능합니다.
구현 방법 및 도구

합성 클라이언트 또는 데이터

합성 클라이언트 또는 데이터 메서드에는 조작된 요청을 일정한 간격으로 보내고 응답을 검사하는 클라이언트를 사용합니다.

합성 클라이언트 또는 데이터 세부정보
장점
  • 다중 요청 사용자 여정의 모든 단계를 측정합니다.
  • 인프라 외부에서 요청을 보내면 SLI에서 더 많은 전체 요청 경로가 캡처됩니다.
단점
  • 합성 요청으로 사용자 환경을 추정하면 오해의 소지가 있을 수 있습니다 (거짓양성 또는 거짓음성).
  • 모든 특수한 사례를 처리하는 것이 어렵고 통합 테스트로 이어질 수 있습니다.
  • 높은 안정성 목표로 인해 정확한 측정을 위한 빈번한 프로브가 필요합니다.
  • 프로브 트래픽이 실제 트래픽을 분산시킬 수 있습니다.
구현 방법 및 도구

클라이언트 계측

클라이언트 계측 방법에는 사용자가 상호작용하는 클라이언트에 관측 기능을 추가하고 SLI를 추적하는 서비스 인프라에 이벤트를 다시 로깅하는 작업이 포함됩니다.

클라이언트 계측 세부정보
장점
  • 사용자 환경을 가장 정확하게 측정할 수 있습니다.
  • CDN 또는 결제 서비스 제공 업체와 같은 타사의 안정성을 수치화할 수 있습니다.
단점
  • 클라이언트 로그 수집 및 처리 지연 시간은 SLI가 운영 응답을 트리거하는 데 적합하지 않도록 합니다.
  • SLI 측정에는 잠재적으로 직접적인 제어를 할 수 없는 다양한 변수가 포함됩니다.
  • 클라이언트에 계측을 빌드하려면 많은 엔지니어링 작업이 필요합니다.
구현 방법 및 도구

측정 방법 선택

SLO를 측정할 대상과 방법을 결정했으면 다음 단계는 고객의 경험과 가장 가깝게 일치하는 측정 방법을 선택하는 것입니다. 최소한의 노력이 요구됩니다. 이를 위해 위 표에 나온 방법을 조합하여 사용해야 할 수도 있습니다. 다음은 시간이 지남에 따라 구현할 수 있는 권장되는 접근 방식을 큰 노력을 들여야 하는 순으로 나열한 것입니다.

  • 애플리케이션 서버 내보내기 및 인프라 측정항목 사용. 일반적으로 이러한 측정항목은 즉시 액세스할 수 있으며 값을 빠르게 제공합니다. 일부 APM 도구에는 기본 SLO 도구가 포함되어 있습니다.
  • 클라이언트 계측 사용. 기존 시스템에는 일반적으로 내장된 최종 사용자 클라이언트 계측이 없으므로 계측을 설정하려면 상당한 투자가 필요할 수 있습니다. 그러나 클라이언트 계측을 제공하는 APM 제품군 또는 프런트엔드 프레임워크를 사용하면 고객의 만족도에 대한 유용한 정보를 빠르게 얻을 수 있습니다.
  • 로그 처리 사용. 서버 내보내기 또는 클라이언트 계측(이전 글머리 기호)을 구현할 수 없지만 로그가 있는 경우 로그 처리가 가장 좋은 방법일 수 있습니다. 또 다른 방법은 내보내기와 로그 처리를 결합하는 것입니다. 내보내기를 일부 SLI (예: 즉각적인 가용성)의 즉각적인 소스로 사용하고 장기 신호(예: SLO 및 알림에서 설명한 느린 소진 알림)의 로그 처리를 사용합니다.
  • 합성 테스트 구현. 고객이 서비스를 사용하는 방법에 대한 기본 사항을 이해했으면 서비스를 테스트합니다. 예를 들어 정상 데이터와 함께 계정을 테스트하고 질의할 수 있습니다. 이 접근 방식은 트래픽이 적은 서비스와 같이 쉽게 관찰되지 않는 장애 모드를 강조표시하는 데 도움이 될 수 있습니다.

다음 단계