조용한 개발 노트

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경5편에서 Linux는 Heap을 모르고, 페이지와 가상 주소 공간만을 관리한다는 점을 살펴봤다.이번 편에서는 그 연장선에서 가장 당황스러운 현상 하나를 다룬다.“로그도 없이 프로세스가 죽었다”“JVM 예외는 없는데 컨테이너가 재시작됐다”이 현상의 주범은 대부분 OOMKill이다.OOMKill은 예외가 아니라 정책이다많은 개발자가 OOMKill을 이렇게 받아들인다.“메모리 버그가 터졌다”하지만 Linux 관점에서 OOMKill은 버그가 아니다.시스템을 살리기 위한 마지막 선택이다.Linux 커널의 우선순위는 명확하다.개별 프로세스보다시스템 전체의 생존메모리가 고갈되면, 커널은 프로세스를 선택해 제거한다.OutOfMemoryError와 OOMKill은..

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

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