Java ve Azure Cosmos DB’de Gecikme ve Thread Pool Sorunları Tanılama

Modern Java uygulamalarınız ve Azure Cosmos DB arasındaki bölgeler arası gecikme ile iş parçacığı havuzu (thread pool) tükenmesi sorunlarını adım adım nasıl teşhis edeceğinizi ve çözeceğinizi öğrenin. Bu kapsamlı rehber, performans ipuçları, vaka analizleri ve pratik çözümlerle uygulamanızın performansını maksimize etmenize yardımcı olacak.

Her şeyden önce, bölgeler arası gecikmenin ne olduğunu ve uygulamanız için neden ciddi bir baş ağrısı yaratabileceğini anlamak önemlidir. Temel olarak, uygulamanızın çalıştığı coğrafi bölge (örneğin, Azure Sanal Makinesi veya Azure App Service) ile Azure Cosmos DB veri tabanınızın konuşlandırıldığı coğrafi bölge arasındaki fiziksel mesafeden kaynaklanan ağ gecikmesidir. Veri, sunucular arasında ışık hızında bile olsa, kat ettiği her kilometreye göre belirli bir gecikmeye sahiptir. Bu gecikme, ışığın boşluktaki hızı yaklaşık olarak saniyede 300.000 kilometre olsa da, gerçek ağlarda fiber optik kablolar, yönlendiriciler ve diğer ağ ekipmanları nedeniyle daha yavaş seyreder. Bu durum, veri isteğinin gönderilip yanıtın alınması arasındaki toplam süreyi (Round-Trip Time – RTT) artırır.

Peki, bu durum Java uygulamanızı nasıl etkiler? Bir e-ticaret uygulamasını düşünün. Uygulama sunucularınız Avrupa’da (örneğin, Batı Avrupa Azure bölgesi) konuşlandırılmışken, Azure Cosmos DB hesabınız Amerika’da (örneğin, Doğu ABD Azure bölgesi) olabilir. Müşterileriniz Avrupa’dan ürün listelerini görüntülerken veya sipariş verirken, her veri okuma ve yazma isteği binlerce kilometrelik bir yolculuk yapmak zorunda kalır. Her bir veritabanı işlemi, bu uzun mesafeyi kat etmek için ek milisaniyeler gerektirecektir. Sayfada birden fazla veri tabanı çağrısı olduğunda (örneğin, ürün detayları, fiyatlandırma, envanter durumu gibi), bu küçük gecikmeler birikerek saniyeler süren toplam yanıt sürelerine dönüşebilir. Kullanıcılar için bu, yavaş yüklenen sayfalar, takılan işlemler ve genel olarak kötü bir deneyim anlamına gelir. Bu da müşteri kaybına ve iş performansı düşüşüne yol açabilir.

Bölgeler arası gecikme sadece uygulamanızın bulunduğu bölge ile Cosmos DB’nin tek bir yazma bölgesi arasındaki mesafeden kaynaklanmaz. Eğer Cosmos DB hesabınız farklı bölgelere replike edilmişse ve uygulamanız en yakın okuma bölgesine yönlendirilse bile, tutarlılık modeli de gecikmeyi etkileyebilir. Örneğin, “Strong” (Güçlü) tutarlılık seviyesi, verinin tüm bölgelerde senkronize olmasını gerektirdiği için yazma işlemlerinde daha yüksek gecikmelere neden olabilir. “Session” veya “Eventual” gibi daha gevşek tutarlılık modelleri ise daha düşük yazma gecikmeleri sunar ancak farklı okuma bölgelerinden yapılan okumalarda verinin biraz eski olma potansiyeli vardır. Bu nedenle, uygulamanızın gereksinimlerine en uygun tutarlılık modelini seçmek de önemlidir.

Bölgeler arası gecikmeyi anlamak ve ele almak, yüksek performanslı ve dağıtık sistemler geliştirmenin temel taşlarından biridir. Optimizasyon stratejileri, uygulamanızı ve veri tabanınızı coğrafi olarak yakınlaştırmak, Cosmos DB’nin çok bölgeli yazma (multi-region writes) yeteneğini kullanmak ve doğru tutarlılık seviyesini seçmek üzerine odaklanmalıdır. İlk aşamada, uygulamanızın ve Cosmos DB’nizin hangi bölgelerde olduğunu basit bir kontrol ile belirlemek, potansiyel gecikme kaynaklarını belirlemede kritik bir adımdır.

Java Uygulamalarında Thread Pool Tükenmesi (Exhaustion) Neden Gerçekleşir ve Nasıl Anlaşılır?

İş parçacığı havuzu (thread pool) tükenmesi, özellikle yüksek yük altında veya hatalı programlama desenleri kullanıldığında Java uygulamalarında sıkça rastlanan ve ciddi sorunlara yol açabilen bir performans sorunudur. Bir iş parçacığı havuzu, uygulamanızın eş zamanlı olarak işleyebileceği görev sayısını sınırlayan ve yöneten bir dizi önceden oluşturulmuş iş parçacığını (thread) içerir. Her bir gelen istek (örneğin, bir HTTP isteği, bir mesaj kuyruğu işlemi veya bir veri tabanı çağrısı), havuzdan bir iş parçacığı alarak işlenir. Bu mekanizma, her istek için yeni bir iş parçacığı oluşturmanın getireceği ek yükü (thread creation overhead) ortadan kaldırarak performansı artırmayı hedefler.

Ancak, eğer veri tabanı çağrıları gibi G/Ç (I/O) yoğun işlemler çok uzun sürerse, ya da iş parçacıkları yanlışlıkla bloke olursa (blocking I/O), havuzdaki tüm iş parçacıkları meşgul hale gelebilir ve yeni görevler için iş parçacığı kalmayabilir. Bu “tükenme” durumu, yeni gelen isteklerin işlenememesine ve genellikle uygulama donmalarına, isteklerin kuyrukta beklemesine veya hata yanıtlarına (örneğin, HTTP 503 Service Unavailable, Connection Timeout) yol açar. Bir iş parçacığının bloke olması, diğer gelen isteklerin de beklemeye alınmasına ve “kar topu etkisi” yaratarak tüm uygulamanın yavaşlamasına veya durmasına neden olabilir.

Thread pool tükenmesinin başlıca nedenleri şunlardır:

1. Uzun Süreli Blocking I/O İşlemleri: Veri tabanı sorguları, harici API çağrıları, dosya okuma/yazma gibi I/O işlemleri, senkron (blocking) bir şekilde yapıldığında, işlem tamamlanana kadar iş parçacığını meşgul eder. Eğer bu işlemler bölgeler arası gecikme nedeniyle uzarsa, iş parçacığı daha uzun süre bloke kalır.
2. Yetersiz Thread Pool Boyutu: Uygulamanızın aynı anda işleyebileceği maksimum istek sayısını karşılayacak kadar büyük olmayan bir iş parçacığı havuzu boyutu, yoğun yük altında hızla tükenmeye yol açabilir.
3. İş Parçacığı Sızıntıları (Thread Leaks): Hatalı kodlama veya kaynak yönetimi nedeniyle iş parçacıklarının serbest bırakılamaması (örneğin, bir hata durumunda kaynakların kapatılmaması), havuzdaki iş parçacıklarının zamanla tükenmesine neden olabilir.
4. Uzun Süreli CPU Yoğun İşlemler: Nadiren de olsa, aşırı CPU yoğun hesaplamalar da bir iş parçacığını uzun süre meşgul edebilir, ancak I/O blokajları daha yaygın bir nedendir.

Peki, bu sorunu nasıl anlarsınız? Uygulamanızın loglarında “thread pool exhausted”, “connection timeout” veya “too many open connections” gibi hata mesajlarını aramalısınız. Ayrıca, izleme araçları (örneğin, JMX metrikleri, Azure Application Insights) aracılığıyla aktif iş parçacığı sayısını, kuyruktaki görev sayısını ve iş parçacığı havuzu boyutunu gözlemlemek de önemlidir. İş parçacığı sayısının maksimum limite ulaştığını ve kuyruk boyutunun sürekli arttığını görüyorsanız, bu durum thread pool tükenmesinin açık bir işaretidir. JVM’de JStack gibi araçlar kullanarak iş parçacığı dökümü almak, hangi iş parçacıklarının ne yaptığını ve nerede bloke olduğunu anlamanıza yardımcı olabilir. Bu dökümlerde “WAITING (on object monitor)” veya “BLOCKED (on object monitor)” durumundaki iş parçacıklarının sayısının yüksek olması, bir darboğazın varlığına işaret eder.

Problemleri Teşhis Etmeye Başlangıç: İlk Adımlar ve Gözlem Araçları

Herhangi bir performans sorununu çözmenin ilk adımı, sorunun nerede olduğunu doğru bir şekilde teşhis etmektir. Bölgeler arası gecikme ve iş parçacığı havuzu tükenmesi sorunlarını teşhis etmek için bir dizi araca ve yönteme ihtiyacımız var. Bu adımlar, sorunun kaynağını belirlemenize ve doğru çözüme yönelmenize yardımcı olacaktır.

1. Bölgesel Konumlandırmayı Kontrol Edin:

Öncelikle, uygulamanızın ve Azure Cosmos DB hesabınızın coğrafi konumlarını kontrol edin. Azure Portal üzerinden Cosmos DB hesabınızın “Replicate data globally” (Verileri küresel olarak çoğalt) bölümüne giderek hangi bölgelerde konuşlandırıldığını görebilirsiniz. Aynı şekilde, Java uygulamanızın çalıştığı Azure Sanal Makinesi, App Service veya Kubernetes kümesinin hangi Azure bölgesinde olduğunu da teyit edin. Eğer aralarında büyük bir coğrafi mesafe varsa (örneğin, uygulamanız Batı Avrupa, Cosmos DB Doğu ABD), bu durum gecikmenin ana kaynağı olabilir.

2. Uygulama Loglarını İnceleyin:

Uygulamanızın logları, sorunların ilk belirtilerini gösteren en zengin kaynaklardan biridir. Yavaş çalışan veri tabanı sorguları, zaman aşımı hataları (timeout errors), bağlantı hataları veya iş parçacığı havuzuyla ilgili uyarılar/hatalar (örneğin, “Thread pool exhausted”, “Connection timed out”, “Request queue full”) için loglarınızı tarayın. Log seviyenizi DEBUG veya INFO seviyesine çekerek Cosmos DB SDK’sının dahili mesajlarını da görmeyi düşünebilirsiniz. Özellikle, isteğin ne kadar sürdüğünü gösteren metrikleri loglamanız, yavaş çağrıları tespit etmenize yardımcı olacaktır.

// Örnek: Basit bir zaman ölçümü ve loglama
long startTime = System.currentTimeMillis();
// Cosmos DB işlemi burada gerçekleşir
// ... container.readItem(...)
long endTime = System.currentTimeMillis();
long duration = endTime - startTime;
System.out.println("Cosmos DB okuma işlemi " + duration + " ms sürdü.");

3. Azure Monitör ve Application Insights Kullanımı:

Azure Monitor ve Application Insights, Azure ortamındaki uygulamalarınız için olmazsa olmaz izleme araçlarıdır. Bu araçları kullanarak:

• Cosmos DB Metrikleri: Azure Cosmos DB hesabınız için ortalama istek gecikmesi, RU/s tüketimi, normalize edilmiş RU tüketimi ve sunucu tarafı gecikmeleri gibi metrikleri izleyin. Ani artışlar veya sürekli yüksek gecikmeler, veri tabanı tarafında bir soruna işaret edebilir.
• Uygulama Metrikleri: Application Insights aracılığıyla Java uygulamanızın HTTP istek gecikmeleri, bağımlılık çağrısı gecikmeleri (Cosmos DB çağrıları dahil), CPU ve bellek kullanımı, iş parçacığı sayısı ve kuyruk uzunlukları gibi metriklerini takip edin. "Dependencies" (Bağımlılıklar) bölümünde Cosmos DB çağrılarının ne kadar sürdüğünü görebilirsiniz.

Application Insights, çağrı yığınlarını (call stacks) ve performans profillerini de toplayabilir, bu da hangi kod parçalarının daha uzun sürdüğünü ve potansiyel olarak iş parçacıklarını bloke ettiğini belirlemenize yardımcı olur. Özellikle uzun süreli Cosmos DB çağrıları, thread pool tükenmesinin en büyük tetikleyicilerinden biridir.

4. Ağ Teşhis Araçları:

Uygulamanızın çalıştığı sanal makineden veya kapsayıcıdan Cosmos DB uç noktasına doğru basit ağ teşhisleri yapın. ping veya traceroute (Windows'ta tracert) gibi komutlar, paketlerin hedefe ulaşması için geçen süreyi ve aradaki atlamaları (hops) göstererek ağ gecikmesi hakkında temel bir fikir verebilir. Yüksek RTT değerleri veya beklenmedik atlamalar, ağ tarafında bir soruna işaret edebilir. Ancak, bulut ortamlarında güvenlik duvarları ve NAT gibi faktörler nedeniyle bu araçların etkinliği sınırlı olabilir.

Bu ilk adımlar, sorunun genel resmini çizmenize ve daha derinlemesine incelemeler için doğru yöne odaklanmanıza olanak tanır. Teşhis sürecinde sabırlı olmak ve her bir veri noktasını dikkatle incelemek, doğru çözüme ulaşmanın anahtarıdır.

Azure Cosmos DB Tarafında Gecikme Kaynaklarını Anlamak ve Azaltmak

Cosmos DB tarafında gecikmeyi azaltmak, doğru konfigürasyon, veri modellemesi ve tutarlılık modeli seçimi ile başlar. Uygulamanızın performansını etkileyen en önemli faktörlerden biri, veri tabanı ile olan iletişim gecikmesidir. Bu bölüm, Cosmos DB tarafındaki başlıca gecikme kaynaklarını ve bunları nasıl azaltabileceğinizi detaylandıracaktır.

1. Bölgesel Yakınlık ve Çok Bölgeli Yazma (Multi-Region Writes):

En temel ve etkili optimizasyon, uygulamanızın ve Cosmos DB hesabınızın coğrafi olarak mümkün olduğunca yakın konumlandırılmasıdır. Eğer uygulamanız yalnızca tek bir Azure bölgesinde çalışıyorsa, Cosmos DB hesabınızın da aynı bölgede birincil yazma bölgesi olarak yapılandırıldığından emin olun. Ancak, uygulamanızın kullanıcıları veya hizmetleri farklı coğrafi bölgelerde bulunuyorsa, Cosmos DB'nin "çok bölgeli yazma" özelliğini etkinleştirmek oyun değiştirici olabilir. Bu özellik, uygulamanızın en yakın veri tabanı kopyasına hem okuma hem de yazma işlemleri yapmasına olanak tanır. Böylece, veri tabanına her erişimde verinin coğrafi olarak yakın bir kopyasına yönlendirilirsiniz, bu da bölgeler arası gecikmeyi önemli ölçüde azaltır.

2. Tutarlılık Modeli Seçimi:

Azure Cosmos DB, beş farklı tutarlılık modeli sunar: Strong (Güçlü), Bounded Staleness (Sınırlı Eskime), Session (Oturum), Consistent Prefix (Tutarlı Önek) ve Eventual (Nihai). Seçtiğiniz tutarlılık modeli, yazma ve okuma gecikmeleri üzerinde doğrudan bir etkiye sahiptir:

• Strong: En yüksek tutarlılığı sağlar ancak tüm bölgelerde verinin senkronize olmasını gerektirdiği için yazma işlemlerinde en yüksek gecikmeyi sunar. Genellikle kritik iş yükleri için tercih edilir.
• Bounded Staleness: Belirli bir süre veya belirli bir işlem sayısı kadar geride kalmaya izin veren bir ara yoldur. Güçlü tutarlılığa göre daha düşük gecikme sunar.
• Session: En yaygın kullanılan modeldir. Belirli bir istemci oturumu için güçlü tutarlılığı garanti eder ancak diğer oturumlar güncel olmayan verileri görebilir. İyi bir performans ve tutarlılık dengesi sunar.
• Consistent Prefix ve Eventual: En düşük gecikmeyi ve en yüksek işlem hacmini sunar, ancak verinin diğer bölgelerde güncellenmesinin biraz zaman alabileceği anlamına gelir. Yüksek oranda okunabilir uygulamalar veya gerçek zamanlı veri gerektirmeyen senaryolar için uygundur.

Uygulamanızın gereksinimlerine göre en gevşek ama kabul edilebilir tutarlılık modelini seçmek, özellikle yazma işlemleri için gecikmeleri önemli ölçüde azaltabilir.

3. Dizinleme Stratejileri (Indexing Strategies):

Yanlış veya eksik dizinleme, sorgu performansını düşürerek gecikmeleri artırabilir. Cosmos DB, varsayılan olarak tüm özellikler için otomatik dizinleme yapar, ancak bazen bu, performans için ideal olmayabilir. İhtiyaç duymadığınız özellikler için dizinlemeyi devre dışı bırakarak yazma işlemlerinin maliyetini ve gecikmesini azaltabilirsiniz. Ayrıca, sıkça sorguladığınız özellikler üzerinde özel bileşik dizinler oluşturmak, karmaşık sorguların daha hızlı çalışmasını sağlayabilir. Dizinleme politikalarınızı, uygulamanızın sorgu desenlerini analiz ederek optimize edin.

4. Sağlanan İşlem Hacmi (RU/s) Yönetimi:

Cosmos DB'de her işlem bir İstek Birimi (Request Unit - RU) tüketir. Yetersiz RU/s sağlandığında, Cosmos DB istekleri kısıtlayabilir (throttling), bu da uygulamanızda gecikmelere ve hata mesajlarına (HTTP 429) yol açar. Yüksek yük altında veya anlık yoğunluklarda bu durum sıkça yaşanır. Auto-scale (Otomatik Ölçeklendirme) özelliği, iş yükünüze göre RU/s'yi dinamik olarak ayarlayarak kısıtlamaları minimize etmeye yardımcı olabilir. Ayrıca, en maliyetli sorgularınızı belirleyerek optimize etmek (örneğin, daha az veri okumak, daha verimli filtreler kullanmak), RU/s tüketimini azaltır ve genel gecikmeyi düşürür.

5. Cosmos DB SDK Bağlantı Modu (Gateway vs. Direct):

Azure Cosmos DB Java SDK'sı, iki farklı bağlantı modu sunar: Gateway (Ağ Geçidi) ve Direct (Doğrudan). Her birinin kendine özgü avantajları ve dezavantajları vardır:

• Gateway Modu: Tüm istekler tek bir ağ geçidi hizmeti üzerinden geçer. Bu mod genellikle daha az bağlantı yönetimi gerektirir ve güvenlik duvarı kurallarını basitleştirir. Ancak, istek başına daha fazla ağ atlaması olduğu için genellikle daha yüksek gecikme sunar.
• Direct Modu: İstemci, arka uç bölmelerine doğrudan bağlanır. Bu, ağ atlamalarını azaltır ve genellikle daha düşük gecikme ve daha iyi performans sunar. Özellikle düşük gecikmeli ve yüksek işlem hacimli iş yükleri için önerilir. Ancak, daha fazla bağlantı yönetimi ve güvenlik duvarı yapılandırması gerektirebilir.

Çoğu modern Java uygulaması için Direct mod daha iyi performans sağladığından tercih edilmelidir. SDK'yı yapılandırırken bu seçeneği doğru bir şekilde ayarladığınızdan emin olun.

Bu stratejileri uygulayarak, Azure Cosmos DB tarafında oluşabilecek gecikmeleri önemli ölçüde azaltabilir ve Java uygulamanızın genel performansını artırabilirsiniz. Sürekli izleme ve proaktif optimizasyon, bu sürecin kritik parçalarıdır.

Java Uygulamasında Thread Pool Yönetimi ve Asenkron Programlama Teknikleri

Java uygulamasındaki iş parçacığı havuzu (thread pool) tükenmesi sorunlarını gidermenin ve performansı artırmanın en etkili yollarından biri, G/Ç (I/O) işlemlerini bloke etmeyen (non-blocking) veya asenkron yaklaşımlar kullanmaktır. Java'nın modern sürümleri (Java 8 ve sonrası) ve reaktif programlama kütüphaneleri (örneğin Reactor, RxJava) bu konuda önemli avantajlar sunar. Azure Cosmos DB Java SDK'sı da reaktif API'ler sunarak bu yaklaşımı destekler.

1. Senkron (Blocking) vs. Asenkron (Non-Blocking) I/O:

Geleneksel olarak, Java'da bir veri tabanı çağrısı veya harici bir servis çağrısı yaptığınızda, çağrı tamamlanana kadar o iş parçacığı bloke olur. Bu, çağrı 100 ms sürse bile, o iş parçacığının başka bir iş yapmadan boşta beklemesi anlamına gelir. Eğer bu gecikme bölgeler arası mesafeden kaynaklı olarak artarsa, iş parçacığının bekleme süresi de uzar. Birçok iş parçacığı aynı anda bloke olduğunda, thread pool hızla tükenir.

Asenkron programlama ise bu sorunu çözer. Bir asenkron çağrı yaptığınızda, isteği gönderir ve iş parçacığını serbest bırakırsınız. Çağrı tamamlandığında, sonuç bir geri çağırma (callback) veya reaktif bir akış (reactive stream) aracılığıyla işlenir. Bu sayede, aynı sayıda iş parçacığıyla çok daha fazla eş zamanlı isteği işleyebilir ve thread pool tükenmesini engelleyebilirsiniz.

2. Azure Cosmos DB Java SDK'sının Reaktif API'leri:

Cosmos DB Java SDK v4 ve sonrası, Project Reactor tabanlı reaktif API'leri kullanır. Bu API'ler, veri tabanı işlemlerini Mono (tek bir öğe) veya Flux (birçok öğe) yayıncıları olarak döndürür. Bu yayıncıları kullanarak, veri tabanı isteklerini asenkron ve non-blocking bir şekilde işleyebilirsiniz.

import com.azure.cosmos.CosmosAsyncClient;
import com.azure.cosmos.CosmosAsyncContainer;
import com.azure.cosmos.models.CosmosQueryRequestOptions;
import com.azure.cosmos.util.CosmosPagedFlux;
import reactor.core.publisher.Flux;

public class AsyncCosmosExample {

    // YourItemClass: Cosmos DB'den dönecek verinin modeli
    static class YourItemClass {
        private String id;
        private String category;
        // Diğer alanlar ve getter/setter'lar
        public String getId() { return id; }
        public void setId(String id) { this.id = id; }
        public String getCategory() { return category; }
        public void setCategory(String category) { this.category = category; }

        @Override
        public String toString() {
            return "Item ID: " + id + ", Category: " + category;
        }
    }

    public void readItemsAsync(CosmosAsyncClient client, String databaseName, String containerName) {
        CosmosAsyncContainer container = client.getDatabase(databaseName).getContainer(containerName);
        CosmosQueryRequestOptions queryOptions = new CosmosQueryRequestOptions();

        // Asenkron bir sorgu çalıştırma. Flux döner.
        // Bu çağrı hemen döner, bloklama yapmaz.
        CosmosPagedFlux results = container.queryItems(
                "SELECT * FROM c WHERE c.category = 'Electronics'", queryOptions, YourItemClass.class);

        System.out.println("Sorgu başlatıldı, ana iş parçacığı engellenmedi.");

        // Abonelik ile sonuçları asenkron olarak işleyin.
        // Her bir öğe geldiğinde veya hata olduğunda bu bloklar çalışır.
        results.byPage() // Sayfa sayfa işlemek için (opsiyonel)
               .flatMap(cosmosPagedResponse -> {
                   cosmosPagedResponse.getResults().forEach(item -> System.out.println("Item received: " + item));
                   return Flux.just(item); // Akışı devam ettirir
               })
               .subscribe(
                   item -> System.out.println("Processing item: " + item.getId()), // Her öğe için
                   error -> System.err.println("Error: " + error.getMessage()),   // Hata durumunda
                   () -> System.out.println("Query completed.")                 // Akış tamamlandığında
               );

        // Ana iş parçacığı burada başka işler yapmaya devam edebilir.
        System.out.println("Ana iş parçacığı başka işler yapmaya devam ediyor...");
    }
}
  

3. CompletableFuture Kullanımı:

Eğer reaktif programlama kütüphanelerine geçiş yapmak istemiyorsanız, Java 8 ile gelen CompletableFuture sınıfı da asenkron ve non-blocking işlemler için güçlü bir araçtır. Kendi bloklama yapan kodunuzu CompletableFuture.supplyAsync() ile bir ForkJoinPool veya özel bir ExecutorService üzerinde çalıştırarak ana iş parçacıklarınızı serbest bırakabilirsiniz.

4. İş Parçacığı Havuzu Boyutlandırması:

Asenkron yaklaşımları kullanmak, iş parçacığı sayısını optimize etmenize yardımcı olsa da, yine de doğru bir havuz boyutu belirlemek önemlidir. Çok küçük bir havuz, isteklerin kuyrukta beklemesine neden olur; çok büyük bir havuz ise aşırı kaynak tüketimine (bellek, CPU bağlam değişimi) yol açabilir. Genellikle CPU yoğun iş yükleri için Runtime.getRuntime().availableProcessors() ile orantılı bir havuz boyutu (örneğin, 1x veya 2x) önerilirken, G/Ç yoğun iş yükleri için daha büyük havuz boyutları gerekebilir. Ancak asenkron I/O kullanıyorsanız, daha küçük bir havuz bile yüksek performans sağlayabilir.

5. Bağlantı Havuzu (Connection Pooling) Optimizasyonu:

Cosmos DB SDK'sı kendi dahili bağlantı yönetimini yapsa da, uygulamanızın diğer harici servislere veya veri tabanlarına olan bağlantılarını yöneten HTTP istemcileri (örneğin, Apache HttpClient, OkHttp) veya diğer JDBC sürücüleri için bağlantı havuzlarını doğru yapılandırmak önemlidir. Her istek için yeni bir bağlantı açmak yerine, bağlantı havuzundan mevcut bir bağlantıyı yeniden kullanmak, gecikmeleri ve kaynak tüketimini önemli ölçüde azaltır.

Asenkron programlama ve doğru iş parçacığı havuzu yönetimi, Java uygulamanızın yüksek eşzamanlılık ve düşük gecikme ile çalışmasını sağlamanın anahtarıdır. Özellikle bölgeler arası gecikmelerin kaçınılmaz olduğu durumlarda, iş parçacıklarını bloke etmeyen yaklaşımlar, uygulamanızın yanıt verme yeteneğini kritik derecede artırır.

Gelişmiş Teşhis ve Optimizasyon Teknikleri: Uygulama İçi Metrikler ve İzleme

Performansı sürekli olarak izlemek ve optimize etmek için gelişmiş teşhis teknikleri ve uygulama içi metrikler hayati önem taşır. Statik konfigürasyonlarla yetinmek yerine, uygulamanızın gerçek zamanlı davranışını anlamak, darboğazları proaktif olarak tespit etmenize ve çözmenize olanak tanır. Bu bölümde, daha derinlemesine izleme ve teşhis yaklaşımlarını inceleyeceğiz.

1. Uygulama Performans İzleme (APM) Araçları:

Azure Application Insights, New Relic, Dynatrace veya Prometheus/Grafana gibi APM araçları, uygulamanızın davranışını derinlemesine analiz etmenizi sağlayan kapsamlı metrikler ve görselleştirmeler sunar. Bu araçlar, aşağıdaki gibi kritik verileri toplar ve analiz eder:

• İstek Gecikmeleri ve Hata Oranları: Hangi HTTP uç noktalarının yavaş çalıştığını veya hata verdiğini gösterir.
• Bağımlılık Çağrıları: Cosmos DB, diğer mikro hizmetler veya harici API'lere yapılan çağrıların gecikmelerini ve hata oranlarını izler. Bu, özellikle Cosmos DB çağrılarının toplam gecikmeye ne kadar katkıda bulunduğunu anlamak için kritik öneme sahiptir.
• Sistem Metrikleri: CPU kullanımı, bellek tüketimi, iş parçacığı sayısı (aktif, beklemede, bloke), çöp toplama (garbage collection) süreleri gibi JVM metriklerini takip eder. Thread pool tükenmesi durumunda aktif veya bloke iş parçacığı sayılarındaki artışları hızlıca görebilirsiniz.
• Uçtan Uca İzleme (End-to-End Tracing): Tek bir isteğin uygulamanızın farklı bileşenleri ve bağımlılıkları arasında nasıl ilerlediğini gösterir. Bu, bölgeler arası çağrıların neden olduğu bir gecikmeyi veya belirli bir veri tabanı sorgusunun tüm işlemi ne kadar yavaşlattığını net bir şekilde ortaya koyar.

2. Cosmos DB SDK Teşhis Dizesi (Diagnostic String):

Azure Cosmos DB Java SDK'sı, her bir yanıtla birlikte ayrıntılı bir teşhis dizesi sağlar. Bu dize, isteğin istemci tarafında ne kadar sürdüğünü, ağ gecikmesini, işlem gören RU miktarını, kullanılan ağ geçidi bilgilerini ve daha fazlasını içeren zengin bilgiler barındırır. Bu teşhis dizesini loglarınıza dahil etmek, her bir Cosmos DB çağrısının performansını derinlemesine analiz etmenizi sağlar.

import com.azure.cosmos.CosmosClient;
import com.azure.cosmos.CosmosContainer;
import com.azure.cosmos.models.CosmosItemRequestOptions;
import com.azure.cosmos.models.CosmosItemResponse;

public class CosmosDiagnosticExample {

    public void readItemWithDiagnostics(CosmosClient client, String databaseName, String containerName, String itemId, String partitionKey) {
        CosmosContainer container = client.getDatabase(databaseName).getContainer(containerName);

        try {
            CosmosItemResponse response = container.readItem(itemId, new com.azure.cosmos.models.PartitionKey(partitionKey), YourItemClass.class);

            System.out.println("Item okundu. RU Tüketimi: " + response.getRequestCharge());
            System.out.println("Gecikme süresi (MS): " + response.getDuration().toMillis());
            System.out.println("Teşhis Dizesi: " + response.getDiagnostics().toString());
            // Teşhis dizesini loglamanız, performans sorunlarını izlemede kritik öneme sahiptir.

        } catch (Exception e) {
            System.err.println("Öğe okuma hatası: " + e.getMessage());
        }
    }
}

3. JVM İş Parçacığı Dökümleri (Thread Dumps) ve Bellek Dökümleri (Heap Dumps):

Uygulamanız donduğunda veya performans düşüşü yaşadığında, jstack komutuyla alınan iş parçacığı dökümleri, o an hangi iş parçacıklarının ne yaptığını gösterir. Bloke olmuş veya uzun süre beklemede olan iş parçacıkları, thread pool tükenmesinin ve performans darboğazlarının doğrudan kanıtıdır. jmap veya jcmd ile alınan bellek dökümleri ise, bellek sızıntılarını veya aşırı bellek tüketimini tespit etmenize yardımcı olabilir, ki bu da dolaylı olarak performansı etkileyebilir.

4. Özel Metrikler ve Log Korelasyonu:

Uygulamanızın kritik iş akışları için özel metrikler oluşturun (örneğin, bir kullanıcının sepetine ürün ekleme süresi). Bu metrikleri APM araçlarınıza göndererek iş açısından kritik performans göstergelerini izleyin. Ayrıca, istek kimliklerini (request IDs) kullanarak tüm log mesajlarını ve metrikleri ilişkilendirin. Bu, belirli bir kullanıcı isteğinin uygulamanızdaki ve Cosmos DB'deki tüm yolculuğunu takip etmenizi sağlayarak, performans düşüşünün tam olarak nerede başladığını belirlemenize yardımcı olur.

5. Verimli Sorgular ve İndeksleme Kontrolü:

Cosmos DB tarafında, maliyetli (yüksek RU tüketen) sorguları düzenli olarak gözden geçirin. Azure Portal'daki "Metrics" (Metrikler) bölümünden ve Application Insights'taki bağımlılık çağrılarından en pahalı sorguları tespit edebilirsiniz. Bu sorguları optimize etmek (örneğin, daha az özellik seçmek, ORDER BY veya GROUP BY kullanmaktan kaçınmak, doğru dizinleri kullanmak), hem RU maliyetini hem de gecikmeyi düşürecektir. İndeksleme politikanızın, sorgu desenlerinizle uyumlu olduğundan emin olun.

Bu ileri düzey teşhis ve optimizasyon tekniklerini kullanarak, Java uygulamanızın Azure Cosmos DB ile etkileşimini sürekli olarak iyileştirebilir, proaktif bir şekilde sorunları tespit edebilir ve kullanıcılarınıza kesintisiz bir deneyim sunabilirsiniz.

Bir Vaka Analizi: E-ticaret Uygulamasında Gecikme ve Thread Pool Krizi

Şimdi, öğrendiğimiz teorik bilgileri gerçek dünya bir senaryo üzerinden pekiştirelim. Orta ölçekli bir e-ticaret firması, ürün kataloglarını Azure Cosmos DB'de tutan ve Java tabanlı Spring Boot mikro hizmetleri kullanan bir platforma sahipti. Uygulama sunucuları Batı Avrupa'da, Cosmos DB ise başlangıçta tek bir Doğu ABD bölgesinde konumlandırılmıştı. İlk başta her şey yolundayken, büyük bir indirim kampanyası (Black Friday) sırasında uygulama performansı aniden düşmeye başladı: müşteriler ürün sayfalarına erişmekte zorlanıyor, sepet işlemleri yavaşlıyor ve bazı kullanıcılar zaman aşımı hatalarıyla karşılaşıyordu. Geliştirme ekibi alarma geçti.

Sorunun Belirtileri:

• Kullanıcı Şikayetleri: "Sayfalar yüklenmiyor", "Sepetime ürün ekleyemiyorum", "Ödeme yapamıyorum".
• Uygulama Yanıt Süreleri: Azure Application Insights metrikleri, HTTP istek yanıt sürelerinin 1 saniyeden 5-10 saniyeye fırladığını gösteriyordu.
• Hata Oranları: Özellikle Cosmos DB ile etkileşim kuran servislerde Connection Timeout ve 503 Service Unavailable hatalarında artış.
• Thread Metrikleri: JVM monitör araçları ve Application Insights, iş parçacığı havuzlarındaki (hem uygulama sunucusu hem de Cosmos DB SDK'sı içindeki) aktif iş parçacığı sayısının maksimuma ulaştığını ve kuyruklarda yüzlerce isteğin beklediğini gösteriyordu. CPU kullanımı nispeten normaldi, bu da CPU darboğazı olmadığını işaret ediyordu.

Teşhis Süreci:

1. Bölgesel Kontrol: Ekip ilk olarak uygulamanın Batı Avrupa'da, Cosmos DB'nin ise Doğu ABD'de olduğunu fark etti. Bu, doğrudan bir bölgeler arası gecikme kaynağıydı. Her bir Cosmos DB çağrısı için ~80-150ms RTT eklentisi vardı.
2. Log Analizi: Loglarda, CosmosDbClient çağrılarının normalden çok daha uzun sürdüğü ve sık sık zaman aşımı hataları fırlattığı görüldü. Özellikle ürün detayları sayfalarında, birden fazla öğe için yapılan paralel Cosmos DB okumalarının toplam süreyi katladığı tespit edildi.
3. Thread Dump Analizi: jstack ile alınan iş parçacığı dökümleri, yüzlerce iş parçacığının CosmosDbClient tarafından başlatılan G/Ç işlemlerini beklerken "WAITING" veya "BLOCKED" durumda olduğunu gösterdi. Bu, senkron (blocking) Cosmos DB çağrılarının thread pool tükenmesine yol açtığını doğruladı.
4. Cosmos DB Metrikleri: Cosmos DB metrikleri, sunucu tarafı gecikmelerin aslında düşük olduğunu ancak client tarafı gecikmelerin çok yüksek olduğunu gösterdi. Bu durum, sorunun veri tabanının kendisinden değil, istemci ile veri tabanı arasındaki ağ gecikmesinden kaynaklandığını teyit etti. RU/s tüketimi de anlık olarak tavan yapıyor, bu da bazı kısıtlamalara yol açıyordu.

Uygulanan Çözümler:

1. Cosmos DB Çok Bölgeli Yazma ve Bölgesel Yakınlaştırma:
   • Cosmos DB hesabı, Batı Avrupa bölgesine bir okuma/yazma bölgesi olarak eklendi.
   • Uygulama, Cosmos DB Java SDK'sının otomatik bölge yönlendirme (automatic region failover/preferring closest region) özelliğinden faydalanacak şekilde yeniden yapılandırıldı. Bu sayede, uygulama artık Batı Avrupa'daki yakın Cosmos DB kopyasına bağlanarak bölgeler arası RTT'yi minimize etti.
2. Asenkron SDK Kullanımı:
   • Tüm Cosmos DB çağrıları, senkron API'lerden Project Reactor tabanlı asenkron API'lere (CosmosAsyncClient) taşındı. Bu, veri tabanı çağrıları beklerken iş parçacıklarının bloke olmamasını sağladı.
   • Özellikle ürün detayları sayfasındaki paralel okumalar Flux.merge() veya Flux.zip() gibi reaktif operatörlerle birleştirilerek tek bir akışta verimli bir şekilde işlendi.
3. RU/s Optimizasyonu:
   • Yoğun dönemlerdeki kısıtlamaları önlemek için Cosmos DB koleksiyonları için Autoscale (Otomatik Ölçeklendirme) etkinleştirildi.
   • En maliyetli sorgular (Application Insights'tan tespit edildi) optimize edildi. Örneğin, gereksiz SELECT * yerine sadece ihtiyaç duyulan alanlar çekildi ve WHERE cümlelerinde daha verimli indeksler kullanıldı.
4. İş Parçacığı Havuzu Boyutlandırması:
   • Asenkron geçişle birlikte, uygulama sunucusunun iş parçacığı havuzu boyutları daha makul seviyelere çekildi, çünkü artık iş parçacıkları G/Ç için bloke olmuyordu.

Sonuç:

Yapılan bu değişiklikler sayesinde, indirim kampanyasının ilerleyen dönemlerinde uygulama performansı önemli ölçüde iyileşti. Yanıt süreleri eski seviyelere düştü, hata oranları azaldı ve müşteriler kesintisiz bir alışveriş deneyimi yaşadı. Bu vaka analizi, hem bölgeler arası gecikmenin hem de thread pool tükenmesinin birbiriyle ilişkili sorunlar olduğunu ve bütüncül bir yaklaşımla çözülmesi gerektiğini açıkça göstermektedir.

Sonuç: Performans Sorunlarına Karşı Proaktif Olmak

Java uygulamalarınızda Azure Cosmos DB ile çalışırken bölgeler arası gecikme ve iş parçacığı havuzu tükenmesi gibi performans sorunları kaçınılmaz olabilir. Ancak, bu makalede ele aldığımız doğru teşhis araçları, kapsamlı izleme stratejileri ve modern programlama yaklaşımları sayesinde bu sorunların üstesinden gelmek ve uygulamanızın performansını optimize etmek mümkündür. Unutmayın, performans optimizasyonu tek seferlik bir iş değildir; sürekli bir süreçtir. Uygulamanızın mimarisini, veri modellemesini ve kodunu düzenli olarak gözden geçirerek ve izleyerek, kullanıcılarınıza kesintisiz ve hızlı bir deneyim sunabilirsiniz.

Başarılı bir bulut tabanlı uygulama stratejisinin temelinde, gelecekteki potansiyel sorunları öngörmek ve bunlara karşı proaktif çözümler geliştirmek yatar. Gecikme ve kaynak tükenmesi gibi sorunları hızlı bir şekilde tespit edip çözmek, hem müşteri memnuniyetini artırır hem de operasyonel maliyetleri düşürür. Uygulamanızın her zaman en iyi performansta çalıştığından emin olmak için izleme araçlarınızı aktif tutun, loglarınızı düzenli olarak inceleyin ve performans testlerini (yük ve stres testleri) rutin geliştirme döngünüzün bir parçası haline getirin. Bu sayede, beklenmedik yük artışları karşısında bile uygulamanızın sağlam kalmasını sağlayabilirsiniz.

Sıkça Sorulan Sorular

• S: Bölgeler arası gecikmeyi tamamen ortadan kaldırmak mümkün müdür?

  C: Fiziksel mesafeden kaynaklanan ağ gecikmesini tamamen ortadan kaldırmak mümkün değildir. Ancak, uygulamanız ve veri tabanınızın aynı veya birbirine yakın coğrafi bölgelerde konumlandırılması, Azure Cosmos DB'nin çok bölgeli yazma özellikleri, istemci tarafı önbellekleme ve ağ trafiğini optimize eden diğer yöntemlerle bu gecikme en aza indirilebilir. Amaç, gecikmeyi kabul edilebilir seviyelere çekmektir.

• S: Thread pool tükenmesi her zaman kötü bir şey midir?

  C: Thread pool tükenmesi, genellikle uygulamanızın gelen yükü etkili bir şekilde işleyemediğinin bir işaretidir ve bu da performansı ve kullanılabilirliği ciddi şekilde düşürebilir. Bu durum genellikle bir performans darboğazına işaret eder. Ancak, bazı durumlarda, aşırı kaynak tüketimini önlemek için bilinçli olarak küçük bir havuz boyutu belirlemek mümkündür, ancak bu dikkatli bir planlama ve kapsamlı test gerektirir. Çoğu senaryoda, thread pool tükenmesi istenmeyen bir durumdur.

• S: Cosmos DB Java SDK'sının hangi modunu kullanmalıyım: Gateway mi, Direct mi?

  C: Genellikle Direct mod, daha az ağ atlaması içerdiği ve daha düşük gecikme ve daha iyi performans sunduğu için tercih edilir. Özellikle düşük gecikmeli ve yüksek işlem hacimli iş yükleri için önerilir. Gateway modu ise daha basit ağ yapılandırmaları ve güvenlik duvarı kuralları gerektirebilir. Çoğu modern uygulama için Direct modu önerilir, ancak ortamınızın gereksinimlerine ve ağ yapılandırmasına göre test etmeniz ve uygun modu seçmeniz önemlidir.

• S: Uygulamamın performansını izlemek için hangi araçları kullanmalıyım?

  C: Azure Monitor ve Azure Application Insights, Azure ekosisteminde entegre ve güçlü izleme araçlarıdır. Ayrıca, Java uygulamaları için JMX, Prometheus/Grafana, New Relic, Dynatrace gibi üçüncü taraf Uygulama Performans İzleme (APM) araçları da derinlemesine metrikler, izleme ve teşhis yetenekleri sunar. Seçiminiz, bütçenize, entegrasyon gereksinimlerinize ve ekibinizin deneyimine bağlı olacaktır.

• S: Asenkron programlamaya geçiş yapmak her zaman en iyi çözüm müdür?

  C: Asenkron programlama, özellikle G/Ç yoğun ve yüksek eşzamanlılık gerektiren uygulamalar için harika bir çözümdür, çünkü iş parçacığı tükenmesini büyük ölçüde azaltır. Ancak, kod karmaşıklığını artırabilir ve doğru uygulanmazsa hata ayıklamayı zorlaştırabilir. Projenizin büyüklüğü, ekibinizin deneyimi ve mevcut mimarinin yapısı gibi faktörleri göz önünde bulundurarak dikkatli bir değerlendirme yapmak önemlidir. Küçük ve basit uygulamalarda senkron yaklaşım hala yeterli olabilirken, dağıtık ve yüksek performanslı sistemlerde asenkron yaklaşımlar genellikle kaçınılmazdır.