Redis 문제 해결

요약

HA 구성이 의도대로 동작하려면 세심하게 관리해야 하는 요소가 많습니다. 아래 문제 해결 절차를 진행하기 전에 방화벽 규칙을 확인합니다: Redis 문제 해결은 기본 Redis 동작 확인부터 시작합니다: 각 서버에 redis-cli 애플리케이션으로 연결해 아래와 같이 info replication 명령을 보내면 모든 설정이 올바른지 확인할 수 있습니다.

HA 구성이 의도대로 동작하려면 세심하게 관리해야 하는 요소가 많습니다.

아래 문제 해결 절차를 진행하기 전에 방화벽 규칙을 확인합니다:

Redis 머신
- 6379에서 TCP 연결을 수신합니다
- 6379에서 TCP로 다른 Redis 머신에 연결합니다
Sentinel 머신
- 26379에서 TCP 연결을 수신합니다
- 26379에서 TCP로 다른 Sentinel 머신에 연결합니다
- 6379에서 TCP로 Redis 머신에 연결합니다

기본 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 이하를 사용한다면 SIDEKIQ_SEMI_RELIABLE_FETCH_TIMEOUT 환경 변수를 늘려 Redis의 CPU 사용량을 개선합니다. 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 콘솔에 들어갑니다:

# For Omnibus installations
sudo gitlab-rails console

# For source installations
sudo -u git rails console -e production

콘솔에서 다음을 실행합니다:
```
redis = Gitlab::Redis::SharedState.redis
redis.info
```
이 화면을 열어 둔 채 아래 설명대로 장애 조치를 유발합니다.
기본 Redis에서 장애 조치를 유발하려면 Redis 서버에 SSH로 접속해 다음을 실행합니다:
```
# port must match your primary redis port, and the sleep time must be a few seconds bigger than defined one
 redis-cli -h localhost -p 6379 DEBUG sleep 20
```
[!warning] 이 작업은 서비스에 영향을 주며 최대 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  # point to sentinel, not to redis port
    -
      host: 10.0.0.2
      port: 26379  # point to sentinel, not to redis port
    -
      host: 10.0.0.3
      port: 26379  # point to sentinel, not to redis port

확실하지 않을 때는 Redis Sentinel 문서를 참고합니다.