[Redis] 레디스 정리 ※

단일 JVM이 아닌 다중 서버 환경에서의 동시성 제어를 위해서는 데이터베이스 락 또는 Redis, Zookeeper 등을 사용한 분산 락을 사용할 수 있다. 이번 글에서는 레디스 분산 락 도입 전에 레디스에 대해 공부하며 레디스 Persistence와 주의 사항, 아키텍처 등 새롭게 알게된 것들에 대해 정리할 예정이다.

 

---

 

 

☑️ 레디스 Persistence

레디스는 예기치 못하게 서버가 다운되어 데이터를 복구해야하는 상황을 대비해 두가지 Persistence 기능을 제공한다.

 

1️⃣ RDB

RDB는 스냅샷 방식으로 동작한다. 이는 특정 시간마다 스냅샷을 만들어 디스크에 저장한 후, 데이터 복구가 필요할 경우 그대로 로딩해서 사용하면 되지만 스냅샷 이후에 변경된 데이터는 저장되지 않기 때문에 데이터 유실의 가능성이 있다.

 

그렇기 떄문에 RDB 방식은 캐시로만 사용하는 경우와 같이 일부 데이터 유실에 영향을 받지 않는 경우에 사용된다.

 

 

사용 방법

`redis.conf` 파일의 `save` 옵션을 통해 자동으로 저장할 수 있으며 cli에서 `BGSAVE` 커멘드를 통해서 수동 저장이 가능하다. 이때 `SAVE` 커멘드는 Blocking 방식으로 작동하여 진행 중인 다른 작업들에 영향을 줄 수 있기 때문에 `fork`를 통해 자식 프로세스를 만들어 백그라운드에서 실행하도록 하는 `BGSAVE` 커멘드 사용을 권장한다.

 

위와 같은 이유로 데이터를 삭제할 때에는 `del` 커멘드 대신 `unlink` 커멘드 사용을 권장한다.

 

//redis.conf 파일
save 900 1  // 900초 동안 1개 이상의 데이터 변경이 있을 경우 RDF 파일 재작성

 

 

2️⃣ AOF

AOF는 데이터를 변경하는 이벤트가 발생할 때마다 Log를 모두 저장하는 방법이다. AOF는 FSYNC 주기에 따라 데이터의 유실이 전혀 없도록 설정할 수 있기 때문에 장애 직전까지의 모든 데이터가 보장되어야 하는 경우에 사용된다.

 

 

사용 방법

`redis.conf` 파일의 `auto-aof-rewrite-percentage` 옵션을 통해 설정할 수 있으며, 이는 현재 AOF 파일 대비 AOF 파일 재작성 크기를 나타낸다. 또한 CLI에서 `BGREWRITEAOF` 커멘드를 통해 AOF 파일 재작성이 가능하다.

 

APPENDFSYNC 옵션

• always: 레디스 명령이 실행될 때 마다 디스크에 기록하며 성능이 매우 떨어진다.
• everysec: 데이터를 모아서 1초 마다 디스크에 쓴다. Write()와 fsync() 시스템 콜 호출의 지연 시간에 따라서 최대 2초 이내의 데이터를 잃어 버릴 수 있지만, 성능과 데이터 보존 양 측면에서 적절한 값으로 기본값인 옵션이다.
• no: 디스크에 쓰는 시점을 운영체제에 맡긴다. 대부분의 리눅스 시스템에서는 30초 마다 디스크에 저장되기 때문에 최대 30초간의 데이터를 유실할 수 있다.

 

 

☑️ Redis 주의 사항

 

1. STOP-WRITES-ON-BGSAVE-ERROR

이 설정은 RDB 파일 저장 실패 시 redis로의 모든 write를 불가능하게 하는 옵션으로 `yes`가 기본 설정값으로 되어있다.

현재 Redis는 RDB 방식과 AOF방식을 모두 사용하고 있기 때문에 예기치 않은 에러를 방지하기 위해서는 설정값을 `NO`로 설정하는 것을 권장한다.

 

2. MAXMEMORY-POLICY

해당 옵션은 메모리가 가득 찼을 때의 정책을 관리하는 옵션으로 아래와 같은 세가지 옵션이 존재하며 `allkeys-lru` 옵션을 권장한다.

• noeviction (default) - 삭제하지 않음
• volatile-lru - expire time이 설정되어 있는 것을 대상으로 LRU
• allkeys-lru - 모든 키를 대상으로 LRU

3. MAXMEMORY 값 설정

RDB 저장과 AOF rewirte 시 fork() 시스템콜을 사용한다. 이때 Copy-on-Write로 인해 메모리를 두배로 사용하는 경우가 발생할 수 있기 때문에 Persistence 사용 시 MaxMentry는 실제 메모리의 절반으로 설정해야한다.

 

4. MEMORY FRAGMENTATION 관리

논리적으로 Redis가 사용하고 있는 메모리인 `used_memory`와 OS가 Redis에 할당하기 위해 사용한 물리적 메모리 양인 `used_memory_rss`의 차이가 클 것은 fragmentation이 크다는 것을 나타낸다. 이는 TTL로 인한 eviction이 많이 발생하는 경우와 같이 삭제되는 키가 많을 때 발생한다.

이를 방지하기 위해 `activedefrag` 옵션을 사용할 수 있는데, redis 공식 문서에 따르면 이는 항상 켜두는 것이 아니라 단편화가 많이 발생할 경우 잠시동안 켜두는 것을 권장한다.

`CONFIG SET activedefrag yes`

 

 

 

☑️ 레디스 아키텍처

 

출처 : NHN FORWORD 2021 레디스 야무지게 사용하기!   https://www.youtube.com/watch?v=92NizoBL4uA

 

 

1. Replication

Replication은 Master-Replica 구조로, 데이터 복제는 비동기 방식으로 이루어진다. Replica는 Master로부터 데이터를 복제하지만, 장애 발생 시 수동으로 복구해야 한다는 단점이 있다. 애플리케이션은 장애 발생 시 수동으로 새로운 Redis 서버의 연결 정보를 변경해줘야 한다.

 

 

2. Sentinel

Redis Sentinel은 자동 Failover가 가능한 고가용성(HA) 구성을 제공한다. Sentinel은 Master와 Replica를 모니터링하고, 문제가 발생하면 자동으로 Replica를 Master로 승격한다. 또한 애플리케이션은 Sentinel을 통해 Redis에 연결하므로, 장애 발생 시 연결 정보를 따로 수정할 필요가 없다. 그러나 Sentinel 자체도 장애가 발생할 수 있으므로 3개 이상의 Sentinel 노드를 사용하여 안정성을 높여야 한다는 주의사항이 존재한다.

 

3. Cluster

 

Redis 3.0부터 제공되는 Cluster는 샤딩과 고가용성을 결합한 아키텍처다. 클러스터는 여러 마스터 노드와 그에 대응하는 Replica 노드들로 구성되며, 가십 프로토콜을 통해 노드 간 상태를 모니터링한다. 샤딩을 통해 데이터를 마스터 노드들에 분배하고, 데이터는 해시 함수에 따라 특정 노드에 저장된다. Redis 클러스터는 장애 발생 시에도 전체 노드 중 하나라도 연결되어 있다면, 모든 노드의 상태 정보를 확인할 수 있으며 애플리케이션의 연결 정보 변경이 필요 없다.

 

 

 

 

---

 

☑️ 결론

 

Redis에서 다루는 자료구조, 다양한 캐시 저장 방식 등 많은 내용들이 있지만 이번 글에서는 Redis에 대해 공부하며 새롭게 알게 된 것들에 대해서만 정리해봤다. 앞으로의 개발 중 만나게 될 다양한 트레이드 오프 상황에 도움이 되는 글이 될 수 있을 것 같다는 생각이 든다.