Redis 문제 해결
HA 설정이 예상대로 작동하려면 주의 깊게 살펴봐야 할 사항이 많이 있습니다.
아래의 troubleshooting을 진행하기 전에 방화벽 규칙을 확인하세요:
- Redis machines
-
6379포트에서 TCP 연결 허용 - 다른 Redis machines로
6379포트에서 TCP로 연결
-
- Sentinel machines
-
26379포트에서 TCP 연결 허용 - 다른 Sentinel machines로
26379포트에서 TCP로 연결 - Redis machines로
6379포트에서 TCP로 연결
-
기본 Redis 활동 확인
기본 Redis 활동 확인으로 Redis troubleshooting을 시작하세요:
- 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의 수와 각각의 연결 세부 정보 목록을 확인할 수 있습니다.
replica인 경우, 주 연결의 세부 정보와 up 또는 down 상태를 확인할 수 있습니다.
Redis 인스턴스의 고 CPU 사용률
기본적으로 GitLab은 각각 Redis 목록으로 저장된 600개 이상의 Sidekiq 큐를 사용합니다. 각 Sidekiq 스레드는 긴 문자열에 나열된 모든 큐에서 BRPOP 명령을 발행합니다.
큐의 수와 BRPOP 호출률이 증가함에 따라 Redis CPU 사용률이 증가합니다. GitLab 인스턴스에 많은 Sidekiq 프로세스가 있으면 Redis CPU 사용률이 100%에 가까이 증가할 수 있습니다. 높은 CPU 사용률은 GitLab 성능을 현저하게 저하시킵니다.
Sidekiq의 CPU 사용률을 줄이려면 다음을 할 수 있습니다:
- routing rules를 사용하여 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 콘솔에 들어갑니다:
# 옴니버스 설치인 경우 sudo gitlab-rails console # 소스 설치인 경우 sudo -u git rails console -e production -
콘솔에서 실행합니다:
redis = Gitlab::Redis::SharedState.redis redis.info이 화면을 열어두고 아래에 설명된 대로 장애 근원을 유발하세요.
-
기본 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.yml
production:
url: redis://:myredispassword@gitlab-redis/
sentinels:
-
host: 10.0.0.1
port: 26379 # redis 포트가 아닌 sentinel을 가리켜야 합니다
-
host: 10.0.0.2
port: 26379 # redis 포트가 아닌 sentinel을 가리켜야 합니다
-
host: 10.0.0.3
port: 26379 # redis 포트가 아닌 sentinel을 가리켜야 합니다
의심스럽다면, Redis Sentinel 문서를 읽어보세요.
도움말