Spring Boot 프로젝트에서 @RestControllerAdvice로 에러를 한곳에서 처리하고, 로그에 traceId를 남기고 싶을 때가 있다. 이때 많은 사람들이 흔히 하는 실수가 있다. 바로 “Advice 안에서 traceId를 만들고 로깅하는 것”이다. 겉보기엔 간단하지만, traceId는 요청 전체를 추적하기 위한 값이기 때문에 예외가 터진 시점이 아니라, 요청이 들어온 시점에 만들어야 한다. 그래야 “요청 시작 → 서비스 로직 → 응답/예외 처리” 모든 로그가 같은 traceId로 묶인다.그래서 등장하는 개념: MDC (Mapped Diagnostic Context)MDC는 로그에 문맥(Context)을 담는 기능이다.각 스레드마다 독립적인 key-value 맵을 가지고 있어서 “현재 요청..

앞서 쿠버네티스의 전반적인 구조—클러스터, 노드, Pod—를 통해 전체 흐름을 이해해봤다. 이제는 그 구조 안에서 실제로 누가 어떤 역할을 담당하는가?, 즉 이 구성 요소들을 어떻게 다루는가?에 대해 정리해보자.1. 쿠버네티스 클러스터Pod는 누가 배치하는가?쿠버네티스에서는 클러스터 환경 안에서 Pod가 노드에 배치된다고 했다. 그렇다면 이 배치 작업은 누가 담당하는가? 에 대한 질문이 생긴다. 이 역할을 담당하는 주체가 바로 컨트롤 플레인(Control Plane)이다. 컨트롤 플레인 vs 워커 노드쿠버네티스 클러스터는 크게 두 가지 종류의 노드로 구성된다. 구성 요소역할컨트롤 플레인 노드클러스터 전체를 관리하고 제어함. Pod 배치, 상태 확인, 스케줄링 등 수행워커 노드실제 Pod가 배치되어 실행..

쿠버네티스란 무엇일까? 많이 들어봤지만, 단순히 "컨테이너를 관리하는 플랫폼" 정도로만 알고 있었다. 그러다 무료로 NKS(Naver Kubernetes Service)를 사용할 기회가 생겨, 클라우드 플랫폼에서 쿠버네티스를 직접 다뤄보면서 구조와 개념을 더 깊이 이해할 수 있었다. 기존에 서버를 배포할 때는 EC2 같은 인스턴스를 띄우고, 그 안에서 코드를 GitHub에서 가져오거나 Docker 이미지를 통해 배포하는 방식을 사용했었다. 즉, 하나의 서버 안에서 이미지를 여러 개 띄우거나, 코드를 빌드한 뒤 백그라운드에서 서버를 실행시키는 방식이었다. 그래서 처음엔 쿠버네티스도 이런 ‘서버 안에서 동작하는 기술’이라고 생각했고, 그 개념을 이해하는 데 시간이 좀 걸렸다. 물론, 서버 안에서 이미지를 띄..