[17 SOSP] Canopy: An End-to-End Performance Tracing And Analysis System

Evaluation

Canopy는 Facebook의 production 환경에서 지난 2년 동안 배포 및 사용되어 왔다. 이번 장에서는 Facebook 엔지니어가 성능 문제를 진단하기 위해 Canopy가 어떻게 사용되어 왔는지를 보여준다. Canopy의 오버헤드와 load-shedding 속성들을 평가한뒤 2.2장에서 설명한 챌린지들을 해결하기 위한 방법을 보여준다.

Canopy는

- 서로 다른 동작을 하는 여러 이기종 시스템에서 신속한 성능 진단 및 성능 모델을 만들 수 있게 한다.

- 많은 사용자가 동시에 서로 다른 목적의 용례를 위한 커스터마이징을 가능하게 한다.

- 새로운 용례 및 실행 조건에 맞게 독립적으로 trace model을 개선할 수 있게 한다.

- 적은 오버헤드로 많은 수의 trace를 볼 수 있다.

5.1 Overhead

5.2 Load Shedding

Production 환경을 미러링한 뒤 load를 서서히 증가시키며 2시간 40분 동안 tail의 성능을 측정한다.

5.3 Trace Model Evolution

새로운 user case가 발생했을 때 기존의 system instrumentation을 수정하지 않고 trace model을 바꿀 수 있다.

5.4 Case studies

Casual Ordering

Facebook.com page load process는 페이지를 조각으로 나누어 그룹을 만든 후 초기에 로드되는 것이 중요한 페이지 조각 그룹을 먼저 표시되도록 그룹을 정렬한다. 개발자는 이 단계를 분석하는 과정에서 가장 높은 우선 순위의 critical path에 낮은 우선 순위의 페이지 조각 그룹인 'Sugesstions'가 나타난 것을 발견하였다 (Figure 12a). 더 자세한 조사를 위해 개발자는 어떤 특정 'Sugesstions' block이 critical path에 나타나는지 확인하고 평균 reqeust latency(Figure 12b)와 상호 참조하여 비교를 해봤다. 그 결과 'Suggestions'가 client-side critical path에 있는 경우 높은 latency가 발생한 것을 발견할 수 있었다 - 서버는 모든 페이지 조각을 전송했지만 클라이언트의 처리 속도가 느린 것을 확인했다. 그러나 서버 측 critical path에 'Suggestions'가 있었다는 것은 의외의 사실이었다. 개발자는 관련된 trace를 검사하였고 root cause를 찾았다: 일부 비동기 연속 작업(asynchronous continuations)이 다르게 처리되어 나타난 서버 실행 환경의 버그였다. 결과적으로 서버는 코드가 없더라도 이러한 연속을 기다릴 수 있다. Figure 12c를 보면 영향을 받은 request의 execution timeline을 볼 수 있다. 서버가 initial request를 수신받았을때, 'Suggestions'에 관련된 비동기 호출이 실행되는 것을 볼 수 있다. 하지만 이 연속(continuation)을 기다리며 예기치 않게 block 대기가 발생하였다. 일반적으로 서버는 우선 순위가 높은 초기 페이지 조각을 flush 했을 것이다. 대신 실행  이 문제는 request의 subset에서 발생했지만, Canopy를 통해서 이러한 문제를 파악할 수 있었다. 커스터마이즈된 feature extraction을 통해 이 문제가 전체 성능에 끼치는 영향도 식별할 수 있었다.

Regressions in Subpopulations

성능 변화는 내부 환경의 변경으로 발생하는 경우도 있지만 외부 환경의 변화로 인해 변화될 때도 있다. 예를 들면 2016년 12월과 2017년 1월에 각각 사이클론과 여러 해저 케이블 절단으로 인해 인도에 인터넷이 여러 차례 중단된 경우가 있다. 이로 인해 영향권에 속한 end-user의 성능이 저하되었으며, 이로 인한 최대 50ms의 페이지 로드 대기 시간은 global regression(전역 회귀)을 발생시킬 만큼 충분히 컸습니다. 국가는 추출된 기능이므로, 해당 축에서 데이터를 분할하면 차이가 명확하게 표시되는 반면 critical path 분석은 예상대로 해당 end-user에게 가장 큰 변화가 네트워크 및 리소스 다운로드에 있음을 보여주었습니다. 여기에서 Canopy는 엔지니어가 원인을 신속하게 식별하는데 도움을 주었다.

Identifying Improvements

Data set을 탐색하는 것 외에도 Canopy의 trace를 사용하여 가상 분석을 수행할 수도 있다. 2.1 장에 설명된 early flush 컴포넌트를 담당한 엔지니어는 critical path에서 성능 저하의 원인을 고려하여 페이지 로드 시간을 개선했다. 분석에 따르면 클라이언트는 페이지 로드가 완료되기 전에 추가 리소스(CSS/JavaScript)를 기다리는 critical path에서 과도한 시간을 소비하고 있었다. 이것은 Facebook.com이 나중에 필요할 것으로 예상되는 페이지의 시작 부분에서 이미 리소스를 보냈기 때문에 발생했다. 하지만 페이지 조각을 구성 후 추가 리소스가 필요할 수도 있다. 페이지 로드 중간에 리소스의 두 번째 wave(우선 순위가 낮은 페이지 조각에서 일반적으로 사용되는 리소스)를 보내면 입증된 눈에 띄는 성능 향상이 될 것으로 예상하고 성능 개선에 성공하였다.

Mobile Clients

Exploratory Analysis

Custom Analysis

7 Related Work

2.2 장에서 Canopy가 해결할 문제에 대해 논의했다. 이 장에서는 다른 연구들에 대한 논의로 이를 구체화한다.

Generating Performance Data

분산 시스템 문제 해결을 위한 기존 도구는 다양한 입력 데이터를 사용한다. 프로세스별 혹은 구성요소별 로그를 수집하는 도구 [29, 37, 66], 인과 관계 이벤트 데이터를 생성하는 end-to-end tracing 도구 [12, 24, 39, 50, 54, 60]; system-level metric 및 perfomrance counter를 추적하는 상태 모니터링 시스템[36]; 애플리케이션 수준 모니터링 데이터를 수집하고 요약하는 집계 시스템[30, 34, 61] 이 있다. Wang et al.은 [63]에서 데이터 센터 문제 해결 도구에 대한 포괄적인 개요를 제공한다. 이러한 모든 데이터는 다양한 종류의 분석에 유용하기 때문에 Canopy는 이러한 광범위한 데이터에 대한 공통 진입점을 제공하도록 설계되었다.

Canopy와 마찬가지로 많은 도구는 request의 execution path를 따라 indentifier를 전파하여 이벤트 간의 인과 관계를 명시적으로 기록한다[12, 24, 39, 50, 54, 60]. 이전 시스템은 공유되는 통신 및 동시성 계층에서 컨텍스트를 전파하여 계측 부담(§2.2 참조)을 완화한다[24, 49, 54, 56]. 최근 연구에서는 소스 및 바이너리 재작성 기술을 사용하여 공통 실행 모델을 자동으로 계측한다[26, 32, 34, 48].
계측 시스템에 대한 다른 접근 방식은 로그와 같은 기존 출력을 사용하여 ​상관 관계 또는 인과 관계를 추론하는 것이다. 이러한 접근 방식에는 여러 로깅 문에 있는 식별자(예: call ID, IP address 등)를 결합하는 작업이 필요하거나[16, 22, 29, 58, 66, 67]; 기계 학습 및 통계 기술을 사용하여 인과 관계 추론을 하거나 [18, 35, 38, 66]; 정적 소스 코드 분석을 통한 모델 보강[66–68]을 하는 방법을 사용한다. 하지만 실제로 인과 관계를 추론하는 데 비용이 많이 들기 때문에 블랙박스 분석을 확장하는 것은 어렵다. 예를 들어 Mystery Machine[22]의 경우 130만 개의 추적에서 Facebook 모델을 계산하는 데 2시간이 걸렸다. Canopy는 샤딩된 백엔드로 인해 현재 하루에 13억 개의 트레이스를 얻고 있으며, 트레이스나 샤드 간에 통신이 필요하지 않다는 장점이 있다(§4.3 참조).

Analyzing Data

분산 시스템의 여러 문제들을 해결하기 위해 다양한 자동화된 분석 기술을 제시되었다. 성능 이상 현상의 근본 원인을 반자동으로 검출하는 기술[64]; 통계적 anomaly 식별 [29]; 온라인 통계 이상치 모니터링 [15]; critical path 종속성, slack, speedup 분석 [22,47]; 그리고 trace의 'before'과 'after' 사이의 구조적, 통계적 차이를 설명[35, 51]하는 연구가 있다. 수동 분석은 훨씬 더 광범위한 문제를 다룬다. 구조나 타이밍이 표준에서 벗어난 요청 분석[2, 17, 20, 21, 46, 51]; 느린 컴포넌트 및 함수 식별 [19, 35, 54]; 워크로드 및 리소스 사용 모델링 [16, 17, 35, 58]과 같은 연구가 있었다. 26개 회사의 production 환경에 배포된 tracing 도구의 use case는 개별 anomalous request 디버깅에서부터 performance, resource, and latency metric 캡처, failure와 behavioral 상관 관계를 사용한 clustering 에 이르기까지 다양하다[33].

Canopy는 이러한 기술을 제거하지 않고 많은 기술을 적용할 수 있는 입력 데이터를 생성하는 데이터 추출 파이프라인을 제공한다. 예를 들어, Spectroscope[51]는 트레이스 구조를 비교하고 ANOVA 테스트를 수행하여 트레이스 전과 후 세트 간의 regression을 진단한다. 비슷하게 Facebook 개발자는 여러 feature 간의 상관 관계를 찾고 여러 distribution (e.g. 어플리케이션의 버전)의 성능을 비교하기 위해 statistical comparison 기술을 사용했다. 그러나 operator-driven exploration(운영자 주도 탐색)은 두드러진(salient) feature를 식별하기 위한 대부분의 자동화된 접근 방식의 전제 조건이다[37]. Alspaugh et al. 은 Splunk (모니터링 도구)의 활용을 분석한 결과 통계 및 기계 학습 추론 기술의 사용은 "상대적으로 드물며" 인간의 추론이 분석의 핵심이라고 언급했다[3]. Canopy의 주 목적은 ad hoc high-level exploratory analysis를 지원하는 것이다. 왜냐하면 실제로 발생하는 문제는 예측하기 어렵고 탐색할 잠재적 feature가 광범위하기 때문이다[34].

몇몇 이전 시스템은 유사한 ad hoc exploration을 지원한다. G2 [25]는 raw trace 수준에서 실행 추적에 대한 쿼리를 작성하기 위한 시스템이므로 §2.2의 확장성 및 추상화 문제에 직면해 있다. 예를 들어, 1억 3천만 개의 이벤트에 대한 G2 쿼리를 평가하는 데 100초가 걸립니다. 이에 비해 interactive Canopy 쿼리는 수조 개의 이벤트를 처리할 수 있다. 계층화된 샘플링은 대략적인 결과를 반환하여 쿼리 시간을 개선할 수 있다[62]. 유사하게, 30일보다 오래된 과거 데이터의 경우 Scuba는 하위 표본을 추출하고 신뢰 범위를 제공합니다(§4.5 참조). Pivot Tracing[34]은 운영자가 진단 프로세스 동안 새 쿼리를 반복적으로 설치할 수 있도록 하는 동적 계측 프레임워크이다. 그러나 전체 추적을 캡처하고 저장해야 가능한 historical analysis에는 적용할 수 없다.