Uber의 쿠버네티스 이관, 그 기술 여정의 전모
왜 쿠버네티스로 전환했는가?
Uber는 수년간 자체 개발한 클러스터 관리 시스템(M3)을 사용해 왔습니다. 하지만 다음과 같은 한계에 직면하게 됩니다:
- 확장성의 한계: 수천 개의 마이크로서비스와 수십만 개의 컨테이너를 운영하며, 기존 M3는 점점 복잡성과 유지 비용이 증가.
- 생태계 고립: 쿠버네티스와 같은 오픈소스 생태계를 활용할 수 없고, 내부 기술 인력에 의존.
- 운영 효율 문제: CI/CD 파이프라인, 리소스 스케줄링, 멀티테넌시 운영이 비효율적.
이에 따라 Uber는 Kubernetes 중심의 현대화된 컴퓨팅 플랫폼으로의 전환을 결정했습니다.
어떻게 마이그레이션했는가?
1. 공존 전략
기존 M3와 새로운 Kubernetes 클러스터가 일정 기간 공존할 수 있도록 설계. 서비스 단위로 점진적 이전.
2. 셀이란 개념 도입
Uber는 단일 글로벌 클러스터가 아니라 ‘Cell’이라는 독립된 K8s 클러스터를 여러 개 운영. 각 Cell은 물리적 데이터센터 혹은 지역적으로 독립되어 있어 장애 전파를 최소화함.
3. 통합된 관리 스택 구축
- Kubernetes 기반 오케스트레이션
- Envoy 기반의 서비스 메시
- gRPC 기반 통신 구조
- CI/CD 파이프라인 자동화
이로 인해 운영 유연성과 디버깅 효율성이 크게 향상되었습니다.
기술적으로 마주한 도전 과제
- 컨테이너 시작 지연(Latency): 고속 배포가 필수적인 Uber에겐 컨테이너 시작 속도가 민감한 이슈.
- 리소스 간섭 관리: 다수의 팀과 서비스가 동일 노드를 사용하는 멀티테넌시 환경에서의 QoS 보장.
- 네트워크 정책: Envoy, CNI 설정, 네임스페이스 간 통신 규제 등 고도화된 네트워크 구성 필요.
Uber의 교훈과 인사이트
- 플랫폼 이전은 단순한 기술 교체가 아닌 조직 문화의 변화
- 자체 기술보다 오픈소스 생태계 활용이 장기적으로 효율적
- 모놀리스를 유지한 채 부분 전환 전략이 리스크를 줄임
- 모든 것이 코드화된 환경에서 디버깅, 테스트, 롤백이 용이
결론
Uber는 세계에서 가장 복잡한 실시간 시스템 중 하나를 오픈소스 기반의 클라우드 네이티브 아키텍처로 성공적으로 전환했습니다. 이 사례는 단순히 규모의 문제가 아니라, 어떻게 기술적 채택과 조직적 전환을 병행할 것인가에 대한 현실적인 전략을 제시합니다.
이제 쿠버네티스는 선택이 아니라 전략이다.
Uber의 사례는 그것을 명확히 증명한다.
[출처] Uber의 블로그