Uber - 엣지+멀티 클라우드 장애 핸들링 이야기 (Part II)

이 글은 우버 기술 블로그인 Engineering Failover Handling in Uber’s Mobile Networking Infrastructure를 의역(https://eng.uber.com/eng-failover-handling/) 한 글입니다. 번역하는 과정에서 오역이나 매끄럽지 못한 부분이 있을 수 있습니다. 문의 사항은 support@imqa.io로 주시길 바랍니다. 원제는 모바일 네트워킹 인프라의 페일오버 엔지니어링이나, 이것보다는 엣지 클라우드 + 멀티 클라우드 페일오버 엔지니어링이라는 것이 더 쉽게 이해할 수 있을 것 같아 부득이하게 이렇게 번역을 하였습니다.  

처음 이 글을 보시는 분은  Uber - 엣지+멀티 클라우드 장애 핸들링 이야기 1편을 읽어 보시길 추천드립니다.

실 세계에서 장애 처리 핸들링

실 세계에서는 우버의 애플리케이션이 다채롭고 흥미롭지만, 어려운 문제들도 접하게 되었습니다. 장애 처리(페일오버) 핸들러의 첫 번째 개선 작업(iteration)이 대부분의 시나리오를 효과적으로 관리했지만, 시스템의 성공을 보장하기 위해, 초기 설계를 개선할 필요가 있었습니다.

사용자가 엘리베이터나 터널에 들어갔을 경우

네트워크 상태가 양호한 사용자가 엘리베이터나 터널에 들어가는 시나리오를 고려해 보십시오. 이는 일시적인 모바일 네트워크 서비스 중단에 불과하지만, 시스템이 공격적으로 반응하여 백업 도메인으로 전환될 경우 앱의 성능이 저하될 수 있습니다.

장애 처리 핸들러를 사용하는 대부분의 경우 상태가 FAILOVER_STATE로 변경되지만 기본 도메인에 대한 요청은 백업 도메인에서 카나리아 요청이 성공하기 전에 복구되어 상태를 다시 PRIMARY_STATE로 전환합니다. 그러나 일부 시나리오에서는 네트워크가 복구되는 즉시 카나리아 응답이 수신되는 경쟁 조건으로 인해 상태가 BACKUP_STATE로 변경되었습니다. 이 경우는 드물지만 시스템이 가능한 한 빨리 PRIMARY_STATE로 다시 전환할 수 있도록 복구 시간제한을 작은 초깃값으로 조정했습니다.

Primary domain (기본 도메인) 을 사용할 수 없는 경우

다른 몇 가지 사례에서, 특정 모바일 통신사를 사용하는 우리의 사용자들은 트래픽이 1차 도메인을 사용할 때 연결 오류에 직면했습니다. 일부 통신사에서는 이 오류가 DNS 시간 초과로 인해 발생한 반면, 다른 경우에는 TLS/TCP 연결 장애로 인해 발생한 것으로 확인되었습니다. 이러한 경우, 중간 인프라가 우리의 통제를 받지 않기 때문에 DNS 제공자, 이동통신사 또는 클라우드 제공자의 문제이든 문제의 근본 원인을 정확히 파악하기가 어렵습니다. 그러나 원활한 앱  경험을 제공하기 위해, 우리 시스템은 오류를 감지하고 백업 도메인으로의 카나리아 요청이 성공적으로 반환된 후,  BACKUP_STATE로 성공적으로 전환하는 데 효과적이었습니다.

이러한 시나리오에 직면하여 우리는 디자인에 몇 가지 추가 작업을 해야 했습니다. 예를 들어, 특정 기간 동안 최소 장애 횟수에 도달하면 FAILOVER_STATE에 대한 페일오버를 트리거 할 수 있는 조건이 하나뿐이었습니다. 그러나 사용자 활동 저하로 인해 앱에서 낮은 트래픽이 생성되는 특정 상황에서는 장애 처리 (페일 오버) 트리거가 지연되는 것을 발견했습니다. 이 문제를 해결하기 위해 다른 시간 초과 임곗값을 추가했습니다. 이 시간 초과에 도달하면 상태 시스템이 최소 장애 횟수에 도달하지 않고도 FAILOVER_STATE로 전환됩니다.

Primary domain (기본 도메인) 복구

소규모 지역 또는 이동통신사로 제한되는 연결 문제 외에도 퍼블릭 클라우드에서 여러 지역 중단 사례가 발생했습니다. 일반적으로 이러한 중단은 일시적이지만 해당 기간 동안 사용자의 상당 부분에게 영향을 미칩니다. 이러한 시나리오에서 시스템은 백업 도메인으로 신속하게 장애 조치를 취한 다음 클라우드 인프라가 복구됨에 따라 기본 도메인으로 다시 라우팅해야 합니다.

위 설계도를 다시 살펴보면, 장애 조치 핸들러는  BACKUP_STATE에 복구 타이머를 유지하고 시간 만료 시 RECOVER_STATE를 진입하여 기본 도메인의 상태를 확인합니다. 이렇게 하면 클라우드 인프라가 복구될 때 모바일 앱이 기본 도메인으로 다시 전환됩니다.

프로덕션에서는 일관된 성능을 보장하기 위해 복구 시간 초과 값을 업데이트하기 위한 메커니즘 설계를 재 평가해야 했습니다. 복구 시간 초과 값을 낮추면 기본 도메인으로 더 빠르게 전환하는 데 도움이 됩니다. 그럼에도 불구하고  Primary_STATE와 BACKUP_STATE 간에 과도한 전환으로 인해 기본(Primary) 도메인이 간헐적으로만 사용 가능한 경우, 최적화된 사용자 환경을 제공하지 못했습니다.

상태 간 전환이 과도하지 않도록 BACKUP_STATE로 전환할 때마다 복구 시간 초과 값을 선형적으로 늘립니다. 이렇게 하면 시스템이 첫 번째 사이클에서 기본 도메인을 적극적으로 시도하지만 이후 사이클마다 프로빙 속도(체크 주기)를 낮출 수 있습니다.

성공 측정하기

(핵심 설계 목표를 만족하는) 장애 처리 핸들러의 효율성을 증명하기 위한 핵심 지표를 보여드리고자 합니다. 기존 솔루션의 단점에 대한 요점을 더욱 강화하기 위해, 이전 섹션에서 설명한 라운드 로빈 기반 페일오버 핸들러(RR)와 페일오버 핸들러(UBER-FH)의 성능을 비교합니다.

기본 도메인의 사용을 최대화하기

첫 번째 목표는 우선 퍼블릭 클라우드 네트워크를 통해 트래픽을 라우팅하여 네트워크 지연 시간을 단축하는 것이었습니다. 그림 1a는 다양한 페일오버 전략에 대한 기본 및 백업 도메인 간의 트래픽 분포를 보여줍니다. UBER-FH는 기본 도메인을 사용하여 트래픽을 거의 99% 라우팅합니다.  그러나 RR은 모바일 네트워크로 인한 오류와 실제 기본 도메인 중단을 효과적으로 구분할 수 없기 때문에 20% 이상의 트래픽을 백업 도메인으로 라우팅합니다.

RR의 경우, 기본 도메인에 연결할 수 없는 경우 백업 도메인에서 새 앱이 시작되도록 지속적으로 캐시 될 때 문제가 더욱 악화되는 것을 목격했습니다. 시스템은 백업 도메인으로 전환하는 데 오류가 발생할 때마다 현재 세션뿐만 아니라 이후의 세션에도 불이익을 줍니다.

Primary 도메인 사용 증가로 인한 성능 영향을 수량화하기 위해 그림 1b는 RR에 대한 UBER-FH를 사용하는 HTTPS 요청에 대한 테일엔드 지연 시간 감소 비율을 보여줍니다. iOS와 Android 모두에서 모든 앱에서 상당한 이득을 보았지만, 특정 앱에서는 더 높은 이득을 보았습니다. 더 높은 이득을 얻는 주된 이유는,  일부 앱들은 상당 부분 모바일 유저들이 접근합니다.  모바일 유저들은 셀룰러 네트워크를 더 많이 사용하기 때문에, 간헐적인 연결(접속)이 더 많이 일어납니다.  

기본 도메인의 사용 증가로 인한 성능 향상은 (i) QUIC 또는 TCP 연결을 (사용자와) 더 가까운 곳에서 종료하면 (네트워크 홉의 감소) 무선 네트워크를 통한 전송 프로토콜의 성능이 향상되고 (ii) QUIC 종료를 위해 현재 클라우드 프런트 엔드 서버에 의존하고 있기 때문에 QUIC의 사용 증가는 두 가지 요소에 기인할 수 있습니다. 아래 그림 2에서 볼 수 있듯이, 우리는 RR에 비해 UBER-FH로 QUIC 사용이 약 5-25% 증가하였습니다.  (역자 의견 : uber의 quic 사용으로 앱 성능을 향상한 별도의 아티클이 존재함)

네트워크 오류를 도메인 중단과 효과적으로 구분하기

카나리아 요청의 사용은 UBER-FH가 네트워크 오류가 있는 경우 도메인의 가용성을 안정적으로 감지하고 대체 도메인으로의 불필요한 전환을 방지하는 데 크게 도움이 되었습니다. 아래 그림 3은 UBER-FH와 RR의 장애 조치 이벤트 수를 비교합니다. 장애 조치 이벤트는 트래픽 라우팅에 사용되는 도메인이 기본 도메인에서 백업 도메인으로 또는 그 반대로 전환되는 단일 이벤트로 정의됩니다. 그림은 사용자 세션 전반의 장애 조치 이벤트 수를 보여줍니다. 구체적으로 말하면, 라이더 세션은 라이더가 한 번의 여행을 하는 것이고, 식사 세션은 먹는 사람이 주문하는 단일 음식 주문입니다. 또한 네트워크 조건, 즉 해당 세션 내 HTTPS 트래픽의 오류 또는 실패율을 기반으로 세션을 그룹화합니다.

그림에서 명확하게 알 수 있듯이 RR 기반 장애 조치는 몇 가지 네트워크 오류가 발생하는 평균 네트워크 조건에서도 도메인 전환에서 너무 반응적입니다. 더 심각한 조건에서 RR은 여러 네트워크 오류가 발생했기 때문에 상당한 도메인 전환이 발생했습니다. 대신 UBER-FH는 대기 시간이나 가용성을 손상시키지 않으면서 심각한 네트워크 조건에서도 장애 조치 이벤트의 수를 크게 줄이는 데 효과적인 것으로 입증되었습니다.

우리는 높은 네트워크 오류율동안 UBER-FH가 불필요하게 백업 도메인으로 전환하는 몇 가지 사례를 보았습니다. 이러한 경우 네트워크가 복구되면 카나리아 요청의 성공이 일반 요청의 성공보다 먼저 처리되어 BACKUP_STATE로 전환되는 것을 보았습니다. 그러나 이러한 인스턴스는 현재 드물게 존재하며, 복구 시간 타임아웃의 초깃값 설정 후에는, 장애 조치 핸들러가  PRIMARY_STATE로 빠르게 다시 전환하는데 효과적입니다.

기본 도메인 중단 시 성능 저하 감소

UBER-FH의 설계를 높이 평가하려면 주 도메인이 간헐적으로 사용할 수 없는 동안 UBER-FH가 작동하는 방식을 측정하는 것이 중요합니다. 특정 국가 C에서 특정 통신사(c4로 명명됨)를 사용하는 사용자의 기본 도메인에서 DNS 오류가 대부분 많이 발생했습니다. 그림 4(왼쪽)는 C 국가의 8개 이동 통신사에 대한 일차 및 백업 도메인을 사용한 트래픽의 분포를 나타냅니다. 그림에서 볼 수 있듯이 UBER-FH는 트래픽이 1차 도메인 가용성에 문제가 있었던 통신사 c4의 백업 도메인으로 다시 돌아가도록 하는 데 효과적입니다.  더 중요한 것은, 우리의 설계 선택사항이 통신사 c4 사용자들의 사용자 경험이 나빠지지 않도록 보장했다는 것입니다. 그림 4(오른쪽)에서 동일한 기간 동안 모든 캐리어(통신사)에 대한 오류율을 표시합니다. 오류율은 실패한 HTTPS 요청 수를 총 HTTPS 요청으로 나눈 값으로 정의됩니다. 분명히 캐리어 c4의 트래픽에 대한 오류율은 동일한 국가의 다른 캐리어(통신사)에서 볼 수 있는 오류율 범위 내에 있습니다.

앞으로 해야 할 것들

장애 조치 핸들러가 Uber 플랫폼의 모든 사용자에게 성공적으로 배포되어 애플리케이션 응답 시간이 단축되고 전반적인 고객 경험이 향상되었습니다. 앞으로 우리는 시스템의 신뢰성을 더욱 향상시키기 위해 생산에서 얻은 모든 학습과 데이터를 활용할 계획입니다. 특히, 모바일에서의 의사 결정을 더욱 강화하기 위해 지역, 네트워크 유형, 통신 사업자의 사용자 전반에 걸쳐 성능 및 안정성을 예측하기 위해 과거 데이터를 사용할 수 있는 시스템을 평가하고 있습니다.  여러 클라우드 공급자를 활용할 수 있는 옵션을 통해 사용자 세션별로 최고의 클라우드 공급자 또는 사내 인프라를 실시간으로 사용하여 지연 시간을 더욱 줄이는 동시에, 잠재적으로 비용을 절감할 수 있는 과제를 해결하는 것을 목표로 합니다.

감사의 말
이 프로젝트에 기여한 Vinoth Chandar와 Jatin Lodhia에게 감사드립니다.

이 글을 번역하며
저 역시 인프라 분야에는 전문가가 아니라, 부족한 번역이 있을 수 있습니다.  개선 사항이나 의견이 있으면 support@imqa.io로 주시길 부탁드립니다.