개발 서버 Tomcat 설정 상향 및 lookup k6 검증 후속

[Whale0928]

배경

lookup API k6 검증 중 dev product-api에서 50 VU stress 단계에 liveness/readiness probe timeout이 발생했고, Pod가 1회 재시작되었습니다.

확인 내용

• dev product-api: replicas=1, cpu=500m/1500m, memory=2Gi/6Gi
• dev product-api 기존 Tomcat 설정: threads.max=15, max-connections=20, connection-timeout=5000
• prod product-api: replicas=2, Tomcat threads.max=200, max-connections=2000
• dev admin-api도 prod 대비 낮은 15/20 설정
• health probe는 앱 트래픽과 동일한 8080 포트를 사용

원인 가설

서버 리소스 부족보다는 dev Tomcat connection/thread 상한이 낮아 k6 50 VU에서 health probe가 starvation 되었고, kubelet liveness 실패로 재시작된 것으로 판단합니다.

조치

• dev product-api Tomcat 설정을 prod와 동일하게 상향
  • threads.max: 200
  • max-connections: 2000
  • connection-timeout: 30000
• dev admin-api Tomcat 설정을 prod와 동일하게 상향
  • threads.max: 100
  • max-connections: 500
  • connection-timeout: 30000

관련 커밋

• bottle-note-api-server: 0a6a63e4 fix: 개발 서버 Tomcat 설정 상향
• bottle-note-api-server: 404f930a fix: lookup 캐시 기본 활성화

후속 검증

• dev 배포 후 lookup k6 Load/Stress 재실행
• product-api Pod restart count 유지 여부 확인
• p95/p99, http_req_failed, liveness/readiness event 확인
• 필요 시 lookup 성공 요청 INFO 로그 제외 또는 actuator management port 분리 검토

[Whale0928]

개발 배포 완료

개발 서버 Tomcat 설정 상향 반영 완료
lookup API k6 재검증까지 완료.

배포 확인:

• product-api / admin-api dev 설정 반영
• product-api: threads.max 200, max-connections 2000, timeout 30000
• admin-api: threads.max 100, max-connections 500, timeout 30000

검증 흐름:

[k6]
  |
  v
[dev product-api]
  |
  +--> [Tomcat thread / connection]
  |
  +--> [Redis lookup snapshot]
  |
  v
[p95 / p99 / fail rate / pod resource]

검증 결과:

• Smoke 1 VU / 30s: p99 58.97ms, fail 0%

• Load 10 VU / 2m: p99 69.56ms, fail 0%

• Stress 50 VU / 3m: 54,989 req, 305.22 RPS, p99 143.86ms, fail 0%

• Pod restart 0회

• 이전 50 VU 실패 원인은 dev Tomcat thread/connection 상한이 낮아 health probe가 굶은 케이스로 확인.

• 현재 stress 기준 CPU max 1257m까지 올라가므로 운영 검증에서는 pod 수와 CPU limit을 같이 봐야 함.

[bottlenote-app]

2026-06-01 product-v1.1.8 운영 배포 반영: Tomcat 설정 상향 및 lookup 안정화 포함