Uber 의 실시간 채팅 시스템은 어떻게 대규모 데이터를 처리할까?

우버는 승객, 운전자, 음식 주문자, 배달원 등 다양한 고객들을 보유하고 있습니다.

 

그리고 우버는 고객들의 문제를 해결하기 위해서 다양한 채널을 사용합니다.

 

크게는 라이브, 비라이브 채널로 이뤄져있으며 라이브 채널은 채팅과 전화로 구성되어있고, 비라이브 채널은 우버의 인앱 메시징 채널로 구성되어 있습니다.

 

우버에게 중요한 건 사용자 관련 문제를 신속하게 해결할 수 있도록 하는 것인데 데이터 분석 결과 라이브 채널이 다른 채널에 비해 효과적으로 해결할 수 있음을 발견했다고 합니다.

 

그러나 우버의 채팅 인프라가 수요를 감당하지 못해 2019년부터 2024년까지 라이브 채팅을 통한 문제 해결은 전체 해결 중 1% 밖에 차지하지 못했다고 합니다.

 

그래서 우버는 실시간 채팅을 개선하기로 결정했다고 합니다. 

 

The Legacy Chat Architecture

우버의 이전 채팅 아키텍처는 다음 이미지와 같았고, 여러 가지 문제점이 있었습니다.

• 신뢰성 문제: 트래픽이 1.5배로 증가하자 신뢰성 문제가 발생하기 시작했다고 합니다. 백엔드에서 발생한 트래픽의 46%가 상담원 브라우저에 전달되지 않아, 상담원과 대화하려는 고객의 대기 시간이 늘어나는 문제가 발생했다고 합니다.
• 확장성 문제: 초당 요청이 10개를 넘어서자, 시스템 성능이 메모리 사용량 증가와 파일 디스크립터 누수로 인해 악화되었다고 합니다. 또한, WAMP 라이브러리의 이전 버전으로 인해 시스템의 Scale Out 이 불가능했다고 합니다. (WAMP 프로토콜은 웹소켓을 통한 클라이언트와 서버 간의 상태 유지를 연결해야하므로, 상태 유지가 필요한 방법입니다. 이로 인해서 요청의 트래픽이 골고루 분산되지 않아. Scale Out 이 힘들다는 단점이 있었습니다.)
• 관측성과 디버깅 문제: 채팅 요청의 상태를 추적하기 어려웠다고 합니다. 또한, 채팅 요청의 약 8%가 어떤 고객 상담원에게도 연결되지 않는 문제도 발생하였다고 합니다. 그리고 WAMP 프로토콜과 그 라이브러리가 더 이상 지원되지 않아 내부 작동 방식을 이해하기 어려웠고, 문제 해결또한 힘들었다고 합니다.
• 상태 유지(Stateful) 문제: 아키텍처 내의 서비스들이 Stateful 했기 때문에 어플리케이션이 재시작하면 상태 유지가 초기화되서 메시지 전달 시간의 급격한 증가와 손실을 초래했다고 합니다.

 

 

Goals of the New Chat Architecture

우버는 기존의 라이브 채팅 시스템에서 마주했던 문제점을 극복하기 위해 다음과 같은 목표 설정을 헀다고 합니다:

• 확장성 향상: 2023년 말까지 전체 고객 지원 연락량의 1%에서 80%로 채팅 트래픽을 증가시키는 것을 목표로 잡았다고 합니다. 이는 주당 약 300만 건의 티켓을 처리하는 것을 의미합니다.
• 성공률 향상: 고객을 상담원에게 연결하는 과정에서 첫 번째 시도에서 99.5% 이상의 성공률 달성을 목표로 잡았다고 합니다.
• 완전한 관측성과 디버깅 가능성: 채팅 전체 흐름에 걸쳐 엔드 투 엔드 관측성과 디버깅 기능을 구축하는 걸 목표로 설정했습니다.
• 무상태 서비스 구축: 시스템을 수평적으로 확장할 수 있도록 무상태(stateless) 서비스로 구축하는 걸 목표로 설정했습니다.

 

 

The New Live Chat Architecture

우버가 새로 설계한 아키텍처는 다음과 같습니다:

바뀐 부분을 보면 다음과 같습니다:

• 기존에 WAMP 프로토콜을 이용해서 고객의 Contact 정보를 상담원 (Agent) 로 전달 했던 매커니즘에서 Kafka 를 통한 Contact 메시지 발행으로 전환했습니다. 이를 통해 수평적으로 독립적으로 메시지 전달을 확장할 수 있습니다.
• Contact Reservation 알고리즘도 최적화되었습니다. 고객의 Contact 요청은 적은 고객을 상담하고 있는 상담원에게 매칭되도록 변경하였고, Sticky Routing 매커니즘을 이용해서 고객은 같은 상담원과 계속해서 통신할 수 있도록 구축했습니다.
• 상담원과 고객의 통신 매커니즘은 GraphQL subscriptions 을 통해 양방향 통신을 하도록 구축했다고 합니다. 이렇게 정한 이유는 Uber 팀 자체가 해당 기술에 익숙하기도 하였고, 해당 라이브러리는 주당 2.3 milion 의 다운로드를 할 정도로 인기있는 라이브러리지만 보고된 이슈는 없었기 때문이라고 합니다.
• 양방향 연결의 경우에도 가용성을 높이기 위해 여러 테크닉을 도입했다고 합니다.
  • 양방향 ping pong 메시지를 통해서 한쪽의 연결이 끊겨질 경우에 다른 쪽도 연결을 자동으로 해제하도록 해서 리소스 낭비를 줄였다고 합니다.
  • 연결이 끊긴 이후에는 자동으로 Back-off 시간을 주기로 재연결을 시도하는 매커니즘을 사용한다고 합니다.
  • Healthcheck 매커니즘을 통해서 상담원의 프론트엔드 서버가 일정 시간동안 응답이 없다면 고객은 다른 상담원을 통해서 해결할 수 있도록 시스템을 구축했다고 합니다.

 

Test Results from the New Chat Architecture

우버는 이렇게 새로운 아키텍처로 변경한 후 고객과 상담원 모두에게 좋은 사용자 경험을 제공하기 위해 다양한 기능 및 비기능 테스트를 수행했다고 합니다.

 

다음은 테스트 결과에 대한 내용입니다:

• 확장성: 각 머신이 10,000개의 소켓 커넥션을 설정할 수 있었으며, 이전 아키텍처보다 20배 더 많은 이벤트를 수평적으로 스케일 아웃 할 수 있다고 합니다.
• Shadow Traffic 테스트: 40,000개의 컨택트와 2,000명의 상담원을 대상으로 테스트를 진행했을 때 문제는 나타나지 않았으며, 지연 시간과 가용성은 만족스러웠다고 합니다.
• 신뢰성 테스트: 신뢰성 테스트를 위해 기존 트래픽을 새로운 시스템으로 유도했을 때도 별다른 문제가 발생하지 않았다고 합니다.
• 상담원 자동 로그아웃 기능: 이전 시스템에서는 상담원이 작업을 마치고 탭을 닫아도 시스템에서 온라인 상태로 남는 버그가 있었다고 합니다. 이 버그로 인해 오프라인 상담원에게 이벤트를 전달하려고 시도하여 고객 대기 시간이 늘어나는 문제가 발생하였는데 새로운 시스템에서는 최근 확인 응답을 놓친 경우 자동 로그아웃 기능이 추가되어서 해당 문제는 해결되었다고 합니다.
• 채팅 트래픽 증가: 새로운 채팅 채널은 전체 우버 컨택트 볼륨의 약 36%를 차지하도록 확장되었다고 합니다. 우버는 앞으로 몇 개월 동안 이 비율을 더욱 늘릴 계획이라고 합니다.
• 오류율 감소: 새로운 아키텍처에서 Contact 요청 전달의 오류율이 46%에서 0.45%로 크게 감소했다고 합니다.

 

References:

https://blog.bytebytego.com/p/how-uber-built-real-time-chat-to?utm_source=post-email-title&publication_id=817132&post_id=143745056&utm_campaign=email-post-title&isFreemail=true&r=2clrg7&triedRedirect=true&utm_medium=email