📈 1. 성능 개선 요약

• AS-IS 대비 지연 시간을 약 390배 단축하고, 처리량을 4,200% 향상시켜 서비스 가용성 100%를 확보

  지표	최적화 전 (AS-IS: 200 VU)	최적화 후 (TO-BE: 150 VU)	개선율
  p(99) Latency	59.99s	154ms	약 390배 개선
  Request Failed	75.53%	0.00%	장애 완전 해소
  Throughput	7.59 ops/s	319.9 ops/s	약 4,200% 향상

🚨 2. 장애 원인 분석

2-1. 대량 데이터 조회 시의 병목 지점 파악

• 200 VU 부하 시 p(99) 지연 시간이 60s에 도달하며, Connection Timeout으로 인한 전체 요청의 75.53% 응답 불능 상태

  

  [지표] 부하 발생 직후 응답 시간이 60초를 기록하며 서비스 가용성이 1/4 수준으로 붕괴

• 초당 약 1,750만 행을 전수 조사하는 Sequential Scan 발생으로 인한 Cache Thrashing 및 Cache Hit Rate이 50.81% 급감 확인

  

  [분석] 과도한 풀 스캔으로 인해 유효 데이터가 캐시에서 밀려나며 메모리 적중률이 50.81% 까지 하락

2-2. 쿼리 실행 계획 분석

• Full Table Scan 및 리소스 독점
  • LIKE %keyword% 조건으로 인한 Parallel Seq Scan 발생
  • 단일 쿼리가 285,781건의 불 필요한 행을 필터링하여 CPU를 점유하고, 커넥션 점유 시간을 늘려 시스템 마비
• Buffer Pollution에 의한 캐시 오염
  • shared hit(15,277) 대비 read(19,132) 수치가 높게 나타나며, 메모리 내 유효 데이터가 축출되는 Cache Thrashing 확인

-> Parallel Seq Scan on tb_coupon c1_0
   Filter: (((title)::text ~~ '%NIKE%'::text) AND ((use_status)::text <> 'ALL'::text))
   Rows Removed by Filter: 285,781
   Buffers: shared hit=15,277 read=19,132
Execution Time: 183.064 ms

🛠️ 3. 개선 과정 및 시행착오

3-1. 데이터 구조 분리 및 1차 병목 해결

[개선 내용] 데이터 구조 분리를 통한 검색 성능 확보 시도