조용한 개발 노트

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경4편에서 Pod 종료는 예외 상황이 아니라 정상적인 운영 흐름이라는 점을 봤다.이번 편에서는 그 종료 과정에서 가장 자주 깨지는 지점, 바로 Graceful Shutdown을 정면으로 다룬다.Graceful Shutdown이 왜 문제가 되는가운영 중에 다음과 같은 현상을 한 번이라도 겪었다면, 대부분 종료 설계 문제다.배포 중 간헐적인 5xx 증가정산 - 결제 - 이벤트 처리 누락종료 로그는 찍혔는데 데이터는 반영되지 않음“가끔” 터지는 장애이 문제들의 공통점은 하나다.종료가 갑작스럽게 일어났고, 애플리케이션은 준비되어 있지 않았다.Kubernetes가 보장하는 종료는 여기까지다Kubernetes의 종료 시퀀스는 매우 단순하다.Pod..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경3편에서는 Probe가 단순한 헬스체크가 아니라, Kubernetes의 의사결정 입력값이라는 점을 살펴봤다.이번 편에서는 그 Probe들이 언제, 어떤 맥락에서 평가되는지, 즉 Pod 전체 생명주기를 Spring Boot 실행 흐름과 함께 정리해본다.Pod Lifecycle을 이해해야 하는 이유운영 중인 Spring 서버에서 이런 질문을 한 번쯤 해봤을 것이다.왜 배포 중에 요청이 끊겼을까?왜 종료 로그는 찍혔는데 트랜잭션이 깨졌을까?왜 서버는 죽지 않았는데 트래픽이 빠졌을까?이 질문들의 답은 대부분 코드가 아니라 Pod Lifecycle에 있다.Kubernetes에서 애플리케이션은 “실행 → 서비스 → 종료”라는 단순한 흐름으로 움..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경Spring 서버를 Kubernetes 위에 올리면, “서버를 한 대 띄웠다”는 감각이 빠르게 무너진다.갑자기 시작 시간이 들쭉날쭉해지고, 재시작이 잦아지고, 로컬 캐시는 의미가 줄어들고, 트래픽이 조금만 흔들려도 지표가 달라진다.이 변화는 설정값 몇 개로 설명되지 않는다. 관점 자체가 달라져야 한다.Kubernetes는 VM을 관리하는 도구가 아니라, 프로세스 실행 환경의 규칙을 강제하는 플랫폼이기 때문이다.컨테이너는 VM이 아니다Kubernetes를 처음 접할 때 가장 흔한 오해는 “가벼운 VM을 여러 개 띄우는 것”이라는 비유다. 하지만 컨테이너는 VM과 구조가 완전히 다르다.VM하이퍼바이저 위에서 동작게스트 OS를 포함커널까지..

33편에서는 멀티 모듈 구조에서 Spring Boot를 어디에 두어야 하는지를 기준으로 정리했다.이번 글에서는 그 구조가 한 단계 더 확장된 상황, 여러 개의 Spring Boot 애플리케이션을 동시에 운영해야 하는 시점을 다룬다.이 단계에서는 더 이상 “코드 구조”만의 문제가 아니다. 배포 단위, 운영 책임, 장애 전파 범위가 핵심이 된다.1) “왜 굳이 애플리케이션을 나눠야 할까?”단일 Spring Boot 애플리케이션으로 시작하는 것은 매우 자연스럽고 합리적인 선택이다.하지만 다음 질문이 나오기 시작하면, 분리를 고민할 시점이다.배치 작업이 API 서버 성능에 영향을 준다일부 기능만 따로 배포하고 싶다실행 옵션(JVM, 리소스)이 서로 다르다이 문제들은 코드 정리로 해결되지 않는다. 운영 단위의 문..

27편에서는 Spring Boot의 Packaging 전략을 통해 왜 fat jar와 layered jar가 기본 선택이 되었는지를 살펴봤다.이번 글에서는 그 패키징 결과물이 컨테이너 환경에서 어떻게 실행되고, 왜 로컬과 다른 동작을 보이는지를 정리한다.“같은 JAR인데 왜 쿠버네티스에서는 다르게 느릴까?” “JVM 옵션을 왜 다시 봐야 할까?” 같은 질문에 구조적으로 답하는 것이 목표다.1) 컨테이너는 가상 머신이 아니다컨테이너 환경을 처음 접하면 VM과 비슷하다고 느끼기 쉽다.하지만 실행 모델은 전혀 다르다.VM: OS를 포함한 독립 환경컨테이너: 호스트 커널을 공유하는 프로세스 격리이 차이 때문에, JVM은 컨테이너 안에서 리소스를 “오해”할 가능성이 있다.Spring Boot가 컨테이너 친화적인 ..

26편에서는 TestConfiguration과 테스트 전용 설정 전략을 통해 테스트와 프로덕션 구조의 경계를 정리했다.이번 글에서는 애플리케이션이 “완성된 코드”를 넘어 어떤 형태로 배포되는가를 결정하는 Spring Boot Packaging 전략을 다룬다.“왜 Spring Boot는 fat jar를 기본으로 쓸까?” “이 구조는 컨테이너 시대에도 여전히 합리적일까?” 같은 질문에 답하는 것이 목표다.1) Packaging은 빌드 문제가 아니라 실행 모델이다많은 경우 패키징은 단순히 “빌드 산출물의 형태”로만 인식된다.하지만 Spring Boot에서 패키징은 실행 모델과 직결된다. “이 애플리케이션은 어떤 단위로 실행되고, 무엇을 포함한 상태로 배포되는가?” Spring Boot는 이 질문에 대해 매우 ..

웜업(warm-up)을 언제 켜고 꺼야 하는지에 대한 판단을 정리했다면, 이제 남는 질문은 하나입니다.“그 결정을 어떻게 가장 안전하게 구현할 것인가?”웜업 ON/OFF는 단순한 조건 분기처럼 보이지만, 실제로는 배포 안정성, 장애 대응 속도, 오토스케일링 시의 리스크까지 좌우하는 설계 요소입니다.이 글에서는 웜업을 다음과 같이 정의합니다.웜업은 Pod가 새로 올라올 때애플리케이션 시동 과정에서 단 한 번만 실행된다.이 전제하에서, Spring Boot 환경에서 사용할 수 있는 웜업 ON/OFF 구현 방식들을 비교하고, 각 방식의 장단점과 실무 기준 베스트 프랙티스를 정리합니다.방식 1. 환경 변수 기반 ON/OFF가장 단순하면서도, 웜업의 실행 시점과 의미가 가장 명확한 방식입니다.APP_WARMUP_..