> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Kapasite Planlama
> Sistem, network ve altyapı yöneticileri için kapsamlı kapasite planlama rehberi: trafik tahmini, donanım gereksinimleri, ağ yapılandırması ve kurulum öncesi kararlar
## Kapasite Planlama Süreci
Kapasite planlama, Apinizer platformunun başarılı bir şekilde kurulması ve çalıştırılması için gerekli kaynakların belirlenmesi sürecidir. Bu sayfa, **sistem yöneticileri**, **network yöneticileri** ve **altyapı ekipleri** için hazırlanmış kapsamlı bir rehberdir.
Kapasite planlama yaparken aşağıdaki faktörler göz önünde bulundurulmalıdır:
### Trafik Tahmini
Trafik tahmini, kapasite planlamanın temelini oluşturur. Aşağıdaki noktalar değerlendirilmelidir:
* **Beklenen API çağrı sayısı**: Günlük ve saatlik bazda beklenen API çağrı hacmi belirlenmelidir
* **Peak trafik tahmini**: En yüksek trafik dönemlerindeki (örneğin kampanya dönemleri, özel günler) trafik hacmi tahmin edilmelidir
* **Trafik büyüme projeksiyonu**: Gelecekteki trafik artışı için projeksiyon yapılmalıdır
* **Mevsimsel değişiklikler**: Yıl içindeki mevsimsel trafik değişimleri göz önünde bulundurulmalıdır
### Deployment Modeli
Apinizer'ın kurulacağı deployment modeli, kaynak gereksinimlerini doğrudan etkiler. Mevcut seçenekler:
* **Topoloji 1: Test ve PoC**: Tüm bileşenlerin tek sunucuda çalıştığı basit kurulum modeli
* **Topoloji 2: Profesyonel Kurulum**: Bileşenlerin farklı sunucularda dağıtıldığı model
* **Topoloji 3: Yüksek Erişilebilirlik**: Yüksek erişilebilirlik için kümeleme yapılan model
* **Topoloji 4: Bölgeler Arası Dağıtım**: Global dağılım, coğrafi yedekleme
Detaylı bilgi için [Deployment Modelleri](/tr/concepts/deployment/deployment-modelleri) sayfasına bakabilirsiniz.
### Yüksek Erişilebilirlik
Kritik iş uygulamaları için yüksek erişilebilirlik gereksinimleri planlanmalıdır:
* **Uptime gereksinimleri**: Sistemin ne kadar süre kesintisiz çalışması gerektiği belirlenmelidir (genellikle %99.9+)
* **Failover stratejisi**: Bir bileşen arızalandığında trafiğin nasıl yönlendirileceği planlanmalıdır
* **Disaster recovery planı**: Büyük çaplı arıza durumlarında sistemin nasıl kurtarılacağı planlanmalıdır
### Büyüme Planı
Kapasite planlaması, sadece mevcut gereksinimleri değil, gelecekteki büyümeyi de kapsamalıdır:
* **Kısa vadeli gereksinimler**: 6 aylık dönem için gereken kaynaklar
* **Orta vadeli gereksinimler**: 1-2 yıllık dönem için planlanan kaynaklar
* **Uzun vadeli gereksinimler**: 3 yıl ve üzeri için öngörülen kaynak gereksinimleri
## Tier Bazlı Kapasite ve Donanım Gereksinimleri
### Worker Nodes (API Gateway)
Worker node'ları API trafiğini işleyen ana bileşenlerdir. Apinizer, dört standart kaynak tierı ile birlikte gelir; her tier hem donanım sınırlarını hem de JVM/thread parametrelerini otomatik olarak yapılandırır.
Peak RPS sütunu **politika uygulanmayan (zero-policy) laboratuvar** koşullarını yansıtır. Üretim boyutlandırması için **Günlük Planlama Kapasitesi** sütununu kullanın. Kendi trafik desenlerinize ve politika karmaşıklığınıza göre yük testi yapılması her zaman tavsiye edilir.
**Neden bu değerler?** Benchmark testleri idealleştirilmiş koşullarda yapılmıştır: GET istekleri, politika yok, \~0,5 ms backend RTT. Gerçek üretim ortamında **POST gövdesi**, **kimlik doğrulama**, **XSD/OpenAPI şema validasyonu**, **XSLT dönüşümü** ve **≥100 ms backend latency** bir arada bulunabilir. CPU-yoğun politikalar (özellikle XSLT ve şema validasyonu) throughput'u benchmark değerlerine kıyasla çok daha fazla düşürür. Aşağıdaki günlük planlama değerleri, tipik kurumsal iş yükleri için gözlemlenen muhafazakâr tahminlerdir.
| Tier | CPU | RAM | Zero-Policy Peak RPS¹ | Günlük Planlama Kapasitesi² | Kullanım Amacı |
| ------ | ------ | ---- | --------------------- | --------------------------- | ------------------------- |
| **W1** | 1 core | 2 GB | \~1.600 RPS | \~1M istek/gün | Test / PoC |
| **W2** | 2 core | 2 GB | \~3.800 RPS | \~2,5M istek/gün | Küçük production |
| **W4** | 4 core | 4 GB | \~9.100 RPS | \~5M istek/gün | Standart production |
| **W8** | 8 core | 8 GB | \~15.700 RPS | \~10M istek/gün | Yüksek hacimli production |
¹ wrk2 aşırı yükleme yöntemiyle ölçülmüş GET istekleri, Elasticsearch logging kapalı, politika yok, upstream RTT \~0,5 ms — laboratuvar koşulları.
² Tipik kurumsal iş yükü için muhafazakâr tahmin: POST verisi, kimlik doğrulama, şema validasyonu ve ≥100 ms backend latency bir arada varsayılmıştır. Düşük politika karmaşıklığında yukarı, CPU-yoğun politika zincirlerinde aşağı revize edin.
**CPU Verimliliği**: W1'den W8'e geçişte ölçülen RPS artışı teorik 8×'in üzerinde **9.6×** olmuştur. Bu süper-lineer ölçekleme, paylaşılan bağlantı havuzu ve Hybrid Platform Thread + Virtual Thread modelinden kaynaklanmaktadır. Büyük tierlara geçmek doğrusal değil, orantıdan fazla kazanım sağlar.
#### Thread ve JVM Parametreleri
JVM bellek ve GC ayarları, container kaynak limitine göre entrypoint tarafından otomatik yapılandırılır; manuel JVM heap parametresi gerekmez. Her tier için Undertow ve Virtual Thread parametreleri aşağıdaki gibidir:
| Tier | IO Thread | Worker Max Thread | VT Parallelism | Backlog | Max Concurrent Req |
| ------ | --------- | ----------------- | -------------- | ------- | ------------------ |
| **W1** | 2 | 256 | 1 | 2048 | 500 |
| **W2** | 4 | 512 | 2 | 4096 | 750 |
| **W4** | 8 | 1024 | 4 | 8192 | 3000 |
| **W8** | 16 | 3072 | 8 | 16384 | 10000 |
Tüm tierlar G1GC kullanır. W1/W2'de heap %60, W4/W8'de %65 olarak ayrılır. Virtual Thread'ler backend I/O ve logging için kullanılır (Hybrid PT+VT modeli); Undertow dispatch için Platform Thread korunur.
#### Bağlantı Havuzu Ayarları
Her tierin varsayılan routing bağlantı havuzu değerleri:
| Tier | Max Conn/Host | Max Conn Total | ES Max Conn/Host |
| ------ | ------------- | -------------- | ---------------- |
| **W1** | 250 | 500 | 8 |
| **W2** | 500 | 1000 | 16 |
| **W4** | 1000 | 2000 | 32 |
| **W8** | 2000 | 4000 | 128 |
#### Kapasite Hesaplama Örneği
**Senaryo**: Günlük 20 milyon istek, tipik kurumsal iş yükü (POST verisi, kimlik doğrulama, şema validasyonu), backend latency \~100 ms
* W4 planlama kapasitesi: **\~5M istek/gün/node**
* Gerekli node: 20M ÷ 5M = **4 adet W4 node**
* Büyüme payı için +1 yedek node önerilir → 5 W4 node
* **Alternatif**: 2 adet W8 node (2 × 10M = 20M/gün) — daha az sunucu, daha yüksek birim maliyet
### Manager Nodes
Manager node'ları, konfigürasyonların yapıldığı web arayüzünü sağlar. Günlük trafik yüküne bağlı olarak değişmez; konfigürasyon yönetimi ve arayüz erişimi için kullanılır. Standalone kurulum için tek node yeterlidir, production ortamları için yüksek erişilebilirlik amacıyla en az 2 node ile HA kurulumu önerilir.
### MongoDB Replica Set
MongoDB, Apinizer'ın konfigürasyon veritabanıdır. API proxy tanımları, politika konfigürasyonları ve metadata bilgilerini saklar. Günlük trafik yüküne bağlı olarak değişmez; gereksinimler, API proxy sayısı ve konfigürasyon karmaşıklığına göre belirlenir.
**Kritik**: MongoDB mutlaka **Replica Set** olarak yapılandırılmalıdır. Tek node dahi olsa replica set olarak kurulmalıdır. Standalone instance kullanılmamalıdır.
### Elasticsearch Cluster
Elasticsearch, log ve analitik verilerini saklar.
| Özellik | Küçük (S) | Orta (M) | Büyük (L) |
| -------------------------- | ---------- | --------- | ---------- |
| **CPU** | 4 core | 8 core | 16 core |
| **RAM** | 16 GB | 32 GB | 64 GB |
| **Disk (Hot)** | 500 GB SSD | 2 TB SSD | 5+ TB SSD |
| **Disk (Warm)** | 1 TB HDD | 3 TB HDD | 10+ TB HDD |
| **Network** | 1 Gbps | 1-10 Gbps | 10+ Gbps |
| **Node Sayısı** | 1 | 1 (min) | 3 (min) |
| **Shard/Index** | 1 | 1 (min) | 3 |
| **Günlük Log** | \< 10 GB | 10-100 GB | > 100 GB |
| **Aylık Log** | \~300 GB | \~1.5 TB | \~6 TB+ |
| **Yıllık Log (Retention)** | \~3.6 TB | \~18 TB | \~72 TB+ |
**Disk Gereksinimi Hesaplama:**
```
Toplam Disk = (Primary Shard Veri Boyutu) × (1 + Replica Sayısı) × Buffer Çarpanı (1.2–1.5)
```
Örnek: 1 TB primary data, replica=1 → \~2.4 TB disk gereksinimi.
* **Production ortamları**: Yüksek erişilebilirlik için minimum replica=1 önerilir.
* **Test/PoC ortamları**: Replica=0 kullanılabilir.
**Disk Stratejisi**: Hot tier için SSD, Warm/Cold tier için HDD kullanılması önerilir. Bu, maliyet optimizasyonu sağlar.
Elasticsearch logging aktifken gateway throughput'u hafif düşer (\~%3–5 GET, \~%8–12 POST 5KB). Bu etki benchmark'larda ölçülmüştür ve kapasite planlamasına dahil edilmiştir.
### Cache Cluster (Hazelcast)
Cache Cluster, Apinizer'ın distributed cache altyapısıdır ve **tutulacak veri büyüklüğüne** ve **yapılacak işleme** göre boyutlandırılmalıdır. Response cache, routing load balancer bilgileri, rate limit sayaçları ve diğer performans kritik veriler burada tutulur.
#### Boyutlandırmayı Etkileyen Faktörler
**1. Tutulacak Veri Tipi ve Büyüklüğü:**
* **Response Cache**: Cache'lenecek response verilerinin boyutu ve sayısı
* **Routing/Load Balancer Bilgileri**: Backend endpoint bilgileri ve yük dengeleme verileri
* **Rate Limit Sayaçları**: Rate limit için kullanılan sayaç verileri (genellikle küçük veri, ancak çok sık erişilir)
* **OAuth2 Token'ları**: Token cache'leme için veri hacmi
**2. Replication Factor:**
RAM Hesaplama:
```
Toplam RAM = (Cache Veri Boyutu) × (1 + Replication Factor) × Buffer Çarpanı (1.2–1.5)
```
| Özellik | Küçük Cache | Orta Cache | Büyük Cache |
| ---------------- | ----------- | ---------- | ----------- |
| **Cache Boyutu** | 32 GB | 64-128 GB | 256+ GB |
| **CPU** | 4 core | 8 core | 16 core |
| **RAM** | 32 GB | 64-128 GB | 256+ GB |
| **Disk** | 100 GB SSD | 200 GB SSD | 500 GB SSD |
| **Network** | 1 Gbps | 1-10 Gbps | 10 Gbps |
| **Node Sayısı** | 3 (min) | 3-5 | 5+ |
## Toplam Kaynak Hesaplama Örneği
Aşağıdaki örnek, orta ölçekli bir production ortamı için toplam kaynak gereksinimlerini göstermektedir.
### Senaryo: Orta Ölçekli Production
**Worker Nodes (W4 × 2):**
* 2 node × (4 core + 4 GB RAM) = 8 core + 8 GB RAM
* Planlama kapasitesi: \~10M istek/gün (2 × 5M/gün)
**Manager Nodes:**
* 1 node × (4 core + 8 GB RAM + 100 GB Disk) = 4 core + 8 GB RAM + 100 GB Disk
**MongoDB Replica Set:**
* 3 node × (4 core + 8 GB RAM + 200 GB Disk) = 12 core + 24 GB RAM + 600 GB Disk
**Elasticsearch Cluster:**
* 1 node × (8 core + 32 GB RAM + 2 TB Disk) = 8 core + 32 GB RAM + 2 TB Disk
**Cache Cluster:**
* 1 node × (4 core + 8 GB RAM + 100 GB Disk) = 4 core + 8 GB RAM + 100 GB Disk
* **Not**: Cache gereksinimleri tutulacak veri büyüklüğü, erişim sıklığı ve replication factor'e göre değişir.
**TOPLAM:**
* **CPU**: \~36 core
* **RAM**: \~80 GB
* **Disk**: \~3 TB
## Kapasite Planlama Checklist
* [ ] Günlük/saatlik/peak trafik tahmini yapıldı
* [ ] Kullanılacak politika türleri belirlendi ve planlama değeri buna göre revize edildi
* [ ] Worker tier seçildi (W1/W2/W4/W8) ve koruyucu RPS hesabı yapıldı
* [ ] Yatay ölçeklendirme (node sayısı) planlandı
* [ ] Trafik büyüme projeksiyonu için gelecek dönem planlaması yapıldı
* [ ] Manager node gereksinimleri belirlendi (Standalone veya HA)
* [ ] MongoDB veri büyüklüğü tahmin edildi (API Proxy sayısı, Audit Log)
* [ ] Elasticsearch log verisi tahmin edildi (günlük/aylık/yıllık retention)
* [ ] Cache cluster boyutu belirlendi (cache'lenecek veri hacmine göre)
* [ ] Network bandwidth gereksinimleri hesaplandı
* [ ] Toplam kaynak hesaplaması yapıldı (CPU, RAM, Disk)
* [ ] Deployment modeli seçildi (Topoloji 1/2/3/4)
* [ ] Kendi ortamında yük testi planlandı
Bu rehber başlangıç için bir kılavuzdur. Gerçek gereksinimler, trafik desenleri, API karmaşıklığı ve politika sayısına göre değişebilir. Production ortamları için mutlaka performans testleri yapılmalıdır. Ayrıntılı benchmark metodolojisi ve ölçüm sonuçları için [Benchmark Sonuçları](/tr/concepts/benchmark-sonuclari) sayfasına bakabilirsiniz.