챕터별 상세
배경: MLXP와 LLM Serving 최적화 기술
MLXP는 네이버의 머신러닝 플랫폼으로 학습, 서빙, 데이터 관리를 포함한 AI/ML 기능을 제공하며 GPU 자원을 Kubernetes 기반으로 관리한다. 최근 LLM의 중요도와 사용량이 증가함에 따라 추론 성능 최적화가 필수적이다. 이를 위해 KV-Cache 인지 라우팅을 통한 다이나믹 라우팅과 단일 노드 메모리 한계를 극복하는 멀티노드 추론 기술을 도입했다. 각 프로젝트 담당자가 최적화된 형태로 LLM을 배포할 수 있도록 클러스터 수준의 최적화를 목표로 한다.
KV-Cache는 LLM 추론 시 이전 토큰의 연산 결과를 저장하여 중복 연산을 방지하는 메모리 기법이다.
MLXP에서 LLM Serving 최적화를 반영한 구조
기존 서빙 구조는 클라이언트 요청이 Istio Gateway를 거쳐 Kubernetes Service를 통해 Pod로 전달되는 일반적인 방식이었다. 최적화를 위해 다이나믹 라우팅을 지원하는 Endpoint Picker와 멀티노드 추론을 위한 LeaderWorkerSet(LWS)을 도입했다. Endpoint Picker는 Pod의 KV-Cache 상태를 기반으로 요청을 최적의 Pod로 라우팅하여 성능을 개선한다. LWS는 여러 노드의 GPU를 하나의 모델처럼 사용하여 단일 노드 메모리를 초과하는 대형 모델을 서빙한다.
LeaderWorkerSet은 Kubernetes에서 분산 학습 및 추론을 위해 여러 Pod를 하나의 그룹으로 관리하는 리소스이다.
Troubleshooting: Istio sidecar와 ZMQ/RPC 통신
Istio sidecar가 Pod의 모든 인바운드/아웃바운드 트래픽을 가로채면서 ZMQ/RPC 통신이 차단되는 문제가 발생했다. Istio는 기본적으로 HTTP 트래픽을 파싱하려 시도하는데, ZMQ/RPC 프로토콜이 이와 충돌하여 연결이 즉시 거부되었다. 이를 해결하기 위해 Istio의 Sidecar CR을 사용하여 특정 포트만 인터셉트하거나 프로토콜을 TCP로 강제하여 Istio의 L7 파싱을 우회하도록 설정했다.
Istio는 서비스 메시 내 트래픽을 제어하기 위해 모든 포트를 가로채며, 프로토콜이 맞지 않으면 통신 오류가 발생할 수 있다.
Troubleshooting: Gateway 500 에러와 mTLS
Endpoint Picker가 Pod IP로 직접 메트릭을 스크래핑할 때 HTTP 500 에러가 발생했다. 이는 Istio의 PassthroughCluster를 통과하는 트래픽에 mTLS Identity가 부여되지 않아 AuthorizationPolicy에서 거부되었기 때문이다. 이를 해결하기 위해 ServiceEntry를 통해 Pod IP 대역을 서비스 메시 내부로 인식시키고, DestinationRule을 통해 mTLS를 적용하여 통신을 허용했다. 장기적으로는 메트릭 포트를 별도로 분리하는 구조를 고려하고 있다.
mTLS는 서비스 간 통신 시 양방향 인증을 통해 보안을 강화하는 프로토콜이다.
GroupDisruptionBudget(GDB) 도입
기존 Pod Disruption Budget(PDB)은 개별 Pod 단위로 중단을 관리하여 분산 추론 환경에서 그룹 단위의 안정성을 보장하지 못했다. LWS로 구성된 멀티노드 추론 환경에서는 그룹 내 Pod 하나만 중단되어도 전체 추론이 불가능해진다. 이를 해결하기 위해 그룹 단위의 중단을 관리하는 GroupDisruptionBudget(GDB) CRD를 도입했다. GDB는 그룹 내 최소 가용 Pod 수를 보장하여 노드 유지보수 시 전체 추론 서비스가 중단되는 것을 방지한다.
PDB는 Kubernetes에서 노드 유지보수 시 Pod의 가용성을 보장하기 위한 정책이다.
LWS를 Volcano로 스케줄링
분산 추론 환경에서는 모든 Pod가 동시에 실행되어야 모델이 정상적으로 로드된다. 기본 Kubernetes 스케줄러는 Pod를 개별적으로 배치하여 자원이 부족할 경우 일부 Pod만 실행되는 문제가 발생한다. 이를 위해 Volcano 스케줄러의 갱 스케줄링(Gang Scheduling) 기능을 도입했다. 모든 Pod가 자원을 확보할 수 있을 때만 일괄적으로 배포하여, 자원 부족 시 그룹 전체를 대기시켜 안정적인 분산 추론 환경을 구성했다.
Gang Scheduling은 분산 작업 시 모든 Pod가 동시에 실행 가능할 때만 작업을 시작하는 스케줄링 방식이다.
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 06. 11.수집 2026. 06. 11.출처 타입 YOUTUBE
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
