Redis 주니어 시스템 설계 면접
새 면접Q. 온라인 쇼핑몰에서 인기 상품 조회 API의 응답 속도를 개선하기 위해 Redis 캐시를 도입하려고 합니다. 캐시 키 설계 시 고려해야 할 사항과 적절한 키 네이밍 전략을 설명하고, 다국어 지원이 필요할 때 키를 어떻게 구성하면 좋을지 제안해주세요.
캐시 키는 고유성, 가독성, 일관성을 고려해야 합니다. 'product:{productId}:detail' 같은 계층적 구조를 사용하고, 콜론(:)으로 네임스페이스를 구분하는 것이 관례입니다. 다국어 지원이 필요한 경우 'product:{productId}:detail:{locale}' 형태로 언어 코드를 포함시켜 언어별로 다른 캐시를 관리할 수 있습니다. 키 길이는 가능한 짧게 유지하되 의미를 명확히 전달해야 하며, 버전 관리가 필요한 경우 'v1:product:{productId}'처럼 버전을 접두사로 추가할 수 있습니다.
- • 계층적 네이밍 구조 사용 (콜론으로 구분)
- • 고유성 보장을 위한 ID 포함
- • 다국어는 locale 파라미터를 키에 포함
- • 가독성과 유지보수성 고려
만약 상품 정보에 사용자별 맞춤 정보(찜 여부, 할인율 등)가 포함된다면 캐시 키 전략을 어떻게 수정하시겠습니까?
Q. 소셜 미디어 서비스에서 사용자의 최근 활동 피드(최근 50개 게시물)를 Redis로 관리하려고 합니다. 어떤 데이터 타입을 사용하는 것이 적합한지 선택하고, 새 게시물 추가와 오래된 게시물 제거를 효율적으로 처리하는 방법을 설명해주세요.
List 데이터 타입이 가장 적합합니다. LPUSH 명령어로 새 게시물을 리스트의 앞쪽에 추가하고, LTRIM 명령어로 지정된 범위(0~49)만 유지하여 자동으로 오래된 게시물을 제거할 수 있습니다. 예를 들어 'LPUSH user:{userId}:feed {postId}'로 추가하고 'LTRIM user:{userId}:feed 0 49'로 최근 50개만 유지합니다. 조회 시에는 LRANGE 명령어로 원하는 범위의 게시물을 가져올 수 있으며, 이 방식은 시간 복잡도 O(1)로 매우 효율적입니다.
- • List 자료구조 선택
- • LPUSH로 최신 항목을 앞에 추가
- • LTRIM으로 크기 제한 유지
- • LRANGE로 범위 조회
만약 피드에 게시물의 타임스탬프와 추가 메타데이터도 함께 저장해야 한다면 데이터 구조를 어떻게 설계하시겠습니까?
Q. 여러 마이크로서비스가 공통으로 사용하는 설정 정보(feature flags, 환경 변수 등)를 Redis에 중앙 관리하려고 합니다. 설정 정보의 구조화 저장과 효율적인 조회를 위해 어떤 데이터 타입을 사용하고, API 설계 시 고려해야 할 캐시 무효화 전략을 설명해주세요.
Hash 데이터 타입을 사용하여 'config:{serviceName}' 키에 여러 설정을 필드-값 쌍으로 저장하는 것이 효율적입니다. HGETALL로 전체 설정을 가져오거나 HGET으로 특정 설정만 조회할 수 있습니다. 캐시 무효화는 설정 변경 시 Pub/Sub을 활용하여 모든 서비스에 변경 알림을 브로드캐스트하고, 각 서비스가 로컬 캐시를 갱신하도록 합니다. 또는 각 설정에 버전 번호를 포함시켜 'config:{serviceName}:v2' 형태로 관리하면 무효화 없이 새 버전으로 전환할 수 있습니다.
- • Hash 자료구조로 구조화된 설정 관리
- • 서비스별 네임스페이스 분리
- • Pub/Sub을 통한 변경 알림
- • 버전 관리를 통한 무중단 업데이트
설정 변경 이력을 추적하고 롤백 기능을 제공해야 한다면 어떻게 설계하시겠습니까?
Q. 단일 Redis 인스턴스의 메모리가 부족해지면서 데이터를 여러 Redis 인스턴스에 분산 저장해야 하는 상황입니다. 클라이언트 측 샤딩(Client-side Sharding)과 Redis Cluster의 차이점을 설명하고, 각각의 장단점을 비교해주세요.
클라이언트 측 샤딩은 애플리케이션 코드에서 해시 함수를 사용해 키를 특정 Redis 인스턴스로 라우팅하는 방식입니다. 구현이 간단하고 제어가 쉽지만, 노드 추가/제거 시 리샤딩이 복잡하고 클라이언트 로직이 복잡해집니다. Redis Cluster는 Redis가 자체적으로 제공하는 분산 솔루션으로 16384개의 해시 슬롯을 자동으로 관리하며, 자동 페일오버와 리샤딩을 지원합니다. 하지만 다중 키 연산에 제약이 있고 설정이 복잡합니다. 소규모에서는 클라이언트 샤딩, 대규모에서는 Redis Cluster가 적합합니다.
- • 클라이언트 샤딩: 애플리케이션에서 분산 로직 구현
- • Redis Cluster: 자동 샤딩 및 페일오버 제공
- • 클라이언트 샤딩은 간단하지만 확장성 제한
- • Redis Cluster는 운영 복잡도가 높지만 자동화된 관리
Consistent Hashing 알고리즘이 샤딩에서 어떤 문제를 해결하는지 설명해주세요.
Q. 프로덕션 환경에서 Redis를 안전하게 운영하기 위한 보안 설정과 베스트 프랙티스를 설명해주세요. 특히 네트워크 접근 제어, 인증, 위험한 명령어 제한 측면에서 어떤 조치를 취해야 하는지 구체적으로 말씀해주세요.
첫째, bind 설정으로 특정 IP에서만 접근 가능하도록 제한하고, 외부 네트워크에 직접 노출하지 않습니다. 둘째, requirepass를 설정하여 비밀번호 인증을 활성화하고, 강력한 비밀번호를 사용합니다. 셋째, rename-command로 FLUSHALL, FLUSHDB, CONFIG 같은 위험한 명령어를 비활성화하거나 다른 이름으로 변경합니다. 넷째, protected-mode를 활성화하여 기본 보안을 강화하고, 가능하면 TLS/SSL을 사용한 암호화 통신을 설정합니다. 다섯째, 최소 권한 원칙에 따라 Redis 6.0 이상에서는 ACL을 사용해 사용자별 권한을 세밀하게 제어합니다.
- • bind와 방화벽으로 네트워크 접근 제어
- • requirepass로 인증 활성화
- • 위험한 명령어 비활성화 또는 이름 변경
- • ACL을 통한 세밀한 권한 관리
Redis에 민감한 개인정보를 저장해야 한다면 데이터 암호화는 어떻게 처리하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!