[Refactor] #263 - User 데이터 캐싱

[its-sky]

🚀PullRequest🚀

📟 관련 이슈

• Resolved: [Refactor] Redis 캐시 적용하기 #263

💻 작업 내용

Hibernate: 
    select
        u1_0.user_id,
        ****
    from
        `user` u1_0 
    where
        u1_0.user_id=?
Hibernate: 
    select
        distinct o1_0.objective_id,
        ****
    from
        objective o1_0 
    join
        `user` u1_0 
            on u1_0.user_id=o1_0.user_id 
    where
        u1_0.user_id=? 
        and o1_0.is_closed=0 
    order by
        o1_0.idx
Hibernate: 
    select
        u1_0.user_id,
        ****
    from
        `user` u1_0 
    where
        u1_0.user_id=?

별 표시는 쿼리문을 간략히 줄이기 위해 다 지우고 쓴 것임을 먼저 알려드리겠습니다 ! 참고해서 봐주세요~

히스토리 조회 쿼리인데 user 정보를 항상 조회하는데에 오버헤드가 매우 크다고 생각했습니다. 또한 @loginuser 어노테이션에 userId를 주입해줄 때 DB에서 유저의 정보를 조회해서 user의 id를 주입해주는데 항상 매 api 요청마다 DB에 다녀오는 것은 성능상 좋지 않다고 판단하였습니다. 또한 특정 API에서는 user 조회를 2번하는 경우도 존재하여 캐시를 적용하기로 결정하였습니다.

근데 왜 Redis 였나?

저희는 유저의 refresh token의 저장소를 redis에 저장하여 사용하고 있습니다. 또한 redis에 대한 부하가 그렇게 크지 않다고 판단했고 추가적인 저장소나 캐싱을 위한 인프라 작업이 필요없을 것 같아 Redis를 적용하기로 했습니다. 또한 Redis를 적용했을 때의 성능도 괜찮다고 판단하여 적용하려 했습니다.

성능 비교

[User 데이터를 캐싱하지 않고 DB에 가져오면서 API를 처리할 때]

[Redis에 캐시하여 API를 처리할 때]

일단 10개의 쓰레드가 100번의 요청의 부하를 가했을 때 테스트 내용입니다. 평균 8배 이상 빠르다는 것을 볼 수 있고 99% 최악의 처리 시간을 고려하더라도 2배 가량 빠르다는 것을 볼 수 있었습니다.

📝 리뷰 노트

고민 사항은 User의 도메인 데이터를 그대로 Redis에 캐싱하는 것에 대해서 보안적으로 괜찮을까? 라는 제 스스로의 질문이 있었습니다. 이 부분에 대해선 일단 redis 자체에 접근할 수 있는 방법이 ec2 내부에서밖에 접근하지 못하기 때문에 보안적으로 문제 없을거라고 생각합니다만.. 보완점이 생기거나 추가 아이디어가 생긴다면 적용토록 하겠습니다!

또한 캐시 데이터의 TTL은 3600초(1시간)을 적용하였는데 access token의 유효 시간인 20분으로 적용해야 할 지, 더 늘려야 할지에 대한 고민을 했었는데 이 부분은 운영하면서 노하우를 쌓아서 추가 튜닝을 해보도록 하겠습니다~

[0lynny]

친절한 설명 감사합니다 ! 이런 부분에 대해서 생각해보지 못했었는데 많이 배워가는것 같아요 ~ 어푸룹.