상어코딩

Spring Boot Actuator — Endpoint SPI와 Health·Metrics·Prometheus 내부

SpringBoot Actuator — Endpoint SPI와 Health·Metrics·Prometheus 내부들어가며운영 중인 서비스를 다루다 보면 결국 세 가지 질문으로 되돌아온다. 지금살아 있나, 트래픽을 받을 준비가 됐나, 무슨 일이 일어나고 있나. SpringBoot는 이 세 질문에 답할 수 있는 창구를 Actuator라는이름으로 묶어놓았다. spring-boot-starter-actuator 의존성 한줄이 /actuator 경로를 열고, 그 아래에 health,metrics, prometheus 같은 엔드포인트를걸어둔다. 다만 이 창구는 기본값이 의도적으로 소심하게 잡혀있다. 뭔가 설정해주지 않으면 web에는 health하나밖에 안 보인다.Actuator의 설계 중심은 @Endpoint라는..

Spring Boot Externalized Configuration — @ConfigurationProperties 바인딩과 Profile·spring.config.import

SpringBoot Externalized Configuration — @ConfigurationProperties 바인딩과Profile·spring.config.import들어가며9편에서 Environment가 어떻게 조립되는가 —PropertySource 평면 리스트에 누가 먼저 꽂히느냐로우선순위가 결정된다는 이야기를 했다. 이번 편은 그 이야기의 자매편이다.9편이 "조립의 원리"였다면, 이번은 Spring Boot가 실무에서 실제로제공하는 설정 주입 수단 전부를 기능별로 펼쳐 보는 쪽이다.application.yml, application-{profile}.yml,spring.config.import, 생성자 바인딩, Duration단위 파싱, @Validated 기동 검증 — 이름은 다들 들어봤지..

Environment와설정 조립: PropertySource / @Value / @ConfigurationProperties들어가며5편에서 @ConditionalOnProperty가 환경변수 한 줄 누락으로기능이 조용히 사라지는 이야기를 했다. 거기서 다뤘던 "환경변수 한 줄"의정체는 사실Environment.getProperty("app.feature.notification.enabled")한 번의 호출이다. 그런데 이 호출은 대체 누가,어디서, 어떤 순서로 값을 읽어오는가?application.yml에 쓴 값과--app.feature.notification.enabled=true CLI 인자와Kubernetes가 꽂아준 APP_FEATURE_NOTIFICATION_ENABLED환경변수가 동시에 있으면..

조건부빈 등록: @Conditional과 Auto-configuration의 뿌리들어가며spring-boot-starter-data-redis를 pom.xml에한 줄 추가하고 애플리케이션을 띄우면, 아무 것도 안 했는데RedisTemplate 빈이 생긴다. 그런데 내가 직접@Bean RedisTemplate를 정의하면, Boot가 만들던 빈은 조용히사라진다. 클래스패스에 spring-data-redis가 없으면 아예시도조차 안 한다 — 에러도 없고 경고도 없다. 겉보기에는 자동으로 보이는이 동작 전체가 @Conditional 하나와 그 파생어노테이션들 위에 올라가 있다.Spring Framework 4에서 도입된 @Conditional은 한 장의인터페이스(Condition)만 구현하면 "이 빈 정의를 등..

Kafka Consumer DX 리빌드 최최종: OOP를 지키며 다시 설계했고, duplicate 이벤트 경로까지 끝까지 수정했다들어가며시리즈를 여기까지 따라왔다면 이제 남는 질문은 하나다.그래서 진짜로 좋아졌는가이 질문에 답할 때 조심해야 할 게 있다.구조가 추상화됐다고 해서 무조건 좋아진 것은 아니다.추상화는 늘 비용이 있다.학습 비용디버깅 비용잘못 설계했을 때의 은닉 비용그래서 이번 글에서는"무엇이 실제로 좋아졌는가"와"어디서 멈춰야 했는가"를 같이 정리하려고 한다.1) 가장 큰 변화는 코드 길이가 아니라 변경 경험이었다이번 작업을 숫자로 거칠게 요약하면 이렇다.리팩터링 전에는 새 이벤트를 붙일 때 보통 아래를 다시 만져야 했다.consumer 본문payload 파싱metadata 검증eventTy..

Kafka Consumer DX 리빌드 3편: EventSpec와 Processor 중심 구조로 구현하기 (OOP, 디자인 패턴, Java 문법)들어가며앞선 글에서 데이터 소유 서비스와 프로젝션 소비 서비스의 경계를 먼저 정리했다.이제 남은 질문은 이것이다.그 경계를 코드로는 어떻게 표현할 것인가이번 작업에서 내가 제일 중요하게 본 기준은 단순했다.consumer에는 라우팅만 남긴다processor에는 이벤트별 스펙 선언만 남긴다새 이벤트를 추가할 때 수정 포인트를 최소화한다이 기준으로 밀어붙이다 보니,자연스럽게 몇 가지 OOP 원칙과 패턴이 코드에 들어갔다.이번 글에서는 그 구현 포인트를 정리해보려고 한다.1) 리팩터링 전의 전형적인 냄새리팩터링 전 consumer 코드는 대체로 이런 흐름을 반복하고 ..

Kafka Consumer DX 리빌드 1편: 왜 컨슈머를 다시 설계했는가들어가며이번 글은 돈모아 프로젝트에서 Kafka consumer 구조를 다시 설계하게 된 배경을 정리한 기록이다.이 글에서 말하는 DX는 IDE 자동완성이나 문법 편의만 의미하지 않는다.내가 여기서 말하는 DX는 아래 질문에 얼마나 빨리 답할 수 있는가에 가깝다.새 이벤트를 추가할 때 어디를 수정해야 하는가DIRECT와 INBOX 중 어떤 경로로 타는가이 이벤트는 누가 소유하고, 누가 소비하는가장애가 났을 때 어디서 복구해야 하는가돈모아는 크라우드펀딩, 일반 판매, 핫딜, 알림, 검색, 분석 대시보드, 미디어 워커까지 여러 서비스가 이벤트를 주고받는 구조다.이벤트를 안 쓸 수는 없었고, 결국 문제는 "이벤트를 얼마나 운영 가능한 방..