Redis 문제 해결
HA 설정이 예상대로 작동하려면 신경써서 챙겨야 할 부분이 많습니다.
아래의 문제 해결을 진행하기 전에 방화벽 규칙을 확인하세요:
- Redis machines
-
6379에서 TCP 연결 수락 - 다른 Redis machines에 TCP를 통해
6379로 연결
-
- Sentinel machines
-
26379에서 TCP 연결 수락 - 다른 Sentinel machines에 TCP를 통해
26379로 연결 - Redis machines에 TCP를 통해
6379로 연결
-
기본 Redis 활동 확인
기본 Redis 활동 확인부터 Redis 문제 해결을 시작하세요:
- GitLab 서버의 터미널을 엽니다.
-
gitlab-redis-cli --stat를 실행하고 실행 중에 출력을 관찰합니다. - GitLab UI로 이동하여 그룹이나 프로젝트 개요, 이슈, 또는 리포지터리의 파일과 같은 여러 페이지를 찾아봅니다.
- 페이지를 찾아보는 동안
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 및 이전 버전을 사용하는 경우, Redis의 CPU 사용률을 개선하기 위해
SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT환경 변수를 늘립니다. GitLab 16.7 이상에서는 기본값이 5로 설정되어야 합니다.
SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 옵션은 연결 해제 및 연결로 인한 부하를 줄이지만, Sidekiq의 셧다운 지연을 늘립니다.
Sentinel 문제 해결
Redis::CannotConnectError: No sentinels available.와 같은 오류가 발생하면 구성 파일에 문제가 있을 수 있거나 이 문제와 관련이 있을 수 있습니다.
redis['master_name'] 및 redis['master_password']에 동일한 값이 정의되어 있는지 확인해야 합니다.
Redis 커넥터 redis-rb는 Sentinel과의 작동 방식이 약간 직관적이지 않습니다. 우리는 Linux 패키지 내에서 복잡성을 숨기려고 노력했지만 여전히 몇 가지 추가 구성이 필요합니다.
구성이 올바른지 확인하려면:
- GitLab 애플리케이션 서버에 SSH로 로그인합니다.
-
Rails 콘솔에 입력합니다:
# Omnibus 설치의 경우 sudo gitlab-rails console # 소스 설치의 경우 sudo -u git rails console -e production -
콘솔에서 실행합니다:
redis = Gitlab::Redis::SharedState.redis redis.info이 화면을 유지하고 아래에 설명된대로 장애 조치를 유발합니다.
-
Primary Redis에서 장애 조치를 유발하려면 Redis 서버에 SSH로 로그인하고 다음을 실행합니다:
# 포트는 기본 Redis 포트와 일치해야하며, sleep 시간은 정의된 시간보다 몇 초 더 커야합니다 redis-cli -h localhost -p 6379 DEBUG sleep 20이 작업은 서비스에 영향을 미치며 인스턴스가 최대 20초 동안 다운됩니다. 성공하면 그 이후에 회복해야 합니다. -
첫 번째 단계의 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 # 레디스 포트가 아닌 Sentinel을 가리킵니다
-
host: 10.0.0.2
port: 26379 # 레디스 포트가 아닌 Sentinel을 가리킵니다
-
host: 10.0.0.3
port: 26379 # 레디스 포트가 아닌 Sentinel을 가리킵니다
의심스러울 때는 Redis Sentinel 문서를 읽어보세요.
도움말