내부 허용된 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::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 호출의 성능에는 refs의 수가 지수적인 영향을 미칩니다.
환경 refs
낡은 환경 refs는 성능 문제를 일으키는 refs의 일반적인 예입니다. 활발한 저장소에서 낡은 환경 refs는 자동으로 정리되지 않기 때문에 수만 개로 늘어날 수 있습니다.
매달린 refs
매달린 refs는 객체 풀에서 실수로 삭제되는 것을 막기 위해 생성됩니다. 많은 수의 이러한 refs가 존재할 수 있으며, 잠재적인 성능 영향을 미칠 수 있습니다. 이 문제에 대한 기존 토론은 gitaly#1900을 읽어보세요. 이 문제는 낡은 환경 refs보다 영향력이 적어 보입니다.
풀 저장소
GitLab에서 fork가 만들어지면 중앙 풀 저장소가 만들어지고 fork가 이와 연결됩니다. 이 풀 저장소는 다른 fork와의 공통 데이터를 저장함으로써 데이터의 중복을 막습니다. 그러나 풀 저장소는 표준 저장소와 달리 동일한 방식으로 정리되지 않으며, refs 문제를 더 자주 겪을 수 있습니다.
기능 플래그
병렬 푸시 확인
플래그:
자체 관리형 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 parallel_push_checks라는 기능 플래그를 활성화해야 합니다. GitLab.com의 경우, 기본적으로 이 기능을 사용할 수 없습니다. 특정 프로젝트에서 사용하려면 GitLab.com 관리자에게 해당 프로젝트용으로 활성화해야 합니다.
이 기능을 프로덕션 환경에서 사용해서는 안 됩니다. GitLab Dedicated의 경우, 이 기능을 사용할 수 없습니다.
이 실험적인 기능 플래그는 해당 엔드포인트를 동시에 여러 개의 RPC를 실행하도록 활성화시킵니다. 이를 통해 전반적인 시간을 대략 절반으로 단축할 수 있습니다. 이 시간 단축은 스레딩을 통해 이루어지며 대규모 시스템에서 잠재적인 부작용이 있을 수 있습니다. GitLab.com에서는 이 기능 플래그가 gitlab-org/gitlab 및 gitlab-com/www-gitlab-com 프로젝트에 대해만 활성화됩니다. 해당 프로젝트에서 요청이 시간 초과되기 때문에 이러한 프로젝트에서만 활성화시키도록 합니다. 이 기능이 GitLab.com 전체에 배포되자, 약간의 푸시가 실패했는데 이는 데이터베이스 연결 풀 같은 자원을 고갈시켰기 때문으로 추정됩니다.
요청이 시간 초과되는 경우에만 이 기능 플래그를 활성화하고 해당 프로젝트에서만 활성화시키도록 합니다.
도움말