Sizing and Capacity Estimations

Sizing and Capacity Estimations

Sizing and Capacity Estimations

A pipeline is a set of agents with a single configuration. There are different types of pipelines that you can deploy depending on your architecture.

Except where called out, the following guidance applies to all pipelines.

Sizing

The resources your Edge Delta components need depend primarily on:

  1. Throughput: raw volume per hour.
  2. Pipeline Configuration features: parsing, alerting, transforms, buffering, etc.
  3. Replication factor: number of pods (node pipeline) or Deployments (gateway pipeline).

We strongly recommend:

  • Prototype first: test your configuration with a narrow slice of real traffic.
  • Measure: capture CPU and memory peaks with kubectl top pods or the Edge Delta app.
  • Extrapolate: scale the observed telemetry up to match production load.

Estimations

The following estimations can form a baseline for your prototype testing:

Pipeline Component(s) Reference Traffic Pattern Benchmark Throughput Benchmark Resources*
Node Agent (DaemonSet) + Rollup + Compactor 256-byte events via HTTP 35 MiB /min / vCPU 1 vCPU ≈ 35 MiB /min ingest
Gateway Processor (Deployment) 10 GB /h mixed logs + traces ≈ 1500 m CPU, ≈ 1500 Mi memory per replica
Rollup (Deployment) 90 GB /h raw metrics ≈ 9000 m CPU, ≈ 4.5 Gi memory per replica Reduces metric cardinality/frequency
Compactor (Deployment) 22 GB /h rolled-up metrics ≈ 6600 m CPU, ≈ 4.4 Gi memory per replica Compresses before egress

*Benchmarks include ~10 % safety head-room. Always validate with your own workload.

Recommendations

Instances with at least 8 vCPUs and 16 GiB RAM strike a good balance between vertical scalability and cost. For high availability, deploy at least one node per cloud Availability Zone.

Cloud Example Node Type
AWS c7g.2xlarge
Azure Standard_D8pls_v5
GCP t2a-standard-8

CPUs

Compute resources drive nearly every stage of the Edge Delta data path—from extraction and parsing through roll-up and final compaction. Allocate cores deliberately so that routine bursts don’t trigger scaling events the instant traffic ticks upward.

The following table lists safe minimum vCPU counts; start here and monitor real-world usage before tightening budgets.

Component Minimum vCPU Notes
Node Pipeline: Processor Agent 2 vCPU DaemonSet; one per node
Gateway Pipeline: Processor 2 – 4 vCPU HorizontalPodAutoscaler (HPA) enabled
Rollup (node or gateway) 0.5 vCPU Scale with metric volume
Compactor (node or gateway) 0.5 vCPU Scale with post-rollup volume

Edge Delta images are multi-architecture; ARM 64 (Graviton / Ampere) often delivers higher work-per-dollar than x86.

Memory

Start with ≈ 2 GiB per vCPU. Bump memory for configurations that:

  • Parse large JSON payloads
  • Buffer high-frequency metrics
  • Perform heavy transformations

Scaling

Vertical Scaling

Each Edge Delta binary is multithreaded and will happily consume all vCPUs you give it. Vertical scaling is simplest for Node Pipeline agents because the DaemonSet already spreads one pod per node.

Caution: Even with vertical scaling, keep at least two nodes (and therefore two agents) behind your ingest endpoint to avoid single-point failure.

Horizontal Scaling

Node Pipeline

Horizontal scaling is usually unnecessary. One DaemonSet pod per node is sufficient. Scale Rollup and Compactor Deployments independently via replicas or an HPA.

Gateway Pipeline

Gateway components are classic Deployments and must be scaled horizontally to meet burst demand.

  --set deployment.autoscaling.enabled=true \
  --set deployment.autoscaling.minReplicas=2 \
  --set deployment.autoscaling.maxReplicas=10 \
  --set deployment.autoscaling.targetForCPUUtilizationPercentage=80 \
  --set deployment.autoscaling.targetForMemoryUtilizationPercentage=80
  • Scale Rollup first when metric volume surges.
  • Scale Compactor to match the rolled-up output rate.

Autoscaling Settings

Below is a clear, step-by-step recipe for setting up an HPA on any Deployment (Gateway Processor, Rollup, or Compactor).

Setting Recommended Value Purpose
Primary metric CPU Most Edge Delta workloads are CPU-bound.
Secondary metric Memory (add only if you buffer large payloads) Catches rare memory spikes.
Target utilisation 90 % CPU averaged over 5 minutes Keeps pods busy but leaves headroom.
Scale-up delay 5 minutes Allows short traffic bursts to settle before adding replicas.
Scale-down delay ≥ 5 minutes Prevents rapid shrink-expand “thrash.”

Example HPA behavior block

behavior:
  scaleUp:
    stabilizationWindowSeconds: 300          # Wait 5 min before adding pods
    policies:
    - type: Percent
      value: 50                              # Grow by ≤ 50 % each step
      periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300          # Wait 5 min before removing pods

After deploying, watch the HPA for a full traffic cycle (peak and off-peak) and fine-tune targets or delays if you still see oscillations.

Quick Reference

Pipeline Component When to Vertical-scale When to Horizontal-scale
Node Agent (DS) Rare – node CPU starved N/A (one per node)
Rollup Occasional memory spikes Metric TPS ↑
Compactor Occasional memory spikes Post-rollup TPS ↑
Gateway Processor CPU consistently > 80 % Ingest TPS ↑ / bursty traffic
Rollup CPU consistently > 75 % Metric TPS ↑
Compactor CPU consistently > 75 % Post-rollup TPS ↑

Need deeper guidance? Check:

  • Scaling guide: See scale deployments for step-by-step HPA setup
  • Benchmark calculator: Contact Edge Delta support for a sizing worksheet tailored to your data profile