2023-10-16-TIL

2023-10-16-TIL

Today I Learned

Observability with Spring Boot 3

관측 가능성(observability)은 시스템 밖으로 나오는 메트릭, 로그, 트레이스를 보고 내부에서 무슨 일이 일어나는지 알 수 있는 정도를 말한다. Spring 블로그의 Observability with Spring Boot 3는 Spring Boot 3에서 이 세 가지를 다루는 방식이 바뀐 점을 소개한다.

핵심은 Micrometer에 새로 들어온 Observation API다. 코드에서 관측하고 싶은 구간을 Observation으로 한 번 감싸면, ObservationRegistry에 등록한 핸들러들이 그 구간의 시작과 끝 이벤트에 반응해 타이머(메트릭), 스팬(트레이스), 로그를 각각 만든다. 계측 코드는 한 번만 쓰고 결과는 여러 신호로 나뉘는 구조다. 블로그 예제는 트레이스를 위해 Brave 브리지(micrometer-tracing-bridge-brave)와 Zipkin 리포터를 추가하고, 트레이스 ID가 로그에 자동으로 들어가 로그와 트레이스를 연결할 수 있음을 보여 준다.

• https://spring.io/blog/2022/10/12/observability-with-spring-boot-3/
• https://www.baeldung.com/spring-boot-3-observability
• https://tanzu.vmware.com/developer/guides/observability-reactive-spring-boot-3/

---

Micrometer vs Spring Cloud Sleuth

Spring Boot 2 시절 분산 추적은 Spring Cloud Sleuth가 맡았다. Sleuth 저장소는 Sleuth가 Spring Boot 3.x부터 동작하지 않고, 마지막으로 지원하는 Spring Boot 메이저 버전은 2.x라고 경고한다. 핵심 기능은 Micrometer Tracing 프로젝트로 옮겨졌고, 계측 코드는 Micrometer와 각 프로젝트로 흩어졌다.

그래서 Boot 3로 올리면 Sleuth 의존성을 걷어 내고 micrometer-tracing과 트레이서 브리지(Brave 또는 OpenTelemetry), 그리고 Zipkin 같은 수집기로 보내는 리포터를 추가해야 한다. 링크된 글들은 이 조합으로 WebFlux와 단일 애플리케이션에 트레이싱을 붙이는 예제다.

• https://betterprogramming.pub/tracing-in-spring-boot-3-webflux-d432d0c78d3e
• https://stackoverflow.com/questions/72406352/spring-boot-3-micrometer-tracing-example
• https://blog.stackademic.com/adding-micrometer-tracing-to-spring-boot-3-with-brave-zipkin-31cd40977ac3
• https://swathisprasad.medium.com/micrometer-tracing-with-spring-boot-3-in-a-monolithic-application-baa655fa8d8f
• https://amithkumarg.medium.com/distributed-tracing-for-spring-boot-3x-app-using-micrometer-brave-and-zipkin-a43fc107bff4
• https://spring.io/projects/spring-cloud-sleuth

---

Log System

29CM의 로그 수집 시스템 소개 글은 쿠버네티스 환경의 로그 파이프라인 사례다. 기존 구성은 서비스마다 사이드카로 붙인 Fluentd가 Fluentd Aggregator로 로그를 보내고, Aggregator가 Elasticsearch에 바로 적재하는 EFK 구조였다. 글에 따르면 Elasticsearch 디스크가 부족해 적재가 실패하자 그 시간 동안의 로그가 유실됐다. 반면 중간에 Kafka를 둔 새 파이프라인에서는 유실이 없었다. 저장소 앞에 버퍼 역할을 하는 메시지 큐를 두면 저장소 장애가 곧 로그 유실로 이어지지 않는다는 점이 이 사례의 요지다.

• https://medium.com/29cm/29cm-%EB%A1%9C%EA%B7%B8-%EC%88%98%EC%A7%91-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%86%8C%EA%B0%9C-e7955d7deec6

---

Kubernetes Metrics Server

metrics-server README에 따르면 Metrics Server는 각 노드의 kubelet에서 CPU와 메모리 사용량을 모아 쿠버네티스 API 서버의 Metrics API로 노출한다. Horizontal Pod Autoscaler와 Vertical Pod Autoscaler가 이 값을 보고 파드 수나 리소스 요청량을 조절하고, kubectl top도 같은 API를 쓴다. README는 수집 주기를 15초로 적고, Metrics Server는 오토스케일링 전용이니 모니터링 시스템의 데이터 원천으로 쓰지 말라고 분명히 한다. 모니터링에는 Prometheus 같은 별도 솔루션을 쓰라고 안내한다.

로그는 별개 문제다. 쿠버네티스 로깅 아키텍처 문서는 로그가 노드나 파드와 독립된 저장소와 수명 주기를 가져야 한다고 보고, 이를 클러스터 수준 로깅이라 부른다. 쿠버네티스는 이를 기본으로 제공하지 않으므로 노드마다 로깅 에이전트를 두거나 사이드카 컨테이너를 붙이는 방식으로 구성한다.

• https://github.com/kubernetes-sigs/metrics-server
• https://kubernetes.io/docs/concepts/cluster-administration/logging/

---

Kubetail

kubetail은 여러 파드의 로그를 한 스트림으로 모아 따라가는(tail/follow) Bash 스크립트다. README는 kubectl logs -f를 여러 파드에 한꺼번에 실행하는 것과 같다고 설명한다. 레플리카가 여러 개인 Deployment에서 요청이 어느 파드로 갔는지 모를 때 로그를 한 화면에서 보기 편하다.

• https://github.com/johanhaleby/kubetail