쿠버네티스의 OpenTelemetry 수집기 배포 모드

쿠버네티스 클러스터에서 텔레메트리의 전체 적용 범위를 보장하기 위해 OpenTelemetry 수집기(collector)를 구현하는 것은 쉽지 않은 일입니다. 쿠버네티스 환경에서 수집기를 올바르게 설정하려면 기술 지식 뿐만 아니라 옵저버빌리티 요구 사항과 시스템 내의 데이터 흐름에 대한 심층적인 이해가 필요합니다. 

이 프로세스를 간소화하는 좋은 방법은 "수집기 배포 모드"를 사용하는 것입니다.  쿠버네티스 내에서 애플리케이션 및 시스템 데이터를 수집, 처리, 내보낼 수 있도록 수집기를 다양한 방법으로 설정하고 관리할 수 있습니다. "배포 모드(deployment mode)"는 "배포 패턴(deployment pattern)"과 다르다는 점을 알아두는 것이 중요합니다. 

이 블로그 게시물에서는 이러한 핵심 개념을 설명하고 옵저버빌리티 전략에 맞게 올바른 배포 모드를 선택하는 데 필요한 기본 지식을 제공합니다. 포함된 내용은 다음과 같습니다. 

• 수집기 배포 패턴과 모드의 차이점
• 수집기 배포 모드가 중요한 이유
• 쿠버네티스 환경에서 사용되는 가장 일반적인 수집기 배포 모드

수집기 배포 패턴 vs. 배포 모드

수집기 배포 패턴은 수집기를 사용해(또는 사용하지 않고) 전체 텔레메트리 수집 전략을 구성하는 방법에 대한 높은 수준의 아키텍처 접근 방식을 말합니다. 

일반적으로 주요 패턴은 다음과 같습니다.

• No Collector: 텔레메트리를 애플리케이션에서 백앤드로 직접 보냅니다. 이러한 접근 방식은 데이터 처리가 필요하지 않은 소규모 애플리케이션이나 테스트 목적에 가장 적합합니다. 
• Agent: 수집기를 배포하는 가장 간단한 방법은 애플리케이션 텔레메트리를 수집기 에이전트로 라우팅하는 것입니다. 그러면 수집기 에이전트는 필요에 따라 모든 처리를 하고 데이터를 하나 이상의 백앤드로 내보냅니다. 이 패턴은 일반적으로 애플리케이션과 동일한 노드에서 수집기를 실행하거나 애플리케이션 파드의 사이드카 컨테이너로 실행하는 것을 의미합니다. 
• Gateway: 이 패턴은 중앙화된 수집 지점을 생성합니다. 애플리케이션 또는 기타 수집기는 단일 OTLP(OpenTelemetry Protocol) 엔드포인트로 텔레메트리를 보내며, 엔드포인트는 독립형이지만 확장 가능한 서비스로 실행되는 하나 이상의 수집기 인스턴스로 지원됩니다. 
• Layered: 이 패턴은 수집기를 두 계층으로 설정합니다. 일반적으로 첫 번째 계층 수집기는 Trace ID/Service 이름을 인식하는 로드 밸런싱 익스포터 툴로 구성되고 두 번째 계층 수집기는 확장을 처리합니다. 테일 샘플링 프로세서와 로드 밸런싱 익스포터를 사용할 때, 이 패턴은 테일 샘플링된 스팬의 로드 밸런싱을 지원하여 동일한 트레이스 ID를 가진 모든 스팬이 동일한 수집기 인스턴스에 도달하도록 하고 트레이스의 단편화를 방지합니다. 

수집기 배포 모드는 쿠버네티스 환경에서 이러한 패턴을 구현하는 데 사용하는 특정 쿠버네티스 메커니즘을 말합니다. 쿠버네티스에서 수집기를 실행하는 "방법"은 다음과 같습니다. 

• Deployments/StatefulSets 독립형 수집기 파드를 실행합니다.
• DaemonSet 노드당 하나의 수집기 파드를 보장합니다.
• Sidecar 애플리케이션 컨테이너와 동일한 파드에 인접한 컨테이너에서 수집기를 실행합니다.

패턴과 모드의 차이점을 설명하기 위해, 에이전트 패턴과 게이트웨이 패턴을 전략적으로 결합한다고 가정해 보겠습니다. 이를 쿠버네티스에서 구현하려면 클러스터에서 수집기를 배포할 수 있도록 다음 모드를 구성합니다. 

• DaemonSet 모드 - 에이전트 수준 수집기
• Deployment 모드 - 게이트웨이 수집기

참고: "Deployment"라는 배포 모드가 실제로 있습니다. 자세한 내용은 이 설정 예를 참조하십시오. 

배포 모드를 고려해야 하는 이유 

각 모드는 시스템의 특정 요구 사항과 아키텍처에 따라 고유한 장단점이 있습니다. 또한, 앞서 설명한 대로 다양한 사용 사례에 맞게 모드를 결합할 수 있습니다. 

다음 사항을 고려해야 합니다. 

• 확장성 요구 사항: 얼마나 많은 데이터를 처리할 것으로 예상하는가? 이는 필요한 수집기 인스턴스 수에 영향을 미칩니다. 
• 성능 요구 사항: 데이터 수집과 처리에서 레이턴시가 낮은 것이 얼마나 중요한가? 
• 장애 허용도 및 고가용성: 높은 수준의 복원력과 안정적인 데이터 수집이 최우선 순위인가?
• 운영의 복잡성: 여러 인스턴스를 관리하고 설정하는 팀의 역량은 어떠한가? 세부적인 설정 옵션이 필요한가? 
• 리소스 활용: 어떤 컴퓨팅 및 네트워크 리소스를 사용할 수 있는가? 네트워크의 용량과 구조가 수집기 인스턴스 확장을 지원할 수 있는가? 

고려해야 할 또 다른 측면은 수집기를 사이드카나 DaemonSet 등의 에이전트로 실행하는 경우 수집기 인스턴스가 많기 때문에 리소스 관점에서 비용이 많이 들 수 있다는 것입니다. 그러나 수집기는 애플리케이션과 동일한 물리적 노드에서 실행되기 때문에, 수집기가 클러스터 외부에 있거나 다른 노드에 있는 경우보다 앱에서 텔레메트리를 내보내는 것이 훨씬 더 빠릅니다. 또한 이러한 방법은 백앤드에 도착하기 전에 호스트 ID 속성 같은 문맥 정보를 텔레메트리 데이터에 첨부하기가 더 쉽습니다. 

쿠버네티스에서의 수집기 배포 모드

쿠버네티스 환경에서 수집기에 적용할 수 있는 주요 배포 모드는 중앙화된 수집기는  Deployment 모드이고, 인스턴스가 각 쿠버네티스 노드에서 실행되어 각 호스트로부터 수집을 허용하는 분산 수집기는  DaemonSet 모드입니다. 특정 요구 사항에 따라 예측 가능한 이름을 가진 한정된 수의 복제본에 StatefulSet 모드를 사용할 수도 있습니다. 

Deployment 모드

Deployment 모드에서 수집기를 설치하는 것은 일반적으로 다음과 같은 클러스터 수준 데이터를 수집하는 데 사용됩니다.

• 클러스터 내의 문제 해결에 유용한 쿠버네티스 이벤트
• 컨트롤 플레인 구성 요소의 성능에 대한 가시성 확보를 위한 컨트롤 플레인 메트릭
• 클러스터에 있는 다양한 쿠버네티스 개체의 상태에 대한 메트릭을 제공하는 kube-state-metrics

이러한 데이터 소스는 전체 클러스터를 나타내기 때문에, 동일한 엔드포인트에서 동일한 메트릭을 수집하는 수집기 인스턴스가 여럿 있을 수 있는 DaemonSet 모드를 사용하는 것은 권장하지 않습니다.

하지만 Deployment 모드에서는 명심해야 할 몇 가지 사항이 있습니다. 그 중 하나는 데이터가 중앙의 수집기로 이동해야 하므로 네트워크 오버헤드와 레이턴시가 증가할 수 있으며, 트래픽이 많은 기간에는 병목 현상이 발생할 가능성이 있다는 것입니다. 또한, Deployment 모드 수집기를 확장하려면 로드 밸런싱의 복잡한 설정이 필요할 수도 있다는 점을 고려해야 합니다. 수집기를 확장하지 않으면 단일 장애 지점이 발생하여 수집기를 사용할 수 없게 되거나 과부하가 걸리면 데이터가 손실될 위험이 있습니다. 

이러한 고려사항 때문에 보통 여러 다른 모드에서 실행되는 수집기를 여러 개 구현합니다. 각 수집기는 이러한 제한이 특히 큰 영향을 미치는 특정 사용 사례를 위해 사용됩니다. 

DaemonSet 모드

DaemonSet 모드에서 수집기는 쿠버네티스 클러스터의 모든 노드에서 파드로 실행되므로 시스템 메트릭, 로컬 로그 수집 또는 네트워크 모니터링 같은 인프라 성능 메트릭을 수집하는 데 적합합니다. 애플리케이션의 맥락에서, 이 모드는 텔레메트리를 위해 레이턴시와 네트워크 오류의 가능성을 줄이는 노드-로컬 엔드포인트를 제공합니다.

다음 이미지는 DaemonSet 모드로 배포된 수집기의 아키텍처를 보여줍니다.

쿠버네티스 노드에서 메트릭을 수집하는 데에는 몇 가지 옵션이 있습니다. 첫 번째는 호스트 메트릭 수신기로, CPU 사용량, 메모리, 디스크 입출력(I/O) 등 노드에서 직접 필수적인 시스템 메트릭을 수집하는 것입니다. 기본 시스템 메트릭이 필요한 경우 이 구성 요소를 사용합니다. 설정도 쉽고 OpenTelemetry에서 바로 지원됩니다. 이 수신기를 사용하는 방법을 보여주는 저장소의 예시를 확인해 볼 것을 권합니다. 

노드에서 더 광범위한 메트릭을 원하는 경우 또 다른 옵션은 Prometheus 수신기와 Prometheus 노드 익스포터 툴을 결합하는 것입니다. 이 조합은 호스트 메트릭 수신기를 통해 사용할 수 없는 고급 시스템 메트릭을 포함해 300여 개의 고유한 메트릭 이름을 제공합니다. 그러나 많은 수의 메트릭은 상당한 비용을 야기할 수 있습니다.

• 높은 카디널리티 및 데이터 스토리지: 많은 메트릭을 관리하면 스토리지 및 처리 비용이 증가할 수 있습니다.
• 운영의 복잡성: 실행되지 않는 과도한 데이터의 생성을 방지하려면 알림과 쿼리의 세부 조정이 필요합니다.

워크로드 메트릭을 수집하려면 Kubelet Stats 수신기를 사용할 수 있습니다. 이 수신기는 각 노드의 쿠버네티스 Kubelet에서 직접 메트릭을 가져옵니다. 추가 툴 없이도 쿠버네티스 컨테이너를 직접 모니터링할 수 있는 효율적인 방법입니다. 컨테이너 CPU 및 메모리 사용량, 파드 수준의 리소스 할당 등 유용한 메트릭을 제공합니다. 

또는 Prometheus 수신기를 사용하여 쿠버네티스 cAdvisor(컨테이너 수준 메트릭 집계)와 같은 소스에서 메트릭을 스크래핑할 수 있습니다. 이러한 메트릭은 기존 옵저버빌리티 설정에서 일반적으로 사용됩니다.

수집기를 DaemonSet 모드로 배포하는 경우 노드의 파일 시스템에 작성된 컨테이너 로그를 캡처하도록 파일 로그 수신기를 설정할 수 있습니다. 그러나 이미 앱에서 수집기로 직접 로그를 전송하고 있을 수도 있으므로 담당 개발자에게 먼저 문의하시기 바랍니다. 

Deployment와 DaemonSet 모드의 주요 차이점은 배포 전략에 있습니다. 표준 OpenTelemetry 수집기 배포는 중앙화되고 확장 가능한 수집 지점을 제공하는 반면, DaemonSet 수집기는 보편적인 노드 수준의 데이터 수집을 보장합니다. 이러한 배포 패턴을 조합하여 서비스 수준 및 인프라 수준의 텔레메트리 데이터를 모두 캡처하는 포괄적인 옵저버빌리티 전략을 수립하는 조직들이 많습니다.

StatefulSet 모드

StatefulSet 모드에서 수집기를 배포하면 영구 스토리지나 안정적이고 고유한 네트워크 ID가 필요한 사용 사례를 지원할 수 있습니다.  StatefulSet 모드에서 수집기를 실행하는 가장 일반적인 사용 사례는 다음과 같습니다. 

• 다수의 Prometheus 엔드포인트를 포함하는 대규모 쿠버네티스 클러스터: StatefulSet은 Target Allocator와 결합하여 사용될 수 있으며, 이 경우 수집기 인스턴스 풀 전반에서 Prometheus 타깃을 균등하게 분배할 수 있습니다.
• 부하 분산 및 테일 샘플링: StatefulSets 모드는 로드 밸런싱 익스포터 같은 프로세서를 위한 데이터 영속성과 안정적인 호스트 이름이 필요할 때 적합합니다. 테일 샘플링이 성공하려면 주어진 트레이스에 대한 모든 스팬을 동일한 수집기 인스턴스로 보내야 합니다. 

핵심 정리

쿠버네티스에서 OpenTelemetry 수집기를 구축하는 방법은 여러 가지가 있지만, 이 예시는 보다 보편적인 "패턴" 중 하나입니다. 쿠버네티스에서 OpenTelemetry를 구현하는 경우 모든 사용 사례를 충족시킬 수 있도록 계층화 또는 체인 수집기가 필요할 수 있습니다. 대부분의 복잡한 아키텍처와 마찬가지로, 여러 가지 주의 사항과 고려 사항이 있지만, 이 글이 적어도 생각해 볼 수 있는 시작점이 되길 바랍니다. 

Deployment 

Deployment 수집기는 독립형으로 실행되며 Kube State 메트릭, 쿠버네티스 이벤트 및 API 서버 메트릭을 포함한 "클러스터 전반"에서 데이터 수집을 담당합니다. Deployment 모드로 이러한 데이터를 수집하면 DaemonSet의 일부로 이러한 설정을 실행하려고 할 때 발생할 수 있는 데이터 중복을 방지할 수 있습니다.

DaemonSet

DaemonSet 수집기는 각 노드에서 에이전트로 실행됩니다. 쿠버네티스 노드 메트릭, Kubelet 및 cAdvisor의 워크로드 메트릭, 노드 파일 시스템의 로그를 수집하는 역할을 합니다. 또한 애플리케이션은 동일한 노드에 위치한 에이전트로 트레이스를 보낼 수도 있습니다.

Gateway

Gateway 수집기는 최종 처리 및 데이터 변환에 사용되며 여러 백앤드로 데이터를 팬아웃할 수 있습니다. 이는 Deployment 또는 StatefulSet가 될 수 있습니다. 로드 밸런서는 상용이든 로드 밸런싱 익스포터를 실행하는 수집기이든(예: 테일 샘플링 사용 사례), 수집기 게이트웨이 앞에 위치하여 텔레메트리가 게이트웨이 수집기 인스턴스 전반에 균등하게 분산되도록 보장합니다. 

추가 고려 사항

각 수집기 배포 모드에는 고려해야 할 장단점이 있지만, 수집기를 설계할 때 고려해야 할 추가 사항은 다음과 같습니다.

• 테넌시(Tenancy): 클러스터가 단일 테넌트인가 아니면 다중 테넌트인가? 이에 따라 데이터는 어떻게, 어디로 라우팅되는가?
• 클러스터 아키텍처: 노드당 많은 파드가 포함된 소수의 대규모 노드를 보유할 계획인가 아니면 노드당 적은 수의 파드가 포함된 다수의 소규모 노드를 보유할 계획인가?
• 데이터 이그레스 및 관리: 보다 쉬운 데이터 관리를 위해 각 클러스터 내의 단일 게이트웨이 수집기를 통해 모든 텔레메트리를 라우팅하길 원하는가 아니면 외부 게이트웨이 수집기에서 데이터를 처리하길 원하는가?

수집기 아키텍처를 구축하고 테스트할 때, 수집기 구성에서 "self metrics"라고도 알려진 OpenTelemetry 수집기의 내부 텔레메트리를 활성화하는 것이 좋습니다. 이러한 메트릭은 수집기 병목 현상, 성능 문제 또는 파이프라인 내에서 의도치 않게 텔레메트리를 삭제할 수 있는 상황을 식별하는 데 매우 유용합니다.

다음 이미지는 다음과 같은 일부 핵심 메트릭에 초점을 맞춘 뉴렐릭 OpenTelemetry 수집기의 데이터 흐름 대시보드의 예를 보여줍니다.

• 허용 및 거부된 스팬, 메트릭 및 로그
• 스팬, 메트릭 및 로그에 대한 내보내기 실패
• 스팬, 메트릭 및 로그에 대한 내보내기 비율
• 내보내기 대기열 용량 및 크기

요약

OpenTelemetry 수집기는 애플리케이션과 쿠버네티스 환경에서 옵저버빌리티 텔레메트리를 수집하는 데 유용한 툴로 자리를 잡았습니다. 다양한 작업을 처리할 수 있는 다재다능한 솔루션이라는 점을 고려하면 그다지 놀라운 일이 아닙니다. 하지만 익숙해지는 데 시간이 좀 걸리는 게 사실입니다. 

대규모로 수집기를 설정하고 관리하려면 먼저 계획을 수립해야 합니다. 기본적인 설정을 잘 익히고, 다양한 배포 모드를 살펴보며, 필요할 때 체인 수집기를 함께 사용하는 방법을 이해하면 수집기를 사용해 쿠버네티스 옵저버빌리티를 다음 단계로 끌어올릴 준비가 된 것입니다. 

이외에  OpenTelemetry로 쿠버네티스를 모니터링하는 데 일반적으로 사용되는 구성 요소를 모아놓은 OpenTelemetry 수집기 쿠버네티스 분포도 확인해 보실 수 있습니다.