Redis 문제 해결
Offering: Self-managed
HA 설정이 예상대로 작동하려면 주의 깊게 관리해야 할 많은 이동 부품이 있습니다.
아래의 문제 해결을 진행하기 전에 방화벽 규칙을 확인하세요:
- Redis 머신
-
6379에서 TCP 연결 허용 -
6379에서 다른 Redis 머신과 TCP로 연결
-
- Sentinel 머신
-
26379에서 TCP 연결 허용 -
26379에서 다른 Sentinel 머신과 TCP로 연결 -
6379에서 Redis 머신과 TCP로 연결
-
기본 Redis 활동 확인
기본 Redis 활동 확인으로 Redis 문제 해결을 시작하세요:
-
GitLab 서버에서 터미널을 엽니다.
-
gitlab-redis-cli --stat를 실행하고 실행되는 동안 출력을 관찰합니다. -
GitLab UI로 이동하여 여러 페이지를 탐색합니다. 그룹 또는 프로젝트 개요, 문제 또는 리포지토리의 파일 등 어떤 페이지든 됩니다.
-
stat출력을 다시 확인하고 브라우징하는 동안keys,clients,requests,connections값이 증가하는지 확인합니다. 숫자가 증가하면 기본 Redis 기능이 작동하고 GitLab이 Redis에 연결할 수 있음을 의미합니다.
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 명령을 발행합니다.
Redis CPU 사용량은 큐의 수와 BRPOP 호출의 비율이 증가함에 따라 증가합니다. 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']에 대한 값을
당신의 sentinel 노드에서 정의한 값과 동일하게 정의해야 합니다.
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이 화면을 열어 두고 아래에 설명된 대로 장애 조치를 트리거합니다.
-
기본 Redis에서 장애 조치를 트리거하려면, Redis 서버에 SSH 접속 후 다음을 실행합니다:
# 포트는 기본 Redis 포트와 일치해야 하며, 지연 시간은 정의된 것보다 몇 초 더 길어야 합니다. 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을 가리켜야 하며, redis 포트는 아님
-
host: 10.0.0.2
port: 26379 # sentinel을 가리켜야 하며, redis 포트는 아님
-
host: 10.0.0.3
port: 26379 # sentinel을 가리켜야 하며, redis 포트는 아님
확신이 서지 않으면, Redis Sentinel 문서를 읽어보세요.
도움말