Istio'yu esas olarak gözlemlenebilirlik için benimsedik. İstekler gözle görülür biçimde yavaşladı, hop başına yaklaşık 15ms ek gecikme ölçtük ve mesh'i söküp attık. Bu kararın yarısı doğruydu. Kararı tetikleyen ölçüm ise değildi.

Ne ölçtük, ne anlama geliyordu

Kaynakları doğru ayarlanmış bir sidecar, hop başına tek haneli düşük milisaniyeler ekler — Istio'nun kendi yayımladığı benchmark'lar bunu yıllardır gösteriyor. Hop başına on beş milisaniye bir service mesh'in bedeli değil, kaynaksız bırakılmış bir mesh'in belirtisidir. Bizimki kaynaksızdı: proxy CPU limitlerini kopyala-yapıştırla o kadar düşük ayarlamıştık ki sidecar'lar yük altında sürekli throttle ediliyordu. Kendi yanlış yapılandırmamızı benchmark'ladık ve faturasını teknolojiye kestik.

Mimarimiz etkiyi büyüttü. Checkout yolu bir düzine ardışık iç çağrıyı zincirliyordu — tek başına bile bir mimari kokusu. Hop başına gerçekçi ~2ms ile bu kabaca 25ms mesh ek yükü demek: fark edilir, tartışılır. Bizim throttle edilmiş 15ms'mizle ise 200ms'lik gecikme bütçesinde ~180ms'ydi; “Istio'yu kaldıralım” fikrinin bu kadar kolay kabul görmesi de böyle oldu.

Aslında neye ihtiyacımız vardı

  • Dağıtık izleme (distributed tracing): süreç içi OpenTelemetry SDK'ları — proxy gerekmez
  • Circuit breaker ve retry'lar: kütüphane tabanlı (Resilience4j)
  • Trafik yönetimi: bizim ölçeğimizde düz Kubernetes Service'leri yeterliydi
  • mTLS: listemizdeki tek gerçek mesh yeteneği. Bunu bilinçli olarak erteledik; belgelenmiş bir kararla ve yeniden ele alma tarihiyle — servisler arası trafiği şifrelemek “tehdit modelimizde yoktu” diye değil. İç trafik için zero-trust 2026'da asgari gerekliliktir; ertelemek kabul edilebilir, kalıcı olarak reddetmek değil.

Başta göz ardı ettiğimiz 2026 manzarası

Hop başına sidecar vergisi artık masadaki tek seçenek değil. Istio'nun ambient modu — 2024'ten beri GA — sidecar'ları tamamen kaldırıyor ve L4'ü paylaşımlı bir ztunnel ile milisaniyenin altında bir maliyetle hallediyor; Cilium'un mesh'i gibi eBPF tabanlı seçenekler de benzer işi kernel içinde yapıyor. İhtiyacınız mTLS ve trafik politikasıysa, sidecar'sız mesh'ler bunları klasik ek yükün çok küçük bir kesriyle sunuyor. Kategoriyi silip atmadan önce bunları değerlendirin — özellikle de Kubernetes'i üretimde gerçek bir ölçekte çalıştırmaya başladığınızda.

Nerede karar kıldık

  • Sidecar mesh'i kaldırdık; OTel izleme ve kütüphane tabanlı dayanıklılık ekledik — gecikme taban çizgisine döndü, cluster kaynak kullanımı kabaca %40 düştü
  • mTLS'in yeniden ele alınması takvimlendi; önde gelen aday ambient mod

Ders: Yalnızca gözlemlenebilirlik için mesh benimsemeyin — ve nedenine kadar izini sürmediğiniz rakamlara dayanarak da reddetmeyin. Doğru yapılandırılmış bir deployment'ı benchmark'layın, ek yükü dürüstçe fiyatlandırın, sonra karar verin.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #ServiceMesh #Kubernetes #Performans #ZeroTrust