2026-05-13T00:04:30.641Z

0

답변 감사합니다. 사용자 응답을 위한 권한 확인, 실제 저장을 위한 권한 확인 두 번의 확인이 필요하며, websocket 서버가 검증 책임을 가질 수 있다고 이해했습니다.

하지만 캐시는 고민이 됩니다. 참가 여부와 차단 여부를 ws 서버에서 검증하려면 ws 서버의 부하 특성 상 캐시를 사용하는 것이 커넥션 고갈 방지와 처리량을 위해 필수적이라고 보여집니다. 그런데 캐시는 네트워크 파티션이나 접속 장애 등 상황에서 일관성을 보장하기 어렵다고 알고 있습니다.

A가 B를 API 서버를 통해 차단하는 경우를 예로 들겠습니다.

1. DB에는 차단 기록 커밋 후 Redis 캐시에 invalidate 또는 write-through가 실패

2. 메시지 큐를 통해서 BlockedEvent를 발행한다면, 캐시에 쓰는 소비자와 Redis 간 파티션 등이나 접속 장애로 쓰기 실패

이 경우에 사용자는 API 서버로부터 차단 요청에 성공 응답을 받지만, ws 서버가 실제로 검증에 사용하는 Redis에는 반영되지 않은 상태가 됩니다. 특히 네트워크 장애나 파티셔닝은 언제 복구될지 모르기 때문에 더 위험하다고 생각됩니다. 채팅에서 사용자는 차단 시 거의 즉시 차단되는 것을 기대할 것이기에 캐시 반영 지연은 서비스에서 허용 불가할 것으로 생각됩니다.

그렇다면

1. Redis 캐시를 사용하면서 일관성을 보장하려면 어떻게 해야하는지

2. 강한 일관성을 위해 DB를 사용하는 것은 성능 상 불가능에 가깝다고 봐야하는지

3. 일반적으로는 invalidation 정도만으로 타협을 해도 괜찮은건지

를 추가로 여쭙고 싶습니다. 감사합니다.

0

안녕하세요. 한재현님,

추가 질문 감사합니다. 아주 좋은 질문을 해주셨습니다.

말씀해주신 우려에 동의하는 부분 입니다.
차단 여부나 채팅방 참가 여부를 Redis에 캐싱하면 WebSocket 서버가 빠르게 검증할 수 있다는 장점이 있습니다. 하지만 Redis 캐시는 결국 DB의 복사본에 가깝기 때문에, 말씀해주신 것처럼, DB와 항상 완전히 같은 상태인 일관성을 보장하기는 어렵습니다.

예를 들어, 아래처럼 A가 B를 차단하는 경우를 생각해보면,

1. A가 B를 차단한다.

2. DB에는 차단 기록이 정상적으로 저장된다.

3. 그런데 Redis 캐시 갱신 또는 invalidate가 실패한다.

4. WebSocket 서버는 아직 이전 Redis 값을 보고 “차단되지 않았다”고 판단할 수 있다.

5. 그러면 B의 메시지가 잠깐 허용될 수 있다.

이러한 경우가 캐시를 사용할 때 생기는 대표적인 정합성 문제입니다.

따라서 Redis를 “진짜 원본 데이터”로 보면 안 되고,

보통은 아래처럼 책임을 나누는 것이 좋습니다.

DB / 권한 서비스 → 원본 데이터

Redis → 빠른 조회를 위한 캐시

WebSocket 서버 → Redis를 보고 빠르게 1차 검증

즉, Redis는 성능을 위해 사용하는 1차 검증 레이어이고, 실제 권한과 차단 상태의 기준은 DB나 권한 서비스에 있어야 합니다.

실제로 공개된 빅테크 사례를 봐도 비슷한 방향을 확인할 수 있습니다.

제가 빅테크 사례를 알아보니, Meta의 Memcache 관련 아티클에서 Meta도 캐시를 “원본 데이터”로 보지 않고, DB의 변경을 캐시에 전파하는 구조를 사용하고 있습니다.

그리고 캐시 불일치는 사용자 입장에서 데이터 유실처럼 보일 수 있기 때문에, Polaris라는 별도 시스템으로 캐시가 DB와 일치하는지 계속 측정하고 추적하여 이 문제를 해결하고 있음을 알 수 있습니다. 그래서 다른 방안으로는 캐시 불일치를 측정하고 복구하는 별도 시스템도 고려해보는 것도 좋은 방법으로 생각됩니다.

다른 사례를 보면, Uber도 비슷합니다. Uber의 Docstore 통합 캐시 사례를 보면, 캐시 invalidation만으로는 기본적으로 eventual consistency가 됩니다.

그래서 읽기-쓰기 직후 일관성이 더 중요한 경우에는 write가 끝난 뒤 해당 캐시 row를 명시적으로 invalidate하는 API를 따로 두었다고 설명합니다. 즉, 일반적인 캐시 경로와 더 강한 정합성이 필요한 경로를 분리하는 것 입니다. 강한 정합성이 필요한 요청은 캐시를 우회하거나 별도 경로로 처리해야 한다는 의미입니다.

그래서 아래와 같이 합리적인 설계방안으로 하는 것을 고려해야 합니다.

1. WebSocket 서버에서 Redis를 보고 빠르게 1차 검증한다.

2. 메시지 서버에서 중요한 권한을 한 번 더 확인한다.

3. DB 저장 직전에도 필요한 경우 최종 검증을 한다.

4. 차단 이벤트는 유실되지 않게 전파한다.

5. 캐시 상태가 불확실하면 메시지를 허용하기보다 거절하거나 보류한다.

여기서 차단 이벤트의 경우에는 DB에 차단 기록을 저장할 때 “이 차단 사실을 다른 시스템에도 알려야 한다”는 기록을 DB에 같이 남겨두는 방식입니다.

DB transaction 안에서 같이 저장

1. A가 B를 차단했다.

2. 이 차단 이벤트를 Redis / WebSocket 서버 / 메시지 서버에 알려야 한다.

이렇게 하면 Redis 갱신이나 이벤트 발행이 일시적으로 실패하더라도, DB에 남아 있는 미처리 이벤트를 보고 나중에 다시 시도할 수 있습니다.

DB에 차단 기록 저장 → BlockedEvent 저장

→ 별도 worker가 Redis 갱신 / 이벤트 발행 시도

→ 실패하면 재시도 → 성공하면 처리 완료

하지만 위와 같이 설계한다고 해서 Redis가 항상 즉시 100% 최신 상태가 된다는 뜻은 아닙니다. DB와 Redis는 서로 다른 시스템이기 때문에 아주 짧은 순간이라도 상태가 어긋날 수 있고, 네트워크 장애가 길어지면 그 차이도 길어질 수 있습니다.

그래서 질문 주신 “그럼 강한 일관성을 위해 DB를 사용하는 것은 성능 상 불가능에 가깝다고 봐야하는지” 부분에 대해서는, 무조건 불가능하다고 볼 수는 없지만, 대규모 채팅 시스템에서는 모든 메시지마다 DB를 직접 조회하는 방식은 보통 부담이 큽니다.

메시지 하나를 보낼 때마다 매번 아래 정보를 DB에서 확인하면 트래픽이 많아질수록 DB가 병목이 될 수 있습니다. 그래서 DB 의 병목을 해결하기 위해 아래와 같이 설계하는 것을 권장드릴 수 있습니다.

일반적인 메시지 전송 → Redis 캐시로 빠르게 1차 검증

캐시 miss / Redis 장애 / 상태가 불확실한 경우 → DB 또는 권한 서비스로 fallback 처리

차단 직후처럼 민감한 상태 → 더 강하게 검증하거나, 불확실하면 메시지를 막음

DB 저장 직전 → 메시지 서비스에서 최종 검증

또 하나 중요한 기준은 데이터의 성격입니다.

온라인 상태, 입력 중 표시, 읽음 여부처럼 잠깐 늦게 반영되어도 되는 정보는 eventual consistency 최종 일관성으로 타협할 수 있습니다.

반면 차단 여부, 채팅방 참가 권한, 유료 구독자 권한, 관리자 권한처럼 잘못 허용되면 문제가 큰 정보는 단순 Redis invalidation만으로는 부족할 수 있습니다.

정리하면 다음과 같습니다.

Redis 캐시만으로 차단/권한 검증의 강한 일관성을 보장하기는 어렵습니다. 하지만 모든 메시지마다 DB를 조회하는 것도 대규모 채팅 시스템에서는 부담이 큽니다.

그래서 Redis는 빠른 1차 검증에 사용하고, DB 또는 권한 서비스는 원본 데이터로 유지하며, 차단처럼 중요한 기능은 여러 단계에서 한 번 더 검증하는 구조가 더 합리적인 시스템이 될 것으로 생각합니다.

그래서 차단, 권한, 구독 여부처럼 잘못 허용되면 문제가 큰 데이터는 캐시만 믿지 않고, 캐시 갱신 실패를 대비한 재시도 구조와 최종 검증 레이어를 함께 두는 것을 권장 해드리고 싶습니다.

다른 질문 사항이 있으시면 언제든지 남겨주세요!

감사합니다.
좋은 밤 되시고, 즐거운 한 주가 되시길 바랍니다.

2026-05-12T05:26:12.862Z