AI 워크로드 시대의 Spring: KServe·llm-d·DRA와 Spring AI (Spring 개발자를 위한 클라우드 표준 10)
Kubernetes가 AI 추론의 사실상 운영체제가 됐다. KServe·llm-d가 모델을 서빙하고 DRA가 GPU를 할당하는 클러스터에서 JVM은 모델 런타임이 아니라 그 모델을 호출하는 애플리케이션 층을 맡는다. Spring AI·LangChain4j의 자리와 시리즈 전체 지도를 정리하는 마지막 편.
Cloud Native
10개 기사컨테이너에서 쿠버네티스까지. 배포·운영·CNCF 생태계를 JVM 관점에서.
-
cloud-native 플랫폼 엔지니어링 기본 블록: Dapr·cert-manager·Backstage (Spring 개발자를 위한 클라우드 표준 9)
배포·관측·메시·스케일을 갖춰도 서비스가 늘면 pub/sub 연결·TLS 발급·서비스 문서를 서비스마다 다시 세우는 반복이 남는다. Dapr는 분산 시스템 기본기를 사이드카로, cert-manager는 TLS 발급·갱신을 자동으로, Backstage는 흩어진 서비스를 개발자 포털 하나로 묶어 이 반복을 없앤다.
-
cloud-native GitOps 입문: Argo CD와 Flux 비교 (Spring 개발자를 위한 클라우드 표준 8)
helm upgrade를 사람이 손으로 치는 한 클러스터의 실제 상태와 Git의 선언은 어긋난다. Git을 단일 진실원으로 두고 컨트롤러가 클러스터를 맞추는 GitOps 4원칙을 정리하고, CNCF Graduated인 Argo CD와 Flux를 Spring Boot 배포 관점에서 비교한다. 이미지 태그 자동화까지.
-
cloud-native Kubernetes 오토스케일링과 서버리스: KEDA·Knative와 JVM 콜드 스타트 (Spring 개발자를 위한 클라우드 표준 7)
HPA는 Kafka 컨슈머 랙을 보지 못한다. KEDA는 이벤트 지표로 파드를 0에서 늘리고, Knative는 트래픽이 없으면 0으로 줄인다. scale-to-zero가 노출하는 JVM 콜드 스타트를 GraalVM 네이티브, CRaC, AOT 캐시로 줄이는 길까지 다룬다.
-
cloud-native 서비스 메시 비교: Istio·Linkerd·Cilium과 JVM 사이드카 비용 (Spring 개발자를 위한 클라우드 표준 6)
재시도·회로 차단·mTLS를 서비스마다 코드로 박으면 같은 로직이 N번 복제된다. 서비스 메시는 이를 앱 밖 프록시로 내린다. Istio(Envoy·ambient), Linkerd(Rust 프록시), Cilium(eBPF)을 JVM 파드의 사이드카 오버헤드 관점에서 비교한다.
-
cloud-native Spring Boot 분산 추적: Micrometer Tracing과 OpenTelemetry (Spring 개발자를 위한 클라우드 표준 5)
서비스가 갈라지면 요청 하나가 어디서 끊겼는지 로그·메트릭만으로는 못 짚는다. Micrometer Tracing이 Observation에서 스팬을 만들고 OpenTelemetry가 표준 프로토콜(OTLP)과 Collector를 제공하는 구조를 Spring 접점 중심으로 다룬다.