🚀 Redis에서 10MB 단일 Value, 과연 괜찮을까?

Redis를 사용하다 보면 이미지, JSON 문서, 혹은 복잡한 객체를 직렬화하여 통째로 저장하고 싶은 유혹에 빠지곤 합니다. 하지만 Redis 공식 문서나 전문가들은 대개 **"큰 값(Large Value)을 피하라"**고 조언합니다. 만약 10MB 크기의 단일 Key-Value를 사용한다면 어떤 일이 벌어질까요?

1. Redis의 'Stop-the-World' 현상

Redis는 명령어를 처리할 때 싱글 스레드로 동작합니다. 10MB 크기의 데이터를 읽거나(GET) 쓸 때(SET), 네트워크 I/O와 메모리 복사 과정에서 시간이 소요됩니다.

• 지연 시간(Latency): 단일 요청을 처리하는 동안 다른 모든 요청은 큐에서 대기하게 됩니다.
• 처리량(Throughput) 저하: 10MB 데이터를 전송하는 동안 수만 개의 작은 명령어가 처리되지 못하고 밀리게 됩니다.

2. 네트워크 대역폭(Bandwidth) 병목

Redis 서버의 네트워크 카드가 1Gbps라고 가정할 때, 10MB 데이터 하나를 전송하는 데 이론적으로 최소 80ms 이상이 소요됩니다. 초당 수십 개만 호출되어도 네트워크 대역폭이 꽉 차버리는 'Network Bottleneck' 현상이 발생합니다.

3. 메모리 관리와 단편화

Redis는 데이터를 메모리에 저장합니다. 큰 객체는 메모리 할당 및 해제 시 오버헤드가 크며, 빈번하게 업데이트될 경우 **메모리 단편화(Fragmentation)**를 유발하여 실제 데이터 크기보다 더 많은 메모리를 점유하게 될 수 있습니다.

---

🛠 어떻게 해결해야 할까? (Best Practices)

10MB 데이터를 그대로 저장하는 대신, 다음과 같은 전략을 고려해 보세요.

✅ 1. 데이터 분할 (Chunking)

하나의 큰 Value를 여러 개의 작은 Key로 나누어 저장하는 방식입니다.

• 예: large_data → large_data:part1, large_data:part2 ...
• 애플리케이션 단에서 이를 병렬로 읽어와 합치는 방식을 사용하면 Redis의 부하를 분산할 수 있습니다.

✅ 2. 압축 (Compression)

텍스트 기반 데이터(JSON, XML 등)라면 Gzip, Snappy, LZ4 등의 알고리즘으로 압축하여 저장하세요. 10MB 데이터가 1~2MB로 줄어든다면 성능 이슈를 상당 부분 완화할 수 있습니다.

✅ 3. 저장소 분리 (Storage Offloading)

가장 권장되는 방식입니다.

• 실제 데이터(10MB)는 AWS S3 같은 오브젝트 스토리지에 저장합니다.
• Redis에는 해당 데이터의 경로(URL)나 메타데이터만 저장합니다.

✅ 4. 데이터 구조 변경

전체 객체가 아닌 특정 필드만 자주 업데이트한다면, 전체를 하나의 String으로 저장하지 말고 Hash 구조를 사용하여 필요한 필드만 접근(HGET, HSET)하도록 변경하세요.

---

💡 요약 및 결론

Redis에서 10MB 단일 Value를 사용하는 것은 가능은 하지만, 위험합니다. 특히 트래픽이 높은 서비스라면 서비스 전체의 장애로 이어질 수 있는 시한폭탄이 될 수 있습니다.

결론: > 1. 가능하면 1MB 이하로 유지하는 것이 좋습니다. 2. 큰 데이터는 압축하거나 S3로 보낸 뒤 링크만 저장하세요. 3. 반드시 저장해야 한다면 분할 저장을 검토하세요.