서론
현재 저희 프로젝트에서는 JWT 토큰을 통해 인증을 진행하고 있습니다. 이 과정에서 권한(role) 체크가 필요한데, 현재는 데이터베이스(DB)를 직접 조회하여 권한을 확인하고 있습니다.
모든 요청이 필터를 통해 처리되기 때문에, 지속적인 DB 조회는 성능 저하를 초래할 수 있습니다.
따라서 DB를 직접 조회하여 권한을 확인하는 대신, 사용자 정보를 인메모리 저장소인 Redis에 캐시하여 권한 체크를 빠르게 권한 체크를 수행할 수 있도록 구성하고자 합니다.
[Redis] 인메모리 저장소와 redis란 무엇일까❓
전통적으로 데이터는 관계형 데이터베이스(RDBMS) 시스템, 예를 들어 MySQL, MariaDB, Oracle과 같은 플랫폼을 통해 관리되었습니다. 이러한 데이터베이스는 파일 시스템(HDD, SSD 등)에 데이터를 저장하
pixx.tistory.com
매번 DB에서 사용자 정보를 조회하는 대신, Redis에서 캐싱된 데이터를 조회함으로써 DB에 대한 직접적인 접근을 줄일 수 있으며, Redis는 인메모리 데이터 저장소로, DB를 직접 조회하는 것보다 훨씬 빠릅니다.
이를 통해 JWT 토큰 인증 시 사용자 정보를 가져오는 과정에서의 응답 시간이 크게 단축됩니다.
Redis 캐시 적용하기
1. CacheConfig 설정
CacheConfig 클래스는 Redis를 캐시 저장소로 구성하는 설정 클래스로, @Configuration과 @EnableCaching 어노테이션을 사용하여 캐시 기능을 활성화합니다.
2. Service에서 캐시 적용
모든 요청은 필터를 통해 처리되며, 이 과정에서 loadUserByUsername 메서드를 사용하여 DB를 직접 조회합니다. 따라서 이 메서드에 캐시를 적용하여 성능을 개선하였습니다.
설정한 캐시는 @Cacheable 어노테이션을 사용하여 지정해주며, value와 key 값을 설정하였습니다.
이렇게 설정하면 Redis에는 users:: 접두사가 붙은 캐시가 생성되며, 값은 loadUserByUsername 메서드의 반환 값인 UserDetails가 저장됩니다.
처음 loadUserByUsername 메서드가 호출될 때 캐시가 저장되고, 이후에는 캐시에 저장된 값을 조회하여 성능을 향상시킬 수 있습니다.
위 결과에서 확인할 수 있듯이, 처음 loadUserByUsername 메서드가 호출될 때 캐시가 저장됩니다. 이후에는 loadUserByUsername 메서드를 호출하지 않고, 데이터베이스 조회 없이 캐시에서 직접 데이터를 가져오는 것을 로그를 통해 확인할 수 있습니다.
권한 수정시 Redis 캐시 삭제
사용자 권한이 변경될 경우 Redis에 저장된 캐시를 즉시 삭제(evit)하고, DB를 읽을 수 있도록 구성하였습니다.
권한을 수정 하는 api를 호출하고 로그를 보면 위와 같이 로그가 찍혔고, Redis를 확인해보면 1시간으로 설정하여 원래 남아있어야 할 캐시 데이터가 삭제된 것을 확인할 수 있었습니다.
'TIL,일일 회고' 카테고리의 다른 글
[TIL, 일일 회고] 2024.09.04 - Spring 심화 AI 비즈니스 검증 프로젝트 트러블 슈팅 (0) | 2024.09.04 |
---|---|
[TIL, 일일 회고] 2024.09.03 - Pageable로 페이징 및 정렬 간소화하기 (0) | 2024.09.03 |
[TIL, 일일 회고] 2024.09.01 - Java 12+의 switch 표현식으로 코드 간결성 높이기 (0) | 2024.09.01 |
[TIL, 일일 회고] 2024.08.31 - @MappedSuperclass 적용하기 (0) | 2024.08.31 |
[Til, 일일 회고] 2024.08.30 - @MappedSuperclass란 무엇일까❓ (0) | 2024.08.30 |