Redis 개발 가이드라인

GitLab에서 Redis를 사용하는 방법, 인스턴스 구성, 키 명명 규칙, 캐싱, 백그라운드 마이그레이션 등을 설명합니다.

Redis 인스턴스 # GitLab은 Redis 를 다음과 같은 여러 목적으로 사용합니다: 캐싱 (주로 Rails.cache 를 통해). Sidekiq 을 사용한 job 처리 큐. 공유 애플리케이션 상태 관리. CI 트레이스 청크 저장. ActionCable의 Pub/Sub 큐 백엔드. 레이트 리밋 상태 저장. 세션. 대부분의 환경(GDK 포함)에서는 이 모든 목적이 동일한 Redis 인스턴스를 가리킵니다. GitLab.com에서는 별도의 Redis 인스턴스 를 사용합니다. 설정에 대한 자세한 내용은 Redis SRE 가이드 를 참조하세요. 모든 애플리케이션 프로세스는 동일한 Redis 서버를 사용하도록 구성되어 있으므로, PostgreSQL 이 적합하지 않은 경우 프로세스 간 통신에 Redis를 사용할 수 있습니다. 예를 들어, 읽기보다 쓰기 횟수가 훨씬 많은 일시적인 상태나 데이터가 이에 해당합니다. Geo 가 활성화된 경우, 각 Geo 사이트는 독립적인 자체 Redis 데이터베이스를 갖습니다. 새 Redis 인스턴스 추가에 관한 개발 문서 가 있습니다. 키 명명 # Redis는 계층 구조 없이 평면 네임스페이스를 사용하므로, 충돌을 방지하기 위해 키 이름에 주의를 기울여야 합니다. 일반적으로 애플리케이션 수준에서 구조처럼 보이도록 콜론으로 구분된 요소를 사용합니다. 예를 들어 projects:1:somekey 와 같은 형태입니다. Redis 사용 목적을 별도의 카테고리로 분리하고, 이를 GitLab.com과 같은 고가용성 구성에서 별도의 Redis 서버에 매핑할 수 있지만, 기본 Omnibus 및 GDK 설정은 단일 Redis 서버를 공유합니다. 즉, 키는 모든 카테고리에 걸쳐 항상 전역적으로 고유해야 합니다. Redis 키 이름에는 전체 경로보다 변경 불가능한 식별자(예: 전체 경로 대신 프로젝트 ID)를 사용하는 것이 일반적으로 더 좋습니다. 전체 경로를 사용하면 프로젝트 이름이 변경될 때 해당 키가 참조되지 않게 됩니다. 키의 내용이 이름 변경으로 인해 무효화되는 경우에는, 키 변경에 의존하는 것보다 항목을 만료시키는 훅을 포함하는 것이 더 좋습니다. 멀티 키 명령 # GitLab은 에픽 878 에서 도입된 캐시 관련 워크로드 유형에 Redis Cluster를 지원합니다. 이로 인해 명명에 추가적인 제약이 생깁니다: GitLab이 여러 키를 동일한 Redis 서버에 보유해야 하는 작업(예: Redis에 보관된 두 세트를 비교하는 경우)을 수행할 때, 키의 변경 가능한 부분을 중괄호로 묶어 이를 보장해야 합니다. 예를 들어: project:{1}:set_a project:{1}:set_b project:{2}:set_c set_a 와 set_b 는 동일한 Redis 서버에 보관되도록 보장되지만, set_c 는 그렇지 않습니다. 현재 개발 및 테스트 환경에서는 RedisClusterValidator 로 이를 검증하며, 이는 cache 와 shared_state Redis 인스턴스 에 대해 활성화되어 있습니다. 더 많은 Redis