Redis 개발 가이드라인

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

Redis 인스턴스 # GitLab은 다음과 같은 별개의 용도로 Redis 를 사용합니다. 캐싱 (대부분 Rails.cache 를 통해 사용합니다). Sidekiq 을 사용하는 job 처리 큐. 공유 애플리케이션 상태 관리. CI 트레이스 청크 저장. Sidekiq 동시 실행 제한을 위한 지연 job 저장. 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를 지원합니다. 이 때문에 이름 짓기에 제약이 하나 더 생깁니다. 여러 키가 같은 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 인스턴스 에 대해