TL;DR좋아요순 정렬은 ORDER BY COUNT(likes) 집계라, 매 요청마다 좋아요 297만 건을 조인·집계·정렬한다 → 7.3초.인덱스로 풀스캔·해시조인은 잡아 14배 빨라졌지만(0.45초), 집계값 정렬(Using temporary; filesort)은 인덱스로 못 없앤다.like_count 컬럼으로 비정규화해 집계 자체를 없애고 정렬 인덱스를 붙이면 0.13ms. 대신 "어떻게 동기화·정합성을 유지하나"라는 새로운 문제가 생긴다.상품과 상품 좋아요는 테이블 정규화로 분리되어 있다. 상품 목록에 "좋아요 순" 정렬을 붙이고, 시드 데이터를 넣어 실제로 호출해봤다. 데이터는 상품 10만, 좋아요 약 297만, 재고 10만, 브랜드 50 규모다.일반 목록 조회는 1초쯤 나왔는데, 좋아요 순으로 ..

이커머스 시스템을 개발하면서 상품 재고에 대한 동시성 처리에 대한 부분이 고민이 되었다.현재 Product와 ProductStock이 분리되어 있는 구조로 Product는 상품에 대한 메타 데이터를 관리하고 ProductStock은 ProductId를 가지며, Product에 대한 재고를 가지고 있다. 재고에 대한 동시성처리를 위해서 주로 많이 사용하는 3가지 케이스에 대해서 테스트를 진행했고, 테스트 결과는 어느정도 예상은 했지만 아래와 같았다.============= (threads=8, 요청량=8000, 재고=6000 → 품절 2000건) =============A) 비관적 락 : 전체 14,599 ms | 410 ops/s | 지연(avg) 14.595 ms | 락대기 누적 98,68..

TL;DR테스트 더블(Test Double)은 특정한 프레임워크나 도구에 종속된 기술이 아니라,"외부 의존성으로 인해 테스트가 어려운 상황을 해결하기 위해 진짜 객체 대신 사용하는 모든 대체재" 다.Java에서 테스트코드 작성시 Mockito를 주로 사용하는데, 대부분의 테스트 더블을 mock() 기반으로 표현할 수 있다.문제는 같은 mock() 객체라도 어떤 테스트는 반환값 제어에 집중하고,어떤 테스트는 호출 여부 검증에 집중하며, 어떤 테스트는 둘 다 사용한다는 점이다.하지만 코드만 봐서는 그 mock 객체가 어떤 의도의 테스트 더블인지 드러나지 않는 경우가 많다.들어가며회원 도메인을 개발하면서 UserService 단위 테스트 코드를 작성하던 중 UserRepository를 mock()으로 만들어 ..

서킷브레이커를 도입하고 나서 슬라이딩 윈도우 타입에 대한 설정값들이 헷갈렸다.COUNT_BASED의 경우 사실 직관적이지만 TIME_BASED의 경우 딱 와닿지 않는 것 같다.Resilience4j를 기준으로 두 가지 윈도우 타입의 내부 동작 원리를 자세히 살펴보고, 어떤 상황에서 무엇을 골라야 하는지 정리해보려고 한다.슬라이딩 윈도우란?서킷브레이커는 세 가지 상태를 가진다.CLOSED: 정상 상태 (모든 요청이 통과한다.)OPEN: 차단 상태 (요청을 즉시 실패시킨다.)HALF_OPEN: 시험 상태 (일부 요청만 허용해서 회복 여부를 판단한다.)이때 CLOSED 상태에서 OPEN으로 전환할지를 결정하는 핵심 매커니즘이 바로 슬라이딩 윈도우다.윈도우는 두 가지 일을 한다.기록: 매 호출의 결과(성공/실패..

Ceph 클러스터 장애가 발생했을 때,BE가 계속 retry를 하면서 오히려 응답이 더 느려지고 있었습니다. 배경현재 Ceph API를 활용해서 Ceph 데이터를 서빙하는 백엔드를 개발하고 있습니다.FE → G/W → BE → Ceph MGR API (Active-Standby 구조)서비스 흐름 자체는 단순한데, Ceph의 Active-Standby 구조 때문에303 Redirect, Fallback, Retry, Active MGR 갱신 같은 걸 전부 BE에서 직접 처리하고 있었습니다.평소에는 별 문제 없이 돌아갔는데, Ceph 장애 상황에서는 다음과 같은 문제가 발생했습니다.평균 응답 시간이 1.15초까지 증가redirect → retry → host 순회 → 재귀 호출 구조장애 원인 파악이 어려움(..

RBD 이미지 -> PG -> OSD 매핑Ceph 클러스터를 운영하다 보면 장애 분석이나 성능·용량 이슈가 생겼을 때,“지금 보고 있는 RBD 이미지가 실제로 어떤 PG에 올라가 있고, 그 PG가 어떤 OSD 들에 퍼져 있는지”를 알고 싶은 순간이 생겼습니다. 예를 들어,1. 특정 OSD 장애가 발생했을 때, 그 OSD에 어떤 이미지가 얼마나 몰려 있는지 보고 싶거나2. 리밸런싱 이후 데이터가 의도대로 고르게 분산됐는지 확인하고 싶은경우 "Ceph 내부에서는 객체 이름과 풀 ID로 해시해서 PG를 계산하고 이 PG를 다시 CRUSH로 여러 OSD에 배치를 하게 됩니다."그래서 저는 go-cpeh(librados를 go 언어로 래핑한 오픈소스)를 사용하여 RBD 이미지 -> PG -> OSD 매핑 API ..

2024.07.27 - [CS] - 소스코드파일부터 실행파일까지 컴파일러 과정 알아보기 소스코드파일부터 실행파일까지 컴파일러 과정 알아보기여러분들은 개발을 진행하면서 단순히 소스코드를 작성하게 되고, 개발한 소스코드를 토대로 실행파일이 생성이 됩니다.어떻게 우리가 작성한 소스코드가 실행파일이 되는지 알아가보겠습니jhost.tistory.com대상 파일(object file) 생성 과정에 대해서 궁금하신 분은 이전에 작성한 글을 참고해 주시면 됩니다. 링커여러분들이 특정 프로그램을 실행할때 해당 프로그램을 실행하기 위한 실행 파일은 하나죠?(물론 그 하나의 실행 파일을 실행 시키기 위해 부가적인 파일이 필요하기도 합니다.) 이전 글에서 말씀드린 컴파일러를 통해서 대상 파일(object file)이 생성된다..

여러분들은 개발을 진행하면서 단순히 소스코드를 작성하게 되고, 개발한 소스코드를 토대로 실행파일이 생성이 됩니다.어떻게 우리가 작성한 소스코드가 실행파일이 되는지 알아가보겠습니다. 인간이 인식할 수 있는 단어로 코드를 작성하는 것 == 소스 파일 (source file)이 소스 파일을 컴파일러에게 전달하면 실행 파일 형태가 됩니다.소스 코드 -> 컴파일러 -> 실행파일컴파일러?특정 프로그래밍 언어로 쓰여있는 문서를 다른 프로그래밍 언어로 옮기는 언어 번역 프로그램입니다. (번역기)컴파일러는 고급 프로그래밍 언어를 저급 프로그래밍(CPU가 인식할 수 있는) 언어로 바꿔주는 역할을 하며, 컴파일된 이후의 코드를 목적코드(object code)라고 합니다. 왜 컴파일러를 사용할까?간단한 코드 예시int a =..

콘서트 예매 사이드 프로젝트를 진행하면서 대기열 관련해서 개발을 진행하면서 비관적 락을 사용해서 대기열 동시성을 풀어 나가려고 했습니다. 요구사항 중 멀티 스레드 환경에서 여러 번의 요청이 들어와도 내가 정한 대기열의 인원수(QUEUE_LIMIT)만 ONGOING 상태로 저장되어야 하며, 대기열 등록 시 ONGOING 상태가 QUEUE_LIMIT 보다 크거나 같은 경우 WAIT 상태로 추가되어야 합니다. (REDIS를 사용하지 않고 대기열 문제를 풀어보고 싶어서 RDB를 사용) 대기열 등록 서비스 호출시 DB에서 ONGOING상태인 유저의 COUNT(*)를 가져와서 위에 요구사항 대로 진행하도록 구현을 하였습니다. 대기열 도메인 구현을 마친 후 마지막으로 동시성 테스트 코드를 작성하여 테스트를 돌려봤지만..

위와 같이 Member에 Team이 들어있는 경우, Member를 조회할 때 Team도 조회해야 할까? -> Member와 Team을 같이 사용하는 경우엔 괜찮지만, Member만 필요한 경우엔 Team까지 호출이 되면 리소스 낭비이다. (즉시로딩, 지연로딩의 차이점) 프록시 Hibernate가 내부에서 만든 가짜 엔티티 객체 em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getRefetence() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 em.getReference()를 호출하는 시점에는 데이터베이스에 query를 호출하지 않는다. 프록시 객체 초기화 1. em.getReference()를 호출해서 Proxy객체를 생성 2. target에 값이 없으면 영속..