[Redis] Redis를 활용한 메타데이터 처리 구조 설계기

1. 발단: 불안정한 메타데이터 처리

링크 저장 서비스를 개발하는 과정에서, 메타데이터를 비동기적으로 처리하는 로직에 문제가 있다는 사실을 발견했다.

한 번의 요청당 평균 700ms의 시간이 소요되었고, 동시에 여러 사용자가 요청을 보냈을 때 일부는 정상적으로 처리되었지만, 일부는 URL만 저장되거나 아예 저장이 되지 않는 상황이 발생했다.

즉, 동일한 API 호출임에도 결과가 달라지는 불안정성이 있었고, 이 문제는 사용자 경험에 직접적인 악영향을 끼칠 것이라 예상했다. (코드를 확실히 잘못 짰다..)

2. 해결책을 찾다: Redis를 떠올리다

이 문제를 해결하기 위해 여러 방안을 고민하던 중, 과거 채팅 서버를 구현할 때 사용했던 Redis가 떠올랐다.

Redis는 단순한 캐시 서버를 넘어서 인메모리 기반의 빠른 데이터 처리, 다양한 자료구조 지원, TTL 기반 자동 만료 기능을 제공한다.

특히, “비동기적으로 처리되는 메타데이터의 상태와 결과를 임시로 저장하는 공간”이 필요했던 내 상황과 Redis의 특성이 잘 맞아떨어졌다.

3. 아키텍처 설계: Queue + Status + Cache

Redis를 도입하면서 전체 흐름을 다음과 같이 설계했다.

1. Request Queue

       public Map<String, String> enqueue(MetadataRequestDto req) throws JsonProcessingException {
           Map<String, String> job = Map.of("requestId", req.getId(), "url", req.getUrl());
           redisTemplate.opsForList().leftPush("metadata:queue", objectMapper.writeValueAsString(job));
           return Map.of("requestId", requestId);
       }

   클라이언트가 URL을 제출하면, 서버는 requestId를 발급한 뒤 Redis Queue(List 또는 Stream)에 등록한다.
   
   
2. Worker/Processor

   @Scheduled(fixedDelay = 1000)
       public void processQueueBatchAsync() {
       // batchSize는 적당히..
           for (int i = 0; i < batchSize; i++) {
               String jobJson = redisTemplate.opsForList().rightPop("metadata:queue");
               if (jobJson == null) break;
   
               asyncProcessor.processJobAsync(jobJson);
           }
       }

   별도의 워커가 Queue에서 요청을 꺼내 메타데이터를 처리한다.
   
   
3. Result Cache (String/JSON)

       @Async
       public CompletableFuture<Object> processJobAsync(String jobJson) {
           try {
               Map<String, String> job = objectMapper.readValue(jobJson, new TypeReference<>() {});
               String requestId = job.get("requestId");
               String url = job.get("url");
   
               return processor.fetchMetadata(url)
                       .toFuture()
                       .thenApplyAsync(metadata -> {
                           try {
                               String resultJson = objectMapper.writeValueAsString(metadata);
                               redisTemplate.opsForValue().set("metadata_result:" + requestId, resultJson, ...);
                           } catch (Exception e) {
                               log.error(" 메타데이터 JSON 직렬화 실패", e);
                           }
                           return null;
                       })
                       .exceptionally(e -> {
                           log.error(" Async 메타데이터 처리 실패", e);
                           return null;
                       });
           } catch (Exception e) {
               log.error(" Async 메타데이터 처리 실패", e);
           }
           return CompletableFuture.completedFuture(null);
       }

   최종 메타데이터 결과를 JSON 형태로 저장한다. 이 역시 TTL을 설정하여 일정 시간이 지나면 자동으로 삭제된다.
4. Status 반환 (Hash)

   public Map<String, Object> getStatus(String requestId) throws JsonProcessingException {
           String resultJson = redisTemplate.opsForValue().get("metadata_result:" + requestId);
           if (resultJson == null) {
               return Map.of("status", "pending");
           }
           MetadataResponseDto result = objectMapper.readValue(resultJson, MetadataResponseDto.class);
           return Map.of("status", "done", "data", result);
       }
   

   각 requestId의 상태(pending, done)를 Hash 구조로 반환한다.
   
   
5. 클라이언트 폴링
   클라이언트는 requestId를 사용해 상태와 결과를 주기적으로 조회한다. 완료되면 결과를 가져와 UI에 반영한다.

이 구조 덕분에, 요청은 즉시 응답할 수 있고, 실제 무거운 메타데이터 파싱 로직은 워커가 뒤에서 처리하게 되었다.

4. 운영 시 고려한 부분

• 메모리 관리: Redis의 eviction 정책 때문에 큐나 상태 데이터가 날아가지 않도록 메모리 여유를 확보해야했다.
• 멱등성: 같은 requestId가 중복 처리되지 않도록 Key값을 UUID로 처리했다.
• 모니터링: 요청 처리량, 평균 지연 시간, 실패율 등을 지표로 수집해 운영 상황을 가시화를 하였다 (그라파나, 프로메테우스 사용).

5. 결론

Redis는 단순히 “캐시 서버”라는 이미지를 넘어서, 비동기 작업 큐 + 상태 저장소 + 임시 캐시 역할을 동시에 수행할 수 있는 강력한 도구다. Redis 기반 아키텍처를 적용한 후, 메타데이터 처리 요청의 평균 응답 시간이 700ms에서 400ms로 약 43% 단축되었다. 단순히 안정성뿐만 아니라 성능 개선 효과도 함께 얻을 수 있었다.

앞으로는 Redis Streams, Consumer Group, Dead Letter Queue 등을 도입해 확장성과 복원력을 더욱 강화할 계획이다. (공부할게 많다.. 즐겁다..!!)