> ## Content Index
> Fetch the complete content index at: https://www.popit.kr/llms.txt
> Use this file to discover other available public pages before exploring further.

# 우버의 마이크로서비스 적용기 해설
- URL: https://www.popit.kr/explaining-ubers-microservices-adoption/
- Published: 2017-10-19T00:42:10.000Z
- Updated: 2019-08-09T00:36:21.000Z
- Author: 안영회
- Tags: #해외글 요약, 마이크로서비스, uber, MSA

*\* 이 글은 작년 7월 사내 동료들에게 공유했던 내용을 일부 수정해서 올림을 알립니다.*

## 확장성 개선을 위한 마이크로 서비스 적용

우버Uber 엔지니어 에밀리 레인홀드Emily Reinhold가 밝힌 우버의 마이크로서비스 적용기([Breaking a Monolithic API into Microservices at Uber](https://www.infoq.com/news/2016/07/uber-microservices?ref=popit.kr))를 다룬 기사 요약입니다. 우선 마이크로서비스 적용 목적을 확장성 개선better scalability에 두고 있습니다. 흥미로운 사실은 확장성Scalability라는 모호한 목표를 구체화 하기 위해 세 가지 지표를 정했습니다. **트래픽 증가 처리(handling growing traffic)**와 **새로운 기능 추가(adding new features easily)** 그리고 **조직 성장에 따르는 아키텍처 적용(adopting an architecture that can adapt itself readily to the growth of the organization)**이 그 지표입니다.

![출처: https://eng.uber.com/building-tincup/](https://eng.uber.com/wp-content/uploads/2016/04/currency_graphic_uber_eng.jpg)

출처: https://eng.uber.com/building-tincup/

## MVCS와 UDR 적용 (핵심 매커니즘)

에밀리는 코드 사이에 존재하는 결합을 줄이기 위해 내린 중요한 설계 결정design decisions을 두 가지로 말합니다. 하나는 MVCS 적용인데 이는 널리 알려진 MVC(Model-View-Controller) 패턴에 서비스의 S를 추가한 개념입니다. **데이터 보관을 담당하는 코드**를 비즈니스 로직에서 분리하기 위해 MVC에 S를 추가한 것이죠. 이렇게 했기 때문에 두 번째 설계 결정을 실행할 수 있었으리라 추정할 수 있습니다. 바로 그 두번째는 RDBMS(제품은 PostgreSQL)을 UDR(Uber’s globally replicated datastore)하는 자체 분산 데이터저장소로 바꾼 것입니다. 무시무시한 일을 한 것인데요. [그의 블로그에서 동기를 살펴보니](https://eng.uber.com/building-tincup/?ref=popit.kr) 글로벌 서비스와 데이터센터 구분에 따라 통화와 환율을 다루는 일이 RDBMS와 데이터센터 종속성을 극복하게 했답니다. 결국 이렇게 하려면, SQL을 사용하던 모든 코드는 UDR을 쓰도록 수정했을 것이라 추정할 수 있습니다. 전체 코드에 다 영향을 주는 작업이지만 대신에 데이터를 맞추는 수동 작업이 모두 사라지고, 전 지구에 걸쳐 발생하는 트래픽을 통화와 환율 정보 기반하에 처리하는 거대한 인프라를 구축했음을 예상할 수 있습니다.

## 서비스 확장을 위한 Tornado, TChannel/Hyperbahn, Thrift 적용

다음으로 서비스 확장에 따른 결제 결정 세 가지를 설명합니다. 첫 번째는 **비동기 네트워크 프로그래밍(Asynchronous networking)**입니다. 우버는 기존 통신 로직이 파이썬으로 짜여져 있다고 하는데, 이벤트 기반의 대용량 비동기 통신을 가능하게 하는 솔루션인 [Tornado](http://www.tornadoweb.org/en/stable/?ref=popit.kr)를 써서 처리량을 늘렸다고 합니다. 기존에는 동기 형태의 프로그래밍을 했는데, 역시 이들 코드를 비동기로 수정한 것입니다. 두 번째는 **서비스 모니터링(Service discovery and resiliency)**인데요. 장애가 발생했을 때 그 지점을 정확하게 알고 장애가 연쇄적으로 확산되지 않도록 응급 차단하는 일(circuit breaking 이라고 함)과 서비스 수준을 통제(SLA)하는 일을 의미합니다. 이를 위해 우버가 사용한 솔루션 역시 오픈소스 제품([TChannel](http://uber.github.io/tchannel/?ref=popit.kr) over [Hyperbahn](http://uber.github.io/hyperbahn/?ref=popit.kr))입니다. 세번째는 **엄격한 인터페이스 정의**입니다. 우버는 여러 언어의 클라이언트를 지원하는 [Thrift](http://thrift.apache.org/?ref=popit.kr)라는 솔루션을 활용해서 원격 서비스에 대해 인터페이스를 명확하게 정의하고 쓰게 하여 주고 받는 데이터 불일치(혹은 버전 불일치)를 막았다고 합니다. 어쩌면 중국에서 우버 사용 초기에 오류가 나는 것이 이런 작업과 관련한 것일 수 있다는 생각이 드네요. 

![(smile)](https://younghoe.atlassian.net/wiki/s/1964495884/6452/fa9c0caf47406cabbb7902a9748da1c5eaedca9e/_/images/icons/emoticons/smile.png)

## 운영 안정화를 위한 세 가지 원칙

마지막으로 그는 우버가 안전한 운영환경(healthy production environment) 유지를 위해 지키는 세 가지 원칙을 설명합니다.

- 병목 지점 확인을 위해서 부하 테스트load tests 수행
- 컨데이터container 사용으로 하드웨어 효율을 높임
- 시스템 복구 및 취약점 식별을 위해 서비스 모의 장애 수행