• 요구 사항
• 클라우드 공급업체에서 관리형 서비스로서의 Redis
  • 제거 정책 설정
• 본인의 Redis 서버에서의 복제 및 장애 조치
  • 단계 1. 주 비 Redis 인스턴스 설정
  • 단계 2. 레플리카 Redis 인스턴스 구성
  • 단계 3. Sentinel Redis 인스턴스 구성
  • 단계 4. GitLab 애플리케이션 구성
• 1차, 2개의 복제본 및 3개의 센티넬이 포함된 최소 구성의 예시
  • Redis Primary 및 센티넬 1을 위한 구성 예시
  • Redis 복제본 1과 센티넬 2를 위한 구성 예시
  • Redis 복제본 2와 센티넬 3을 위한 구성 예시
  • GitLab 애플리케이션의 구성 예시
• 문제 해결

Redis 복제 및 장애 조치를 제공하여 고유의 인스턴스 제공

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. /etc/gitlab/gitlab.rb 파일에서 외부 Redis 서비스에 대한 적절한 연결 세부 정보로 GitLab 애플리케이션 서버를 구성합니다.

   단일 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(Least Recently Used) 캐시로 구성되어야 하며, Persistent는 noeviction으로 설정해야 합니다.

이를 구성하는 것은 클라우드 공급업체 또는 서비스에 따라 다를 수 있지만, 일반적으로 다음 설정 및 값이 캐시를 구성합니다.

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

본인의 Redis 서버에서의 복제 및 장애 조치

본인이 설치하고 Linux 패키지와 함께 제공되는 것이 아닌 독립적으로 Redis를 사용할 때 확장 가능한 Redis 설정을 구성하기 위한 설명서입니다. Linux 패키지를 사용하는 것이 권장됩니다. Linux 패키지를 GitLab에 특별히 최적화하고 Redis를 지원되는 최신 버전으로 업그레이드하는 것을 책임집니다.

또한, Redis 확인에 명시된 고급 Redis 설정에 따라 /home/git/gitlab/config/resque.yml에 대한 모든 참조를 재정의할 수도 있음에 유의하십시오. 각별히 중요한 것은 Linux 패키지 Redis HA의 복제 및 장애 조치 문서를 읽는 것입니다. Redis 구성에 중요한 정보를 제공하기 때문에 해당 가이드를 읽은 후 이 가이드를 이어서 진행하세요.

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

• 이 가이드의 모든 Redis 서버는 소켓 대신 TCP 연결을 사용하도록 구성되어야 합니다. Redis를 TCP 연결로 구성하려면 Redis 구성 파일에서 bind 및 port를 모두 정의해야 합니다. 모든 인터페이스(0.0.0.0)에 바인딩하거나 원하는 인터페이스의 IP를 지정할 수 있습니다(예: 내부 네트워크에서의 IP).
• Redis 3.2 이후부터 외부 연결 수신에 대한 암호를 정의해야 합니다(requirepass).
• Redis를 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
   
   ## 다른 기계가 연결할 수 있도록 Redis를 TCP로 수신하도록 `port`를 정의하세요 (기본 포트는 `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
   
   ## 다른 기기가 연결할 수 있도록 Redis가 TCP로 수신하도록 `port`를 정의합니다 (기본 포트는 `6379`).
   port 6379
   
   ## 비밀번호 인증 설정 (모든 노드에서 동일한 비밀번호 사용).
   ## Sentinel과 사용하도록 Redis를 설정할 때는 `requirepass`와 `masterauth`에 동일한 비밀번호를 정의해야 합니다.
   requirepass 여기에-redis-비밀번호-입력
   masterauth 여기에-redis-비밀번호-입력
   
   ## IP 및 포트로 Redis 기본 인스턴스를 가리키는 `replicaof` 정의.
   replicaof 10.0.0.1 6379
   

3. 변경 사항이 적용되도록 Redis 서비스를 다시 시작합니다.
4. 나머지 레플리카 노드에 대해 위 단계를 다시 진행합니다.

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

Sentinel은 특수 유형의 Redis 서버입니다. redis.conf에서 정의할 수 있는 기본 구성 옵션 대부분을 상속받지만, 특정 설정은 sentinel 접두어로 시작합니다.

Redis Sentinel이 IP 10.0.0.1에 설치되어 있다고 가정합니다 (일부 설정은 기본과 중복될 수 있음):

1. Redis Sentinel 설치.

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

   ## 다른 기기에서 액세스할 수 있는 로컬 IP를 가리키는 `bind` 주소를 정의합니다.
   ## 외부 액세스 가능한 IP에 바인딩이 필요한 경우, 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
   bind 10.0.0.1
   
   ## 다른 기기가 연결할 수 있도록 Sentinel이 TCP로 수신하도록 `port`를 정의합니다 (기본 포트는 `6379`).
   port 26379
   
   ## 비밀번호 인증 설정 (모든 노드에서 동일한 비밀번호 사용).
   ## Sentinel과 사용하도록 Redis를 설정할 때는 `requirepass`와 `masterauth`에 동일한 비밀번호를 정의해야 합니다.
   requirepass 여기에-redis-비밀번호-입력
   masterauth 여기에-redis-비밀번호-입력
   
   ## `sentinel auth-pass`를 사용하여 Redis 기본 및 레플리카 인스턴스에 정의한 동일한 공유 비밀번호를 정의합니다.
   sentinel auth-pass gitlab-redis 여기에-redis-비밀번호-입력
   
   ## `sentinel monitor`를 사용하여 Redis 기본 노드의 IP와 포트, 장애 조치를 시작하기 위해 필요한 쿼럼을 정의합니다.
   sentinel monitor gitlab-redis 10.0.0.1 6379 2
   
   ## `sentinel down-after-milliseconds`를 사용하여 응답하지 않는 서버를 다운된 것으로 간주하는 시간(밀리초)을 정의합니다.
   sentinel down-after-milliseconds gitlab-redis 10000
   
   ## `sentinel failover_timeout`의 값을 `ms` 단위로 정의합니다. 이 값은 여러 의미를 가집니다:
   
   ## * 이전 장애 조치가 이미 시도된 경우에 동일한 기본에 대해 재시작하는 데 필요한 시간; 이는 failover timeout의 두 배입니다.
   ##
   ## * 현재 구성에 따라 잘못된 기본에 복제되는 레플리카가 올바른 기본과 복제되도록 강제되기까지의 시간. 이것은 완전히 failover 타임아웃이고(현재 구성이 발견된 시점부터 계산)...
   ##
   ## * 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간(아직 프로모션된 레플리카에 의해 인정되지 않음).
   ##
   ## * 진행 중인 장애 조치가 모든 레플리카가 새 기본의 레플리카로 재구성되기를 기다리는 최대 시간. 그러나 이 시간 이후에도 레플리카는 어쨌든 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차, 2개의 복제본 및 3개의 센티넬이 포함된 최소 구성의 예시

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

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

이 예시에서 센티넬 1은 Redis Primary와 동일한 기기에 구성되어 있으며, 센티넬 2는 Replica 1과 동일한 기기에, 그리고 센티넬 3는 Replica 2와 동일한 기기에 구성되어 있습니다.

다음은 각 기기와 할당된 IP의 목록과 설명입니다:

• 10.0.0.1: Redis Primary + 센티넬 1
• 10.0.0.2: Redis 복제본 1 + 센티넬 2
• 10.0.0.3: Redis 복제본 2 + 센티넬 3
• 10.0.0.4: GitLab 애플리케이션

초기 구성 이후에, 센티넬 노드에 의해 장애 조치(failover)가 이루어지면, Redis 노드가 구성을 다시하고 Primary는 영구적으로 변경됩니다(redis.conf 포함) 다른 노드로, 새로운 장애 조치가 다시 시작될 때까지.

sentinel.conf에서도 마찬가지로 됩니다. 새로운 센티넬 노드가 Primary를 감시하거나 장애 조치가 다른 Primary 노드를 승격한 후에 초기 실행 이후에 재정의됩니다.

Redis Primary 및 센티넬 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 복제본 1과 센티넬 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 복제본 2와 센티넬 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  # 레디스 포트가 아닌 센티넬을 가리킵니다
       -
         host: 10.0.0.2
         port: 26379  # 레디스 포트가 아닌 센티넬을 가리킵니다
       -
         host: 10.0.0.3
         port: 26379  # 레디스 포트가 아닌 센티넬을 가리킵니다
   

2. 변경 사항이 적용되도록 GitLab을 다시 시작하십시오.

문제 해결

Redis 문제 해결 가이드를 확인하세요.