Tuhaf ama, Geçen ay bir müşteride ilginç bir şey yaşadık. İstanbul’daki bir e-ticaret firması, kara cuma öncesi yük testlerinde garip bir tablo gördü: CPU kullanımı %35 civarında, RAM rahat, disk IOPS da normal sınırda… ama uygulama tepki süresi bazen 2 saniyeye çıkıyordu (buna dikkat edin). Klasik refleks ne oldu tahmin edin: “VM’i büyütelim.” Büyüttük. Hiçbir şey değişmedi.
Bi saniye — İşin aslı şu ki, bulutta performans artık tek bir parçayı şişirmekle çözülen bir mesele değil. Kaynak ekleyerek darboğazı aşma dönemi, en azından modern iş yüklerinde, çoktan kapandı. Bunu lafı gevelemeden söyleyeyim.
Azure IaaS tarafında son birkaç yılda olan değişimin özü tam burada: performans, izole bileşenlerin toplamı değil — koordineli bir sistemin çıktısı. Compute, storage ve network’ün birlikte nasıl davrandığı, tek başına ne kadar güçlü olduklarından daha önemli hâle geldi. Bu yazıda bu sistem düzeyli yaklaşımı, sahadan gördüklerimle anlatmaya çalışacağım.
Performans Artık Tek Boyutlu Bir Karar Değil
İlginç olan şu ki, Eskiden danışmanlık verirken müşteriye sorardık: “Kaç vCPU? Kaç GB RAM? Hangi disk tier?” Üç soru, üç cevap, iş biterdi. Şimdi öyle değil. Şimdi performans dediğimiz şey, birkaç farklı boyutun aynı anda nasıl davrandığına bakmak demek (bizzat test ettim)
Bunu biraz açayım.
Bunları biraz açayım. AZ-305 sertifikasına çalışırken de defalarca karşıma çıkmıştı, sahada da öyle oldu:
- Gecikme (latency): Ortalama latency değil, P99 ve P99.9 önemli. Çünkü kullanıcı deneyimini ortalama değil, kuyruğun ucundaki en kötü senaryolar belirliyor. (bence en önemlisi)
- Throughput: Belli bir zaman diliminde ne kadar iş bitirebiliyorsun? — ciddi fark yaratıyor
- Ölçeklenebilirlik: Yük arttıkça performans aynı kalabiliyor mu, yoksa düşüyor mu?
- Tutarlılık: Aynı operasyon iki kez aynı sürede tamamlanabiliyor mu? Yoksa rastgele dalgalanma var mı?
- Time-to-performance: Yeni kaynağı ne kadar hızlı ayağa kaldırabiliyorsun? Bu da bir performans metriği — çoğu kişi unutuyor.
Bakın şimdi, bu beşincisi özellikle Türkiye’deki şirketler için kritik. Çünkü bizim tarafta tahmin edilemeyen kampanya patlamaları, anlık ürün lansmanları, hatta sosyal medya kaynaklı anı trafikler çok yaygın. Yani uygulamanın hızlı çalışması kadar, altyapının hızlı tepki vermesi de önemli.
“Bir veritabanı bir an storage latency tarafından kısıtlanırken, hemen ardından network bandwidth tarafından sıkışabilir. Darboğaz sabit değil, dinamik bir şey.”
AI İş Yükleri: Sistem Düzeyli Performansın Ders Kitabı
AI tarafına gelelim. Çünkü sistem düzeyli performansın neden önemli olduğunu en net AI workload’larında görüyoruz. Bir LLM eğitim pipeline’ı düşünün — düzinelerce GPU, terabaytlarca veri, sürekli node’lar arası senkronizasyon.
Geçen yıl bir araştırma şirketinde bir POC yaptık. NDv5 serisi VM’ler kullanıyorduk, H100 GPU’larla. İlk denemede GPU utilization %40-50 bandında takılıyordu. Pahalı donanımın yarısı boşta duruyordu yani. Sebep? GPU compute değilmiş; node’lar arası veri akışıymış. InfiniBand topolojisi, RDMA ayarları ve storage tarafındaki paralel okuma kapasitesi düzgün ayarlanınca utilization %85’lere çıktı. Aynı donanım. Sadece sistem düzeyinde uyum.
Eh, İşte AI workload’larda Azure’un öne çıktığı nokta bu. LLM Cold Start Çilesi: Run:AI Streamer ile 6x Hız yazımda da değinmiştim; model yükleme süresi bile sistemin nasıl tasarlandığına göre 6 kata kadar değişebiliyor. Yani sadece GPU değil, GPU’ya veriyi nasıl beslediğin de aynı derecede kritik.
Türkiye’de AI Workload İçin Pratik Tavsiye
Açık konuşayım: Türkiye’deki çoğu kurumun AI projelerinde gördüğüm en büyük hata, “ne kadar büyük GPU alırsak o kadar iyi ölür” mantığı. Halbuki bütçenin %60’ını GPU’ya, %10’unu storage’a ayırmak klasik tuzak oluyor. Bence şu dağılım daha gerçekçi:
- GPU/Compute: %45-50
- High-throughput storage (Azure Managed Lustre veya NetApp Files): %20-25
- Network (InfiniBand olan SKU’lar): SKU içinde geliyor, ama doğru SKU seçmek lazım
- Observability ve monitoring: %5-10 (bunu kimse hesaba katmıyor, sonra yaniyor)
Ha bu arada, Azure NetApp Files EDA İçin: Bulutta Çip Tasarımı Devri yazısında da değinmiştim; yüksek throughput gerektiren senaryolarda storage seçimi GPU seçimi kadar önemli olabiliyor.
Cloud-Native Uygulamalarda Performans Tutarlılığı
Garip gelecek ama, Kubernetes ortamlarına geçelim. Burada da işler farklı değil aslında. AKS kullanan müşterilerimde gördüğüm en yaygın sorun şu: “Pod’lar çalışıyor ama bazen tepki vermiyor.”
Genelde sebep node SKU’su ya da network tarafında oluyor — bence çok yerinde bir karar —. Bir pod CPU throttle ediliyor olabilir (PSI metriklerine bakmadan anlamak zor), başka bir pod aynı node’da disk I/O’yu tüketiyor olabilir ya da CNI plugin’i seçimi yanlış yapılmış olabilir. Kubernetes v1.36’da PSI Metrikleri GA: Sahadan Notlar yazımda PSI’nın ne kadar değerli olduğunu detaylıca anlatmıştım — özetle, pod düzeyinde “basınç” görmeden performans tuningi yapmak karanlıkta ok atmak gibi. Daha fazla bilgi için MSVC’de SPGO Devri: Production’dan PGO Kalitesi yazımıza bakabilirsiniz.
Kendi deneyimimden konuşuyorum, Azure tarafında AKS için son zamanlarda dikkatimi çeken birkaç şey var:
| Senaryo | Önerilen Yaklaşım | Beklenen Kazanç |
|---|---|---|
| Yüksek pod yoğunluğu | Ephemeral OS disk + Premium SSD v2 | %30-40 disk latency düşüşü |
| Stateful workload | Azure Container Storage + NVMe local | Sub-ms latency |
| Yoğun east-west trafik | Accelerated Networking + Azure CNI Overlay | Network throughput 2-3x |
| Burst tipi yük | KEDA + Spot Node Pool | %40-60 maliyet düşüşü |
Bu tablonun her satırı sahada gördüğüm şeylerden geliyor. Mesela “Premium SSD v2″yi göz ardı etmeyin — Premium SSD v1’e göre IOPS ve throughput’u ayrı ayrı ayarlayabiliyorsunuz; bu da maliyet açısından baya iş görüyor. Bu konuyla ilgili Kubernetes v1.36 Server-Side Sharded Watch: Saha Notları yazımıza da göz atmanızı tavsiye ederim.
Iş-Kritik Sistemlerde Sürdürülebilir Performans
Dürüst olmak gerekirse, Şimdi gelelim klasik enterprise dünyasına. SAP HANA, Oracle, büyük SQL Server cluster’ları… Bu sistemlerde performans “anlık tepki” meselesi değil; “haftalarca, aylarca tutarlılık” meselesi.
Eh, Logosoft’ta bir bankacılık projesinde benzer bir senaryo yaşadık. Müşteri Oracle Exadata’dan Azure’a göç ediyordu. M-series VM’ler, Ultra Disk, Proximity Placement Group, Accelerated Networking — paketin tamamı vardı yani. İlk testlerde performans iyiydi. Üçüncü haftada bir anomali fark ettik: belli saatlerde batch işlerinin süresi %15 uzuyordu. Kubernetes v1.36: Silinemeyen Admission Politikaları Dönemi yazımızda bu konuya da değinmiştik.
Peki neden? Aynı PPG içindeki başka bir VM (test ortamı), production’dakiyle kaynak rekabetine giriyordu. Çözüm olarak ayrı bir PPG ve dedicated host’a geçtik. Ders şu: Iş-can alıcı sistemlerde “deploy ettim, çalışıyor” yetmiyor.Evet böyle söylüyorum çünkü sürekli izleme. Sürekli ince ayar gerekiyor. Daha fazla bilgi için etcd 3.7.0-beta.0 Yayında: RangeStream ve v2store Vedası yazımıza bakabilirsiniz.
Büyük Kurum mu Startup mı?
Bazen olay bayağı ölçeğe göre değişiyor. Bir startup’sanız ve aylık Azure faturanız 5000$ altındaysa bu yazının çoğu size fazla detay gibi gelebilir ama yine de bazı yerleri iş görür:
Bunu biraz açayım.
- Burstable (B-series) VM’lerden uzak durun; test/dev için fena değil ama production’da hoş sürpriz yapmıyor.
- D-series v5 veya v6 ile başlayın; AMD muadillerini (Das_v5) de değerlendirin — TL bazında %15-20 daha ucuz olabiliyor.
- `Premium SSD`ye geçin; `Standard SSD` ile oyalanmayın. Fark baya hissediliyor ama fiyat farkı sandığınız kadar büyük olmayabiliyor.
Kurumsal yapıdaysanız hikâye değişiyor tabii. Sizde “deployment hızı” kadar “değişiklik yönetimi” de önemli oluyor. O yüzden:
- `Azure Landing Zone` disiplininden ödün vermeyin.
- `Performans baselining` yapın — her workload için ne normal ne anormal yazılı olarak belirleyin.
- `Capacity reservation` kullanın — özellikle yıl sonu gibi yoğun dönemlerde “kapasite yok” hatası almak istemezsiniz. Geçen sene tam böyle bir kapasite krizi yaşadık bir bölgede; anlatmayayım…
Peki Performansı Nasıl Okumalıyız?
Bir şey dikkatimi çekti: Kısacası geri dönelim baştaki İstanbul’daki e-ticaret firmasına.
Ne yaptık sonunda? VM büyütmek yerine şu kombinasyonu uyguladık:
- `Application Gateway`’in arkasına Premium SKU geçtik (autoscale dahil).
- `Database` tarafında Read Replica ekledik — okuma trafiğini dağıttık.
- `Redis Cache` devreye aldık (en sık sorgular için).
- `VM`ler aynı kaldı ama `Accelerated Networking` kapalıymış (!) — açıldı. (bu kritik)
Şimdi, dürüst olmak gerekirse, Sonuçta P99 tepki süresi 2 saniyeden 280 milisaniyeye düştü.
VM boyutu hiç değişmedi.
Işin aslı sistem düzeyli yaklaşım dediğim şey tam olarak buydu. Daha fazla bilgi için Kubernetes v1.36: Service ExternalIPs Tarihe Karışıyor yazımıza bakabilirsiniz.
Şimdi gelelim işin can alıcı noktasına.
Bu hikâyeden çıkarmamız gereken ders şu: Bir sorunla karşılaştığınızda ilk soru “Hangi kaynağı büyüteyim?” olmamalı; “Sistem nerede koordinasyon kaybediyor?” diye sormak lazım.
Çoğu zaman cevap hiç beklemediğiniz yerde çıkıyor.
Dene-Bak Modeli Yerine Daha Temiz Bir Yol Var mı?
Eğer “bir yerden başlamak istiyorum” diyorsanız şu adımları takıp edin:
1.Adım: Ölçün sonra konuşun.Azure Monitör + Application Insights + Log Analytics üçlüsünü kurun.
Hangi metriklerin “normal” olduğunu yazılı baseline olarak belirleyin.
Bu olmadan tuning yapmak resmen boşuna kürek çekmek oluyor.
Kısacası, bir şey dikkatimi çekti: 2.Adım: Darboğazı belirleyin.`CPU` mu `memory` mi `disk` mi `network` mü?
Çoğu zaman aklınızdan geçen ilk şey çıkmıyor.
Tail latency’lere odaklanın; ortalama değerler insanı kolay kandırıyor.
3.Adım: Tek katmanı değil sistemi düşünün.`Storage`’ı hızlandırdınız. `network` hâlâ darboğazsa kazanç sınırlı kalıyor.
Compute’u büyüttünüz ama uygulama tek thread’liyse yine çok fark etmiyor.
4.Adım: Maliyetle dengeleyin.`Premium SSD v2` her zaman gerekli olmuyor.
Ultra Disk pahalı bir oyuncak gibi duruyor; gerçekten lazımsa kullanın.Azure Files Entra-Only: AD’siz SMB Devri Başladı tarzı yeni özellikler de bazen mimariyi sadeleştirip performansa katkı verebiliyor — sadece teknik özelliklere değil mimarı sadeliğe de bakın.””>
Sürekli İyileştirme Olmadan Olmaz mı?
5.Adım:Sürekli iyileştirme döngüsü kurun.Cloud performance “kur. Unut” işi değil.
Her ay 1-2 saatlik review toplantısı yapın.
Workload’ünüz değişiyor, Azure SKU’ları değişiyor, fiyatlar değişiyor.
Sıkça Sorulan Sorular
Azure’da performansı artırmak için nereden başlamalıyım?
Tecrübeme göre en hızlı kazanç genelde iki yerden geliyor: Accelerated Networking’in açık olup olmadığını kontrol etmek (açıkçası şaşırırsınız, bayağı VM’de kapalı geliyor). Disk caching ayarlarını workload’a göre yeniden gözden geçirmek. İkisi de aslında 30 dakikalık işler, ama %20-40 gibi ciddi bir fark yaratabiliyorlar.
Evet, doğru duydunuz.
Premium SSD v2 mi, Ultra Disk mi?
Bence pratik kural şu: P99 latency’nın 1ms altında olması şart olan senaryolar için — mesela high-frequency trading ya da real-time analytics — Ultra Disk (şaşırtıcı ama gerçek). Geri kalan %90 senaryo için Premium SSD v2 hem daha esnek hem daha ekonomik. Hani IOPS ve throughput’u ayrı ayrı satın alabildiğiniz için gereksiz yere fazla ödeme yapmıyorsunuz, yani işinize geldiği kadar ödüyorsunuz.
Küçük bir startup için performans optimizasyonu çok erken değil mi?
Hayır, ama “over-engineering” tuzağına düşmeyin. Aslında startup için tek tavsiyem şu üç şey: doğru VM ailesi seçimi (Dasv5/Dadsv5 fiyat/performans açısından gerçekten çok iyi), Premium SSD kullanımı ve Application Insights ile temel monitoring. Bu kadarı yeter, yani fazlasına gerek yok. Reserved Instance’ı işe 6 ay tutarlı kullanım sonrası düşünün.
AI workload’larda en hayatı bileşen hangisi?
Çoğu insan hemen “GPU” der, ama benim deneyimim biraz farklı. Eğitim senaryolarında storage throughput ve InfiniBand network, çoğu zaman GPU’dan daha kritik bir darboğaz oluyor. Inference tarafında işe model yükleme süresi (yani cold start) ve memory bandwidth öne çıkıyor. Açıkçası “GPU’yu büyüt” refleksinden vazgeçin, çünkü asıl sorun genelde orada değil.
Test ortamı production ile birebir aynı mı olmalı?
İdeal olarak evet. Ama maliyet açısından her zaman mümkün olmuyor. Pragmatik yaklaşım şu: SKU ailesi aynı kalsın — hani Dsv5 kullanıyorsanız Dsv5 olsun — boyutu küçültebilirsiniz. Hani ne farkı var diyorsunuz, değil mi? Network topolojisi ve disk tipi işe mutlaka aynı olmalı, çünkü performans karakteristikleri en çok bu iki katmanda değişiyor.
Kaynaklar ve İleri Okuma
Konunun detayına inmek isteyenler için birkaç sağlam kaynak:
- Azure IaaS: Deploy high-performance workloads with a system-level approach (Microsoft Azure Blog)
- Azure VM Sizes — Resmî Dokümantasyon
- Azure Well-Architected Framework: Performance Efficiency Pillar
- Azure Managed Disks — Tıp Karşılaştırması
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
