Redis 문제 해결

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

HA 설정이 예상대로 작동하려면 주의 깊게 처리해야 하는 여러 가동 컴포넌트가 있습니다.

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

  • Redis 머신
    • 6379에서 TCP 연결 수락
    • 다른 Redis 머신과 TCP를 통해 6379에서 연결
  • Sentinel 머신
    • 26379에서 TCP 연결 수락
    • 다른 Sentinel 머신과 TCP를 통해 26379에서 연결
    • 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

주 서버에 연결한 경우 연결된 복제본의 수와 각 연결의 세부 정보 디렉터리이 표시됩니다.

복제본인 경우 주 연결의 세부 정보와 up 또는 down 여부가 표시됩니다.

Redis 인스턴스에서 높은 CPU 사용률

기본적으로 GitLab은 600개 이상의 Sidekiq 대기열을 사용하며, 각 대기열은 Redis 디렉터리으로 저장됩니다. 각 Sidekiq 스레드는 긴 문자열로 나열된 모든 대기열에 대해 BRPOP 명령을 내립니다. 대기열 수와 BRPOP 호출 속도가 증가함에 따라 Redis CPU 활용이 증가합니다. GitLab 인스턴스에 많은 Sidekiq 프로세스가 있는 경우 이는 Redis CPU 활용률이 100%에 가깝게 만들 수 있습니다. 높은 CPU 활용률은 GitLab 성능을 크게 저하시킵니다.

Sidekiq로 인한 Redis CPU 사용률을 줄이려면 다음을 수행할 수 있습니다:

SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 옵션은 종료 및 연결로 인한 부하를 줄이지만 Sidekiq의 종료 지연시간을 늘립니다.

Sentinel 문제 해결

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

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

Redis 커넥터인 redis-rb가 Sentinel과 함께 작동하는 방식은 약간 직관적이지 않습니다. 리눅스 패키지에서 복잡성을 숨기려고 했지만 몇 가지 추가 구성이 필요합니다.

구성이 올바른지 확인하려면 다음을 수행하세요:

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

  2. Rails 콘솔에 입력합니다: 

    # 옴니버스 설치인 경우
sudo gitlab-rails console
   
# 소스 설치인 경우
sudo -u git rails console -e production

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

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

    이 화면을 열어두고 아래에 설명된대로 장애 조치를 발생시켜 보세요.

  4. 주 Redis에서 장애 조치를 발생시키려면 첫 번째 단계에서 Rails 콘솔로 다시 들어가고 다음을 실행합니다: 

    # 포트는 주 Redis 포트와 일치해야 하며, sleep 시간은 정의된 것보다 몇 초 더 커야 합니다.
redis-cli -h localhost -p 6379 DEBUG sleep 20
    caution
    이 작업은 서비스에 영향을 미치며 최대 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)에서 호스트 이름으로 사용되어야 합니다.)

의심스러울 때 Redis Sentinel 문서를 참조하세요.