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

GitLab 14.4에 도입됨

참고: 이 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: 레일스 컨트롤러 또는 Grape-API 엔드포인트의 식별
feature_category: 해당 컨트롤러 또는 API 엔드포인트에 지정된 기능 범주

요청 Apdex SLO

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

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

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

성공적인 측정과 실패한 측정은 둘 다 stage 그룹의 오차 예산에 영향을 미칩니다.

요청의 긴급성 조정

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

긴시간 실행되는 요청은 인프라에 더 많은 부담을 줍니다. 한 요청을 처리하는 동안 쓰레드는 해당 요청의 기간 동안 점유된 채로 머무릅니다. 쓰레드는 다른 작업을 처리할 수 없습니다. Ruby의 Global VM Lock으로 인해 쓰레드는 락을 유지하고 동일한 Puma 워커 프로세스에서 처리되는 다른 요청들에게 불이익을 줄 수 있습니다. 사실, 요청은 워커가 처리하는 다른 요청에게 방해가 되는 소란스러운 이웃입니다. 이러한 이유로 목표 지속시간의 상한선을 5초로 제한합니다.

긴급성 감소 (더 높은 목표 지속시간 설정)

기존 엔드포인트에서 경우에 따라 긴급성을 낮출 수 있습니다. 다음 사항을 고려하십시오:

Apdex는 인지 성능에 관한 것입니다. 사용자가 요청 결과를 기다리는 활동적인 경우 5초를 기다릴 수 있는 경우가 있습니다. 그러나 엔드포인트가 많은 데이터를 필요로하는 자동화에 의해 사용된다면 5초가 수용 가능할 수 있습니다.
제품 관리자는 엔드포인트가 어떻게 사용되는지 확인하는 데 도움을 줄 수 있습니다.
일부 엔드포인트의 작업량은 호출자가 지정한 매개변수에 따라 크게 달라질 수 있습니다. 긴급성은 이러한 차이를 수용해야 합니다. 경우에 따라 엔드포인트가 no-op(무용)으로 변할 때 해당 작업을 무시해야 합니다. 예를 들어, MergeRequests::DraftsController가 모든 병합 요청에 대해 사용되지만 드물게 렌더링 되는 경우, 여전히 작업을 수행할 수 있는 지점을 선택해야 합니다.
엔드포인트에 의해 사용되는 종속 리소스를 고려하십시오. 엔드포인트가 Gitaly나 데이터베이스에서 많은 데이터를 로드하고 이로 인해 불만족스러운 성능이 발생하는 경우, 긴급성을 줄이지 않고 데이터를로드하는 방법을 최적화하는 것이 좋습니다.
이러한 경우에는 인프라가 견딜 수 있다면 엔드포인트가 SLO를 충족하도록 긴급성을 일시적으로 줄이는 것이 적절할 수 있습니다. 이 경우 이슈에 링크된 코드 코멘트를 작성하십시오.
엔드포인트가 많은 CPU 시간을 사용하는 경우, 이를 고려해야 합니다. 이러한 유형의 요청은 가능한 짧게 유지해야 할 중요하지 않은 이웃의 유형입니다.
트래픽 특성도 고려해야 합니다. 종종 트래픽이 폭주하는 경우(예: CI 트래픽이 동일한 엔드포인트를 여러 작업에 충격적으로 활성화함)에는 5초 동안 요청을 받는 것은 인프라적으로 받아들이기 힘든 상황입니다. 우리는 일반 트래픽과 함께 느린 요청이 들어오는 것에 대비하여 플리트를 충분히 빨리 확장할 수 없습니다.

기존 엔드포인트의 긴급성을 낮출 때는 확장성 팀 구성원을 리뷰에 참여시키십시오. 로그에서 사용 가능한 요청률 및 지속시간을 사용하여 권장 사항을 만들 수 있습니다. 서비스용 SLO보다 높은 지속시간을 설정하는 프로세스와 동일한 프로세스를 사용하여 임계값을 선택할 수 있습니다.

새로운 엔드포인트에 가장 긴 지속시간을 설정하지 마십시오. 왜냐하면 해당 결정을 지지하는 데이터가 아직 없기 때문입니다.

긴급성 증가(목표 기간을 낮추는 것)

긴급성을 높일 때, 요청을 처리하는 플리트에서 SLO를 만족시키는지 확인해야 합니다. 로그의 정보를 사용하여 다음을 확인할 수 있습니다.

Kibana의 이 테이블을 엽니다.
테이블은 기본적으로 가장 바쁜 엔드포인트에 대한 정보를 로드합니다. 응답을 빠르게 하려면 다음을 추가하세요:
- json.meta.caller_id.keyword에 대한 필터
- 관심 있는 식별자, 예를 들어: ruby Projects::RawController#show 또는: plaintext 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의 엔드포인트는 선언된 기능 카테고리에 기반하여 그룹의 에러 버젯에 기여합니다.

그룹에 포함된 엔드포인트를 알아보려면, 그룹용 대시보드에서 요청률을 확인할 수 있습니다. 예산 귀속 행에서 Puma Apdex 로그 링크를 통해 1초 또는 5초 목표를 충족하지 못하는 요청이 몇 개인지 확인할 수 있습니다.

대시보드 내용에 대한 추가 정보는 단계 그룹 대시보드를 참조하세요. 에러 버젯 자체에 대한 탐구에 대한 자세한 내용은 이슈 1365를 확인하세요.