쿠버네티스 도입 이후, 우버가 운영 품질을 확보하는 방식
퇴근길, 택시 호출 버튼을 누르는 순간 우버를 사용하는 수천 명의 사용자가 동시에 위치 정보를 전송하고, 인근 차량과의 매칭 요청이 쏟아집니다. 단 몇 분 안에 택시가 배정되지 않으면, 사용자는 앱을 닫고 경쟁 서비스로 이탈하게 됩니다. 실시간 서비스에서 지연은 곧 고객 이탈이자 매출 손실입니다.
택시 호출, 음식 배달, 실시간 결제처럼 즉각적인 응답이 생명인 서비스가 늘어나면서 컨테이너 기반 인프라는 이제 선택이 아닌 필수가 되었습니다. CNCF 설문조사에 따르면, 응답 기업의 80% 이상이 실제 서비스 환경에서 쿠버네티스(Kubernetes)를 운영 중이며, 13%는 시범 운영 또는 평가 중인 것으로 나타났습니다. 쿠버네티스는 수백, 수천 개의 컨테이너화된 애플리케이션의 배포·확장·복구를 자동화하는 오케스트레이션 플랫폼입니다. 배포, 확장, 복구까지 자동화되면서 운영 부담은 크게 줄었습니다. 하지만 새로운 질문이 생겼습니다. 자동화된 환경에서 서비스 품질은 누가, 어떻게 책임질까요?
우버는 현재 4,500개 이상의 마이크로서비스를 운영하며 주 100,000회 이상 배포를 진행합니다. 2024년, Apache Mesos 기반 플랫폼에서 쿠버네티스로 전면 마이그레이션을 완료하며 50개 이상의 쿠버네티스 클러스터를 구축했습니다. 흥미로운 점은 우버가 쿠버네티스 마이그레이션을 준비하며 먼저 모니터링 체계와 운영 품질 기준을 정립했다는 것입니다. 쿠버네티스가 배포·확장·복구를 자동화해주지만, 서비스 품질은 별도로 관찰해야 했기 때문입니다. 이 글에서는 쿠버네티스 환경에서 운영 품질을 확보하기 위한 모니터링 도입 기준을 살펴보겠습니다.
1. 쿠버네티스가 만든 배포 자동화 환경
쿠버네티스의 핵심은 컨테이너 운영을 자동화하는 데 있습니다. 우버가 주 100,000회 이상 마이크로서비스를 배포하면서도 안정적으로 서비스를 유지할 수 있는 것도 쿠버네티스 환경 덕분입니다. 컨테이너는 애플리케이션과 실행 환경을 하나로 묶어 어디서든 동일하게 실행할 수 있게 해주는 기술입니다.
마이크로서비스 아키텍처가 확산되면서 수십, 수백 개의 컨테이너를 동시에 운영해야 하는 상황이 일반화되었고, 이를 효율적으로 관리할 수 있는 오케스트레이션 기술의 중요성이 커졌습니다.
컨테이너 기술이 보편화되면서 쿠버네티스와 도커(Docker)의 개념 차이가 자주 언급됩니다. 둘 다 컨테이너를 다루지만 역할이 다릅니다. 도커가 컨테이너를 '만들고 실행'한다면, 쿠버네티스는 그 컨테이너들을 '대규모로 운영'합니다.
위 그림처럼 쿠버네티스는 도커 등으로 만든 다수의 컨테이너를 여러 노드에 자동으로 배치하고 관리합니다. 덕분에 수천 개의 컨테이너를 자동으로 배치하고, 장애가 나면 스스로 복구할 수 있죠. 하지만 이 자동화에는 포함되지 않는 영역이 있습니다.
2. 쿠버네티스는 품질까지 관리해주지 않는다
쿠버네티스는 컨테이너가 ‘실행 중인지’는 알려주지만, ‘지연 없이 제대로 작동하는지’는 알려주지 않습니다.
예를 들어 트래픽이 증가하면 쿠버네티스는 파드(Pod)를 자동으로 늘립니다. 하지만 ‘늘어난 파드가 실제로 요청을 잘 처리하는지’, ‘특정 파드에서 응답 지연이 발생하는지’는 알려주지 않습니다. 실제로 트래픽 급증 시 기존 파드는 과부하 상태인데, 새로 생성된 파드는 초기화 지연으로 요청을 받지 못하는 상황이 발생할 수 있습니다. 서비스 응답이 느려지는 건 체감하지만, 어느 파드가 문제인지 특정하지 못하는 거죠. 확장은 자동이지만, 서비스 품질은 여전히 운영자의 몫입니다.
우버도 쿠버네티스 전환 과정에서 이 한계를 경험했습니다. 기존 모니터링 도구로는 리소스 단편화로 인한 파드 배치 실패, 동일 노드 내 다른 파드 간 리소스 경합으로 인한 성능 저하, 잦은 파드 재시작의 영향을 파악하기 어려웠습니다. 결국 우버는 클러스터 건강 상태와 성능을 상세히 추적하는 자체 배포 옵저버빌리티 도구를 구축했습니다.
문제는 쿠버네티스 환경이 동적(Dynamic)이라는 점입니다. 파드는 트래픽에 따라 자동으로 늘어나거나 줄어들고, 장애가 발생하면 다른 노드에서 재생성됩니다. 즉, 모니터링 대상이 계속 변동될 수 있습니다. 마이크로서비스 아키텍처에서는 하나의 서비스 지연이 전체 시스템에 연쇄적으로 영향을 미칠 수 있어 복잡성은 더욱 커집니다.
전통적인 서버 모니터링은 고정된 서버의 CPU, 메모리를 확인하는 방식이었습니다. 하지만 쿠버네티스에서는 모니터링 대상 자체가 고정되어 있지 않고, 데이터 소스도 여러 노드에 분산되어 있어 기존 방식이 통하지 않습니다. 개별 서버가 아닌 클러스터 전체를 한눈에 파악하고, 동적으로 변화하는 워크로드를 추적할 수 있는 통합 모니터링 체계가 필요한 이유입니다.
자동화된 운영 환경에서도 장애는 발생합니다. 쿠버네티스가 해결해주지 않는 것, 결국 모니터링으로 채워야 합니다.
3. 운영 안정성을 지키는 모니터링 4가지 계층
클러스터 전체 상태를 파악하고 서비스 지연의 원인을 추적하려면, 계층별로 나눠서 접근해야 합니다. 쿠버네티스 모니터링은 크게 네 가지 계층으로 나눌 수 있습니다. 서비스 지연 등 장애가 발생하면 클러스터 전체 상태를 먼저 확인하고, 컨트롤 플레인 → 노드 → 파드·애플리케이션 순서로 원인을 추적합니다. 각 계층에서 확인해야 할 핵심 지표가 다르기 때문입니다.
3-1. 클러스터 메트릭: 전체 클러스터 상태
클러스터 메트릭(Cluster Metrics)은 쿠버네티스 클러스터의 전반적인 건강 상태를 추적합니다. 개별 노드나 파드가 아닌, 클러스터 전체를 조감도처럼 바라보는 관점입니다. 주로 다음 지표를 확인합니다.
- 노드 전체의 리소스 사용량 (CPU, 메모리, 디스크)
- API 서버 등 클러스터 컴포넌트의 가용성과 성능
클러스터 레벨에서 이상 징후가 감지되면, 어느 노드 또는 어느 파드에서 문제가 발생했는지 하위 계층으로 drill-down하여 원인을 추적합니다.
3-2. 컨트롤 플레인 메트릭: 클러스터의 '두뇌’
컨트롤 플레인 메트릭(Control Plane Metrics)은 클러스터의 원활한 상태를 유지하는 핵심 컴포넌트이며, 이들의 상태를 보여주는 지표입니다. 쉽게 말해 쿠버네티스의 '두뇌' 역할을 합니다. 컨트롤 플레인은 다음 요소들로 구성됩니다.
구성 요소 | 역할 | 주요 메트릭 |
etcd | 클러스터의 모든 데이터를 저장하는 키-값 저장소 | etcd 지연 시간 |
kube-scheduler | 새로운 파드를 적절한 노드에 배치 | 스케줄링 대기 시간 |
kube-controller-manager | 클러스터 상태를 감시하고 원하는 상태로 유지 | 워크큐(Work Queue) 길이 |
kube-apiserver | 모든 요청의 진입점, 클러스터 상태 조회 및 변경 처리 | API 응답 시간 |
컨트롤 플레인에 문제가 생기면 새로운 파드 배포, 스케일링, 장애 복구 등 모든 자동화 기능이 멈출 수 있습니다. 스케줄러, 컨트롤러 매니저, API 서버 관련 메트릭을 모니터링하면 클러스터 전체에 영향을 주기 전에 이슈를 탐지할 수 있습니다.
3-3. 노드 메트릭: 개별 워커 노드 상태
노드 메트릭(Node Metrics)은 클러스터 내 개별 노드의 성능을 집중적으로 봅니다. 파드가 실제로 실행되는 물리적/가상 서버의 상태를 확인하는 계층입니다. 다음 항목을 중점적으로 모니터링합니다.
- CPU, 메모리, 네트워크 대역폭, 디스크 공간 사용률
- Container Runtime Health : 컨테이너 런타임(containerd 등) 상태
- kubelet: 각 노드에서 파드가 정상 실행되도록 관리하는 에이전트
- kube-proxy: 파드 간 네트워크 통신을 담당하는 프록시
특정 노드의 리소스가 부족하면 해당 노드에 배치된 모든 파드 성능에 영향을 미칩니다. 노드별 리소스 사용률을 추적하면 병목 구간을 사전에 파악할 수 있습니다.
3-4. 파드 및 애플리케이션 메트릭: 실제 워크로드
파드(Pod)는 쿠버네티스에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 포함합니다. 사용자 요청을 실제로 처리하는 계층이므로 서비스 품질과 직결됩니다. 다음 지표를 통해 워크로드 상태를 파악합니다.
- 파드·컨테이너 메트릭: 상태(Running, Pending, Failed), 재시작 횟수, CPU·메모리 사용량
- 애플리케이션 메트릭: 응답 시간(Latency), 에러율(Error Rate), 처리량(Throughput)
응답 시간이 갑자기 늘어나면서 에러율도 함께 상승한다면, 하위 서비스의 병목이나 노드 리소스 부족을 의심해야 합니다.
위 4가지 계층의 데이터를 연계해서 분석해야 장애의 근본 원인을 빠르게 파악할 수 있습니다.
4. 운영 품질을 완성하는 쿠버네티스 모니터링 전략
앞서 제시한 4가지 계층을 효과적으로 연계 분석하려면 어떤 조건이 필요할까요? 먼저, 모니터링 도입 시점을 판단해야 합니다. 다음 상황 중 하나라도 해당된다면 통합 모니터링 체계 구축을 검토할 시점입니다.
- 장애 원인 파악에 10분 이상 걸린다.
- 파드가 어느 노드에서 실행 중인지 즉시 확인하기 어렵다.
- 서비스 간 연쇄 장애가 발생한 적 있다.
이 문제들의 공통 원인은 ‘운영 가시성의 부재’입니다. 여기서 필요한 것이 옵저버빌리티(Observability)입니다. 메트릭, 로그, 트레이스를 통해 서버 장애뿐만 아니라, 특정 구간 지연 등 문제의 원인까지 파악할 수 있어야 합니다.
옵저버빌리티(Observability)란? 시스템의 외부 출력만으로 내부 상태를 이해할 수 있는 정도를 의미합니다. 모니터링이 '무엇이 잘못됐는지'를 알려준다면, 옵저버빌리티는 '왜 잘못됐는지'까지 확인 가능합니다.
장애 대응이 빠른 조직일수록 클러스터-노드-파드 계층을 하나의 흐름으로 연계 분석합니다. 우버 역시 이러한 통합 모니터링 체계를 구축하여 대규모 쿠버네티스 환경을 안정적으로 운영하고 있습니다. 국내에서는 exemONE과 같은 풀스택 옵저버빌리티(Full-stack Observability) 솔루션이 클러스터 토폴로지부터 애플리케이션 트랜잭션까지 하나의 화면에서 연계해 분석할 수 있는 플랫폼을 제공합니다.
특정 서비스에서 응답 지연이 발생했을 때, exemONE의 분석 흐름은 다음과 같습니다.
- 먼저 클러스터 토폴로지에서 해당 파드의 위치를 확인합니다.
- 이어서 해당 노드의 리소스 사용률을 점검하고, 파드 재시작 이력이나 이벤트 로그를 추적합니다.
- 마지막으로 애플리케이션 레벨에서 어떤 트랜잭션이 지연되었는지까지 연계 분석할 수 있습니다.
단순히 지표를 수집하는 것이 아니라, 장애가 비즈니스에 미치는 영향을 즉시 파악하고 대응할 수 있습니다.
운영 자동화는 쿠버네티스가, 운영 품질은 모니터링이 책임집니다. 결국 쿠버네티스 환경에서 서비스 품질은 자동화가 아니라, 문제를 얼마나 빠르게 이해하고 대응할 수 있는가에서 결정됩니다.
쿠버네티스 환경, 운영 품질을 확보하는 법
출처
CNCF Research Reveals How Cloud Native Technology is Reshaping Global Business and Innovation - CNCF (2025.04)Migrating Uber's Compute Platform to Kubernetes: A Technical Journey - Uber Engineering Blog (2025.04)Up: Portable Microservices Ready for the Cloud - Uber Engineering Blog (2023.07)
함께 보면 좋은 아티클
