HA 설정이 예상대로 작동하려면 많은 구성 요소를 신중하게 관리해야 합니다.

아래 문제 해결을 진행하기 전에 방화벽 규칙을 확인하세요:

• Redis 머신
  • 6379 TCP 연결 허용
  • 6379 TCP를 통해 다른 Redis 머신에 연결
• Sentinel 머신
  • 26379 TCP 연결 허용
  • 26379 TCP를 통해 다른 Sentinel 머신에 연결
  • 6379 TCP를 통해 Redis 머신에 연결

기본 Redis 활동 확인#

기본 Redis 활동 확인으로 Redis 문제 해결을 시작하세요:

1. GitLab 서버에서 터미널을 엽니다.
2. gitlab-redis-cli --stat를 실행하고 실행 중인 출력을 관찰합니다.
3. GitLab UI로 이동하여 몇 개의 페이지를 탐색합니다. 그룹 또는 프로젝트 개요, 이슈, 리포지터리의 파일 등 어떤 페이지든 괜찮습니다.
4. stat 출력을 다시 확인하고 탐색할수록 keys, clients, requests, connections 값이 증가하는지 확인합니다. 숫자가 증가하면 기본 Redis 기능이 작동하고 GitLab이 연결할 수 있는 것입니다.

Redis 복제 문제 해결#

redis-cli 애플리케이션을 사용하여 각 서버에 연결하고 아래와 같이 info replication 명령을 전송하여 모든 것이 올바른지 확인할 수 있습니다.

/opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication

Primary Redis에 연결되면 연결된 replicas 수와 각각의 연결 세부 정보 목록이 표시됩니다:

# Replication
role:master
connected_replicas:1
replica0:ip=10.133.5.21,port=6379,state=online,offset=208037514,lag=1
master_repl_offset:208037658
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:206989083
repl_backlog_histlen:1048576

replica인 경우 프라이머리 연결 세부 정보와 up 또는 down 상태가 표시됩니다:

# Replication
role:replica
master_host:10.133.1.58
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
replica_repl_offset:208096498
replica_priority:100
replica_read_only:1
connected_replicas:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Redis 인스턴스의 높은 CPU 사용량#

기본적으로 GitLab은 600개 이상의 Sidekiq 큐를 사용하며 각각 Redis 목록으로 저장됩니다. 각 Sidekiq 스레드는 긴 문자열에 나열된 모든 큐와 함께 BRPOP 명령을 실행합니다. 큐 수와 BRPOP 호출 속도가 증가함에 따라 Redis CPU 사용률이 증가합니다. GitLab 인스턴스에 많은 Sidekiq 프로세스가 있는 경우 Redis CPU 사용률이 100%에 근접할 수 있습니다. 높은 CPU 사용률은 GitLab 성능을 크게 저하시킵니다.

Sidekiq으로 인한 Redis의 CPU 사용량을 줄이려면 다음을 모두 사용할 수 있습니다:

• 라우팅 규칙을 사용하여 Sidekiq 큐 수를 줄입니다.
• GitLab 16.6 이하를 사용하는 경우 SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 환경 변수를 늘려 Redis의 CPU 사용량을 개선합니다. GitLab 16.7 이상에서는 기본값이 5로 충분합니다.

SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 옵션은 해체 및 연결로 인한 오버헤드를 줄이지만 Sidekiq의 종료 지연이 증가합니다.

Sentinel 문제 해결#

Redis::CannotConnectError: No sentinels available.과 같은 오류가 발생하면 구성 파일에 문제가 있거나 이 이슈와 관련이 있을 수 있습니다.

sentinel 노드에 정의한 것과 동일한 값을 redis['master_name'] 및 redis['master_password']에 정의했는지 확인해야 합니다.

Redis 커넥터 redis-rb가 sentinel과 함께 작동하는 방식은 다소 직관적이지 않습니다. Linux 패키지에서 복잡성을 숨기려고 하지만 여전히 몇 가지 추가 구성이 필요합니다.

구성이 올바른지 확인하려면:

1. GitLab 애플리케이션 서버에 SSH로 접속합니다

2. Rails 콘솔로 진입합니다:

   # Omnibus 설치의 경우
   sudo gitlab-rails console
   
   # 소스 설치의 경우
   sudo -u git rails console -e production
   

3. 콘솔에서 실행합니다:

   redis = Gitlab::Redis::SharedState.redis
   redis.info
   

   이 화면을 열어두고 아래에 설명된 대로 페일오버를 트리거합니다.

4. 프라이머리 Redis에서 페일오버를 트리거하려면 Redis 서버에 SSH로 접속하여 다음을 실행합니다:

   # 포트는 프라이머리 redis 포트와 일치해야 하며, sleep 시간은 정의된 것보다 몇 초 더 커야 합니다
    redis-cli -h localhost -p 6379 DEBUG sleep 20
   

   [!warning] 이 작업은 서비스에 영향을 미치며 최대 20초 동안 인스턴스를 중단시킵니다. 성공하면 그 후에 복구되어야 합니다.

5. 첫 번째 단계에서 Rails 콘솔로 돌아가서 실행합니다:

   redis.info
   

   몇 초 지연(페일오버/재연결 시간) 후 다른 포트가 표시되어야 합니다.

소스 컴파일 설치에서 번들 외 Redis 문제 해결#

GitLab에서 Redis::CannotConnectError: No sentinels available.과 같은 오류가 발생하면 구성 파일에 문제가 있거나 이 업스트림 이슈와 관련이 있을 수 있습니다.

resque.yml 및 sentinel.conf가 올바르게 구성되어 있는지 확인해야 합니다. 그렇지 않으면 redis-rb가 제대로 작동하지 않습니다.

(sentinel.conf)에 정의된 master-group-name (gitlab-redis)은 GitLab(resque.yml)의 호스트명으로 반드시 사용해야 합니다:

# sentinel.conf:
sentinel monitor gitlab-redis 10.0.0.1 6379 2
sentinel down-after-milliseconds gitlab-redis 10000
sentinel config-epoch gitlab-redis 0
sentinel leader-epoch gitlab-redis 0

# resque.yaml
production:
  url: redis://:myredispassword@gitlab-redis/
  sentinels:
    -
      host: 10.0.0.1
      port: 26379  # point to sentinel, not to redis port
    -
      host: 10.0.0.2
      port: 26379  # point to sentinel, not to redis port
    -
      host: 10.0.0.3
      port: 26379  # point to sentinel, not to redis port

확실하지 않은 경우 Redis Sentinel 문서를 읽으세요.