수집기

수집기는 여러 서비스가 내보내는 관측 데이터를 받아서 저장 서버까지 대신 날라 줍니다. 서비스는 저장 서버가 어디 있는지 몰라도 됩니다. 같은 이름으로 메모리를 치우는 가비지 컬렉터나 웹 페이지를 긁어 오는 크롤러를 부르기도 합니다. 이 항목은 관측 데이터를 모으는 수집기를 다룹니다.

쉽고 빠른 이해

수집기는 서비스들이 내보내는 기록을 받아 한곳에 모았다가 저장 서버로 넘겨 줍니다. 주문 서비스와 결제 서비스가 둘 다 기록을 수집기 한 대로 보내면, 수집기가 그것을 모아 저장 서버로 넘기는 식입니다.

이것이 없으면 서비스마다 저장 서버 주소와 다시 보내기를 따로 챙겨야 합니다. 저장 서버를 바꾸는 날에는 서비스를 전부 고쳐 다시 배포해야 합니다.

어떻게 도는가:

1. 서비스가 보내는 기록을 받습니다
2. 여러 건을 묶습니다. 필요 없는 것은 거릅니다. 어느 기계에서 왔는지 꼬리표도 붙입니다
3. 저장 서버가 받는 모양으로 바꿔 보냅니다

대가도 있습니다. 돌보아야 할 서버가 하나 늘어납니다. 수집기가 막히면 기록이 쌓이다가 버려집니다. 그래서 서비스가 한두 개이고 저장 서버가 하나뿐이면 수집기 없이 직접 보내는 편이 단순합니다.

상세

편지를 부치는 사람은 동네 우체통에 넣기만 합니다. 우체통의 편지는 집하장에 모였다가 가는 곳별로 나뉘어 큰 트럭에 실립니다. 편지를 쓴 사람은 집하장 너머의 길을 몰라도 됩니다.

이 집하장 노릇을 하는 프로그램이 수집기입니다. 여러 프로그램이 보내는 관측 데이터를 받아서 모으고 다듬은 뒤 저장 서버로 넘깁니다. 주문 서비스와 결제 서비스가 요청을 처리할 때마다 기록을 수집기 한 대로 보낸다고 해 봅시다. 수집기는 그 기록을 몇 초씩 모았다가 저장 서버로 한꺼번에 넘깁니다.

영어 이름은 collector 입니다. 실무에서는 소리 나는 대로 「컬렉터」라고도 합니다.

수집기가 나르는 데이터

관측 데이터는 프로그램이 돌면서 자기 상태를 적어 밖으로 내보내는 기록입니다. 이런 기록을 통틀어 텔레메트리라고 부릅니다. 가 보지 않고도 서버 안에서 무슨 일이 나는지 알려고 내보냅니다.

기록은 크게 세 갈래입니다. 수집기 하나가 세 갈래를 다 받기도 하고, 한 갈래만 맡기도 합니다.

트레이스는 서비스마다 하나씩 생기는 구간으로 이루어집니다. 서비스 하나가 요청을 받아 처리한 한 구간이 스팬입니다. 요청이 주문 서비스를 거쳐 결제 서비스로 넘어가면 스팬이 둘 생깁니다.

이렇게 요청 하나의 길을 따라가는 일을 분산 추적이라 합니다. 분산 추적에서 수집기는 여러 서비스가 보낸 스팬을 받아 저장 서버로 넘깁니다.

앞에서 저장 서버라 부른 곳은 기록을 받아 두기만 하지 않습니다. 화면과 알림으로 보여 주는 일까지 합니다. 이런 서버를 관측성 백엔드라 합니다. 아래부터는 줄여서 백엔드라고 씁니다.

수집기가 없을 때 생기는 일

서비스가 백엔드로 직접 보낸다고 해 봅시다. 서비스마다 백엔드 주소를 설정에 적어야 합니다. 백엔드가 잠깐 멈추면 다시 보내는 일도 서비스마다 따로 짜야 합니다.

백엔드를 다른 제품으로 바꾸는 날은 더 번거롭습니다. 제품마다 받는 데이터 모양이 다르기 때문입니다. 서비스의 보내는 코드와 설정을 전부 고쳐 다시 배포해야 합니다. 서비스가 서른 개면 서른 번 배포합니다.

수집기를 끼우면 서비스는 수집기 주소 하나만 압니다. 백엔드를 바꾸거나 하나 더 붙이는 일은 수집기 설정에서 끝납니다. 다시 보내기와 묶어 보내기도 수집기가 맡으므로 서비스 코드가 가벼워집니다.

받기와 다듬기와 내보내기

수집기 안은 세 단계로 나뉩니다. 데이터는 받는 단계로 들어와 다듬는 단계를 지나 내보내는 단계로 나갑니다. 이렇게 단계를 이어 붙인 줄기를 파이프라인이라고 부릅니다.

flowchart TD
    S["서비스들"] --> R["받기"]
    R --> P["다듬기"]
    P --> E["내보내기"]
    E --> B1["백엔드 하나"]
    E --> B2["백엔드 둘"]

그림 끝에서 갈래가 둘로 나뉜 것은 같은 데이터를 백엔드 두 곳에 함께 보낼 수 있다는 뜻입니다. 이 쓰임은 내보내는 단계에서 다시 봅니다.

받는 단계는 네트워크 포트를 열어 두고 서비스가 보내는 데이터를 받습니다. 받을 수 있는 데이터 모양을 여럿 갖춰 두면 형식이 서로 다른 서비스를 한 수집기가 다 받습니다.

다듬는 단계는 받은 데이터를 백엔드로 보내기 전에 손봅니다. 흔히 하는 일은 아래 다섯입니다.

다섯 가운데 묶기는 거의 언제나 켭니다. 기록이 날 때마다 한 건씩 보내면 네트워크 호출이 요청 수만큼 늘어나기 때문입니다. 나머지 넷은 필요한 것만 골라 켭니다.

내보내는 단계는 데이터를 백엔드가 받는 모양으로 바꿔 보냅니다. 그림의 두 갈래처럼 같은 데이터를 백엔드 둘로 동시에 보낼 수도 있습니다. 옛 백엔드에서 새 백엔드로 옮기는 동안 양쪽에 다 보내 두는 식입니다. 이 단계를 맡는 부품을 익스포터라고 부릅니다.

데이터가 들어오는 세 길

데이터가 수집기로 들어오는 길은 셋입니다. 앞의 둘은 서비스와 수집기 가운데 누가 먼저 움직이느냐로 갈립니다. 셋째는 로그를 모을 때 쓰는 길입니다.

푸시 방식에서는 서비스가 먼저 보냅니다. 수집기는 포트를 열고 기다리기만 합니다. 서비스는 수집기 주소를 알아야 합니다.

풀 모델에서는 수집기가 먼저 갑니다. 정해진 주기마다 서비스에 찾아가 지금 값을 읽어 옵니다. 메트릭을 모을 때 흔히 씁니다.

이렇게 주기마다 찾아가 긁어 오는 일을 스크레이핑이라 합니다. 긁어 오려면 수집기가 돌아야 할 서비스들의 목록을 알고 있어야 합니다.

셋째 길은 파일입니다. 서비스가 로그를 파일에 적으면 수집기가 그 파일을 끝에서부터 따라 읽습니다. 서비스 코드를 고치지 않고도 로그를 모을 수 있어서 오래된 프로그램에 자주 씁니다.

에이전트와 게이트웨이

수집기를 어디에 띄우느냐에 따라 부르는 이름이 갈립니다. 서비스 가까이 두는 쪽과 한가운데 모아 두는 쪽입니다.

에이전트는 서비스가 도는 기계마다 하나씩 띄우는 수집기입니다. 서비스와 같은 기계에 있으니 보내는 거리가 짧습니다. 그 기계의 이름 같은 꼬리표도 붙이기 쉽습니다.

쿠버네티스는 서비스가 도는 기계 한 대를 노드라고 부릅니다. 쿠버네티스에서는 에이전트를 노드마다 하나씩 띄웁니다.

에이전트를 서비스마다 하나씩 붙여 띄우기도 합니다. 서비스 바로 옆에 함께 뜨는 이런 보조 프로그램을 사이드카라 합니다.

게이트웨이는 여러 에이전트가 보낸 것을 한 번 더 모으는 중앙 수집기입니다. 백엔드 주소와 접속 키를 이곳에만 두면 됩니다. 요청 하나의 기록이 다 모일 때까지 들고 있다가 남길지 정하는 일도 게이트웨이가 맡습니다. 이 일은 아래 「테일 샘플링과 수집기」에서 봅니다.

flowchart TD
    subgraph M1["기계 1"]
        A1["서비스"] --> G1["에이전트"]
    end
    subgraph M2["기계 2"]
        A2["서비스"] --> G2["에이전트"]
    end
    G1 --> GW["게이트웨이"]
    G2 --> GW
    GW --> BE["관측성 백엔드"]

둘을 겹쳐 쓰는 구성이 흔합니다. 에이전트가 가까이서 받아 꼬리표를 붙입니다. 게이트웨이는 그것을 모아 골라 남긴 뒤 백엔드로 보냅니다.

테일 샘플링과 수집기

기록을 일부만 고르는 방식 가운데 하나는 서비스가 아니라 수집기가 맡아야 합니다. 한 요청의 기록을 끝까지 모아 봐야 고를 수 있어서입니다. 이 소절은 그 방식과 게이트웨이가 그것을 맡는 까닭을 봅니다.

기록을 전부 남기면 저장할 양이 요청 수에 비례해 불어납니다. 그래서 일부만 골라 남깁니다. 이 고르기를 샘플링이라고 부릅니다.

요청이 처음 들어올 때 남길지 정하는 방식을 헤드 샘플링이라 합니다. 가볍습니다. 대신 나중에 실패한 요청이 하필 안 뽑혔으면 그 기록이 없습니다.

요청이 다 끝난 뒤 스팬을 모아 보고 정하는 방식은 테일 샘플링입니다. 실패한 요청과 오래 걸린 요청을 골라 남길 수 있습니다. 대신 판단할 때까지 수집기가 그 요청의 스팬을 전부 들고 있어야 합니다.

게이트웨이가 여러 대면 한 가지가 더 필요합니다. 한 요청의 스팬이 여러 게이트웨이로 흩어지면 어느 한 대도 전체를 못 봅니다.

그래서 요청마다 붙는 번호를 씁니다. 요청 하나에는 처음부터 끝까지 따라다니는 고유 번호가 붙습니다. 이 번호가 트레이스 번호입니다. 게이트웨이 앞의 에이전트나 로드 밸런서가 이 번호를 보고 같은 번호는 늘 같은 게이트웨이로 보냅니다.

수집기를 두면 치르는 것

돌보아야 할 서버가 하나 늘어납니다. 수집기도 멈추고 느려질 수 있으므로 수집기 자신을 지켜보는 일이 따로 생깁니다.

데이터가 백엔드에 닿기까지 조금 늦어집니다. 한 번 더 거치고, 묶어 보내려고 잠시 기다리기 때문입니다. 장애가 난 직후 화면에 그 순간이 몇 초 늦게 뜨는 것이 이 탓입니다.

수집기는 받은 것을 보내기 전까지 버퍼에 쌓아 둡니다. 버퍼는 잠시 담아 두는 메모리 공간입니다. 백엔드가 느려지면 이 버퍼가 가득 찹니다.

버퍼가 가득 차면 수집기는 둘 가운데 하나를 합니다. 새로 들어오는 기록을 버립니다. 아니면 보내는 쪽에 천천히 보내라고 알립니다.

천천히 보내라고 알리는 쪽을 백프레셔라 합니다. 뒤가 막힌 것을 앞에 알려 들어오는 양을 줄이는 방식입니다.

버퍼가 메모리에만 있으면 수집기가 죽는 순간 쌓여 있던 기록도 사라집니다. 이것이 걱정되면 버퍼를 디스크에 적어 두는 방식을 고릅니다. 디스크에 적는 만큼 느려집니다. 디스크 공간도 차지합니다.

수집기가 한 대뿐이면 그 한 대가 멈출 때 모든 기록이 끊깁니다. 이렇게 하나가 멈추면 전체가 서는 곳을 단일 장애점이라고 부릅니다. 그래서 게이트웨이는 여러 대를 띄우고 로드 밸런서로 나눠 받게 합니다.

서비스가 한두 개이고 백엔드가 하나뿐이면 수집기 없이 직접 보내는 편이 단순합니다. 수집기는 서비스가 많을수록, 백엔드를 바꿀 일이 있을수록, 보내기 전에 거를 것이 많을수록 값이 커집니다.

이 역할을 하는 제품

같은 역할을 하는 제품이 여럿 있습니다. 주로 어느 갈래의 데이터를 모으느냐로 나뉩니다.

첫 줄의 수집기는 OpenTelemetry 프로젝트가 만듭니다. 이 수집기는 앞에서 본 세 단계의 부품을 영어 이름으로 리시버, 프로세서, 익스포터라고 부릅니다. 다른 제품의 설명서에서도 이 세 낱말을 자주 만납니다.

같은 이름을 쓰는 다른 수집기

「수집기」는 관측 데이터 말고도 두 곳에서 흔히 쓰입니다. 둘 다 이 항목과는 하는 일이 다릅니다.

프로그래밍 언어의 런타임에서 수집기는 가비지 컬렉터를 우리말로 옮긴 이름입니다. 프로그램이 더 이상 쓰지 않는 메모리를 찾아서 되돌려 받습니다. 이 일은 가비지 컬렉션 항목이 다룹니다.

웹에서 수집기는 웹 크롤러를 가리키기도 합니다. 링크를 따라 웹 페이지를 돌아다니며 내용을 긁어 모으는 프로그램입니다. 검색 엔진이 색인을 만들려고 띄우는 것이 대표적입니다.

관련 항목

수집기가 모아 나르는 신호

텔레메트리 · 로그 · 메트릭 · 트레이스 · 스팬 · 프로파일

수집기로 보낼 데이터를 만드는 앞 단계

계측 · 자동 계측 · 컨텍스트 전파 · 배기지

수집기 안에서 데이터가 거치는 처리 단계

파이프라인 · 리시버 · 익스포터 · 배치 전송 · 샘플링 · 헤드 샘플링 · 테일 샘플링 · 집계

수집기가 데이터를 받아 오는 방식

푸시 · 풀 모델 · 스크레이핑 · 서비스 디스커버리

수집기를 띄우는 배치 방식

에이전트 · 게이트웨이 · 사이드카 · 데몬셋 · Kubernetes

수집기가 데이터를 넘기는 저장소와 화면

관측성 백엔드 · 시계열 데이터베이스 · 대시보드 · 알림

수집기가 쓰이는 상위 실천

관측성 · 모니터링 · 분산 추적 · APM

수집기 데이터의 모양을 정하는 표준

OpenTelemetry · OTLP · 시맨틱 컨벤션 · Trace Context

수집기의 하위 종류와 그 제품

로그 수집기 · OpenTelemetry Collector · Fluent Bit · Fluentd · Logstash · Vector · Prometheus

수집기를 굴릴 때 부딪히는 문제

백프레셔 · 버퍼 · 단일 장애점 · 로드 밸런서 · 카디널리티 · 데이터 유실

이름이 겹치는 다른 수집기

가비지 컬렉션 · 가비지 컬렉터 · 웹 크롤러 · 자동 수집기