Azure IaaS’ta Performans: VM’den Çok Daha Fazlası Var
Performans dediğimiz şey, artık tek bir ayar değil
Kendi deneyimimden konuşuyorum, Bulutta performans konuşurken çoğu ekip hâlâ aynı yere takılıyor: “Daha büyük VM alalım, sorun çözülür.” Açık konuşayım, bazen iş görüyor. Ama çoğu zaman da sadece faturayı şişiriyor. Azure IaaS tarafında mesele, CPU’yu biraz büyütmekten ibaret değil; compute, storage ve network’ün birlikte nasıl davrandığına bakmak gerekiyor. İşin aslı bu.
Ben bunu ilk kez 2018’de, İstanbul’da bir finans müşterisinde çok net gördüm. Uygulama sahibi diskleri hızlandırınca rahatlayacağını düşünüyordu. Sonra loglara baktık; darboğaz aslında ağ tarafındaydı. İlginç olan şu: yük arttıkça sorun yeri de değişiyordu. Bir gün storage, ertesi gün network… Yanı sabit bir problem yoktu, sistemin kendisi yer değiştiriyordu. Garip ama gerçek.
Doğrusu, Performans artık “en hızlı parça kim?” sorusu değil bence. Daha çok “bu parçalar birbirini boğuyor mu?” sorusu. Azure’un sistem düzeyi yaklaşımı da tam burada anlam kazanıyor. Tek tek iyi duran bileşenler yerine, birlikte fena çalışmayan bir yapı kurmaya uğraşıyorsunuz.
Ha bu arada, bu yaklaşım küçük ekipler için de önemli ama kurumsalda etkisi daha büyük oluyor. Startup tarafında birkaç deneme yapıp yolu bulabiliyorsunuz; enterprise tarafta işe yanlış mimarı kararın geri dönüşü hem pahalı hem de sancılı oluyor. Mantıklı değil mi? Baya sancılı.
Neden eski alışkanlıklar yetmiyor?
Hani, Eskiden performans problemi varsa çözüm basitti: daha fazla kaynak ver, geç. Şimdi öyle değil. Modern iş yükleri dalgalı çalışıyor; bazen veri akışı tıkanıyor, bazen depolama gecikmesi yükseliyor, bazen de uygulama katmanı gayet iyi görünürken altta kuyruklar birikiyor. Kafa karıştırıcı biraz.
2021’de Ankara’da bir üretim müşterisinde benzer bir tablo yaşadık (buna dikkat edin). Kubernetes üzerinde koşan servisler gayet düzgündü ama batch işlemleri gecikiyordu (ilk duyduğumda inanamadım). İlk bakışta hesap gücü eksik gibi duruyordu; sonra anladık ki düğümler arası veri transferi yeterince akıcı değildi. Hani insan önce “CPU yetmiyor” diyor ya… meğer mesele orası değilmiş.
Bence burada en can alıcı nokta time-to-performance. Yanı altyapıyı ne kadar hızlı ayağa kaldırabildiğiniz, ölçekleyebildiğiniz veya toparlayabildiğiniz de performansın parçası. Kağıt üstünde çok hızlı görünen bir sistem, beş saat provisioning bekletiyorsa pratikte pek havalı olmuyor (en azından benim deneyimim böyle)
AI iş yüklerinde dar boğaz nerede çıkıyor?
Yanı, AI tarafı biraz acımasızdır (evet, doğru duydunuz). Model eğitimi yaparken herkes GPU konuşur ama veri akışı yavaşsa o GPU’lar oturup çay içiyor gibi kalır. Ben buna birkaç kez denk geldim; özellikle dağıtık eğitim senaryolarında compute güçlüydü ama node’lar arasında veri gidip gelmesi süründüğü için toplam süre uzuyordu.
Dürüst olmak gerekirse, Geçen yıl Dubai’de bir müşteriyle yaptığımız PoC’de tam da bu öldü. Başta herkes daha büyük VM istedi. Sonra ölçtük; bottleneck diskten ziyade ağda ve veri yerleşimindeydi. Azure tarafında doğru yerleştirme ve uygun ağ tasarımıyla işi toparladık ama ilk denemede aldığım hata mesajını unutamıyorum: pipeline ilerliyor sanıyorsunuz, sonra düğüm senkronizasyonu patlıyor… can sıkıcıydı.
Çok konuştum, örnekle göstereyim.
E tabi burada Azure’un güzelliği şu: sistemi sadece “tek makine” gibi görmüyor. Compute’u storage ile aynı cümlede ele almak zorundasınız. Aksi hâlde yüksek çekirdekli bir VM alıp performans beklemek biraz kuvvetli araba alıp dar sokakta gazlamak gibi oluyor.
| Konu | Sadece kaynak artırma | Sistem düzeyi yaklaşım |
|---|---|---|
| CPU | Daha büyük VM seçilir | İş yüküne göre dengelenir |
| Ağ | Genelde sonradan fark edilir | Tasarımın başına konur |
| Storage | Daha hızlı disk alınır | I/O paterni analiz edilir |
| Tutarlılık | Zaman zaman ihmal edilir | P99/P99.9 ile izlenir |
Kubernetes ve cloud-native tarafta olay neden farklı?
Dikey büyütmek her zaman çözüm değil
Şunu fark ettim: Kubernetes dünyasında performans konusu daha da karmaşıklaşıyor çünkü artık tek makinede değil, dağıtılmış bir yapıda yaşıyorsunuz. Benim gözümde burada en büyük hata, pod sayısını artırmayı otomatik çözüm sanmak. Pod artar ama node iletişimi zayıfsa yine duvara toslarsınız.
Ağ sınırı küçük görünür ama etkisi büyüktür
Bunu Logosoft tarafında yürüttüğümüz bir projede açık açık gördük; servisler arasında küçük paketlerin çok sık gidip geldiği senaryolarda network ayarı neredeyse CPU kadar can alıcı hâle geliyor. Az-çok çalışan yapı ile gerçekten ölçeklenen yapı arasında fark var yanı.
Durun, bir saniye.
Aslında — hayır dur, daha doğrusu, Küçük startup iseniz şunu öneririm: önce basit ölçün, sonra büyütün. Büyük kurumsal yapıda işe doğrudan gözlemleme katmanı kurmadan ilerlemeyin; (şaşırtıcı ama gerçek). Sorun çıktığında kök nedeni bulmak beş dakikalık iş olmuyor…
Performans konusu yalnızca “daha fazla kaynak” meselesi değil; doğru kaynakların doğru sırada konuşması meselesi.
Sürdürülebilir performans için benim baktığım yerler
Önce ölçüm, sonra iyileştirme
Bence çoğu ekip optimizasyonu ters sırayla yapıyor: önce tahmin ediyorlar, sonra ayar çekiyorlar, en son ölçmeye başlıyorlar (geç kalmış olabiliyor). Ben AZ-305’e hazırlanırken de aynı dersi tekrar tekrar gördüm; mimarı kararların hepsi ölçümle desteklenmediğinde sadece güzel sunum slaytı olarak kalıyor.
P99’u küçümsemeyin
Pek çok yönetici ortalama gecikmeye bakıp rahatlıyor ama kullanıcı deneyimini bozan şey çoğu zaman kuyrukta bekleyen o son yüzde biri oluyor (bizzat test ettim). Bilhassa finansal sistemlerde veya sipariş platformlarında tail latency ciddi fark yaratıyor.
Maliyet ile performansı ayrı kutulara koymayın
Tuhaf ama, TL bazında düşündüğünüzde bazı hızlandırmalar gerçekten mantıklı olabilirken bazıları fena hâlde pahalıya gelebiliyor. Mesela küçük ekipseniz premium disk + özel ağ tasarımı yerine önce iyi izleme ve uygun instance ailesiyle başlamak daha akıllıca olabilir. Kurumsal tarafta işe SLA baskısı yüzünden bu yatırım kendini zaten geri ödüyor.
- Küçük ekip: Önce darboğazı bulun, sonra kaynak ekleyin. — ciddi fark yaratıyor
- Büyük kurum: Standart mimarı desenleri oluşturun ve tekrar kullanılabilir hâle getirin. (bu kritik)
- AI projesi: Veri hattını compute kadar ciddiye alın.
- Kritik uygulama: İzleme olmadan tuning yapmayın.
Sahada gördüğüm üç pratik ders
Birincisi şu: performans problemleri nadiren tek noktadan çıkar gelir.
İkincisi: hızlanma isteği ile gerçek ihtiyaç birbirine karışabiliyor.
Üçüncüsü işe şu — insanlar genelde sorun çözüldü sanıp kısa süre sonra aynı yere geri dönüyorlar çünkü kök neden kapatılmamış oluyor.
Size bir şey söyleyeyim, Nisan ayında Gebze’deki bir üretim ortamında yaşadığımız olay buna güzel örnekti. Storage latency düşürülmüş görünüyordu ama uygulama hâlâ takılıyordu. Sonra loglarda ufak bir queue dolması yakaladık; yanı sorun aslında zincirin başka halkasındaydı. Bakın şimdi… böyle durumlarda biraz sabır şart!
Eğer bugün başlayacak olsam ilk üç adımı şöyle atarım:
# Basit kontrol listesi
1) P95 / P99 gecikmeleri izle
2) Storage IOPS ile network throughput'u birlikte değerlendir
3) Aynı testi farklı saatlerde tekrarla
4) Ölçek artınca davranış değişiyor mu bak
5) Gerekirse VM boyutundan önce topolojiyi düzelt
Bunu söylediğimde bazı arkadaşlar “ya tamam da biz sadece VM seçiyoruz” diyor. Haklısınız… ama tam da problem orada başlıyor zaten. Bulutta kötü tasarlanmış her seçim size daha pahalıya dönüyor; iyi tasarım işe sessizce çalışıyor, kimse fark etmiyor bile.”
Kapanışta söyleyeyim: Azure IaaS neden değerli?
İnanın, Bana göre Azure IaaS’ın güçlü tarafı tekil bileşen satması değil, koordineli sistem sunması. Bu önemli çünkü modern iş yükleri lineer davranmıyor; bazen veri girişi sıkışıyor, bazen uygulama katmanı nefes alamıyor, bazen de dağıtılmış mimaride ufak bir gecikme bütün deneyimi bozuyor. Sistem düzeyi düşünmeyince bunların hepsi rastgele arızalarmış gibi görünüyor.
Açıkçası ben bu yaklaşımı doğru yönde atılmış bir adım olarak görüyorum. Ama hâlâ eksik olan şey şu: birçok ekip kendi workload’ünü yeterince tanımadan genel reçete peşinde koşuyor. Oysa can alıcı soru “hangi servis en hızlı?” değil,“benim senaryomda hangisi en dengeli çalışıyor?” olmalı.
Eğer denemek istiyorsanız ilk işiniz yeni VM açmak olmasın. Önce ölçün,sonra darboğaz haritasını çıkarın,ardından compute-storage-network ilişkisini birlikte okuyun. Küçük görünür ama etkisi büyük olan adımlar genelde burada saklanıyor… derken kastım tam olarak bu.
Sıkça Sorulan Sorular
Azure IaaS’ta performans neden sadece VM boyutu demek değil?
Çünkü aslında gerçek performans, compute, storage ve network’ün birlikte nasıl çalıştığından çıkıyor. Büyük VM almak bazen işe yarıyor, ama darboğaz başka yerdeyse — bence pek bir şey değişmiyor.
P99 gecikme neden bu kadar önemli?
P99 ve P99.9 değerleri, yanı kullanıcıların nadiren ama bir kez yaşayınca iyice hissettikleri o kötü anları gösteriyor. Ortalama değerler güzel görünse bile, açıkçası uç gecikmeler uygulamayı yavaş hissettirmeye yetiyor.
Küçük şirketler bu yaklaşımı nasıl uygulasın?
Küçük ekipler önce izlemeyi kurmalı, sonra basit testlerle darboğazı bulmalı. Her şeyi aynı anda optimize etmeye çalışmak yerine — tecrübeme göre — en çok etki eden noktaya odaklanmak çok daha mantıklı.
Büyük kurumlarda en hayatı konu ne?
Büyük yapılarda standardizasyon ve gözlemlenebilirlik öne çıkıyor. Hani sorun çıktığında yalnızca hız değil, kök neden analizi de kritik oluyor. Karmaşa büyüdükçe yanlış tahminlerin maliyeti de ciddi artıyor.
Kaynaklar ve İleri Okuma
Orijinal Azure Blog yazısı: Azure IaaS system-level performance yaklaşımı
Azure Virtual Machines Resmî Dokümantasyonu
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.
Yorum gönder