팀 프로젝트/market.normalization.project16 조회 성능 향상시키기(7) Semaphore에서 Mutex로 갈아타기 개요현재 단일 인스턴스 환경에서 비동기 쿼리 동시실행 제어를 Semaphore로 진행하고 있었다.근데 생각해보니까 하나만 허용할거면 Mutex가 더 나을 거 같아서 리팩토링 하게 되었다 Mutex vs Semaphore항목MutexSemaphore주 목적상호 배제 (Mutual Exclusion)리소스 수 제한된 접근 제어값0 또는 1 (이진락)0 이상 (카운터)오버헤드보통 더 적음보통 더 큼시스템 콜대부분 커널 공간 필요대부분 커널 공간 필요사용자 수1개 스레드만 소유 가능여러 스레드가 접근 가능 뮤텍스가 보통 더 가벼운데, 오직 하나의 스레드만 접근 허용하기 때문에 0 또는 1의 간단한 상태만 관리하면 되기 때문이다.커널 락 사용 방식이나 구현체에 따라 차이는 있지만, 카운트 관리가 필요 없는 뮤텍.. 2025. 4. 10. Transactional인데, 왜 Redis 로직에서 Connection을? 개요2025.04.04 - [팀 프로젝트/플러스 프로젝트] - Transactional-Readonly가 어플리케이션에 미치는 영향 Transactional-Readonly가 어플리케이션에 미치는 영향개요Hot Key를 관찰하려고 부하테스트를 하던 도중, 세션 자동 생성에 이어 이상한 점을 하나 더 발견했다.우선, 짧게 실험 결과를 요약하고 가면..1. 실험 목적:Hot Key가 Redis 또는 시스템에 어떤 영roqkfchqh.tistory.com지난번에 이어서... Transactional Readonly에 관한 글이다.Transactional readonly를 불필요한 상황에서 사용했을 때 쓸모없는 DB 커넥션이 생겨버려서 부하가 몰릴 경우 어플리케이션 전반의 latency가 증가하는 현상을 관측할.. 2025. 4. 6. Transactional-Readonly가 어플리케이션에 미치는 영향 개요Hot Key를 관찰하려고 부하테스트를 하던 도중, 세션 자동 생성에 이어 이상한 점을 하나 더 발견했다.우선, 짧게 실험 결과를 요약하고 가면..1. 실험 목적:Hot Key가 Redis 또는 시스템에 어떤 영향을 미치는지 확인2. 실험 조건:key: "popular:market:items"TTL: 무제한 - '인기 검색' 은 redis만 사용하도록 할 것이기 때문. 물론 fallback도 존재함.JMeter: 3000유저 / 1초 ramp / 1000 loopRedis: 단일 인스턴스, 로컬실험 도중 1-2번의 Key Update 진행하여, 시스템에 미치는 영향 확인사용한 툴: Prometheus, Grafana, Jmeter3. 결과 요약:Redis key rate(GET)초당 5000~6000.. 2025. 4. 4. Actuator가 자동으로 Session을 생성한다 개요Redis Hot Key Issue를 겪어보려고 Jmeter로 부하테스트를 돌리는 도중에 이슈가 발생했다.정확히는 Hot Key 부하테스트와 관련은 없지만, Redis Insight를 뒤적거리다 발견했다.어플리케이션을 켜놓고 가만히 놔뒀는데, 세션이 스스로 생성되었다..하나에 632B라 무시할만한 수준이라고 생각할 수도 있지만, 15초에 한번 Metrics를 수집하며 이것의 TTL이 30분이니까 서버가 지속될 때 최대 약 74KB * 인스턴스 개수 만큼 Redis에 쌓인다.그리고 어쨋든 버그기도 하고.. 거슬린다. 대체 왜 생긴걸까? 파악너무 예전에 만들었던 Session + Security 구조라 기억이 잘 안 나니까 우선 세션이 어디에서 생성되는지 로그를 찍어보자.@Slf4j@Componentp.. 2025. 4. 2. 조회 성능 향상시키기(5) Semaphore로 비동기 쿼리 동시 실행 제어하기 개요현재 로직에는 잠재적인 문제가 존재한다비동기 방식으로 캐시 갱신 쿼리를 실행할 경우, 최소 1초에 한 번 실행될 수 있다.하지만 일시적인 DB 부하로 인해 쿼리 실행 시간이 1초 이상 걸리는 상황이 발생한다면, 다음과 같은 문제가 생길 수 있다 1. 동일 작업이 중복 실행되어 jvm의 스레드 자원이 낭비된다.2. 캐시 갱신 타이밍이 겹치면서 race condition이 발생할 수 있다.3. 불필요한 느린 쿼리들이 중복 호출될 수 있다(현재 기준 동일 네트워크 상에서 평균 600ms로 빠른 편이 아니다) -> 결과적으로 어플리케이션, DB, Redis 모두에 영향을 끼칠 수 있다. Semaphore세마포어를 활용해 비동기 메서드 실행을 하나의 스레드로 제한하는 방식으로 문제를 해결할 수 있다고 판단했.. 2025. 3. 26. 조회 성능 향상시키기(4) 인기 품목 조회 최적화 개요인기 거래소, 경매장 조회를 어떻게 구성할지 고민이 된다.일반적인 캐시 방식으로 설계할 경우 설계에 따라 사용자가 보게 되는 수량이나 가격 정보가 실제 데이터와 달라질 수 있다.특히 인기품목은 거래가 활발히 이루어지기 때문에, 캐시를 사용하면 이미 품절된 상품이 인기품목으로 계속 노출되는 문제가 발생할 수 있다.그렇다고 DB에서 직접 조회하기에는 부담이 있다. 현재 기준으로도 거래소는 621ms, 경매장은 322ms로 성능이 썩 만족스럽진 않으며,실제 운영 환경에서는 삽입 및 수정 요청까지 동시에 발생할 가능성이 높아서 락 경합이 발생할 위험이 있다.이 문제를 어떻게 해결할 수 있을까? 고려 중인 전략1. 캐시 + 스케줄러 도입을 통한 성능 개선상대적으로 변동이 적은 인기 품목은 역시 캐시 스케줄러.. 2025. 3. 24. 조회 성능 향상시키기(3) Pagination Count Query 최적화 문제 상황현재 '전체 경매장 조회'는 커버링 인덱스로 개선하였음에도 불구하고 702ms로 1초 가까이 소모된다.로컬에서 네트워크 지연시간이 0ms인 걸 감안하면, 실제 서버에선 1초가 넘는다는 소리다 수많은 개선방법이 있겠지만, 나는 count query 최적화를 우선 진행하기로 했다.'전체 거래소 조회' 에도 같은 로직을 적용할 수 있기 때문이다. count query 최적화는 꽤 많은 방법을 적용해볼 수 있을 거 같다. 하나씩 적용해보고 장단점을 비교해보자. count query 개선 방법우선 대상 count query들은 이미 index를 꽤 잘 타고 있기 때문에 DB레벨에서의 최적화는 더이상 힘든 상황이다. 1. 마지막 페이지 근처에 도달하기 전까지는 count query 생략하기데이터가 100.. 2025. 3. 23. 조회 성능 향상시키기(2) 커버링 인덱스 with Querydsl 커버링 인덱스란?커버링 인덱스는 쿼리에서 필요로 하는 모든 컬럼을 포함하는 인덱스다.쿼리가 요청하는 모든 데이터가 인덱스 자체에 이미 포함되어 있어, 데이터베이스가 원본 테이블에 접근할 필요 없이 인덱스만으로 쿼리를 처리할 수 있다.MySQL에서 커버링 인덱스는 select절에 있는 모든 컬럼과 where, order by, group by절에서 사용되는 모든 컬럼이 인덱스에 포함되어야 한다.이 때문에 쓰기 작업에서 트레이드오프가 존재하지만, 일반적인 웹 서버에서 읽기:쓰기 비율이 9:1정도인 것을 감안하면 오프셋 기반 페이지네이션에서는 커버링 인덱스를 적극적으로 활용하는 편이 좋다고 생각한다. 또한 유지 보수도 조금 까다로운 편이다. select절이 바뀌면 인덱스를 재설정해주어야 한다.커버링 인덱스는 .. 2025. 3. 22. 조회 성능 향상시키기(1) PageableExecutionUtils? 2025.02.06 - [팀 프로젝트/플러스 프로젝트] - 조회 성능 개선 작업 정리본최종 플젝 때 건 아니지만.. 예전에 완전한 조회속도 개선에 실패하고 후일을 도모했던 쿼리를 이제 진짜로 향상시켜보자우선 커서기반은 제쳐두고, 오프셋 기반 페이지네이션으로 튜닝에 도전해보자 PageableExecutionUtils - fetchCount과거의 내가 써놓은 코드를 보는데pageable을 이런식으로 리턴했다. 이당시엔 fetch로 불러오니 당연히 빠르겠지! 하고 사용한 것 같은데.. 해당 방식 대로 하니 8.51초가 나왔고,Fetchable#fetchCount() was computed in memory! See the Javadoc for AbstractJPAQuery#fetchCount for more.. 2025. 3. 21. 플러스 프로젝트 KPT 회고 KEEP🥇 소통서로 코드를 확인하며 로직 면에서 아쉬운 부분을 피드백하면 피드백 받은 사람이 적극 수용하고, 의견이 다를 때에는 같이 얘기하면서 조율한 점아이스 브레이킹, 팀원끼리 어색한 시간이 매우 짧아서 바로 활발할 의사소통을 하면서 프로젝트에 돌입할 수 있던 점발표자한테 모든 걸 맡기지 않고 다같이 리허설을 하면서 피드백도 하고 같이 발표 자료도 검토한 점의사소통이 잘 되어서 프로젝트 완성도에 오롯이 집중할 수 있던 점팀원이 힘들 때마다 서로 서로 격려와 응원의 말을 자주 해준 점🥈 기록5분 기록 보드 등등을 활용하여 고민과 규칙과 계획을 꼼꼼하게 기록한 점기술을 하나 사용할 때나 기술적 의사결정을 할 때마다 꼭 근거를 덧붙인 점🥉 협업jira, pull request template을 사용하.. 2025. 2. 7. 이전 1 2 다음
