[팀 프로젝트-쇼핑몰]성능 최적화 및 마무리
이번 프로젝트에선 API 명세 및 CRUD 구현을 집중적으로 다루기 보다 성능최적화를 핵심 목표로 잡았다.
협업보다는 각자의 도메인에 적용할 수 있는 성능 최적화를 다루었고 내가 다룬건 제품도메인의 제품조회 성능 향상이다.
✅ Redis 를 이용한 제품 조회 성능 향상
📌기존 코드
- 100명의 이용자가 하나의 제품을 조회하면 DB에 select 와 update 쿼리문 100번씩 발생했다.
- 엔티티를 꺼내서 조회수를 1 증가가 후 -> 다시 Save() 호출
📌개선 코드
- 반복적인 읽기가 많은 호출에 적합한 Look Aside 패턴을 적용하였다.(추후에 캐시 적용 패턴 정리하기)
💡 Look Aside란?
- Look Aside 는 간단하게 클라이언트가 서버에 데이터를 요청할 시, 캐시를 먼저 조회하고 있다면, 데이터를 바로 꺼내오고 없다면 DB 에서 데이터를 조회. 그다음 조회해온 데이터를 캐시에 업데이트를 시킨다.
- 결과적으로 자주 조회되는 데이터는 캐싱 적용을 통해 DB 를 거치지 않고 가져올 수 있다 -> 성능 개선
하지만 , 여기에도 단점이 존재한다.
💡 Look Aside 단점 및 보완 방법
1️⃣ 캐시 미스로 인한 지연
-> 전날 자주 조회된 데이터에 대해 미리 로드하여 캐시 히트율 증가
-> 쓰기 작업이 발생할 때마다 캐시도 즉시 갱신(Write-Through) 캐시 전략 고려
2️⃣ 데이터 일관성 문제
-> WebSocket,서버 센트 이벤트 기술 도입으로 데이터베이스와 캐시동기화
3️⃣ 조회수 동시성 문제
-> 분산 락(Distributed Lock) 적용
단점도 존재하지만 또다른 의문점이 생겼다.
Q. 대규모 어플에서는 수많은 데이터가 조회될텐데 캐시에 과부화가 오는 거 아닌가?
맞다.만약에 캐싱에도 제한점 및 조건을 두지 않으면 DB 처럼 과부화가 올 수 있다.
그럴때 해결할 수 있는 방법으로 두가지를 적용해보았다.
💡 캐싱 한계점 보안
1️⃣ 캐시 TTL설정 (1분간 유지)
Duration.ofMinutes(1)
- 해당 코드를 통해 1분뒤에는 캐시에 있는 데이터가 자동 삭제가 된다.
2️⃣ Scheduled (Spring 기본 어노테이션)
@Scheduled(cron = "0 0 0 * * ?")
- 자정마다 캐시를 초기화해서 불필요한 캐시가 쌓이는걸 방지한다.
결과적으로 캐시 적용을 통해 1000번의 조회를 진행했을때 기존코드보다 약 10 배 이상의 속도가 차이났다.
프로젝트에 대한 발표도 해보았으니 보고싶은분은 1시간 56분 쯤부터 시청하시면됩니다!
비디오 회의, 웹 회의, 웨비나, 화면 공유
Zoom은 모바일, 데스크톱 및 회의실 시스템에서 비디오 및 오디오 회의, 채팅 및 웨비나를 안전하고 편리하게 진행할 수 있는 클라우드 플랫폼을 제공하여 첨단 엔터프라이즈 비디오 통신을 선도
zoom.us
프로젝트를 마무리 하며 피드백을 정리해보자면 다음과 같다.
- 사용자가 좀 더 사용하지 않는 시간(가장 없는 시간)에 캐시 클리어 하는 것도 하나의 방법
- 캐시 어노테이션 ⇒ 동일한 작업을 하는 함수, 메서드를 만드는 것도 좋음
- 직렬화, 역직렬화도 만드는 게 좋을 수 있음(JPA 등 확정성 고려하기)
- 일단 돌아가게 만듬 ⇒ 리팩토링 하는게 개발
- 기획의도에 들어가지 않는다면 개발자 중심으로 설계 후 → 사용자 UI 피드백 까지 반영
이상 플러스 주차 프로젝트를 마무리 하겠습니다!
읽어주셔서 감사합니다.
