MLXP: Kubernetes LLM 서빙 최적화 기술 도입기 | AI Trends

NAVER D2AI/ML조회 1회

MLXP: Kubernetes LLM 서빙 최적화 기술 도입기

Kubernetes 기반 LLM 서빙 플랫폼 MLXP를 운영하며 겪은 Istio, 스케줄링, Pod 보호 정책 관련 기술적 난제와 해결책을 공유한다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

핵심 요약

LLM 서빙 최적화를 위해 도입한 기술들이 기존 인프라와 충돌할 때, 서비스 메시와 스케줄러 설정을 어떻게 조정하여 안정성을 확보했는지 실무 사례를 제시한다.

배경

네이버의 ML 플랫폼인 MLXP에서 LLM 서빙 최적화 기술을 도입하며 발생한 인프라 스택 간의 충돌 문제를 다룬다.

대상 독자

Kubernetes 기반 GPU 워크로드 운영자 및 MLOps/Infra 엔지니어

의미 / 영향

Kubernetes 환경에서 LLM 서빙을 운영할 때 발생하는 인프라 스택 간의 복잡한 충돌 문제를 해결하는 구체적인 아키텍처 패턴을 제시한다. 이는 대규모 LLM 인프라 운영 시 안정성을 확보하고 운영 효율을 높이는 데 기여한다.

챕터별 상세

01:07

배경: MLXP와 LLM Serving 최적화 기술

MLXP는 네이버의 머신러닝 플랫폼으로 학습, 서빙, 데이터 관리를 포함한 AI/ML 기능을 제공하며 GPU 자원을 Kubernetes 기반으로 관리한다. 최근 LLM의 중요도와 사용량이 증가함에 따라 추론 성능 최적화가 필수적이다. 이를 위해 KV-Cache 인지 라우팅을 통한 다이나믹 라우팅과 단일 노드 메모리 한계를 극복하는 멀티노드 추론 기술을 도입했다. 각 프로젝트 담당자가 최적화된 형태로 LLM을 배포할 수 있도록 클러스터 수준의 최적화를 목표로 한다.

KV-Cache는 LLM 추론 시 이전 토큰의 연산 결과를 저장하여 중복 연산을 방지하는 메모리 기법이다.

05:05

MLXP에서 LLM Serving 최적화를 반영한 구조

기존 서빙 구조는 클라이언트 요청이 Istio Gateway를 거쳐 Kubernetes Service를 통해 Pod로 전달되는 일반적인 방식이었다. 최적화를 위해 다이나믹 라우팅을 지원하는 Endpoint Picker와 멀티노드 추론을 위한 LeaderWorkerSet(LWS)을 도입했다. Endpoint Picker는 Pod의 KV-Cache 상태를 기반으로 요청을 최적의 Pod로 라우팅하여 성능을 개선한다. LWS는 여러 노드의 GPU를 하나의 모델처럼 사용하여 단일 노드 메모리를 초과하는 대형 모델을 서빙한다.

LeaderWorkerSet은 Kubernetes에서 분산 학습 및 추론을 위해 여러 Pod를 하나의 그룹으로 관리하는 리소스이다.

13:09

Troubleshooting: Istio sidecar와 ZMQ/RPC 통신

Istio sidecar가 Pod의 모든 인바운드/아웃바운드 트래픽을 가로채면서 ZMQ/RPC 통신이 차단되는 문제가 발생했다. Istio는 기본적으로 HTTP 트래픽을 파싱하려 시도하는데, ZMQ/RPC 프로토콜이 이와 충돌하여 연결이 즉시 거부되었다. 이를 해결하기 위해 Istio의 Sidecar CR을 사용하여 특정 포트만 인터셉트하거나 프로토콜을 TCP로 강제하여 Istio의 L7 파싱을 우회하도록 설정했다.

Istio는 서비스 메시 내 트래픽을 제어하기 위해 모든 포트를 가로채며, 프로토콜이 맞지 않으면 통신 오류가 발생할 수 있다.

21:53

Troubleshooting: Gateway 500 에러와 mTLS

Endpoint Picker가 Pod IP로 직접 메트릭을 스크래핑할 때 HTTP 500 에러가 발생했다. 이는 Istio의 PassthroughCluster를 통과하는 트래픽에 mTLS Identity가 부여되지 않아 AuthorizationPolicy에서 거부되었기 때문이다. 이를 해결하기 위해 ServiceEntry를 통해 Pod IP 대역을 서비스 메시 내부로 인식시키고, DestinationRule을 통해 mTLS를 적용하여 통신을 허용했다. 장기적으로는 메트릭 포트를 별도로 분리하는 구조를 고려하고 있다.

mTLS는 서비스 간 통신 시 양방향 인증을 통해 보안을 강화하는 프로토콜이다.

27:41

GroupDisruptionBudget(GDB) 도입

기존 Pod Disruption Budget(PDB)은 개별 Pod 단위로 중단을 관리하여 분산 추론 환경에서 그룹 단위의 안정성을 보장하지 못했다. LWS로 구성된 멀티노드 추론 환경에서는 그룹 내 Pod 하나만 중단되어도 전체 추론이 불가능해진다. 이를 해결하기 위해 그룹 단위의 중단을 관리하는 GroupDisruptionBudget(GDB) CRD를 도입했다. GDB는 그룹 내 최소 가용 Pod 수를 보장하여 노드 유지보수 시 전체 추론 서비스가 중단되는 것을 방지한다.

PDB는 Kubernetes에서 노드 유지보수 시 Pod의 가용성을 보장하기 위한 정책이다.

29:14

LWS를 Volcano로 스케줄링

분산 추론 환경에서는 모든 Pod가 동시에 실행되어야 모델이 정상적으로 로드된다. 기본 Kubernetes 스케줄러는 Pod를 개별적으로 배치하여 자원이 부족할 경우 일부 Pod만 실행되는 문제가 발생한다. 이를 위해 Volcano 스케줄러의 갱 스케줄링(Gang Scheduling) 기능을 도입했다. 모든 Pod가 자원을 확보할 수 있을 때만 일괄적으로 배포하여, 자원 부족 시 그룹 전체를 대기시켜 안정적인 분산 추론 환경을 구성했다.

Gang Scheduling은 분산 작업 시 모든 Pod가 동시에 실행 가능할 때만 작업을 시작하는 스케줄링 방식이다.

실무 Takeaway

Istio 환경에서 ZMQ/RPC 등 비-HTTP 프로토콜을 사용할 경우, Sidecar CR을 통해 프로토콜을 TCP로 강제하거나 특정 포트를 인터셉트 대상에서 제외해야 통신 오류를 방지할 수 있다.
분산 추론 환경에서 Pod IP로 직접 메트릭을 수집할 때는 Istio의 mTLS 정책과 충돌할 수 있으므로, ServiceEntry와 DestinationRule을 활용해 Identity를 부여해야 한다.
분산 모델 서빙 시 Pod 개별 Eviction으로 인한 서비스 중단을 막으려면, PDB 대신 그룹 단위의 가용성을 보장하는 GroupDisruptionBudget(GDB)을 도입해야 한다.
분산 추론 Pod의 동시 실행을 보장하려면 기본 스케줄러 대신 Volcano와 같은 갱 스케줄러를 사용하여 자원 확보 시 일괄 배포되도록 구성해야 한다.

언급된 리소스

문서KServe

문서Istio

AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 06. 11.수집 2026. 06. 11.출처 타입 YOUTUBE

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.