Rails request SLIs (service level indicators)

GitLab 14.4에서 도입됨

이 SLI는 서비스 모니터링에 사용됩니다. 그러나 기본적으로 단계 그룹의 오류 예산에는 사용되지 않습니다.

요청 Apdex SLI 및 오류율 SLI는 응용 프로그램에서 정의된 SLI입니다.

요청 Apdex는 성공한 요청의 기간을 메트릭하여 응용 프로그램 성능의 지표로 삼습니다. 이는 REST 및 GraphQL API 및 일반 컨트롤러 엔드포인트를 포함합니다.

오류율은 서버의 잘못된 작동을 파악하기 위해 실패한 요청을 메트릭합니다. 이는 REST API 및 일반 컨트롤러 엔드포인트를 포함합니다.

gitlab_sli_rails_request_apdex_total: 모든 5xx 상태 코드로 응답되지 않은 요청마다 증가합니다. 느린 실패가 두 번 계산되지 않도록하며, 해당 요청은 이미 오류 SLI에 계산되어 있습니다.
gitlab_sli_rails_request_apdex_success_total: 지정된 대상 기간보다 빨리 실행된 모든 성공한 요청마다 증가합니다. (참조: #adjusting-request-urgency)
gitlab_sli_rails_request_error_total: 5xx 상태 코드로 응답된 모든 요청마다 증가합니다.
gitlab_sli_rails_request_total: 모든 요청마다 증가합니다.

이러한 카운터에는 다음이 포함되어 있습니다:

endpoint_id: Rails 컨트롤러 또는 Grape-API 엔드포인트의 식별자
feature_category: 해당 컨트롤러 또는 API 엔드포인트에 지정된 기능 범주

요청 Apdex SLO

이러한 카운터를 결합하여 성공 비율로 사용할 수 있습니다. SLO를 충족시키기 위해 기록된 비율은 다음보다 높아야합니다:

예를 들어, 웹 서비스의 경우, 요청 중 적어도 99.8%가 대상 기간보다 빠르기를 원합니다.

이러한 대상은 경보 및 서비스 모니터링에 사용됩니다. 경보를 발생시키지 않도록 대상을 고려하여 지속적으로 설정합니다. 그러나 목표는 사용자의 요구를 충족하는 대상을 설정하는 것입니다.

성공적인 메트릭과 그렇지 않은 메트릭은 단계 그룹의 오류 예산에 영향을 줍니다.

요청 긴급도 조정

모든 엔드포인트가 동일한 유형의 작업을 수행하는 것은 아니기 때문에, 각 엔드포인트에 대해 다른 긴급 수준을 정의하는 것이 가능합니다. 긴급성이 낮은 엔드포인트는 긴급성이 높은 엔드포인트보다 더 오래 실행될 수 있습니다.

긴 실행 요청은 인프라에 대해 더 비용이 많이든다. 하나의 요청을 처리하는 동안 스레드는 그 요청의 기간 동안 점유되어 있습니다. 스레드는 다른 작업을 처리할 수 없습니다. 루비의 글로벌 VM 락으로 인해 스레드는 락을 유지하고 동일한 Puma 워커 프로세스에서 처리되는 다른 요청들에 대해 정체될 수 있습니다. 사실상 해당 요청은 워커에서 처리되는 다른 요청에 대한 소음 형태입니다. 이러한 이유로 대상 기간의 상한선을 5초로 설정합니다.

긴급성을 줄이려면 (대상 기간을 더 높게 설정하려면)

기존 엔드포인트에서 긴급성을 경우에 따라 감소시킬 수 있습니다. 다음 사항을 고려합니다:

Apdex는 지각된 성능에 관한 것입니다. 사용자가 요청 결과를 기다리고 있다면, 5초를 기다리는 것은 허용할 수 없을 것입니다. 그러나 엔드포인트가 많은 데이터가 필요한 자동화에 의해 사용되는 경우, 5초가 적합할 수 있습니다.
제품 매니저는 엔드포인트가 어떻게 사용되는지 확인하는 데 도움을 줄 수 있습니다.
일부 엔드포인트의 워크로드는 호출자가 지정한 매개변수에 따라 크게 달라질 수 있습니다. 긴급성은 이러한 차이에 맞추어야합니다. 경우에 따라 엔드포인트가 no-ops로 전환되면 엔드포인트가 작업을 수행할 경우 대상을 여전히 수용할 수 있도록 대상을 선택해야합니다.
엔드포인트에서 사용되는 종속 리소스를 고려해야합니다. 엔드포인트가 Gitaly 또는 데이터베이스에서 많은 데이터를 로드하고 이로 인해 성능이 불만족스러울 경우 대상 기간을 높이는 대신 데이터로드 방법을 최적화할 것을 고려해야합니다.
이러한 경우에 엔드포인트가 SLO를 충족하도록 대상 기간을 일시적으로 줄이는 것이 적절할 수 있으며, 이 경우 인프라가 견딜 수 있는 경우입니다. 이러한 경우에는 문제에 링크하는 코드 주석을 달아야합니다.
엔드포인트가 많은 CPU 시간을 요구하는 경우에도 고려해야합니다: 이러한 종류의 요청은 우리가 가능한 매우 짧게 유지하려고 노력해야할 소음 형태입니다.
교통 특성도 고려해야합니다. 엔드포인트로의 교통이 때때로 CI 트래픽이 엔드포인트에 도달하는 일괄 처리를 초기화하여 유입되는 일괄 작업이있는 경우, 이러한 엔드포인트가 다섯 초 동안 수행되는 것은 인프라적으로 허용할 수 없습니다. 우리는 일반 교통과 함께 들어오는 느린 요청을 수용하기 위해 충분히 빠르게 플릿을 확장할 수 없습니다.

엔드포인트의 긴급성을 낮추려면 확장 가능성 팀 구성원을 검토에 참여시켜야합니다. 로그에 기록된 요청률과 기간을 사용하여 권장 사항을 도출할 수 있습니다. 서비스를 위한 SLO보다 높은 기간을 설정하는 프로세스와 동일한 프로세스를 사용하여 임계 값을 선택할 수 있습니다.

우리는 엔드포인트에서 가장 긴 기간을 설정해서는 안되며, 그 이유는 아직 결정을 지원할 데이터가 없기 때문입니다.

긴급성 증가(낮은 대상 지속 시간 설정)

긴급성을 높일 때에는 요청을 처리하는 플리트의 SLO를 여전히 충족하는지 확인해야 합니다. 로그에서 제공되는 정보를 사용하여 확인할 수 있습니다:

키바나의 이 테이블을 엽니다.
해당 테이블은 기본적으로 가장 바쁜 엔드포인트에 대한 정보를 로드합니다. 응답 속도를 높이려면 다음을 추가합니다:
- json.meta.caller_id.keyword에 대한 필터
- 원하는 식별자, 예를 들어:
```
Projects::RawController#show
```
  또는:
```
GET /api/:version/projects/:id/snippets/:snippet_id/raw
```
엔드포인트를 처리하는 서비스에 대한 적절한 백분위 수 지속 시간을 확인합니다. 전체 지속 시간은 의도한 대상보다 낮아야 합니다.
전체 지속 시간이 의도한 대상보다 낮은 경우, 키바나의 이 그래프에서 시간당 피크를 확인합니다. 여기서 해당 백분위 수는 설정하려는 대상 지속 시간을 넘어서서는 안 됩니다.

임계값을 너무 많이 줄이면 Apdex 저하에 대한 경보가 발생할 수 있으므로 Merge Request에 Scalability 팀 구성원을 참여시키세요.

긴급성 조정 방법

엔드포인트가 특정 대상을 사용하지 않는 경우 기본적으로 긴급성이 1초로 설정됩니다. 다음과 같은 구성이 가능합니다:

긴급성	초 단위 지속 시간	비고
`:high`	0.25초
`:medium`	0.5초
`:default`	1초	아무것도 지정되지 않았을 때 기본값으로 사용됨.
`:low`	5초

Rails 컨트롤러

컨트롤러의 모든 액션에 대해 긴급성을 지정할 수 있습니다:

class Boards::ListsController < ApplicationController
  urgency :high
end

또한 컨트롤러의 특정 액션에 대해 긴급성을 지정할 수도 있습니다:

class Boards::ListsController < ApplicationController
  urgency :high, [:index, :show]
end

컨트롤러 스펙에서 엔드포인트의 요청 긴급성을 확인하기 위한 사용자 정의 RSpec matcher도 제공됩니다:

specify do
   expect(get(:index, params: request_params)).to have_request_urgency(:medium)
end

Grape 엔드포인트

전체 API 클래스에 대해 긴급성을 지정할 수 있습니다:

module API
  class Issues < ::API::Base
    urgency :low
  end
end

또한 특정 액션에 대해 긴급성을 지정할 수도 있습니다:

module API
  class Issues < ::API::Base
      urgency :medium, [
        '/groups/:id/issues',
        '/groups/:id/issues_statistics'
      ]
  end
end

또는 엔드포인트별로 긴급성을 지정할 수도 있습니다:

get 'client/features', urgency: :low do
  # 엔드포인트 로직
end

사용자 정의 RSpec matcher는 grape 엔드포인트 스펙과도 호환됩니다:

specify do
   expect(get(api('/avatar'), params: { email: 'public@example.com' })).to have_request_urgency(:medium)
end

네임스페이스 수준에서 긴급성을 지정할 수 없습니다. 이렇게 하면 지시문이 무시됩니다.

오류 예산 속성 및 소유권

이 SLI는 서비스 수준 모니터링에 사용됩니다. 이것은 단계 그룹에 대한 오류 예산에 공급됩니다.

자세한 정보는 사용자 정의 SLI 정의 및 오류 예산에 편입되는 에픽을 읽어보세요. SLI의 엔드포인트는 이 특성 카테고리에 선언된 것에 따라 그룹의 오류 예산에 공급됩니다.

귀하의 그룹에 포함된 엔드포인트를 확인하려면, 귀하는 귀하의 그룹 대시보드에서 요청률을 볼 수 있습니다. 예산 소속 행에서 Puma Apdex 로그 링크를 통해 1초 또는 5초 타겟을 충족하지 못하는 요청이 얼마나 있는지 확인할 수 있습니다.

대시보드 내용에 대한 자세한 정보는 단계 그룹 대시보드를 참조하십시오. 오류 예산 자체에 대한 자세한 정보는 이슈 1365를 참조하십시오.

Rails request SLIs (service level indicators)

요청 Apdex SLO

요청 긴급도 조정

긴급성 증가(낮은 대상 지속 시간 설정)

긴급성 조정 방법

Rails 컨트롤러

Grape 엔드포인트

오류 예산 속성 및 소유권

도움말

기능 사용 가능성과 제품 평가판

도움받기