Python AI Uygulamalarında Azure App Service: Hız Kazandıran Sessiz Değişim
Geçen ay, İstanbul’da bir müşteride Python tabanlı bir yapay zekâ servisinin dağıtımını incelerken aynı şeyi düşündüm: asıl mesele modelin kendisi değil, modeli ayağa kaldırma kısmıydı. Kod hızlıydı, ekip de fena değildi, ama deployment hattı… işte orada iş uzuyordu. Azure App Service’in Python tarafında yaptığı yeni platform iyileştirmeleri tam da bu sıkıştığı yere dokunuyor.
Azure App Service on Linux’i uzun zamandır seviyorum; çünkü ekipleri “ben altyapıyı unutayım, uygulamayı çalıştırayım” noktasına biraz yaklaştırıyor. Python, Node.js,.NET fark etmiyor; servis arka tarafta baya iş görüyor. Ama yapay zekâ uygulamaları büyüdükçe tablo değişti. Hele bir de requirements.txt, yüzlerce bağımlılık ve şişmiş sanal ortamlar devreye girince, eski akış biraz ağır kalmaya başladı. Microsoft’un burada yaptığı işin özü şu: daha az bekleme, daha az sürpriz.
Bir dakika — bununla bitmedi.
Bu yazıda olaya sadece “Microsoft güzel bir optimize etme yaptı” diye bakmayacağım. Açık konuşayım, kağıt üstünde her hız artışı iyi görünür; pratikte işe asıl soru şudur: Bu değişiklik benim gece yarısı bastığım sürümü gerçekten hızlandırıyor mu? Cevap büyük ölçüde evet. Hatta biraz şaşırdım açıkçası;. Bu iyileştirme yalnızca AI projelerine değil, dependency yoğun çalışan tüm Python uygulamalarına da dokunuyor.
Neden asıl darboğaz paket kurulumu değilmiş?
İlk bakışta herkesin gözü pip install’a kayıyor. Ben de uzun süre öyle sandım, açık konuşayım; hatta 2019’da Ankara’daki bir finans kuruluşunda benzer bir Python servisini hızlandırmaya çalışırken ilk kurcaladığımız yer dependency çözümlemesiydi, ama logların dibine indikçe anladık ki asıl dert paket indirmekten çok dosya sayısı. I/O deseniydi. Yanı mesele sadece “kaç paket var?” değildi, biraz da “bu paketler nasıl taşınıyor, nerede takılıyor?” sorusuydu.
Çok konuştum, örnekle göstereyim.
Azure App Service’te remote build açıldığında Oryx devreye giriyor; sanal ortam kuruluyor, bağımlılıklar yükleniyor. Sonra her şey bir arşive çevriliyor. İşin can sıkıcı tarafı burada başlıyor işte: o tar + gzip adımı bazen toplam sürenin büyük bölümünü yiyor, hatta kaynak yazıdaki örnekte 7.5 GB’lık PyTorch uygulamasında sıkıştırma aşaması build süresinin %58’ını almış. Evet, yanlış okumadınız; kurulumdan bile fazla. Bu kadar mı? Değil tabiî.
Bak şimdi kritik nokta şu: /home dizini Azure Storage SMB mount üstünde dürüyor. Küçük dosya I/O’su burada baya pahalıya geliyor. Python virtual environment dediğimiz yapı da aslında küçük dosya mezarlığı gibi; binlerce minik dosya var. Bunları tek tek SMB üzerinden yazmak yerine sistem hepsini yerelde hazırlayıp tek bir sıkıştırılmış arşiv olarak taşıyor. Mantıklı mı? Evet. Şık mı? Pek değil. Ama performans açısından iş görüyor mu? Fazlasıyla.
Hmm, bunu nasıl anlatsamdı…
Sıkıştırma neden bu kadar can yakıyor?
Tuhaf ama, Çünkü compression CPU istiyor, disk istiyor, zaman istiyor… yanı üçlü bela gibi davranıyor. Bir de dependency seti büyüdükçe olay katlanıyor; özellikle ML projelerinde PyTorch, NumPy, SciPy gibi paketler derken ortaya çıkan dosya sayısı hafife alınacak şey değil, hani insan ilk bakışta “ne olacak ki” diyor ama sonra build süresi uzadıkça yüzü düşüyor.
Şöyle söyleyeyim, Geçen sene İzmir’de bir e-ticaret ekibinde buna benzer bir tablo gördüm. Model basit görünüyordu ama container ayağa kalkarken süre uzuyordu; sebep model ağırlığından çok ortamın hazırlanmasıydı, yanı asıl fren kodda değil platform tarafında saklanıyordu. İnsanlar genelde uygulama koduna odaklanıyor, ama platform bazen arkadan sessizce frene basıyor; sız ne dersiniz, denediniz mi hiç?
Tam da öyle.
Zstd gecişi neden önemli?
Kaynak yazıda en çok dikkatimi çeken kısım burası öldü: Microsoft mevcut sıkıştırma yaklaşımını zstd ile değiştirmiş gibi dürüyor, ya da en azından o tarafa doğru net bir adım atıyor — itiraf edeyim, beklentimin üstündeydi —. Zstd’nın adı son yıllarda daha sık duyulur öldü; sebebi de aslında çok karmaşık değil — hız iyi, oran fena değil, modern workload’larda da idare ediyor.
Kendi tarafta zstd’yi ilk kez DP-203 çalışmalarında veri aktarımı tarafında kurcalamıştım; sonra 2024’te Logosoft’ta hibrit bulut göcusu yapan bir üretim müşterisi için image transfer senaryosunda tekrar karşıma çıktı. Orada suyu biraz daha net gördüm: her yerde en yüksek sıkıştırma oranını kovalamak gerekmiyor, çünkü bazen biraz daha düşük oran ama ciddi şekilde kısa süren işlem, günün sonunda çok daha değerli oluyor.
Aslında mesele sadece “daha hızlı deploy” değil; geliştirme döngüsünü kısaltmak ekiplerin daha çok deneme yapabilmesi demek.
Bence burada Microsoft’un attığı adım doğru yönde ama is bitmiş de değil (ben de ilk duyduğumda şaşırmıştım). Çünkü deployment süresi azalınca geliştirici seviniyor; fakat cold start davranışı, storage katmanı ve dependency stratejisi yine aynı şekilde onemini koruyor. Yanı platform biraz toparlandı diye diğer detayları çöpe atmak yok.
Bakın, peki neden? Çünkü is sadece paket açma hızına bakmıyor.
Bir de şu var: bazen insanlar tek bir iyilestirmeyi görüp tüm sistemi oraya bağlıyor, ama o kadar basit olmuyor. Mesela yeni sıkıştırma algoritması güzel çalışabilir, hatta bayağı iş görür; ama network, disk ve runtime davranışı kotuysa tablo yine karışır. Hani “tamam bu tamamdır” diyorsun, sonra başka yerden ufak bir takılma çıkıyor.
| Aşama | Eski Etki | Yeni Etki | Not |
|---|---|---|---|
| Paket kurulumu | Orta | Aynı kalabilir | Pip hâlâ önemli |
| Sıkıştırma / arşivleme | Büyük darboğaz | Daha hızlı | %30 civarı iyileşme hedefi |
| Cold start açılımı | Dikkat gerektirir | Daha dengeli olabilir | /home I/O hâlâ kritik |
| Ekip verimliliği | Sık bekleme hissi | Daha akıcı döngü | En çok da AI projelerinde etkili |
Neyse, konu biraz dağıldı ama asıl nokta aynı: zstd geçişi tek başına mucize değil, fakat deploy ve aktarım tarafında hissedilir bir rahatlama sağlayabiliyor. Neyse, sız ne dersiniz? Denediniz mi hiç?
Bunu Türkiye’de nasıl okumalıyız?
Türkiye’de kurumsal tarafta tablo biraz ayrı akıyor, açık konuşayım (ciddiyim). Startup ekibiyseniz çoğu zaman “çalışsın yeter” kafası baskın oluyor; deployment’ın 6 dakika mı 10 dakika mı sürdüğü pek kimsenin radarına girmeyebiliyor (ilk aylar hariç, orası ayrı). Ama bankacılıkta, telekomda ya da kamuya yakın yapılarda iş değişiyor: her dakika maliyet demek, her bekleme de güven kaybı demek. Peki neden? Çünkü ölçek büyüyünce küçük gecikme bile can sıkıyor.
Şahsen, Küçük ekipler için ben net şunu derim: remote build kullanın ama dependency tarafını gevşetmeyin; gereksiz paketi kesip atın, requirements dosyanızı da mümkün olduğunca temiz tutun. Büyük kurumsal yapılarda işe bunun üstüne image caching stratejisi, release window planlaması ve pipeline gözlemi eklemek gerekiyor, çünkü sizde sorun tek bir deploy değil, onlarca app aynı anda değişince o minicik gecikme topluca büyüyüp hissedilir hâle geliyor. Tahmin eder mısınız? Şey gibi yanı, tek başına idare eder duran şey kalabalıkta hemen göze batıyor.
Maliyet tarafını da konuşalım mesela… Azure fiyatlarını TL bazında düşündüğünüzde küçük görünen farkların ay sonunda can sıktığını hepimiz biliyoruz artık! Deployment süresinin %30 düşmesi doğrudan faturayı uçurmaz belki ama operasyonel verimi artırır; ekip daha az bekler, daha çok iterasyon yapar. Özellikle AI projelerinde POC’den prod’a geçiş hızlanır. Hani ilk bakışta “bu kadar mı?” diyorsunuz ya, sonra ay sonu raporuna bakınca işin rengi değişiyor.
Eğer bütçe kısıtlıysa ne yapmalı?
Zstd geçişi güzel haber. Sizin tarafta hemen bugün yapabileceğiniz birkaç şey var: önce temel işi toparlayın, sonra ince ayara geçin. Mesela requirements.txt dosyasını sadeleştirin; ağır bağımlılıkları mümkünse ayrı katmana alın; remote build mi artifact deploy mu kararını da test ederek verin. Caching mekanizmalarını kontrol edin, kodun yanında runtime boyutunu da izleyin. Kulağa basit geliyor ama çoğu ekip tam burada tökezliyor (ben de ilk duyduğumda şaşırmıştım)
- requirements.txt dosyasını sadeleştirin.
- Mümkünse ağır bağımlılıkları ayrı katmana alın.
- Remote build mi artifact deploy mu kararını test ederek verin. — bunu es geçmeyin
- Caching mekanizmalarını kontrol edin.
- Kodun yanında runtime boyutunu da izleyin.
Neyse uzatmayayım; şunu özellikle söyleyeyim: bazı ekipler için App Service hâlâ gayet doğru platform olabilirken bazı senaryolarda container tabanlı alternatifler ya da AKS üzerinde kontrollü dağıtım daha mantıklı olabilir (özellikle özel bağımlılıkları çok olan yapılarda). Az önce farklı bir yerden baktım ama aslında mesele şu: hangi model size daha az sürpriz çıkarıyorsa, orası daha doğru yerdir. Sız ne dersiniz?
Bende bıraktığı izlenim ne?
Açık konuşayım, bu tarz platform optimizasyonları ilk bakışta ufak tefek gibi dürüyor,. Işin içine girince etkisi baya hissediliyor. Ben AZ-305’e hazırlanırken bir kez daha gördüm bunu; mimarı kararların çoğu, aslında performans ile maliyet arasında gidip geliyor, bazen de insanın kafasını hafif karıştırıyor.
Şahsen, Bir gün Bursa’daki bir üretim firmasına ait iç API’de build süresi uzayınca ekip baya gerilmişti (inanın bana). CI tarafı yeşil görünüyordu, ama prod çıkışı takılıyordu; işte tam o noktada anladık ki sorun modelde değil pipeline’daydı, yanı klasik ama can sıkan türden bir vaka. Çözümün yarısı teknoloji değildi açıkçası; package list temizliği, doğru deployment modu. Düzgün gözlemleme işi toparladı.
# Basit kontrol listesi
1) Deploy tipini belirle
2) Bağımlılık sayısını ölç
3) Build süresindeki en ağır aşamayı bul
4) Gerekirse remote build yerine artifact yaklaşımını test et
5) Sonucu Application Insights ile izle
Vallahi, Microsoft’un bu hamlesi bence özellikle AI app geliştiren ekipler için fena olmayan bir moral kaynağı olmuş. Geliştirici deneyimini doğrudan iyileştiriyor, bunu inkâr edemem. Ama dur bir saniye — biraz da eksik tarafı var: böyle gelişmeler çoğu zaman platform seviyesinde anlatılıyor, gerçek kullanıcıya nasıl yansıdığı işe yeterince somut gösterilmiyor olabiliyor (yanlış duymadınız). Hani insan orada küçük bir örnek bekliyor.
Kurumlar için pratik okuma notu
paragrafının alt metni ne?
Eğer sız enterprise taraftaysanız bunu sadece “deployment hızlandı” diye okumayın. Asıl mesele, standartlaşmış pipeline’ın sürdürülebilir hâle gelmesi; bu kısmı atlayınca resmin yarısı eksik kalıyor. Küçük startup’ta tek kişi gecikmeye katlanır, olur biter; büyük şirketteyse aynı gecikme onlarca kişinin iş akışına çarpar, sonra herkes birbirine bakar.
Sıkça Sorulan Sorular
Azure App Service’te Python deploy neden yavaşlıyor?
Aslında en büyük sebep dependency yoğunluğu ve arşivleme adımı. Yanı remote build sırasında sanal ortam binlerce dosya üretirse süreç fena hâlde uzuyor. Bir de SMB tabanlı /home alanına yazma maliyeti var, o da işi epey ağırlaştırıyor.
Zstd geçişi bana ne kazandırır?
Yanı, Daha hızlı sıkıştırma, genel olarak daha kısa deployment süresi. Bence en net farkı, mesela dependency bakımından ağır Python uygulamalarında hissediyorsunuz. Küçük projelerde açıkçası etki biraz sınırlı kalabiliyor (evet, doğru duydunuz)
Tüm Python uygulamalarında aynı faydayı görür müyüm?
Hayır, görmeyebilirsiniz. Hafif web uygulamalarında fark sınırlı kalıyor; ama AI workload’larında, ML bağımlılığı yüksek projelerde ve büyük virtualenv kullanan servislerde etki gerçekten belirgin oluyor. Tecrübeme göre ne kadar ağır bağımlılık, o kadar hissedilir bir fark demek.
Küçük ekip mi yoksa kurumsal yapı mı bu değişiklikten daha çok yararlanır?
Küçük ekiplerde hız artışı doğrudan geliştirici mutluluğuna yansıyor, bence bu küçümsenecek bir şey değil. Kurumsal yapılarda işe toplam operasyon süresi düştüğü için asıl kazanç orada büyüyor. Yanı her iki tarafta da fayda var, ama ölçek büyüdükçe etkisi gerçekten katlanıyor.
Kaynaklar ve İleri Okuma
- Platform Improvements for Python AI Apps on Azure App Service — bunu es geçmeyin
- Azure App Service Resmî Dokümantasyonu
- Oryx Açık Kaynak Projesi
- Azure Files Resmî Belgeleri
- SAP ve Azure’da Yeni AI Dönemi: Kurumsal Akıl Nereye Gidiyor?
- LLM Cold Start Derdi: Blob Stream ile Hız Kazanmak (bence en önemlisi)
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