목적: 5분간 클릭 트래픽 폭주 대응 검증

클릭→앨범 생성: 37명 유저 → 1,321개 앨범 생성 → 1,800개 이미지 분류

주요 지표 & 인사이트

• Spring Boot
  • CPU 순간 100 %, DB 커넥션 0→60, Acquire Time 0 → 600 ms → 1–2분간 P95 지연
• Cloud SQL (vCPU 1)
  • CPU 100 % 포화, 슬로 쿼리·fsync 급등 → 단일 vCPU 한계로 병목
• GPU 서버
  • 최대 13 % 활용, 대부분 CPU 처리 → GPU 배치·로직 최적화 필요
• Kafka
  • 모니터링 지표 누락(Exporter 미설치) → 다음 이벤트 전 도입

개선 포인트

• DB 인스턴스 vCPU 확대 & 슬로 쿼리 인덱싱
• Hikari 풀 최소 아이들 수 조정 (워밍업)
• GPU 경로 최적화 + 모니터링 강화
• Kafka Exporter 도입 및 SLO 대시보드 추가

대시보드 열기

핵심 구간 — 16 시 45 분 ~ 50 분

시각	관측 지표	변화 & 해석	영향
16:30 이전	CPU < 5 %, Load Avg ≈ 0.1, Idle DB 커넥션 ≈ 70	평상시 베이스라인	문제 없음
16:40 ~ 16:44	‑ CPU 첫 스파크(≈ 35 %)‑ Open‑Files 200 → 350	사전 트래픽 체크 / 프리로딩 단계로 추정	준비 과정
16:45 정각	**CPU max 100 % (1 초)**Load Avg 1.8, Open‑Files 700	사용자 대량 유입 시작	스레드 & FD 급증
16:46 ~ 16:48	‑ Active DB 커넥션 0 → 60‑ Acquire Time 0 ms → 600 ms 피크‑ GC Minor Count 10 → 30	풀 고갈로 커넥션 대기 → 지연 발생메모리 할당 급증 → Eden GC 붐	API p95 지연 ↑
16:49	‑ GC Stop‑the‑World 45 ms 피크 후 감소‑ Acquire Time 600 ms → 80 ms	Hikari 풀 최대치 확보 완료 & 캐시 Warm‑up	응답 속도 회복
16:50 ~ 16:55	CPU 25 % → 10 %, Load Avg 하락Active Conn 60 → 10 (idle ↑)	사용자 트래픽 정점 통과	시스템 정상화
17:00 이후	모든 지표 베이스라인 회귀	이벤트 종료	안정 상태

카테고리	이벤트 구간 동작	진단
CPU / Load	1 ~ 2 분간 60 % 이상 점유, 이후 급감	애플리케이션 쓰레드 스파이크이지만 CPU 바운드 상황은 아님
GC	Minor GC 횟수・Stop‑the‑World 시간 일시 상승(≤ 60 ms)	Eden 대량 할당 → 정상 GC, Old Gen 여유 ⇒ 메모리 압박 없음
HikariCP	풀 최대 150 중 Active 60까지 증가, Acquire Time ≲ 0.6 s	풀 크기 부족은 아님. 순간 쿼리 지연 → DB 성능 한계 근접
Open Files	170 → 700	keep‑alive 소켓 + 로그파일 추가. ulimit -n 32k 이상 권장
HTTP Request Count	동시 6 ~ 8 종 엔드포인트 폭발식 호출	트래픽 분포 정상, 4xx/5xx 없음 → 성공률 100 % 근접
Logback	INFO/WARN 로그 약 3 배 증가, ERROR 없음	예외 없이 정상 처리

1. 초기 커넥션 대기(0.6 s)

   • 원인: 트래픽 급증 시 커넥션 풀이 급격히 Active 로 전환 → DB 핸드오프 지연.

   • 대응:

     spring.datasource.hikari:
       minimum-idle: 30       # 워밍업 단계 확보
       connection-timeout: 2000

     또는 이벤트 시작 1 분 전 프리로딩 배치 실행.

2. Eden GC 스파이크

   • Heap 11 %→14 %로 여전히 낮음. GC Tuning 불필요.
   • 실제 병목은 GC가 아니라 DB Wait.

3. 모니터링 가시성

   • Latency P95/P99, Success Rate 패널 미구성 → 직관 부족.
   • Micrometer Histogram 활성화 후 SLO 대시보드(+ Alert) 추가 권장.

대시보드 열기

노란색: prod 초록색: dev

시각 (UTC)	주요 지표 변화	해석
04 : 43 ~ 04 : 45	• CPU 사용률 5 → 30 %
• 행 읽기·쓰기 증가(초당 ≈ 3 k)
• InnoDB buffer pool 사용률 미세 상승	애플리케이션 트래픽 예열 단계
04 : 46	CPU 100 % 포화 (vCPU 1 한계)Disk Busy ≈ 1 %InnoDB data fsync & log fsync 동시 급등MySQL 행 읽기·쓰기 각각 > 20 k	CPU‑바운드 상황.
워커 스레드가 동시 처리 → 커밋 플러시까지 CPU 독점
04 : 47	• 상위 슬로 쿼리 1 건 기록
• MySQL InnoDB 읽기/쓰기 IOPS 피크
• MySQL 데이터 읽기 캐시 적중률 → 99 % 유지	슬로 쿼리는 인덱스 누락 또는 파일 정렬 가능성. 캐시 적중률 높음 → 디스크 병목 아님
04 : 48	CPU 70 % → 20 %로 급락
fsync·IOPS 동시에 감소	버스트 처리 완료, 대기 큐 소멸
04 : 49 ~ 04 : 53	• CPU < 10 % 베이스라인 회귀
• 커넥션 수 소폭 감소(0.8 → 0.3 conn/s)
• Buffer pool·메모리 사용량 완만히 하락	시스템 정상화

💡 디스크 사용률(Disk Busy 1.3 %)가 한계(5 %) 대비 매우 낮기 때문에, 병목은 스토리지가 아니라 단일 vCPU 로 인한 스레드 경쟁임을 확인할 수 있습니다.

범주	관찰	의미 / 원인
CPU 사용률	P99 = 100 %, P50 ≈ 5.9 %	이벤트 순간 완전 포화, 평시엔 여유
Rows Read / Written	최대 20 k ~ 30 k rows/s	읽기·쓰기 모두 폭주 → DB가 직접 트래픽 병목
InnoDB fsync	Data & Log fsync 동시에 200 ops/s	잦은 COMMIT → 그룹 커밋·binlog 플러시
Slow Queries	상단 패널 1 건 높이 > 200s 표시	인덱스 없거나 filesort / temp table 발생 추정
Disk Busy	최고 1.3 %	HDD(100 GB) IO 여유 → CPU 제한
Buffer Pool 적중률	99 % 유지	캐싱은 정상, 디스크 읽기 미발생

• 단일 vCPU 한계 – CPU 포화로 전체 처리 지연.
• 슬로 쿼리 – 이벤트 시점에 특정 쿼리가 길게 실행되어 워커를 블록.
• COMMIT 폭주 – fsync 스파이크가 log write 마다 flush = 1 설정 가능성.

“CPU 100 % 1 vCPU 스파이크 → DB 전체 일시 지연” ⇒ vCPU 2 ↑ + 슬로 쿼리 인덱스 최적화 로 다음 이벤트에도 안정적인 처리 가능.

Kafka로 전환하면서 HTTP 에서 kafka 프로토콜로 전환 따라서 kafka exporter를 설치했어야했는데 대비를 하지 못했습니다. 이후 다음 이벤트를 위해 도입

대시보드 열기

구간(UTC+9)	GPU 사용률(%)	상관 관계 해석
16 : 35 ~ 16 : 44	≈ 0 %	GPU 미사용 – 애플리케이션은 꾸준히 임베딩 API를 호출하지만 GPU는 idle.
16 : 45	13 % 피크	워커가 첫 배치(≈ 400 req)를 GPU로 처리.
16 : 46 ~ 16 : 48	0 % ↗ 4 % ↘ 0 %	짧은 마이크로‑배치 몇 회 → GPU util 3 ~ 4 %.
16 : 49 ~ 16 : 51	7 % → 0 %	또 한 차례 배치. 이후 GPU idle.
16 : 52 ~ 17 : 05	0 % (1 % 미만)	임베딩 요청은 계속되지만 GPU는 거의 안 씀(<= 2 %).

요약: 요청량 대비 GPU Util이 0 ~ 13 % 에 불과합니다. 대부분의 임베딩이 CPU 경로로 빠지거나, GPU 컨테이너가 워밍‑업 배치만 실행하고 종료되는 패턴으로 보입니다.