조용한 개발 노트

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경“서버를 띄운다”는 말은 익숙하지만, 그 말이 실제로 무엇을 의미하는지는 자주 생략된다.VM을 만들고, 컨테이너를 올리고, Pod를 띄우는 순간에도 우리는 여전히 이렇게 말한다.서버를 띄웠다하지만 Linux 관점에서 이 말은 정확하지 않다.리눅스에는 서버라는 개념이 없다.리눅스가 아는 것은 오직 프로세스다.리눅스가 이해하는 유일한 실행 단위Linux 커널이 관리하는 핵심 대상은 다음 몇 가지뿐이다.프로세스스레드메모리파일 디스크립터스케줄링 큐여기 어디에도 “서버”, “애플리케이션”, “서비스” 같은 개념은 없다.즉, Linux 입장에서 Spring 서버는그냥 하나의 프로세스다.JVM 서버의 실체Spring Boot 애플리케이션을 실행하면 어떤 일이 ..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경1편부터 11편까지 우리는 Kubernetes를 “사용법”이 아니라 실행 환경의 규칙으로 바라봤다.마지막 편에서는 그 규칙들이 무엇을 의미하는지, 그리고 Spring 서버를 운영하는 우리의 책임이 어디까지인지 정리한다.서버리스는 아니지만, 서버도 아니다Kubernetes 위의 Spring 서버는 종종 두 극단 사이에서 오해된다.서버리스처럼 신경 쓸 게 없다기존 서버와 똑같이 운영하면 된다둘 다 틀렸다.Kubernetes는 서버를 감춰주지 않는다.대신, 서버의 생명주기를 더 자주, 더 명확하게 드러낸다.시작과 종료, 재시작, 축출, 스케일링이 모두 일상적인 이벤트가 된다.Kubernetes는 문제를 해결해주지 않는다많은 사람들이 Kub..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경10편에서 Pod 재시작은 실패가 아니라 정상적인 복구 메커니즘이라는 관점을 다뤘다.이번 편에서는 그 재시작보다 한 단계 위에서 벌어지는 일, Node 장애와 Pod Eviction을 살펴본다.운영 중에 이런 상황을 본 적이 있을 것이다.특정 Pod들이 한꺼번에 사라진다재시작 이유가 명확하지 않다애플리케이션 로그에는 아무 흔적이 없다이 현상의 배경에는 대부분 Node 단위의 문제가 있다.Kubernetes에서 Node는 “안정적인 전제”가 아니다전통적인 서버 운영에서는 이런 전제가 암묵적으로 깔려 있었다.서버는 웬만하면 살아 있다Kubernetes에서는 이 전제가 성립하지 않는다.Node는 언제든 사라질 수 있는 자원이다.클라우드 인..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경9편에서 HPA가 왜 늦게 반응하는지 살펴봤다.이번 편에서는 운영 중 가장 자주 오해되는 현상, Pod 재시작을 다룬다.로그에 이런 문구가 보이면 대부분 긴장한다.Restarting container, CrashLoopBackOff하지만 Kubernetes 관점에서 재시작은 “문제”가 아니라 기본 복구 메커니즘이다.재시작은 실패가 아니라 전략이다전통적인 서버 운영에서는 프로세스가 죽으면 사고였다.원인을 찾고, 수동으로 재기동하고, 재발을 막는 것이 목표였다.Kubernetes의 관점은 다르다.프로세스는 언제든 죽을 수 있고, 다시 띄우면 된다.이 전제 위에서 모든 것이 설계되어 있다.Restart Policy의 실제 의미Pod에는 R..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경8편에서 우리는 QoS Class가 장애 상황에서 어떤 Pod를 살리고, 어떤 Pod를 포기하는지 결정한다는 것을 봤다.이번 편에서는 트래픽이 늘어났을 때 “알아서 늘어나야 할” 컴포넌트, HPA가 왜 항상 기대만큼 빠르게 반응하지 않는지 살펴본다.HPA에 대한 가장 흔한 기대많은 사람들이 HPA를 이렇게 기대한다.트래픽이 늘면 바로 Pod가 늘어난다CPU가 튀면 즉시 스케일 아웃된다부하가 줄면 자연스럽게 줄어든다하지만 실제 운영에서는 이런 말을 더 자주 듣는다.“트래픽은 이미 터졌는데, Pod는 한참 뒤에 늘어났다”이 현상은 설정 실수 이전에, HPA의 구조적 특성에서 비롯된다.HPA는 “실시간 반응 시스템”이 아니다가장 먼저 바로..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경7편에서 CPU와 Memory request/limit이 JVM 성능에 직접적인 영향을 준다는 것을 봤다.이번 편에서는 그 리소스 설정이 장애 상황에서 어떤 Pod를 살리고, 어떤 Pod를 먼저 죽일지를 어떻게 결정하는지 다룬다.이 판단 기준이 바로 QoS Class다.QoS Class는 “성능 등급”이 아니다QoS라는 이름 때문에 종종 이렇게 오해한다.QoS가 높으면 빠르다QoS가 낮으면 성능이 떨어진다하지만 Kubernetes에서 QoS Class의 본질은 전혀 다르다.QoS Class는 “장애 상황에서의 생존 우선순위”다.평상시에는 큰 차이가 없다.하지만 노드에 문제가 생기는 순간, 이 차이는 바로 결과로 나타난다.Kuberne..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경6편에서는 종료 중에도 트랜잭션이 흐르고 있다는 사실을 봤다.이번 편에서는 운영 중 가장 많이 겪지만, 가장 오해가 많은 주제를 다룬다.“CPU랑 메모리 limit을 걸었을 뿐인데, 왜 서버가 느려질까?”이 질문의 답은 JVM이나 Spring 설정 하나로 설명되지 않는다.Kubernetes의 리소스 모델과 JVM의 실행 모델이 충돌하는 지점에서 문제가 생긴다.request와 limit은 “권장값”이 아니다Kubernetes 리소스 설정을 처음 접하면 이렇게 이해하기 쉽다.request는 최소 보장limit은 최대 사용개념적으로는 맞지만, JVM 관점에서는 이 설명이 너무 순하다.limit은 “경고선”이 아니라 “강제 제약”이다.CPU..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경5편에서 Graceful Shutdown이 왜 필수인지 살펴봤다.이번 편에서는 종료 과정에서 가장 민감하고, 가장 자주 문제를 일으키는 대상인 트랜잭션을 다룬다.종료 중 트랜잭션 문제는 왜 위험한가트랜잭션 문제는 로그로 잘 드러나지 않는다.대부분 이런 형태로 발견된다.정산 금액이 맞지 않는다중복 처리된 데이터가 있다간헐적으로 누락되는 이벤트가 있다그리고 공통된 설명이 붙는다.“재현이 안 된다”종료 시점의 트랜잭션 문제는 타이밍 문제이기 때문에, 로컬이나 테스트 환경에서는 거의 드러나지 않는다.Pod 종료 중에도 요청은 처리되고 있다가장 먼저 바로잡아야 할 오해가 있다.Pod가 Terminating 상태라고 해서, 트랜잭션이 자동으로 ..

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에서 애플리케이션은 “실행 → 서비스 → 종료”라는 단순한 흐름으로 움..