• 요구 사항
• 클라우드 제공업체의 관리형 서비스로서의 Redis
  • 폐기 정책 설정
• 자체 Redis 서버를 통한 복제 및 장애 조치
  • 단계 1. 기본 Redis 인스턴스 구성
  • 단계 2. 복제 Redis 인스턴스 구성
  • 단계 3. Redis Sentinel 인스턴스 구성
  • 단계 4. GitLab 애플리케이션 구성
• 1 기본 및 2 레플리카, 그리고 3 Sentinel의 최소 구성 예제
  • Redis Primary 및 Sentinel 1의 구성 예
  • Redis 복제본 1 및 Sentinel 2의 구성 예
  • Redis 복제본 2 및 Sentinel 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 노드에 대한 인증이 구성된 경우 필요합니다
   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 서버를 통한 복제 및 장애 조치

이 문서는 Linux 패키지에 포함되어 있는 Redis 대신 별도로 설치한 Redis를 사용하여 확장 가능한 Redis 설정을 구성하는 방법에 대한 문서입니다. Linux 패키지를 사용하는 것이 권장되지만, 본 문서를 통해 설치 및 업그레이드에 대한 GitLab의 최신 지원 버전에 최적화된 Redis를 사용하지 않을 때 사용할 수 있습니다.

또한, 고급 Redis 설정에 대한 참조를 모두 /home/git/gitlab/config/resque.yml에 대한 참조로 대체하도록 선택할 수도 있습니다.

리눅스 패키지 설치의 replication and failover 문서를 읽는 것은 Redis 구성에 중요한 정보를 제공하므로, 본 안내서를 진행하기 전에 반드시 읽어보세요.

새로운 Redis 인스턴스를 설정하기 위해 계속 진행하기 전에 몇 가지 요구 사항이 있습니다:

• 본 안내서에서 설명하는 모든 Redis 서버는 소켓이 아닌 TCP 연결을 사용하도록 구성되어 있어야 합니다. Redis를 TCP 연결을 사용하도록 구성하려면 Redis 구성 파일에 bind 및 port를 모두 정의해야 합니다. 모든 인터페이스(0.0.0.0) 또는 원하는 인터페이스의 IP(예: 내부 네트워크의 IP)로 바인딩할 수 있습니다.
• Redis 3.2 이상부터 외부 연결을 받기 위해 비밀번호를 정의해야 합니다(requirepass).
• Sentinel을 사용하는 경우, 동일한 인스턴스에서 복제 비밀번호 정의(masterauth)를 반드시 정의해야 합니다.

또한, 리눅스 패키지와 함께의 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`를 정의하세요(default 포트는 `6379`).
   port 6379
      
   ## 패스워드 인증 설정(모든 노드에서 동일한 비밀번호를 사용하세요).
   ## Sentinel에서 사용하기 위해 Redis 도메인(리플리카) 정의(`masterauth`) 시 동일한 비밀번호를 정의해야 합니다.
   requirepass 여기에_redis_비밀번호_입력
   masterauth 여기에_redis_비밀번호_입력
   

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`를 정의하세요(default 포트는 `6379`).
   port 6379
      
   ## 패스워드 인증 설정(모든 노드에서 동일한 비밀번호를 사용하세요).
   ## Sentinel에서 사용하기 위해 Redis 도메인(리플리카) 정의(`masterauth`) 시 동일한 비밀번호를 정의해야 합니다.
   requirepass 여기에_redis_비밀번호_입력
   masterauth 여기에_redis_비밀번호_입력
      
   ## `replicaof`를 사용하여 IP 및 포트를 가리키는 Redis 기본 인스턴스를 정의하세요.
   replicaof 10.0.0.1 6379
   

3. 변경 사항이 적용되도록 Redis 서비스를 재시작하세요.
4. 다른 복제 노드에 대해 동일한 단계들을 다시 진행하세요.

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

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

Redis Sentinel이 Redis 기본 인스턴스와 동일한 인스턴스(아이피 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 여기에 레디스 패스워드 입력
   masterauth 여기에 레디스 패스워드 입력
      
   ## `sentinel auth-pass`로 Redis 기본 및 레플리카 인스턴스에 정의된 동일한 공유 비밀번호를 정의하세요.
   sentinel auth-pass gitlab-redis 여기에 레디스 패스워드 입력
      
   ## `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`의 값을 `ms`로 정의하세요. 이에는 다음과 같은 여러 의미가 있습니다:
   ##
   ## * 주어진 Sentinel에 의해 이전 기본에 대해 이미 시도된 이전 장애 조치 후 장애 조치를 다시 시작하는 데 필요한 시간은 장애 조치 시간의 두 배입니다.
   ##
   ## * Sentinel 현재 구성에 따라 잘못된 기본에 복제하는 레플리카에 거의 정확한 시간은 장애 조치 시간입니다(어느 Sentinel이 구성 오류를 감지한 순간부터 세어짐).
   ##
   ## * 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간(하지만 정확한 병렬 동기화 진행 상황은 지정된 대로이다)는 이 시간을 초과하더라도 Sentinels가 레플리카를 재구성하지 만, 정확하지는 않음.
   sentinel failover_timeout 30000
   

3. 변경 사항이 적용되도록 Redis 서비스를 다시 시작하세요.
4. 다른 Sentinel 노드에 대해 동일한 단계를 다시 수행하세요.

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

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

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

다음 단계는 Redis나 Sentinels이 동일한 기기에 없는 ideally한 GitLab 애플리케이션 서버에서 실행해야 합니다.

1. resque.yml.example을 참고하여 /home/git/gitlab/config/resque.yml을 편집하고 올바른 서버 자격 증명을 가리키는 Sentinel 라인을 주석 처리 해제하세요.

   # resque.yaml
   production:
     url: redis://:레디스-패스워드-입력@gitlab-redis/
     sentinels:
       -
         host: 10.0.0.1
         port: 26379  # 레디스 포트가 아닌 Sentinel을 가리킵니다.
       -
         host: 10.0.0.2
         port: 26379  # 레디스 포트가 아닌 Sentinel을 가리킵니다.
       -
         host: 10.0.0.3
         port: 26379  # 레디스 포트가 아닌 Sentinel을 가리킵니다.
   

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

1 기본 및 2 레플리카, 그리고 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 여기에 레디스 암호 입력
   masterauth 여기에 레디스 암호 입력
   

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

   bind 10.0.0.1
   port 26379
   sentinel auth-pass gitlab-redis 여기에 레디스 암호 입력
   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 및 Sentinel 2의 구성 예

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

   bind 10.0.0.2
   port 6379
   requirepass 여기에 레디스 암호 입력
   masterauth 여기에 레디스 암호 입력
   replicaof 10.0.0.1 6379
   

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

   bind 10.0.0.2
   port 26379
   sentinel auth-pass gitlab-redis 여기에 레디스 암호 입력
   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 및 Sentinel 3의 구성 예

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

   bind 10.0.0.3
   port 6379
   requirepass 여기에 레디스 암호 입력
   masterauth 여기에 레디스 암호 입력
   replicaof 10.0.0.1 6379
   

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

   bind 10.0.0.3
   port 26379
   sentinel auth-pass gitlab-redis 여기에 레디스 암호 입력
   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://:여기에 레디스 암호 입력@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 문제 해결 가이드를 참조하세요.