Redis Persistence와 운영 모드
문제 상황
로그인 시 사용 및 발급되는 Access Token, Refresh Token 저장에 Redis를 사용하고 있었으며, Google Cloud의 관리형 쿠버네티스 서비스 GKE에서 Deployment로 배포하여 사용 중이었다.
문제는 Redis의 Persistence 설정을 주지 않아 클라우드 벤더사(Google)의 노드 관리 작업으로 인해 Pod가 노드에서 추출될 때 Redis 메모리의 데이터가 소실되었다.(사실 당연히 발생할 수 밖에 없는 문제였다.)
문제는 JWT 형식의 Access Token의 유효 기한이 30분이라, 최대 30분 뒤에는 모든 클라이언트의 로그인이 풀린다는 점이었다.
위 문제 상황으로 인해 Redis Persistence는 필수로 설정하고, Cluster 단위의 설정까지 필요한지 확인해보기로 했다.
Persistence
RDB(Redis Database)
일정 주기마다 메모리 내의 데이터셋을 스냅샷으로 백업하는 방식이다.
장점
- 스냅샷 그대로 로드하면 되므로 복구 속도가 빠르다.
- 주기적으로 백업하므로 성능 부하가 생길 가능성이 낮다.
단점
- 마지막 스냅샷 이후의 변경 내용은 소실된다.
AOF(Append Only File)
모든 쓰기 작업 명령을 파일로 저장하는 백업 방식이다.
장점
- 소실되는 데이터가 존재할 가능성이 낮다.
단점
- 로그에 적힌 모든 명령어를 실행해야 하므로 복구 속도가 느리다.
- 명령어를 기록해야 하므로 I/O 작업이 증가한다.
RDB, AOF 중 하나만 선택해야 하는게 아니고 둘 다 사용할 수도 있다.
StandAlone
일반적으로 Redis Image를 그대로 Deployment로 배포하는 경우 StandAlone으로 작동하며, Redis 인스턴스를 하나만 사용해 Write, Read가 같은 단일 엔드포인트를 사용하게 된다.
장점
- 단일 인스턴스이기 때문에 관리가 쉽다.
- 읽기, 쓰기 엔드포인트가 하나기 때문에 클라이언트 연결도 간편하다.
- 동기화 작업이 없기 때문에 정합성 문제 역시 없다.
- 소모 리소스가 적고 복제본 간 통신이 필요없다.
단점
- 단일 인스턴스이기 때문에 가용성이 낮다.
- 쓰기와 읽기가 같은 인스턴스에서 작동하기 때문에 과부하가 발생하기 쉽다.
Replication
Master 인스턴스와 그 복제본인 Replica 인스턴스를 분리하여 읽기 전용으로 사용하는 운영 모드이다.
읽기/쓰기 두 개의 엔드포인트를 두어 쓰기 작업과 읽기 작업의 트래픽 분리가 가능하다.
Sentinel
- Master 인스턴스에 재해 발생 시 자동으로 Failover 하기 위해 존재하는 서버
- Sentinel 사용 시 Failover 이후 Master 인스턴스로 전환하기 위해 클라이언트 측 작업이 필요하다.
RedisClient client = RedisClient.create(); RedisURI uri = RedisURI.Builder .sentinel("sentinel-host", "mymaster") .withSentinel("sentinel-host2") .withSentinel("sentinel-host3") .build(); StatefulRedisConnection<String, String> conn = client.connect(uri);
장점
- 쓰기와 읽기의 엔드포인트가 나뉘어 부하 분산이 가능함.
- Sentinel을 통해 가용성을 챙길 수 있음.
단점
- 동기화 과정에서 데이터가 서로 맞지 않는 정합성 문제가 발생할 가능성도 있음.
Failover도 시간이 소요되기 때문에 완전한 무중단 운영은 불가능하다.
Cluster
데이터를 여러 노드에 분산 저장(샤딩)하면서, 다중 Master-Replica 구조로 고가용성까지 지원하는 Redis의 확장형 모드이다.
장점
- 각 Master에 여러 Replica가 존재해 고가용성을 보장한다.
- 데이터 저장과 트래픽이 분산 처리된다.
단점
- 설정과 운영이 복잡하다.
- 인스턴스가 많으니 소모되는 리소스가 높다.
선택한 방식
아래의 이유로 Redis StandAlone에 Persistence는 AOF + RDB로 대응하기로 결정했다.
- Redis 활용 범위가 Access/Refresh Token에 한정되어 트래픽 부담이 크지 않았다.
- 클라우드 벤더의 작업을 제외하면 Redis 자체 장애가 없었다.
- 클라이언트 구성 변경을 최소화하고 싶었다.
추후 트래픽 증가나 다른 데이터 저장 용도로 Redis를 확장하게 된다면 Replication 또는 Cluster로 전환을 고려해야할 듯 싶다.
참고자료
