Redis 문제 해결

Tier: Free, Premium, Ultimate Offering: Self-Managed

HA(High Availability) 설정이 예상대로 작동하려면 주의 깊게 취급해야 할 부분이 많습니다.

다음과 같은 문제 해결을 진행하기 전에 방화벽 규칙을 확인하십시오.

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

기본적인 Redis 활동 확인

기본적인 Redis 활동 확인으로 Redis 문제 해결 시작:

  1. GitLab 서버의 터미널을 엽니다.
  2. gitlab-redis-cli --stat를 실행하고 실행 중에 출력을 관찰합니다.
  3. GitLab UI로 이동하여 그룹 또는 프로젝트 개요, 이슈 또는 리포지토리의 파일과 같은 여러 페이지를 둘러봅니다.
  4. 페이지를 둘러볼 때마다 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 성능을 크게 저하시킵니다.

Redis에서 Sidekiq로 인한 CPU 사용량을 줄이기 위해 다음을 수행할 수 있습니다:

SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 옵션은 연결 해제 및 연결하는데 드는 부하를 줄이지만 Sidekiq의 종료 지연을 증가시킵니다.

Sentinel 문제 해결

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

redis['master_name']과 Sentinel 노드에 정의한 것과 동일한 값을 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에서 장애 조치를 발생시키려면 첫 번째 단계의 Rails 콘솔에서 다음을 실행합니다: 

    redis.info

    잠시 후 다른 포트 번호를 볼 수 있어야 합니다(장애 조치/재연결 시간).

자체 컴파일된 설치물을 사용하는 Redis 문제 해결

Redis::CannotConnectError: No sentinels available.와 같은 GitLab에서 오류가 발생하는 경우 구성 파일에 문제가 있을 수 있거나 이상현상 이슈와 관련될 수 있습니다.

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  # 레디스 포트가 아닌 Sentinel을 가리켜야 함
    -
      host: 10.0.0.2
      port: 26379  # 레디스 포트가 아닌 Sentinel을 가리켜야 함
    -
      host: 10.0.0.3
      port: 26379  # 레디스 포트가 아닌 Sentinel을 가리켜야 함

의심스러울 때에는 Redis Sentinel 문서를 참조하십시오.