Redis에서 presence(현재 접속중인 인원)을 관리하는 방법과, 에러 시 처리방법

[parkjuyeong0312]

개발 상황
Redis에서는 현재 접속중인 인원을 관리하고 있습니다.
Redis의 메인메모리(RAM)에 현재 접속중인 멤버 정보를 관리합니다.

Redis은 key, value형식의 nosql이며, value의 경우 다양한 자료구조를 사용할 수 있습니다.

1. 현재 접속 인원
   key : room:{roomId}:connected_users
   value : SET["userid",...]

set으로 현재 접속 인원을 관리합니다.

2. 접속 인원의 세션관리
   key : room:{roomId}:sessions:{userId}
   value : SET [ "sess-abc", "sess-def" ]

set으로 유저별로의 세션관리를 합니다.

• 접속 시: SADD로 추가
• 종료 시: SREM으로 제거 (마지막 세션이면 connected_users에서도 제거)
• 추방/탈퇴 시: removeAllSessions으로 전체 삭제

문제상황
Redis에서 오류가 발생했을 시, presence 처리가 되지 않았다고 했을때, client의 접속 상황과 동기화하는 로직이 없습니다. 즉, removePresenceSafe에서 Redis 예외 발생 시, presence가 삭제되지 않고 영구적으로 남습니다.

• 이미 방을 떠난 유저가 getOnlineUserIds()에서 계속 온라인으로 조회됨
• 현재 TTL이나 cleanup 메커니즘이 없어 Redis 재시작 전까지 찌꺼기 잔존

해결방안
1. retry
try-catch문 안에서 만약 redis상에 presence(현재 활동 멤버) 갱신이 실패된다면, redis 갱신을 retry를 하는 방법.
이 방법의 경우, 단순한 네트워크 단절은 해결되지만, Redis 서버 자체 장애시에는 문제점을 해결할 수 없습니다.

2. TTL+heartbeat
유저별 presence 키에 TTL을 설정한다.
클라이언트가 주기적으로 heartbeat를 전송해서 TTL을 갱신한다.(Sliding TTL)
heartbeat 중단시 해당 세션은 자동 만료된다.

이 방법의 경우, 클라이언트에서 Redis에게 heartbeat를 주기적으로 호출해야되고, Redis의 입장에서는 트래픽이 증가해 부담이 될 수 있음.

논의 사항
현재 mvp 단계에서 급한 부분은 아닌 것 같습니다. Redis에서 오류가 발생한다는 가정하에 생기는 문제점을 해결하는 방법에 대해 논의한 것이라서요. 하지만, 이슈는 일어날 수 있고, 어떤 해결방식으로 처리해야하는지 논의할 필요는 있을 거 같아 올려봅니다.

[minbros]

저도 저거 한번 확인한 적이 있었는데, 결국에 제대로 구현하려면 1, 2번 다 필요할 것 같아요. 그리고 지금 프론트엔드 딴에서는 이미 하트비트를 계속 쏘고 있더라고요. 기본값인지 에이전트가 직접 구현한 건지는 모르겠는데, 저희도 하트비트를 클라이언트한테 쏘게 만들어서 둘 중 하나가 하트비트를 받지 못하면 Redis에서 세션을 제거하는 로직이 필요할 것 같아요

[minbros]

아 지금 보니까 서버에서 SockJS를 적용하도록 활성화한 상태인데 여기에 하트비트가 자동으로 포함되고 있어서 클라이언트한테 전달이 되고 있었던 거네요! 그러면 따로 하트비트 설정은 넣을 필요가 없을 것 같고 Sliding TTL이랑 retry 로직만 넣으면 될 거 같아요

[minbros]

Redis에서 Set으로 세션 관리가 되는 부분은 어떻게 제거해야 하는지 물어봤는데, Redis Keyspace Notification을 이용한다고 해요. 이것에 대한 클로드 코드 답변입니다!

양쪽 모두 설정이 필요합니다.

---

Redis 쪽 (활성화)

기본값이 비활성화라서 redis.conf 또는 런타임 명령으로 켜야 합니다.

notify-keyspace-events Ex
# E = Keyevent 방식, x = expired 이벤트

Spring 설정에서 런타임으로 켤 수도 있습니다.

// 앱 시작 시 한 번 실행
redisTemplate.execute((RedisCallback<Void>) conn -> {
    conn.setConfig("notify-keyspace-events", "Ex");
    return null;
});

---

앱 쪽 (구독 + 처리)

Spring Data Redis의 RedisMessageListenerContainer로 만료 이벤트를 구독합니다.

// __keyevent@0__:expired 채널 구독
// 만료된 키 이름이 메시지로 날아옴
// ex) "room:{id}:sessions:{userId}" → connected_users에서 userId 제거

---

주의사항

Redis에서 만료 이벤트가 발행될 때 키는 이미 삭제된 상태입니다. 만료된 키 이름만 메시지로 받으므로, 키 이름에서 roomId와 userId를 파싱할 수 있도록 키 네이밍 패턴을 잘 설계해야 합니다.

현재 키 패턴 room:{id}:sessions:{userId}은 파싱하기 좋은 구조라 그대로 써도 됩니다.

[minbros]

이벤트 기반으로 안하고 스케줄링 방식으로 갱신하도록 구현해도 되는데, 제대로 써보려면 이런 걸 도입해 보는 게 좋을 것 같아서 스케줄링 방식보다 좀 더 복잡하더라도 이걸 선택했어요

[parkjuyeong0312]

확인했습니다!구현전에 고민해보고, 추가로 논의해야될 부분 있으면 코멘트 남길게요

[parkjuyeong0312]

TTL 설정
고민해보니, 스케줄링이든 이벤트 기반이든, 세션에 TTL은 필수입니다.
유저가 stale 상태인지 판단하려면 세션 키가 살아있는지를 봐야 하는데, TTL이 없으면 세션 키가 영원히 남아있어서 판단 자체가 불가능하니까요.
그래서 흐름은 이렇게 갑니다.

• 세션은 TTL이 지나면 삭제
• SET과 세션 키의 존재 여부를 비교
• 다르다면 SET에서 해당 유저 제거

TTL은 누가 갱신할 것인가
이벤트 기반으로 간다면

• 프론트에서 주기적으로 ping을 쏴준다
• ping이 올 때마다 서버는 TTL을 sliding(refresh) 해준다
• ping이 끊기고 TTL이 만료되면 만료 이벤트가 발생
• Spring 서버가 그 이벤트를 받아 SET에서 현재 활동 멤버를 제거

근데 이벤트 기반의 문제는, 서버가 꺼져서 이벤트가 유실되면 복구할 방법이 없다는 점입니다.
이걸 해결하기 위해 스케줄링을 같이 넣습니다.

최종 설계

• ping 주기: 30초 (프론트 → 서버)
• TTL sliding: ping이 올 때마다 갱신
• 백업 스케줄링: TTL sliding과 무관하게 일정 주기로 SET을 스캔해 stale 유저 정리

ping이 멈추고 TTL이 만료된 시점에 마침 서버가 꺼져서 이벤트가 유실된다 하더라도, 스케줄러가 돌면서 잡아서 처리해주는 구조입니다.
이벤트가 유실되는 최악의 경우, 스케줄링 주기만큼 유령 유저가 남아있게 됩니다.

서버가 이벤트를 유실하는 케이스 자체가 흔하지 않고, 어디까지나 백업용 안전장치이기 때문에 너무 자주 돌릴 필요는 없다고 봅니다. 5분이나 10분 주기 정도면 충분하다고 판단해서 그 선에서 잡으려고 합니다.