Anycast load balancing

Revised existing load balancer infrastructure from a Layer 4 load balancer connected to a set of virtual machines, to a Layer 7 load balancer connected to a Kubernetes service.

This change improved sentry.io’s apex host and customer dashboards in several major ways:

1. By switching from unicast to anycast, round-trip time was dramatically reduced for users not near the us-central1 region in GCP; this, in turn, improves dashboard response times for humans
2. By shifting public TLS termination to the edge, client systems can now connect using HTTP/2, HTTP/3, or QUIC; new TLS protocol versions, features, and cipher suites are now available to Sentry engineers faster
3. By replacing VMs with Kubernetes pods, scaling nginx at the edge becomes a simple kubectl command instead of a lengthy provisioning process
4. By implementing a centralized WAF, access controls are considerably easier to maintain; this applies both to day-to-day actions like rate limiting, and to longer-term compliance goals
5. By (finally) disabling unencrypted HTTP ingestion, overall security is enhanced

Project link: https://blog.sentry.io/sentry-ingestion-domains-updates/

• TLS
• anycast
• WAF
• load balancer