db 커넥션 풀 및 jvm 설정 추가

[jhan0121]

🚀 작업 내용

원인 분석

힙 덤프 분석 결과 두 가지 원인을 확인함.

• -Xmx 미설정으로 JVM 기본 힙이 약 227MB로 동작 중이었고,
  Spring Boot + OpenTelemetry + AWS SDK 조합에서 부하 시 90%에 도달
• HikariCP maxLifetime 기본값(30분)에 의한 커넥션 교체 사이클로
  ConnectionImpl 객체가 Finalizer 처리 속도보다 빠르게 누적 (힙 덤프 시점 1,506개 확인)
• 위 두 원인이 복합 작용: GC STW → 커넥션 점유 시간 증가 → pool 고갈 → timeout 47회 발생

변경 사항

Dockerfile

• -XX:MaxRAMPercentage=60.0 : 컨테이너 limit(600m) 기준 360MB를 최대 힙으로 사용
• -XX:InitialRAMPercentage=60.0 : 초기 힙을 최대값과 동일하게 설정해 힙 확장 비용 제거
• -XX:MaxMetaspaceSize=150m : NMT 실측값(~94MB) 기반으로 설정, 무제한 확장 방지
• -XX:+ExitOnOutOfMemoryError : OOM 시 즉시 종료 후 컨테이너 재시작 유도
• -XX:+HeapDumpOnOutOfMemoryError : OOM 발생 시 자동 힙 덤프 생성
• -XX:HeapDumpPath=/app/log/heapdump.hprof : 볼륨 마운트 경로에 저장해 재시작 후에도 보존

docker-compose.yml

• app: 600m / alloy: 150m / node-exporter: 30m 메모리 제한 설정
• t4g.micro 가용 메모리(909MB) 기준으로 각 컨테이너 배분

application-prod.yaml

• leak-detection-threshold: 5000 추가
• 5초 이상 반환되지 않는 커넥션 발생 시 스택 트레이스 포함 경고 로그 출력
• HikariCP 추가 튜닝 필요 여부를 판단하기 위한 모니터링 목적

📸 이슈 번호

• close db 커넥션 풀 및 jvm 설정 추가 #98

✍ 궁금한 점

• 매직 넘버 설정 초기값을 정하는 기준은 어떻게 잡아야 할까?

[github-actions]

코드 리뷰

힙 덤프 분석을 통해 복합적인 원인을 정확히 파악하고, 체계적으로 해결한 점이 인상적입니다. 전반적으로 방향성은 올바르나, 몇 가지 개선 사항을 제안드립니다.

---

✅ 잘된 점

• 힙 덤프 분석으로 근본 원인(JVM 힙 미설정 + Finalizer 지연 복합 작용)을 명확히 규명
• -XX:MaxRAMPercentage 방식으로 컨테이너 재배포 시에도 유연하게 대응
• InitialRAMPercentage = MaxRAMPercentage로 힙 확장 비용 제거 — 적절한 선택
• OOM 시 즉시 재시작(ExitOnOutOfMemoryError) + 볼륨 경로에 힙 덤프 보존 — 운영 관점에서 올바른 설계
• leak-detection-threshold 추가로 커넥션 누수 여부 모니터링 가능

---

🔴 주요 이슈

1. 힙 덤프 파일 고정 경로 → 덮어쓰기 위험

-XX:HeapDumpPath=/app/log/heapdump.hprof

OOM이 반복 발생하면 이전 덤프가 덮어써져 원인 추적이 어렵습니다. JVM은 파일이 이미 존재하면 덤프를 생성하지 않을 수도 있습니다.

제안: 디렉터리만 지정하면 JVM이 타임스탬프 포함 파일명을 자동 생성합니다.

-XX:HeapDumpPath=/app/log/

2. maxLifetime 원인 파악 후 미조치

PR 설명에서 HikariCP maxLifetime 기본값(30분)에 의한 커넥션 교체 사이클을 원인으로 명시하셨는데, 해당 값 조정이 변경 사항에 없습니다. 모니터링 후 튜닝 예정이라면 이슈나 TODO로 남겨두는 것이 좋을 것 같습니다.

# 검토 필요 — 기본값 30분이 Finalizer 누적의 원인으로 확인됨
# max-lifetime: 600000  # 예: 10분으로 단축 검토

---

🟡 개선 제안

3. UseContainerSupport 명시 불필요 (minor)

-XX:+UseContainerSupport

JDK 8u191+ / JDK 11 이상에서는 기본값이 true입니다. 현재 베이스 이미지가 최신이라면 제거해도 동일하게 동작합니다. 다만 명시적으로 남겨두는 것 자체가 해롭지는 않습니다.

4. ENTRYPOINT 가독성

현재 ENTRYPOINT가 한 줄에 모든 옵션이 나열되어 있어 diff 확인 및 향후 수정이 불편합니다. CMD로 JVM 옵션을 분리하거나, shell form + 개행으로 가독성을 높이는 방법도 고려해볼 수 있습니다.

ENTRYPOINT ["java", \
  "-Duser.timezone=UTC", \
  "-XX:MaxRAMPercentage=60.0", \
  ...
  "-jar", "app.jar"]

Dockerfile은 배열 형식(exec form)에서 \ 개행을 지원하지 않으므로, 실제로는 환경변수(JAVA_OPTS)나 쉘 스크립트로 분리하는 방법이 더 현실적입니다.

5. docker-compose 버전 호환성 확인

deploy:
  resources:
    limits:
      memory: 600m

deploy.resources.limits는 Docker Compose v2 CLI(docker compose)에서는 Swarm 없이도 동작하지만, 구버전 docker-compose (Python 구현)에서는 --compatibility 플래그 없이는 무시됩니다. 운영 환경에서 사용하는 CLI 버전을 확인해주세요.

6. swap 메모리 제한 미설정

메모리 limit만 설정 시 Docker 기본 동작은 swap을 memory * 2까지 허용합니다. 컨테이너가 swap을 사용하면 성능에 영향을 줄 수 있으므로, 필요에 따라 명시적으로 제한을 고려해볼 수 있습니다.

deploy:
  resources:
    limits:
      memory: 600m
      # memswap_limit: 600m  # swap 사용 금지 시

---

💬 매직 넘버 기준 질문에 대한 답변

매직 넘버 설정 초기값을 정하는 기준은 어떻게 잡아야 할까?

이번 PR처럼 측정 기반으로 결정하는 게 가장 좋습니다. 일반적인 접근 방식:

1. NMT / 힙 덤프 실측값 기반: 이번처럼 실측 94MB → 150m 상한 설정
2. 안전 마진 적용: 실측값의 1.5~2배를 초기값으로 설정 후 모니터링
3. 단계적 조정: 너무 타이트하게 시작하지 말고, 알람/로그로 병목을 확인하며 좁혀가기
4. 컨테이너 총량 역산: 이번처럼 호스트 가용 메모리(909MB)에서 서비스별로 역산하는 방식도 유효

leak-detection-threshold: 5000도 "5초면 정상 처리가 충분히 끝날 시간" 이라는 도메인 지식 기반이므로, 이런 식으로 근거를 PR 설명에 남기는 방식은 좋은 습관입니다.

---

메모리 배분 검산 (참고)

항목	값
컨테이너 limit	600m
JVM 최대 힙 (60%)	360m
Metaspace 상한	150m
JVM 기타 (스택, 코드캐시 등)	~90m
합계	~600m ✓
전체 컨테이너 합	780m + OS ~129m ≈ 909m ✓

배분 수치는 적절합니다.

[github-actions]

🧪 테스트 커버리지 리포트

Overall Project	96.74%	🍏

There is no coverage information present for the Files changed