• 요구 사항
• 클라우드 제공업체에서 관리형 서비스로 사용하는 Redis
  • 삭제 정책 설정
• 자체 Redis 서버를 사용한 복제 및 장애 조치
  • 단계 1. 기본 Redis 인스턴스 구성
  • 단계 2. 복제 Redis 인스턴스 구성
  • 단계 3. Redis Sentinel 인스턴스 구성
  • 단계 4. GitLab 애플리케이션 구성
• 1개 기본, 2개 레플리카 및 3개 센티넬로 최소 구성 예제
  • Redis 주 서버 및 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 설정을 구성하는 방법에 대한 것입니다. 물론, Linux 패키지를 사용하는 것을 강력히 권장하며 GitLab에 맞게 특별히 최적화되었고 Redis를 지원하는 최신 버전으로 업그레이드 작업을 맡아주기 때문입니다.

또한 Linux 패키지 Redis HA의 복제 및 장애 조치 설명을 읽어보는 것을 강력 추천드립니다. Redis의 구성에 있어 매우 중요한 정보를 제공하기 때문입니다. 이 안내서를 읽고 이 가이드를 진행하기 전에 꼭 읽어보시기 바랍니다.

새로운 Redis 인스턴스를 설정하기에 앞서 다음은 요구 사항입니다:

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

3. 변경 사항이 적용되도록 Redis 서비스를 재시작하세요.
4. 기타 복제 노드에 대해 위의 단계를 다시 따라가세요.

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

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

Redis Sentinel이 기본 Redis와 동일한 인스턴스에 설치되어 있다고 가정하고 IP가 10.0.0.1인 Redis 기본과 함께 설치되어 있다고 가정합니다(일부 설정은 기본과 중첩될 수 있음):

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` 단위로 정의합니다. 이에는 여러 의미가 있습니다:
   ##
   ## * 특정 Sentinel이 이전에 동일한 Primary에 대해 이미 장애 조치를 시도한 후 재시작하는 데 필요한 시간은 장애 조치 시간의 두 배입니다.
   ##
   ## * 현재 Sentinel 구성에 따라 잘못된 Primary에 복제되는 레플리카의 복제를 올바른 Primary로 강제 복제하는 데 필요한 시간은 정확히 장애 조치 시간입니다(센티넬이 구성 오류를 감지한 순간부터 세어짐).
   ##
   ## * 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간(아직 승격된 레플리카에 의해 `REPLICAOF NO ONE`이 아직 승인되지 않음).
   ##
   ## * 진행 중인 장애 조치가 모든 레플리카가 새 Primary의 레플리카로 다시 구성될 때까지 기다리는 최대 시간. 그러나 이 시간이 지나도록 레플리카는 어쨌든 Sentinels에 의해 다시 구성되지만 명시된 것과 정확한 병렬 동기화 진행과 일치하지는 않음.
   sentinel failover_timeout 30000
   

3. 변경 사항이 적용되도록 Redis 서비스를 다시 시작합니다.
4. 다른 Sentinel 노드에 대해 위의 단계를 다시 수행합니다.

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

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

모든 Sentinel 노드 목록이 필요하지는 않지만, 장애가 발생하는 경우 목록된 노드 중 하나에 액세스해야 합니다.

다음 단계는 GitLab 애플리케이션 서버에서 수행해야 하며, 이 서버에는 이상적으로 Redis나 Sentinel이 함께 설치되어 있지 않아야 합니다:

1. resque.yml.example의 예제를 참고하여 /home/git/gitlab/config/resque.yml 파일을 편집하고 Sentinel 라인을 주석 처리 해제한 다음, 올바른 서버 자격 증명을 가리킵니다:

   # resque.yaml
   production:
     url: redis://:redi-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를 다시 시작합니다.

1개 기본, 2개 레플리카 및 3개 센티넬로 최소 구성 예제

이 예제에서는 모든 서버가 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 애플리케이션

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

동일한 일이 sentinel.conf에 대해서도 해당되며, 초기 실행 후에 Primary를 감시하기 시작하는 새 센티넬 노드가나 장애 조치가 다른 Primary 노드로 승격할 때 재정의됩니다.

Redis 주 서버 및 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  # 레디스 포트가 아닌 Sentinel을 가리킵니다
       -
         host: 10.0.0.2
         port: 26379  # 레디스 포트가 아닌 Sentinel을 가리킵니다
       -
         host: 10.0.0.3
         port: 26379  # 레디스 포트가 아닌 Sentinel을 가리킵니다
   

2. 변경 사항이 적용되도록 GitLab을 재시작합니다.

문제 해결

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