Spring Boot Admin 2.x 마이그레이션
1. Spring Boot Admin 2.x 업그레이드의 함정
MSA(마이크로서비스 아키텍처) 기반 프로젝트에서 수십 개의 백엔드 인스턴스 헬스 체크(Health Check)와 상태를 모니터링하기 위해 Spring Boot Admin (SBA)을 적극 도입해 활용했습니다. 서비스 규모가 커짐에 따라 Spring Boot 버전을 올리면서 내부 SBA 서버 역시 1.x 버전에서 2.x 버전으로 메이저 업그레이드를 단행해야 했습니다. 그러나 업그레이드 직후 슬랙(Slack)이나 사내 메신저로 헬스 상태 알림을 보내주는 커스텀 Notifier 모듈의 컴파일 에러가 발생했습니다.
원인 파악 (핵심 개념)
Spring Boot Admin 2.x부터는 코어 도메인 로직이 전면 리팩토링되면서, 클라이언트 앱을 지칭하던 핵심 객체 및 네이밍이 변경되었습니다.
- [AS-IS] 1.x: 알림을 발생하는 주체를
Application단위로 취급 - [TO-BE] 2.x: 컨테이너 스케일 아웃이 잦은 클라우드 네이티브 환경에 맞춰 단일 앱이 아닌, 실행 중인 개별
Instance단위로 도메인 네이밍이 세분화됨
이에 따라 기존에 알림 훅을 잡기 위해 상속받아 구현했던 AbstractStatusChangeNotifier 내부 인수의 의존성 클래스들이 Application에서 Instance 패키지로 싹 물갈이되었습니다.
3. 커스텀 Notifier 코드 마이그레이션 및 구현
SBA 코어 저장소의 1.x -> 2.x 마이그레이션 커밋 내역을 분석하여 사내 커스텀 Notifier 코드의 의존성(import)과 파라미터를 전부 치환(Refactoring)해야 정상 작동합니다.
| 변경 전 (SBA 1.x) | 변경 후 (SBA 2.x) |
|---|---|
de.codecentric.boot.admin.model.Application | de.codecentric.boot.admin.server.domain.entities.Instance |
doNotify(ClientApplicationEvent event) | doNotify(InstanceEvent event, Instance instance) |
참고 (SBA 2.x 마이그레이션 단서가 된 핵심 커밋):
4. 마이그레이션 적용 결과
도메인-주도 설계(DDD) 관점에서 Application 이라는 모호한 단어를 버리고 Instance 로 구체화한 오픈소스 메인테이너의 결단은 기술적으로 아주 올바르다고 느꼈습니다. 덕분에 K8s 기반에서 파드(Pod)가 다중으로 확장될 때, 각각의 컨테이너 ‘인스턴스’별 헬스 체크 로직을 훨씬 깔끔하게 디자인할 수 있는 계기가 되었습니다. 메이저 업그레이드 전에는 언제나 Release Note와 Migration Guide를 정독하는 것이 삽질을 줄이는 최고의 지름길임을 다시 한번 상기했습니다.