Using Latency SLOs Instead of Error Rate in Argo Rollouts Canary Analysis

Benim ortamımda, canary promotions'u sadece error rate'ye dayandırmak kullanıcı deneyimini zarar görebilecek ince düşüşleri kaçırmamıza yol açar. Bir servis 200 OK döndürürken yanıt süreleri yavaşça kötüleşebilir — bu şey kullanıcılar tarafından hemen fark edilir, ama error-rate-tabanlı analiz bunu görmez. İşte bu yüzden Argo Rollouts'te canary analizi için latency SLO'lara geçtim. Bu, promotion kararlarını kullanıcıların gerçekten hissettikleriyle hizalar.

Temel fikir basit: HTTP 5xx veya başarısız istekleri ölçmek yerine, belirli bir gecikme eşiği altındaki isteklerin yüzdesini izliyoruz (örneğin p95 < 200ms). Eğer canary bu SLO'yu karşılıyorsa promotion yapıyoruz; karşılamıyorsa rollback yapıyor veya durduruyoruz. Bu yaklaşım, error rate düz kalsa bile performans regresyonlarını erken yakalar.

Son bir müşteriyle karşılaştığım API için bir rollout'ta bunu nasıl yapılandırdığımı gösteriyorum.

Defining Latency-Based Metrics in Argo Rollouts

Argo Rollouts, Prometheus üzerinden özel metrikler desteklediği için latency SLO entegrasyonu oldukça basit. 2 dakikalık bir pencerede 200ms altındaki isteklerin oranını hesaplayan bir metrik tanımladım.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: latency-slo
spec:
  args:
  - name: service-name
  metrics:
  - name: latency-slo
    interval: 30s
    count: 4
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          (
            sum(rate(http_request_duration_seconds_bucket{job="api", le="0.2"}[2m]))
            /
            sum(rate(http_request_duration_seconds_count{job="api"}[2m]))
          ) * 100
    successCondition: result >= 95
    failureCondition: result < 90
    limit: 3
    failFast: true

Bu sorgu, son 2 dakikada 200ms (le="0.2") altındaki isteklerin yüzdesini hesaplar. İsteklerin en az %95'i bu eşiği karşılıyorsa metrik geçer sayılır. %90'un altına düşerse başarısız sayılır. Gürültüyü azaltmak için 30s aralıkla 4 kez okuma kullanıyorum.

Integrating the Template into a Rollout

Sonra bu şablonu rollout spesifikasyonunun analysis bölümüne referans olarak ekledim. Bu, metriklerin canary adımı sırasında çalıştırılmasını sağlar.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - analysis:
          templates:
          - templateName: latency-slo
            args:
            - name: service-name
              value: api
      - setWeight: 50
      - analysis:
          templates:
          - templateName: latency-slo
            args:
            - name: service-name
              value: api
      - setWeight: 100

Analiz, %20 ve %50 trafik değişikliklerinde çalıştırılır. Latency SLO karşılanmazsa Argo Rollouts rollout'u durdurur ve geri alma işlemini başlatır. Bu, performansı kötü olan sürümlerin tam trafiğe ölçeklenmesini önler.

İpucu: Promotion sırasında gerçek zamanlı analiz sonuçlarını görmek için kubectl argo rollouts get rollout api-rollout --watch komutunu kullanın.

Why Latency SLOs Beat Error Rates for User Experience

Error rate ikili bir metriktir: bir istek ya başarısız olur ya da olmaz. Ancak latency her kullanıcı etkileşimini etkiler. Yavaş bir API sayfaları yanıtsız hiss ettirir, bounce rate'ini artırır ve güveni zayıflatır — her istek 200 döndürse bile.

Bir durumda, bir deploy yavaş bir veritabanı sorgusu getirdi ve p95 latensti 180ms'den 420ms'e çıktı. Error rate 0.1%'de kaldı, bu yüzden geleneksel analiz onu promote edecekti. Ama latency SLO %98'den %65'e düştü ve otomatik rollback tetikledi. Kullanıcılar bu düşüşü hiç hissetmedi.

Bu yaklaşım ayrıca SRE uygulamalarıyla da uyumludur: sadece başarısızlıktan kaçınmak yerine, SLO'larımızda vaat ettiğimizi ölçüyoruz. Bu, zihniyetimizi "bozuk mu?" yerine "yeterince hızlı mı?" sorusuna çevirir.

Common Pitfalls and How I Avoid Them

Yanlış hizalanmış eşikler: Kendi servisinizin bazeline göre ayarlanmamış başka birinin latency hedefini kopyalamak yanlış pozitiflere veya regresyonları kaçırmamıza yol açar. Ben her zaman SLO belirlemeden önce 4 haftalık p95/p99 verilerini incelemeyi tercih ederim.

Prometheus sorgusu hataları: rate() eksikliği veya yanlış bucket etiketi metriği bozar. Prometheus UI'da sorguları önce test ederim, sonra AnalysisTemplate'e kopyalarım.

Çok kısa pencereler: 10s gibi kısa aralıklar doğal varyansa bağlı dalgalanmalara yol açar. Ben 30s-1m aralıklar arasında kalmayı ve birden fazla okuma yapmayı tercih ederim.

Ağ gürültüsünü görmezden gelmek: Service mesh veya ingress gecikmesi sonuçları eğebilir. Metriği uygulama katmanına (job="api") izole ederek, rollout'u altyapı sorumluluğundan arınmaya çalışırım.

When to Still Use Error Rate

Latency SLO'lar error rate analizini değiştirmez — onu tamamlar. Ben kritik başarısızlık modları için (örneğin 5xx tırmanışı, timeout zincirleri) error-rate kontrollerini de tutarım. Birleşik bir yaklaşım en iyi sonucu verir:

Latency SLO → normal başarısızlık modlarında kullanıcı deneyimini korur
Error rate → sert hataları, zincirlemeleri veya downtime'i yakalar

Bu bende katmanlı koruma sağlar: hem performans regresyonlarını hem de kesintileri hızlıca tespit ederim.

Final Thoughts

Argo Rollouts'te latency SLO'lara geçiş, benim release kalitesini nasıl değerlendirdiğimi değiştirdi. Artık sadece servisin çalışıp çalışmadığına değil, kullanıcılar için iyi çalışıp çalışmadığına bakıyorum. Kullanıcıların gerçekte deneyimlediklerini ölçerek, sorunları daha erken yakalarım, suçlama oyunlarını azaltırım ve daha güvenle yayın yaparım.

Argo Rollouts kullanıyorsanız ve canary kararlarını sadece error rate'ye dayandırıyorsanız, latency-tabanlı analiz eklemeyi deneyin. Tek bir servis ile başlayın, latency bazelinizi belirleyin ve promotion davranışının nasıl değiştiğini gözlemleyin. Error'lerin kaçırdığı şeyleri latency'ın yakaladığı kadar sıklıkla göreceksiniz.

Kapak görseli: Mikecligon · CC0 (Wikimedia Commons / kamu malı) · https://commons.wikimedia.org/wiki/File:Michael_Ligon_Stock_Market_Conference_2023.png