[WIL] week 11

Fact

이번 프로젝트 담당 업무

• 물품 및 Rating API, 캐싱, 스케줄링

 

주요 내용

 

유저 간 등록한 물품을 교환 또는 경매에 등록하여 입찰할 수 있는 서비스

• 물품교환: 상대방이 등록한 물건을 선택 후, 내 물건을 선택하여 거래요청을 하는 서비스
• 레이팅: 물품 등록 시 자신의 물건 값어치를 작성하여 다른 유저들이 해당 물품의 가격을 맞추는 유사 게임 시스템        해당 서비스를 통해 경매 하한가를 설정 물품 등록 시 설정한 값어치는 게임의 정답 용도로만 사용 물건 평가가          3개일 시, 평가 받은 평균가가 물건의 가격으로 설정
• 경매: 경매 기간 만료 시, 입찰받은 물건 중 마음에 드는 물품을 골라 거래하는 서비스 등록하는 유저가 경매기간을    설정할 수 있음. 레이팅 평가가 끝나지 않은 상품은 등록 및 입찰을 할 수 없음 경매에 등록한 유저는 하한가를 설정할 수 있으며 레이팅 평가로 이루어진 값이 기준이 됨
• 가격 업데이트: Rating 시스템은 하한가 설정 뿐 아니라 게임성 목적도 가지기에 평가가 완료된 상품도 추가적인 평가를 받을 수 있음.
  • 추가적인 평가로 인한 변경된 가격은 데이터 신선도를 위해 가격 업데이트를 진행
  • 유저 수가 적은 시간대인 새벽 시간대에 업데이트 될 수 있도록 스케줄링을 사용
  • 경매에 참여중인 물품들은 가격 변경이 일어나지 않음

 

개선내용

 

1. Redis를 사용해 캐싱하여 전체물품 조회 시 최대 953ms였던 응답속도를 11ms까지 단축

2. RAND() 함수를 사용하여 동시성 문제를 완화하고, 여러 유저에게 다른 물품을 보여주어 UX 를 향상시킴 QueryDSL은 RAND() 함수를 지원하지 않아 nativeQuery를 사용하여 작성
3. 동시성 발생 빈도를 줄인 후, 동시성 제어를 위해 낙관적 락을 사용하여 데이터 무결성과 안정성을 확보
4. 레이팅을 가장 많이 진행한 5명을 반환 및 이미 평가한 상품에 대해 중복 평가를 방지하는 등 복잡한 쿼리 작업 수행 시, QueryDSL을 활용하여 JPA의 단순 조회와 비교하여 더욱 효율적 인 데이터베이스 조회를 구현

 

 

 

---

 

Feeling

1. 캐싱을 처음 사용해 보았으나 속도가 말도 안되게 빨라져서 감탄했다.

2. 어떻게 동시성을 줄일것이며, 동시성이 줄었다면 어떤 동시성 제어 기법을 사용할 것인지 생각해야 했기에 힘들었다.

3. RAND() 함수는 QueryDSL로 작성할 수 없었기에 하루종일 고민을 했었다. nativeQuery를 알게 되었을 땐 너무 기뻤다.

4. 프로젝트 진행 간 처음 작성했던 코드보다 더욱 효율적으로 작성할 수 있는 부분들이 계속 떠올라서 리팩토링에 많은 시간을 할애하게 되었다. 가독성과 응답속도가 빨리지는게 눈에 보여서 재미있었다.

 

---

 

Finding: 알게된 것

1. Redis를 사용하여 캐싱하여 서버의 부하를 줄이는 방법

2. nativeQuery를 사용하여 쿼리를 직접 직접 조작하는 방법
3. 낙관적 락을 사용하여 데이터 무결성과 안정성을 확보하는 방법
4. QueryDSL을 활용하여 복잡한 쿼리를 가독성 좋게 작성하는 방법

---

 

Future: 알게된 것을 어떻게 활용할 것인가

1. 유저들의 방문이 가장 많은 페이지를 캐싱하여 서버로부터 발생하는 부하를 줄일 것이다.

2. QueryDSL과 JPA에서 지원하지 않는 함수가 존재할 시, JPA의 nativeQuery를 사용하여 구현할 것이다.

3. 상황에 따라 낙관적 락, 비관적 락을 구분하여 사용할 것이다.

4. 복잡한 쿼리문 작성이 필요할 때 QueryDSL을 사용하여 작성할 것이다.