내부 허용된 API

internal/allowed 엔드포인트는 사용자가 Git 저장소에서 특정 작업을 수행할 수 있는 권한이 있는지를 평가합니다. 다음과 같은 여러 가지 확인을 수행합니다.

  • 브랜치 또는 태그 이름이 허용되는지 확인합니다.
  • 사용자가 해당 작업을 수행할 권한이 있는지 여부를 확인합니다.

엔드포인트 정의

내부 API 엔드포인트는 lib/api/internal 하위에 정의되어 있으며, /allowed 경로는 lib/api/internal/base.rb에 있습니다.

엔드포인트 사용

internal/allowed는 다음 경우에 호출됩니다.

  • 저장소로 푸시하는 경우.
  • GitLab 사용자 인터페이스를 통해 저장소에서 작업을 수행하는 경우, 이는 제안을 적용하거나 GitLab IDE를 사용하는 것과 관련됩니다.

일반적으로 Gitaly에서 이 엔드포인트를 호출합니다. 외부 사용자가 아닌 내부적으로 (응용 프로그램의 다른 부분에서) 호출됩니다.

푸시 확인

internal/allowed의 중요한 부분은 EE::Gitlab::Checks::PushRuleCheck를 호출하는 것인데, 이는 다음 확인을 수행할 수 있습니다.

  • EE::Gitlab::Checks::PushRules::CommitCheck
  • EE::Gitlab::Checks::PushRules::TagCheck
  • EE::Gitlab::Checks::PushRules::BranchCheck
  • EE::Gitlab::Checks::PushRules::FileSizeCheck

재귀

internal/allowed에서 호출되는 일부 Gitaly RPC는 다시 internal/allowed로 호출됩니다. 이러한 호출은 이제 원래 요청과 관련이 있습니다. Gitaly는 권한 부여를 위해 Rails 애플리케이션에 의존하며 권한 모델을 별도로 유지하지 않습니다.

이러한 호출은 로그에 초기 요청과는 다르게 나타납니다. {예시}

이 엔드포인트는 재귀적으로 호출될 수 있기 때문에 이러한 엔드포인트의 성능 저하는 기하급수적인 영향을 줄 수 있습니다. 이 문서는 사실 성능 조사로부터 적용되었습니다.

알려진 성능 이슈

Refs

Git 저장소의 refs의 수는 해당 저장소에 호출되는 git 명령의 성능에 주목할 만한 영향을 미칩니다. 마찬가지로 Gitaly RPC도 영향을 받습니다. 특정 git 명령은 모든 refs를 스캔하며 해당 명령의 속도에 주목할 만한 영향을 미칩니다.

internal/allowed 엔드포인트의 재귀적 호출은 ref 카운트가 성능에 기하급수적인 영향을 미치게 합니다.

환경 refs

오래된 환경 refs는 성능 문제를 일으키는 흔한 예제입니다. 활발한 저장소에서 오래된 환경 refs는 수만 개로 이어지며, 자동으로 정리되지 않습니다.

덩그러니 refs

덩그러니 refs는 객체 풀에서의 실수적인 삭제를 방지하기 위해 생성됩니다. 수많은 덩그러니 refs가 존재할 수 있으며, 잠재적인 성능 영향을 미칠 수 있습니다. 이 문제에 대한 기존 토론은 gitaly#1900를 참조하십시오. 이 문제는 환경 refs보다는 덜한 효과를 가질 것으로 보입니다.

풀 저장소

GitLab에서 포크를 생성하면 중앙 풀 저장소가 생성되며 해당 포크는 이에 연결됩니다. 이 풀 저장소는 다른 포크에서 공통 데이터를 저장하여 데이터 중복을 방지합니다. 그러나 풀 저장소는 표준 저장소와는 다르게 정리되지 않으며, refs 문제에 더 취약합니다.

기능 플래그

병렬 푸시 확인

자체 관리형 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 parallel_push_checks라는 기능 플래그를 활성화해야 합니다. GitLab.com에서는 기본적으로 이 기능을 사용할 수 없습니다. 프로젝트 단위로 활성화하려면 GitLab.com 관리자에게 parallel_push_checks라는 기능 플래그를 활성화하도록 요청해야 합니다. 이 기능을 프로덕션 환경에서 사용해서는 안 됩니다. GitLab 전용 서버에서는 이 기능을 사용할 수 없습니다.

이 실험적인 기능 플래그는 엔드포인트에서 여러 개의 RPC를 동시에 실행하여 전체 시간을 대략 절반으로 줄이는 것을 가능하게 합니다. 이 시간 절약은 스레딩을 통해 달성되며 대규모에서 잠재적인 부작용이 있습니다. GitLab.com에서는 이 기능 플래그가 gitlab-org/gitlabgitlab-com/www-gitlab-com 프로젝트에 대해서만 활성화되어 있습니다. 이를 사용하지 않는 경우, 이러한 프로젝트에서 엔드포인트로의 요청이 정기적으로 시간 초과됩니다. 이 기능이 GitLab.com 전체에 배포된 경우 일부 푸시가 실패했으며, 이는 아마도 데이터베이스 연결 풀 등의 리소스를 고갈시킨 것으로 보입니다.

이 기능 플래그는 시간 초과 문제를 겪고 있는 경우에만 사용하고 해당 프로젝트에 대해서만 활성화하는 것을 권장합니다.