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밀리초 사이의 응답도 수용할 수 있습니다. 자세한 내용은 Rail 모델을 참조하세요.

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

  • 대화형: 사용자가 요소를 클릭한 후 결과를 기다리는 시간으로 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 및 알림에서 설명한 느린 소진 알림)의 로그 처리를 사용합니다.
  • 합성 테스트 구현. 고객이 서비스를 사용하는 방법에 대한 기본 사항을 이해했으면 서비스를 테스트합니다. 예를 들어 정상 데이터와 함께 계정을 테스트하고 질의할 수 있습니다. 이 접근 방식은 트래픽이 적은 서비스의 경우와 같이 쉽게 관찰할 수 없는 장애 모드를 강조표시하는 데 도움이 될 수 있습니다.

다음 단계