LogoLogo
WarpStream.comSlackDiscordContact UsCreate Account
  • Overview
    • Introduction
    • Architecture
      • Service Discovery
      • Write Path
      • Read Path
      • Life of a Request (Simplified)
    • Change Log
  • Getting Started
    • Install the WarpStream Agent / CLI
    • Run the Demo
    • "Hello World" for Apache Kafka
  • BYOC
    • Run the Agents Locally
    • Deploy the Agents
      • Object Storage Configuration
      • Kubernetes Known Issues
      • Rolling Restarts and Upgrades
    • Infrastructure as Code
      • Terraform Provider
      • Helm charts
      • Terraform Modules
    • Monitoring
      • Pre-made Datadog Dashboard
      • Pre-made Grafana Dashboard
      • Important Metrics and Logs
      • Recommended List of Alerts
      • Monitoring Consumer Groups
      • Hosted Prometheus Endpoint
    • Client Configuration
      • Tuning for Performance
      • Configure Clients to Eliminate AZ Networking Costs
        • Force Interzone Load Balancing
      • Configuring Kafka Client ID Features
      • Known Issues
    • Authentication
      • SASL Authentication
      • Mutual TLS (mTLS)
      • Basic Authentication
    • Advanced Agent Deployment Options
      • Agent Roles
      • Agent Groups
      • Protect Data in Motion with TLS Encryption
      • Low Latency Clusters
      • Network Architecture Considerations
      • Agent Configuration Reference
      • Reducing Infrastructure Costs
      • Client Configuration Auto-tuning
    • Hosted Metadata Endpoint
    • Managed Data Pipelines
      • Cookbooks
    • Schema Registry
      • WarpStream BYOC Schema Registry
      • Schema Validation
      • WarpStream Schema Linking
    • Port Forwarding (K8s)
    • Orbit
    • Enable SAML Single Sign-on (SSO)
    • Trusted Domains
    • Diagnostics
      • GoMaxProcs
      • Small Files
  • Reference
    • ACLs
    • Billing
      • Direct billing
      • AWS Marketplace
    • Benchmarking
    • Compression
    • Protocol and Feature Support
      • Kafka vs WarpStream Configuration Reference
      • Compacted topics
    • Secrets Overview
    • Security and Privacy Considerations
    • API Reference
      • API Keys
        • Create
        • Delete
        • List
      • Virtual Clusters
        • Create
        • Delete
        • Describe
        • List
        • DescribeConfiguration
        • UpdateConfiguration
      • Virtual Clusters Credentials
        • Create
        • Delete
        • List
      • Monitoring
        • Describe All Consumer Groups
      • Pipelines
        • List Pipelines
        • Create Pipeline
        • Delete Pipeline
        • Describe Pipeline
        • Create Pipeline Configuration
        • Change Pipeline State
      • Invoices
        • Get Pending Invoice
        • Get Past Invoice
    • CLI Reference
      • warpstream agent
      • warpstream demo
      • warpstream cli
      • warpstream cli-beta
        • benchmark-consumer
        • benchmark-producer
        • console-consumer
        • console-producer
        • consumer-group-lag
        • diagnose-record
        • file-reader
        • file-scrubber
      • warpstream playground
    • Integrations
      • Arroyo
      • AWS Lambda Triggers
      • ClickHouse
      • Debezium
      • Decodable
      • DeltaStream
      • docker-compose
      • DuckDB
      • ElastiFlow
      • Estuary
      • Fly.io
      • Imply
      • InfluxDB
      • Kestra
      • Materialize
      • MinIO
      • MirrorMaker
      • MotherDuck
      • Ockam
      • OpenTelemetry Collector
      • ParadeDB
      • Parquet
      • Quix Streams
      • Railway
      • Redpanda Console
      • RisingWave
      • Rockset
      • ShadowTraffic
      • SQLite
      • Streambased
      • Streamlit
      • Timeplus
      • Tinybird
      • Upsolver
    • Partitions Auto-Scaler (beta)
    • Serverless Clusters
Powered by GitBook
On this page
  • Required Arguments
  • Object Storage
  • Region
  • Permissions and Ports
  • Service discovery
  • GOMAXPROCS
  • Instance Selection
  • Network Optimized Instances
  • Auto-Scaling
  • Automatic Availability Zone Detection

Was this helpful?

  1. BYOC

Deploy the Agents

How to deploy the Agents.

PreviousRun the Agents LocallyNextObject Storage Configuration

Last updated 2 months ago

Was this helpful?

Remember to review our documentation on , as well as our instructions on once you're done. A few small changes in client configuration can result in 10-20x higher throughput when using WarpStream, and proper client configuration is required to leverage WarpStream's zone-aware discovery system.

Required Arguments

The WarpStream Agent is completely stateless and thus can be deployed however you prefer to deploy stateless containers. For example, you could use or a .

The WarpStream Docker containers can be found in the . However, if you're deploying WarpStream into a Kubernetes cluster, we highly recommend using our .

The Agent has four required arguments that must be passed as command line flags:

  1. bucketURL

  2. agentKey

  3. defaultVirtualClusterID

  4. region

For example:

docker run public.ecr.aws/warpstream-labs/warpstream_agent:latest \
    agent \
    -bucketURL "s3://$S3_BUCKET?region=$S3_BUCKET_REGION" \
    -agentKey $AGENT_KEY \
    -defaultVirtualClusterID $YOUR_VIRTUAL_CLUSTER_ID
    -region $CLUSTER_REGION

The values of agentKey , defaultVirtualClusterID , and region can be obtained from the .

Note that the entrypoint for the WarpStream docker image is a multi-command binary. For production usage, the subcommand that you want to run is just called agent as shown above.

Depending on the tool you're using to deploy/run containers, it can sometimes be cumbersome to provide additional arguments beyond the agent subcommand.

In that case, all of the required arguments can be passed as environment variables instead:

  1. WARPSTREAM_BUCKET_URL

  2. WARPSTREAM_AGENT_KEY

  3. WARPSTREAM_DEFAULT_VIRTUAL_CLUSTER_ID

  4. WARPSTREAM_REGION

Object Storage

Region

The region flag corresponds to the region that the WarpStream control plane is running in. This corresponds to the value that was selected when the BYOC cluster was created and can be obtained from the WarpStream UI. This value does not need to correspond to the cloud region that the Agents are deployed in, but you should pick the region that is closest to where your Agents are deployed to minimize latency.

Currently supported regions for BYOC are:

Cloud provider
Region
URL

AWS

us-east-1

AWS

ap-southeast-1

AWS

us-west-2

AWS

eu-central-1

GCP

asia-south1

GCP

us-central1

GCP

europe-west1

AWS

ap-northeast-1

Azure

eastus

Permissions and Ports

Finally, the WarpStream Agent requires 2 ports to be exposed. For simplicity, we recommend just ensuring that the WarpStream Agent can listen on ports 9092 (or 9094 in the case of schema registry) and 8080 by default; however, the section below contains more details about how each port is used and how to override them if necessary.

Default: 9092

Override: -kafkaPort $PORT

Disable: -enableKafka false

This is the port that exposes the Kafka TCP protocol to Kafka clients. Only disable it if you don't intend to use the Kafka protocol at all.

Default: 8080

Override: -httpPort $PORT

Default: 9094

Override: -schemaRegistryPort $PORT

You can also use the env variable WARPSTREAM_SCHEMA_REGISTRY_PORT to override the port.

This is the port that exposes the Schema Registry HTTP server.

Service discovery

GOMAXPROCS

The WarpStream Agent uses heuristics to automatically configure itself based on the available resources. The most important way this happens is by adjusting concurrency and cache sizes based on the number of available cores.

The Agent uses standard operating system APIs to determine how many cores are available, and it prints this value when starting:

2023/08/31 09:21:22 maxprocs: Leaving GOMAXPROCS=12: CPU quota undefined

In general, we recommend that you manually set the GOMAXPROCS environment variable to the number of cores that you've made available to the Agent in your environment. For example, if you've allocated 3 cores to the Agent's container, then we recommend adding GOMAXPROCS=3 as an environment variable.

The value of GOMAXPROCS must be a whole number and not a fraction. We also recommend that you always assign Agent whole numbers for CPU quotas so that the Agent doesn't have fractional CPU quotas. Fractional CPU quotas can result in throttling and increased latency since the value of GOMAXPROCS and the number of whole cores available to the Agent won't match.

Instance Selection

While the WarpStream Agents don't store data on local disks, they do use the network heavily. Therefore we recommend using network-optimized cloud instances that provide at least 4GiB of RAM per vCPU. We also recommend using dedicated instances and not bin-packing the Agent containers to avoid noisy neighbor issues where another container running on the same VM as the Agents causes network saturation.

In AWS, we think the m5n and m6in series are a great choice for running the Agents.

In GCP, the n4 series is a great choice with the c4 series as a close second.

We recommend running the Agents with at least 2 vCPUs available and providing at least 4 GiB of RAM per vCPU, therefore the m5n.large and m6in.large are the minimum recommended instance sizes in AWS.

Network Optimized Instances

The Agent does a lot of networking to service Apache Kafka Produce and Fetch requests, as well as perform background compaction. The Agent uses compression and intelligent caching to minimize this, but fundamentally, WarpStream is a data-intensive system that is even more networking-heavy than Apache Kafka due to reliance on remote storage.

Debugging latency caused networking bottlenecks and throttling is a nightmare in all cloud environments. None of the major clouds provide sufficient instrumentation or observability to understand why or if your VM's network is being throttled. Some have dynamic throttling policies that allow long bursts but suddenly degrade with no explanation.

For all of these reasons, we recommend running the WarpStream Agents on network-optimized instances, which allows the Agents to saturate their CPU before saturating the network interface. That situation is easier to understand, observe, and auto-scale on.

Auto-Scaling

When running the Agent on the appropriate instance type as described above, we recommend auto-scaling based on CPU usage with a target of 50% average usage. Our internal testing workload runs the Agent at more than 75% CPU usage with little latency degradation, but choosing an appropriate threshold requires balancing the concerns of cost efficiency and responsiveness to bursts of traffic that happen faster than your auto-scaler can react.

Automatic Availability Zone Detection

By default, the agent will try to reach the cloud provider metadata to detect in which availability zone the agent is running and advertise this to the WarpStream control plane. It currently supports AWS, GCP, and Azure.

If the agent appears with a warpstream-unset-az availability zone when you look at your virtual cluster in the WarpStream console, then it means it failed to do it. You should have a log error determining availability zone with possibly an explanation of what went wrong.

As a last resort, you can use the WARPSTREAM_AVAILABILITY_ZONEenvironment variable described in the table above to declare the availability zone in which your agent is running.

bucketURL is the URL of the object storage bucket that the WarpStream Agent should write to. See on how to construct a proper URL for the specific object storage implementation that you're using. The Deploy tab in the WarpStream UI for your BYOC cluster also has a utility to help you construct a well formed URL.

In addition to constructing a well-formed bucketURL, you'll also need to create and configure a dedicated object storage bucket for the Agents, and ensure that the Agents have the appropriate permissions to access that bucket. See on how to do that correctly.

If you are , please ensure that your bucketURL is in quotes to prevent any interpolation when running from the command line

You can contact us to request a new region by sending an email to .

The WarpStream Agents need permission to perform various different operations against the object storage bucket. Review for more details.

In addition to object storage access, the WarpStream Agent will also need permission to communicate with the control plane URL (see table above) in order to write/read Virtual Cluster metadata. Raw data flowing through your WarpStream will never leave your cloud account, only metadata required to order batches of data and perform remote consensus. You can read more about what metadata leaves your cloud account in our .

User for inter-agent communication within a single availability zone so the Agents can form a with each other. Also used to expose Prometheus metrics.

The advertiseHostnameStrategy flag allows you to choose how the agent will advertise itself in Warpstream service discovery (more details ). The default auto-ip4 is a good choice for most cases in production.

This number is usually right, but it may not be right depending on how the Agent is deployed. For example, the Agent may determine the wrong value when running in .

Using much larger instances is fine as well; just make sure to set the value of to ensure the Agent can make use of all the available cores even when running in a containerized environment (our helm chart does this automatically).

If you're using our , auto-scaling can be .

For instance, a known issue on AWS EKS is that the hop limit on old EKS node group is 1, preventing the call to AWS metadata from failing. Raising it to 2 should fix the issue (see ).

support@warpstreamlabs.com
security and privacy considerations documentation
distributed file cache
here
AWS ECS
official helm charts
enabled trivially
AWS doc
GOMAXPROCS
https://metadata.default.us-east-1.warpstream.com
https://metadata.default.ap-southeast-1.warpstream.com
https://metadata.default.us-west-2.warpstream.com
https://metadata.default.eu-central-1.warpstream.com
https://metadata.default.asia-south1.gcp.warpstream.com
https://metadata.default.us-central1.gcp.warpstream.com
https://metadata.default.europe-west1.gcp.warpstream.com
https://metadata.default.ap-northeast-1.warpstream.com
https://metadata.default.eastus.azure.warpstream.com
how to configure your Kafka client for WarpStream
tuning for performance
AWS ECS
Kubernetes Deployment
official Helm charts
WarpStream Admin Console
our documentation
our documentation
using a bucket prefix
our object storage permissions documentation
installation docs