[spring] redis로 caching해서 dbms의 부하 줄이기 - 3

한참 관련 로직을 작성하던 중 클래스를 잘못 설계한 벽에 부딪히고 말았다.

그리고 토요일 kt 기지국 화재로....모든 의욕을 잃었다.

백엔드 프로그래밍에서는 계층마다 dto를 둔다. 

db에서 데이터를 읽고 쓸때는 entity class를 사용한다.

클라이언트와 통신할 때는 entity class를 그대로 노출할 수 없으니 request의 parameter와 response와 mapping해주는 dto를 둔다.

그리고 현재 redis를 사용할 경우에는 dto를 하나 더 사용하는 경우가 생길 수 있다.

그런데 맨 처음 rdbms를 사용할 때는 redis를 고려하지 않고 dto를 하나만 두고 service 객체에서 하나의 dto 타입만을 반환해줘서 문제가 생겼다.

위와 같이 클라이언트에 보내줄 데이터타입으로 전환하는 것은 controller에서 해준다.

service 객체에서도 redis용 entity를 받아서 그대로 컨트롤러에 돌려주도록 수정했다.

dto에 대한 타입문제는 해결했다. dto가 중복되는 문제가 있어서 문제가 있긴하지만 그것은 다음글에서 수정해도록 하자.

이제 실제 구현을 살펴보도록 하자.

기능에 대해서는 테스트 코드로 테스트했으니 service 객체로 구현해보자.

구현한 기능은 위와 같다.

그리고 위 객체에 의존하는 컨트롤러의 코드는 아래와 같다.

본래는 spring data jpa에서 기본적으로 Page<> 객체를 반환해줘서 간편하게 사용했는데.

redis에서 데이터를 불러오므로 그런 구조는 사용 불가해졌고 그래서 찾아본 결과 List를 Page로 간단하게 생성할 수 있었다.

대신 인자에 전체 list의 size를 넣어줘야한다.

컨트롤러 작성도 완료했으니 실제 잘 돌아가는지 확인해보자.

API를 사용하기 간단한 웹앱을 만든게 있다.(vue.js 학습겸 겸사겸사)

quasar framework라고 vue.js 기반으로 mobile ui를 제공해주는 프레임워크다.

우선 앱의 메인화면이다. 작업했으나 포스팅하지 않은 사용자가 최근 조회한 이벤트를 볼 수 있는(향후 사용자의 정보를 바탕으로 추천하는 컨텐츠를 노출해줄) 메인 화면이다.

이제 검색버튼을 누르면 컨텐츠들을 불러 올 것이다.

기본 검색 조건은 이번달의 모든 지역의 모든 종류의 컨텐츠이다.

아직 어떤 컨텐츠도 레디스에 저장되지 않았다.

이제 검색버튼을 눌러서 컨텐츠들을 조회해보자.

위와 같이 조회한 데이터를 db에서 받아서 레디스에 저장하고 페이징하고 있는 것을 확인할 수 있다.

페이징할 때 하나의 페이지의 갯수는 10개이다.

다른 조건으로도 한번 검색해보자.

테스트하던 중 문제점 하나 발견했다.

기본검색 조건에 대해서는 페이징처리가 빠른데.

30개 정도 되는 검색조건에 대해서는 페이징 처리 속도가 느리다.

일단 확실한 문제점은 스크롤을 할 때 서버에 request 보내는 타이밍이 너무 타이트하다.

스크롤이 거의 화면 끝에 가야지 서버에 요청을 보낸다..

그리고 레디스에서 list 자료형을 이용할 때 list의 사이즈가 30이하일 때 성능상 문제가 있는지도 확인해봐야겠다.

항상 redis나 mongodb같은 nosql에 관심은 많았는데.

이번 기회에 레디스의 기본적인 사용법이나마 익힐 수 있어서 너무 좋았다.

그리고 블로그에 글을 올리고 과감하게 페북에 공유하면서..스스로 오류가 없었는지 찾아보고..rdb의 풀테이블 스캔이나 레인지 인덱스 스캔, 그리고 redis의 hash table과 quick list, ziplist등의 내용을 찾아보면서 잊고 있던 내용도 다시 한번 복습할 수 있어서 좋았다.

이번에 정말 레디스의 기본적인 사용법만 익혀봤다.

더 깊이 들어가자면 master - slave 구조나 레디스 센티넬 같은 것도 더 찾아봐야하지만 이번 사이클에서는 여기까지 하기로 한다.

향후 개선점을 찾아서 블로그에 글을 또 올릴 수 있기를 빈다.