배포 설계 및 원칙

옵저버빌리티 파이프라인은 US1-FED Datadog 사이트에서 사용할 수 없습니다.

개요

인프라스트럭처에 옵저버빌리티 파이프라인 작업자를 배포하기 시작하면 다음과 같은 질문에 직면할 수 있습니다.

  • 네트워크 내부 어디에 옵저버빌리티 파이프라인 작업자를 배포해야 하나요?
  • 데이터를 어떻게 수집해야 하나요?
  • 데이터를 어디에서 처리해야 하나요?

이 가이드에서는 옵저버빌리티 파이프라인 작업자 아키텍처를 설계할 때 고려해야 할 사항, 구체적으로 다음 항목에 대해 설명합니다:

네트워킹

옵저버빌리티 파이프라인 작업자 배포 구축을 위한 첫 번째 단계는 옵저버빌리티 파이프라인 작업자가 네트워크 내부 어디에 적합할지, 그리고 어디에 배포할지를 파악하는 것입니다.

네트워크 경계 작업

옵저버빌리티 파이프라인 작업자는 애그리게이터(aggregator)로 배포되기 때문에 송신 비용을 최소화하려면 네트워크 경계 내에 배포해야 합니다. 옵저버빌리티 파이프라인 작업자의 인그레스는 공용 인터넷을 통해 이동해서는 안 됩니다. 따라서 Datadog은 이 작업을 간소화하기 위해 리전당 하나의 애그리게이터(aggregator)로 시작할 것을 권장합니다.

방화벽 및 프록시 사용

방화벽을 사용하는 경우 에이전트 통신을 애그리게이터(aggregator)로 제한하고 애그리게이터(aggregator) 통신을 설정된 소스 및 싱크로 제한하세요.

HTTP 프록시 사용을 선호하는 경우 옵저버빌리티 파이프라인 작업자는 모든 옵저버빌리티 파이프라인 작업자 HTTP 트래픽을 프록시를 통해 라우팅하는 전역 프록시 옵션을 제공합니다.

DNS 및 서비스 검색 사용

옵저버빌리티 파이프라인 작업자 애그리게이터 및 서비스를 찾으려면 DNS 또는 서비스 검색을 통해 이루어져야 합니다. 이 전략은 트래픽의 라우팅과 로드밸런싱을 용이하게 하며, 에이전트와 로드 밸런서가 애그리게이터를 발견하는 방법입니다. 적절한 문제 분리를 위해 옵저버빌리티 파이프라인 작업자는 DNS 쿼리를 확인하지 않고 대신 시스템 수준 리졸버(예: Linux resolving)에 위임합니다.

에이전트 클러스터, 로드 밸런서 클러스터, 옵저버빌리티 파이프라인 작업자 집합이 있는 클라우드 리전을 보여주는 다이어그램으로, 각 그룹이 DNS 또는 서비스 레지스트리에 별도의 쿼리를 전송하고 있습니다.

프로토콜 선택

옵저버빌리티 파이프라인 작업자로 데이터를 전송할 때는 로드밸런싱과 애플리케이션 수준의 전송 승인을 쉽게 할 수 있는 프로토콜을 선택할 것을 권장합니다. HTTP와 gRPC는 유비쿼터스 특성을 가지고 있고 HTTP/gRPC 기반 서비스를 효과적이고 효율적으로 운영하는 데 도움이 되는 도구와 문서가 많아 선호됩니다.

프로토콜에 맞는 소스를 선택하세요. 각 옵저버빌리티 파이프라인 작업자 소스는 서로 다른 프로토콜을 구현합니다. 예를 들어 옵저버빌리티 파이프라인 작업자 소스 및 싱크는 옵저버빌리티 파이프라인 작업자 간 통신을 위해 gRPC를 사용하며, HTTP 소스를 사용하면 HTTP를 통해 데이터를 수신할 수 있습니다. 해당 프로토콜은 소스를 참조하세요.

데이터 수집하기

파이프라인은 데이터 수집에서 시작됩니다. 귀사의 서비스와 시스템은 수집하여 대상까지 다운스트림으로 전송할 수 있는 데이터*를 생성합니다. 데이터 수집은 에이전트를 통해 이루어지며, 어떤 에이전트를 사용할지 이해하면 원하는 데이터를 수집할 수 있습니다.

에이전트 선택

엔지니어링 팀의 시스템 모니터링 능력을 최적화하는 에이전트를 선택해야 합니다. 따라서 옵저버빌리티 파이프라인 작업자를 작업에 가장 적합한 에이전트와 통합하고 옵저버빌리티 파이프라인 작업자를 별도의 노드에 애그리게이터(aggregator)로 배포하세요.

예를 들어 Datadog 네트워크 성능 모니터링은 Datadog Agent를 공급업체별 시스템과 통합하고 공급업체별 데이터를 생성합니다. 따라서 옵저버빌리티 파이프라인 작업자에서 지원되는 데이터 유형이 아니기 때문에 Datadog Agent는 데이터를 수집하여 Datadog에 직접 보내야 합니다.

또 다른 예로, Datadog Agent는 서비스 메트릭을 수집하고 이를 공급업체별 Datadog 태그로 강화합니다. 이 경우 Datadog Agent는 메트릭을 Datadog에 직접 보내거나 옵저버빌리티 파이프라인 작업자를 통해 라우팅해야 합니다. 생성되는 데이터가 공급업체별 방식으로 강화되므로 옵저버빌리티 파이프라인 작업자는 Datadog Agent를 대체해서는 안 됩니다.

에이전트와 통합할 때 옵저버빌리티 파이프라인 작업자를 설정하여 로컬 네트워크를 통해 에이전트로부터 직접 데이터를 수신하고 옵저버빌리티 파이프라인 작업자를 통해 데이터를 라우팅합니다. datadog_agent 또는 open_telemetry와 같은 소스 컴포넌트를 사용하여 에이전트로부터 데이터를 받습니다.

에이전트 리스크 감소

에이전트와 통합할 때는 에이전트를 단순 데이터 포워더로 설정하고 지원되는 데이터 유형을 옵저버빌리티 파이프라인 작업자를 통해 라우팅하세요. 이렇게 하면 에이전트의 책임을 최소화하여 데이터 손실 및 서비스 중단의 위험을 줄일 수 있습니다.

데이터 처리

옵저버빌리티 파이프라인 작업자의 소스와 싱크 간에 효율적인 파이프라인을 설계하려는 경우, 처리할 데이터 유형과 처리 위치를 이해하는 데 도움이 됩니다.

처리할 데이터 선택

옵저버빌리티 파이프라인 작업자를 사용하여 데이터를 처리할 수 있습니다*. 그러나 지속적인 프로파일링 데이터와 같은 실시간 공급업체별 데이터는 상호 운용되지 않으며 처리 시에 일반적으로 얻는 이점이 없습니다.

원격 처리

원격 처리의 경우 옵저버빌리티 파이프라인 작업자를 애그리게이터(aggregator)로 별도의 노드에 배포할 수 있습니다.

이 다이어그램은 여러 작업자를 포함하는 옵저버빌리티 파이프라인 작업자 애그리게이터를 보여줍니다. 이 작업자들은 네트워크 로드 밸런서에서 데이터를 수신하고 여러 다른 싱크로 데이터를 전송합니다.

데이터 처리가 노드에서 원격 애그리게이터(aggregator) 노드로 이동합니다. 원격 처리는 높은 내구성과 고가용성이 필요한 환경(대부분의 환경)에 권장됩니다. 또한 에이전트를 추가할 때 인프라스트럭처 재구성이 반드시 필요하지 않으므로 설정하기가 더 쉽습니다.

자세한 내용은 애그리게이터(aggregator) 아키텍처를 참조하세요.

데이터 버퍼링

데이터를 버퍼링하는 위치와 방법도 파이프라인의 효율성에 영향을 미칠 수 있습니다.

데이터를 버퍼링할 위치 선택

버퍼링은 대상과 가까운 곳에서 이루어져야 하며, 각 대상에는 다음과 같은 이점을 제공하는 자체 격리 버퍼가 있어야 합니다:

  1. 각 대상은 싱크의 요구 사항에 맞게 버퍼를 설정할 수 있습니다. 자세한 내용은 데이터 버퍼링 방법 선택을 참조하세요.
  2. 각 대상에 대한 버퍼를 격리하면 버퍼가 설정된 용량에 도달할 때까지 하나의 오작동 대상 때문에 전체 파이프라인이 중단되는 것을 방지할 수 있습니다.

이러한 이유로 옵저버빌리티 파이프라인 작업자는 버퍼를 싱크와 연결합니다.

노드의 에이전트가 다른 노드의 버퍼를 사용하여 옵저버빌리티 파이프라인 작업자로 데이터를 전송하는 다이어그램입니다.

데이터를 버퍼링할 방법 선택

옵저버빌리티 파이프라인 작업자의 내장 버퍼는 작업을 간소화하여 복잡한 외부 버퍼가 필요하지 않습니다.

옵저버빌리티 파이프라인 작업자 버퍼 유형을 선택할 때는 대상의 목적에 가장 적합한 유형을 선택하세요. 예를 들어, 기록 시스템에서는 높은 내구성을 위해 디스크 버퍼를 사용해야 하고, 분석 시스템에서는 짧은 지연 시간을 위해 메모리 버퍼를 사용해야 합니다. 또한 두 버퍼 모두 다른 버퍼로 오버플로우되어 클라이언트에 역압이 전파되는 것을 방지할 수 있습니다.

싱크에 가까운 디스크 버퍼와 메모리 버퍼로 데이터를 전송하는 옵저버빌리티 파이프라인 작업자의 소스를 보여주는 다이어그램입니다.

데이터 라우팅

애그리게이터(aggregator)가 데이터를 적절한 대상으로 보낼 수 있도록 데이터를 라우팅하는 것은 파이프라인 설계의 마지막 요소입니다. 애그리게이터(aggregator)를 사용하여 팀에 가장 적합한 시스템으로 데이터를 유연하게 라우팅하세요.

기록 시스템과 분석 시스템의 분리

기록 시스템과 분석 시스템을 분리하여 목적에 영향을 미치는 절충안을 만들지 않고 비용을 최적화하세요. 예를 들어, 기록 시스템은 시간이 지남에 따라 대량의 데이터를 일괄 처리하고 압축하여 비용을 최소화하는 동시에 모든 데이터의 높은 내구성을 보장할 수 있습니다. 또한 분석 시스템은 데이터를 샘플링하고 정리하여 비용을 절감하는 동시에 실시간 분석을 위해 지연 시간을 낮출 수 있습니다.

데이터를 디스크 버퍼로 전송한 다음 아카이빙을 위해 데이터를 전송하거나 샘플링을 위해 블록 스토리지 디스크로 전송하는 옵저버빌리티 파이프라인 작업자의 소스를 보여주는 다이어그램입니다.

기록 시스템으로 라우팅(아카이빙)

다음을 수행하여 비용을 최소화하면서 기록 시스템을 최적화하여 내구성을 높이세요:

  • 노드 재시작 및 소프트웨어 오류로 인한 데이터 손실을 줄이려면 애그리게이터 역할에서만 아카이브에 작성하세요.
  • 디스크 버퍼와 함께 싱크를 앞에 위치합니다.
  • 모든 소스에 대해 엔드 투 엔드 승인을 활성화합니다.
  • batch.max_bytes는 ≥ 5MiB로, batch.timeout_secs는 ≥ 5분으로 설정하고, 압축(aws_s3 싱크와 같은 아카이빙 싱크를 위한 기본값)을 활성화합니다.
  • 처리되지 않은 원시 데이터를 보관하여 데이터 재생을 허용하고 처리 중 우발적인 데이터 손상 위험을 줄이세요.

분석 시스템으로 라우팅

분석 시스템을 최적화하고 비용을 절감하려면 다음을 수행하세요:

  • 메모리 버퍼와 함께 싱크를 앞에 위치합니다.
  • batch.timeout_sec를 ≤ 5초로 설정합니다 (datadog_logs와 같은 분석 싱크의 기본값).
  • remap 변환을 사용하여 분석에 사용되지 않는 속성을 제거합니다.
  • 분석에 사용되지 않는 이벤트 필터링
  • 볼륨을 줄이기 위해 로그를 level info 또는 그 이하로 샘플링하는 것을 고려하세요.

* 옵저버빌리티 파이프라인은 로그를 지원합니다. 메트릭에 대한 지원은 베타 버전입니다.