[Geek News] Uber가 수천개의 마이크로서비스를 멀티 클라우드 플랫폼으로 이전한 방법

1. 출처

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

- 번역 : Uber가 수천개의 마이크로서비스를 멀티 클라우드 플랫폼으로 이전한 방법 | GeekNews (hada.io)

이 글은 원글과 GeekNews의 요약을 보고 개인 의견 메모를 위해 작성되었습니다.

---

2. 요약

• "Up: Portable Microservices Ready for the Cloud"
• Uber는 4,500명의 엔지니어와 수많은 자동 시스템이 매주 4,000회 이상 4,500개의 Stateless 마이크로서비스를 배포
• 이 서비스들은 전 세계에서 독립적으로 일하는 수백 개의 개별 팀에 의해 개발, 배포 및 운영됨
• 서비스는 크기, 모양, 기능이 다양하여, 일부는 작고 내부 작업에 사용되며, 일부는 크고 대규모 실시간 계산에 사용

2.1. Uber의 Stateless 서비스 역사

• 2014년에 Uber는 Python으로 작성된 Monolith에 한대의 PostgreSQL DB에 데이터를 저장
• 성장하면서 엔지니어를 충원하고 Microservice 아키텍처로 전환
• 서비스가 많아지면서 우버는 µDeploy 라는 도구를 만들어서 코드를 중앙에서 대규모로 배포
  • 모든 Stateless 서비스를 컨테이너화하고, 호스트 관리 및 배치를 추상화
  • 인프라 그룹이 비즈니스 단위 마이크로서비스와 독립적으로 호스트 플릿을 관리 가능하게 했음
  • 하지만 서비스 관리 및 배치는 여전히 수작업
• 우버의 인프라는 영역(Zone) 들의 그룹이 지역(Region)을 형성하는 모델을 따름
• 리젼 안의 영역 간 레이턴시는 충분히 짧아서 같은 지역 내의 서비스간에는 동기식 통신이 효율적
• 각 영역은 우버가 소유한 머신들의 클러스터이거나 퍼블릭 클라우드 업체의 것일수도 있지만, 특정 영역 자체는 항상 단일 업체로만 가능
• 일반적으로 모든 마이크로서비스는 같은 지역 내에 있는 한, 지연 시간 문제 없이 다른 서비스를 호출할 수 있어야 함
• µDeploy는 엔지니어가 여전히 가용 영역(Availability Zone) 수준에서 물리적 배치를 관리해야 했기 때문에 워크로드의 지리적 배치가 시스템에서 중앙 집중화되지 않았음
• 즉, 서비스 엔지니어는 온프레미스 영역에서 서비스를 실행할지 여부뿐만 아니라 어떤 특정 영역에서 실행할지 여부도 여전히 결정해야 했음
• 온프레미스 데이터 센터를 운영하면서 칩 부족과 공급망 문제로 인해 리드 타임이 길어짐
• 2023년 2월 13일, Uber는 공급망 문제에 대한 노출을 줄이고 다각화하기 위해 오라클 및 Google과 파트너십을 맺음
• 비즈니스를 지원하는 수백 개의 다양한 서비스를 개발하는 수천 명의 Uber 엔지니어로부터 "기본 인프라를 추상화할 수 있는 시스템"을 갖추지 않고서는 이 전략을 실행하는 것이 불가능

2.2. Uber를 클라우드로 이관하기 위해 준비하기

• 비즈니스를 계속 운영하면서 4,500개의 상태 비저장 서비스를 클라우드로 마이그레이션하려면 엄청난 양의 조정과 노력이 필요
• 이 작업은 오류가 발생하기 쉽고 수동으로 조율된 노력을 통해 관리하기가 거의 불가능하다는 것을 처음부터 분명히 알 수 있었음
• Stateless 마이크로서비스의 유지 및 관리를 대규모로 수행하려면 사람의 개입 없이 중앙 집중식 배포 시스템에서 자동으로 관리할 수 있도록 서비스를 혁신해야 했음
• Stateless 를 넘어서 Portability로
  • Region과 Zone에 대한 모델을 기반으로 "이식성(Portability)"이라는 개념을 생각해냄
  • 이식성이란 지역 내의 모든 영역에서 실행할 수 있고, 사람의 개입 없이 인프라 플랫폼에 의해 자동으로 새로운 영역으로 이동할 수 있는 서비스를 말함
  • 퍼블릭 클라우드 제공업체 간 이동은 물론, 온프레미스 영역 안팎에서의 이동도 포함
  • 일부 서비스는 영역 구성과 영역 리소스의 선호도에 따라 달라지기 때문에 일반적으로 이식성을 가지고 있지 않았음
  • 클라우드로의 자동 마이그레이션을 수행하기 위해서는 모든 서비스에 대해 이식성을 보유하도록 해야했음

2.3. Uber를 Portable 하게 만들기

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

2.4. 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 자체에는 외부에 있지만 실제 용량 배치의 대상이며 물리적 호스트에 컨테이너 배치를 관리

 

2.5. 효과

• 2018년에 Up 작업을 시작하여 2019년 초에 작동하는 프로토타입을 제공했고, 2020년 중반에 플랫폼을 정식으로 출시
• 그 이후 Uber의 모든 비즈니스 라인에 걸쳐 4,000개 이상의 서비스를 기존 배포 플랫폼에서 Up으로 마이그레이션
• 이 마이그레이션의 대부분은 자동화되었기 때문에 팀은 가장 진보된 사용 사례에 집중할 수 있었고 다른 팀의 마이그레이션을 지원도 가능
• 이 기간 동안 플랫폼의 안정성을 최우선 과제로 삼아 매일 수백만 명의 사용자가 Uber 시스템을 사용하는 상황에서 비즈니스를 안정적으로 운영할 수 있었음
• 약 2,000,000개의 컴퓨팅 코어를 새로운 플랫폼으로 이전하는 전체 마이그레이션은 약 2년에 걸쳐 진행되었으며, 2022년에 성공적으로 완료
• 이 마이그레이션을 통해 자동 확장 및 효율화 노력을 통해 수천만 달러의 추가 용량을 비즈니스에 환원
• 수동 서비스 업데이트, 새 구역 설정 및 채우기, Uber의 복잡한 인프라 환경 탐색 학습에 소요되던 수만 시간의 엔지니어링 시간을 절약하여 상당한 금전적 비용을 절감할 수 있었음

2.6. 앞으로 할 일

• µDeploy에서 Up으로의 마이그레이션을 완료한 후, 팀은 이제 중앙 집중식 자동화된 방식으로 전체 서비스에 적용할 수 있는 솔루션과 이러한 기능을 중심으로 한 사용자 경험을 구축하는 데 집중할 수 있게 됨
• 클라우드 마이그레이션
  • Uber는 플릿의 상당 부분을 클라우드로 이전중
  • 대규모 자동화와 Up에서 제공하는 추상화 계층을 통해 서비스 팀은 이러한 전환에 필요한 인프라 세부 사항에서 크게 벗어날 수 있음
• 자동화된 Continuous Delivery
  • 자동화된 파이프라인을 사용하여 코드가 프로덕션에 배포되기 전에 다양한 검사와 테스트를 실행하여 프로덕션까지 코드 배포를 완전히 자동화하는 것을 목표로 함
  • 2023년에 팀이 집중할 계획인 특별한 부분은 서비스를 '최신 상태'로 유지하여 프로덕션에서 실행되는 모든 코드가 최신 보안 및 라이브러리 업데이트를 통해 최신 상태로 유지되도록 하는 것
• 배포 안전(Safety)
  • 기존 데이터에 따르면 우리가 관찰한 사고의 상당수가 코드 및 설정 변경과 관련이 있는 것으로 나타남
  • 프로덕션 전 테스트를 실행하거나 점진적 롤아웃 정책을 설정하는 등 서비스 수명주기의 수동적인 측면을 자동화하여 실제로 프로덕션까지 도달하는 결함의 비율을 크게 낮추는 것을 목표로 함
• 플랫폼
  • Uber의 모든 Stateless 서비스 플릿을 하나의 엄브렐라 플랫폼아래에 구성하면 인프라 플랫폼 제품 간의 종속성과 상호 작용을 보다 명확하게 모델링할 수 있게 됨
  • 이를 통해 코드에서 통일된 모델을 제공할 수 있을 뿐만 아니라 나머지 엔지니어링 조직에도 완전히 통합된 사용자 경험을 제공
  • 모든 인프라를 한 곳에서 관찰하고 운영할 수 있는 것이 팀의 다음 큰 목표

2.7. 결론

• Up 플랫폼을 구축하기 위한 노력은 이제 모든 Stateless 서비스가 동일한 모범 사례와 자동화를 사용하여 점진적으로 배포되고 있다는 점에서 상당한 문화적 변화를 의미
• 롤아웃 정책을 변경하거나 대규모 라이브러리 롤아웃을 위한 자동화를 구축하는 데 이전에는 수개월의 작업이 필요했던 작업이 이제 중앙 집중식 방식으로 가능해짐
• Uber 엔지니어가 인프라에 대한 걱정 없이 코드에만 집중할 수 있도록 하겠다는 비전을 달성하기 위해 Up의 이해관계자 및 서비스 소유자와 지속적으로 협력할 수 있기를 기대

---

3. 개인 의견

최근 회사에서 EKS와 GKE를 다루면서 멀티 클러스터에  대해 공부할 필요를 느끼고 있었다.

특히, GKE에는 Fleet이라고 하는 논리적으로 클러스터를 그룹화하는 개념도 있었다.

 

Uber는 글로벌 서비스를 추구하다보니 온갖 지역에 있는 업체의 머신을 사용해야 했다.

이러한 상황에서 4,000개가 넘는 마이크로 서비스를 운영하는 일은

Terraform과 같은 IaC 로도 감당하기 어려웠을 것으로 생각된다.

 

실제로 Terraform을 사용해보면서 느낀 것은

• 동시에 여러명이 사용하기 어렵고(State 파일이 Lock이 걸리니까!)
• 리소스 변경에 대한 실시간 대응이 약한 편이다.(Terraform apply 중에 누군가 리소스를 웹에서 수정해버렸다면, 작업은 실패한다)

이러한 점들을 해결하기 위해 인프라 추상화를 한번 더 추상화하는 방법을 택하게 된 것이다.

물론 이러한 작업들이 쉽지 않았을 것이라고 생각한다.

기존 직원들의 반대나 불신을 걷어내기 위한 Soft한 작업도 몇년 간 이어져왔을 거라고 생각하면 

박수가 절로 나온다.

 

입사 1개월 차 병아리 개발자 시절에 NHN 컨퍼런스에서 들었던

멀티 클러스터 개념을 슬슬 몸으로 체감하고 있는 요즘이다.

더욱 공부에 박차를 가해야겠다.