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

• 브랜치 또는 태그 이름이 허용 가능한지 확인합니다.

• 사용자가 해당 작업을 수행할 권한이 있는지 여부를 확인합니다.

엔드포인트 정의#

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

엔드포인트 사용#

internal/allowed는 다음과 같은 경우에 호출됩니다:

• 리포지터리에 푸시하는 경우.

• 제안 적용 또는 GitLab IDE 사용과 같이 GitLab 사용자 인터페이스를 통해 리포지터리에서 작업을 수행하는 경우.

Gitaly는 일반적으로 이 엔드포인트를 호출합니다. 이 엔드포인트는 API의 외부 사용자가 아닌 애플리케이션의 다른 부분에 의해 내부적으로만 호출됩니다.

푸시 검사#

internal/allowed 플로의 핵심 부분은 EE::Gitlab::Checks::PushRuleCheck 호출이며, 다음과 같은 검사를 수행할 수 있습니다:

• EE::Gitlab::Checks::PushRules::CommitCheck

• EE::Gitlab::Checks::PushRules::TagCheck

• EE::Gitlab::Checks::PushRules::BranchCheck

재귀 호출#

internal/allowed에 의해 호출된 일부 Gitaly RPC는 다시 internal/allowed로 콜백 호출을 합니다. 이러한 호출은 이제 원래 요청과 연관됩니다. Gitaly는 인가를 위해 Rails 애플리케이션에 의존하며, 자체적으로 권한 모델을 유지하지 않습니다.

이러한 호출은 초기 요청과 다르게 로그에 표시됩니다. {example}

이 엔드포인트는 재귀적으로 호출될 수 있기 때문에, 이 엔드포인트의 느린 성능은 기하급수적인 성능 영향을 초래할 수 있습니다. 이 문서는 실제로 성능 조사에서 도출된 내용을 기반으로 합니다.

알려진 성능 문제#

Refs#

Git 리포지터리의 refs 수는 해당 리포지터리에서 호출되는 git 명령의 성능에 상당한 영향을 미칩니다. Gitaly RPC도 마찬가지로 영향을 받습니다. 특정 git 명령은 모든 refs를 탐색하므로, 해당 명령의 속도에 현저한 영향을 줍니다.

internal/allowed 엔드포인트에서 RPC 호출의 재귀적 특성으로 인해 ref 수가 성능에 기하급수적인 영향을 미칩니다.

환경 refs#

오래된 환경 refs는 과도한 refs로 인해 성능 문제가 발생하는 일반적인 예입니다. 오래된 환경 refs는 자동으로 정리되지 않기 때문에 활성 리포지터리에서 수만 개에 이를 수 있습니다.

댕글링 refs#

댕글링 refs는 오브젝트 풀에서 오브젝트가 우발적으로 삭제되는 것을 방지하기 위해 생성됩니다. 이러한 refs는 많은 수가 존재할 수 있으며, 잠재적인 성능 영향이 있을 수 있습니다. 이 문제에 대한 기존 논의는 gitaly#1900을 참조하세요. 이 문제는 오래된 환경 refs보다 영향이 적은 것으로 보입니다.

풀 리포지터리#

GitLab에서 포크가 생성되면 중앙 풀 리포지터리가 생성되고, 포크가 여기에 연결됩니다. 이 풀 리포지터리는 다른 포크에 공통인 데이터를 저장하여 데이터 중복을 방지합니다. 그러나 풀 리포지터리는 표준 리포지터리와 동일한 방식으로 정리되지 않아 refs 문제가 발생하기 더 쉽습니다.