구성요소(Components) 요구사항

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

데이터베이스

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

PostgreSQL 요구사항

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

개발 및 테스트에 사용되는 버전이므로, 아래에 명시된 최소 PostgreSQL 버전을 사용하는 것이 좋습니다.

GitLab 버전최소 PostgreSQL 버전
10.09.6
13.011

또한 pg_trgmbtree_gist 익스텐션(Extension)이 모든 GitLab 데이터베이스에 로드되는지 확인해야 합니다.

참고

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

Puma 설정

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

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

Puma workers

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

  • 2
  • CPU Core 수 - 1

예를 들어 4개의 코어가 있는 노드는 3개의 Puma 워커로 구성되어야 합니다.

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

Puma 스레드

권장되는 스레드 수는 총 메모리, 레거시 Rugged 코드 사용 등 여러 요인에 따라 달라집니다.

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

Unicorn Workers

대부분의 경우 다음을 사용하는 것이 좋습니다.
: (CPU 코어 * 1.5) + 1 = Unicorn 워커
예를 들어 코어가 4개인 노드에는 Unicorn 워커가 7개 있습니다.

2GB 이상의 모든 머신에 대해 최소 3개의 Unicorn 워커를 권장합니다. 1GB 머신이 있는 경우 과도한 스와핑을 방지하기 위해 두 개의 Unicorn 워커만 구성하는 것이 좋습니다.

사용 가능한 CPU와 메모리 용량이 충분하다면, Unicorn 워커 수를 늘려도 괜찮으며 이는 일반적으로 애플리케이션의 응답 시간을 줄이고 병렬 요청을 처리하는 능력을 높이는 데 도움이 됩니다.

Omnibus 패키지(기본값은 위의 권장 사항)가 있을 때 Unicorn 워커를 변경하려면 Omnibus GitLab 문서에서 Unicorn 설정을 참조하세요.

참고

GitLab 13.0부터 Unicorn을 대체하여 Puma가 기본 Web 서버입니다. GitLab 14.0에서 Unicorn에 대한 지원이 제거될 예정입니다.

Redis와 Sidekiq

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

Prometheus와 Exporters

Omnibus GitLab 9.0부터 Prometheus 및 관련 Exporter들이 기본적으로 활성화되어 GitLab을 쉽고 심층적으로 모니터링할 수 있습니다. 이러한 프로세스는 기본 설정으로 약 200MB의 메모리를 사용합니다.

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

GitLab Runner

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

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

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

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

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

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

참고로 GitLab.com의 자동 확장(Auto-scaling) Shared Runner단일 작업이 아래 CPU와 메모리를 사용하여 단일 인스턴스에서 실행되도록 구성됩니다.

  • 1 vCPU
  • 3.75GB RAM

깃랩 문서 바로가기