Model sunumu ve mikroservis entegrasyonu: desenler, sözleşme, dağıtım

Model mikroservis dünyasına nasıl oturur?

Mikroservis mimarisinde her servis tek bir iş sorumluluğunu taşır, kendi veri deposuna sahiptir ve diğerleriyle iyi tanımlanmış arayüzler üzerinden konuşur. Yapay zeka modeli bu düzene farklı biçimlerde girer: uygulama servisinin içine gömülü bir kütüphane olarak ya da kendi başına dağıtılan ve ağ üzerinden çağrılan ayrı bir servis olarak.

Gömülü kullanım küçük modeller ve düşük gecikme gereksinimi için basit bir çözümdür; ancak model her güncellendiğinde uygulama servisinin yeniden dağıtılması gerekir ve model kaynağı (bellek, işlemci) uygulama ile aynı yerde tüketilir. Ayrı servis olarak sunum (model serving) ise model yaşam döngüsünü uygulamadan ayırır: model bağımsız güncellenir, bağımsız ölçeklenir, farklı ekipler sahiplenir. Çoğu kurumsal entegrasyonda bu ikinci yol tercih edilir, çünkü modelin kaynak ihtiyacı (çoğunlukla GPU ya da büyük bellek) diğer servislerinkinden çok farklıdır.

Modeli ayrı servis olarak sunmak ve mikroservis ekosistemine bağlamak için gereken kararlar şunlardır: çağrı biçimi, servis sözleşmesi, dayanıklılık, dağıtım ve izleme.

Entegrasyon desenleri: senkron, asenkron ve toplu

Çağrı biçimini kullanım senaryosu belirler.

Senkron istek-yanıt (REST ya da gRPC): kullanıcının cevabı beklediği durumlar. Örneğin bir ödeme sırasında sahte işlem skoru almak. Gecikme bütçesi sıkıdır; model hızlı yanıt vermek zorundadır, aksi halde çağrı zaman aşımına uğrar.

Asenkron mesajlaşma (kuyruk ya da olay akışı): sonuç anında gerekmiyorsa. Örneğin yüklenen bir belgenin sınıflandırılması. İstek bir kuyruğa bırakılır, model servisi tüketir, sonuç başka bir olayla geri yayımlanır. Bu desen ani yük artışlarını tampon alır ve model servisinin ölçeklenmesinden bağımsız çalışır.

Toplu işleme (batch): gece çalışan skorlama işleri ya da periyodik yeniden hesaplamalar. Sonuçlar bir veri deposuna yazılır, diğer servisler oradan okur. Çağrı başına gecikme önemli değildir, toplam verim önemlidir.

Bazı sistemler karma kullanır: sık gelen sorgular önceden hesaplanıp önbellekten sunulur, nadir sorgular canlı çağrılır. Dil modelleri gibi akış (streaming) üreten servislerde ise yanıt parça parça iletilir; bu, istemci sözleşmesinde ayrıca tanımlanmalıdır.

Servis sözleşmesi: girdi, çıktı ve sürümleme

Model servisinin arayüzü, diğer servislerle arasındaki sözleşmedir ve ilk tasarlanan şeydir. Girdi şeması (alan adları, türler, zorunlulukları), çıktı şeması (tahmin, güven değeri, model sürümü) ve hata davranışı açıkça yazılır. Model bir sınıflandırma sonucu döndürüyorsa yalnız etiketi değil, olasılığı ve hangi model sürümüyle üretildiğini de döndürmek, sonradan hata ayıklamayı mümkün kılar.

Sürümleme katmanlıdır: API sürümü (sözleşme değişimi) ve model sürümü (aynı sözleşme altında iyileştirilen model). Model sürümü değişimi API sürümünü bozmamalı; ancak çıktı dağılımı değiştiği için çağıran servisler bundan etkilenebilir. Bu yüzden model sürümü yanıtta görünür tutulur ve çağıran taraf sürüm değişiminden haberdar edilir.

Doğrulama sınırda yapılır: model servisi geçersiz girdiyi modele ulaşmadan reddeder. Eksik alan, beklenmedik tür ya da aşırı büyük girdi, model hatasından önce yakalanmalıdır. İstek boyutu ve süre sınırları da sözleşmenin parçasıdır.

Dayanıklılık: zaman aşımı, yeniden deneme, yedek davranış

Model servisi diğer servislerden yavaş ve daha değişken yanıt verir. Çağıran servis bu gerçeği tasarımına yazmalıdır:

• Zaman aşımı: her çağrının açık bir üst süresi olmalı; sınırsız bekleme zincirleme çöküş yaratır.
• Yeniden deneme: yalnızca güvenli ve idempotent çağrılarda, üstel geri çekilme ile. Tahmin çağrısı yan etkisizse yeniden denenebilir; ödeme gibi yan etkili çağrıda dikkatli olunur.
• Devre kesici (circuit breaker): model servisi sürekli hata veriyorsa çağrıları geçici olarak durdurup hızlıca yedek davranışa geçer.
• Yedek davranış (fallback): model yanıt veremediğinde ne olacağı önceden belirlenir. Basit bir kural, son bilinen sonuç, varsayılan değer ya da insana yönlendirme. Önemli olan, model çökünce kullanıcının sessizce yanlış sonuç görmemesidir.
• Yük sınırlama: ani artışta model servisini korumak için hız sınırı ve kuyruk derinliği sınırı.

Asenkron akışlarda mesajın tekrar işlenme ihtimali için idempotency, işlenemeyen mesajlar için ölü mektup kuyruğu (dead-letter queue) kurulur.

Dağıtım ve yaşam döngüsü: model sürümleri nasıl yayına alınır?

Model dağıtımı uygulama dağıtımından daha risklidir, çünkü hata derleme sırasında değil, canlı veride davranış farkı olarak ortaya çıkar. Bu yüzden kademeli yayın uygulanır.

Gölge dağıtım (shadow): yeni model canlı trafiği alır ama sonuçları kullanıcıya dönmez; eski modelle karşılaştırılır. Canary dağıtım: trafiğin küçük bir bölümü yeni modele yönlendirilir, izleme metrikleri sağlıklıysa oran artırılır. Mavi-yeşil dağıtım: eski ve yeni sürüm birlikte hazır tutulur, sorun olursa hızla eskiye dönülür.

Model yapıtları (artifact), kod ile aynı disiplinle sürümlenmeli, bir model kayıt sistemi içinde kimin, hangi veriyle, hangi parametrelerle eğittiği kayıtlı olmalıdır. CI/CD hattı model testlerini (örnek girdilerin beklenen çıktıyı vermesi, gecikme ve bellek sınırları) otomatik çalıştırır. Aynı model dosyası geliştirme, test ve üretimde aynı yapıyla çalışmalı; ortam farkları ayrı yapılandırma ile yönetilmelidir.

Ölçeklenme tarafında model sunumu bellekte ısınma gerektirebilir; soğuk başlangıç süresi, otomatik ölçeklenmede göz önüne alınmalıdır. Kaynak yoğun modellerde istekleri toplu halde işlemek (dynamic batching) verimi artırır, ancak gecikmeyi etkiler.

Gözlemlenebilirlik: servis sağlığından model sağlığına

Klasik mikroservis izleme; istek sayısı, hata oranı, gecikme ve kaynak kullanımıdır. Model servisinde buna model davranışı eklenir. Girdi dağılımı kaydıyla veri kayması (drift) izlenir: canlı verinin eğitim verisinden uzaklaşması model kalitesinin düşeceğinin erken işaretidir. Çıktı dağılımı da izlenir: model aniden hep aynı sınıfı veriyorsa bir şey ters gidiyordur.

Dağıtık izleme (distributed tracing) bir isteğin servisler arasında nasıl dolaştığını gösterir; model servisi bu izin içinde ayrı bir adım olarak görünmelidir ki yavaşlığın kaynağı bulunabilsin. Loglarda girdi ve çıktının hassas kısımları maskelenmeli, kişisel veri korunmalıdır.

Gerçek sonuç etiketleri sonradan geliyorsa (örneğin dolandırıcılık onayı haftalar sonra netleşir), tahminlerle gerçekleşenlerin sonradan eşleştirildiği bir döngü kurulmalıdır. Bu döngü, hem yeniden eğitim kararını hem model kalite panosunu besler.

Güvenlik tarafında kimlik doğrulama ve yetkilendirme servis arası çağrılarda da uygulanır, model uç noktaları kamuya açık bırakılmaz, istek sınırlaması ve girdi doğrulaması kötüye kullanımı azaltır.

Sık yapılan hatalar ve nereden başlanır?

Sık hatalar: modeli uygulama koduna gömüp ölçeklenme sorununu sonradan keşfetmek, sözleşmeyi yazmadan servisi yayına almak, zaman aşımı ve yedek davranış tanımlamamak, model sürümünü yanıtta döndürmemek, yalnız altyapı metriklerini izleyip model kalitesini izlememek, eğitim ortamı ile sunum ortamı arasındaki bağımlılık farklarını gözden kaçırmak.

Başlangıç için küçük bir yol izlenebilir: mevcut bir modeli basit bir HTTP servisine sarmak, girdi doğrulaması ve sürüm bilgisi eklemek, istemci tarafında zaman aşımı ve yedek davranış tanımlamak, ardından kuyruk tabanlı bir asenkron varyantını denemek. Sonraki adım gölge dağıtım ve izleme panosudur.

Kurumsal ortamda entegrasyonun teknik tarafı kadar sahiplik tarafı da önemlidir: modeli veri bilimi ekibi mi, platform ekibi mi işletecek, olay durumunda kim çağrılacak? Bu soruların cevabı sözleşme kadar önemli olan işletim sözleşmesidir.

Mindset programlarında bu beceri nerede çalışılır?

Yapay Zeka ile Mikroservis Entegrasyonu programı; "Yapay Zeka API Tasarımı ve Servisi", "Mesaj Kuyruğu ve Olay Mimarisi", "Ölçeklenebilirlik ve Dayanıklılık", "Gözlemlenebilirlik ve İzleme" ve "CI/CD ve Sürekli Dağıtım" modülleriyle bu başlıklardaki konuların uygulama tarafını işler. "Kurumsal Entegrasyon Vaka Çalışması ve Uygulama" modülü bir bütün akışı denemeye olanak verir. Backend geliştiriciler ve platform mühendisleri için uygundur.

Yapay Zeka Modeli Entegrasyon Mimarisi programı ise "Model Servisleme ve Çıkarsım Altyapısı", "API Tasarımı ve Yük Dengeleme", "Yapay Zeka Boru Hattı Orkestrasyon" ve "Gözlemlenebilirlik, İzleme ve MLOps" modülleriyle mimari kararları ele alır. Mimari ekipler, entegrasyonun hem tasarım hem uygulama tarafını bu programlarla tamamlayabilir.