원격 쓰기 튜닝

원격 쓰기 튜닝 (Remote write tuning)

프로메테우스는 원격 쓰기(remote write)에 합리적인 기본값을 구현하지만, 사용자는 제각각 다른 요구 사항을 가지고 자기 환경에 맞게 원격 설정을 최적화하고 싶어해요. 이 문서는 원격 쓰기 구성을 통해 조정 가능한 튜닝 파라미터를 설명해 드려요.

원격 쓰기는 장기 저장소 등으로 샘플을 보내는 기능이에요. 이 문서를 읽고 나면 데이터 흐름이 어떻게 되는지, 메모리 사용은 왜 늘어나는지, 그리고 queue_config 아래의 각 파라미터를 언제 어떻게 조절해야 하는지 이해할 수 있을 거예요.

출처: 문서

본문

프로메테우스는 원격 쓰기에 합리적인 기본값을 구현하지만, 많은 사용자가 서로 다른 요구 사항을 가지고 있고 자기 원격 설정을 최적화하고 싶어 해요.

이 페이지는 원격 쓰기 구성을 통해 사용 가능한 튜닝 파라미터를 설명해요.

원격 쓰기 특성 (Remote write characteristics)

각 원격 쓰기 목적지는 write-ahead log(WAL)에서 읽는 큐를 시작하고, 샘플을 샤드(shard)가 소유한 인메모리 큐에 쓴 다음, 구성된 엔드포인트에 요청을 보내요. 데이터의 흐름은 이렇게 생겼어요.

      |-->  queue (shard_1)   --> remote endpoint
WAL --|-->  queue (shard_...) --> remote endpoint
      |-->  queue (shard_n)   --> remote endpoint

한 샤드가 백업되어 큐를 채우면, 프로메테우스는 WAL에서 어떤 샤드로든 읽는 것을 차단해요. 실패는 원격 엔드포인트가 2시간 이상 다운되어 있지 않는 한 데이터 손실 없이 재시도돼요. 2시간 후에는 WAL이 컴팩트되고 전송되지 않은 데이터는 손실돼요.

운영 중에 프로메테우스는 들어오는 샘플 속도, 전송되지 않은 미전송 샘플 수, 각 샘플 전송에 걸린 시간을 기반으로 사용할 샤드의 최적 수를 지속적으로 계산해요.

리소스 사용 (Resource usage)

원격 쓰기를 사용하면 Prometheus의 메모리 풋프린트가 늘어나요. 대부분의 사용자가 대략 25% 증가한 메모리 사용을 보고하지만, 그 숫자는 데이터의 형태에 의존해요. WAL의 각 시리즈에 대해 원격 쓰기 코드는 시리즈 ID에서 라벨 값으로의 매핑을 캐시하므로, 많은 양의 시리즈 변동(churn)은 메모리 사용을 유의미하게 증가시켜요.

시리즈 캐시에 더해 각 샤드와 그 큐도 메모리 사용을 늘려요. 샤드 메모리는 number of shards * (capacity + max_samples_per_send)에 비례해요. 튜닝할 때는 실수로 메모리가 부족해지는 것을 피하기 위해 capacity와 max_samples_per_send를 늘리면서 max_shards를 줄이는 것을 고려하세요. capacity: 10000과 max_samples_per_send: 2000의 기본값은 샤드 메모리 사용을 샤드당 2 MB 미만으로 제한해요.

원격 쓰기는 또한 CPU와 네트워크 사용을 늘려요. 하지만 위와 같은 이유로 그 증가량을 예측하는 것은 어려워요. 일반적으로 Prometheus 서버가 원격 쓰기로 샘플을 보내는 데 뒤처지면(prometheus_remote_storage_samples_pending) CPU와 네트워크 포화를 확인하는 것이 좋은 관행이에요.

파라미터 (Parameters)

관련된 모든 파라미터는 원격 쓰기 구성의 queue_config 섹션 아래에 있어요.

capacity

Capacity는 WAL에서 읽기를 차단하기 전에 샤드당 메모리에 큐잉되는 샘플 수를 제어해요. WAL이 차단되면 어떤 샤드에도 샘플이 추가될 수 없고 모든 처리량이 중단돼요.

Capacity는 대부분의 경우 다른 샤드를 차단하지 않을 만큼 충분히 높아야 하지만, 너무 높으면 과도한 메모리 소비와 리샤딩(resharding) 중 큐를 비우는 데 더 오랜 시간이 걸릴 수 있어요. capacity를 max_samples_per_send의 3~10배로 설정하는 것을 권장해요.

max_shards

Max shards는 각 원격 쓰기 큐에 Prometheus가 사용할 샤드(병렬성)의 최대 수를 구성해요. Prometheus는 너무 많은 샤드를 사용하지 않으려 하지만, 큐가 뒤처지면 원격 쓰기 컴포넌트가 max shards까지 샤드 수를 늘려 처리량을 높여요. 매우 느린 엔드포인트에 원격 쓰기하지 않는 한 max_shards를 기본값보다 늘릴 가능성은 낮아요. 하지만 원격 엔드포인트를 압도할 가능성이 있거나, 데이터가 백업됐을 때 메모리 사용을 줄이려면 max shards를 줄여야 할 수도 있어요.

min_shards

Min shards는 Prometheus가 사용하는 최소 샤드 수를 구성하며, 원격 쓰기가 시작될 때 사용되는 샤드 수예요. 원격 쓰기가 뒤처지면 Prometheus가 자동으로 샤드 수를 확장하므로 대부분의 사용자는 이 파라미터를 조정할 필요가 없어요. 하지만 min shards를 늘리면 Prometheus가 필요한 샤드 수를 계산하는 동안 처음에 뒤처지는 것을 피할 수 있어요.

max_samples_per_send

Max samples per send는 사용 중인 백엔드에 따라 조정할 수 있어요. 많은 시스템이 지연시간을 크게 늘리지 않고 배치당 더 많은 샘플을 보내도 아주 잘 작동해요. 다른 백엔드는 각 요청에 많은 수의 샘플을 보내려 하면 문제가 생길 거예요. 기본값은 대부분의 시스템에서 작동할 만큼 작아요.

batch_send_deadline

Batch send deadline은 단일 샤드의 전송 사이 최대 시간을 설정해요. 큐잉된 샤드가 max_samples_per_send에 도달하지 않았더라도 요청이 보내져요. Batch send deadline은 지연시간에 민감하지 않은 저용량 시스템에서 요청 효율을 높이기 위해 늘릴 수 있어요.

min_backoff

Min backoff는 실패한 요청을 재시도하기 전에 기다리는 최소 시간을 제어해요. 백오프를 늘리면 원격 엔드포인트가 다시 온라인에 돌아왔을 때 요청을 분산시켜요. 백오프 간격은 실패한 각 요청에 대해 max_backoff까지 두 배로 늘어나요.

max_backoff

Max backoff는 실패한 요청을 재시도하기 전에 기다리는 최대 시간을 제어해요.

더 알아보기 (Learn more)