Java3 시간당 34GB Spring Boot 로깅이 TPS에 미치는 영향과 병목점 분석 시간당 34GB의 로그 발생사내 인프라 담당자가 우리가 담당하고 있는 서버의 로깅 설정 관련된 내용을 공유해주었다. 간단하게 정리하면 다음과 같다:Cloudwatch는 로그 GB마다 과금되는 형태불필요한 로그로 인해 비용이 발생하는것으로 확인됨현재 서비스에서 발생하는 로그(특히 info)를 점검할 필요가 있음도메인 개발자라서 인프라 업무를 직접 수행할 기회와 권한이 없었다. 이번에 인프라팀이 공유해준 걸 계기로 개인적으로 살펴보았다. 먼저 Cloudwatch에 들어가 직접 눈으로 로그 발생량을 확인했다. 우리 서비스는 HR 서비스이기 때문에 대부분의 트래픽은 9시부터 18시 사이에 발생한다. 시간당 대략 34GB(2.7억건)의 로그가 발생하며 그 중에 44% 정도가 jdbc.resultset=INFO 에.. 2026. 3. 1. [JVM Internal] 레지스터 vs 스택 머신: 자바는 왜 스택 방식을 택했는가? (바이트코드 분석) 들어가며이 글은 거창하게 바이트코드를 분석하려는 의도로 시작하지 않았다. 단지 JVM을 학습하는 과정에서 제시된 간단한 실습 예제를 직접 실험해보고 있었다. 작성된 자바 파일을 javac와 javap 명령어로 컴파일하고 역어셈블(Disassemble)하는 과정은 생각보다 많은 질문을 던져주었다. "우리가 작성한 소스코드는 실제로 JVM 위에서 어떻게 돌아갈까?""단순한 i++ 연산은 CPU와 메모리 관점에서 어떤 비용을 지불하는가?" 이러한 질문을 가지고 실험을 하면서, 컴파일러의 최적화와 JVM의 스택 머신 아키텍처 특징을 바이트코드와 그 연산 플로우에서 확인할 수 있었다. 이 글에서는 간단한 증감 연산자(i++) 실험을 통해 소스코드가 바이트코드로 변환될 때 발생하는 차이와 그 원리를 정리해본다. 자.. 2026. 1. 19. 자바 플랫폼 vs 가상 스레드 - 언제, 왜 성능 차이가 나는가? 요약가상 스레드는 CPU성능을 높이는 기술이 아닌, 대기 중인 스레드의 점유 비용을 낮추는 동시성 모델이다.스파이크 트래픽 환경에서 I/O-bound 작업은 가상 스레드로 인해 큐 대기와 p95 지연이 크게 줄어들었다.CPU-bound 작업에서는 스레드 모델 변경만으로 유의미한 성능 차이가 나타나지 않았다.가상 스레드는 병목을 제거하기보다, 병목의 위치를 스레드에서 다른 계층(DB, 외부 API 등)으로 이동시킨다.따라서 가상 스레드 도입은 성능 최적화 문제가 아니라, 백프레셔/타임아웃/제한 등의 설계를 포함한 시스템 설계 문제로 여겨야한다. 문제 Java 21에서 가상스레드가 도입되었다. 개인적으로 가상 스레드는 넷플릭스 테크 블로그 아티클 "Java 21 Virtual Threads - Dude, W.. 2026. 1. 11. 이전 1 다음
