MLOps Rehberi: Makine Öğrenmesi Modellerini Production'a Taşıma

Giriş: MLOps Nedir ve Neden Önemlidir?

Makine öğrenmesi modelleri geliştirmek günümüzde nispeten kolaydır. Açık kaynak kütüphaneleri kullanarak son derece başarılı modeller oluşturabiliriz. Ancak bu modelleri production ortamına taşıyarak, ölçeklendirebilir, güvenilir ve sürdürülebilir şekilde çalıştırmak tamamen farklı bir hikayedir.

Araştırmalara göre, veri bilimcileri tarafından geliştirilen makine öğrenmesi modellerinin %87'si hiçbir zaman production ortamına ulaşmaz. Bu başarısızlığın ana sebepleri şunlardır:

• Model geliştirme ve production ortamının uyumsuzluğu
• Veri drift ve model degradasyonunun izlenmemesi
• Manuel tekrarlayan deployment prosesleri
• Eksik versiyon kontrolü ve model yönetimi
• DevOps ve ML mühendisliği arasındaki bilgi boşluğu

MLOps (Machine Learning Operations), geleneksel DevOps pratiğini makine öğrenmesi iş akışına uyarlayan bir disiplindir. Amacı, ML modellerinin geliştirme aşamasından production'a geçiş ve sürdürülmesi sürecini otomatikleştirmek, standartlaştırmak ve ölçeklendirebilir hale getirmektir.

MLOps Olgunluk Modeli (Maturity Model)

MLOps yolculuğunuz başlamadan önce, mevcut durumunuzu anlamanız gerekir. Gartner ve Google Cloud tarafından önerilen MLOps olgunluk modeli dört seviye içerir.

Level 0: Manuel MLOps (Ad-Hoc, No Automation)

Bu seviyede veri hazırlama, model eğitimi ve deployment tamamıyla manuel yapılır. Model versiyonlaması yapılmaz, monitoring ve alert sistemi yoktur. Data scientist ve operations arasında koordinasyon minimaldır. İş akışı veri toplamaktan manuel eğitime, sonra manuel deployment'a gider. Risk profili çok yüksektir çünkü model ne zaman başarısız olacağını veya veri değiştiğini kimse bilemez.

Level 1: Otomasyona Doğru İlk Adımlar

Bu seviyede model eğitim süreci scriptleştirilir ve kontrol edilir. Veri versiyonlaması başlar, experiment tracking yapılmaya başlanır. Temel CI/CD pipeline'ı işletilir ancak manuel review ve approval adımları bulunur. İş akışı versiyonlanmış veriden otomasyonlu eğitime, manuel review'dan sınırlı monitoring'e gider.

Level 2: Otomatikleştirilmiş ML Pipeline'ı

End-to-end ML pipeline tamamen otomatiktir. Model registry ve artifact management kurulmuştur. Veri preprocessing, feature engineering ve model eğitimi orchestration tools ile yönetilir. Automated testing ve validation pipeline'ları vardır. Model serving infrastructure, Kubernetes üzerinde kurulmuştur. Production ve development ortamları aynıdır.

Level 3: Tam Otomasyon ve AI-Driven Operations

Tüm süreç end-to-end otomatiktir. Veri drift ve concept drift algılandığında otomatik olarak retraining tetiklenir. A/B testing ve progressive deployment otomasyonu yapılır. Model performance anomalileri otomatik olarak raporlanır. Yeni veri kalitesine göre tüm pipeline kalibrasyonu yapılır. İnsan müdahalesi yalnızca exception handling için gereklidir.

Smart Maple olarak Ankara'da Oplist ürünümüzü geliştirirken, health-care scheduling optimizasyonu yapan ML modellerimiz Level 2-3 arasında bir olgunluğa ulaşmıştır. Hasta istekleri ve doktor availability'si real-time değiştiğinde, modellerimiz otomatik olarak retraining'den geçer.

MLOps Tool Stack Karşılaştırması

MLOps ekosistemi oldukça geniştir. Aşağıdaki tablo, pazardaki en popüler ve enterprise-ready çözümleri karşılaştırmaktadır:

Özellik	MLflow	Kubeflow	Vertex AI	SageMaker
Temel Fokus	Experiment Tracking, Model Registry	End-to-end Pipeline Orchestration	Google Cloud Entegrasyonu	AWS Entegrasyonu
Öğrenme Eğrisi	Düşük-Orta	Yüksek	Orta	Orta
Veri Versiyonlaması	Desteklenmiyor (DVC entegrasyonu)	Desteklenmiyor	Native	Native
Model Registry	Native ve Güçlü	Sınırlı	Native	Native
Pipeline Orchestration	Basit (Projects)	İleri (Kubernetes tabanlı)	Native (Cloud AI Platform)	Native
Hosting Gereksinimi	Self-hosted veya MLflow Cloud	Kubernetes cluster gerekli	Google Cloud	AWS
Cost Model	Açık kaynak (ücretsiz)	Açık kaynak (infrastructure malı)	Pay-per-use (ortalama $2K-5K/ay)	Pay-per-use (ortalama $2K-5K/ay)
Community	Çok aktif	Aktif	Güçlü (Google tarafından)	Güçlü (AWS tarafından)
Enterprise Support	Databricks	Linux Foundation	Google	AWS

Biz Python-native ekosistem ve esneklik sebebiyle MLflow ve Kubeflow kombinasyonunu tercih ederiz. DVC ile veri versiyonlaması, MLflow ile experiment tracking yaparız. Pipeline orchestration için Kubeflow'ı Kubernetes clusterımızda çalıştırırız.

Veri Versiyonlaması: DVC (Data Version Control)

Makine öğrenmesi projelerinde, kod kadar (hatta daha fazla) önemli olan veridir. Eğer modelinizin başarılı olmasında hangi veri sürümünün kullanıldığını bilemezseniz, modeli tekrar üretemez ve debug edemezsiniz.

DVC (Data Version Control), Git'e benzer şekilde veri versiyonlaması ve pipeline'ı yönetme aracıdır. Büyük veri dosyalarını ve model artifacts'ları uzak storage'da (S3, GCP, Azure) saklarken, versiyonlama bilgisini Git'te tutarsınız. Bu sayede tüm veri değişiklikleri Git commit'leriyle bağlantılı hale gelir. Veri dosyasının boyutu ne olursa olsun, repository boyutu sabit kalır. Belirli bir versiyondaki veriyi anında geri alabilirsiniz. Data scientist ve data engineer'lar kolayca işbirliği yapabilir.

Experiment Tracking: MLflow

Makine öğrenmesi modelleri geliştirirken, birçok deney yaparsınız: hyperparameter tuning, feature engineering varyasyonları, model architecture değişiklikleri vb. Bu deneyleri organize etmemek kaçınılmaz olarak hangi parametrelerle en iyi sonuç aldığını unutturur, aynı deneyi birden fazla kez çalıştırmanıza neden olur ve model improvement'larını takip etmenizi güçleştirir.

MLflow, deneyleri trackinglemek, model parametrelerini, metrikleri ve artifacts'ları kaydetmek için açık kaynak bir platformdur. Üç ana bileşeni vardır: Tracking, deneyleri, parametreleri, metrikleri ve artifact'ları kaydeder. Projects, ML projeleri tanımlar ve çalıştırır. Models, model versiyonlaması yapılmasını sağlar. Registry, production model'lerini yönetir.

Tüm deneylerin merkezi dashboard'una erişebilirsiniz. Parametreler ve metriklerin otomatik karşılaştırması yapılır. Model artifact'larının tamamı kaydedilir. Remote tracking server'da tüm team üyeleri erişebilir.

Model Registry ve Versiyonlaması

Eğitimini tamamlayan modeli production'a taşımak için, o modeli kayıt etmek, versiyonlamak ve onay sürecinden geçirmek gerekir. MLflow Model Registry'yi kullanarak modelleri bir staging ortamında test edebilirsiniz. Model stages şunlardır: None (ilk oluşturma aşaması), Staging (test ortamında test edilme aşaması), Production (üretim ortamında aktif model) ve Archived (kullanım dışı bırakılan model).

Bu yapı sayesinde yeni modelleri aşamalı olarak ortamlar arasında ilerletebilir, eski versiyonu kolay şekilde archive edebilirsiniz.

CI/CD Pipeline'ları: ML için Otomasyonlu Deployment

Geleneksel yazılım mühendisliğinde CI/CD yaygınken, ML dünyasında pek çok proje hala manuel deployment yapıyor. Bu ciddi risklerle dolu: model'deki bug'lar ve veri drift'ler gözlemlenemiyor, deployment'lar inconsistent ve hataya açık hale geliyor, rollback'ler çok pahalıya mal oluyor.

Otomatikleştirilmiş ML pipeline'ında DVC ile veriler çekilir, veri kalitesi kontrol edilir, model eğitilir ve MLflow'a log edilir. Unit test'leri çalışır, model accuracy düşmüş mü kontrol edilir. Başarılıysa Staging ortamına deploy edilir. Entegrasyon test'leri ve yük test'leri yapılır. Prod'da canary (kısım) deployment başlatılır. Canary metrikleri izlenir. Başarılıysa %100'e çıkılır. Başarısızsa eski versiyona dönülür.

Bu adımları otomatikleştirmek, deployment sıklığını ayda 1'den günde 3-5 model update'ine çıkarır. Aynı zamanda model fail'i gözlemden onarmaya geçen süre 3 günden 15 dakikaya düşer.

Model Serving Seçenekleri

Production'da model'i serve etmenin birden fazla yolu vardır:

Seçenek	FastAPI	TensorFlow Serving	Triton Inference Server
Best For	Genel amaçlı, SKLearn, XGBoost	Deep Learning (TensorFlow)	High-performance, multi-framework
Latency	~50-200ms	~20-100ms	~10-50ms
Throughput	100-500 req/s	1000+ req/s	5000+ req/s
Memory	Düşük (~500MB)	Orta (~2-4GB)	Yüksek (~4-8GB)
Scaling	Kubernetes pod replicas	Model server instances	Kubernetes pod replicas
Setup Complexity	Düşük	Orta	Yüksek
Model Format	Pickle, ONNX, SavedModel	SavedModel	ONNX, SavedModel, TorchScript

Smart Maple Oplist için RandomForest modelleri kullanıyoruz ve gelen talepleri 100ms'in altında cevaplamalıyız. Bu nedenle FastAPI'yi tercih ederiz. FastAPI ile bir REST API oluşturur, MLflow'dan production model'i yükler ve gelen tahmin isteklerine cevap verir. Health check endpoint'i de bulunarak model serving'in sağlığı izlenir.

Model Monitoring ve Anomali Tespiti

Production'da model deploy ettikten sonra, başarısı orada ölçülür. Model ne kadar güzel test aşamasında perform etmiş olursa olsun, gerçek dünyada sorunlar çıkabilir. Data drift, eğitim verisinden farklı dağılımda veri gelmesi anlamına gelir. Concept drift ise problemin kendisinin zamanla değişmesi demektir. Model degradation, model accuracy'sinin zamanla azalması anlamına gelir.

Drift detection yaparak eğitim verisinden ne kadar sapma olduğunu ölçersiniz. Performance tracking ile accuracy, precision, recall izlersiniz. Latency monitoring ile response time'ın uzamamasını kontrol edersiniz. Anomali detection yaparak beklenmeyen input pattern'lerini yakalamazsınız. Alert system ile threshold aşılırsa otomasyonlu alert gönderilir.

Bu monitoring stratejileri sayesinde veri değişiklikleri erken fark edilir ve gerekirse otomatik retraining tetiklenir.

MLOps İnfrastruktur Maliyetleri

MLOps kurgulamak ciddi maliyet gerektirir. Küçük ölçekli setup (1-3 model, 10 milyondan az kayıt) için aylık yaklaşık $372 beklenir: Kubernetes cluster, MLflow server, S3 storage, RDS PostgreSQL. Orta ölçekli setup (5-10 model, 100 milyon kayıt) için aylık yaklaşık $1,520 gerekir: daha büyük Kubernetes cluster, HA MLflow, daha fazla storage, Monitoring suite. Enterprise ölçekte (20+ model, 1 milyardan fazla kayıt) ise aylık yaklaşık $9,800 harcama yapılır.

Smart Maple Medium scale MLOps setup'ında, bir developer team (3-5 engineer) için aylık yaklaşık $3,500 maliyet harcar. Cloud infrastructure, third-party tools lisansları ve operational overhead'i içerir. Ancak bu maliyet, elle deployment yapıyken hata yüzünden yaşanan downtime'dan ve yeniden çalışma maliyetlerinden kurtarır.

Smart Maple MLOps Metodolojisi: Oplist Case Study

Smart Maple olarak, Ankara merkezli yazılım şirketiyiz. Oplist ürünümüz, sağlık kuruluşları için hasta-doktor scheduling optimizasyonu yapan bir SaaS ürünüdür.

Hastane yönetim sistemlerinde, günde binlerce hasta randevu talebine karşılık sınırlı doktor ve saat vardır. El ile randevu atama hekimlerin deneyime bağlı ve biased oluyor, ER sürükleniyor, hasta memnuniyeti düşük kalıyor. Çözüm olarak OR-Tools (Google Optimization Tools) ve Random Forest ensemble kullanarak optimal patient-to-doctor-to-timeslot assignment yapıyoruz.

MLOps architecture'ımız üç katmandan oluşur. Production Data Pipeline katmanında real-time veri Kafka üzerinden gelir, data validation yapılır, Feature Store'da depolanır, FastAPI üzerinden model serving yapılır. Model Retraining Pipeline katmanında DVC ile veri versiyonlanır, Kubeflow orchestration yapar, MLflow tracking yapılır, model test edilir, model registry'ye kaydedilir. Monitoring ve CI/CD katmanında data drift algılanır, performance monitoring yapılır, otomatik retraining tetiklenir, canary deployment başlatılır.

Oplist'in MLOps altyapısı sayesinde model accuracy %91.2'ye çıktı (manuel atama %73 iken). Doctor utilization %94'e yükseldi (%67 öncesi). Patient wait time ortalama 2.3 günden 0.8 güne düştü. Deployment frequency günde 3-5 model update'e çıktı (ayda 1 iken). Recovery time model fail'i gözlemden onarmaya 15 dakika kaldı (3 gün iken).

MLOps Best Practices ve Tavsiyeleri

MLOps yolculuğunda başarılı olmak için şu pratikleri izlemeniz tavsiye edilir: Kod, veri, model, config olmak üzere her şeyi versiyonlayın. Unit, integration, performance test'lerini otomasyonlu çalıştırın. Data drift, performance degradation, anomalileri sürekli izleyin. Data engineer, ML engineer, ML ops rolleri ayırın. Model kart ve data sheet yazın. Yeni model'leri canary ile test edip sonra full deploy edin. Eski model'e dönüş her zaman mümkün olsun. Cloud resource'larını düzenli review edin. Model ve data access control'ü sıkı tutun. Data scientists'lerin MLOps tools'larını öğrenmesini sağlayın.

Sonuç

Makine öğrenmesi modellerini production'a taşımak, sadece bir teknik zorluk değil; aynı zamanda organizasyonel bir dönüşümdür. MLOps, data science ile DevOps arasındaki uçurumu kapatır ve modellerin güvenilir, ölçeklenebilir ve izlenebilir şekilde çalışmasını sağlar.

Smart Maple olarak, Ankara'dan kurumsal ölçekli MLOps sorunlarını çözerek, Oplist gibi başarılı ürünler geliştirdik. Siz de benzer zorluklar yaşıyorsanız, MLOps yolculuğunuza başlamak için doğru zamanı değerlendirin.

Makine öğrenmesi projelerinizin production'a geçmesinde desteğe ihtiyacınız varsa, Smart Maple'ı ziyaret edin ve danışmanlık hizmetlerimiz hakkında bilgi alın. Ankara'da kurulu, Python, Kubernetes, Cloud infrastructure uzmanı bir yazılım şirketi olarak, makine öğrenmesi, veri mühendisliği ve ürün geliştirme konularında yardımcı olmaktan mutlu oluruz.

Hemen başlamaya hazır mısınız? smart-maple.com adresini ziyaret edin ve MLOps dönüşümüne ilk adımı atın.