Trouble Shooting
-
도입배경
- 상품목록조회는 주문 전 필수적으로 처리되는 API로 조회 성능을 확보하는 것이 중요
- 현재 DB에서 불러오는 로직으로 측정시 목표로 했던 처리량 200.0/sec 의 미만의 154/sec 정도로 나오고 있어서 개선이 필요
-
기술적 의사결정 과정
- 조회는 DB I/O에서 시간이 소요되니 DB보다 빠른 별개의 저장소에서 검색을 처리해야겠다고 생각함
- Elastic Search는 실시간 데이터 인덱싱을 지원해 빠른 조회가 가능하고 분산 아키텍처를 기반으로 높은 트래픽을 처리할 수 있다는 장점이 있음
- 추후에 ELK 스택기반으로 모니터링 시스템을 구축할 수 있다는 확장성 면에서 선택
- 원본 저장소인 카산드라는 그대로 저장을 하면서 검색, 필터링, 정렬 조건에 해당하는 정보들은 따로 Elastic Search 저장소에 저장을 하는 방향으로 아키텍처를 변경하여 개발
상품 상세조회 시엔 원본 저장소인 카산드라에서 전체 정보를 읽어옴
상품 목록 조회시엔 Elastic Search에서 상품목록에 필요한 정보들만 읽어옴
-
개선한 방법
- 상품 목록 조회가 처리해야하는 다양한 필터링, 정렬 조건들
- 필터링: 상품 카테고리, 브랜드이름, 상품 사이즈, 메인컬러, 태그
- 정렬: 신상순/판매순/리뷰순/가격높은순/가격낮은순
- 최소가격, 최대가격 값으로 가격 범위검색
- 위의 조건들로 상세한 쿼리 작성을 위해 ElasticSearchRepository를 사용하지 않고 Query methods을 사용하여 Custom Search 쿼리를 구현
- 조회 결과는 페이징 처리 후 반환하여 서버와 클라이언트의 부하를 줄임
- 상품 목록 조회가 처리해야하는 다양한 필터링, 정렬 조건들
-
결과
- Elastic Search 도입으로 상품목록조회 API의 처리량을 기존보다 약 114.3% 증가
- 테스트는 Jmater를 사용해서 스레드 수 100, Ramp-up 시간 1, 루프 카운트 10 으로 진행
- 일반 Cassandra Repository로 ALLOW FILTERING을 허용하여 테스트
-
도입배경
- 대규모 트래픽 환경에서 쿠폰 발급 시 쿠폰 수량이 공유자원이므로 동시성 이슈가 발생
- 동시성 이슈를 해결하기 위해 비관적 락을 적용하여 해결하였지만 DB에 락을 걸다보니 분산 서버 환경을 구성하는 의미가 없어짐. > 분산 서버 환경에 맞지 않는다고 판단
- 또한, 비관적 락의 경우, DB에 락을 걸기에 동시 요청이 많은 상황에서 처리량이 10 - 60/sec정도의 낮은 처리량을 보여 개선이 필요
-
기술적 의사결정
- kafka를 선택한 이유는 기술적 의사결정 부분에 작성
- 분산락을 사용하기에 적합한 기술을 찾아보니 Redis를 이용한 라이브러리 중 Lettuce와 Redisson 존재. 두 개를 비교
- 시간이 없는 상황에서 분산락 기능이 필요하였고 Lettuce는 분산락 기능을 직접 구현해야하는 반면 Redisson은 제공되는 기능이 있었음
- Redisson이 라이브러리는 크기는 상대적으로 컸으나 분산락 기능과 개발 시간을 줄일 필요가 있었기에 Redisson을 선택
-
개선방법
- 쿠폰 발급 로직에서 분산 락만을 적용했을 때, 대규모 트래픽 상황에서 일부 요청이 락 획득에 실패하여 정상적으로 처리되지 않는 문제가 발생 > 해결하기 위해 쿠폰 발급 요청을 Kafka를 이용한 비동기 처리 방식으로 변경
- Kafka 적용 후 락 흭득 문제 해결 및 처리량 증가
-
결과
테스트 환경 - 쿠폰 1000개 발급 요청(100명의 사용자가 10번씩 요청)
기존
개선 후
분산락과 Kafka 도입 후 쿠폰 발급 API에 많은 요청이 발생해도 동시성 이슈가 발생하지 않으며 처리량이 50/sec > 222/sec 으로 약 344% 이상 향상