Rails 요청 SLI(서비스 수준 지표)

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

요청 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: 이 카운터는 엔드포인트의 긴급성에 따라 정의된 대상 지속 시간보다 빨리 수행된 모든 성공한 요청에 대해 증가합니다.
gitlab_sli_rails_request_error_total: 이 카운터는 5xx 상태 코드로 응답된 모든 요청에 대해 증가합니다.
gitlab_sli_rails_request_total: 이 카운터는 모든 요청에 대해 증가합니다.

이러한 카운터에는 다음의 라벨이 지정됩니다:

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

요청 Apdex SLO(Service Level Objective)

이러한 카운터는 성공 비율로 결합될 수 있습니다. 이 비율의 목표는 서비스 카달로그에서 서비스당 정의됩니다. 이 SLI가 SLO를 충족하려면 기록된 비율이 다음보다 높아야 합니다:

예를 들어, 웹 서비스의 경우, 요청의 최소 99.8%가 대상 지속 시간보다 빠르기를 원합니다.

우리는 이러한 목표를 경보 및 서비스 모니터링에 사용합니다. 이러한 목표를 고려하여 경보를 발생시키지 않도록 설정함으로써 우리의 사용자를 만족시키는 대상을 설정합니다.

성공적인 메트릭과 실패한 메트릭 둘 다 stage 그룹의 오류 예산에 영향을 줍니다.

요청 긴급성 조정

모든 엔드포인트가 동일한 유형의 작업을 수행하는 것은 아니기 때문에 다른 엔드포인트에 대해 서로 다른 긴급성 수준을 정의할 수 있습니다. 낮은 긴급성을 가진 엔드포인트는 높은 긴급성을 가진 엔드포인트보다 오랜 요청 지속 시간이 가능합니다.

장시간 실행되는 요청은 우리의 인프라에 더 비용이 많이 듭니다. 한 요청을 처리하는 동안 스레드는 해당 요청의 지속 시간 동안 계속 점유됩니다. 스레드는 다른 것을 처리할 수 없습니다. 루비의 GVL(Global VM Lock)로 인해 스레드는 잠금을 유지하고 동일한 Puma worker 프로세스가 처리하는 다른 요청에 대기할 수 있습니다. 사실 요청은 worker가 처리하는 다른 요청에게 소음을 일으킵니다. 이러한 이유로 대상 지속 시간의 상한선을 5초로 제한합니다.

긴급성을 낮추는 경우, 확장성 팀 구성원을 검토에 참여시킵니다. 권장 사항을 도출하기 위해 로그에서 사용할 수 있는 요청률 및 지속시간을 사용할 수 있습니다. 서비스에 대한 SLO를 위해 기간을 선택하는 과정은 긴급성을 높이는 경우와 동일한 프로세스를 사용합니다.

새로운 엔드포인트에 가장 긴 지속 시간을 설정하지 않도록 주의해야 합니다. 왜냐하면 아직이 결정을 지원하는 데이터가 없기 때문입니다.

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

긴급성을 높이는 경우, 엔드포인트가 요청을 처리하는 플릿에 대해 여전히 SLO를 충족하는지 확인해야 합니다. 다음의 정보를 확인할 수 있습니다:

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

임계값을 너무 많이 낮추면 Apdex 저하에 대한 경보가 발생할 수 있으므로, MR에 확장성 팀 구성원을 참여시킵니다.

긴급도 조절 방법

여기서는 기능 범주 가져오기와 유사하게 긴급도를 지정할 수 있습니다. 목표 지정 없이 엔드포인트를 사용하는 경우 기본 긴급도(1초 지속)가 사용됩니다. 이러한 구성이 가능합니다.

긴급도	초 단위 지속 시간	비고
`:높음`	0.25초
`:중간`	0.5초
`:기본`	1초	아무것도 지정하지 않았을 때의 기본 옵션.
`:낮음`	5초

Rails 컨트롤러

컨트롤러의 모든 액션에 대해 긴급도를 지정할 수 있습니다.

class Boards::ListsController < ApplicationController
  urgency :높음
end

특정 액션에 대해 긴급도를 지정하려면 다음과 같이 합니다.

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

컨트롤러 스펙에서 엔드포인트의 요청 긴급도를 확인하기 위한 사용자 지정 RSpec 매처가 있습니다.

지정 do
   expect(get(:index, params: request_params)).to have_request_urgency(:중간)
end

Grape 엔드포인트

전체 API 클래스에 대해 긴급도를 지정하려면 다음과 같이 합니다.

module API
  class Issues < ::API::Base
    urgency :낮음
  end
end

또한 API 클래스의 특정 액션에 대해 긴급도를 지정할 수도 있습니다.

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

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

get 'client/features', urgency: :낮음 do
  # 엔드포인트 논리
end

그레이프 엔드포인트 스펙에서도 사용자 지정 RSpec 매처를 사용할 수 있습니다.

지정 do
   expect(get(api('/avatar'), params: { email: 'public@example.com' })).to have_request_urgency(:중간)
end

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

오류 예산 지정 및 소유권

이 SLI는 서비스 수준 모니터링에 사용됩니다. 이는 단계 그룹의 오류 예산으로 들어갑니다.

그룹별로 엔드포인트의 SLI에 어떤 것이 포함되어 있는지 알아보려면 group dashboard for your group. 의 Budget Attribution 행에서 Puma Apdex 로그 링크를 통해 1초 또는 5초 타깃을 충족하지 못하는 요청 수를 확인할 수 있습니다.

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

Rails 요청 SLI(서비스 수준 지표)

요청 Apdex SLO(Service Level Objective)

요청 긴급성 조정

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

긴급도 조절 방법

Rails 컨트롤러

Grape 엔드포인트

오류 예산 지정 및 소유권

도움말

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

도움받기