refactor: redis를 활용한 조회 성능 최적화

[mikekks]

👩‍💻 Contents

구현 오버뷰

• 레디스를 사용해서 변동성이 적은 데이터를 캐싱해봤습니다.
• 모임 정보, 모임장, 공동모임장 정보를 캐싱하여 캐싱된 경우에 쿼리를 3회 줄였습니다.

Reader 레이어

• Repository와 service 레이어 사이에 Reader 레이어를 두었습니다.
• 해당 레이어의 역할은 캐싱된 데이터가 있다면 그 데이터를 반환하고, 캐싱되지 않았다면 repository 로 내려가서 해당 데이터를 조회합니다.

캐싱 방식

• 상세 모임 조회에서 캐싱을 저장합니다.
• 모임 수정 API에서 해당 모임이 캐시에 저장되어있으면 해당 캐시를 삭제합니다.

레디스 테스트 컨테이너

• 테스트 환경에서도 레디스를 어떻게 해야할지 고민이 많았습니다.
• local redis에 의존하는 것은 너무 불편하다고 생각이 들어 test container로 레디스를 띄어서 구현했습니다.
• 해당 구현은 redisContainerBaseTest 클래스 보시면 되겠습니다!
• 해당 방법은 아래 사진과 같습니다!
  • 참고자료 : https://loosie.tistory.com/813#3._Testcontainers%EB%A1%9C_%ED%86%B5%ED%95%A9_%ED%85%8C%EC%8A%A4%ED%8A%B8_%ED%99%98%EA%B2%BD_%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

트러블슈팅 - 직렬화/역직렬화

• 이번에 구현하면서 가장 애먹은 부분이었습니다.
• 먼저 LocalDateTime은 직렬화가 되지 않는 문제가 있었습니다.
• 뿐만 아니라, UserActivityVO, ImageUrlVO, mStartDate 등과 같은 객체도 직렬화가 제대로 되지 않았습니다.
• 따라서 해당 데이터들을 직렬화 하기 위한 코드 수정이 있었습니다.

트러블 슈팅 - 하이버네이트 Lazy 로딩 객체 직렬화/역직렬화

• Meeting 객체 내의 User 객체의 직렬화/역직렬화 문제도 있었습니다.
• 연관관계가 있는 객체(User) 까지 레디스에 저장하려고 했지만 그게 잘 되지 않았습니다.
• 그래서 Meeting 따로, User 따로 조회하고자 했습니다.
• 하지만 첨부사진에서 426번라인에서 Meeting 를 조회할 때, Meeting 객체 내에 있는 User 가 427번 라인의 meetingLeader 에도 저장되는 문제가 있었습니다. 하지만 Meeting 객체 내에 있는 User는 Lazy loading 방식이어서 null로 저장되어 있기 때문에 meetingLeader도 null 저장되는 문제가 있었습니다.
• 그래서 UserReader 에서 User 가 아닌 MeetingCreatorDTO를 캐시하도록 구현했습니다..! 이게 설명이 어려운데 같이 얘기해봐도 좋을 것 같아요!

유의사항

• 현재 인프라 테스트를 위해 github workflow를 변경한 상태입니다. 머지 전에 수정하고 머지하도록 하겠습니다.

추가적으로 했던 것들

• 서버 에러의 경우 에러 트레이스를 보는게 도움이 돼서 트레이스를 모두 출력하도록 수정해봤습니다!

성능 개선 (warm-up 제외하고 3회 3000번 요청 진행)

local - redis 전
639 ms
581 ms
625 ms

dev - redis 전
2233 ms
2008 ms
1655 ms

local - redis 후
290 ms
280 ms
281 ms

dev - redis 후
1715 ms
1503 ms
1101 ms

그래도 1.5배 정도 빨라진 것 같습니다!

📝 Review Note

인프라

• 저번에 레디스의 도커 컴포즈에 대해 얘기가 있었는데 의견여쭤보고 싶습니다!
• 현재는 컴포즈 내에 레디스를 넣어둔 상황입니다.
• 그 이유로, 개발 하면서 경험했던 것을 말씀드려보겠습니다! 캐시에 저장된 데이터와 스프링 서버에서 불러오려는 객체 간의 차이가 발생하면 오류가 발생합니다. 이런 부분을 생각해봤을 때, 배포가 될 때 redis도 함께 새로 세팅하는게 좋겠다고 생각하여 함께 컴포즈로 묶어줬습니다. 이 부분에 대해 의견 궁금합니다!

📣 Related Issue

• closed refactor: redis 도입 #477

✅ 점검사항

• docker-compose.yml 파일에 마이그레이션 한 API의 포워딩을 변경해줬나요?
• Spring Secret 값을 수정하거나 추가했다면 Github Secret에서 수정을 해줬나요?
• Nestjs Secret 값을 수정하거나 추가했다면 Docker-Compose.yml 파일 및 인스턴스 내부의 .env 파일을 수정했나요?

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[pull-request-size]

Hi there 👋

Using this App for a private organization repository requires a paid subscription.

You can click Edit your plan on the Pull Request Size GitHub Marketplace listing to upgrade.

If you are a non-profit organization or otherwise can not pay for such a plan, contact me by creating an issue

[mikekks]

Dto 부분과 코멘트 남긴 부분 한 번 체크해주시면 감사하겠습니다!

더 좋은 의견있으시면 환영입니다!

[hoonyworld]

고생하셨습니다 민규님!

코멘트 한번 봐주시면 감사하겠습니다.

[hoonyworld]

고생하셨습니다 민규님!

코멘트 한개 남겼습니다! 해당 사항에 대해서 논의가 해결되면 머지해도 좋을 것 같습니다.