가상 스레드를 켰는데 왜 빨라지지 않는가: JEP 491 이후 이동한 병목
JDK 24의 JEP 491로 synchronized pinning이 사라졌습니다. 지금 검색되는 가상 스레드 조언 절반이 낡았고, 진짜 병목은 커넥션 풀로 옮겨갔습니다.
JDK 24의 JEP 491로 synchronized pinning이 사라졌습니다. 지금 검색되는 가상 스레드 조언 절반이 낡았고, 진짜 병목은 커넥션 풀로 옮겨갔습니다.
Java 25 LTS의 JEP 18개 중 지금 바로 쓸 수 있는 것과 아직 프리뷰인 것을 구분했습니다. Scoped Values는 정식, 구조적 동시성은 아직 5번째 프리뷰입니다.
백엔드 시스템의 성능을 최적화하는 과정에서 가장 가성비가 좋고 즉각적인 효과를 볼 수 있는 기술은 단연 ‘캐싱(Caching)‘입니다. 관계형 데이터베이스(RDBMS)는 디스크 I/O를 기반으로 동작하기 때문에 물리적인 속도의 한계가 명확하며, 트래픽이 몰릴 경우 병목 현상의 주범이 됩니다. 반면 Redis와 같은 인메모리(In-Memory) 저장소는 RAM에 데이터를 저장하고 처리하므로, 디스크보다 수백 배 빠른 접근 속도를 제공합니다. 하지만 “Redis를 도입했다”는 사실만으로 모든 … 더 읽기
안정적으로 운영되던 서비스에서 갑작스럽게 특정 시간대에 API 응답 속도가 5초 이상 지연되는 현상을 겪어보신 적 있으십니까? 특히 TPS(초당 트랜잭션 수)가 평소와 다름없는 수준임에도 불구하고, 간헐적으로 발생하는 타임아웃과 지연은 개발자와 운영자를 곤혹스럽게 만듭니다. 네트워크 장비나 인프라의 문제가 아니라면, 그 원인은 의외로 우리가 무심코 사용했던 코드 한 줄에 숨어 있을 수 있습니다. 일부 서버에서 발생한 API 지연 … 더 읽기
백엔드 개발자가 로컬 환경에서 혼자 개발하고 테스트할 때는 절대 마주칠 수 없는, 하지만 운영 환경에 배포되자마자 서비스의 신뢰도를 바닥으로 떨어뜨리는 무서운 문제가 있습니다. 바로 ‘동시성 이슈(Concurrency Issue)‘입니다. 가장 대표적인 예가 ‘재고 관리 시스템‘입니다. 재고가 딱 1개 남은 인기 상품이 있다고 가정해 봅시다. 이 상품을 구매하기 위해 사용자 A와 사용자 B가 0.001초의 차이로 동시에 ‘구매’ 버튼을 … 더 읽기
Spring Data JPA를 사용하다 보면 신기한 경험을 하게 됩니다. 데이터베이스에서 객체를 조회한 후, setter 메서드로 값을 변경하기만 했는데 별도로 save()나 update() 메서드를 호출하지 않아도 DB에 변경 사항이 반영되는 현상입니다. 마치 자바 컬렉션에서 객체를 꺼내 필드를 수정한 것처럼 자연스럽게 동작합니다. 또한, 같은 ID를 가진 엔티티를 두 번 조회했는데 쿼리 로그에는 SELECT 문이 한 번만 찍히는 경우도 목격하게 됩니다. 이러한 JPA의 ‘마법’ 같은 기능 … 더 읽기
현대 웹 애플리케이션에서 소셜 로그인(Social Login)은 선택이 아닌 필수 기능이 되었습니다. 사용자 입장에서는 귀찮은 회원가입 절차를 건너뛸 수 있어 편리하고, 서비스 제공자 입장에서는 비밀번호 관리의 부담을 덜고 검증된 사용자 정보를 얻을 수 있다는 확실한 이점이 있기 때문입니다. 하지만 개발자 입장에서 소셜 로그인을 처음 구현하려고 하면 마주치는 장벽이 꽤 높습니다. “OAuth 2.0 프로토콜은 무엇이고, 리다이렉트 URI는 … 더 읽기
관측 가능성(Observability) 시리즈의 마지막 퍼즐이자, 마이크로서비스 아키텍처(MSA) 환경에서 병목 지점을 찾아내는 최고의 해결사인 “분산 추적(Distributed Tracing)“에 대한 포스팅입니다. 우리는 지금까지 ELK Stack을 통해 “과거에 발생한 에러 로그”를 통합 관리하는 법을 배웠고, Prometheus와 Grafana를 통해 “현재 서버의 리소스 상태”를 모니터링하는 체계를 갖추었습니다. 이 두 가지 시스템만으로도 모놀리식(Monolithic) 아키텍처나 서버 개수가 적은 환경에서는 충분한 관제 능력을 발휘할 수 있습니다. … 더 읽기
소프트웨어 개발, 특히 데이터베이스를 다루는 백엔드 개발이나 사용자 경험을 중시하는 프론트엔드 개발에서 “성능 최적화”는 영원한 숙제와도 같습니다. 우리는 항상 “어떻게 하면 더 빠르게 데이터를 보여줄 수 있을까?”를 고민합니다. 하지만 아이러니하게도 무조건 빨리, 모든 것을 미리 가져오는 것이 항상 정답은 아닙니다. 때로는 필요한 순간까지 기다렸다가 가져오는 것이 전체 시스템의 리소스를 절약하고 체감 속도를 높이는 지름길이 되기도 … 더 읽기
이전 포스팅에서 다룬 ELK Stack이 “과거에 무슨 일이 있었는지(Logs)“를 분석하는 도구라면, 오늘 다룰 Prometheus와 Grafana는 “현재 서버의 상태가 어떤지(Metrics)“를 진단하는 청진기와 같습니다. 지난 시간에 우리는 ELK Stack을 통해 대용량 로그를 통합 관리하는 방법을 배웠습니다. 이제 여러분은 특정 에러가 언제 발생했는지 로그를 통해 추적할 수 있는 능력을 갖추게 되었습니다. 하지만 로그만으로는 시스템의 전체적인 건강 상태를 파악하는 … 더 읽기