조용한 개발 노트

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..

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..

38편에서는 Auto-Configuration이 성능에 미치는 영향을 통해 기본값이 언제 비용이 되는지를 살펴봤다.이번 글에서는 그 연장선에서, 실무에서 가장 당황스러운 상황 중 하나를 다룬다. “테스트는 다 통과하는데, 운영에서는 왜 깨질까?” 이 문제는 우연이 아니라, 테스트 환경과 운영 환경의 전제가 다르기 때문에 반복해서 발생한다.1) 테스트는 항상 “다른 Spring Boot”를 띄운다많은 개발자가 테스트를 이렇게 인식한다. “운영이랑 같은 Spring Boot를 띄우는 거니까 안전하겠지.” 하지만 실제로 테스트에서 띄우는 Spring Boot는 운영과 완전히 동일하지 않다.테스트는 다음을 의도적으로 바꾼다.ProfilePropertySourceAuto-Configuration 적용 범위외부 의..

대규모 트래픽 환경에서 가장 어려운 질문은 “어떻게 고칠까?”가 아닙니다.“지금 이 상태를 장애로 봐야 할까?”서버는 살아 있고, 에러율도 낮으며, 모니터링 지표도 완전히 무너진 건 아닙니다.하지만 사용자 체감은 분명히 나빠지고 있고, 어딘가 불안합니다.이 글에서는 이 애매한 상태를 감각이 아니라 기준으로 판단하는 방법을 정리합니다.완전 장애보다 더 흔한 상태실무에서 마주치는 대부분의 문제는 완전 장애가 아닙니다.서비스는 응답한다에러율은 0.x%헬스 체크는 통과한다하지만,p99 레이턴시는 튀고일부 요청은 타임아웃되고CS나 알림은 점점 늘어난다이 상태가 바로,“판단이 필요한 상태”입니다.장애 판단을 어렵게 만드는 착각1. 에러율이 낮으면 괜찮다는 착각에러율은 장애 판단에 중요한 지표지만, 충분 조건은 아닙..