어려웠던 점

1. Redis 내에서의 팔로우 양방향 관계 지정

• 비관계형 데이터 베이스에서 팔로우 관계를 어떻게 처리할 것인지 긴 고민을 했습니다.
• 단방향 관계인 좋아요 기능과는 달리 팔로우의 N:M 관계를 어떻게 풀어나갈 지 초점을 맞췄습니다.
• 기회비용을 고려해야 했습니다.
  • 양방향 저장 시 데이터 적재량 증가 vs 단방향 데이터 저장 시 탐색 효율 저하

💡 이렇게 해결했습니다.

• 와일드카드를 최대한 지양하는 방향이 올바르다고 판단하여 양방향 저장을 선택했습니다.
• “following”, “follower” 접두사를 붙이는 key 네이밍 전략을 활용하여 양방향으로 저장했습니다.
• 최종적으로, 유저의 팔로워 및 팔로잉 리스트 조회 시 탐색 시간을 크게 줄일 수 있었습니다.

2. Spring Batch를 통한 데이터 동기화 시 전체 탐색 문제

• 배치 작업에서 Redis의 데이터를 MySQL로 동기화하는 작업은 매일 새벽 3시에 진행됐습니다.
• 이 때, Redis에서 업데이트 된 데이터만을 배치 작업에 태우기 위한 다양한 시도를 했습니다.

💡 이렇게 해결했습니다.

• Redis의 ZSET 자료형을 활용하여, 스코어를 데이터 업데이트 시간으로 지정했습니다.
• 데이터가 업데이트 될 때마다, 해당 데이터의 key값을 update ZSET에도 반영했습니다.
• 이를 통해, 이전 배치 시간 이후 발생한 업데이트의 키 값만을 동기화 할 수 있었습니다.
• 배치 마무리 시점에는, ZSET을 초기화함으로써 새로운 업데이트 set만을 담을 수 있게 했습니다.
  • 나아가, 좋아요나 팔로우 취소로 인해 Value의 자료형이 Empty일 경우, 이를 테이블에서 제거하여 추가적인 공간 확보 작업도 진행했습니다.

3. 최종 통계 도출 시 Top 5 가격의 영수증 파악

• 최종 데이터 통계를 구할 때, 가격 순으로 가장 비싼 5개의 영수증을 파악해야했습니다.
• 모든 유저의, 모든 영수증을 한 번에 파악하기에는 너무 많은 비용이 발생한다고 생각했습니다.

💡 이렇게 해결했습니다.

• 데이터 업데이트 시 ZSET을 활용했던 방법을 응용하였습니다.
• 어느 한 시점에 발생하는 탐색 효율 저하를, 유저에게 실시간으로 분산시키는 전략을 선택했습니다.
• 유저가 영수증을 저장할 때, Top5 영수증 ZSET에도 가격을 score로 지정하여 반영했습니다.
  • 우선순위에 따라 6위로 지정된 영수증은 자동적으로 삭제하여 5위권을 갱신했습니다.