- Sorunun tespiti
- Airbridge kimlik doğrulama sunucusunda aralıklı yanıt gecikmeleri meydana geldi.
- API isteklerinden önce kimlik doğrulama/yetkilendirme yapıldığından, kimlik doğrulama sunucusundaki gecikme tüm hizmetin kararlılığını doğrudan etkiliyordu.
- İzleme sonuçlarında 1 saniyeyi aşan yanıt gecikmesi uyarılarının giderek sıklaştığı görüldü → neden analizi ve optimizasyon çalışması başlatıldı.
- Neden analizi
- (1) Aşırı DB Query: Yetki kontrolü sürecinde her istekte çok fazla DB Query oluşuyordu, bu da DB Connection Pool'un hızla tükenmesine yol açıyor → yanıt gecikmesi oluşuyordu.
- (2) HikariCP Connection Pool doygunluğu: DB Query'lerin aşırı çalıştırılması sırasında HikariCP havuzu doyuma ulaşıyor → thread'lerin 30 saniyeden uzun süre beklediği doğrulandı.
- (3) Düşük cache verimliliği: TTL'in 30 saniye gibi kısa bir değere ayarlanması + verimsiz cache mantığı → DB Query'lerin yeniden oluşma olasılığı yüksekti.
- İyileştirme stratejisi
- (1) Yetki kontrolü ve cache yapısının iyileştirilmesi
- Toplu DB sorgulama (
findAllBy~) yöntemi devreye alındı → DB Query sayısı 134'ten 4'e indi (-97%).
- Uygulama belleği tabanlı
mutableMap cache uygulandı.
- Tek sorumluluk ilkesi (SRP) uygulandı → metotlar ayrıştırıldı ve alt mantık bazında cache stratejileri tanımlandı.
- (2) 2 katmanlı cache yapısının devreye alınması
- Local Cache (Caffeine, L1) + Remote Cache (Redis, L2) karma yapısı uygulandı.
- Cache stratejileri L1-Only, L2-Only ve Hybrid olarak ayrıştırılarak operasyonel verimlilik artırıldı.
- Cache bellek kullanımı analiz edildi → 500 bin Redis anahtarı öngörüldü, yaklaşık 190MB bellek gereksinimi hesaplandı ve güvenli tampon alan sağlandı.
- (3) Redis Pub/Sub tabanlı cache geçersizleştirme
- TTL bağımlılığından çıkılarak, yetki bilgisinde değişiklik olduğunda cache'in gerçek zamanlı senkronizasyonu sağlandı.
- Bir sunucuda değişiklik olduğunda, Redis kanalı üzerinden tüm sunucuların Local Cache'i eşzamanlı olarak geçersizleştirildi.
- (4) HikariCP connection pool ayarı
maximum-pool-size 10'dan 30'a çıkarıldı.- Connection Timeout, Idle Timeout, Max Lifetime gibi ayrıntılı seçenekler optimize edildi → DB I/O çekişmesi azaltıldı.
- Performans testleri ve sonuçlar: Büyük ölçekli trafikte de kararlı performans korundu.
- Üretim ortamındaki iyileştirme etkisi
- Dağıtımdan sonra yanıt gecikmesi uyarıları ortadan kalktı, genel yanıt süreleri dengelendi.
- Hizmet güvenilirliği ve operasyonel kararlılık önemli ölçüde arttı.
- Ek optimizasyon: JVM Warm-Up
- Dağıtımdan hemen sonra JIT derleme gecikmesinin ilk isteklerde yanıt gecikmesine yol açtığı tespit edildi.
- Warm-Up Runner devreye alındı:
- Uygulama başlatılırken önceden dummy istekler çalıştırıldı.
- K8s Pod değişiminde JIT tamamlandıktan sonra trafik işlendi → ilk yanıt süresi 1.07s'den 94ms'ye düşürüldü.
- Sonuç ve etkiler
- Yanıt gecikmesi sorunu çözüldü + trafik ani artışlarına dayanıklı bir yapı oluşturuldu.
- Airbridge genelinde hizmet kararlılığı ve güvenilirliği artırıldı.
- Kimlik doğrulama sunucusunun kullanım değeri yükseltilerek domain hizmet geliştirme verimliliği artırıldı.
2 yorum
Son dönemde Google derin bağlantı hizmetinin sona ermesiyle bu hizmeti kullanan şirketlerin sayısı artmış gibi görünüyor.
İstikrarlı bir hizmet bekliyorum!
Şey... bizim şirket de kısa süre önce burada sözleşme imzaladı, performans iyileştirmesi için çok sıkı çalışıyorsunuz anlaşılan!!!