• Redis 기반 세션 클러스터링 및 복제 고가용성

[개념]

Redis는 REmote DIctionary Server의 약자로 공식적으로 NoSQL Database로 분류되어 있는 오픈소 데이터베이스이다.
In-Memory Key-Value Store, 즉 메모리에 Key-Value 값을 저장하여 빠른 성능을 보장하며, 다양한 언어 클라이언트 및 자료구조를 지원하므로 다양한 상황에서 사용될 수 있다.
많은 서비스에서 캐시, 세션 저장을 위해 많이 사용하며, 실시간 순위나 메시지 브로커, 비동기 작업 큐로도 사용하기도 한다.
명령어가 짧고 직관적이며, redis-cli를 통해 터미널에서 실행하거나 Python, C#, .NET, Java 등 Redis에서 제공하는 여러 언어의 클라이언트 라이브러리로 연결하여 사용할 수 있다.

 

[Redis가 제공하는 자료구조 별 사용 예시]

String (문자열) SET name "tistory"
GET name
"tistory" 문자, 숫자 등 간단한 값 저장 
List (순서 있는 목록) LPUSH fruits "apple"
LPUSH fruits "banana"
LPUSH fruits "cherry"
LRANCE fruits 0 -1
1) "cherry"
2) "banana"
3) "apple"
댓글, 목록, 대기열
Set (중복 없는 집합) SADD tags "redis"
SADD tags "database"
SADD tags "redis"
SMEMBERS tags
1) "database"
2) "redis"
중복 없는 항목 관리 (좋아요 등)
Pub/Sub (메시지 전달) *구독* SUBSCRIBE news
*발생* PUBLISH news "Hello Redis"
"Hello Redis"
*구독 터미널에 출력*
실시간 알림 등 사용

 

Redis에서는 고가용성(HA, High Availavility)을 유지하기 위해 Replication(복제)을, 확장성을 위해 Cluster 구조를 제공한다.
기본적으로 Master/Slave (또는 Leader/Follower) 구조로 Replication을 제공하며, 하나의 쓰기Write 가능한 Master(Leader) 읽기전용Read 또는 백업을 기본으로 하는 Slave(Follower)를 두고 고가용성을 유지한다.
Master->Slave로 단방향 복제가 발생하며, 이 때 복제는 비동기(Async) 방식으로 동작하여 아주 약간 데이터 지연이 발생할 가능성이 있다.

Replication 구조에서는 Redis Sentinel을 함께 구성하여 고가용성을 유지할 수 있다.
Redis Sentinel은 Master 인스턴스를 모니터링 하며 Master에서 이슈가 발생할 경우 자동으로 Slave를 Master로 승격하여 서비스를 유지시킨다. [참고] High availability with Redis Sentinel 

 

[Redis Replication 구조]

 

Redis Cluster는 Replication의 구조를 그대로 가져가며 그 자체를 수평적으로 분산시켜 거대한 시스템으로 구성한 것이다.
N개의 Master가 있고, Master는 1개 이상의 Slave를 보유한다.

Cluster에는 Sharding/Replication/Failover 3가지 개념이 존재하고, 전체 0~16485 Slots이 Master에 자동으로 나눠지며(Sharding),
Replication 구조에서 자동으로 Master의 장애를 감지, Slave를 승격(Failover)시킬수 있게 된다.
Key는 "CRC16(key) % 16384" 연산으로 Slot 번호를 계산하여 해당 Slot을 관리하는 Master에 저장된다.

Client는 직접 Master에 통신하여 Key를 저장하거나 읽어오며, Key를 읽을때 값을 가지고 있지 않은 Master로 요청하게 될 경우
MOVED 응답을 통해 어디에 해당 Key가 저장되어 있는지 전달받게 된다. Redis Cluster에서는 다중 키 연산이 불가능 하므로,
함께 연산이 필요한 Key들은 HashTag를 통해 동일한 마스터에 저장될 수 있도록 구성되어야 한다.

 

 


 

Redis는 데이터베이스, 캐시, 메시지 브로커로 사용되는 인메모리(in-memory) 데이터 저장소입니다. 디스크에 데이터를 저장하는 전통적인 데이터베이스와 달리, 모든 데이터를 **메모리(RAM)**에 저장하는 것이 가장 큰 특징이에요.


왜 Redis를 쓸까? 🏃‍♂️

Redis의 가장 큰 장점은 엄청나게 빠른 속도입니다. 모든 데이터를 메모리에서 읽고 쓰기 때문에, 디스크 I/O가 필요한 데이터베이스보다 훨씬 빠릅니다. 웹 서비스에서 Redis는 주로 다음과 같은 용도로 사용됩니다.

  1. 캐시(Cache): 자주 조회되는 데이터를 Redis에 저장해두고, 요청이 들어올 때마다 데이터베이스를 거치지 않고 Redis에서 바로 응답을 줍니다. 이렇게 하면 데이터베이스 부하를 줄이고 응답 시간을 단축할 수 있습니다.
  2. 세션 저장소: 로그인한 사용자의 세션 정보를 Redis에 저장하여, 여러 웹 서버 간에 세션 데이터를 공유하고 관리하는 데 사용됩니다.
  3. 랭킹 시스템: 실시간으로 순위가 변하는 게임 랭킹이나 인기 검색어 순위 등을 Redis의 Sorted Set 자료구조를 이용해 빠르게 처리할 수 있습니다.
  4. 메시지 큐: Pub/Sub 기능을 사용하여 실시간 채팅이나 알림 등 메시지 브로커 역할도 수행합니다.

Redis의 독특한 특징 🛠️

Redis는 단순히 키-값(key-value) 쌍만 저장하는 것이 아니라, 다양한 자료구조를 지원한다는 점이 독특합니다. 덕분에 Redis는 매우 유연하게 활용될 수 있어요.

  • String: 가장 기본적인 문자열 저장 방식.
  • List: 여러 개의 문자열을 순서대로 저장하는 목록.
  • Set: 중복되지 않는 값들의 집합.
  • Sorted Set: 점수(score)를 기준으로 정렬되는 집합. (랭킹 시스템에 유용)
  • Hash: 필드와 값의 쌍으로 이루어진 객체. (사용자 프로필 정보 등에 유용)

Redis와 MySQL 비교 (쉬운 비유)

Redis와 MySQL 같은 전통적인 데이터베이스의 차이는 **'책상 위의 서류철'**과 **'서류 창고'**의 차이와 비슷합니다.

  • MySQL (서류 창고): 모든 서류(데이터)가 서류 창고(디스크)에 정리되어 있습니다. 서류를 찾으려면 창고로 가서 서류를 꺼내와야 하므로 시간이 좀 걸립니다. 하지만 서류가 많아도 모두 보관할 수 있습니다.
  • Redis (책상 위의 서류철): 자주 사용하는 중요한 서류(데이터)만 책상 위(메모리)에 꺼내놓습니다. 필요할 때 바로바로 찾아볼 수 있어 매우 빠릅니다. 하지만 책상 공간(메모리 용량)이 제한적이라 모든 서류를 다 올려놓을 수는 없습니다.

결론적으로, Redis는 빠른 속도가 필요하거나 다양한 자료구조를 활용해야 할 때 사용하는 보조 저장소라고 이해하면 됩니다.

 


[문제]

1) Redis Sentinel의 주요 역할로 옳은 것은?

  1. 데이터 백업 자동화
  2. 마스터 장애 발생 시 슬레이브를 마스터로 자동 승격
  3. 클러스터 내 데이터 샤딩
  4. 키별 만료 시간 설정
  5. Lua 스크립트 실행
 정답확인

2. 마스터 장애 발생 시 슬레이브를 마스터로 자동 승격

 

2) Redis 클러스터에서 특정 키에 대해 클라이언트가 "MOVED" 응답을 받았을 때 올바른 처리 방법은?

  1. 요청을 동일한 노드로 재시도한다
  2. 요청을 중단한다
  3. 안내 메시지만 출력하고 아무 조치도 하지 않는다
  4. 전달 받은 새로운 슬롯(slot)을 관리하는 마스터 노드로 요청을 다시 보낸다
  5. 클러스터를 리스타트한다
 정답확인
4. 전달 받은 새로운 슬롯(slot)을 관리하는 마스터 노드로 요청을 다시 보낸다

 

3) Redis를 대규모 서비스에 적용할 때는 단일 노드의 한계 극복 및 무중단 서비스를 위해 클러스터(cluster) 구성이 필요합니다.
    Redis Cluster 환경에서는 전체 데이터를 복수의 노드에 분산 저장하고, 마스터-레플리카 구조를 통해 장애 시 데이터를 보존합니다.
    클러스터의 샤딩(sharding), 슬롯(slot) 관리 및 failover 처리와 관련하여 다음 설명 중 올바른 것을 고르시오.

  1. 동일한 키는 클러스터 내 여러 Master 노드에 자동 복제되어 저장된다.
  2. 클러스터는 각 키를 해시 함수로 계산한 슬롯 번호에 따라 Master에 분산 저장한다.
  3. 클러스터 환경에서 마스터 노드가 장애를 일으켜도 자동 failover는 지원하지 않는다.
  4. Redis Cluster에서는 데이터 일관성을 위해 모든 노드에 데이터를 동기적으로 저장한다.
  5. 클러스터 구성 시 마스터는 반드시 각자 하나의 레플리카만 둘 수 있다.
 정답확인

2. 클러스터는 각 키를 해시 함수로 계산한 슬롯 번호에 따라 Master에 분산 저장한다.

 

4) 글로벌 SNS 서비스에서 수억 명의 사용자의 피드, 알림 등 다양한 데이터를 빠르고 안정적으로 처리하기 위해 Redis Cluster 환경을 운영한다고 가정합니다.
    각 지역 데이터센터에는 여러 개의 Redis 노드가 있으며, 클러스터 구성을 통해 데이터 분산과 고가용성을 달성하고 있습니다.
    이런 실무 환경에 대한 다음 설명 중 옳은 것은?

  1. 특정 유저의 피드 데이터는 클러스터 내 모든 노드에 복제되어 저장된다.
  2. 각 노드는 0~16383번 슬롯 중 일부를 담당하며, 키 해시값에 따라 자동 분산 저장된다.
  3. 마스터 노드 장애 시 수동 개입 없이는 어떤 Replica도 마스터로 승격되지 않는다.
  4. 수평 확장이 불가능하므로 클러스터 노드 수를 늘릴 수 없다.
  5. 복잡한 트랜잭션 처리를 위해 다중 키 연산이 자유롭게 허용된다.
 정답확인

b) 각 노드는 0~16383번 슬롯 중 일부를 담당하며, 키 해시값에 따라 자동 분산 저장된다.

 

5) 글로벌 SNS 업체에서는 수억 명의 사용자 데이터를 빠르게 저장하고 조회하는 동시에, 장애 발생 시 데이터 손실 및 서비스 중단 위험을 최소화하기 위해 Redis Cluster를 엔진으로 채택했습니다.
    Cluster는 여러 노드에 데이터를 분산 저장(샤딩)하고, 각 노드별로 복제본(Replica)을 유지해 신속한 장애 복구를 도모합니다.
    또한, Redis의 클러스터 모드에서는 애플리케이션이 각 키의 분산 위치를 알아야 하며, 데이터의 일관성과 가용성, 확장성이 복합적으로 고려됩니다.
    이런 상황에서 Redis Cluster의 동작 및 특징에 대한 올바른 설명을 고르세요.

  1. 모든 키-값 데이터는 클러스터 내 여러 마스터 노드에 동시 복제되어 저장되기 때문에 데이터 손실 가능성이 없다.
  2. 클러스터 내 각 키는 해시 슬롯(Hash Slot) 방식으로 분할되어 특정 마스터 노드에만 저장된다.
  3. 마스터 노드 장애 발생 시, 별도의 설정 없이도 자동 복구나 Failover 처리가 이뤄지지 않는다.
  4. 다중 키(Multi-key) 연산은 클러스터 내 여러 슬롯(노드)에 걸쳐 자유롭게 수행할 수 있다.
  5. 노드 추가나 삭제 등 확장 및 축소가 불가능하여 클러스터 크기는 고정된다.
 정답확인

2. 클러스터 내 각 키는 해시 슬롯(Hash Slot) 방식으로 분할되어 특정 마스터 노드에만 저장된다.

 


 

A) 한 서비스가 Redis master 1대와 replica 2대(replica1, replica2)로 운영 중입니다. 어느 날 master와 replica1 사이 네트워크가 15분 동안 단절됩니다.
    그동안 replica1은 master의 변경사항을 수신하지 못해 데이터가 일치하지 않게 됩니다.
    네트워크 복구 후 replica1은 master와 전체 동기화를 시도하지만, maxmemory 설정이 작아 전체 복제 데이터를 모두 저장하지 못합니다.
    이 상황에서 발생하거나 관련 있는 현상/설명으로 옳지 않은 것을 고르세요.

  1. replica1은 동기화에 실패할 경우, 여전히 오래된 데이터를 클라이언트에게 제공할 수 있다.
  2. replica2는 네트워크 이상이 없었으므로 master와 동일한 최신 데이터를 계속 서비스한다.
  3. master와 replica1 간의 복제가 네트워크/메모리 문제로 반복적으로 실패하면, replica1이 데이터 일관성을 잃을 수 있다.
  4. 전체 복제 과정에서 maxmemory eviction 정책에 따라 replica1의 기존 데이터도 삭제될 수 있다.
  5. replica1은 동기화 실패 시 자동으로 master 역할로 승격되어 쓰기 요청을 받아들이게 된다.
 정답확인

5. replica1은 동기화 실패 시 자동으로 master 역할로 승격되어 쓰기 요청을 받아들이게 된다.

해설 : replica1이 동기화에 실패해도, 자동으로 master가 되어 쓰기 요청을 처리하지 않습니다. Redis에서는 반드시 명시적으로 역할 전환(예: Sentinel, manual failover)이 필요합니다.

나머지 선택지는 실제 장애 상황에서 발생 가능한 현상/설명입니다.

1.  replica1이 구버전 데이터 제공
2. 네트워크 이상 없던 replica2는 최신 데이터 유지
3.  동기화 반복 실패로 복제 불일치 가능
4. eviction 정책에 따라 기존 데이터 삭제 가능

 

B) 여러 대의 노드로 이루어진 Redis Cluster 환경에서, 각 노드는 slot을 분산해 저장하고 있습니다. 상태는 다음과 같습니다.

  • cluster 전체 노드: 6대(3 master, 3 replica)
  • 특정 master 노드(M1)가 하드웨어 장애로 다운됨. 이 마스터의 replica(R1)가 살아남아 있다는 신호를 다른 노드들에게 전송하고 있습니다.
  • cluster의 min-replicas-to-write 옵션은 1로 설정되어 있습니다.

    이 상황에서 발생할 수 있는 결과나 현상으로 옳지 않은 것을 고르세요.

  1. 클러스터에서는 자동으로 남은 replica(R1)가 마스터로 승격(failover)되어 해당 슬롯 데이터를 계속 서비스한다.
  2. cluster-replicas 옵션이 1 이상이므로, 최소 하나의 replica가 남아 있으면 클러스터는 쓰기·읽기가 모두 가능하다.
  3. 특정 master(M1)가 사라져도, 나머지 master들이 담당하는 slot에는 아무런 영향이 없다.
  4. 클러스터 내부적으로 단일 key에 대한 operations는 해당 slot을 가진 노드만 장애가 아니라면 정상적으로 동작한다.
  5. failover 이후 새로 마스터가 된 R1이 장애 발생 직전의 완벽한 최신 데이터를 반드시 보장한다.
 정답확인

5. failover 이후 새로 마스터가 된 R1이 장애 발생 직전의 완벽한 최신 데이터를 반드시 보장한다.

해설 : Redis Cluster의 replica가 장애 직전 master의 완벽한 최신 데이터를 보장하지는 않습니다(최대 1~2개 명령까지 데이터 유실 가능성 있음)

A, B, C, D는 Redis Cluster 정상 동작·옵션에 부합합니다.

'기타' 카테고리의 다른 글

39. Debezium  (0) 2025.08.30
38. VMware  (2) 2025.08.30
32. kafka  (1) 2025.08.29
47. 통합가시성  (0) 2025.08.29
46. Cloud 비용 최적화  (0) 2025.08.29

+ Recent posts