Dağıtım Modelleri

Doğru dağıtım modeli yalnızca uygulamanın nerede çalışacağına karar vermez. Kimliğin nerede doğrulandığını, kurumsal bilginin nerede saklandığını, hangi verinin model sağlayıcısına gidebildiğini, connector'ların hangi ağdan dış sistemlere ulaştığını ve platformu kimin işleteceğini birlikte belirler.

Bu rehber dört yaygın topolojiyi karşılaştırır:

1. Kurum içi veya özel bulut
2. Kontrollü hibrit
3. Air-gapped / izole
4. Yönetilen ortam

Önce veri sınırını çizin

Topolojiyi ürün isimleriyle değil, veri sınıfları ve güven sınırlarıyla tasarlayın. İlk çalıştayda aşağıdaki varlıkları bir ağ şeması üzerine yerleştirin:

• Kullanıcı kimliği ve oturum verisi
• Organizasyon, departman, Space ve yetki metadatası
• Kaynak dosyalar ve connector'lardan alınan içerik
• Chunk, embedding ve vektör indeksleri
• Prompt, retrieval bağlamı ve model yanıtı
• Agent ve workflow tanımları
• Credential, anahtar ve sertifikalar
• Workflow ara durumu ve dış sistem işlem sonuçları
• Audit, uygulama logu, metrik ve trace verisi
• Yedekler, replikalar ve felaket kurtarma kopyaları

Her varlık için şu dört soruyu yanıtlayın:

“Uygulama kurum içinde” ifadesi tek başına yeterli değildir. Uygulama içerideyken harici embedding veya model endpoint'i kullanılıyorsa seçilen topoloji hibrit bir veri akışı içerir.

Ortak bileşenler

Fiziksel yerleşim değişse de aşağıdaki mantıksal sorumluluklar korunur:

Kullanıcı / Kurumsal Kimlik
             ↓
Knowentra Web ve API ─── Kontrol Düzlemi
             │
             ├── İlişkisel Veritabanı
             ├── Dosya / Obje Deposu
             ├── Vektör Deposu ve Embedding
             ├── LLM Secure Gateway / Guardrails
             ├── Yerel veya Harici Model Endpoint'i
             └── Workflow, Connector ve Realtime Servisleri

Bu bileşenlerin tek sunucuda başlaması mümkündür; üretimde aynı hata alanında kalmaları gerektiği anlamına gelmez. Erişilebilirlik, kapasite ve güvenlik ihtiyacı arttıkça stateful servisler ve worker'lar ayrı ölçeklenir.

Model 1 — Kurum içi veya özel bulut

Bu modelde Knowentra'nın uygulama ve veri katmanları kurumun kontrol ettiği veri merkezinde, Kubernetes/OpenShift kümesinde veya özel bulut hesabında çalışır.

Tipik yerleşim

Kurum ağı
├── Reverse proxy / ingress
├── Knowentra Web ve API
├── Workflow ve background worker'lar
├── LLM Secure Gateway ve guardrails
├── Veritabanı, vektör ve obje depolama
├── Yerel model / Ollama / OpenAI uyumlu endpoint
└── Kurumsal IdP, SIEM ve gizli değer yönetimi

Harici model veya SaaS connector kullanılmıyorsa temel iş yükü kurum ağında kalabilir. Harici servis kullanıldığında ilgili trafik için kontrollü outbound hattı açılır ve model artık “tamamen kurum içi” değildir.

Uygun olduğu durumlar

• Veri yerleşimi ve altyapı kontrolü temel gereksinimse
• Kurumsal IdP, SIEM, KMS/HSM ve ağ politikalarıyla yakın entegrasyon gerekiyorsa
• Yerel GPU veya mevcut model serving altyapısı kullanılacaksa
• İnternet çıkışı kurum tarafından sıkı biçimde yönetiliyorsa
• Platform operasyonunu yürütecek ekip mevcutsa

Kurumun üstlendiği başlıca işler

• Sunucu veya küme kapasitesi
• İşletim sistemi, container runtime ve ağ güvenliği
• Veritabanı, obje depolama ve vektör deposu operasyonu
• TLS sertifikaları, DNS, ingress ve firewall
• Yedekleme, geri yükleme ve felaket kurtarma
• Sürüm yükseltme, izleme ve olay müdahalesi

Model 2 — Kontrollü hibrit

Hibrit modelde kimlik, kurumsal bilgi, indeks ve kontrol düzlemi kurum sınırında tutulurken izin verilen model veya entegrasyon çağrıları dış hizmetlere yönlendirilebilir.

Tipik akış

Kurum ağı                                      İzinli dış servisler
┌─────────────────────────────┐                ┌─────────────────────┐
│ Knowentra + bilgi depoları  │                │ Model sağlayıcısı   │
│ Kimlik ve politika          │── kontrollü ──▶│ SaaS API / webhook  │
│ LLM Secure Gateway          │    egress      │ Yönetilen servis    │
│ Workflow worker'ları        │◀───────────────│                     │
└─────────────────────────────┘                └─────────────────────┘

LLM Secure Gateway, izin verilen harici model çağrısından önce hassas veriyi politikaya göre maskeler. Bu kontrol, gönderimin hukuki veya kurumsal olarak otomatik biçimde uygun olduğu anlamına gelmez. Sağlayıcı, bölge, saklama, eğitimde kullanım ve alt işleyen koşulları ayrıca onaylanmalıdır.

Hibrit yerleşim seçenekleri

• Hassas kullanım senaryoları yerel modele, genel kullanım harici modele gider.
• Embedding yerelde yapılır; yalnızca minimize edilmiş prompt harici modele çıkar.
• Bilgi indekslenmiş olarak kurumda kalır; işlem anında izinli SaaS verisi canlı sorgulanır.
• Workflow motoru kurumda çalışır; belirli connector çağrıları proxy üzerinden dışarı çıkar.
• Merkezi uygulama özel bulutta çalışır; tesis veya şube connector worker'ı yerel ağda çalışır.

Kritik kontroller

• Varsayılan kapalı egress ve açık sağlayıcı allowlist'i
• Hedef FQDN, port, sertifika ve mümkünse sabit proxy
• Organizasyon ve departman bazlı model politikası
• Sağlayıcıya gönderilmeden önce veri minimizasyonu ve maskeleme
• Harici credential'lar için merkezi gizli değer deposu ve rotasyon
• İstek başına sağlayıcı, model, politika ve veri sınıfı audit'i
• Timeout, rate limit ve harici servis kesintisi davranışı

Model 3 — Air-gapped / izole

Air-gapped dağıtımda çalışma ortamının internete doğrudan erişimi yoktur. Uygulama, modeller, paketler, connector'lar, güvenlik güncellemeleri ve lisans işlemleri için kontrollü bir taşıma süreci gerekir.

Air-gap neyi değiştirir?

Offline paket zinciri

1. Onaylı dış hazırlık ortamında release artefact'ları alınır.
2. Image digest, checksum, SBOM ve imza doğrulanır.
3. Zararlı yazılım ve zafiyet taraması yapılır.
4. Paket değişiklik kaydıyla transfer medyasına alınır.
5. İçeri aktarım kapısında doğrulama tekrarlanır.
6. İç registry ve model deposuna immutable sürüm olarak yüklenir.
7. Staging ortamında kurulum, migration ve geri dönüş testi yapılır.
8. Üretime değişiklik yönetimiyle alınır.

Air-gap ortamında dış model sağlayıcısı, genel SaaS connector'ı veya bulut webhook'u kendiliğinden çalışmaz. Bu yetenekler için veri diyodu, kontrollü relay ya da ayrı güvenlik bölgesi tasarlanıyorsa ortam “tam izolasyon” değil, kısıtlı bağlantılı bir topoloji olarak belgelenmelidir.

Model 4 — Yönetilen ortam

Yönetilen modelde uygulama veya altyapı operasyonunun bir bölümü hizmet sağlayıcı tarafından yürütülür. Kurum yine de kullanıcı erişimi, veri sınıflandırması, agent yetkileri, connector credential'ları ve iş süreci sonuçlarından sorumludur.

Yönetilen hizmet değerlendirmesinde sözleşme ve teknik tasarım birlikte incelenmelidir:

• Verinin işlendiği ve yedeklendiği bölgeler
• Tenant izolasyon yöntemi
• Yönetici erişimi ve ayrıcalıklı oturum kayıtları
• Şifreleme anahtarının sahipliği ve rotasyonu
• Log, prompt ve dosya saklama süreleri
• Alt işleyenler ve harici model sağlayıcıları
• RPO, RTO, bakım penceresi ve olay bildirim süresi
• Veri dışa aktarma, silme ve hizmetten çıkış prosedürü

Karşılaştırma matrisi

Bileşen yerleşim matrisi

Her bileşen için tek bir “doğru” yer yoktur. Aşağıdaki matris başlangıç noktasıdır:

Paylaşılan sorumluluk modeli

Dağıtım kararı verilirken her işi tek bir tarafa atayın. “Ortak” ifadesi tek başına sorumlu kişiyi belli etmez.

Ağ ve port planlama

Üretim kurulumu öncesinde kaynak, hedef, protokol ve iş gerekçesi olan bir akış matrisi hazırlayın. Portları herkese açmak yerine servis kimliği ve ağ segmentiyle sınırlandırın.

Gerçek port numaralarını ürün dokümanından kopyalamak yerine kurulum manifest'i, proxy ve seçilen altyapıyla doğrulayın. Port eşlemesi sürüm ve topolojiye göre değişebilir.

Yüksek erişilebilirlik ve felaket kurtarma

Yüksek erişilebilirlik yalnızca iki web instance'ı çalıştırmak değildir. Aşağıdaki bağımlılıklar aynı hata alanında kalıyorsa platform yine tek noktadan kesilebilir:

• İlişkisel veritabanı ve transaction logları
• Obje/dosya deposu
• Vektör deposu veya yeniden indeksleme kaynağı
• Redis, queue ve workflow ara durumu
• Gizli değer deposu ve şifreleme anahtarları
• Model endpoint'i ve GPU kapasitesi
• Ingress, DNS ve kurumsal IdP

RPO ve RTO her veri sınıfı için ayrı tanımlanmalıdır. Vektör indeksleri kaynak dosyalardan yeniden üretilebiliyorsa yedekleme yaklaşımı ilişkisel veriden farklı olabilir; fakat yeniden indeksleme süresi RTO hesabına eklenmelidir.

Model seçme karar ağacı

İnternet bağlantısı kesinlikle yasak mı?
├── Evet → Air-gapped topoloji
└── Hayır
    ├── Tüm uygulama ve veri kurum kontrolünde olmalı mı?
    │   ├── Evet → Kurum içi / özel bulut
    │   └── Hayır
    │       ├── Hassas veri içeride, bazı modeller dışarıda olabilir mi?
    │       │   ├── Evet → Kontrollü hibrit
    │       │   └── Hayır → Yönetilen model değerlendirilebilir
    │       └── Operasyon kapasitesi ve sözleşme kontrollerini doğrula
    └── Her durumda veri sınıfı, kimlik, egress ve DR kararlarını belgele

Tek organizasyonda birden fazla model kullanılabilir. Örneğin finans verisi air-gapped bölgede, genel kurumsal bilgi özel bulutta ve anonimleştirilmiş bir kullanım senaryosu izinli harici modelde çalışabilir. Bu durumda politika ve audit, isteğin hangi bölgeye neden yönlendiğini göstermelidir.

Kapasiteyi nasıl tahmin edersiniz?

Başlangıç boyutlandırması için yalnızca kullanıcı sayısına bakmayın:

• Eşzamanlı chat isteği ve hedef yanıt süresi
• Seçilen modelin token/saniye değeri ve context boyutu
• Günlük yeni belge, toplam chunk ve embedding hacmi
• Vektör sorgusu yoğunluğu ve filtre karmaşıklığı
• Eşzamanlı workflow ve ortalama çalışma süresi
• Connector API rate limitleri ve senkronizasyon penceresi
• Realtime bağlantı sayısı
• Log, audit ve yedek saklama süresi

Önce düşük riskli gerçekçi bir pilot yükü ölçün. CPU/RAM tablosunu üretim kapasite garantisi olarak kullanmayın; model boyutu ve iş yükü profili sonucu büyük ölçüde değiştirir.

Üretime geçiş kontrol listesi

• Veri sınıfları ve izin verilen fiziksel bölgeler belgelendi.
• Uygulama, model, embedding, indeks, dosya ve log konumları işaretlendi.
• Tüm inbound, outbound ve iç ağ akışları onaylandı.
• Harici sağlayıcıların saklama ve eğitimde kullanım koşulları incelendi.
• LLM Secure Gateway egress'ten önce konumlandırıldı.
• Credential'lar merkezi kasada ve dar kapsamla tutuluyor.
• Stateful servisler için kalıcı depolama ve şifreleme var.
• Yedekleme kadar restore ve yeniden indeksleme süresi de test edildi.
• RPO, RTO, bakım penceresi ve nöbet sorumluları belli.
• Sürüm ve model artefact'ları imza/checksum ile doğrulanıyor.
• Kapasite testi gerçekçi chat, retrieval ve workflow yükünü kapsıyor.
• Hizmetten çıkış, veri dışa aktarma ve güvenli silme planı hazır.

Sonraki adımlar

• Mantıksal sınırlar için Platform Mimarisi
• İlk deneme ortamı için Kurulum
• Üretim sertleştirmesi için Üretim Kurulumu Kontrol Listesi
• Model egress politikası için LLM Secure Gateway
• Kaynak ve araç ağ erişimi için Desteklenen Entegrasyonlar