내부 허용된 API
internal/allowed 엔드포인트는 사용자가 Git 리포지터리에서 특정 작업을 수행할 권한이 있는지를 평가합니다. 여러 가지 확인을 수행합니다.
- 브랜치 또는 태그 이름이 허용되는지 확인합니다.
- 사용자가 그 작업을 수행할 권한이 있는지 여부를 확인합니다.
엔드포인트 정의
내부 API 엔드포인트는 lib/api/internal에 정의되어 있으며 /allowed 경로는 lib/api/internal/base.rb에 있습니다.
엔드포인트 사용
internal/allowed는 다음 경우에 호출됩니다.
- 리포지터리에 푸시합니다.
- GitLab 사용자 인터페이스를 통해 리포지터리에서 작업을 수행할 때, 제안을 적용하거나 GitLab IDE를 사용하는 경우 등.
일반적으로 이 엔드포인트는 Gitaly에서 호출됩니다. API의 외부 사용자가 아닌 응용 프로그램의 다른 부분에 의해서 내부적으로만 호출됩니다.
푸시 확인
internal/allowed 흐름의 주요 부분은 다음 확인을 수행할 수 있는
EE::Gitlab::Checks::PushRuleCheck 호출입니다.
EE::Gitlab::Checks::PushRules::CommitCheckEE::Gitlab::Checks::PushRules::TagCheckEE::Gitlab::Checks::PushRules::BranchCheckEE::Gitlab::Checks::PushRules::FileSizeCheck
등을 수행할 수 있습니다.
재귀
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가 수만 개에 이를 수 있으며, 자동으로 정리되지 않습니다.
Dangling refs
Dangling refs는 객체 풀에서 실수로 삭제되는 것을 방지하기 위해 생성됩니다. 이러한 refs의 수가 많을 수 있으며, 잠재적인 성능 영향을 미칠 수 있습니다. 이 문제에 대한 기존 토론은 gitaly#1900를 참조하십시오. 이 문제는 낡은 환경 refs보다는 덜한 영향을 미치는 것으로 보입니다.
풀 리포지터리
GitLab에서 포크가 생성되면 중앙 풀 리포지터리가 생성되고 포크가 연결됩니다. 이 풀 리포지터리는 다른 포크에 공통 데이터를 저장하여 데이터 중복을 방지합니다. 그러나 풀 리포지터리는 표준 리포지터리처럼 정리되지 않으며, refs 문제에 더 취약합니다.
피처 플래그
병렬 푸시 확인
이 실험적인 피처 플래그는 엔드포인트를 동시에 여러 개의 RPC로 실행하여 전체 소요 시간을 대략 절반으로 줄입니다. 이 시간 절약은 스레딩을 통해 달성되며 대규모에서 잠재적인 부작용이 있습니다. GitLab.com에서는 이 피처 플래그가 gitlab-org/gitlab 및 gitlab-com/www-gitlab-com 프로젝트에 대해서만 활성화되어 있습니다. 이 기능이 없으면 이러한 프로젝트는 종종 엔드포인트에 대한 요청 시간 초과가 발생합니다. 이 기능이 GitLab.com 전체에 배포되었을 때 일부 푸시가 실패했으며, 아마도 데이터베이스 연결 풀 등의 리소스가 고갈되었기 때문으로 보입니다.
이 피처 플래그는 요청 시간 초과를 경험하는 경우에만 사용하고 해당 프로젝트에만 활성화하는 것이 좋습니다.
도움말