나도 좀 알자! Redis

https://www.youtube.com/watch?v=mPB2CZiAkKM&t=1907s

우아한 Redis 세미나 영상을 보면서 정리한 내용입니다. 더욱 자세한 내용을 보고 싶다면 영상을 참고하시길 바랍니다. 

Redis의 등장

과거 모놀리틱 아키텍처에선 서버의 성능을 높이기 위해 주로 CPU, 메모리, 디스크를 늘리는 수직적 확장을 사용했다. 하지만 이 방식은 비용이 많이 들고, 일정 수준 이상으로 확장하기 어렵다는 한계가 있었다.

 

그래서 개발자들은 마이크로 서비스 아키텍처를 도입하여 애플리케이션을 독립적인 작은 서비스 단위로 나누고, 필요한만큼 서버를 증설하는 수평적 확장 방식을 적용하게 된다. 덕분에 트래픽이 몰리는 특정 서비스만 유연하게 확장할 수 있게된 것이다.

 

 

그러나 새로운 문제가 발생하였다. 서비스가 각각의 별도의 서버와 프로세스에서 동작하다 보니 서버 간 메모리를 직접 공유할 수 없다는 점이다.! 프로세스 간 자원을 효율적으로 공유하기 위한 통합 메모리 저장소가 필요했고, 이를 해결하기 위해 등장한 것이 Redis이다.

 

즉, Redis는 인메모리 데이터 저장소로서, 빠른 속도로 데이터를 읽고 쓰며 여러 서비스가 공통적으로 활용할 수 있는 공유 자원 역할을 한다. 

 

Redis의 자료구조

Redis는 태생이 메모리이기 때문에 속도가 매우매우 중요하다. 그래서 상황에 맞는 자료구조를 선택해 사용하는 것이 핵심이다. 

1. String

일반적인 문자열로 key나 value에 활용된다.

 

2. List

순서를 가지는 문자열의 연결 리스트 구조

맨 앞/뒤의 데이터 삽입/삭제가 빠르지만, 중간 삽입/삭제는 매우 느리다.

 

3. Set

중복을 허용하지 않는 집합 구조

교집합, 합집합, 차집합 연산을 지원한다.

 

4. Sorted Set

정렬을 지원하는 Set

각 원소마다 Score를 부여해 정렬한다.

 

5. Hash

필드와 값을 매핑할 수 있는 Key-Value Map 구조

하나의 키 안에 여러 필드를 저장할 수 있다.

 

List, Set, Sorted Set, Hash 는 컬렉션이라고 부르는데 컬렉션에는 너무 많은 아이템을 담는 것은 좋지 않다. 몇 천개 수준으로 유지하며 많아도 10,000개 이하로 유지해야한다. 값을 검색하거나 삭제, 업데이트 시 성능 저하가 발생할 수 있기 때문이다.

 

Collection을 사용하며 TTL을 사용할 때 주의해야할 점은 expire는 컬렉션 전체에 적용된다는 점이다. Hash나 List 안에 개별 아이템마다 TTL을 걸 수 없다는 것을 인지하자.

 

Redis 운영

메모리 관리

Redis는 모든 데이터를 메모리에 올려두는 구조라 정해진 Physical Memory 이상을 사용하게 되면 위험하기에 메모리 관리가 중요하다. 

 

Maxmemory 옵션으로 상한선을 지정할 수 있지만 실제 사용량은 이보다 커질 수 있다. 이유는 jemalloc 같은 메모리 할당자에 의존하기 때문이다. 예를 들어, 페이지 크기가 4096B일 때 4097B를 쓰려고 하면 Redis는 4097B만 사용한다고 생각하지만 실제로는 8KB가 할당된다. (4096B페이지 1개와 1B페이지 1개 두 개를 할당받게 됨)

 

따라서 단순히 maxmemory 설정만 해두는게 아니라 실제 메모리 사용량을 꾸준히 모니터링해야한다.

 

Redis Replication

Redis의 복제는 비동기 방식이기 때문에 짧은 순간이지만 Primary와 Replica 간 데이터 차이가 발생할 수 있다. 이를 Replication Lag이라고 부른다.

• 설정은 간단히 replicaof <hostname> <port> 명령으로 할 수 있고
• DBMS의 statement replication과 유사하게 쿼리 단위로 명령을 전송하는 개념이라고 이해하면 된다

 

Redis Sharding

데이터가 커지고 트래픽이 많아지면 여러 대의 서버로 분산해서 데이터를 저장해야 한다. 이를 샤딩(Sharding)이라고 부르고, 데이터를 어떤 기준으로 분산할지에 따라 방식이 나뉜다.

 

1. Range Sharding

• 키의 범위에 따라서 서버를 나눠 저장하는 방식
• 확장이 용이
• 바쁜 서버와 여유로운 서버 간 불균형이 심해지고
• 이미 저장된 데이터를 쉽게 옮길 수 없음

ex
001~100번 -> 서버 1의 redis
101~200번 -> 서버 2의 redis

 

2. Modular Sharding

• 키 해시값을 어떤 값으로 나눈 나머지(modular)에 따라 서버를 배정하는 방식
• 데이터를 균등하게 나눌 수 있음
• 배수 단위로 서버를 늘리면 데이터가 어디에 분산될지 명확히 보임
• 서버 수가 변경되면 데이터 재분배 문제 발생

ex
hash(key) % 2 == 0 -> 서버 1의 redis
hash(key) % 2 == 1 -> 서버 2의 redis

 

 

3. Indexed Sharding

• 키를 통해 데이터가 어디에 저장될지를 관리하는 서버(Index Server)가 관리
• 유연함
• 하지만 Index Server에 장애가 생기면 시스템 전체에 영향

 

Monitoring

운영환경에서의 안정성과 예기치 못한 에러 상황을 사전에 방지하기 위해 모니터링을 해주는 것이 좋다. 

다음은 주요깊게 봐야할 지표들이다.

 

Redis 내부 지표 (INFO 명령어)

• RSS:  실제로 물리 메모리를 얼마나 쓰고 있는가
• Used Memory: Redis가 생각하는 자신이 사용하고 있는 메모리
• Connected Clients: 현재 Redis에 연결된 클라이언트 수. 과도하게 늘어나면 성능 저하의 원인
• Ops per Second: Redis가 얼마나 많은 요청을 처리하고 있는지

System 지표

• CPU
• Disk I/O: RDB or AOF를 통한 영속화 기능을 사용하는 경우 디스크 속도에 병목
• Network. (rx/tx): Redis는 네트워크 기반으로 통신하기 때문에 네트워크 대역폭과 패킷 드롭 여부를 확인해야함