[번역] Up: 클라우드를 위한 휴대용 마이크로서비스 준비

출처: https://www.uber.com/en-GB/blog/up-portable-microservices-ready-for-the-cloud/

 

소개

매주 4,500명의 엔지니어와 수많은 자율 시스템이 4,000개 이상의 Uber 마이크로서비스를 10만 번 이상 배포합니다. 이러한 서비스는 전 세계에서 독립적으로 활동하는 수백 개의 개별 팀에 의해 개발, 배포, 운영됩니다. 내부 운영에 사용되는 소규모 서비스부터 대규모 실시간 연산에 사용되는 대규모 서비스까지 그 규모와 형태, 기능이 다양합니다. 

이러한 서비스는 모두 다르지만 공통적인 특성을 공유하며, 간소화를 위해 통합할 수 있는 측면이 많습니다. 저희가 집중한 측면은 배포, 용량 관리, 규정 준수 및 일상적인 운영이었습니다. 이 글에서는 기본 구성 및 롤아웃 메커니즘을 어떻게 통합하고 간소화했는지, 그 과정에서 해결한 몇 가지 흥미로운 과제와 이를 통해 달성한 효율성에 대해 설명합니다.

 

 

Uber의 상태 비저장 서비스 역사

2014년에 Uber는 Python®으로 작성되고 단일 PostgreSQL® 데이터베이스에 데이터를 저장하는 모놀리식 애플리케이션이었습니다. 시스템이 성장하고 회사가 더 많은 엔지니어를 고용하기 시작하면서 결국 Uber는 마이크로서비스 아키텍처로 전환했습니다.

 

하지만 여전히 임의의 bash 스크립트부터 전용 Jenkins 작업 세트에 이르기까지 사람들이 코드를 배포하는 방식에는 많은 차이가 있었습니다. 서비스 수가 수백 개로 늘어나기 시작하면서 Uber는 대규모로 코드를 중앙에서 배포할 수 있는 µDeploy를 구축했습니다.

µDeploy를 통해 모든 상태 비저장 서비스를 컨테이너화하고 호스트 관리 및 배치를 추상화하여 인프라 그룹이 비즈니스 수준의 마이크로서비스와 독립적으로 호스트 제품군을 관리할 수 있도록 했습니다. 그러나 서비스 관리 및 배치는 여전히 수작업으로 이루어졌습니다.

 

지역 및 구역

Uber의 인프라는 여러 구역이 하나의 지역을 형성하는 모델을 따릅니다. 지역 내 구역 간의 지연 시간은 충분히 짧아 같은 지역 내의 서비스 간에 동기식 통신이 효율적으로 이루어집니다. 영역은 Uber가 소유한 머신의 클러스터일 수도 있고 퍼블릭 클라우드 제공업체의 용량일 수도 있지만, 특정 영역은 항상 단일 제공업체의 지원만 받습니다. 일반적으로 모든 마이크로서비스는 동일한 지역 내에 있는 한 지연 시간 문제 없이 다른 서비스를 호출할 수 있어야 합니다.

µDeploy를 사용하면 엔지니어가 여전히 가용 영역 수준에서 물리적 배치를 관리해야 했기 때문에 워크로드의 지리적 배치가 시스템에서 중앙 집중화되지 않았습니다. 즉, 서비스 엔지니어는 온프레미스 영역에서 서비스를 실행할지 여부뿐만 아니라 어떤 특정 영역에서 실행할지 여부도 여전히 결정해야 했습니다.

 

 

클라우드로의 이전 결정

온프레미스 데이터센터를 운영하면서 칩 부족과 공급망 문제로 인해 리드 타임이 길어졌습니다. 2023년 2월 13일, Uber는 공급망 문제에 대한 노출을 줄이고 다각화하기 위해 오라클 및 Google과 파트너십을 맺었습니다. 비즈니스를 지원하는 수백 개의 다양한 서비스를 개발하는 수천 명의 Uber 엔지니어로부터 기본 인프라를 추상화할 수 있는 시스템을 갖추지 않고서는 이 전략을 실행하는 것이 불가능했습니다.

 

 

Uber의 클라우드 마이그레이션 준비

비즈니스를 계속 운영하면서 4,500개의 상태 비저장 서비스를 클라우드로 마이그레이션하려면 엄청난 양의 조정과 노력이 필요하며, 이 작업은 오류가 발생하기 쉽고 수동으로 조율된 노력을 통해 관리하기가 거의 불가능하다는 것을 처음부터 분명히 알 수 있었습니다. 상태 비저장 마이크로서비스의 유지 및 관리를 대규모로 수행하려면 사람의 개입 없이 중앙 집중식 배포 시스템에서 자동으로 관리할 수 있도록 서비스를 혁신해야 했습니다.

 

 

무국적자를 넘어서: 이동성

에어비앤비는 구역과 지역에 대한 모델을 기반으로 이동성이라는 개념을 생각해냈습니다. 이동성이란 지역 내의 모든 영역에서 실행할 수 있고, 사람의 개입 없이 인프라 플랫폼에 의해 자동으로 새로운 영역으로 이동할 수 있는 서비스를 말합니다. 여기에는 퍼블릭 클라우드 제공업체 간 이동뿐만 아니라 사내 존 안팎으로의 이동도 포함됩니다. 일부 서비스는 영역별 구성과 영역별 리소스의 선호도에 따라 달라지기 때문에 일반적으로 이러한 속성이 없었습니다. 클라우드로의 자동 마이그레이션을 수행하기 위해서는 모든 서비스에 대해 이 속성을 보유해야 한다는 것이 분명해졌습니다.

 

 

Uber의 휴대성 강화

2021년과 2022년에 걸쳐 엔지니어링 전반에서 모든 서비스가 이식성을 갖출 수 있도록 하는 프로그램을 운영했습니다. 많은 경우 코드 검사를 통해 코드에서 문자열 상수 및 파일 이름을 사용하는 것만으로도 이식성 위반을 감지할 수 있었습니다. 이러한 간단한 사례의 경우, 특정 물리적 위치에서 실행되도록 하드코딩된 것으로 보이는 코드를 강조 표시하는 린터 규칙을 만들었습니다. 서비스가 실제로 이식 가능한지 테스트하기 위해 실제로 사람의 개입 없이 서비스를 여러 영역으로 이동시켜야 했습니다. 서비스 소유자가 서비스의 첫 번째 이동을 시작할 수 있는 테스트 도구 모음을 구축했습니다. 이 툴은 안전하고 점진적인 코드 롤아웃을 위한 기존 툴을 기반으로 했기 때문에 서비스 소유자는 언제든지 원래 영역으로 배치를 되돌리고 문제가 발견되면 해결할 수 있었습니다. 이동이 성공적으로 완료되면 해당 서비스는 앞으로 자동으로 이동하도록 표시되었습니다. 이후 몇 년 동안 Uber의 모든 서비스에 대해 이 프로세스를 반복했고 결국 모든 서비스를 완전히 완료했습니다. 이 작업을 완료한 후에는 서비스 엔지니어의 개입 없이도 영역 토폴로지를 변경할 수 있었습니다.

시간이 지나도 서비스가 이동성을 유지할 수 있도록 몇 주마다 모든 서비스를 구역 간에 지속적으로 마이그레이션하여 이동 기능을 정기적으로 연습합니다. 이를 통해 서비스의 회귀를 쉽게 발견할 수 있으며, 시간이 지남에 따라 엔지니어는 서비스에 대한 특정 영역 배치를 가정하지 않는 데 익숙해졌습니다.

 

 

멀티 클라우드 멀티 테넌트 페더레이션 컨트롤 플레인

가장 시간이 많이 걸리고 오류가 발생하기 쉬운 서비스 운영으로 판단한 내용을 바탕으로 다음과 같은 초기 시스템 목표를 설정했습니다.

• 엔지니어가 인프라 시스템과 상호 작용할 수 있는 단일 진입점 제시
• 시스템에 직접 배포된 서비스에 대한 모범 사례를 관리 및 적용하여 코드 롤아웃 시 높은 수준의 안전성 제공
• 가용성 영역에 대한 서비스 배치 자동화; 여기에는 새로운 가용성 영역이 사용 가능해지면 새로운 영역으로 배치를 변경하여 일반적으로 Uber의 고가용성을 지원하기 위해 배치를 중앙에서 조정하는 것이 포함됩니다.
• 번거로운 인프라 수준 마이그레이션을 자동화하여 서비스 엔지니어가 마이그레이션에 관여할 필요가 없도록 합니다.

 

 

상위 수준 아키텍처

Up은 각각 고유한 책임이 있는 세 가지 아키텍처 계층으로 구성되어 있습니다.

 

상단의 경험 레이어는 엔지니어가 시스템과 상호 작용하는 다양한 방법을 구현합니다. 여기에는 직접 제어할 수 있는 UI, 일상적인 배포를 자동화하기 위한 지속적 배포 환경, 시스템을 양호한 상태로 유지하는 로봇이 모두 포함됩니다. 또한 사용률이 낮은 클러스터와 영역으로 워크로드를 지속적으로 이동시키는 밸런서와 각 워크로드에 대한 용량 할당을 지속적으로 최적화하는 자동 스케일러도 포함됩니다.

플랫폼 레이어는 경험 레이어가 서비스와 상호 작용하는 데 사용하는 추상화를 구현합니다. 여기에는 서비스 운영의 개념적 모델을 형성하는 서비스 및 서비스 환경 추상화와 서비스 수준 API 자체가 포함됩니다. 플랫폼 계층에서 서비스 제약 조건은 실제 서비스 배치의 원하는 속성을 설명하는 상위 수준의 목표 상태로 표현됩니다. 여기에는 실행할 머신의 성능과 지역별 서비스에 대한 전체 컴퓨팅 용량에 대한 제약 조건이 포함될 수 있습니다.

 

페더레이션 레이어는 컴퓨팅 클러스터에 대한 통합을 구현합니다. 이 계층은 상위 계층에서 사용하는 영역 및 영역 추상화를 구현하기 위해 모든 클러스터를 기능 및 물리적 배치에 따라 구성합니다. 이 계층은 플랫폼에서 높은 수준의 서비스 목표 상태를 가져와 영역 및 클러스터 배치로 변환합니다. 이 변환은 목표 상태의 제약 조건과 클러스터의 실제 상태(현재 사용 가능한 용량과 클러스터 및 보조 제약 조건을 충족할 수 있는 클러스터 포함)를 모두 기반으로 합니다. 이 변환 결과는 시간이 지남에 따라 변경될 수 있으며 나중에 다른 영역과 클러스터 배치가 더 바람직할 수 있습니다. 밸런서의 모든 호출과 경험 계층에서 시작된 다른 작업으로 인해 이 배치가 다시 계산되고 변경될 수 있습니다. 시스템이 안전하게 유지되고 서비스가 양호한 상태를 유지할 수 있도록 변경 관리 구성 요소는 서비스 상태를 모니터링하는 모든 시스템과의 통합을 통해 글로벌 상태를 조금씩 점진적으로 변경하는 롤아웃 흐름을 구현합니다. 이 롤아웃 프로세스에는 전체 시스템에서 카나리아링 및 상태 신호 모니터링이 포함됩니다. 문제가 발견되면 시스템은 변경을 시작하기 전의 구성 및 배치로 서비스를 신속하게 되돌립니다.

 

마지막으로, 리전에는 실제 클러스터 인스턴스가 포함되며, 여기에는 Peloton 및 Kubernetes® 클러스터가 포함됩니다. 이러한 인스턴스는 Up 자체에는 외부에 있지만 실제 용량 배치의 대상이며 물리적 호스트에 컨테이너 배치를 관리합니다.

 

 

영향력

2018년에 Up 작업을 시작하여 2019년 초에 작동하는 프로토타입을 제공했으며, 2020년 중반에 플랫폼을 정식으로 출시했습니다. 그 이후로 Uber의 모든 비즈니스 라인에 걸쳐 4,000개 이상의 서비스를 기존 배포 플랫폼에서 Up으로 마이그레이션했습니다. 이 마이그레이션의 대부분은 자동화되었기 때문에 팀은 가장 진보된 사용 사례에 집중할 수 있었고 다른 팀의 마이그레이션을 지원할 수 있었습니다. 이 기간 동안 플랫폼의 안정성을 최우선 과제로 삼아 매일 수백만 명의 사용자가 Uber 시스템을 사용하는 상황에서 비즈니스를 계속 운영할 수 있었습니다.

 

약 2,000,000개의 컴퓨팅 코어를 새로운 플랫폼으로 이전하는 전체 마이그레이션은 약 2년에 걸쳐 진행되었으며, 2022년에 성공적으로 완료되었습니다. 이 마이그레이션을 통해 자동 확장 및 효율화 노력을 통해 수천만 달러의 추가 용량을 비즈니스에 환원하고, 수동 서비스 업데이트, 새 구역 설정 및 채우기, Uber의 복잡한 인프라 환경 탐색 학습에 소요되던 수만 시간의 엔지니어링 시간을 절약하여 상당한 금전적 비용을 절감할 수 있었습니다.

 

 

다음 단계

µDeploy에서 Up으로의 마이그레이션을 완료한 팀은 이제 중앙 집중식 자동화된 방식으로 전체 서비스에 적용할 수 있는 솔루션과 이러한 기능을 중심으로 한 사용자 경험을 구축하는 데 집중할 수 있습니다. 

클라우드 마이그레이션

Uber는 차량의 상당 부분을 클라우드로 이전하고 있습니다. 대규모 자동화와 Up에서 제공하는 추상화 계층을 통해 서비스 팀은 이러한 전환에 필요한 인프라 세부 사항에서 크게 벗어날 수 있습니다. 

 

자동화된 지속적 배포

자동화된 파이프라인을 사용하여 코드가 프로덕션에 배포되기 전에 다양한 검사와 테스트를 실행하여 프로덕션까지 코드 배포를 완전히 자동화하는 것을 목표로 합니다. 특히 2023년에 집중할 계획인 부분은 서비스를 '최신 상태'로 유지하여 프로덕션 환경에서 실행되는 모든 코드가 최신 보안 및 라이브러리 업데이트를 통해 최신 상태로 유지되도록 하는 것입니다.

 

배포 안전성

기존 데이터에 따르면 우리가 관찰한 인시던트의 상당수가 코드 및 설정 변경과 관련이 있는 것으로 나타났습니다. 저희는 프로덕션 전 테스트를 실행하거나 점진적 롤아웃 정책을 설정하는 등 서비스 수명주기의 이전 수작업 측면을 자동화하여 실제로 프로덕션까지 도달하는 결함의 비율을 크게 낮추는 것을 목표로 합니다.

 

플랫폼

Uber의 모든 상태 비저장 서비스 제품군을 하나의 포괄적인 플랫폼으로 구성하면 인프라 플랫폼 제품 간의 종속성과 상호 작용을 보다 명확하게 모델링할 수 있습니다. 이를 통해 코드에서 통일된 모델을 제공할 수 있을 뿐만 아니라 나머지 엔지니어링 조직에도 완전히 통합된 사용자 경험을 제공할 수 있습니다. 모든 인프라를 한 곳에서 관찰하고 운영할 수 있는 것이 팀의 다음 큰 목표입니다.