Uber's Failover Architecture: Reconciling Reliability and Efficiency in Hyperscale Microservice Infrastructure

이 논문은 우버가 2 배 용량 모델에서 비즈니스 중요도에 따른 차등화된 'UFA(Failover Architecture)'로 전환하여, 비중요 서비스의 선제적 중단과 자동화된 안전 장치를 통해 정상 상태 자원 할당을 2 배에서 1.3 배로 줄이고 활용률을 20% 에서 30% 로 높이면서도 99.97% 의 가용성을 유지하는 성과를 거두었다고 설명합니다.

Mayank Bansal, Milind Chabbi, Kenneth Bogh, Srikanth Prodduturi, Kevin Xu, Amit Kumar, David Bell, Ranjib Dey, Yufei Ren, Sachin Sharma, Juan Marcano, Shriniket Kale, Subhav Pradhan, Ivan Beschastnikh, Miguel Covarrubias, Chien-Chih Liao, Sandeep Koushik Sheshadri, Wen Luo, Kai Song, Ashish Samant, Sahil Rihan, Nimish Sheth, Uday Kiran Medisetty

게시일 Tue, 10 Ma
📖 4 분 읽기☕ 가벼운 읽기

Each language version is independently generated for its own context, not a direct translation.

우버의 '실패 대비 시스템' (UFA): 어떻게 100 만 개의 CPU 코어를 구했을까?

우버 (Uber) 와 같은 거대 기업은 전 세계 수백만 명의 사용자를 실시간으로 연결해야 합니다. 만약 우버의 서버 하나가 고장 나면, 택시 호출이나 음식 배달이 멈출 수 있어 큰 문제가 됩니다. 그래서 우버는 항상 서버를 두 배로 준비해 두었습니다. 마치 "비상용 구명보트"를 항상 띄워 두는 것과 같죠.

하지만 이 방식은 엄청난 비용이 들었습니다. 평소에는 구명보트가 빈 채로 떠다니며 공간을 차지하고 있었기 때문입니다. 이 논문은 우버가 어떻게 이 비효율적인 시스템을 고쳐, 서버 사용량을 20% 에서 30% 로 늘리면서 100 만 개의 CPU 코어 (컴퓨터 두뇌) 를 아꼈는지 설명합니다.

이 복잡한 이야기를 비유를 통해 쉽게 풀어보겠습니다.


1. 문제: "무조건 두 배 준비"의 비효율성

비유: 대형 호텔의 '빈 방' 문제
우버는 과거에 모든 서비스를 위해 두 개의 거대한 호텔을 운영했습니다.

  • 호텔 A (현재 사용): 손님이 들어와서 방을 씁니다.
  • 호텔 B (비상용): 손님이 없어도, 호텔 A 에 문제가 생기면 모든 손님을 B 로 옮길 수 있도록 항상 비워 둡니다.

이 방식은 안전하지만, 호텔 B 의 50% 는 항상 비어 있었습니다. 마치 비행기 좌석의 절반을 항상 비워두고 '비상용'으로만 예약해 두는 것과 같습니다. 우버는 매년 20 시간 미만의 '진짜 큰 재해'만 발생한다는 데이터를 발견했습니다. 즉, 매년 365 일 중 364 일 이상은 그 비싼 '비상용 호텔'이 쓸모없이 비어 있었던 것입니다.

2. 해결책: UFA (우버 실패 아키텍처)

우버는 "모든 것을 똑같이 보호할 필요는 없다"는 사실을 깨달았습니다. 핵심 서비스 (택시 호출, 결제) 는 절대 멈추면 안 되지만, 부가적인 서비스 (앱 내 광고, 통계 분석) 는 잠시 멈춰도 괜찮습니다.

이 아이디어를 바탕으로 UFA라는 새로운 시스템을 만들었습니다.

핵심 전략 1: "빈 방을 임시로 임대하자" (지능형 과부하)

  • 평소 (정상 상태): 비상용 호텔 B 의 빈 방들을 일시적으로 다른 손님들 (중요하지 않은 서비스) 에게 빌려줍니다.
  • 결과: 평소에는 호텔 B 가 비어 있는 게 아니라, 다른 손님들이 그 방을 사용하며 수익을 내는 것입니다.

핵심 전략 2: "재난이 오면 먼저 내보내기" (우선순위 대피)

  • 재난 발생 시 (호텔 A 고장): 호텔 B 에 임시로 있던 '중요하지 않은 손님들'을 즉시 밖으로 내보냅니다.
  • 대피: 내보낸 손님들은 잠시 호텔 밖 (클라우드나 임시 공간) 에서 기다리다가, 호텔 A 가 고쳐지면 다시 들어옵니다.
  • 핵심 서비스: '중요한 손님들' (택시 호출 등) 은 호텔 B 의 빈 방을 즉시 모두 차지하여 100% 서비스를 유지합니다.

이게 바로 UFA 의 핵심입니다. 평소에는 빈 공간을 활용하고, 위기가 오면 그 공간을 핵심 서비스에게 내어주는 유연한 시스템입니다.

3. 가장 큰 난관: "연쇄 폭탄"을 제거하다

이 시스템을 도입할 때 가장 큰 문제는 **'의존성'**이었습니다.

  • 문제 상황: 중요한 서비스 (A) 가 비싼 식당 (B) 에 의존하고 있었습니다. 만약 식당 B 가 문을 닫으면, A 도 문을 닫아야 했습니다.
  • 위험: 비상용 호텔 B 에 임시로 있던 '식당 B'가 재해 때 내쫓기면, '중요한 서비스 A'도 함께 멈추게 됩니다.

해결책: "안전망 설치"
우버는 수천 개의 서비스 관계를 분석하여, 중요한 서비스가 비중요한 서비스의 고장에 영향을 받지 않도록 코드를 고쳤습니다.

  • 비유: "식당 B 가 문을 닫더라도, 중요한 손님 A 는 편의점에서 간단히 끼니를 해결할 수 있도록" 시스템을 개조한 것입니다.
  • 도구: 우버는 자동화된 AI 와 분석 도구를 만들어, 개발자가 코드를 작성할 때 이런 '위험한 연결'을 미리 찾아내게 했습니다.

4. 실제 효과: 놀라운 결과

이 시스템을 실제 우버에 적용한 결과는 다음과 같습니다.

  1. 비용 절감:100 만 개의 CPU 코어를 줄였습니다. 이는 약 400 만 개 중 25% 를 아낀 것입니다.
  2. 효율성 증가: 서버 사용률이 20% 에서 30% 로 크게 향상되었습니다. (빈 방이 사라진 셈입니다.)
  3. 안정성 유지: 중요한 서비스 (택시 호출 등) 의 가동률은 **99.97%**를 유지하며, 재해 상황에서도 멈추지 않았습니다.
  4. 빠른 대응: 실제 재해가 발생했을 때, 17 시간 동안 100 만 개의 코어를 순식간에 전환하여 서비스를 이어갔습니다.

5. 교훈: 기술보다 중요한 것

이 프로젝트는 단순히 기술만 바꾼 것이 아니라, 조직 문화를 바꾼 것이었습니다.

  • 수천 개의 팀 협력: 우버에는 수천 개의 개발 팀이 있습니다. 모든 팀이 이 새로운 규칙에 따라 코드를 고치고, 테스트를 받아야 했습니다.
  • 실전 훈련: 이론만 믿지 않고, 실제 재해 상황을 모의해 보는 '훈련 (Drill)'을 수백 번 반복하며 시스템을 다듬었습니다.

요약

우버의 UFA 는 "평소에는 빈 공간을 활용해서 돈을 아끼고, 위기가 오면 그 공간을 핵심 서비스에 내어주어 안전을 지키는" 똑똑한 시스템입니다.

이는 마치 비행기와 같습니다. 평소에는 모든 좌석을 팔아 수익을 내지만, 비상구가 필요할 때는 그 공간을 확보해 두는 방식이 아니라, 비상용 좌석 (핵심 서비스) 을 항상 확보하고, 나머지 좌석 (비중요 서비스) 은 평소엔 팔다가 비상 시에는 우선순위에 따라 내보내는 방식입니다.

이러한 혁신 덕분에 우버는 더 안전하면서도 훨씬 더 효율적으로 운영될 수 있게 되었습니다.