목록사이드 프로젝트/온라인 쇼핑몰 ver.6 (4)
개발놀이터
기존 ver.2에서 Redis를 도입해 RDBMS의 부하를 30퍼센트 줄여 문제점을 개선하였습니다. 하지만 읽기 요청이 많아지면 Redis에 큰 무리가 가게 되고 Redis가 standalone 상태에서 다운되면 뒤에 있는 RDBMS도 다운될 가능성이 있습니다. 때문에 Redis의 고가용성을 유지하는 것이 새로운 과제가 되었고 이번 ver.6에서 Redis Sentinel을 이용해 문제를 해결하게 되었습니다. 왜 Sentinel이었나?Redis에 고가용성을 위한 옵션으로 Sentinel과 Cluster가 존재합니다. 둘 중 Sharding이 지원되는 Cluster가 상위호환이지만 Sentinel을 선택하게 되었습니다. Sentinel을 선택한 이유는 우선 첫번째로 프로젝트에 Sharding이 필요할..
백엔드에서 가장 난이도 있기로 소문난 특정 지점에 트래픽이 몰리는 상황을 대비하여 Redis를 이용해 대기열을 만들었습니다. https://coding-review.tistory.com/530 Redis로 대기열 구현하기이번 포스팅에선 Redis로 대기열을 구현한 것을 공유하려고 컴퓨터 앞에 앉았습니다. 이번에 주요한 기능은 WebSocket과 Redis의 Sorted Set 자료구조입니다. Sorted Set은 정렬 알고리즘의 시간 복잡도coding-review.tistory.com 제 프로젝트는 온라인 쇼핑몰인만큼 블랙프라이데이나 콜라보 이벤트를 하는 경우 트래픽이 몰리는 것을 대비하여 대기열을 만들었습니다. 이번 대기열을 이용해 애플리케이션 서버 부하와 RDBMS의 부하를 획기적으로 줄일 수..
기존 프로젝트에서 동시성 문제가 발생하였고 이를 JPA의 비관적 락으로 해결하였습니다. 하지만 비관적락이 RDBMS로 하여금 락킹 매커니즘을 관리하기위해 커넥션을 생성하고 이때문에 RDBMS에 부하가 발생한다는 문제가 발생했습니다. 해결방법으로 Redis의 라이브러리인 Redisson을 이용해 분산 락을 구현했습니다. 기존에 사용하던 Lettuce는 스핀락의 개념으로 Redis에 lock을 지속적으로 확인해야 하기 때문에 RDBMS의 부하가 그대로 Redis로 몰린다는 단점이 있었습니다. 때문에 Redisson을 사용하게 되었습니다. wrk2로 부하 테스트를 진행하였고 docker로 컨테이너를 모니터링 하여 테스트를 진행했습니다. 특징RDBMS는 MySQL을 사용하였습니다. 스레드는 8개, 동시 커..
사이드 프로젝트인 온라인 쇼핑몰에 Redis를 이용해 Client Side Caching을 적용했습니다. Redis 6에 추가된 RESP3 프로토콜을 사용했고 Redis Client인 Spring Boot에서 CacheFront 를 이용해 클라이언트 사이드 캐싱을 구현할 수 있었습니다. wrk2를 이용해 API 테스트를 진행했습니다. 스레드 개수 : 8개동시 연결 : 50개지속 시간 : 60초초당 요청 수 : 1000개 성능 개선동일한 기준에서 테스트를 진행했을 때 Redis를 순수하게 이용했을 때와 local caching을 이용했고, 이로인해 Latency는 평균 80% 최대 130% 개선하였고, throughput은 평균 4% 최대 250% 개선하였습니다. 이로 인해 얻은 것기존 프로젝트에서..