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

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

이러한 카운터는 다음 항목으로 레이블이 지정됩니다:

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

요청 Apdex SLO

이 카운터는 성공 비율로 결합할 수 있습니다. 이 비율의 목표는 서비스 카탈로그에 따라 서비스별로 정의됩니다. 이 SLI가 SLO를 충족하려면 기록된 비율이 다음보다 더 커야 합니다:

예를 들어: 웹 서비스의 경우, 요청의 최소 99.8%가 목표 지속 시간보다 빨라야 합니다.

우리는 이 목표를 경고 및 서비스 모니터링에 사용합니다. 경고를 유발하지 않도록 이러한 목표를 고려하여 지속 시간을 설정하십시오. 그러나 목표는 사용자에게 만족을 주는 목표로 긴급성을 설정하는 것입니다.

성공적인 측정과 실패한 측정 모두 단계 그룹의 오류 예산에 영향을 미칩니다.

요청 긴급성 조정

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

오랜 요청은 우리 인프라에 더 비쌉니다. 하나의 요청을 처리하는 동안 스레드는 요청 기간 동안 차지됩니다. 스레드는 다른 어떤 것도 처리할 수 없습니다. Ruby의 Global VM Lock으로 인해 스레드는 잠금을 유지하고 동일한 Puma 워커 프로세스가 처리 중인 다른 요청을 차단할 수 있습니다. 요청은 사실상 워커가 처리하는 다른 요청의 시끄러운 이웃입니다. 이러한 이유로 목표 지속 시간의 상한은 5초로 제한합니다.

긴급성 감소 (더 높은 목표 기간 설정)

기존 엔드포인트에 대한 긴급성을 특정 사례에 따라 감소시킬 수 있습니다. 다음 사항을 고려하세요:

Apdex는 인식된 성능에 관한 것입니다. 사용자가 요청 결과를 actively 기다리고 있다면, 5초 기다리는 것은 수용 가능하지 않을 수 있습니다. 그러나 엔드포인트가 많은 데이터를 요구하는 자동화에 의해 사용된다면, 5초가 수용 가능할 수 있습니다.

제품 관리자가 엔드포인트 사용 방식을 확인하는 데 도움을 줄 수 있습니다.
일부 엔드포인트의 작업량은 호출자가 지정한 매개변수에 따라 크게 달라질 수 있습니다. 긴급성은 이러한 차이를 수용해야 합니다. 어떤 경우에는 엔드포인트가 수행하는 작업에 대해 별도의 애플리케이션 SLI를 정의할 수 있습니다.

특정 경우에 엔드포인트가 no-op으로 바뀌어 매우 빨라진다면, 목표 설정 시 이러한 빠른 요청을 무시해야 합니다. 예를 들어, MergeRequests::DraftsController가 모든 병합 요청이 조회될 때마다 호출되지만, 거의 렌더링하지 않는다면, 우리는 여전히 작업을 수행하는 엔드포인트에 맞는 목표를 선택해야 합니다.
엔드포인트가 소비하는 종속 리소스를 고려하세요. 엔드포인트가 Gitaly나 데이터베이스에서 많은 데이터를 로드하고 이로 인해 불만족스러운 성능이 발생한다면, 긴급성을 낮추어 목표 기간을 늘리는 것보다는 데이터를 로드하는 방식을 최적화하는 것을 고려해야 합니다.

이러한 경우에는 인프라스트럭처에 견딜 수 있다면 엔드포인트가 SLO를 충족하도록 임시로 긴급성을 줄이는 것이 적절할 수 있습니다. 이러한 경우, 문제에 연결된 코드 주석을 작성하세요.

만약 엔드포인트가 많은 CPU 시간을 소비한다면, 이러한 요청이 가능한 짧게 유지해야 할 소음 이웃의 일종임을 고려해야 합니다.
트래픽 특성도 고려해야 합니다. 엔드포인트로의 트래픽이 CI 트래픽처럼 한 번에 많은 작업을 처리할 경우, 이러한 엔드포인트가 5초를 소요하는 것은 인프라 측면에서 용납할 수 없습니다. 정규 트래픽과 함께 느린 요청을 수용할 수 있도록 플릿을 빠르게 확장할 수 없습니다.

기존 엔드포인트의 긴급성을 낮출 때는 스케일러빌리티 팀 구성원을 검토에 포함하세요. 우리는 로그에 있는 요청 비율과 기간을 사용하여 권장 사항을 도출할 수 있습니다. 긴급성 증가와 동일한 프로세스를 사용하여 임계값을 선택할 수 있으며, 서비스의 SLO보다 높은 기간을 선택하세요.

우리는 이를 도입하는 병합 요청의 엔드포인트에 대해 가장 긴 기간을 설정하지 말아야 합니다. 왜냐하면 이를 뒷받침할 데이터가 아직 없기 때문입니다.

긴급성 증가 (더 낮은 목표 기간 설정)

긴급성을 증가시킬 때, 요청을 처리하는 플릿이 여전히 SLO를 충족하는지 확인해야 합니다. 로그의 정보를 사용하여 확인할 수 있습니다:

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

임계값을 너무 낮추면 Apdex 저하에 대한 경고를 초래할 수 있으므로, 병합 요청에 스케일러빌리티 팀 구성원을 포함해야 합니다.

긴급성 조정 방법

엔드포인트가 기능 범주를 가져오는 방법과 유사하게 긴급성을 지정할 수 있습니다. 특정 타겟이 없는 엔드포인트는 기본 긴급성으로 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 매처가 제공됩니다:

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

API 클래스의 특정 액션에 대해서도 긴급성을 지정하려면:

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

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

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

Grape 엔드포인트 스펙과 호환되는 사용자 정의 RSpec 매처도 제공됩니다:

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

경고:

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

오류 예산 귀속 및 소유권

이 SLI는 서비스 수준 모니터링에 사용됩니다. 이는 단계 그룹의 오류 예산에 반영됩니다.

자세한 내용은 맞춤형 SLI 정의 및 오류 예산에 포함시키기 관련 에픽을 참조하세요.

SLI의 엔드포인트는 기능 범주에 따라 그룹의 오류 예산으로 반영됩니다.

어떤 엔드포인트가 귀하의 그룹에 포함되어 있는지 알아보려면, group dashboard for your group에서 요청 비율을 확인할 수 있습니다.

예산 귀속 행에서 Puma Apdex 로그 링크는 1초 또는 5초 목표를 충족하지 않는 요청 수를 보여줍니다.

대시보드의 콘텐츠에 대한 자세한 내용은 단계 그룹을 위한 대시보드를 참조하세요. 오류 예산에 대한 탐색에 대한 자세한 내용은 issue 1365를 참조하세요.

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

요청 Apdex SLO

요청 긴급성 조정

긴급성 감소 (더 높은 목표 기간 설정)

긴급성 증가 (더 낮은 목표 기간 설정)

긴급성 조정 방법

Rails 컨트롤러

Grape 엔드포인트

오류 예산 귀속 및 소유권

도움말

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

도움받기