GC2 시간당 34GB Spring Boot 로깅이 TPS에 미치는 영향과 병목점 분석 시간당 34GB의 로그 발생사내 인프라 담당자가 우리가 담당하고 있는 서버의 로깅 설정 관련된 내용을 공유해주었다. 간단하게 정리하면 다음과 같다:Cloudwatch는 로그 GB마다 과금되는 형태불필요한 로그로 인해 비용이 발생하는것으로 확인됨현재 서비스에서 발생하는 로그(특히 info)를 점검할 필요가 있음도메인 개발자라서 인프라 업무를 직접 수행할 기회와 권한이 없었다. 이번에 인프라팀이 공유해준 걸 계기로 개인적으로 살펴보았다. 먼저 Cloudwatch에 들어가 직접 눈으로 로그 발생량을 확인했다. 우리 서비스는 HR 서비스이기 때문에 대부분의 트래픽은 9시부터 18시 사이에 발생한다. 시간당 대략 34GB(2.7억건)의 로그가 발생하며 그 중에 44% 정도가 jdbc.resultset=INFO 에.. 2026. 3. 1. Fat 메시지로 인한 Consumer 메모리 누수 케이스 문제현상: 8개 Fargate Task 중 1개만 메모리 사용률이 지속 상승 (60% → 97%)결과: 메모리 알람 후 해당 Task 재시작특이점: 동일 코드 기반의 다른 Task들은 GC 정상 작동환경: Java 21, Spring Boot, Kafka Consumer, MyBatis Batch, AWS Fargate 증상 분석CloudWatch 메모리 그래프: 특정 Task만 계단식 상승덤프 서버: 동일 이벤트 처리에도 톱니형 GC 패턴 (정상)GC 자체 문제라기보다는 객체 참조 유지로 인한 회수 불가 상황에 가까움 원인 분석대량 청크 메시지권한 갱신 이벤트를 한 번에 2,500건 단위로 Kafka에 게시특정 Task가 해당 청크를 독점 처리하면 순간적으로 수만 개 객체 생성중복 역직렬화Consume.. 2025. 11. 23. 이전 1 다음
