feat: 문서 구조 변경 및 tech-visual 스킬 추가

2026-09-04 18:20:00 +09:00
parent 43901f0abf
commit 2efb7ee1f2
683 changed files with 61180 additions and 10479 deletions
@@ -0,0 +1,87 @@
+---
+id: 6cbe963f-86f8-4df6-be5a-900712970d01
+kind: QUESTION
+slug: concurrency-stability
+title: 실제 동시 트래픽에서도 이 구조가 안정적인가
+topic: JPA 피드 조회 성능
+project: Liner N + 1문제
+status: 게시 전
+studio: "https://hyeonworks.com/studio/documents/6cbe963f-86f8-4df6-be5a-900712970d01/edit"
+questionStatus: 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. 운영 알람으로 쓸 지표를 정한다.