Mock servisler, chaos ve kapasite planlama

Bu sayfa üç ayrı aracı anlatır:

1. Mock servisler — ödeme, SMS, kargo gibi dış API'lerin yerine yanıt veren mock'lar; yük testi gerçek sağlayıcıları ne yorar ne de ücretlendirir.
2. Yük altında fault injection (chaos) — Kubernetes'te koşu sırasında pod silmek ya da ağ gecikmesi eklemek ve sistemin ne kadar sürede toparlandığını ölçmek.
3. Kapasite planlama — bir kırılma noktası koşusundan "X kullanıcı için kaç pod gerekir?" tahmini.

#Mock servisler

#Ne işe yarar

Yük testi sırasında test edilen sisteminiz bir ödeme sağlayıcısını, SMS servisini ya da kargo API'sini çağırıyorsa, bu çağrılar gerçek sağlayıcıya gitmemelidir: ücretlendirilir, rate limit'e takılır, gerçek SMS gider. Mock servisler bunların yerine yanıt verir:

• Her servis bir slug altında (http://<mock-host>:8472/<slug>/…) endpoint'lere (metot ve /v1/orders/:id gibi yol kalıbı) şablon yanıtla (durum, header'lar, gövde) cevap verir.
• Seçilen gecikme dağılımıyla bekler (sabit, düzgün, p50/p95 ile normal ya da log-normal; en çok 60 sn): gerçek sağlayıcının gecikmesini taklit eder.
• Belirlediğiniz hata oranında kendi durum kodu ve gövdesiyle hata döner: sisteminizin sağlayıcı hatalarında nasıl davrandığını yük altında görürsünüz.
• Hazır şablonlar: iyzico (test taklidi), PayTR (test taklidi), SMS sağlayıcısı (genel) ve Kargo API'si (genel).

#Ne zaman kullanılır

• Test ortamınız bir dış servise bağımlıysa ve o servisin test ortamı yük kaldırmıyorsa.
• Dış servisin yavaşlığının ya da hatalarının sisteminize etkisini kontrollü ölçmek istediğinizde (ör. ödeme sağlayıcısı p95 800 ms olursa ne olur?).

#Önce: mock dinleyicisini açın

Mock dinleyicisi varsayılan olarak kapalıdır (her planda vardır). Tanımları kaydedebilirsiniz ama dinleyici açık değilse yanıt veren olmaz; sayfa bunu Mock dinleyicisi kapalı. ile söyler. İki seçenek:

A) Controller içinde (Docker kurulumu):

1. Kurulum dizininde deploy/docker/.env dosyasına SPITFIRE_MOCK_ADDR=:8472 ekleyin.
2. deploy/docker/docker-compose.yml içinde controller'ın ports bölümündeki hazır yorum satırını (# - "8472:8472") açın.
3. Controller'ı yeniden başlatın (ör. kurulum komutunu yeniden çalıştırarak).
4. Sayfada "Controller mock servisleri … adresinde sunuyor." görmelisiniz.
5. Test edilen sistem controller'a başka bir adla erişiyorsa (ör. iç DNS adı) gösterilen adresi SPITFIRE_MOCK_PUBLIC_URL ile ayarlayın (ör. http://spitfire.internal:8472).

B) Ayrı bir konteyner olarak (test edilen sisteme yakın, aynı imajdan):

docker run -p 8472:8472 -e SPITFIRE_URL -e SPITFIRE_TOKEN algebransoft/spitfire spitfire mock

Tanımları API token'ıyla alır ve 30 sn'de bir yeniler (--refresh). İnternetsiz bir ağda sayfadan JSON indir ile dosyayı alıp sunabilirsiniz:

spitfire mock --file mock-services.json

Bu durumda sayaçlar mock adresindeki /_spitfire/stats'tadır (sayfada görünmez).

#Mock servis oluşturma

Mock servisler sayfası

1. Sol menüde Altyapı → Mock servisler'i açın.
2. Yeni mock servis'e basın. Başlangıç penceresinde bir şablon seçin: iyzico, PayTR, SMS, kargo ya da Boş servis (başlangıç için tek endpoint). Kaydetmeden önce her endpoint'i değiştirebilirsiniz.
3. Ad ve Yol öneki (slug) verin. Servis mock adresinde /<slug>/ altında yanıt verir (ör. slug odeme → http://mock-host:8472/odeme/…).
4. Endpoint'ler bölümünde her endpoint için:
   • Metot (ANY her metodu karşılar) ve Yol: sabit metin, tek parça için bir parametre (/v1/orders/:id) ve kalan her şey için sonda *. İlk eşleşen endpoint yanıtlar.
   • Durum (ör. 200).
   • Response header'ları: satır başına bir tane, Ad: değer.
   • Response body: yer tutucularla (aşağıda).
   • Gecikme: Yok, Sabit, Düzgün (En az (ms), En çok (ms)), Normal ya da Log-normal (p50 ve p95 ile). Log-normal gerçek servisler gibi uzun bir sağ kuyruk verir.
   • Hata oranı, Hata durumu ve Hata body'si: isteklerin bu oranı yerine hata alır (aynı gecikmeden sonra).
   • Başka endpoint için Endpoint ekle.
5. Kaydet'e basın.
6. Servis kartında Test edilen sistemin adresi görünür; Kopyala ile alın.
7. Test edilen sistemi bu adrese yönlendirin: test ortamında sağlayıcının base URL ayarına bu adresi yazın. Spitfire çağrıları kendisi yönlendiremez.
8. Bir istek gönderin ve Son istekler'de görün (son 50 istek, 2 sn'de bir yenilenir; gövde ve header'lar saklanmaz).

Yeni mock servis: şablon seçimi

Response body yer tutucuları:

Content-Type JSON ise istek değerleri JSON metni için kaçışlanır.

Servis kartındaki sayaçlar: İstek, Üretilen hata (hata oranı nedeniyle), Endpoint yok / kapalı ve Son istek. Kapat (503 döner) servisi silmeden kapatır, Aç yeniden açar. Mock servis oluşturma, değiştirme, açma/kapama ve silme denetim kaydına geçer.

#Yük altında fault injection (chaos)

#Ne işe yarar

Test edilen sistem Kubernetes'te çalışıyorsa, bir koşu seçilen anda pod silebilir (Deployment ya da StatefulSet yenilerini başlatır) ya da onlara ağ gecikmesi ekleyebilir. Koşu toparlanma süresini ölçer: enjeksiyondan (gecikmede hatanın bitişinden) koşunun p95'i ve hata oranı, verdiğiniz sınırların içine bekleme süresi boyunca (varsayılan 5 sn) dönene kadar. Hiç isteğin tamamlanmadığı bir saniye asla toparlanmış sayılmaz.

#Ne zaman kullanılır

• "Bir checkout pod'u yük altında ölürse kullanıcılar ne kadar süre hata görür?"
• "Veritabanına giden yola 200 ms eklenirse p95 ne olur, sistem toparlanır mı?"

#Gereksinimler

• Spitfire controller'ı Kubernetes'te çalışmalı ve test edilen sisteme ulaşabilen bir kümede olmalı. Değilse "Fault injection kullanılamıyor: controller Kubernetes'te çalışmıyor" yazar.
• Ağ gecikmesi için tc (iproute2) içeren, kümenizin çekebildiği bir imaj gerekir. Yoksa yalnız pod silme sunulur.
• baseline ya da restricted Pod Security Standard uygulayan namespace'ler NET_ADMIN'i reddeder; oralarda yalnız pod silme çalışır.

#Güvenlik: varsayılan kapalı, her adımda korunur

Adım adım açmak:

1. Bir admin kurulum için açar: Runner'lar sayfasında Yük altında fault injection (Kubernetes) kartında Bu kurulumda fault injection'a izin ver'i işaretleyin.
2. İzin verilen namespace'ler'i virgülle yazın (test ortamları). Asla tüm küme: namespace her zaman gerekir, kube-* namespace'leri listelense bile reddedilir ve Spitfire'ın kendi pod'larına asla dokunulmaz.
3. İsterseniz Ağ gecikmesi için imaj (isteğe bağlı) ve Arayüz girin. İmaj NET_ADMIN yetkili bir geçici (ephemeral) konteyner olarak çalışır.
4. Kubernetes de izin vermeli. Controller'ın servis hesabının kendi namespace'i dışında hiçbir yetkisi yoktur. Küme operatörü deploy/kubernetes/fault-injection.yaml dosyasını izin verilen her namespace'e uygular (pod get/list/delete, pods/ephemeralcontainers patch); yetkiyi geri almak için siler.

#Bir koşuda hata enjekte etmek

1. Test sayfasında Çalıştır'a basın (yalnız admin; API token'ıyla olmaz).
2. Koşu sırasında hata enjekte et (Kubernetes)'i açın ve Hata ekle'ye basın.
3. Her hata için:
   • Eylem: Pod sil ya da Ağ gecikmesi (imaj yoksa "tc imajı gerekir").
   • Namespace: izin verilenlerden biri.
   • Etiket seçici: zorunlu, ör. app=checkout ya da tier in (web).
   • Zaman: koşu başından saniye (koşunun planlanan bitişinden önce olmalı).
   • Pod: kaç pod (1–50).
   • Ağ gecikmesinde Gecikme (1–10000 ms) ve Süre (5–1800 sn).
   • Toparlanma sınırları: Toparlandı: p95 ≤ … ve hata ≤ … boyunca … sn (1–60).
4. Dry run: eşleşen pod'ları göster ile seçicinin şu an eşleştiği pod'ları görün: "Çalışan N pod'dan M tanesine uygulanır". Pod'lar, hatanın zamanı geldiğinde çalışanlar arasından rastgele seçilir; liste o zamana kadar değişebilir.
5. "Bu koşunun aşağıdaki namespace'lerde gerçek pod'ları sileceğini ya da bozacağını anlıyorum" kutusunu işaretleyin.
6. Onaylamak için namespace'leri yazın (virgülle).
7. Başlatın. Onay, koşu oluşmadan denetim kaydına yazılır; denetim kaydı yazılamazsa koşu da başlamaz.

#Sonucu okumak

Koşu sayfasındaki Fault injection kartı ve rapor her hata için şunları listeler: Zaman, Hata (ör. "2 pod sil", "60 sn boyunca +200 ms"), Durum (planlandı, uygulandı, başarısız, atlandı), vurduğu pod'lar, En kötü p95, En kötü hata oranı ve Toparlanma — "12 sn", "ölçülebilir etki yok" ya da "… anına kadar toparlanmadı". Her enjeksiyon koşu logunda ve denetim kaydında da görünür.

#Kapasite planlama

#Ne işe yarar

Biten bir kırılma noktası koşusunun sayfasında Kapasite planlama kartı, bulunan kırılma noktasını hedef eşzamanlı kullanıcı sayısına ölçekler: "5 000 eşzamanlı kullanıcı için ≈ 18 örnek (aralık 15–18)". Bu bir TAHMİN — ölçüm değildir; kart dayandığı her varsayımı açıkça yazar.

#Adım adım

1. Önce bir kırılma noktası koşusu yapın: test sayfasında Çalıştır → Kırılma noktasını bul (kapasite testi). Başlangıç, Artış, En çok, Basamak süresi, p95 sınırı ve Hata oranı sınırı'nı girin ve başlatın.
2. Koşu bitince sayfasında Kapasite planlama kartını bulun.
3. Koşudaki örnek sayısı: koşu sırasında test edilen endpoint'in arkasındaki pod ya da sunucu sayısı. Spitfire sistemi görmez; bu sayıyı siz girersiniz.
4. Hedef eşzamanlı kullanıcı: planladığınız kullanıcı sayısı.
5. Kullanıcı başına iterasyon/sn: boş bırakılırsa koşudan hesaplanır (bir kullanıcı = testin bir sanal kullanıcısı, düşünme süresi dahil; Little yasası). Kendi değerinizi de girebilirsiniz.
6. Yedek kapasite: %0–90 arası.
7. Sonucu okuyun: başlık, aralık, Güven (düşük ya da orta; doğrusal ölçekleme ölçülmediği için hiçbir zaman ortadan yüksek değildir), Varsayımlar ve Verinin söyledikleri.
8. İsterseniz Koşuya kaydet: girdiler bu tahmini, varsayımlarıyla birlikte koşu raporuna koyar.

#Varsayımlar ve sınırlar

• Kırılma noktasına kadar doğrusal ölçekleme: bir örnek, kırılma noktasında taşıdığını taşır ve paylaşılan bağımlılıklar (veritabanı, önbellek, kuyruklar, dış servisler) önce doymaz.
• Kullanıcılar testin senaryosu gibi davranır (kırılma noktası koşusu tek senaryoyu koşturur).
• Gerçek kırılma noktası geçen basamakla geçemeyen basamak arasındadır; aralık iki ucu da gösterir.
• Hiçbir basamak başarısız olmadıysa ya da yük üretecinin VU'su bittiyse sayı bir üst sınırdır ("en çok").
• CPU'su doymuş bir yük üreteci ve ölçülen kırılma noktasının çok ötesindeki bir hedef güveni düşürür.
• Test edilen sistemin kaynak metrikleri (CPU, bellek) bu tahminde kullanılmaz; kart tahminin yalnız verime dayandığını söyler.

#Sık karşılaşılan sorunlar

#İlgili sayfalar

• Gözlemlenebilirlik — kırılma anında hangi kaynağın doyduğu
• Sürüm karşılaştırma — iki kolun kırılma noktaları yan yana
• Sorun giderme
• Mock servisler Spitfire'da: /mock-services · Runner'lar Spitfire'da: /runners