[MSA 경험기] 모아 구독 (2) 페이지 네이션, 캐싱을 적용한 상품 조회

지난 글

이전 글 에서는 MSA 프로젝트를 시작한 계기와 프로젝트 기획 및 설계에 대해 작성했었다.

https://yubi5050.tistory.com/218

[MSA 경험기] 모아 구독 (1) 프로젝트 기획 및 설계

 

이번 글 에서는 '조회 서비스 - 구독 상품 조회'를 구현하면서 고민하였던 부분, 관련하여 사용한 기술들을 중심으로 이야기 해보려고 한다.

 

주제는 크게 아래 두가지 이다.

• 다수의 구독 상품 목록 조회시 Pagination 적용
• 고정적으로 Reponse되는 항목에 대한 부분 Caching 적용

 

구독 상품 목록 Pagination 구현

일전에 Django에서 쓸수 있는 Pagination에 대해 조사해서 정리했던 적이 있었고, 이번에 개발하는 서비스에 적합한 Pagination 방법이 무엇인지 고민을 하게 되었다.

https://yubi5050.tistory.com/214

[Django] Pagination 방법 비교 (Feat. Django, DRF)

 

📌 고민 1) Django Pagination vs DRF Pagination

DRF Pagination : 기본적으로 Response에 편의성이 더 좋음 (count, prev url, next url 등 자동반환)
Django Pagination : 제공되는 모듈들이 Django-template(SSR 방식)에 좀더 적합하다고 판단

 

📌 고민 2) DRF의 어떤 Paginator를 선택 할 것인가? 

DRF Paginaton 방법에는 아래 3가지가 있고, 최종 Cursor 기반의 Pagination을 선택하게 되었다.

• PageNumbering 방식
• LimitOffset 방식
• Cursor 방식

 

선택 한 근거는 크게 두 가지 였는데,

1. '모아구독' 서비스는 판매자가 많아질 시 중간에 신규 구독 상품이 추가(Create), 변경(Update)될 여지가 많은 서비스였다. 따라서 중간에 Writing이 많이 발생하는 경우 id 기반으로 다음 데이터를 가져오는 Cursor Pagination 방식이 더 안전

2. '모아구독' 서비스는 구독 상품 리스트 조회시 Pagination Navigator 보다 Drag액션 기반의 무한 스크롤 방식이 사용자의 UX에 더 적합하다고 생각하였고, 따라서 특정 offset이나 limit을 조정할 필요가 없었음. 단지 고정된 Page Size에 해당되는 데이터만 계속 전달 되면 됨

 

 

카테고리 목록 Caching 적용

'모아 구독' 서비스에는 사용자에게 고정적으로 응답되는 부분(=카테고리 목록)이 존재, 이 부분을 캐시로 대응하면 좀 더 좋겠다라는 생각이 들었었다. 캐시는 데이터를 메모리에 저장해 놓기 때문에 DB 디스크 에서 읽는 것 보다 훨씬 더 빠르게 응답 가능 하다는 장점이 있다.

 

Django에서 캐시 사용시 선택 가능한 방법에는 아래 두가지 존재

• Redis Cache
• Memcached

 

일전에 정리한 내용을 바탕으로 '모아 구독' 서비스에 더 적절한 캐시는 무엇일지 고민 해보았다.

https://yubi5050.tistory.com/219

[Cache] Memcached vs Redis 차이

 

📌 고민 1) Memcached vs Redis 선택

최종 선택한 건 Redis를 활용한 Caching 방법이였고, 근거는 크게 두가지 였다.

1. memcached를 사용하기 위한 추가적인 설치와 소켓 연결 등의 절차가 필요했고, memcached를 사용하는 목적 중 여러 서버에서 공유하기 위한 목적이 있는데, 모아구독 서비스에서는 우선 단일 EC2에서 어플리케이션만 분리하여 진행했기에, 활용도가 조금 떨어진다고 생각했다.

2. Redis는 더 다양한 Data Structure(List, Set 등)을 지원하였고, 모아구독에서 다른 서비스에서 List나 set 형태의 데이터 형태를 캐싱할 소요가 있었기 때문에 Redis를 선택하게 되었다.

 

📌 Caching 전 후 속도 비교 (Postman)

캐싱 전 후 의 속도를 비교해보면 7.51KB의 데이터를 전송하는데 360ms 에서 91ms 까지 속도가 감소한 것을 확인 할 수 있었다. 

 

 

📌 Query Profiling Tool을 활용한 Caching 적용 확인 

Django의 Profiling Tool인 Django Debug Toolbar를 활용하여 Caching 여부를 확인해보면 

 

👉 (캐싱 전) 최초 실행시 아래와 같이 Category 조회 시간만 44ms 가 잡히는 걸 확인 할 수 있다.

 

 

 

👉 (캐싱 후) 이후 재실행하면 아래와 같이 Category 조회 시간이 22ms 가 잡히는 걸 확인 할 수 있고 Cache hits 와 Backend의 django_redis.cache object가 활용된 걸 알 수 있다.

 

.