공개를 위해 운영 IP·포트·호스트·서비스·DB 식별정보를 가명 처리하거나 이미지에서 가렸다. 원본 pcap은 운영 데이터 보호를 위해 첨부하지 않았다. 분석 수치와 패킷의 시간 관계는 유지했다.운영 환경에서 9개월 넘게 분당 수 건씩 찍히던 HikariCP 워닝 하나를 추적한 기록이다. 처음엔 방화벽을 의심했고, 이후엔 DB 쿼리와 설정을 의심했고, 마지막엔 패킷과 MySQL 내부 카운터로 범위를 좁혔다. 결론은 "DB 서버가 패킷을 읽기 전 단계에서 특정 커넥션만 1.5~2초 방치한다"는 것이고, 가장 유력한 원인은 MySQL Enterprise Thread Pool 플러그인이다. 다만 플러그인 내부 메커니즘까지는 아직 확정하지 못했다. 그 과정에서 세운 가설, 검증 방법, 결과를 시간순으로 기록한 ..

개요배경: 인증 서비스 버전 업그레이드(Java 21 → 25, Spring Boot 3.5 → 4.1) 검증을 위한 12시간 롱런 부하테스트 수행사건: 일정 부하(약 400rps) 유지 중 약 90초간 서비스 처리 정지 발생 후 자연 회복결론 요약: k8s CPU Limit의 CFS Bandwidth Control에 의한 컨테이너 동결. DB·GC·특정 API 무관, Java 버전 무관. 신·구 버전 양쪽에서 동일 발생 확인증상처리량(throughput) 순간 0 부근까지 하락HikariCP 커넥션 풀 대기(pending): 0 → 163 폭증응답 최대 지연 3.5초 (= connectionTimeout 3000ms + α)HTTP 5xx 약 11건 — SQLTransientConnectionExcep..

1. 개요요청량이 많이 몰리는 프론트 페이지가 있음.서비스의 모든 기능이용의 진입점으로, 누구나 반드시 거쳐야 하는 화면이다. Node.js로 운영된다. 이 페이지의 프론트 렌더링 방식을 CSR에서 SSR로 바꿨다. SSR이 더 우아한 선택처럼 보였으니까.그런데 그 변경 하나가, 신규 서비스 론칭 날 전체 서비스를 30분간 멈춰 세웠다. 렌더링 방식을 바꿨을 뿐인데 어떻게 시스템 전체가 마비됐을까. 2. 문제신규 서비스 출시 순간 해당 페이지로 Burst 트래픽이 몰렸다. 평소의 완만한 곡선이 아니라, 짧은 시간에 수직으로 꽂히는 트래픽이다. Node.js 서버가 과부하에 빠졌다. 요청 응답이 Internal Server Error로 떨어지기 시작했고, 그 상태가 약 30분간 이어졌다. 해당 페이지는 ..

1. 개요정해진 시각마다 도는 batch 서비스가 하나 있다.오래된 데이터를 정리하고, 조건에 맞는 사용자에게 안내 메일을 보내고, 만료된 레코드를 지우는, 흔한 정리성 잡들의 모음이다.지금까지는 인스턴스 한 대로만 돌았다. 한 대뿐이니 @Scheduled로 매일 정해진 시각에 잡을 깨우면 그만이었다. 중복도, 경합도 없다. 이걸 여러 대로 늘리기로 했다. 한 대에 몰리는 부하를 나누고, 그 한 대가 죽으면 서비스가 멈추는 구조도 벗어나고 싶었다.그런데 인스턴스를 열 대로 늘리는 순간 그동안 신경 쓸 필요 없던 것들이 한꺼번에 튀어나온다. 2. 무엇이 문제인가인스턴스를 늘릴 때 가장 먼저 떠오르는 걱정은 중복 실행이다.@Scheduled는 각 인스턴스의 타이머에서 독립적으로 수행된다. 열 대면 같은 잡..

1. 배경운영 중 배포 도중 문제가 생겨 롤백한 적이 있었다.신버전을 한 번에 전체 파드로 올리다 보니, 이상을 알아챘을 땐 이미 전체 트래픽이 신버전을 타고 있었다.그래서 신버전을 일부 트래픽에만 먼저 노출하고 문제가 없으면 비중을 단계적으로 올리는 canary 배포를 검토하게 됐다. 목표는 두 가지였다.문제가 나도 영향 범위를 canary 트래픽으로 한정하고 즉시 롤백한다.단계마다(ex: 10% → 50% → 100%) 검증하면서 비중을 올린다.환경은 이렇다. 쿠버네티스 클러스터가 버전이 다른 두 종류로 공존하고(argo-rollouts 컨트롤러 v1.2.0과 v1.6.6), 두 클러스터 모두 ingress로 Citrix(NetScaler)를 쓴다.argo-rollouts는 이미 설치돼 있었지만 사내..

1. 개요Java 21에서 정식화된 가상 스레드(virtual thread)는 Spring Boot 3.2+ 에서 spring.threads.virtual.enabled=true 한 줄로 켜진다. "켜면 처리량이 오른다"는 기대가 흔하다. 운영 중인 서비스(Spring Boot 4 / JDK 25 - vt pinning issue 해소)에 적용하면 실제로 얼마나 빨라질까? 결론은 단순하다. 처리량은 거의 오르지 않는다. 가상 스레드가 효과를 내는 조건은 "병목이 스레드일 때"로 한정되며, 잘 짜인 서비스는 대개 스레드보다 먼저 다른 자원에서 막힌다. 그리고 효과가 실제로 나타나는 지점은 처리량이 아니라 장애 격리다. 2. 가상 스레드는 언제 효과가 있나서버는 보통 요청 1개에 스레드 1개를 할당하는 th..

1. 문제 정의어떤 작업을 지정된 시각에 정확히 한 번 실행해야 하는 경우가 있다. (지연 작업)예를 들어 사용자가 가입한 뒤 24시간이 지난 시점에 온보딩 안내 메일을 1회 발송하는 상황을 생각해 보자.이를 여러 인스턴스로 동작하는 분산 환경(예: Kubernetes replicas)에서 처리하려면 다음을 보장해야 한다.정해진 시각(예: 24시간 뒤)에 작업이 실행될 것인스턴스가 여러 대여도 작업이 중복 실행되지 않을 것어떤 경우에도 작업이 유실되지 않을 것여기에 더해, 운영 관점에서 두 가지를 피하고자 했다. 이 두 가지가 이후 방식 선택의 핵심 기준이 된다.기준 1: 모든 인스턴스가 동시에 무언가를 주기적으로 폴링하는 구조를 피한다.기준 2: 그 폴링이 DB를 향하는 것을 특히 피한다(DB 부하)...

https://velog.io/@dohyunkim12/Java-NonWritableChannelException