Elasticsearch

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

이 페이지에서는 고급 검색을 활성화하는 방법에 대해 설명합니다. 활성화되면 고급 검색은 더 빠른 검색 응답 시간과 향상된 검색 기능을 제공합니다.

버전 요구 사항

Elasticsearch 버전 요구 사항

고급 검색은 다음 Elasticsearch 버전과 함께 작동합니다.

GitLab 버전 Elasticsearch 버전
GitLab 15.0 이상 Elasticsearch 7.x 이상
GitLab 14.0에서 14.10 Elasticsearch 6.8에서 7.x 이상

고급 검색은 Elasticsearch 지원 종료 정책을 따릅니다. GitLab에서 Elasticsearch 지원 버전을 변경할 때, 우리는 그것을 월간 릴리스 포스트의 폐기 알림에서 공지합니다.

OpenSearch 버전 요구 사항

GitLab 버전 OpenSearch 버전
GitLab 15.5.3 이상 OpenSearch 1.x 이상
GitLab 15.0에서 15.5.2 OpenSearch 1.x

Elasticsearch 또는 OpenSearch의 버전이 호환되지 않는 경우 데이터 손실을 방지하기 위해 색인이 중지되고 elasticsearch.log 파일에 메시지가 기록됩니다.

호환되는 버전을 사용하고 OpenSearch에 연결한 후 “Elasticsearch 버전 호환되지 않음”이라는 메시지를 받으면 색인 일시 중지합니다.

시스템 요구 사항

Elasticsearch는 GitLab 시스템 요구 사항에 문서화된 추가 리소스가 필요합니다.

데이터 양에 따라 메모리, CPU 및 리포지터리 리소스의 양이 다릅니다. 많이 사용되는 Elasticsearch 클러스터는 더 많은 리소스가 필요할 수 있습니다. estimate_cluster_size Rake 작업은 고급 검색 리포지터리 요구 사항을 추정하기 위해 총 리포지터리 크기를 사용합니다.

Elasticsearch 설치

Elasticsearch는 Linux 패키지에 포함되어 있지 않으며, 직접 컴파일하여 설치할 때도 포함되어 있지 않습니다. 별도로 설치해야 합니다 그리고 원하는 버전을 선택해야 합니다. Elasticsearch의 설치 방법에 대한 자세한 정보는 이 페이지가 다루지 않습니다.

Elasticsearch를 직접 설치하거나 AWS, GCP 또는 Azure에서 제공하는 Elasticsearch Service 또는 Amazon OpenSearch와 같은 클라우드 호스팅 오퍼링을 사용할 수 있습니다.

Elasticsearch를 GitLab과 동일한 서버에 실행하는 것은 권장되지 않으며 GitLab 인스턴스 성능 저하의 원인이 될 수 있습니다.

단일 노드 Elasticsearch 클러스터의 경우 기능적인 클러스터 상태는 항상 기본 샤드 할당으로 인해 옐로우 상태입니다. Elasticsearch는 프라이머리 샤드를 동일한 노드에 레플리카 샤드로 할당할 수 없습니다.

검색 색인은 다음 후에 업데이트됩니다:

참고: 프로덕션에서 새로운 Elasticsearch 클러스터를 사용하기 전에 중요한 설정에 대한 Elasticsearch 문서를 참조하세요.

새로운 Elasticsearch 주 버전으로 업그레이드

Elasticsearch를 업그레이드할 때는 GitLab 구성을 변경할 필요가 없습니다.

Elasticsearch를 업그레이드하는 동안 다음을 수행해야 합니다:

  • 변경 사항을 계속 추적할 수 있도록 색인 중지
  • 검색이 HTTP 500 오류로 실패하지 않도록 고급 검색을 비활성화

Elasticsearch 클러스터가 완전히 업그레이드되고 활성 상태가 될 때 색인 재개 및 고급 검색을 활성화하십시오.

GitLab 15.0 이상으로 업그레이드하는 경우 Elasticsearch 7.x 이상을 사용해야 합니다.

Elasticsearch 리포지터리 인덱서

GitLab은 Git 리포지터리 데이터를 색인하기 위해 Go로 작성된 인덱서를 사용합니다.

GitLab 버전에 따라 Go 인덱서의 설치 절차가 다릅니다:

소스에서 인덱서 설치

먼저 몇 가지 의존성을 설치한 다음 인덱서 자체를 빌드하고 설치합니다.

의존성 설치

이 프로젝트는 텍스트 인코딩을 위해 국제 유니코드 컴포넌트 (ICU)에 의존하므로 make를 실행하기 전에 플랫폼의 개발 패키지가 설치되어 있는지 확인해야 합니다.

Debian / Ubuntu

Debian 또는 Ubuntu에서 설치하려면 다음을 실행하십시오: 

sudo apt install libicu-dev
CentOS / RHEL

CentOS 또는 RHEL에서 설치하려면 다음을 실행하십시오: 

sudo yum install libicu-devel
macOS

참고: 먼저 Homebrew를 설치해야 합니다.

macOS에서 설치하려면 다음을 실행하십시오: 

brew install icu4c
export PKG_CONFIG_PATH="/usr/local/opt/icu4c/lib/pkgconfig:$PKG_CONFIG_PATH"

빌드 및 설치

인덱서를 빌드하고 설치하려면 다음을 실행하십시오: 

indexer_path=/home/git/gitlab-elasticsearch-indexer

# gitlab-elasticsearch-indexer에 대한 설치 작업 실행:
sudo -u git -H bundle exec rake gitlab:indexer:install[$indexer_path] RAILS_ENV=production
cd $indexer_path && sudo make install

gitlab-elasticsearch-indexer가 /usr/local/bin에 설치됩니다.

PREFIX 환경 변수를 사용하여 설치 경로를 변경할 수 있습니다. 그렇게 하는 경우 sudo에 -E 플래그를 전달해야합니다. 예제: 

PREFIX=/usr sudo -E make install

설치 후에 색인 중에 Permission denied - /home/git/gitlab-elasticsearch-indexer/와 같은 오류가 발생하는 경우 production -> elasticsearch -> indexer_path 설정을 /usr/local/bin/gitlab-elasticsearch-indexer로 설정해야 할 필요가 있습니다. 해당 경로는 이진 파일이 설치된 위치입니다.

색인 오류 보기

GitLab Elasticsearch 인덱서에서의 오류는 elasticsearch.log 파일과 json.exception.class가 Gitlab::Elastic::Indexer::Error인 sidekiq.log 파일에 보고됩니다. 이러한 오류는 Git 리포지터리 데이터의 색인 중에 발생할 수 있습니다.

고급 검색 활성화

필수 조건:

  • 인스턴스에 대한 관리자 액세스가 있어야 합니다.

고급 검색을 활성화하려면 다음을 수행하십시오:

  1. 왼쪽 사이드바에서 아래쪽에 있는 관리자 영역을 선택합니다.

  2. 설정 > 고급 검색을 선택합니다.

    참고: 고급 검색 섹션을 보려면 유효한 GitLab Premium 라이선스가 필요합니다.

  3. Elasticsearch 클러스터에 대한 고급 검색 설정을 구성합니다. Elasticsearch 검색 사용 확인란을 아직 선택하지 마십시오.

  4. Rake 작업을 사용하여 모든 데이터를 색인합니다. 작업은 이미 존재하지 않는 경우 빈 색인을 생성하고, 색인이 이미 활성화되어 있지 않은 경우 Elasticsearch 색인을 활성화합니다. 

    # 경고: 기존 색인이 모두 삭제됩니다
# Omnibus 설치
sudo gitlab-rake gitlab:elastic:index
   
# 경고: 기존 색인이 모두 삭제됩니다
# 소스 설치
bundle exec rake gitlab:elastic:index RAILS_ENV=production
  5. 선택 사항. 백그라운드 작업의 상태를 모니터링합니다.
    1. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
    2. Sidekiq 대시 보드에서 큐를 선택하고 elastic_commit_indexer 및 elastic_wiki_indexer 큐가 0으로 감소될 때까지 기다립니다. 이러한 큐에는 그룹 및 프로젝트의 코드 및 위키 데이터를 색인하는 작업이 포함됩니다.
  6. 색인이 완료되면 Elasticsearch 검색 사용 확인란을 선택한 후 변경 사항 저장을 선택합니다.

참고: Elasticsearch 클러스터가 비활성화된 상태에서 Elasticsearch가 활성화된 경우 문제가 발생할 수 있습니다. 인스턴스는 변경 사항을 색인하려는 작업을 대기시키지만 유효한 Elasticsearch 클러스터를 찾을 수 없기 때문에 문제가 발생합니다.

GitLab 인스턴스의 리포지터리 데이터가 50기가바이트 이상인 경우 대용량 인스턴스를 효율적으로 색인하는 방법을 참조하세요.

Index all projects 설정 활성화

Index all projects 설정은 초기 색인을 수행하기 위해서만 사용할 수 있으며, 색인을 처음부터 다시 생성하는 데는 사용할 수 없습니다. Index all projects를 사용하여 고급 검색을 활성화하려면:

  1. 왼쪽 사이드바에서 가장 아래쪽에 관리 영역을 선택합니다.
  2. 설정 > 고급 검색을 선택합니다.
  3. Elasticsearch 인덱싱 확인란을 선택한 후 변경 사항 저장을 선택합니다.
  4. Index all projects를 선택합니다.
  5. 선택 사항. 백그라운드 작업의 상태를 확인하려면 진행 상황 확인을 선택합니다.

에픽, 그룹 위키, 개인 스니펫, 사용자를 색인하려면 Rake 작업을 사용해야 합니다. 

# 옴니버스 설치
sudo gitlab-rake gitlab:elastic:index_epics
sudo gitlab-rake gitlab:elastic:index_group_wikis
sudo gitlab-rake gitlab:elastic:index_snippets
sudo gitlab-rake gitlab:elastic:index_users

# 소스에서 설치
bundle exec rake gitlab:elastic:index_epics RAILS_ENV=production
bundle exec rake gitlab:elastic:index_group_wikis RAILS_ENV=production
bundle exec rake gitlab:elastic:index_snippets RAILS_ENV=production
bundle exec rake gitlab:elastic:index_users RAILS_ENV=production

고급 검색 구성

다음과 같은 Elasticsearch 설정이 있습니다:

매개변수 설명
Elasticsearch indexing Elasticsearch 색인화를 활성화 또는 비활성화하고 존재하지 않는 경우 빈 색인을 만듭니다. 예를 들어 색인화를 활성화하고 검색을 비활성화하여 색인이 완전히 완료될 때까지 시간을 주려는 경우 유용합니다. 또한, 이 옵션이 기존 데이터에는 영향을 미치지 않으며, 이는 데이터 변경을 추적하고 새 데이터가 색인화되도록 보장하는 백그라운드 색인 프로그램을 활성화/비활성화하는 것뿐입니다.
Pause Elasticsearch indexing 일시적 색인 일시 중지를 활성화 또는 비활성화합니다. 이는 클러스터 마이그레이션/재색인에 유용합니다. 모든 변경 사항은 여전히 추적되지만 재개할 때까지 Elasticsearch 색인에는 커밋되지 않습니다.
Search with Elasticsearch enabled 검색에서 Elasticsearch 사용을 활성화 또는 비활성화합니다.
Requeue indexing workers 색인화 워커를 자동으로 다시 대기열에 넣도록 활성화합니다. 이는 모든 문서가 처리될 때까지 Sidekiq 작업을 인큐하여 코드가 아닌 색인화 처리량을 향상시킵니다. 색인화 워커를 다시 대기열에 넣는 것은 작은 인스턴스나 Sidekiq 프로세스가 적은 경우에 권장되지 않습니다.
URL Elasticsearch 인스턴스의 URL입니다. 클러스터링을 지원하려면 쉼표로 구분된 디렉터리을 사용합니다(예: http://host1, https://host2:9200). Elasticsearch 인스턴스에 암호가 설정된 경우 사용자 이름 및 비밀번호 필드를 사용합니다. 또는 http://<사용자명>:<비밀번호>@<elastic_host>:9200/와 같이 인라인 자격 증명을 사용합니다. OpenSearch를 사용하는 경우 포트 80 및 443을 통한 연결만 허용됩니다.
Username Elasticsearch 인스턴스의 사용자 이름입니다.
Password Elasticsearch 인스턴스의 암호입니다.
Number of Elasticsearch shards and replicas per index Elasticsearch 인덱스는 성능상의 이유로 여러 개의 샤드로 분할됩니다. 일반적으로 최소 다섯 개의 샤드를 사용해야 합니다. 수천만 개의 문서가 있는 인덱스는 더 많은 샤드를 가져야 합니다(가이드 참조). 이 값의 변경은 색인을 다시 생성할 때까지 적용되지 않습니다. 확장성과 탄력성에 대한 자세한 정보는 Elasticsearch 설명서를 참조하세요. 각 Elasticsearch 샤드는 여러 개의 레플리카를 가질 수 있습니다. 이러한 레플리카는 샤드의 완전한 사본이며 증가된 쿼리 성능 또는 하드웨어 장애에 대한 탄력성을 제공할 수 있습니다. 이 값을 늘리면 인덱스에 필요한 총 디스크 공간이 증가합니다. 각 인덱스의 샤드 및 레플리카 수를 설정할 수 있습니다.
Limit the amount of namespace and project data to index 이 설정을 활성화하면 색인할 네임스페이스 및 프로젝트를 지정할 수 있습니다. 다른 모든 네임스페이스 및 프로젝트는 데이터베이스 검색을 사용합니다. 이 설정을 활성화하지만 네임스페이스나 프로젝트를 지정하지 않은 경우에는 프로젝트 레코드만 색인됩니다. 자세한 내용은 네임스페이스 및 프로젝트 데이터의 한도 설정을 참조하세요.
Using AWS OpenSearch Service with IAM credentials AWS IAM 권한 부여, AWS EC2 인스턴스 프로파일 자격 증명 또는 AWS ECS 작업 자격 증명을 사용하여 OpenSearch 요청에 서명합니다. AWS 호스팅 OpenSearch 도메인 액세스 정책 구성에 대해서는 Amazon OpenSearch Service에서의 Identity and Access Management을 참조하세요.
AWS Region OpenSearch 서비스가 위치한 AWS 지역입니다.
AWS Access Key AWS 액세스 키
AWS Secret Access Key AWS 비밀 액세스 키
Maximum file size indexed 인스턴스 제한 사항에 대한 설명을 참조하세요.
Maximum field length 인스턴스 제한 사항에 대한 설명을 참조하세요.
Number of shards for non-code indexing 색인화 워커 샤드의 수입니다. 이 값은 비코드 색인화 처리량을 더 많이 하는 병렬 Sidekiq 작업을 인큐하여 색인화 성능을 향상시킵니다. 작은 인스턴스나 Sidekiq 프로세스가 적은 경우에는 샤드 수를 늘리는 것이 권장되지 않습니다. 기본값은 2입니다.
Maximum bulk request size (MiB) GitLab의 Ruby 및 Go 기반 색인화 프로세스에서 사용됩니다. 이 설정은 주어진 색인화 프로세스에서 페이로드를 Elasticsearch Bulk API에 제출하기 전에 수집해야 하는 데이터(및 메모리에 저장) 양을 나타냅니다. GitLab Go 기반 색인화에서는 이 설정을 Bulk request concurrency와 함께 사용해야 합니다. Maximum bulk request size (MiB)는 Elasticsearch 호스트 및 GitLab Go 기반 색인화를 실행하는 호스트의 리소스 제한을 고려해야 합니다.
Bulk request concurrency Bulk request concurrency는 병렬로 실행되는 GitLab Go 기반 색인화 프로세스(또는 스레드) 수를 나타냅니다. 이는 색인화 성능을 향상시키지만 Elasticsearch 대량 요청 대기열을 빠르게 채웁니다. 이 설정은 위의 Maximum bulk request size 설정과 함께 사용되어야 하며 Elasticsearch 호스트와 GitLab Go 기반 색인화를 실행하는 호스트의 리소스 제한을 고려해야 합니다.
Client request timeout Elasticsearch HTTP 클라이언트 요청 시간 초과 값(초). 0은 시스템 기본 시간 초과 값을 사용함을 의미하며, GitLab 애플리케이션이 구축된 라이브러리에 따라 다릅니다.
Code indexing concurrency 동시에 실행되는 최대 Elasticsearch 코드 색인화 백그라운드 작업 수입니다. 이 값은 리포지터리 색인화 작업에만 적용됩니다.
caution
Maximum bulk request size (MiB)와 Bulk request concurrency 값을 높이면 Sidekiq 성능에 부정적인 영향을 미칠 수 있습니다. Sidekiq 로그에서 증가된 scheduling_latency_s 기간이 보이면 기본값으로 복원하세요. 자세한 내용은 이슈 322147을 참조하세요.

액세스 요구 사항

Elasticsearch 및 역할 권한

Elasticsearch에 액세스하여 작업을 수행하려면 GitLab에서 다음 권한을 갖는 역할이 필요합니다: 

{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["gitlab-*"],
      "privileges": [
        "create_index",
        "delete_index",
        "view_index_metadata",
        "read",
        "manage",
        "write"
      ]
    }
  ]
}

자세한 내용은 Elasticsearch 보안 권한을 참조하세요.

fein-grained 액세스 제어를 통해 AWS OpenSearch 서비스 이용

세분화된 액세스 제어를 사용하여 Self-Managed형 AWS OpenSearch 서비스를 GitLab에서 사용하려면 권장 구성 중 하나를 사용해 보세요.

인스턴스의 도메인 액세스 정책을 구성하여 es:ESHttp* 동작을 허용합니다. 주체(principals) 또는 리소스를 제한하는 예제 구성은 다음과 같습니다: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "*"
        ]
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Resource": "domain-arn/*"
    }
  ]
}

자세한 내용은 Amazon OpenSearch 서비스에서 ID 및 액세스 관리를 참조하세요.

내부 데이터베이스의 마스터 사용자와 연결

내부 데이터베이스의 사용자를 사용하여 세분화된 액세스 제어를 사용하는 경우 OpenSearch에 연결하려면 HTTP 기본 인증을 사용해야 합니다. 고급 검색 설정의 OpenSearch URL 또는 사용자 이름과 비밀번호 텍스트 상자에 마스터 사용자 이름과 비밀번호를 제공할 수 있습니다. 자세한 내용은Tutorial: 내부 사용자 데이터베이스 및 HTTP 기본 인증를 참조하세요.

IAM 사용자와 연결

세분화된 액세스 제어를 IAM 자격 증명과 함께 사용하는 경우 고급 검색 설정의 AWS OpenSearch IAM 자격 증명 섹션에 자격 증명을 제공할 수 있습니다.

세분화된 액세스 제어 권한

고급 검색에는 다음 권한이 필요합니다. 자세한 내용은 역할 생성을 참조하세요. 

{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [
    {
      "index_patterns": [
        "gitlab*"
      ],
      "allowed_actions": [
        "data_access",
        "manage_aliases",
        "search",
        "create_index",
        "delete",
        "manage"
      ]
    },
    {
      "index_patterns": [
        "*"
      ],
      "allowed_actions": [
        "indices:admin/aliases/get",
        "indices:monitor/stats"
      ]
    }
  ]
}

* 인덱스 패턴은 고급 검색에 몇 가지 권한이 필요합니다.

네임스페이스 및 프로젝트 데이터의 색인 제한

네임스페이스 및 프로젝트 데이터의 양을 제한합니다 확인란을 선택하면 색인할 네임스페이스 및 프로젝트를 지정할 수 있습니다. 네임스페이스가 그룹인 경우 해당 하위 그룹 및 하위 그룹에 속한 프로젝트도 색인됩니다.

고급 검색은 모든 네임스페이스가 색인된 경우에만 교차 그룹 코드/커밋 검색(전역)을 제공합니다. 모든 네임스페이스가 색인된 상황에서만 코드 또는 커밋 범위를 제공합니다. 일부 네임스페이스만 색인된 경우 전역 검색은 네임스페이스의 범위에서만 가능합니다. 색인된 네임스페이스가 여러 개인 경우(일부 네임스페이스만 색인된 경우) 코드/커밋 검색을 할 수 있는 방법은 없습니다. 예를 들어, 두 개의 그룹이 색인된 경우 첫 번째 그룹에서만 코드 검색을 실행한 다음 두 번째 그룹에서 실행할 수 있습니다.

네임스페이스 또는 프로젝트를 지정하지 않으면 프로젝트 레코드만 색인됩니다.

caution
인스턴스를 이미 색인한 경우 필터링을 올바르게 작동시키려면 인덱스를 다시 생성해야 합니다. 이를 위해 gitlab:elastic:recreate_index와 gitlab:elastic:clear_index_status Rake 작업을 실행해야 합니다. 그 후 디렉터리에서 네임스페이스 또는 프로젝트를 제거하면 Elasticsearch 인덱스에서 데이터가 예상대로 삭제됩니다.

모든 프로젝트 레코드가 색인됨

네임스페이스 및 프로젝트 데이터의 양을 제한합니다 확인란을 선택하면:

  • 모든 프로젝트 레코드가 색인됩니다.
  • 연결된 데이터(이슈, Merge Request 또는 코드)는 색인되지 않습니다.

네임스페이스 또는 프로젝트를 지정하지 않으면 프로젝트 레코드만 색인됩니다.

사용자 지정 언어 분석기 활성화

smartcn 및/또는 kuromoji 분석 플러그인을 사용하여 중국어 및 일본어의 언어 지원을 개선할 수 있습니다.

언어 지원을 활성화하려면:

  1. 원하는 플러그인을 설치하고 플러그인 설치 안내에 따라 Elasticsearch 문서를 참조하세요. 플러그인은 클러스터의 각 노드에 설치되어야 하며 설치 후에 각 노드를 다시 시작해야 합니다. 플러그인 디렉터리은 이 섹션의 나중에 표에서 확인하실 수 있습니다.
  2. 왼쪽 사이드바에서 가장 아래쪽에 있는 관리 영역을 선택합니다.
  3. 설정 > 고급 검색을 선택합니다.
  4. 사용자 정의 분석기: 언어 지원을 찾습니다.
  5. 색인화를 위해 플러그인 지원을 활성화합니다.
  6. 변경 사항을 적용하려면 변경 사항 저장을 선택합니다.
  7. 제로 다운타임 재색인 또는 새로운 매핑이 포함된 새 인덱스를 생성하려면 모든 것을 다시 색인합니다.
  8. 이전 단계가 완료되면 검색을 위해 플러그인 지원을 활성화합니다.

고급 검색 비활성화

Elasticsearch 통합을 비활성화하려면:

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
  2. 설정 > 고급 검색(Advanced Search)을 선택합니다.
  3. Elasticsearch 색인화와 Elasticsearch 사용 시 검색 활성화 확인란을 지웁니다.
  4. 변경 사항 저장을 선택합니다.

  5. 선택 사항. 여전히 온라인 상태인 Elasticsearch 인스턴스의 경우 기존 색인을 삭제합니다: 

     # 옴니버스 설치
 sudo gitlab-rake gitlab:elastic:delete_index
    
 # 소스에서 설치한 경우
 bundle exec rake gitlab:elastic:delete_index RAILS_ENV=production

인덱싱 일시 중지 해제

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
  2. 설정 > 고급 검색(Advanced Search)을 선택합니다.
  3. 고급 검색을 확장합니다.
  4. Elasticsearch 인덱싱 일시 중지 확인란을 지웁니다.

제로 다운타임 재색인

이 재색인 방법의 아이디어는 Elasticsearch 재색인 API 및 Elasticsearch 인덱스 별칭 기능을 활용하여 작업을 수행하는 것입니다. 우리는 GitLab이 읽기/쓰기에 사용하는 ‘primary’ 인덱스에 연결되는 인덱스 별칭을 설정합니다. 재색인 프로세스가 시작되면 ‘primary’ 인덱스의 쓰기를 일시 중지합니다. 그런 다음 다른 인덱스를 만들고 재색인 API를 호출하여 인덱스 데이터를 새로운 인덱스로 이동시킵니다. 재색인 작업이 완료되면 새 인덱스에 연결된 인덱스 별칭으로 전환하여 새 ‘primary’ 인덱스가됩니다. 마지막으로 쓰기를 재개하고 전형적인 작업을 재개합니다.

제로 다운타임 재색인 사용

제로 다운타임 재색인을 사용하여 새 인덱스를 만들고 기존 데이터를 복사하지 않고 변경할 수없는 인덱스 설정이나 매핑을 구성할 수 있습니다. 데이터가 이미 색인되지 않은 경우 제로 다운타임 재색인은 검색 클러스터에 데이터를 추가하지 않습니다. 재색인을 시작하기 전에 모든 고급 검색 마이그레이션을 완료해야합니다.

고급 검색 관리를 통해 재색인 트리거하기

재색인 프로세스를 트리거하려면:

  1. 관리자로 GitLab 인스턴스에 로그인합니다.
  2. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
  3. 설정 > 고급 검색(Advanced Search)을 선택합니다.
  4. Elasticsearch 제로 다운타임 재색인을 확장합니다.
  5. 클러스터 재색인 트리거를 선택합니다.

재색인은 Elasticsearch 클러스터의 크기에 따라 시간이 오래 걸릴 수 있습니다.

이 프로세스가 완료되면 14일 후에 원래 색인이 삭제 예정입니다. 이 작업을 취소하려면 동일한 페이지에서 취소 버튼을 누릅니다.

재색인이 실행되는 동안 해당 섹션에서 진행 상황을 확인할 수 있습니다.

Elasticsearch 제로 다운타임 재색인

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
  2. 설정 > 고급 검색(Advanced Search)을 선택합니다.
  3. Elasticsearch 제로 다운타임 재색인을 확장하면 다음 옵션을 찾을 수 있습니다:
조각 배수

조각 배수는 재색인하는 동안 조각 수를 계산합니다.

GitLab은 매뉴얼 조각화를 사용하여 재색인을 효율적으로 안전하게 제어하여 사용자가 실패한 조각 만 다시 시도할 수 있습니다.

곱셈기의 기본값은 2이며 인덱스 당 샤드 수에 적용됩니다. 예를 들어이 값이 2이고 인덱스에 20개의 샤드가있는 경우 재색인 작업이 40 개의 조각으로 분할됩니다.

최대 실행 중인 조각

최대 실행 중인 조각 매개 변수의 기본값은 60이며 Elasticsearch 재색인 중에 동시에 실행되는 최대 조각 수에 해당합니다.

이 값을 너무 높게 설정하면 검색 및 쓰기로 클러스터가 과도하게 포화 될 수 있습니다. 이 값을 너무 낮게 설정하면 재색인 프로세스가 매우 오랜 시간이 걸릴 수 있습니다.

이에 대한 최상의 값은 클러스터 크기에 따라 달라지며, 재색인 중에 일시적으로 검색 성능 저하를 수용할 수 있는지, 재색인이 빠르게 완료되어 인덱싱을 계속하는 것이 얼마나 중요한지에 달려 있습니다.

가장 최근의 재색인 작업을 실패로 표시하고 인덱싱 재개하기

가끔은 완료되지 않은 재색인 작업을 포기하고 인덱싱을 재개하려고 할 수 있습니다. 다음 단계로 이 작업을 수행할 수 있습니다:

  1. 가장 최근의 재색인 작업을 실패로 표시합니다. 

     # 옴니버스 설치
 sudo gitlab-rake gitlab:elastic:mark_reindex_failed
    
 # 소스에서 설치한 경우
 bundle exec rake gitlab:elastic:mark_reindex_failed RAILS_ENV=production
  2. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
  3. 설정 > 고급 검색(Advanced Search)을 선택합니다.
  4. 고급 검색을 확장합니다.
  5. Pause Elasticsearch indexing 확인란을 지웁니다.

인덱스 무결성

  • 버전 15.10에서 도입되었으며 search_index_integrity라는 플래그로 제공됩니다. 기본적으로 비활성화됩니다.
  • 16.4 버전에서 일반적으로 사용 가능해집니다. 피처 플래그 search_index_integrity가 제거되었습니다.

인덱스 무결성은 누락된 리포지터리 데이터를 감지하고 수정합니다. 이 기능은 코드 검색이 결과를 반환하지 않을 때 자동으로 사용됩니다.

고급 검색 마이그레이션

백그라운드에서 실행중인 재색인 마이그레이션이 있으면 매뉴얼 개입이 필요하지 않습니다. 이는 보통 고급 검색에 새로운 기능이 추가되는 상황에서 발생하며, 이는 콘텐츠가 색인되는 방식을 추가하거나 변경할 때 발생합니다.

마이그레이션 사전 파일

각 마이그레이션은 ee/elastic/docs/ 폴더에 해당하는 사전 파일이 있으며 다음 정보를 포함합니다: 

name:
version:
description:
group:
milestone:
introduced_by_url:
obsolete:
marked_obsolete_by_url:
marked_obsolete_in_milestone:

예를 들어 마이그레이션이 도입되거나 폐기된 시점을 식별하는 데 이 정보를 사용할 수 있습니다.

보류 중인 마이그레이션 확인

보류 중인 고급 검색 마이그레이션을 확인하려면 이 명령을 실행합니다: 

curl "$CLUSTER_URL/gitlab-production-migrations/_search?size=100&q=*" | jq .

이 명령은 다음과 유사한 내용을 반환해야합니다: 

{
  "took": 14,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "gitlab-production-migrations",
        "_type": "_doc",
        "_id": "20230209195404",
        "_score": 1,
        "_source": {
          "completed": true
        }
      }
    ]
  }
}

마이그레이션과 관련된 문제를 해결하려면 elasticsearch.log 파일을 확인하십시오.

중단된 마이그레이션 다시 시도

일부 마이그레이션은 재시도 한도와 함께 빌드되어 있습니다. 마이그레이션이 재시도 제한 내에 완료되지 못하면 중지되고 고급 검색 통합 설정에 알림이 표시됩니다. 마이그레이션이 왜 중지되었는지 확인하고 변경 사항을 처리하기 전에 elasticsearch.log 파일을 확인하는 것이 좋습니다. 실패 원인을 수정한 것으로 여기면 “마이그레이션 재시도”를 선택하고 백그라운드에서 마이그레이션이 다시 시도되도록 예약됩니다.

마이그레이션을 성공시킬 수 없으면 첫째로 인덱스를 처음부터 다시 만드는 마지막 수단을 고려하십시오. 이렇게하면 새로 생성 된 인덱스가 정확하고 최신의 스키마로 재색인으로 인해 모든 마이그레이션을 건너 뛸 수 있습니다.

모든 마이그레이션이 주요 업그레이드를 진행하기 전에 완료되어야 함

주요 GitLab 버전으로 업그레이드하기 전에 해당 주요 버전 이전의 모든 마이너 버전의 마이그레이션을 마쳐야 합니다. 또한, 주요 버전 업그레이드를 진행하기 전에 중단된 마이그레이션을 재시도하여 해결해야 합니다. 자세한 정보는 새로운 주요 버전으로 업그레이드를 참조하세요.

제거된 마이그레이션은 사용되지 않는 것으로 표시됩니다. 새 버전에서 제거된 보류 중인 고급 검색 마이그레이션이 완료되지 않은 상태에서 GitLab을 업그레이드하면 해당 버전에서 제거된 보류 중인 마이그레이션은 실행되거나 재시도될 수 없습니다. 이 경우에는 처음부터 인덱스를 다시 만들어야 합니다.

생략 가능한 마이그레이션

생략 가능한 마이그레이션은 특정 조건이 충족될 때에만 실행됩니다. 예를 들어, 특정 버전의 Elasticsearch에 의존하는 마이그레이션이 해당 버전에 도달할 때까지 건너뛸 수 있습니다.

생략 가능한 마이그레이션이 제거된 시점에 실행되지 않았다면 변경을 적용하려면 인덱스를 다시 생성해야 합니다.

GitLab 고급 검색 Rake 작업

다음과 같은 Rake 작업을 사용할 수 있습니다:

다음은 일부 제공되는 Rake 작업입니다:

작업 설명
sudo gitlab-rake gitlab:elastic:info 고급 검색 통합에 대한 디버깅 정보 출력.
sudo gitlab-rake gitlab:elastic:index Elasticsearch 인덱싱을 활성화하고 gitlab:elastic:recreate_index, gitlab:elastic:clear_index_status, gitlab:elastic:index_group_entities, gitlab:elastic:index_projects, gitlab:elastic:index_snippets, 그리고 gitlab:elastic:index_users를 실행합니다.
sudo gitlab-rake gitlab:elastic:pause_indexing Elasticsearch 인덱싱을 일시 중단합니다. 변경 사항은 계속 추적됩니다. 클러스터/인덱스 마이그레이션에 유용합니다.
sudo gitlab-rake gitlab:elastic:resume_indexing Elasticsearch 인덱싱을 재개합니다.
sudo gitlab-rake gitlab:elastic:estimate_shard_sizes 데이터베이스 개수를 기반으로 각 인덱스의 샤드 크기를 추정합니다. 이 추정치는 리포지터리 데이터 (코드, 커밋, 위키)를 포함하지 않습니다. GitLab 16.11에 도입되었음.
sudo gitlab-rake gitlab:elastic:enable_search_with_elasticsearch Elasticsearch를 사용하여 고급 검색을 활성화합니다.
sudo gitlab-rake gitlab:elastic:disable_search_with_elasticsearch Elasticsearch를 사용한 고급 검색을 비활성화합니다.

환경 변수

Rake 작업 외에도 프로세스를 수정하는 데 사용할 수있는 몇 가지 환경 변수가 있습니다:

환경 변수 이름 데이터 유형 작업 내용
ID_TO 정수 값보다 작거나 같은 프로젝트만 색인화하도록 색인화자(Indexer)에 지시합니다.
ID_FROM 정수 값보다 크거나 같은 프로젝트만 색인화하도록 색인화자(Indexer)에 지시합니다.

프로젝트 범위 또는 특정 프로젝트 색인화

ID_FROM 및 ID_TO 환경 변수를 사용하여 제한된 수의 프로젝트를 색인화할 수 있습니다. 스테이징 색인화에 유용할 수 있습니다. 

root@git:~# sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=1 ID_TO=100

ID_FROM 및 ID_TO가 or equal to 비교를 사용하기 때문에 두 값이 동일한 프로젝트 ID로 설정되면 하나의 프로젝트만 색인화에 사용할 수 있습니다: 

root@git:~# sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=5 ID_TO=5
프로젝트 리포지터리 색인화 중...I, [2019-03-04T21:27:03.083410 #3384]  INFO -- : GitLab 사용자 / 테스트의 색인화(ID=33)...
I, [2019-03-04T21:27:05.215266 #3384]  INFO -- : GitLab 사용자 / 테스트의 색인화(ID=33)가 완료되었습니다!

고급 검색 색인 범위

검색을 수행할 때 GitLab 색인은 다음 스코프를 사용합니다:

스코프 이름 검색 대상
commits 커밋 데이터
projects 프로젝트 데이터 (기본값)
blobs 코드
issues 이슈 데이터
merge_requests Merge Request 데이터
milestones 마일스톤 데이터
notes 노트 데이터
snippets 스니펫 데이터
wiki_blobs 위키 내용
users 사용자
epics 에픽 데이터

튜닝

최적의 클러스터 구성 선택에 대한 지침

클러스터 구성을 선택하는 데 도움이 되는 기본적인 지침은 Elastic Cloud Calculator를 참조하십시오. 아래에서 자세한 정보를 찾을 수 있습니다.

  • 일반적으로, 회복성을 갖도록 하기 위해 적어도 하나의 복제본을 가진 2노드 클러스터 구성을 사용하려고합니다. 리포지터리 사용량이 빠르게 증가하는 경우, 가로 스케일링 (더 많은 노드 추가)을 미리 계획하십시오.
  • 검색 클러스터에 HDD 리포지터리를 사용하는 것은 성능에 악영향을 미칩니다. SSD 리포지터리(NVMe 또는 SATA SSD 드라이브)를 사용하는 것이 좋습니다.
  • 대규모 인스턴스에 대해 only nodes를 사용하는 것은 권장되지 않습니다. only nodes는 data nodes보다 작기 때문에 성능 및 고급 검색 마이그레이션에 영향을 미칠 수 있습니다.
  • GitLab Performance Tool을 사용하여 다양한 검색 클러스터 크기 및 구성에 대한 검색 성능을 평가할 수 있습니다.
  • Heap size는 물리적 RAM의 50% 이상으로 설정해서는 안됩니다. 또한, zero-based compressed oops 임계값을 초과해서는 안됩니다. 정확한 임계값은 다양하지만 대부분의 시스템에서는 26GB 정도 안전하며, 일부 시스템에서는 30GB까지 사용할 수도 있습니다. 자세한 내용은 Heap size settings 및 Setting JVM options를 참조하십시오.
  • refresh_interval은 인덱스별 설정입니다. 실시간 데이터가 필요하지 않은 경우 기본값 1초에서 더 큰 값으로 조정할 수 있습니다. 이는 신선한 결과를 얼마나 빨리 볼 수 있는지를 변경합니다. 이것이 중요하다면 기본값에 가능한 가깝게 유지해야 합니다.
  • 만약 많은 양의 중요한 색인 작업이 있는 경우, indices.memory.index_buffer_size를 30% 또는 40%로 높일 수 있습니다.

고급 검색 설정

Elasticsearch 샤드의 수

인덱스당 Elasticsearch 샤드 수를 적어도 5로 설정하십시오. 인덱스의 샤드 크기를 업데이트하려면 설정을 변경하고 중단 시간이 발생하지 않는 재색인을 트리거하십시오.

데이터베이스 데이터를 포함하는 인덱스
  • gitlab:elastic:estimate_shard_sizes 소개 in GitLab 16.11.

데이터베이스 데이터를 포함하는 인덱스의 경우:

  • gitlab-production-projects
  • gitlab-production-issues
  • gitlab-production-epics
  • gitlab-production-merge_requests
  • gitlab-production-notes
  • gitlab-production-users

Rake 작업 gitlab:elastic:estimate_shard_sizes를 실행하여 샤드 수를 결정합니다. 작업은 근사 문서 개수 및 샤드 및 복제본 크기에 대한 권장 사항을 반환합니다.

리포지터리 데이터를 포함하는 인덱스

리포지터리 데이터를 포함하는 인덱스의 경우:

  • gitlab-production
  • gitlab-production-wikis
  • gitlab-production-commits

평균 샤드 크기를 몇 GB에서 30GB 사이로 유지하십시오. 평균 샤드 크기가 30GB 이상으로 증가하면 인덱스의 샤드 크기를 늘리고 zero-downtime reindexing을 트리거하십시오. 클러스터가 건강하게 유지되려면 노드당 샤드 수는 구성된 heap 크기의 20배를 초과해서는 안됩니다. 예를 들어, 30GB 힙을 가진 노드의 경우 최대 600개의 샤드를가질 수 있습니다.

Elasticsearch 복제본 수

인덱스당 Elasticsearch 복제본 수를 1로 설정하십시오 (각 샤드에 하나의 복제본이 있습니다). 이 수는 0이 아니어야 하며, 노드 하나가 손실되면 인덱스가 손상됩니다.

대규모 인스턴스 효율적으로 색인화하는 방법

이 섹션은 다른 기본 지침이 색인화될 데이터가 많아 문제를 일으킬 경우 도움이 될 수 있습니다.

caution
대규모 인스턴스를 색인화하는 것은 많은 Sidekiq 작업을 생성합니다. 이 작업에 대비하여 확장 가능한 설정 또는 추가 Sidekiq 프로세스를 생성하여 이 작업에 대비해야합니다.
  1. Elasticsearch 호스트 및 포트를 구성.

  2. 빈 인덱스를 생성하십시오: 

    # 옴니버스 설치
sudo gitlab-rake gitlab:elastic:create_empty_index
   
# 소스 설치
bundle exec rake gitlab:elastic:create_empty_index RAILS_ENV=production

  3. 지금까지의 GitLab 인덱스를 다시 색인화 하는 경우, 인덱스 상태를 지우십시오: 

    # 옴니버스 설치
sudo gitlab-rake gitlab:elastic:clear_index_status
   
# 소스 설치
bundle exec rake gitlab:elastic:clear_index_status RAILS_ENV=production
  4. Elasticsearch 색인화 확인란을 선택.

  5. 대규모 Git 리포지터리의 색인화는 시간이 걸릴 수 있습니다. 프로세스를 가속화하기 위해 색인화 속도를 조정:

    • 일시적으로 refresh_interval을 높일 수 있습니다.

    • 복제본 수를 0으로 설정할 수 있습니다. 이 설정은 인덱스의 각 기본 샤드 복사본 수를 제어합니다. 따라서 0 복제본은 샤드를 노드 간에 복제하지 않도록 만들어 색인화 성능을 높일 수 있습니다. 이것은 신뢰성 및 쿼리 성능 측면에서 중요한 교역입니다. 초기 색인화 후에는 복제본 수를 고려된 값으로 설정하는 것이 중요합니다.

    색인화 시간이 20% 감소할 수 있습니다. 색인화가 완료된 후에는 refresh_interval 및 number_of_replicas를 원하는 값으로 다시 설정할 수 있습니다.

    note
    이 단계는 선택 사항이며 대규모 색인 작업을 크게 가속화할 수 있습니다.
    curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
     --data '{
       "index" : {
           "refresh_interval" : "30s",
           "number_of_replicas" : 0
       } }'

  6. 프로젝트 및 관련 데이터를 색인화하십시오: 

    # 옴니버스 설치
sudo gitlab-rake gitlab:elastic:index_projects
   
# 소스 설치
bundle exec rake gitlab:elastic:index_projects RAILS_ENV=production

    이로써 각 프로젝트에 대해 Sidekiq 작업을 큐잉합니다. 모니터링 > 백그라운드 작업 > 큐 탭에서 elastic_commit_indexer를 선택하거나, Rake 작업을 사용하여 색인화 상태를 쿼리할 수 있습니다. 

    # 옴니버스 설치
sudo gitlab-rake gitlab:elastic:index_projects_status
   
# 소스 설치
bundle exec rake gitlab:elastic:index_projects_status RAILS_ENV=production
   
색인화가 65.55% 완료되었습니다 (6555/10000 프로젝트)

    프로젝트의 색인화를 특정 범위의 프로젝트로 제한하려면 ID_FROM 및 ID_TO 매개변수를 제공할 수 있습니다: 

    # 옴니버스 설치
sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=1001 ID_TO=2000
   
# 소스 설치
bundle exec rake gitlab:elastic:index_projects ID_FROM=1001 ID_TO=2000 RAILS_ENV=production

    ID_FROM 및 ID_TO는 프로젝트 ID입니다. 두 매개변수는 모두 선택 사항입니다. 위의 예제는 ID 1001에서 (포함) ID 2000까지 모든 프로젝트를 색인화합니다.

    note
    gitlab:elastic:index_projects에 의해 큐잉된 프로젝트 색인 작업은 종종 중단될 수 있습니다. 많은 이유로 발생할 수 있지만 색인화 작업을 다시 실행하는 것은 항상 안전합니다.

    색인화 작업을 다시 실행하면 기존의 진행 상황을 모두 “잊도록” 하는 gitlab:elastic:clear_index_status Rake 작업을 사용할 수도 있습니다.

  7. 에픽, 그룹 위키, 개인 스니펫 및 사용자는 프로젝트와 연관되지 않으므로 별도로 색인화해야합니다: 

    # 옴니버스 설치
sudo gitlab-rake gitlab:elastic:index_epics
sudo gitlab-rake gitlab:elastic:index_group_wikis
sudo gitlab-rake gitlab:elastic:index_snippets
sudo gitlab-rake gitlab:elastic:index_users
   
# 소스 설치
bundle exec rake gitlab:elastic:index_epics RAILS_ENV=production
bundle exec rake gitlab:elastic:index_group_wikis RAILS_ENV=production
bundle exec rake gitlab:elastic:index_snippets RAILS_ENV=production
bundle exec rake gitlab:elastic:index_users RAILS_ENV=production

  8. 색인화 후에 복제 및 다시 refresh를 사용할 수 있습니다. (이전에 refresh_interval을 높인 경우에만): 

    curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
     --data '{
       "index" : {
           "number_of_replicas" : 1,
           "refresh_interval" : "1s"
       } }'

    위의 refresh를 활성화한 후 강제 Merge이 호출되어야합니다.

    Elasticsearch 6.x 이상의 경우 강제 Merge을 진행하기 전에 인덱스가 읽기 전용 모드에 있어야합니다. 

    curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' \
     --data '{
       "settings": {
         "index.blocks.write": true
       } }'

    그런 다음, 강제 Merge을 시작하십시오:

    ```shell curl –request POST ‘localhost:9200

삭제된 문서

GitLab 객체에 변경 또는 삭제가 이루어지면(Merge Request 설명이 변경되었을 때, 리포지터리의 기본 브랜치에서 파일이 삭제되었을 때, 프로젝트가 삭제되었을 때 등), 색인된 문서가 삭제됩니다. 그러나 이러한 삭제는 “소프트” 삭제이므로 “삭제된 문서”의 총 수와 따라서 낭비되는 공간이 늘어납니다. Elasticsearch는 지능적인 세그먼트 Merge을 통해 이러한 삭제된 문서를 제거합니다. 그러나 GitLab 설치에서의 활동량과 유형에 따라 색인에서 최대 50%의 낭비 공간이 발생할 수 있습니다.

일반적으로 기본 설정을 그대로 두고 Elasticsearch가 Merge하고 공간을 자동으로 회수하도록 권장합니다. 삭제된 문서 처리에 관한 Lucene의 핸들링에서는 “대체로 최대 세그먼트 크기를 줄이는 것 외에는 Lucene의 기본 설정을 그대로 두고 삭제가 언제 회수되는지에 대해 심각하게 걱정할 필요가 없다.”고 언급하고 있습니다.

그러나 일부 큰 규모의 설치에서는 Merge 정책 설정을 조정하고 싶어할 수도 있습니다:

  • index.merge.policy.max_merged_segment 크기를 기본 5GB에서 2GB 또는 3GB 정도로 줄이는 것을 고려해 보세요. Merge은 세그먼트의 삭제가 최소 50%인 경우에만 발생합니다. 더 작은 세그먼트 크기는 Merge이 더 자주 발생하도록 합니다. 

    curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' \
     --data '{
       "index" : {
         "merge.policy.max_merged_segment": "2gb"
       }
     }'

  • 또한 index.merge.policy.reclaim_deletes_weight를 조정할 수 있으며, 이는 얼마나 적극적으로 삭제를 대상으로 하는지를 제어합니다. 그러나 이로 인해 비용이 많이든 Merge 결정이 발생할 수 있으므로 이러한 설정을 변경하기 전에 트레이드오프를 이해해야 합니다. 

    curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' \
     --data '{
       "index" : {
         "merge.policy.reclaim_deletes_weight": "3.0"
       }
     }'

  • 삭제된 문서를 제거하기 위해 강제 Merge을 수행하지 마세요. 문서에는 이로 인해 회수되지 않을 수 있는 매우 큰 세그먼트가 발생할 수 있으며 중요한 성능 또는 가용성 문제를 발생시킬 수 있다는 경고가 포함되어 있습니다.

전용 Sidekiq 노드 또는 프로세스를 사용하여 대형 인스턴스 색인

caution
대부분의 인스턴스는 이를 구성할 필요가 없어야 합니다. 아래 단계는 라우팅 규칙의 고급 설정을 사용합니다. 작업의 완전한 손실을 방지하기 위해 라우팅 규칙의 영향에 대해 충분히 이해해야 합니다.

대규모 인스턴스를 색인하는 것은 많은 시간과 리소스를 소비할 수 있는 과정으로, Sidekiq 노드 및 프로세스를 압도할 수 있는 잠재적인 가능성을 가지고 있습니다. 이는 GitLab의 성능과 가용성에 부정적인 영향을 미칩니다.

GitLab에서 여러 개의 Sidekiq 프로세스를 시작할 수 있기 때문에 색인 큐에는 항상 전용 워커가 있고, 나머지 큐에는 경합을 피하려면 다른 전용 워커가 있도록 설정할 수 있습니다.

이를 위해 라우팅 규칙 옵션을 사용하여 Sidekiq이 작업 일치 쿼리를 기반으로 작업을 특정 큐로 라우팅할 수 있습니다.

이를 처리하기 위해 일반적으로 다음 두 가지 옵션 중 하나를 권장합니다. 다음 중 하나를 선택할 수 있습니다:

아래 단계를 위해 sidekiq['routing_rules'] 항목을 고려하세요:

  • "feature_category=global_search" 항목을 가진 sidekiq['queue_groups']의 하나의 프로세스는 모든 색인 작업을 global_search 큐로 경로 지정합니다.
  • "*" 항목을 가진 sidekiq['queue_groups']의 하나의 프로세스는 나머지 모든 색인 작업이 default 큐로 경로 지정합니다.

sidekiq['queue_groups']에 포함된 적어도 하나의 프로세스는 mailers 큐를 포함해야 하며, 그렇지 않으면 메일러 작업이 전혀 처리되지 않습니다.

note
라우팅 규칙(sidekiq['routing_rules'])은 모든 GitLab 노드(특히 GitLab 레일스 및 Sidekiq 노드)에서 동일해야 합니다.
caution
여러 프로세스를 시작할 때, 프로세스 수는 Sidekiq에 할당하려는 CPU 코어 수를 초과해서는 안 됩니다. 각 Sidekiq 프로세스는 하나의 CPU 코어만 사용할 수 있으며, 이는 이용 가능한 작업 부하 및 동시성 설정에 따라 결정됩니다. 자세한 내용은 어떻게 여러 Sidekiq 프로세스를 실행하는지를 참조하세요.

단일 노드에 두 개의 프로세스

하나의 노드에 인덱싱 및 비인덱싱 Sidekiq 프로세스를 작성하려면 다음을 수행하세요:

  1. Sidekiq 노드에서 /etc/gitlab/gitlab.rb 파일을 다음과 같이 변경합니다: 

    sidekiq['enable'] = true
sidekiq['queue_selector'] = false
   
sidekiq['routing_rules'] = [
   ["feature_category=global_search", "global_search"],
   ["*", "default"],
]
   
sidekiq['queue_groups'] = [
   "global_search", # global_search 큐를 수신하는 프로세스
   "default,mailers" # default 및 mailers 큐를 수신하는 프로세스
]
   
sidekiq['min_concurrency'] = 20
sidekiq['max_concurrency'] = 20
  2. 파일을 저장하고 GitLab을 다시 구성하여 변경 사항이 적용되도록 합니다.
  3. 다른 모든 레일스 및 Sidekiq 노드에서 sidekiq['routing_rules']이 위와 동일한지 확인합니다.
  4. 기존 작업을 이주하는 레일스 작업을 실행하세요:
note
GitLab을 다시 구성한 직후에 즉시 레일스 작업을 실행하는 것이 중요합니다. GitLab을 다시 구성한 후에는 기존 작업을 레일스 작업이 이주를 시작할 때까지 처리하지 않습니다.

두 노드에 각각 하나의 프로세스

이러한 큐 그룹을 두 노드에서 처리하려면:

  1. 인덱싱 Sidekiq 프로세스를 설정하려면 인덱싱 Sidekiq 노드에서 /etc/gitlab/gitlab.rb 파일을 다음과 같이 변경합니다: 

    sidekiq['enable'] = true
sidekiq['queue_selector'] = false
   
sidekiq['routing_rules'] = [
   ["feature_category=global_search", "global_search"],
   ["*", "default"],
]
   
sidekiq['queue_groups'] = [
  "global_search", # global_search 큐를 수신하는 프로세스
]
   
sidekiq['min_concurrency'] = 20
sidekiq['max_concurrency'] = 20

  2. 파일을 저장하고 GitLab을 다시 구성하여 변경 사항이 적용되도록 합니다.

  3. 비인덱싱 Sidekiq 프로세스를 설정하려면 비인덱싱 Sidekiq 노드에서 /etc/gitlab/gitlab.rb 파일을 다음과 같이 변경합니다: 

    sidekiq['enable'] = true
sidekiq['queue_selector'] = false
   
sidekiq['routing_rules'] = [
   ["feature_category=global_search", "global_search"],
   ["*", "default"],
]
   
sidekiq['queue_groups'] = [
   "default,mailers" # default 및 mailers 큐를 수신하는 프로세스
]
   
sidekiq['min_concurrency'] = 20
sidekiq['max_concurrency'] = 20
  4. 다른 모든 레일스 및 Sidekiq 노드에서 sidekiq['routing_rules']이 위와 동일한지 확인합니다.
  5. 파일을 저장하고 GitLab을 다시 구성하여 변경 사항이 적용되도록 합니다.

  6. 기존 작업을 이주하는 레일스 작업을 실행하세요: 

    sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued
note
GitLab을 다시 구성한 직후에 즉시 레일스 작업을 실행하는 것이 중요합니다. GitLab을 다시 구성한 후에는 기존 작업을 레일스 작업이 이주를 시작할 때까지 처리하지 않습니다.

기본 검색으로 되돌리기

가끔씩 Elasticsearch 색인 데이터에 문제가 발생할 수 있습니다. 그러한 경우 GitLab은 검색 결과가 없을 때 그 영역에서 기본 검색으로 돌아가는 것을 허용합니다. 이 “기본 검색”은 고급 검색을 전혀 사용하지 않은 것처럼 동작하며 다른 데이터 소스(예: PostgreSQL 데이터 및 Git 데이터)를 사용하여 검색합니다.

데이터 복구: Elasticsearch는 보조 데이터 리포지터리 일뿐

GitLab에서의 Elasticsearch 사용은 항상 보조 데이터 리포지터리로만 사용됩니다. 이는 Elasticsearch에 저장된 모든 데이터가 언제든지 특히 PostgreSQL 및 Gitaly로부터 다시 유도될 수 있다는 것을 의미합니다. 따라서 Elasticsearch 데이터 리포지터리가 어떤 이유로 손상된 경우에도 모든 것을 처음부터 다시 색인할 수 있습니다.