조용한 개발 노트

42편에서는 Spring의 Bean 생명주기 이벤트를 통해 애플리케이션 내부에서 언제 초기화하고 언제 정리할지를 어떻게 설계해야 하는지를 살펴봤습니다.이번 글에서는 그 전략을실제 운영 환경, 특히 Kubernetes에서 어떻게 안전하게 연결할 것인가를 정리해보겠습니다.이 글의 핵심 질문은 다음입니다.“Spring 애플리케이션의 생명주기와 Pod의 생명주기를 어떻게 맞출 것인가?”1. Kubernetes에서 Pod의 생명주기Kubernetes에서 Pod는 다음과 같은 생명주기를 가집니다.Pod 생성컨테이너 시작서비스 트래픽 수신종료 신호 수신 (SIGTERM)Graceful 종료강제 종료 (SIGKILL)Spring 애플리케이션은 이 흐름을 정확히 이해하지 못하면,기동 중 트래픽 유입종료 중 요청 손실같은..

41편에서는 @Conditional을 활용해 대규모 서비스에서 Bean을 “무엇을 생성할지” 설계하는 방법을 살펴봤습니다.이번 글에서는 그 다음 질문에 답해보겠습니다.“Bean이 생성되고, 준비되고, 종료되는 그 순간에 우리는 무엇을 할 수 있을까?”이 질문의 답이 바로 Bean 생명주기 이벤트입니다.1. Bean 생명주기 이벤트는 왜 필요한가대규모 서비스에서는 다음과 같은 요구가 자주 등장합니다.애플리케이션 기동이 끝났을 때 초기 작업 실행특정 Bean이 준비된 이후 후속 로직 수행종료 시 리소스 정리이 로직을생성자@PostConstruct에 넣기 시작하면, Bean의 책임이 급격히 무거워집니다.생명주기 이벤트의 목적은 명확합니다.“Bean 생성과 운영 로직을 분리한다”2. Spring에서 제공하는 주..

40편에서는 ApplicationContext 초기화 비용을 줄이기 위한 실무 전략을 단계별로 정리했습니다.이번 글에서는 그 전략을 설계 패턴으로 승격시키는 핵심 도구,@Conditional을 중심으로 대규모 서비스에서 Bean을 언제, 왜, 어떻게 생성할지를 체계화하는 방법을 살펴보겠습니다.1. 조건부 Bean이 왜 중요한가대규모 서비스에서는 다음 조건들이 동시에 존재합니다.환경(dev / stage / prod)기능 on/off (Feature Toggle)외부 시스템 연결 여부이때 모든 Bean을 무조건 생성하면,초기화 비용 증가불필요한 의존성 로딩기동 실패 가능성 증가로 이어집니다.조건부 Bean의 목표는 명확합니다.“필요한 순간에, 필요한 Bean만 생성한다”2. @Profile vs @Cond..

39편에서는 대규모 서비스에서 Bean 구성 전략을 어떻게 가져가야 하는지를 설계 관점에서 정리했습니다.이번 글에서는 그 전략을 실제로 체감 성능으로 연결하기 위해,ApplicationContext 초기화 과정에서 시간은 어디서 쓰이고, 무엇을 줄일 수 있는가를 단계별로 살펴보겠습니다.1. Spring Boot 기동이 느려지는 이유Spring Boot 애플리케이션의 기동 시간은 단일 작업이 아니라환경 설정 로딩자동 구성(Auto Configuration)Bean 스캔 및 생성의존성 주입초기화 콜백 실행의 누적 결과입니다.대규모 서비스에서는“작은 비용들이 쌓여 큰 지연이 된다”는 점을 항상 염두에 둬야 합니다.2. ApplicationContext 초기화 흐름 한 번에 보기ApplicationContext..

38편에서는 Servlet과 Reactive를 함께 사용하는 혼합 아키텍처 전략을 살펴봤습니다.이번 글에서는 그 아키텍처를 실제로 떠받치는Spring Bean 구성 전략을 대규모 서비스 관점에서 정리해보겠습니다.이 글의 핵심 질문은 다음입니다.“Bean은 많아질수록 왜 느려지고, 왜 복잡해질까?”1. 소규모와 대규모 서비스의 Bean 차이소규모 서비스에서는Bean 수가 적고의존 관계가 단순하며초기화 비용이 문제 되지 않습니다하지만 대규모 서비스에서는:Bean 수 수백~수천 개복잡한 의존 그래프초기화 순서 문제가 동시에 발생합니다.이때부터 Bean 구성은“기능 구현”이 아니라 “시스템 설계”의 영역이 됩니다.2. 모든 Bean을 한 번에 만들면 안 되는 이유Spring의 기본 전략은싱글톤 Bean을 App..

37편에서는 WebFlux를 언제 선택해야 하는지를 실행 모델과 트래픽 특성 관점에서 정리했습니다.하지만 실무에서는 이런 질문이 더 자주 나옵니다.“기존 Spring MVC를 전부 WebFlux로 바꿔야 할까?”결론부터 말하면,대부분의 경우, 그렇지 않다입니다.이번 글에서는 Servlet 기반과 Reactive 기반을 현실적으로 함께 사용하는 전략을 정리해보겠습니다.1. 왜 혼합 아키텍처가 필요한가대부분의 서비스는 다음과 같은 특성을 동시에 가집니다.일반적인 CRUD 요청 (동기 MVC에 적합)외부 API 호출이 많은 요청 (Reactive에 적합)실시간성/스트리밍 요청 (Reactive에 적합)이 모든 요청을전부 Servlet으로 처리하거나전부 Reactive로 처리하는 것은 현실적으로 비효율적인 선택..

36편에서는 Spring MVC 환경에서 비동기 처리(Callable, DeferredResult)를 통해 Servlet Thread 병목을 우회하는 방법을 살펴봤습니다.이번 글에서는 그 다음 질문에 답해보겠습니다.“그럼 언제부터는 비동기가 아니라 WebFlux를 써야 할까?”이 질문에 대한 답은 기술 선호가 아니라 실행 모델과 트래픽 특성에 있습니다.1. WebFlux는 무엇이 다른가Spring WebFlux는Servlet Thread 모델이 아닌, Reactive(Event Loop) 모델위에서 동작합니다.즉,요청 하나당 스레드 하나 ❌적은 수의 이벤트 루프 스레드로 다수 요청 처리 ⭕가 핵심 차이입니다.이 차이로 인해 WebFlux는Thread 점유를 최소화하고I/O 대기 동안 다른 작업을 수행할 ..

35편에서는 Servlet Thread-per-request 모델의 구조적 한계를 살펴봤습니다.이번 글에서는 그 한계를 넘기 위한 Spring MVC의 해법,“비동기 요청 처리(Async Request)”를 요청 흐름 기준으로 정리해보겠습니다.핵심 질문은 이것입니다.“Thread를 더 늘리지 않고 동시에 더 많은 요청을 처리할 수 있을까?”1. Spring MVC 비동기 처리의 핵심 아이디어비동기 처리의 본질은 단순합니다.오래 걸리는 작업 동안 Servlet Thread를 점유하지 않는다즉,요청을 받자마자 Thread를 반환하고작업은 다른 실행 단위에서 처리결과가 준비되면 응답을 재개하는 구조입니다.이 방식은 35편에서 봤던“Thread가 묶여 있는 문제”를 직접적으로 해결합니다.2. 동기 vs 비동기 ..

34편에서는 Spring Web 요청 흐름을 APM 지표와 연결해, 어디에서 시간이 소비되는지를 숫자로 확인하는 방법을 살펴봤습니다.이번 글에서는 그 다음 질문에 답해보겠습니다.“튜닝을 다 했는데도 왜 여기서 더 빨라지지 않을까?”이 질문의 답은 대부분 코드가 아니라 Servlet Thread 모델에 있습니다.1. Spring MVC는 어떤 실행 모델 위에 있을까Spring MVC는Servlet 기반 동기(Thread-per-request) 모델위에서 동작합니다.이 모델의 핵심은 다음 두 가지입니다.요청 하나당 스레드 하나요청 처리 동안 해당 스레드를 점유이 구조는:이해하기 쉽고디버깅이 직관적이며대부분의 CRUD 서비스에 잘 맞습니다하지만 동시에 명확한 성능 한계를 내포하고 있습니다.2. 실제 요청 처리..

33편에서는 Web 계층 장애를 요청 흐름 기준으로 분해해 어디서 문제가 생겼는지 찾는 방법을 살펴봤습니다.이번 글에서는 그 흐름을APM 지표와 1:1로 연결해 숫자로 병목을 증명하는 방법을 정리해보겠습니다.핵심은 단순합니다. APM의 각 구간이 Spring Web 요청 흐름의 어느 단계인지 정확히 매핑하는 것입니다.1. APM을 볼 때 가장 흔한 오해많은 경우 APM을 이렇게 봅니다.“응답 시간이 느리다”“DB는 빠른데 왜 느리지?”하지만 APM의 진짜 가치는“어디에서 시간이 쓰였는지”를 알려주는 데 있습니다.이를 위해서는 Spring Web 요청 흐름과 APM 구간을 머릿속에서 정확히 겹쳐야 합니다.2. 요청 흐름과 APM 구간 기본 매핑Spring Web 요청 흐름을 APM 구간과 매핑하면 대략 다..