구성요소(Components) 요구사항

GitLab 구성요소가 최적의 성능으로 작동하기 위해서는 각 구성요소별로 버전 및 설정 권장사항을 따르는 것이 좋습니다.

데이터베이스

PostgreSQL은 Omnibus GitLab 패키지와 함께 번들로 제공되는 유일하게 지원되는 데이터베이스입니다. 외부 PostgreSQL 데이터베이스를 사용할 수도 있습니다. MySQL에 대한 지원은 GitLab 12.1에서 제거되었습니다. MySQL/MariaDB와 함께 GitLab을 사용하는 기존 사용자는 업그레이드하기 전에 PostgreSQL로 마이그레이션하는 것이 좋습니다.

PostgreSQL 요구사항

정확한 요구사항은 사용자 수에 따라 다르지만, PostgreSQL을 실행하는 서버에는 최소 5~10GB의 스토리지를 사용할 수 있어야 합니다.

개발 및 테스트에 사용된 최소 PostgreSQL 버전(다음 표에 명시된 대로)을 사용하는 것이 좋습니다.

GitLab 버전	최소 PostgreSQL 버전
13.0	11
14.0	12

또한 다음 익스텐션(Extension)이 GitLab 데이터베이스에 모두 로드되었는지 확인해야 합니다. 이 요구사항 및 트러블슈팅에 대해 자세히 알아보세요.

익스텐션	최소 GitLab 버전
pg_trgm	8.6
btree_gist	13.1
plpgsql	11.7

참고

PostgreSQL 9.6 및 10에 대한 지원이 GitLab 13.0에서 제거되어 GitLab은 파티셔닝(Partitioning)과 같은 PostgreSQL 11 개선사항의 이점을 누릴 수 있습니다. PostgreSQL 12로의 전환 일정은 관련 에픽을 참조하세요.

GitLab Geo에 대한 추가 요구 사항

GitLab Geo를 사용하는 경우 Omnibus GitLab 관리형 인스턴스를 실행하는 것이 좋습니다. 이를 기반으로 적극적으로 개발 및 테스트하기 때문입니다. GitLab 팀은 대부분의 외부(Omnibus GitLab에서 관리하지 않음) 데이터베이스(예: AWS Relational Database Service(RDS))와 호환되도록 노력하고 있지만 호환성을 보장할 수 없습니다.

Gitaly 클러스터 데이터베이스 요구 사항

자세한 내용은 Gitaly Cluster 문서를 참조하세요.

GitLab 데이터베이스의 독점적인 사용

GitLab, Geo, Gitaly Cluster 또는 기타 구성요소를 위해 생성되거나 사용되는 데이터베이스는 GitLab 전용이어야 합니다. GitLab 설명서의 절차를 따르거나 GitLab 지원팀 또는 GitLab 엔지니어의 지시를 따르는 경우를 제외하고 데이터베이스, 스키마, 사용자 또는 기타 속성을 직접 변경하지 마십시오.

• 주요 GitLab 애플리케이션은 현재 세 가지 스키마를 사용합니다.
  • 기본 public 스키마
  • gitlab_partitions_static (자동 생성)
  • gitlab_partitions_dynamic (자동 생성) 다른 스키마는 수동으로 생성하면 안 됩니다.
• GitLab은 Rails 데이터베이스 마이그레이션의 일부로 새 스키마를 생성할 수 있습니다. 이것은 GitLab 업그레이드를 수행할 때 발생합니다. 이 작업을 수행하려면 GitLab 데이터베이스 계정에 액세스 권한이 필요합니다.
• GitLab은 업그레이드 프로세스 중에 테이블을 생성하고 수정하며, 파티션 된 테이블을 관리하기 위한 일반 작업의 일부로도 사용됩니다.
• GitLab 스키마를 수정하면 안 됩니다.(예: 트리거 추가 또는 테이블 수정) 데이터베이스 마이그레이션은 GitLab 코드베이스의 스키마 정의에 대해 테스트됩니다. 스키마를 수정하면 GitLab 버전 업그레이드가 실패할 수 있습니다.

Puma 설정

Puma에 대한 권장 설정은 실행 중인 인프라에 따라 결정됩니다. GitLab Linux 패키지는 기본적으로 권장되는 Puma 설정을 사용합니다. 설치 방법에 관계없이 Puma 설정을 조정할 수 있습니다.

• GitLab Linux 패키지를 사용하는 경우 Puma 설정 변경에 대한 지침은 Puma 설정을 참조하세요.
• GitLab Helm chart를 사용하는 경우 Webservice chart를 참조하세요.

Puma workers

권장 워커 수는 다음 중 가장 높은 것으로 계산됩니다.

• 2
• CPU 및 메모리 리소스 가용성의 조합(Linux 패키지에 대해 자동으로 구성되는 방법 참조)

다음 시나리오를 예로 들어 보겠습니다.

• 2Cores/8GB 메모리가 있는 노드는 2개의 Puma 워커로 구성되어야 합니다.

다음과 같이 계산됩니다.

The highest number from
2
And
[
the lowest number from
  - number of cores: 2
  - memory limit: (8 - 1.5) = 6
]

따라서 2와 2에서 가장 높은 값은 2입니다.

• 4Cores/4GB 메모리가 있는 노드는 2개의 Puma 워커로 구성되어야 합니다.

The highest number from
2
And
[
the lowest number from
  - number of cores: 4
  - memory limit: (4 - 1.5) = 2.5
]

따라서 2와 2에서 가장 높은 값은 2입니다.

• 4Cores/8GB 메모리가 있는 노드는 4개의 Puma 워커로 구성되어야 합니다.

The highest number from
2
And
[
the lowest number from
  - number of cores: 4
  - memory limit: (8 - 1.5) = 6.5
]

따라서 2와 4에서 가장 높은 값은 4입니다.

충분한 CPU 및 메모리 용량을 사용할 수 있으면 Puma 워커의 수를 늘릴 수 있습니다. 일반적으로 Puma 워커의 수가 많을수록 애플리케이션의 응답 시간을 줄이고 병렬 요청을 처리하는 능력을 높이는데 도움이 됩니다. 인프라에 대한 최적의 설정을 확인하려면 테스트를 수행해야 합니다.

Puma 스레드

권장되는 스레드 수는 총 메모리 및 레거시 Rugged 코드 사용을 비롯한 여러 요인에 따라 다릅니다.

• 운영 체제에 최대 2GB의 메모리가 있는 경우 권장되는 스레드 수는 1입니다. 값이 높을수록 스와핑이 초과되어 성능이 저하됩니다.
• 레거시 Rugged 코드를 사용 중인 경우 권장 스레드 수는 1입니다.
• 다른 모든 경우에 권장되는 스레드 수는 4입니다. Ruby MRI 멀티 스레딩이 작동하는 방식 때문에 이 값을 더 높게 설정하지 않는 것이 좋습니다.

Worker당 Puma 최대 메모리

기본적으로 각 Puma 워커의 메모리는 1024MB로 제한됩니다. 이 설정은 조정할 수 있으며 Puma 워커 수를 늘려야 하는 경우 고려해야 합니다.

Redis와 Sidekiq

Redis는 모든 사용자 세션과 백그라운드 작업 대기열을 저장합니다. Redis의 스토리지 요구사항은 최소이며 사용자 당 약 25KB입니다. Sidekiq은 다중 스레드 프로세스로 백그라운드 작업을 처리합니다. 이 프로세스는 전체 Rails 스택(200MB 이상)으로 시작되지만, 메모리 누수로 인해 시간이 지남에 따라 커질 수 있습니다. 매우 활동적인 서버(10,000명의 청구 가능한 사용자)에서 Sidekiq 프로세스는 1GB 이상의 메모리를 사용할 수 있습니다.

Prometheus와 관련 Exporters

Prometheus 및 관련 Exporter는 기본적으로 활성화되어 GitLab의 심층 모니터링을 가능하게 합니다. 이러한 프로세스는 약 200MB의 메모리를 사용합니다.

Prometheus 및 Exporter를 비활성화하거나 이에 대한 자세한 정보를 읽으려면 Prometheus 문서를 확인하십시오.

GitLab Runner

GitLab을 설치하려는 동일한 머신에 GitLab Runner를 설치하지 않는 것이 좋습니다. GitLab Runner를 구성하는 방법과 CI 환경에서 애플리케이션을 실행하는 데 사용하는 도구에 따라, GitLab Runner는 상당한 양의 가용 메모리를 사용할 수 있습니다.

위에서 사용할 수 있는 메모리 사용량 계산은 GitLab Runner와 GitLab Rails 애플리케이션을 동일한 머신에서 실행하기로 결정한 경우에는 유효하지 않습니다.

보안상의 이유로, 특히 GitLab Runner에서 셸 실행기(Shell executor)를 사용할 계획인 경우, 단일 머신에 모든 것을 설치하는 것은 안전하지 않습니다.

CI 기능을 사용하려는 경우 각 GitLab Runner에 대해 별도의 머신을 사용하는 것이 좋습니다. GitLab Runner 서버 요구사항은 다음에 따라 다릅니다.

• GitLab Runner에서 구성한 실행기(Executor) 유형
• 빌드 Job을 실행하는 데 필요한 리소스
• Job 동시성(concurrency) 설정

Job의 특성은 각 사용 사례에 따라 다르기 때문에 최적의 설정을 얻으려면 Job 동시성을 조정하여 실험해야 합니다.

참고로, Linux 상의 SaaS Runner는 단일 작업이 아래 CPU와 메모리를 사용하여 단일 인스턴스에서 실행되도록 구성됩니다.

• 1 vCPU
• 3.75GB RAM

GitLab 원문 보기