document-haness/docs/n+1liner/tech-log-studio/jpa-feed-query-performance/question/question-concurrency-stability.md

id, kind, slug, title, topic, project, status, studio, questionStatus

id	kind	slug	title	topic	project	status	studio	questionStatus
6cbe963f-86f8-4df6-be5a-900712970d01	QUESTION	concurrency-stability	실제 동시 트래픽에서도 이 구조가 안정적인가	JPA 피드 조회 성능	Liner N + 1문제	게시 전	https://hyeonworks.com/studio/documents/6cbe963f-86f8-4df6-be5a-900712970d01/edit	OPEN

실제 동시 트래픽에서도 이 구조가 안정적인가

지금까지의 측정은 단일 스레드 퍼시스턴스 통합 테스트에서 조회 횟수의 증가 형태를 확인한 것이다. 처리량, 커넥션 풀 안정성, 동시성은 이 측정의 범위 밖이라 조회 구조가 실제 부하를 견디는지 아직 모른다.

관계

• PostgreSQL Query Plan 측정 기준 측정 범위와 도구 선택을 정한 기준이다.
• feed_visible을 Production CQRS로 승격할 것인가 부하 결과가 필요한 다른 판단이다.

사실

• 측정은 단일 스레드에서 이미 열린 테스트 트랜잭션 안의 어댑터 호출만 쟀다. HTTP 종단을 거치지 않았다.
• 지연 값은 warm cache 상태의 로컬 비교값이다. 표본은 7회 중 앞 2회를 버린 5개다.
• 표본이 적어 백분위수 대신 중앙값과 최댓값으로 기록했다.
• 왕복 수는 2,022개에서 23개로, 엔티티 로드는 1,569개에서 0개로, 자식 전송은 1,509행에서 최대 60행으로 줄었다.
• 깊은 페이지 조회는 2,000행 대신 20행을 읽었다.
• 문서 첫머리에 고트래픽 처리량, 커넥션 풀 안정성, 동시성이 범위 밖임을 명시했다.

가정

• 왕복 수가 줄면 같은 트래픽에서 DB 부하도 줄어든다.
• 요청당 왕복이 처리량에 곱해지므로 왕복 감소는 처리량 한계를 올린다.
• 단일 스레드에서 확인한 조회 형태는 동시 실행에서도 유지된다.

미지수

• 목표 처리량에서 커넥션 풀이 포화되는가. 풀 크기와 대기 시간은 어떻게 되는가.
• 동시 실행에서 지연 분포가 어떻게 되는가. 꼬리 지연이 어디까지 늘어나는가.
• 배치 크기 설정이 동시 실행에서 어떻게 작동하는가. 세션마다 독립인가.
• 깊은 페이지 요청이 섞이면 전체 지연에 어떤 영향을 주는가.
• 캐시가 차갑거나 통계가 갱신되지 않은 상태에서 계획이 달라지는가.
• 어느 지표를 운영 알람 기준으로 삼을 것인가.

제약

• 단일 스레드 값으로는 동시성 질문에 답할 수 없다. 도구를 바꿔야 한다.
• 안정적인 꼬리 지연을 말하려면 워밍업 후 반복 횟수를 크게 늘린 독립 세트가 여러 개 필요하다.
• 부하 테스트 환경이 운영과 다르면 결과를 그대로 옮길 수 없다. 데이터 규모와 하드웨어를 맞춰야 한다.
• 로컬에서 확인한 것을 운영에서 확인한 것으로 승격하지 않는다.

선택지

1. 부하 테스트와 APM으로 확인한다

목표 처리량을 정하고 종단 지연, 처리량, 커넥션 풀 지표를 함께 잰다. 조회 구조의 개선이 부하에서도 나타나는지 본다.

환경 구성과 데이터 준비에 시간이 든다.

2. 반복 횟수를 늘린 지연 측정부터 한다

같은 단일 스레드 조건에서 표본을 크게 늘려 꼬리 지연을 먼저 안정화한다. 동시성은 아직 다루지 않는다.

동시성 질문에는 여전히 답하지 못한다.

3. 현재 범위를 명시하고 운영 판단은 미룬다

조회 형태 개선까지만 주장하고 처리량은 다루지 않는다. 필요해질 때 부하 테스트를 연다.

운영에 올린 뒤 문제를 발견할 위험이 남는다.

다음 검증

1. 목표 처리량과 허용 지연을 먼저 정한다. 기준이 없으면 결과를 판정할 수 없다.

2. 운영과 비슷한 데이터 규모를 준비한다. 편중 분포를 유지한다.

3. 부하 테스트로 종단 지연과 처리량을 측정한다. 커넥션 풀 사용률과 대기 시간을 함께 본다.

4. 개선 전후 구조를 같은 조건에서 비교한다. 왕복 감소가 처리량으로 이어지는지 확인한다.

5. 깊은 페이지와 얕은 페이지 요청을 섞어 지연 분포를 본다.

6. 운영 알람으로 쓸 지표를 정한다.