Inflearn Community Q&A

문영훈님 좋은 질문 해주셔서 감사합니다!!

1. 가설이 맞습니다

문영훈님이 예상하신 대로, 피드 100개에 대해 각각 Redis에 "이 글이 새로운 글인지?" 확인하는 요청을 보내면, Redis 명령 자체는 마이크로초 단위로 빠르지만 네트워크 왕복(round-trip)이 100번 발생합니다. Redis는 메모리에서 데이터를 꺼내는 건 극도로 빠르지만, 애플리케이션 서버와 Redis 서버 사이의 네트워크 통신 비용은 매번 발생하거든요. DB SELECT도 비동기 병렬로 100개가 동시에 나가면, 커넥션 풀에서 동시에 처리되니까 결과적으로 Redis 100번 호출과 체감 시간이 비슷해질 것 같습니다

강의 교재에서도 다루고 있지만, Redis가 DB보다 빠른 이유는 "디스크 I/O 없이 메모리에서 바로 데이터를 꺼낸다"는 점인데, 이건 단일 요청 기준의 이야기입니다. 네트워크 호출 횟수가 많아지면 그 이점이 희석될 수 있습니다

2. 실무에서도 당연히 네트워크 호출 횟수를 고려합니다

Redis가 빠르다고 해서 무한정 호출해도 된다고 생각하면 안 되고, "한 번의 연결로 최대한 많은 작업을 처리한다"는 원칙을 항상 염두에 두는 편입니다

이걸 위해 Redis에서 제공하는 대표적인 기능이 Pipeline입니다. Redis Pipeline은 여러 개의 명령을 한 번의 네트워크 왕복으로 모아서 보내는 기능인데요, 영훈님 상황에 딱 맞는 해결책입니다. Spring Data Redis를 쓰고 계시다면 RedisTemplate.executePipelined() 메서드를 확인해보시길 추천드립니다!참고: https://redis.io/docs/latest/develop/use/pipelining/

3. 프로젝트에 적용하는 방향

말씀해주신 것처럼, 피드별로 새로운 글 목록을 모은 다음 한 번에 Redis에서 확인하는 방식이 맞습니다. 구체적으로 두 가지 접근이 가능해요.

첫 번째는 Redis Pipeline을 사용하는 방법입니다. 피드에서 가져온 글들의 식별자(URL이나 ID)를 모아두고, Pipeline으로 한 번에 EXISTS 또는 GET 명령을 보내면 네트워크 왕복이 1번으로 줄어듭니다. 100개 피드에서 글이 총 500개 나왔다면, 500번 호출하던 걸 1번으로 줄이는 거예요.

두 번째는 Redis의 Set 자료구조를 활용하는 방법입니다. 이미 처리한 글의 식별자를 Redis Set에 넣어두고, SISMEMBER 명령을 Pipeline으로 묶어 한 번에 확인하는 방식도 깔끔합니다. 혹은 SMEMBERS로 전체 Set을 한 번에 가져온 뒤 애플리케이션 레벨에서 비교하는 것도 데이터 양에 따라 효율적일 것 같습니다

4. 이렇게 개선하면 이력서에 쓸 수 있는 경험이 됩니다

영훈님이 발견한 이 상황 자체가 아주 좋은 이력서 소재입니다. "Redis를 도입했는데 기대만큼 성능이 안 나왔다 → 원인을 분석해보니 네트워크 라운드트립이 병목이었다 → Pipeline을 적용해서 네트워크 호출 100회 → 1회로 줄이고 성능을 개선했다" 이 흐름이 바로 문제 → 해결 → 결과 구조거든요.

개선 전후를 측정해서 "Redis 호출 100회 → Pipeline 적용으로 1회, 스케줄러 작업 소요 시간 X초 → Y초로 Z% 개선"이런 수치를 만들어보시면, 단순히 "Redis 캐싱 적용"보다 훨씬 깊이 있는 경험을 어필할 수 있습니다.

지금 이 문제를 스스로 발견하고 가설까지 세우신 거 정말 잘 하고 계신 거니까, Pipeline 적용해서 수치 만들어보시고 이력서에 녹여보시면 좋겠습니다. 파이팅입니다!!!

안녕하세요, 인프런 AI 인턴입니다. 문영훈님.

Redis를 사용하였을 때 성능 차이가 미미하다는 점에 대해 질문 주셨군요. Redis는 주로 메모리 내에서 데이터를 저장하므로 빠른 속도를 제공합니다. 그러나 네트워크의 오버헤드와 같은 요소가 성능에 영향을 줄 수 있습니다. 아래는 이 문제와 관련하여 고려할 수 있는 몇 가지 포인트입니다:

Redis 사용 시 성능 최적화 방법:

1. 네트워크 오버헤드 최소화:

   • Redis와의 통신은 네트워크를 통해 이루어지므로, 불필요한 빈번한 요청은 피하는 것이 좋습니다.
     
   • 요청을 Batch로 묶어 한번의 요청으로 여러 데이터를 조회하거나 저장하는 것이 효율적일 수 있습니다.
     

2. 데이터 구조 활용:

   • Redis는 다양한 자료구조를 지원하므로 적절한 자료구조를 사용하는 것이 중요합니다. 예를 들어, 여러 피드의 정보를 저장할 때, 적합한 데이터 타입(예: List, Set)을 사용하여 데이터를 효율적으로 처리할 수 있습니다.
     

3. 파이프라이닝(Pipelining) 사용:

   • Redis는 파이프라이닝 기능을 지원하여 여러 명령어를 하나의 요청으로 보내는 것이 가능합니다. 이를 통해 네트워크 왕복 시간을 줄일 수 있습니다.
     

4. 캐싱 전략 재검토:

   • 캐시할 데이터의 대상으로 적절한 것을 선택하고 캐싱 계층이 증가하도록 설계합니다. 예를 들어, 새 피드 판단 로직을 캐싱하여 DB 조회를 줄이도록 개선할 수 있습니다.
     

5. 모니터링 및 프로파일링:

   • Redis와 DB 조회 간의 성능 차이가 거의 없다면, 애플리케이션에서 요청 처리 시간을 모니터링하고 병목 지점을 분석해야 합니다. Redis 명령어의 처리 시간도 프로파일링하면 도움이 됩니다.
     

문영훈님께서 올바르게 가정하셨듯이, 네트워크 트래픽을 최소화하고 효율적인 접근 패턴을 설계하는 것이 Redis의 성능을 제대로 발휘할 수 있는 핵심입니다. 관련하여 자세한 설명과 해결책은 아래 링크의 유사한 질문을 참조하시면 도움이 될 것입니다:

• 질문 제목: Redis 캐싱과 성능 최적화 방법
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.