자체 인스턴스 제공을 통한 Redis 복제 및 장애 조치

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

GitLab를 클라우드 공급 업체에서 호스팅하는 경우 Redis에 대해 관리형 서비스를 선택적으로 사용할 수 있습니다. 예를 들어 AWS는 Redis를 실행하는 ElastiCache를 제공합니다.

또는, Linux 패키지와 별도로 자체 Redis 인스턴스를 관리할 수 있습니다.

요구 사항

자체 Redis 인스턴스를 제공하기 위한 요구 사항은 다음과 같습니다.

  • 필요한 최소 Redis 버전을 요구 사항 페이지에서 찾습니다.
  • 스탠드얼론 Redis 또는 Sentinel로 Redis 고가용성을 지원합니다. Redis Cluster는 지원되지 않습니다.
  • AWS ElastiCache와 같은 클라우드 공급 업체에서 관리되는 Redis는 잘 작동합니다. 이러한 서비스가 고가용성을 지원하는 경우 Redis Cluster 유형이 아닌지 확인하십시오.

Redis 노드의 IP 주소 또는 호스트 이름, 포트, 그리고 (필요한 경우) 암호를 기록하세요.

클라우드 공급 업체의 관리형 서비스로서의 Redis

  1. 요구 사항에 따라 Redis를 설정합니다.

  2. GitLab 응용 프로그램 서버를 /etc/gitlab/gitlab.rb 파일에서 외부 Redis 서비스에 대한 적절한 연결 세부 정보로 구성합니다.

    단일 Redis 인스턴스 사용 시: 

    redis['enable'] = false
   
gitlab_rails['redis_host'] = '<redis_instance_url>'
gitlab_rails['redis_port'] = '<redis_instance_port>'
   
# Redis 노드에서 Redis 인증이 구성된 경우 필요함
gitlab_rails['redis_password'] = '<redis_password>'
   
# 인스턴스가 Redis SSL을 사용하는 경우 true로 설정
gitlab_rails['redis_ssl'] = true

    별도의 Redis Cache 및 Persistent 인스턴스 사용 시: 

    redis['enable'] = false
   
# 기본 Redis 연결
gitlab_rails['redis_host'] = '<redis_persistent_instance_url>'
gitlab_rails['redis_port'] = '<redis_persistent_instance_port>'
gitlab_rails['redis_password'] = '<redis_persistent_password>'
   
# 인스턴스가 Redis SSL을 사용하는 경우 true로 설정
gitlab_rails['redis_ssl'] = true
   
# Redis Cache 연결
# SSL 사용 시 `redis://`을 `rediss://`로 바꿉니다
gitlab_rails['redis_cache_instance'] = 'redis://:<redis_cache_password>@<redis_cache_instance_url>:<redis_cache_instance_port>'

  3. 변경 사항이 적용되도록 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

삭제 정책 설정

단일 Redis 인스턴스 실행 시, 삭제 정책을 noeviction으로 설정해야 합니다.

별도의 Redis Cache 및 Persistent 인스턴스를 실행하는 경우, Cache는 allkeys-lru (LRU)로 설정되어야 하며, Persistent는 noeviction으로 설정되어야 합니다.

이 설정은 클라우드 공급 업체 또는 서비스에 따라 다르지만 보통 다음과 같은 설정과 값을 사용하여 캐시를 구성합니다.

  • maxmemory-policy = allkeys-lru
  • maxmemory-samples = 5

자체 Redis 서버를 사용한 복제 및 장애 조치

이 문서는 별도로 Redis를 설치하고 Linux 패키지와 함께 제공되는 것이 아닌 확장 가능한 Redis 설정을 구성하는 방법에 대한 문서입니다. 그러나 Linux 패키지를 사용하는 것이 권장되며 GitLab에 특별히 최적화되었으며 Redis를 지원하는 것에 신경씁니다.

또한 /home/git/gitlab/config/resque.yml에 대한 모든 참조를 고급 Redis 설정에 맞게 재정의할 수 있으며 구성 파일 문서에서 설명합니다.

별도의 단계로 진행하기 전에 Linux 패키지 Redis HA의 복제 및 장애 조치 설문지를 반드시 읽으십시오. Redis 구성에 중요한 정보가 포함되어 있기 때문에 이 가이드를 진행하기 전에 읽어 보십시오.

새로운 Redis 인스턴스를 설정하기 전에 다음 요구 사항을 준비해야 합니다.

  • 이 가이드에서 설명하는 모든 Redis 서버는 소켓 대신 TCP 연결을 사용하도록 구성해야 합니다. Redis를 TCP 연결로 구성하려면 Redis 구성 파일에서 bind와 port를 정의해야 합니다. 모든 인터페이스 (0.0.0.0)에 바인딩하거나 원하는 인터페이스의 IP를 지정할 수 있습니다(예: 내부 네트워크 중 하나).
  • Redis 3.2부터 외부 연결을 수신하려면 비밀번호를 정의해야 합니다(requirepass).
  • Sentinel을 사용하는 경우 같은 인스턴스에서 레플리카 암호 정의 (masterauth)에 대해 동일한 암호를 정의해야 합니다.

또한 Linux 패키지로 Redis 복제 및 장애 조치에 설명된 선행 조건을 읽으십시오.

단계 1. 주요 Redis 인스턴스 구성

Redis 주요 인스턴스 IP가 10.0.0.1로 가정됩니다.

  1. Redis 설치.

  2. /etc/redis/redis.conf 편집: 

    ## 다른 기계에서 연락할 수 있는 로컬 IP를 가리키도록 `bind` 주소를 정의합니다.
## 실제로 외부 접근 가능한 IP에 바인딩해야 하는 경우 추가 방화벽 규칙을 추가하여 무단 액세스를 방지합니다:
bind 10.0.0.1
   
## 다른 기계가 연결할 수 있도록 `port`를 정의하여 redis가 TCP에서 수신하도록 합니다(기본 포트는 `6379`).
port 6379
   
## 암호 인증 설정(모든 노드에 동일한 암호 사용).
## Redis를 Sentinel과 함께 사용하도록 설정할 때는 `requirepass`와 `masterauth`에 동일한 암호를 정의해야 합니다.
requirepass redis-password-goes-here
masterauth redis-password-goes-here
  3. 변경 사항이 적용되도록 Redis 서비스를 다시 시작합니다.

단계 2. 복제 Redis 인스턴스 구성

Redis 복제 인스턴스 IP가 10.0.0.2로 가정됩니다.

  1. Redis 설치.

  2. /etc/redis/redis.conf 편집: 

    ## 다른 기계에서 연락할 수 있는 로컬 IP를 가리키도록 `bind` 주소를 정의합니다.
## 실제로 외부 접근 가능한 IP에 바인딩해야 하는 경우 추가 방화벽 규칙을 추가하여 무단 액세스를 방지합니다:
bind 10.0.0.2
   
## 다른 기계가 연결할 수 있도록 `port`를 정의하여 redis가 TCP에서 수신하도록 합니다(기본 포트는 `6379`).
port 6379
   
## 암호 인증 설정(모든 노드에 동일한 암호 사용).
## Redis를 Sentinel과 함께 사용하도록 설정할 때는 `requirepass`와 `masterauth`에 동일한 암호를 정의해야 합니다.
requirepass redis-password-goes-here
masterauth redis-password-goes-here
   
## `replicaof`를 사용하여 IP 및 포트가 있는 Redis 주요 인스턴스를 가리키도록 정의합니다.
replicaof 10.0.0.1 6379
  3. 변경 사항이 적용되도록 Redis 서비스를 다시 시작합니다.
  4. 다른 복제 노드에 대해 다시 단계를 수행합니다.

단계 3. Redis Sentinel 인스턴스 구성

Sentinel은 특별한 유형의 Redis 서버입니다. 대부분의 기본 구성 옵션을 정의할 수 있으며, 특정 옵션은 sentinel 접두사로 시작합니다.

Redis Sentinel이 10.0.0.1 주요 Redis 인스턴스와 동일한 인스턴스에 설치되었다고 가정합니다(설정 중 일부는 주요 설정과 중복될 수 있습니다).

  1. Redis Sentinel 설치.

  2. /etc/redis/sentinel.conf 편집: 

    ## 다른 기계에서 연락할 수 있는 로컬 IP를 가리키도록 `bind` 주소를 정의합니다.
## 실제로 외부 접근 가능한 IP에 바인딩해야 하는 경우 추가 방화벽 규칙을 추가하여 무단 액세스를 방지합니다:
bind 10.0.0.1
   
## 다른 기계가 연결할 수 있도록 `port`를 정의하여 Sentinel이 TCP에서 수신하도록 합니다 (기본 포트는 `6379`).
port 26379
   
## 암호 인증 설정 (`sentinel auth-pass`를 사용하여 Redis 주요 및 복제 인스턴스에 정의된 동일한 공유 암호를 정의합니다).
requirepass redis-password-goes-here
masterauth redis-password-goes-here
   
## `sentinel monitor`를 사용하여 Redis 주요 노드의 IP 및 포트, 장애 조치를 시작하기 위해 필요한 쿼럼을 정의합니다.
sentinel monitor gitlab-redis 10.0.0.1 6379 2
   
## `sentinel down-after-milliseconds`를 사용하여 응답하지 않는 서버를 다운으로 간주하는 시간(ms)을 정의합니다.
sentinel down-after-milliseconds gitlab-redis 10000
   
## `sentinel failover_timeout`에 대한 값을 정의합니다. 여러 의미가 있습니다:
##
## * 동일한 주요에서 이전 장애 조치 후 같은 주요에 대해 현재 설정에 의해 이미 특정 시간 동안 장애 조치를 다시 시작하기 위한 시간은 장애 조치 시간의 두 배입니다.
##
## * Sentinel이 현재 구성에 따라 잘못된 주요에 대해 복사본을 복제하도록 강제하려면 정확한 장애 조치 시간(특정 Sentinel이 구성 오류를 감지한 이후부터 카운팅)은 장애 조치 시간입니다.
##
## * 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간 (아직 확정되지 않은 상태의 장애 조치를 NO ONE의 REPLICAOF로써 완료하지 않았을 때).
##
## * 최대 일시적 병렬 복제를 사용하여 모든 복사본이 새 주요의 복사본으로 다시 구성되기까지 장애 조치가 대기하는 최대 시간. 그러나 이 시간 이후에도 Sentinels에 의해 복사본이 완전히 다시 구성되지만 정확한 병렬 동기화 진행은 지정된대로 이루어지지 않습니다.
sentinel failover_timeout 30000
  3. 변경 사항이 적용되도록 Redis 서비스를 다시 시작합니다.
  4. 다른 Sentinel 노드에 대해 다시 단계를 수행합니다.

단계 4. GitLab 애플리케이션 구성

새로운 설치나 기존 설치에서 언제든지 Sentinel 지원을 활성화 또는 비활성화할 수 있습니다. GitLab 애플리케이션 관점에서는 모든 것이 Sentinel 노드의 올바른 자격 증명만 필요합니다.

모든 Sentinel 노드의 디렉터리이 필요하지 않지만, 장애 발생 시 적어도 하나의 디렉터리된 노드에 액세스해야 합니다.

다음 단계는 기본적으로 Redis 또는 Sentinel과 동일한 기계에 없어야 할 GitLab 애플리케이션 서버에서 수행해야 합니다.

  1. 예시를 따라 /home/git/gitlab/config/resque.yml을 편집하고 resque.yml.example에 포인팅하는 Sentinel 라인을 주석 처리 해제하고, 올바른 서버 자격 증명을 가리키도록 합니다: 

    # resque.yaml
production:
  url: redis://:redi-password-goes-here@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을 가리킵니다.

  2. 변경 사항이 적용되려면 GitLab을 다시 시작하세요.

1(primary), 2(replica), 3(sentinel) 최소 구성 예시

이 예시에서는 모든 서버가 10.0.0.x 범위의 내부 네트워크 인터페이스를 갖고 있으며, 이러한 IP를 사용하여 서로 연결할 수 있다고 가정합니다.

실제 사용에서는 다른 기계에서의 무단 액세스를 방지하고 외부(인터넷)의 트래픽을 차단하기 위해 방화벽 규칙을 설정해야 합니다.

이 예에서는 Sentinel 1이 Redis Primary와 동일한 기계에 구성되고, Sentinel 2는 Replica 1과 동일한 기계에 구성되며, Sentinel 3은 Replica 2와 동일한 기계에 구성됩니다.

다음은 각 기계 및 할당된 IP의 디렉터리과 설명입니다:

  • 10.0.0.1: Redis Primary + Sentinel 1
  • 10.0.0.2: Redis Replica 1 + Sentinel 2
  • 10.0.0.3: Redis Replica 2 + Sentinel 3
  • 10.0.0.4: GitLab 애플리케이션

초기 구성 후, Sentinel 노드에 의해 장애 조치가 시작되면 Redis 노드가 다시 구성되고 Primary가 영구적으로 변경되며(redis.conf를 포함하여), 새로운 장애 조치가 다시 시작될 때까지 다른 노드로 변경됩니다.

sentinel.conf도 마찬가지로 초기 실행 후에 재정의되며, 새로운 sentinel 노드가 Primary를 감시하기 시작하거나 장애 조치가 다른 Primary 노드를 활성화할 때마다 재정의됩니다.

Redis Primary 및 Sentinel 1 구성 예시

  1. /etc/redis/redis.conf에서: 

    bind 10.0.0.1
port 6379
requirepass redis-password-goes-here
masterauth redis-password-goes-here

  2. /etc/redis/sentinel.conf에서: 

    bind 10.0.0.1
port 26379
sentinel auth-pass gitlab-redis redis-password-goes-here
sentinel monitor gitlab-redis 10.0.0.1 6379 2
sentinel down-after-milliseconds gitlab-redis 10000
sentinel failover_timeout 30000

  3. 변경 사항이 적용되려면 Redis 서비스를 다시 시작하세요.

Redis Replica 1 및 Sentinel 2 구성 예시

  1. /etc/redis/redis.conf에서: 

    bind 10.0.0.2
port 6379
requirepass redis-password-goes-here
masterauth redis-password-goes-here
replicaof 10.0.0.1 6379

  2. /etc/redis/sentinel.conf에서: 

    bind 10.0.0.2
port 26379
sentinel auth-pass gitlab-redis redis-password-goes-here
sentinel monitor gitlab-redis 10.0.0.1 6379 2
sentinel down-after-milliseconds gitlab-redis 10000
sentinel failover_timeout 30000

  3. 변경 사항이 적용되려면 Redis 서비스를 다시 시작하세요.

Redis Replica 2 및 Sentinel 3 구성 예시

  1. /etc/redis/redis.conf에서: 

    bind 10.0.0.3
port 6379
requirepass redis-password-goes-here
masterauth redis-password-goes-here
replicaof 10.0.0.1 6379

  2. /etc/redis/sentinel.conf에서: 

    bind 10.0.0.3
port 26379
sentinel auth-pass gitlab-redis redis-password-goes-here
sentinel monitor gitlab-redis 10.0.0.1 6379 2
sentinel down-after-milliseconds gitlab-redis 10000
sentinel failover_timeout 30000

  3. 변경 사항이 적용되려면 Redis 서비스를 다시 시작하세요.

GitLab 애플리케이션의 구성 예시

  1. /home/git/gitlab/config/resque.yml을 편집하세요: 

    production:
  url: redis://:redis-password-goes-here@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을 가리킵니다.

  2. 변경 사항이 적용되려면 GitLab을 다시 시작하세요.

문제 해결

Redis 문제 해결 가이드를 참조하세요.