- "Up: Portable Microservices Ready for the Cloud"
- Uber는 4,500명의 엔지니어와 수많은 자동 시스템이 매주 4,000회 이상 4,500개의 Stateless 마이크로서비스를 배포
- 이 서비스들은 전 세계에서 독립적으로 일하는 수백 개의 개별 팀에 의해 개발, 배포 및 운영됨
- 서비스는 크기, 모양, 기능이 다양하여, 일부는 작고 내부 작업에 사용되며, 일부는 크고 대규모 실시간 계산에 사용
Uber의 Stateless 서비스 역사
- 2014년에 Uber는 Python으로 작성된 Monolith에 한대의 PostgreSQL DB에 데이터를 저장
- 성장하면서 엔지니어를 충원하고 Microservice 아키텍처로 전환
- 서비스가 많아지면서 우버는 µDeploy 라는 도구를 만들어서 코드를 중앙에서 대규모로 배포
- 모든 Stateless 서비스를 컨테이너화하고, 호스트 관리 및 배치를 추상화
- 인프라 그룹이 비즈니스 단위 마이크로서비스와 독립적으로 호스트 플릿을 관리 가능하게 했음
- 하지만 서비스 관리 및 배치는 여전히 수작업
- 우버의 인프라는 영역(Zone) 들의 그룹이 지역(Region)을 형성하는 모델을 따름
- 리젼 안의 영역 간 레이턴시는 충분히 짧아서 같은 지역 내의 서비스간에는 동기식 통신이 효율적
- 각 영역은 우버가 소유한 머신들의 클러스터이거나 퍼블릭 클라우드 업체의 것일수도 있지만, 특정 영역 자체는 항상 단일 업체로만 가능
- 일반적으로 모든 마이크로서비스는 같은 지역 내에 있는 한, 지연 시간 문제 없이 다른 서비스를 호출할 수 있어야 함
- µDeploy는 엔지니어가 여전히 가용 영역(Availability Zone) 수준에서 물리적 배치를 관리해야 했기 때문에 워크로드의 지리적 배치가 시스템에서 중앙 집중화되지 않았음
- 즉, 서비스 엔지니어는 온프레미스 영역에서 서비스를 실행할지 여부뿐만 아니라 어떤 특정 영역에서 실행할지 여부도 여전히 결정해야 했음
- 온프레미스 데이터 센터를 운영하면서 칩 부족과 공급망 문제로 인해 리드 타임이 길어짐
- 2023년 2월 13일, Uber는 공급망 문제에 대한 노출을 줄이고 다각화하기 위해 오라클 및 Google과 파트너십을 맺음
- 비즈니스를 지원하는 수백 개의 다양한 서비스를 개발하는 수천 명의 Uber 엔지니어로부터 "기본 인프라를 추상화할 수 있는 시스템"을 갖추지 않고서는 이 전략을 실행하는 것이 불가능
Uber를 클라우드로 이관하기 위해 준비하기
- 비즈니스를 계속 운영하면서 4,500개의 상태 비저장 서비스를 클라우드로 마이그레이션하려면 엄청난 양의 조정과 노력이 필요
- 이 작업은 오류가 발생하기 쉽고 수동으로 조율된 노력을 통해 관리하기가 거의 불가능하다는 것을 처음부터 분명히 알 수 있었음
- Stateless 마이크로서비스의 유지 및 관리를 대규모로 수행하려면 사람의 개입 없이 중앙 집중식 배포 시스템에서 자동으로 관리할 수 있도록 서비스를 혁신해야 했음
- Stateless 를 넘어서 Portability로
- Region과 Zone에 대한 모델을 기반으로 "이식성(Portability)"이라는 개념을 생각해냄
- 이식성이란 지역 내의 모든 영역에서 실행할 수 있고, 사람의 개입 없이 인프라 플랫폼에 의해 자동으로 새로운 영역으로 이동할 수 있는 서비스를 말함
- 퍼블릭 클라우드 제공업체 간 이동은 물론, 온프레미스 영역 안팎에서의 이동도 포함
- 일부 서비스는 영역 구성과 영역 리소스의 선호도에 따라 달라지기 때문에 일반적으로 이식성을 가지고 있지 않았음
- 클라우드로의 자동 마이그레이션을 수행하기 위해서는 모든 서비스에 대해 이식성을 보유하도록 해야했음
Uber를 Portable 하게 만들기
- 2021년과 2022년에 걸쳐 모든 서비스가 이식성이 있는지 확인하기 위해 엔지니어링 전반에 걸쳐 프로그램을 운영
- 많은 경우 코드 검사를 통해 코드의 문자열 상수 및 파일 이름 사용 여부만 살펴봐도 이식성 위반을 감지할 수 있었음
- 간단한 사례의 경우, 특정 물리적 위치에서 실행되도록 하드코딩된 것으로 보이는 코드를 강조 표시하는 린터 규칙을 작성함
- 서비스가 실제로 이식 가능한지 테스트하기 위해 실제로 사람의 개입 없이 서비스를 여러 영역으로 이동해봐야 했음
- 서비스 소유자가 서비스의 첫 번째 이동을 시작할 수 있는 테스트 도구 모음을 구축
- 안전하고 점진적인 코드 롤아웃을 위한 기존 툴을 기반으로 했기 때문에 서비스 소유자는 언제든지 원래 영역으로 배치를 되돌리고 문제가 발견되면 해결가능
- 이동이 성공적으로 완료되면 해당 서비스는 앞으로 자동으로 이동하도록 표시
- 이후 몇 년 동안 Uber의 모든 서비스에 대해 이 프로세스를 반복했고 결국 모든 서비스를 완전히 완료
- 작업 완료 후에는 서비스 엔지니어의 개입 없이 구역 토폴로지를 변경할 수 있게 됨
- 시간이 지나도 서비스가 이식성을 유지할 수 있도록 몇 주마다 모든 서비스를 영역 간에 지속적으로 마이그레이션하여 이동 기능을 정기적으로 테스트함
- 이를 통해 서비스의 Regression을 쉽게 발견할 수 있으며, 시간이 지남에 따라 엔지니어는 서비스에 대한 특정 영역 배치를 가정하지 않는 데 익숙해졌음
Up: Multi-Cloud Multi-Tenant Federation Control Plane
- 다음과 같은 초기 시스템 목표를 설정
- 엔지니어가 인프라 시스템과 상호 작용할 수 있는 단일 진입점(Single Point of Entry) 제공
- 시스템에 직접 배포된 서비스에 대한 모범 사례를 관리하고 적용하여 코드 롤아웃 중에 높은 수준의 안전성을 제공
- 가용성 영역에 대한 서비스 배치 자동화; 새로운 가용성 영역이 사용 가능해지면 새로운 영역으로 배치를 변경하여 일반적으로 Uber의 고가용성을 지원하기 위해 배치를 중앙에서 조정하는 것이 포함
- 번거로운 인프라 수준 마이그레이션을 자동화하여 서비스 엔지니어가 마이그레이션에 관여할 필요가 없도록 함
- 하이레벨 아키텍처
- Experience Layer:
- 엔지니어가 시스템과 상호 작용하는 다양한 방법을 구현
- UI, Continuous Delivery, 시스템을 양호한 상태로 유지하는 로봇 등
- 사용률이 낮은 클러스터와 영역으로 워크로드를 지속적으로 이동시키는 Balancer
- 각 워크로드에 대한 용량 할당을 지속적으로 최적화하는 Auto Scaler
- Platform Layer:
- Experience 레이어가 서비스와 상호 작용하는 데 사용되는 추상화를 구현
- 서비스 운영의 개념적 모델을 형성하는 서비스 및 서비스 환경 추상화와 서비스 수준 API 자체가 포함
- 플랫폼 레이어에서 서비스 제약 조건은 실제 서비스 배치의 원하는 속성을 설명하는 상위 수준의 목표 상태로 표현
- 실행할 머신의 성능과 지역별 서비스에 대한 전체 컴퓨팅 용량에 대한 제약 조건이 포함될 수 있음
- Federation Layer:
- 컴퓨팅 클러스터에 대한 통합을 구현
- 상위 레이어에서 사용하는 지역 및 영역 추상화를 구현하기 위해 모든 클러스터를 기능 및 물리적 배치에 따라 구성
- 플랫폼에서 높은 수준의 서비스 목표 상태를 가져와 영역 및 클러스터 배치로 변환하며, 이 변환은 목표 상태의 제약 조건과 클러스터의 실제 상태(현재 사용 가능한 용량과 클러스터 및 보조 제약 조건을 충족할 수 있는 클러스터 포함)를 기반으로 함
- 이 변환 결과는 시간이 지남에 따라 변경될 수 있으며 나중에 다른 영역과 클러스터 배치가 더 바람직할 수 있음
- 밸런서의 모든 호출과 경험 계층에서 시작된 다른 작업으로 인해 이 배치가 다시 계산되고 변경될 수도 있음
- 시스템이 안전하게 유지되고 서비스가 양호한 상태를 유지할 수 있도록 변경 관리 구성 요소는 서비스 상태를 모니터링하는 모든 시스템과의 통합을 통해 글로벌 상태를 조금씩 점진적으로 변경하는 롤아웃 흐름을 구현
- 롤아웃 프로세스에는 전체 시스템에서 카나리아링 및 상태 신호 모니터링이 포함되며, 문제가 발견되면 시스템은 변경을 시작하기 전의 구성 및 배치로 서비스를 신속하게 롤백
- Regions
- 리전에는 실제 클러스터 인스턴스가 포함됨
- Peloton 및 Kubernetes® 클러스터가 포함
- 이들은 Up 자체에는 외부에 있지만 실제 용량 배치의 대상이며 물리적 호스트에 컨테이너 배치를 관리
효과
- 2018년에 Up 작업을 시작하여 2019년 초에 작동하는 프로토타입을 제공했고, 2020년 중반에 플랫폼을 정식으로 출시
- 그 이후 Uber의 모든 비즈니스 라인에 걸쳐 4,000개 이상의 서비스를 기존 배포 플랫폼에서 Up으로 마이그레이션
- 이 마이그레이션의 대부분은 자동화되었기 때문에 팀은 가장 진보된 사용 사례에 집중할 수 있었고 다른 팀의 마이그레이션을 지원도 가능
- 이 기간 동안 플랫폼의 안정성을 최우선 과제로 삼아 매일 수백만 명의 사용자가 Uber 시스템을 사용하는 상황에서 비즈니스를 안정적으로 운영할 수 있었음
- 약 2,000,000개의 컴퓨팅 코어를 새로운 플랫폼으로 이전하는 전체 마이그레이션은 약 2년에 걸쳐 진행되었으며, 2022년에 성공적으로 완료
- 이 마이그레이션을 통해 자동 확장 및 효율화 노력을 통해 수천만 달러의 추가 용량을 비즈니스에 환원
- 수동 서비스 업데이트, 새 구역 설정 및 채우기, Uber의 복잡한 인프라 환경 탐색 학습에 소요되던 수만 시간의 엔지니어링 시간을 절약하여 상당한 금전적 비용을 절감할 수 있었음
앞으로 할 일
- µDeploy에서 Up으로의 마이그레이션을 완료한 후, 팀은 이제 중앙 집중식 자동화된 방식으로 전체 서비스에 적용할 수 있는 솔루션과 이러한 기능을 중심으로 한 사용자 경험을 구축하는 데 집중할 수 있게 됨
- 클라우드 마이그레이션
- Uber는 플릿의 상당 부분을 클라우드로 이전중
- 대규모 자동화와 Up에서 제공하는 추상화 계층을 통해 서비스 팀은 이러한 전환에 필요한 인프라 세부 사항에서 크게 벗어날 수 있음
- 자동화된 Continuous Delivery
- 자동화된 파이프라인을 사용하여 코드가 프로덕션에 배포되기 전에 다양한 검사와 테스트를 실행하여 프로덕션까지 코드 배포를 완전히 자동화하는 것을 목표로 함
- 2023년에 팀이 집중할 계획인 특별한 부분은 서비스를 '최신 상태'로 유지하여 프로덕션에서 실행되는 모든 코드가 최신 보안 및 라이브러리 업데이트를 통해 최신 상태로 유지되도록 하는 것
- 배포 안전(Safety)
- 기존 데이터에 따르면 우리가 관찰한 사고의 상당수가 코드 및 설정 변경과 관련이 있는 것으로 나타남
- 프로덕션 전 테스트를 실행하거나 점진적 롤아웃 정책을 설정하는 등 서비스 수명주기의 수동적인 측면을 자동화하여 실제로 프로덕션까지 도달하는 결함의 비율을 크게 낮추는 것을 목표로 함
- 플랫폼
- Uber의 모든 Stateless 서비스 플릿을 하나의 엄브렐라 플랫폼아래에 구성하면 인프라 플랫폼 제품 간의 종속성과 상호 작용을 보다 명확하게 모델링할 수 있게 됨
- 이를 통해 코드에서 통일된 모델을 제공할 수 있을 뿐만 아니라 나머지 엔지니어링 조직에도 완전히 통합된 사용자 경험을 제공
- 모든 인프라를 한 곳에서 관찰하고 운영할 수 있는 것이 팀의 다음 큰 목표
결론
- Up 플랫폼을 구축하기 위한 노력은 이제 모든 Stateless 서비스가 동일한 모범 사례와 자동화를 사용하여 점진적으로 배포되고 있다는 점에서 상당한 문화적 변화를 의미
- 롤아웃 정책을 변경하거나 대규모 라이브러리 롤아웃을 위한 자동화를 구축하는 데 이전에는 수개월의 작업이 필요했던 작업이 이제 중앙 집중식 방식으로 가능해짐
- Uber 엔지니어가 인프라에 대한 걱정 없이 코드에만 집중할 수 있도록 하겠다는 비전을 달성하기 위해 Up의 이해관계자 및 서비스 소유자와 지속적으로 협력할 수 있기를 기대