조용한 개발 노트

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경1편부터 11편까지 우리는 Linux 커널이 JVM 서버를 어떻게 바라보고, 어떤 규칙으로 자원을 나누며, 언제 개입하고, 언제 프로세스를 종료하는지를 따라왔다.이 마지막 편에서는 지금까지의 내용을 하나로 묶는다.서버 장애를 “현상”이 아니라 “상태”로 읽는 법서버 장애는 갑자기 생기지 않는다운영 중 장애를 마주하면 보통 이렇게 느낀다.어제까지 잘 되던 서버가 갑자기 느려졌다로그 없이 서버가 죽었다특정 조건에서만 문제가 재현된다하지만 Linux 관점에서 보면,이런 장애는 “갑작스러운 사고”가 아니다.커널의 상태가 임계점에 도달했을 뿐이다.“느린 서버”를 Linux 상태로 번역하기“서버가 느리다”는 말은 너무 추상적이다.Linux 관점에서는 보통 다..

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경1편부터 10편까지 우리는 Linux 커널이 JVM 서버를 어떻게 실행하고, 어떤 규칙으로 자원을 나누며, 어떻게 감시하고, 언제 죽이는지를 하나씩 살펴봤다.이번 편에서는 그 모든 요소가 한 지점에서 충돌하는 순간들을 정리한다.운영 중 자주 듣는 말들이 있다.“코드는 멀쩡한데 서버가 느리다”“메모리는 남아 있는데 죽었다”“배포할 때만 이상하다”이 말들은 대부분 JVM, Linux, 컨테이너의 가정이 서로 어긋나는 지점에서 나온다.충돌 1. JVM의 병렬성 가정 vs Linux 스케줄러JVM은 기본적으로 이렇게 가정한다.CPU 코어 수만큼 병렬 실행이 가능하다스레드를 늘리면 처리량이 늘어난다하지만 Linux 스케줄러(CFS)는 다르게 동작한다.CPU..

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경8편에서 우리는 namespace가 컨테이너를 “다른 세계처럼 보이게” 만드는 기술이라는 점을 살펴봤다.이번 편에서는 그 세계 안에서 서버를 가장 조용히, 그리고 가장 자주 무너뜨리는 요소를 다룬다.파일 디스크립터(File Descriptor)이 개념은 너무 기본적이어서 종종 중요성을 잊는다.하지만 실무 장애에서 파일 디스크립터는 생각보다 자주, 그리고 치명적으로 등장한다.파일 디스크립터란 무엇인가Linux에서 파일 디스크립터는프로세스가 커널 리소스에 접근하기 위한 핸들이다.파일 디스크립터로 표현되는 대상은 생각보다 많다.일반 파일소켓파이프stdin / stdout / stderr즉,네트워크 서버는 파일 디스크립터 위에 세워진 프로그램이다.소켓도 ..

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경7편에서 cgroup은 리소스를 “제한”하는 기능이 아니라 프로세스가 어떤 규칙 아래에서 실행되는지 정의하는 시스템이라는 점을 살펴봤다.이번 편에서는 컨테이너의 또 다른 핵심 축인 namespace를 다룬다.cgroup이 “얼마나 쓸 수 있는가”를 정한다면,namespace는 “무엇을 볼 수 있는가”를 정한다.namespace가 없었다면 컨테이너는 존재할 수 없다컨테이너를 처음 접하면 이런 착각을 하기 쉽다.컨테이너는 가벼운 VM이다컨테이너마다 OS가 따로 있다하지만 Linux 관점에서 이는 사실이 아니다.컨테이너는 같은 커널을 공유한다.그럼에도 컨테이너가 서로 완전히 분리된 것처럼 보이는 이유가 바로 namespace다.namespace의 본질n..

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경6편에서 우리는 OOMKill이 버그가 아니라 Linux 커널의 생존 전략이라는 점을 살펴봤다.이번 편에서는 그 OOMKill과 CPU 스로틀링의 근원이 되는 핵심 개념, cgroup(Control Group)을 다룬다.cgroup은 흔히 이렇게 설명된다.“컨테이너 리소스를 제한하는 기능”하지만 이 설명은 충분하지 않다.cgroup은 단순한 제한 장치가 아니라, 프로세스가 어떤 규칙 아래에서 실행되어야 하는지를 정의하는 시스템이다.cgroup이 등장한 이유cgroup이 도입되기 전의 Linux에서는 다음과 같은 문제가 반복적으로 발생했다.특정 프로세스가 메모리를 과도하게 사용다른 프로세스까지 함께 느려짐시스템 전체가 불안정해짐Linux 커널은 프로..

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

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경1편에서 Kubernetes는 “서버를 관리하는 도구”가 아니라 프로세스 실행 규칙을 강제하는 환경이라는 이야기를 했다.이번 편에서는 그 규칙 중에서도 가장 중요한 질문 하나를 정면으로 다뤄보려 한다.Pod는 도대체 무엇을 보장해주고, 무엇은 절대 보장해주지 않는가이 질문에 대한 오해가 많을수록, 운영 환경에서는 “이유를 알 수 없는 장애”가 늘어난다.Pod는 “실행 단위”이지 “존재 보장 단위”가 아니다Pod를 처음 접하면 자연스럽게 이런 기대를 하게 된다.Pod는 실행 중이어야 한다Pod는 쉽게 죽지 않을 것이다Pod가 살아 있으면 서버도 안정적일 것이다하지만 Kubernetes 공식문서의 관점은 다르다.Pod는 유지 대상이 아니..

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

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

Part 3는 Spring Boot의 내부 기능 설명을 넘어, Spring Boot를 둘러싼 실행·확장·책임의 경계를 다룬다.그 첫 주제는 Spring을 오래 써도 명확히 짚고 넘어가지 않는 개념, ApplicationContext와 BeanFactory의 차이다.“둘 다 Bean 컨테이너 아니야?”라는 질문에 구조적으로 답할 수 있게 되는 것이 목표다.1) BeanFactory는 “최소 컨테이너”다BeanFactory는 Spring의 가장 기본적인 컨테이너 인터페이스다.역할은 단순하다.Bean 정의를 보관하고요청 시 Bean을 생성한다즉, BeanFactory는 객체 생성과 의존성 해소만을 책임진다.그 외의 기능은 의도적으로 포함하지 않는다.이 설계는 “가볍고, 단순하며, 핵심만 가진 컨테이너”를 만들..