대규모 시스템을 위한 저비용 모니터링 도구를 구축하는 방법은?

프로덕션 서비스를 운영하려면 내부에서 무슨 일이 일어나는지 알아야 하지만, 메트릭을 추가하는 데에는 비용이 따른다. InfoQ가 게시한 발표에서 IOP Systems의 공동 창립자인 Brian Martin은 구현에 따라 차이가 발생해 카운터 업데이트가 약 5나노초가 걸리는 작업에서 1마이크로초를 넘는 작업으로 바뀔 수 있다고 설명한다. 히스토그램의 경우 스레드 간 경쟁이 발생하면 차이가 약 7나노초에서 수십 마이크로초로 확대될 수 있다.

발표의 핵심은 특정 Rust 라이브러리를 선택하는 것이 아니라, 측정을 성능 설계의 일부로 다루는 데 있다. 수백만 번 호출되는 경로에 배치된 메트릭은 작은 비용이라도 증폭시키는 반면, 측정이 없으면 지연, 프로덕션 장애, 성능 개선을 진단하기가 더 어려워진다.

데이터 유형과 업데이트 비용을 이해하는 것부터 시작하라

Martin은 메트릭을 세 가지 주요 유형으로 구분한다. 일반적으로 감소하지 않는 요청 수와 같은 카운터, 큐 깊이와 같은 현재 값을 나타내는 순간값, 응답 시간과 같은 값의 분포를 설명하는 히스토그램이다. 각 유형은 서로 다른 연산을 요구하고, 히스토그램은 하나의 총합 카운터로는 얻을 수 없는 정보를 제공하므로 이 구분은 중요하다.

가장 단순한 경우에는 정수 카운터에 atomic fetch_add가 적합하다. 반면 비교 및 교환 루프, 즉 CAS는 여러 스레드가 같은 위치에서 경쟁할 때 일반적으로 재시도가 필요하다. 비용의 상당 부분은 코어 간 캐시 라인의 동기화에서 발생한다. 발표에서는 32개의 가상 프로세서를 갖춘 AWS Graviton에서 측정한 결과를 제시한다. 저비용 원자적 업데이트를 사용했을 때 이론상 처리량 상한은 초당 약 1억 1,900만 요청이었고, Prometheus와 함께 더 높은 비용의 구현을 사용했을 때는 약 2,300만 요청이었다.

프로세서별 분할로 경쟁을 줄여라

모든 스레드가 하나의 카운터를 공유하면 캐시 라인이 코어 사이에서 계속 이동한다. Martin은 대신 프로세서마다 별도의 카운터를 만들어 쓰기 작업이 거의 경쟁 없이 이루어지도록 한 뒤, 읽을 때 값을 합산할 것을 제안한다. 이 방식은 읽기 비용을 약간 높이지만, 모든 요청에서 반복되는 쓰기 핫패스를 보호한다.

여기서 false sharing 현상에 주의해야 한다. 논리적으로 별개의 카운터를 사용하는 것만으로는 충분하지 않다. 하나의 캐시 라인에 배치되면 64바이트인 캐시 라인 안에 64비트 카운터 8개가 나란히 들어갈 수 있기 때문이다. 따라서 발표에서는 카운터를 그룹화하고 패딩하여 서로 다른 캐시 라인을 차지하도록 권장한다. 제시된 수치에 따르면 적절한 분할을 사용하면 이론상 성능이 원자적 카운터를 사용한 초당 약 1억 1,900만 요청에서 초당 약 64억 요청으로 높아질 수 있다.

업데이트 경로를 위해 히스토그램을 설계하라

히스토그램의 비용은 값이 속하는 버킷을 결정하는 것에서 시작된다. 버킷 목록을 선형 검색하는 방식은 가장 단순하지만 가장 느리고, 이진 검색은 비교 횟수를 줄이지만 여전히 버킷 수의 영향을 받는다. 더 빠른 대안은 값을 검색하는 대신 값으로부터 버킷 번호를 계산하는 직접 인덱싱이다.

이 인덱싱에는 여러 절충점이 있다. 선형 범위로 나누는 방식은 빠르지만 작은 값에서 상대 오차가 비교적 커질 수 있다. 로그 인덱싱은 상대 오차를 더 잘 유지하지만 로그 자체를 계산하는 비용이 크다. Martin은 Log2를 기반으로 한 외부 범위와 정밀도를 조절하는 하위 버킷을 사용하는 방법을 소개하며, HDR Histogram과 H2Histogram이 그 예다. 비원자적 테스트에서 버킷 결정과 업데이트에는 HDR Histogram이 약 2.65나노초, H2Histogram이 약 2.15나노초가 걸렸다.

근사적 일관성은 언제 허용되는가?

히스토그램의 비용은 인덱싱 방식만으로 결정되지 않는다. 일부 애플리케이션은 각 작업에서 여러 원자적 연산을 수행하거나, 값의 합계에 CAS를 사용하거나, 일관된 스냅샷을 얻기 위해 잠금을 사용한다. 발표에 따르면 일부 구현은 1마이크로초를 넘었고, 32코어에서 수십 마이크로초에 이르기도 했다. 반면 직접 인덱싱과 단일 원자적 업데이트를 기반으로 한 구현은 카운터의 비용에 더 가까웠다.

대안은 근사적 일관성이다. 히스토그램을 읽는 동안 일부 버킷이 변경될 수 있지만, 메트릭 자체가 원래 근사적이라면 연속된 두 번의 읽기 사이의 차이도 여전히 유용하다. 이는 모든 경우에 적용되는 규칙은 아니다. 완전히 일관된 스냅샷이 필요한 시스템은 비용이 들더라도 동기화를 선호할 수 있다.

certi.news의 편집적 해석

실무에서 달라지는 점은 메트릭을 추가할지 결정할 때 메트릭의 이름뿐 아니라 업데이트 구조도 함께 고려해야 한다는 것이다. 원자적 카운터, 프로세서별 분할, 직접 인덱싱을 사용하면 민감한 경로 안에서도 측정을 사용할 수 있게 되는 반면, 동기화되거나 동적으로 확장 가능한 히스토그램은 부하가 높은 상황에서 큰 비용을 초래할 수 있다. 발표는 모든 라이브러리나 서비스에 적용되는 하나의 해법을 제시하지 않는다. 유연성, 다른 프로젝트에서의 라이브러리 사용 가능성, 일관성, 성능은 부분적으로 서로 충돌하는 목표임을 보여준다. 따라서 라이브러리의 이름이나 경쟁이 없는 상태의 결과에 의존하기보다, 목표로 하는 경쟁 수준과 처리량에서 실제 구현을 테스트해야 한다.

Martin은 또한 Rezolus 프로젝트를 통해 eBPF를 사용하여 Linux 커널을 수정하지 않고도 스케줄러, 시스템 호출 경로, TCP 스택을 포함한 정밀한 메트릭을 얻는 방법을 소개한다. 여전히 열린 질문은 각 상황에서 어느 정도의 정밀도와 일관성이 필요한지, 그리고 시스템을 확장할 때 읽기 또는 조각 수집 비용이 계속 허용 가능한 수준으로 유지될지 여부다.