🧠 이번 주에 새로 배운 것
- 캐시를 적용해보고, 부하 테스트를 통해 실제 얼만큼 성능이 향상되었는지 확인할 수 있었다.
- 실행계획을 통해 확인하고, 이를 기반으로 쿼리를 고쳐나갈 수 있었다.
- K6를 통해 부하 테스트를 수행할 수 있었다.
- 카디널리티에 따라 인덱스가 효과적으로 작용할 수 있는지 고려해야 함을 알 수 있었다.
- 조회 요청의 단일 응답 시간이 느려야만 캐시를 거는 것이 아니다.
- 빠른 조회 연산이라도 실제 요청이 너무 많으면, DB에 불필요하게 닿지 않고 커넥션을 점유하지 않도록 캐시를 도입할 수 있다.
💭 이런 고민이 있었어요
- 캐시 자체를 코드에 적용하는 것보다, 각각 어떠한 전략으로 가져갈지 고민하게 되었다.
- 상품 상세 조회에서 캐시를 가져야하는 이유를 크게 느끼지 못했다.
- 상품 상세 조회는 상품 ID를 알고 있기에, 이를 이용한 여러 조회는 빠르게 일어날 것이라고 생각
- 캐시를 사용한다는 것을 어느 계층에서 나타내야 할까?
- 유니크 인덱스는 유니크한 상황이라면 무조건 다 걸어야 할까?
💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트
- 부하 테스트를 통해, 서버가 버틸 수 있는 요청량을 확인해보자.
- 단일 조회 연산의 응답시간이 느리거나, 단일 조회 연산이 빠르더라도 요청량 자체가 너무 많다면 캐시를 고려해보자.
- 조회 쿼리에 대해 인덱스가 적절히 걸려있는지 전체적으로 확인해보자.
- 모든 필터링 케이스에 인덱스를 건다기보다, 모수를 최소화할 수 있는 방향으로 적용하자.
🤔 아쉬웠던 점 & 다음 주에 해보고 싶은 것
- Redis를 통해 좋아요 연산 과정 개선해보기
- 상품 목록 조회의 앞부분 페이지 캐싱
- 상품 목록 조회에서 뒷 페이지의 요청이 느린 상황 개선하기
- 커서 기반 페이지네이션, 역순 인덱스 + OFFSET 고려해보기
- MaterializedView가 정확히 무엇인지, 어떠한 부분을 개선할 수 있는지 스스로 정리해보기
- Real MySQL을 읽은 경험은 있지만, 시간이 지나 여러 정보들이 휘발되어, 인덱스를 적용하는 과정에서 다시 찾아보게 되었다.