Kapasite Planlama

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 Süreci

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 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

Trafik Kategorileri

Tier	Trafik Seviyesi	Kullanım Amacı
Tier 1	< 500K istek/gün	Test/POC ortamları
Tier 2	500K - 3M istek/gün	Production ortamları
Tier 3	> 3M istek/gün	Enterprise production (8 core ile günlük 20M+ istek desteklenir)

Worker Nodes (API Gateway)

Worker node’ları API trafiğini işleyen ana bileşenlerdir. Aşağıdaki tablo, gerçek benchmark testlerine dayalı performans verilerini içermektedir.

Özellik	Tier 1	Tier 2	Tier 3
CPU	2 core	4 core	8 core
RAM	2 GB	4 GB	8 GB
Node Sayısı	1	2	4
IOPS	1,000	3,000	5,000+
IO Threads	2	4	8

RAM Gereksinimi Hesaplama

Worker node’ların RAM gereksinimi, aşağıdaki faktörlere göre hesaplanmalıdır: Hesaplama Formülü:

RAM (mesaj) = (İşletim Sistemi için Ayrılan RAM) + (Max. Thread Sayısı x Thread Size) + ((Ortalama Request Boyutu + Ortalama Response Boyutu) × Eş-zamanlı İstek Sayısı × Buffer Çarpanı (1.5-2.0))

1. Thread Sayısına Göre RAM Gereksinimi: Thread sayısı, RAM gereksinimini doğrudan etkiler. Her thread için JVM’de stack alanı ayrılır:

Maksimum Thread Sayısı: Connection pool ayarlarındaki Max Thread Count değeri
Thread Stack Size (-Xss): JVM parametresi ile her thread için ayrılan stack alanı
- Default değer: Genellikle 1 MB (platform ve JVM versiyonuna göre değişebilir)
- Önerilen değer: -Xss1m (1 MB) veya -Xss512k (512 KB) - uygulama gereksinimlerine göre
Hesaplama: Maksimum thread sayısı × Thread Stack Size = Minimum thread stack RAM gereksinimi

Örnek Hesaplama:

Maksimum thread sayısı: 4.096
Thread Stack Size (-Xss): 1 MB (default)
Thread Stack RAM gereksinimi: 4.096 × 1 MB = ~4 GB (sadece thread stack’leri için)

JVM Parametresi:

-Xss1m  # Her thread için 1 MB stack alanı
# veya
-Xss512k  # Her thread için 512 KB stack alanı (daha az RAM kullanımı)

2. Ortalama Mesaj Büyüklüğüne Göre RAM Gereksinimi: Request ve response mesajlarının boyutu, RAM kullanımını önemli ölçüde etkiler:

Küçük Mesajlar (< 1 KB): Minimal RAM gereksinimi
Orta Mesajlar (1-10 KB): Orta seviye RAM gereksinimi
Büyük Mesajlar (> 10 KB): Yüksek RAM gereksinimi
Çok Büyük Mesajlar (> 100 KB): Çok yüksek RAM gereksinimi

3. Dosya İşleme Durumuna Göre RAM Gereksinimi: Eğer API’ler dosya upload/download işlemleri yapıyorsa, ek RAM gereksinimi oluşur:

Dosya İşleme Yok: Ek RAM gereksinimi yok
Küçük Dosyalar (< 1 MB): Minimal ek RAM
Orta Dosyalar (1-10 MB): Orta seviye ek RAM
Büyük Dosyalar (> 10 MB): Yüksek ek RAM gereksinimi

4. Anlık Yük Miktarına Göre RAM Gereksinimi: Tahmin edilen anlık yük miktarı (peak trafik), RAM gereksinimini etkiler:

Düşük Yük (< 100 reqs/sec): Minimal RAM
Orta Yük (100-1.000 reqs/sec): Orta seviye RAM
Yüksek Yük (1.000-10.000 reqs/sec): Yüksek RAM
Çok Yüksek Yük (> 10.000 reqs/sec): Çok yüksek RAM

5. İşletim Sistemi ve Diğer Bileşenler: İşletim sistemi ve diğer sistem bileşenleri için RAM ayrılmalıdır:

İşletim Sistemi: Genellikle 1-2 GB
Kubernetes Bileşenleri: Kubelet, kube-proxy vb. için ~500 MB
Diğer Sistem Servisleri: ~500 MB

Toplam RAM Hesaplama Örneği: Tier 2 Senaryosu (4 Core / 4 GB RAM):

Thread RAM: 4.096 thread × 1 MB = 4 GB
Mesaj RAM: (5 KB ortalama) × 1.000 eş-zamanlı istek × 1.5 = ~7.5 MB (minimal)
Dosya İşleme: Yok = 0 GB
İşletim Sistemi: ~2 GB
Toplam: ~6 GB (güvenlik için 8 GB önerilir)

Kubernetes YAML’da RAM Ayarlama: Kubernetes YAML dosyalarında, request ve limit değerleri aynı olarak ayarlanmalıdır. RAM kullanım oranı JVM parametresi ile belirlenir:

resources:
  requests:
    memory: "8Gi"  # Minimum gereksinim
  limits:
    memory: "8Gi"  # Maksimum limit (request ile aynı)

JVM MaxRAMPercentage Parametresi: JVM’de MaxRAMPercentage parametresi ile container’a ayrılan RAM’in ne kadarının kullanılacağı belirlenir. Önerilen değer %75’tir: Örnek:

Node RAM: 8 GB
Container RAM Limit: 8 GB
JVM MaxRAMPercentage: 75%
JVM Kullanılacak RAM: 8 GB × 0.75 = 6 GB
İşletim Sistemi ve Diğer: 8 GB × 0.25 = 2 GB

resources:
  requests:
    memory: "8Gi"
  limits:
    memory: "8Gi"

JVM Parametreleri:

-server -XX:MaxRAMPercentage=75.0

Bu şekilde JVM, container’a ayrılan 8 GB RAM’in %75’ini (6 GB) kullanır, kalan %25 (2 GB) işletim sistemi ve diğer sistem bileşenleri için ayrılır.

Önemli: Thread Stack Size (-Xss) parametresi ayarlanmadığında, JVM default değeri kullanılır (genellikle 1 MB). Yüksek eş-zamanlı thread sayısı kullanılıyorsa, thread stack’leri için önemli miktarda RAM gereksinimi oluşur. Örneğin 4.096 thread için sadece stack alanı ~4 GB RAM gerektirir. Production ortamlarında mutlaka kendi trafik desenlerinize göre RAM gereksinimini hesaplayın ve test edin. Gerekirse -Xss parametresini düşürerek (örneğin 512 KB) RAM kullanımını optimize edebilirsiniz.

Benchmark Performans Sonuçları

Önemli: Aşağıdaki performans verileri tahmini değerlerdir ve birçok parametreye göre değişkenlik gösterebilir. Bu değerler, backend servisin hızlı yanıt verdiği (network gecikmesi minimal) ideal koşullarda ölçülmüştür. Gerçek production ortamlarında performans şu faktörlere göre değişiklik gösterebilir:

Network latency: Backend servise olan network gecikmesi
Backend API performansı: Backend servisin yanıt süresi ve işlem kapasitesi
Politika karmaşıklığı: Gateway üzerine eklenen politikaların sayısı ve karmaşıklığı
İstek gövdesi boyutu: Büyük payload’lar daha fazla işlem gücü gerektirir
Eş-zamanlı yük deseni: Trafiğin dağılımı ve peak anları
Sistem kaynakları: CPU, RAM ve disk I/O kullanımı

Bu nedenle production ortamları için mutlaka kendi trafik desenlerinize ve altyapınıza göre performans testleri yapılmalıdır.

Aşağıdaki performans verileri, eş-zamanlı thread yükleri altında gerçek test ortamında ölçülmüştür. Testler, backend servisin hızlı yanıt verdiği (network gecikmesi minimal) ideal koşullarda yapılmıştır. 2 Core / 2 GB RAM Konfigürasyonu (Tier 1 - Test/POC):

GET İstekleri:
- 50 thread: ~2.200 reqs/sec (ortalama 22ms)
- 100 thread: ~2.200 reqs/sec (ortalama 45ms)
- 250 thread: ~2.100 reqs/sec (ortalama 119ms)
POST İstekleri (5KB gövde):
- 50 thread: ~1.900 reqs/sec (ortalama 26ms)
- 100 thread: ~1.800 reqs/sec (ortalama 56ms)
- 250 thread: ~1.500 reqs/sec (ortalama 170ms)

4 Core / 4 GB RAM Konfigürasyonu (Tier 2 - Production):

GET İstekleri:
- 50 thread: ~8.000 reqs/sec (ortalama 6ms)
- 500 thread: ~6.700 reqs/sec (ortalama 73ms)
- 1.000 thread: ~6.700 reqs/sec (ortalama 147ms)
POST İstekleri (5KB gövde):
- 50 thread: ~7.300 reqs/sec (ortalama 6ms)
- 500 thread: ~7.100 reqs/sec (ortalama 69ms)
- 1.000 thread: ~7.000 reqs/sec (ortalama 141ms)

8 Core / 8 GB RAM Konfigürasyonu (Tier 3 - Enterprise):

GET İstekleri:
- 50 thread: ~15.400 reqs/sec (ortalama 3ms)
- 500 thread: ~15.600 reqs/sec (ortalama 31ms)
- 1.000 thread: ~15.400 reqs/sec (ortalama 64ms)
- 2.000 thread: ~14.800 reqs/sec (ortalama 133ms)
- 4.000 thread: ~14.300 reqs/sec (ortalama 276ms)
- 8.000 thread: ~11.600 reqs/sec (ortalama 655ms)
POST İstekleri (5KB gövde):
- 50 thread: ~13.400 reqs/sec (ortalama 3ms)
- 500 thread: ~13.600 reqs/sec (ortalama 36ms)
- 1.000 thread: ~13.500 reqs/sec (ortalama 73ms)
- 2.000 thread: ~13.200 reqs/sec (ortalama 150ms)
- 4.000 thread: ~12.800 reqs/sec (ortalama 309ms)
- 8.000 thread: ~11.100 reqs/sec (ortalama 701ms)
POST İstekleri (50KB gövde):
- 50 thread: ~4.700 reqs/sec (ortalama 10ms)
- 500 thread: ~3.500 reqs/sec (ortalama 142ms)
- 1.000 thread: ~3.000 reqs/sec (ortalama 326ms)
- 2.000 thread: ~2.800 reqs/sec (ortalama 710ms)

Kapasite Hesaplama Örneği: 8 core / 8 GB RAM konfigürasyonu ile günlük 20 milyon+ istek desteklenebilir. Örnek hesaplama:

Günlük 20 milyon istek = Ortalama ~231 reqs/sec
Peak trafik (günün %20’sinde trafiğin %60’ı): ~694 reqs/sec
8 core konfigürasyonu ile 1.000 thread’de ~15.400 reqs/sec (GET) kapasitesi mevcuttur
Bu nedenle 8 core ile günlük 20 milyon+ istek rahatlıkla karşılanabilir

Not: Bu değerler tahmini olup, network latency, backend API performansı, politika karmaşıklığı ve diğer faktörlere göre değişkenlik gösterebilir. Gerçek kapasite planlaması için kendi ortamınızda performans testleri yapılmalıdır.Daha yüksek trafik gereksinimleri için yatay ölçeklendirme (Kubernetes üzerinden ek worker node’lar eklenerek) yapılabilir.

Önemli Notlar:

Eş-zamanlı Thread vs İstek: Eş-zamanlı thread sayısı ile anlık istek sayısı farklı kavramlardır. Bir thread, belirli bir süre içinde birden fazla istek yapabilir. Gateway’ler genellikle stateless çalıştığı için eş-zamanlı istek sayısı ve latency ölçümü daha anlamlıdır.
Performans Etkileyen Faktörler:
- Backend servisin yanıt süresi
- Network gecikmesi
- Gateway üzerine eklenen politikaların karmaşıklığı ve sayısı
- İstek gövdesi boyutu (büyük payload’lar daha fazla işlem gücü gerektirir)
Ölçeklendirme: Dikey ölçeklendirmenin bir sınırı vardır. Kabul edilebilir yanıt sürelerine sahip daha fazla eş-zamanlı kullanıcıyı desteklemek için yatay ölçeklendirme (Kubernetes üzerinden kolayca yapılabilir) veya dikey + yatay kombinasyonu düşünülmelidir.
Politika Etkisi: Gateway’e eklenen her politika performansı etkiler. Örneğin “Basic Authentication” gibi basit politikalar minimal etki yaparken, “Content Filtering” gibi işlem gücü yüksek politikalar veya “LDAP Authentication” gibi dış bağlantı gerektiren politikalar daha fazla performans etkisi yaratır.

Worker Node Konfigürasyon Ayarları

Worker node’ların performansı, aşağıdaki konfigürasyon ayarlarına bağlıdır. Bu ayarlar, API Gateway Ortam Ayarlama ekranından yapılabilir: Tier 1 (2 Core / 2 GB RAM) Önerilen Ayarlar:

IO Threads: 2
Routing Connection Pool - Min Thread Count: 512
Routing Connection Pool - Max Thread Count: 2.048
Routing Connection Pool - Max Connections Total: 2.048
Elasticsearch Client - IO Thread Count: 8

Tier 2 (4 Core / 4 GB RAM) Önerilen Ayarlar:

IO Threads: 4
Routing Connection Pool - Min Thread Count: 1.024
Routing Connection Pool - Max Thread Count: 4.096
Routing Connection Pool - Max Connections Total: 4.096
Elasticsearch Client - IO Thread Count: 16

Tier 3 (8 Core / 8 GB RAM) Önerilen Ayarlar:

IO Threads: 8
Routing Connection Pool - Min Thread Count: 1.024
Routing Connection Pool - Max Thread Count: 8.192
Routing Connection Pool - Max Connections Total: 8.192
Elasticsearch Client - IO Thread Count: 32

JVM Parametreleri:

-server -XX:MaxRAMPercentage=75.0

Dikkat: Bu performans verileri, backend servisin hızlı yanıt verdiği ve network gecikmesinin minimal olduğu ideal koşullarda ölçülmüştür. Gerçek production ortamlarında, backend servisin yanıt süresi, network gecikmesi ve eklenen politikalar performansı önemli ölçüde etkileyebilir. Production ortamları için mutlaka kendi trafik desenlerinize göre performans testleri yapılmalıdır.

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	Tier 1	Tier 2	Tier 3
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+

Replica Sayısı ve Veri Büyüklüğü: Elasticsearch’te tutulacak toplam veri büyüklüğü, replica sayısına göre değişkenlik gösterir. Replica, aynı verinin kaç kopyasının tutulacağını belirler ve disk gereksinimini doğrudan etkiler. Disk Gereksinimi Hesaplama:

Toplam Disk Gereksinimi = (Primary Shard Veri Boyutu) × (1 + Replica Sayısı) × Buffer Çarpanı (1.2-1.5)

Örnek Senaryolar:

Replica = 0: Veri replike edilmez. Tek kopya tutulur. Minimum disk gereksinimi.
- Örnek: 1 TB primary data → ~1.2 TB disk gereksinimi
Replica = 1: Verinin bir kopyası daha tutulur. Yüksek erişilebilirlik için önerilir.
- Örnek: 1 TB primary data → ~2.4 TB disk gereksinimi (1 TB primary + 1 TB replica)
Replica = 2: Verinin iki kopyası daha tutulur. Çok yüksek erişilebilirlik için.
- Örnek: 1 TB primary data → ~3.6 TB disk gereksinimi (1 TB primary + 2 TB replica)

Önemli Notlar:

Production Ortamları: Yüksek erişilebilirlik için minimum replica = 1 önerilir. Bu durumda disk gereksinimi yaklaşık 2 katına çıkar.
Test/PoC Ortamları: Replica = 0 kullanılabilir, disk gereksinimi daha düşüktür.
Disk Planlaması: Replica sayısı belirlenirken hem yüksek erişilebilirlik hem de disk maliyeti dikkate alınmalıdır.

Disk Stratejisi: Hot tier için SSD, Warm/Cold tier için HDD kullanılması önerilir. Bu, maliyet optimizasyonu sağlar.

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. Cache boyutu günlük trafik sayısından ziyade; cache’lenecek veri hacmi, erişim sıklığı ve replication ayarlarına bağlıdır.

Boyutlandırmayı Etkileyen Faktörler

Cache Cluster boyutlandırması aşağıdaki faktörlere göre belirlenmelidir: 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
Diğer Performans Verileri: Quota, throttling ve diğer cache’lenen veriler

2. Erişim Paterni ve İşlem Yoğunluğu:

Rate Limit Kullanımı: Rate limit kullanılıyorsa, sayaçlar çok sık okunup yazıldığı için yüksek thread sayısı ve yüksek CPU gereksinimi oluşur. Ancak cache’lenen veri küçük olduğu için RAM gereksinimi nispeten düşük olabilir.
Response Cache Kullanımı: Büyük response’lar cache’leniyorsa, yüksek RAM gereksinimi oluşur.
Eş-zamanlı Erişim: Aynı anda kaç thread’in cache’e erişeceği CPU ve thread gereksinimini etkiler.

3. Replication Factor: Replication factor, aynı verinin kaç node’da tutulacağını belirler ve RAM gereksinimini doğrudan etkiler:

Replication Factor = 0: Veri replike edilmez. Her node kendi verisini tutar. Toplam RAM gereksinimi daha düşüktür.
Replication Factor = 1: Verinin bir kopyası daha tutulur. Aynı veri hacmi için RAM gereksinimi artar.

RAM Hesaplama Formülü:

Toplam RAM = (Cache Veri Boyutu) × (1 + Replication Factor) × Buffer Çarpanı (1.2-1.5)

Örnek Senaryolar: Küçük Cache (32 GB):

Cache Veri Boyutu: ~20 GB
Replication Factor: 1
Buffer Çarpanı: 1.3
Toplam RAM: 20 GB × (1 + 1) × 1.3 = ~52 GB (3 node için ~17 GB/node)

Orta Cache (64-128 GB):

Cache Veri Boyutu: ~50-100 GB
Replication Factor: 1
Buffer Çarpanı: 1.3
Toplam RAM: 100 GB × (1 + 1) × 1.3 = ~260 GB (3 node için ~87 GB/node)

Büyük Cache (256+ GB):

Cache Veri Boyutu: ~200 GB+
Replication Factor: 1
Buffer Çarpanı: 1.3
Toplam RAM: 200 GB × (1 + 1) × 1.3 = ~520 GB (5 node için ~104 GB/node)

Ö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 (Tier 2)

Worker Nodes:

3 node × (4 core + 4 GB RAM + 100 GB Disk) = 12 core + 12 GB RAM + 300 GB Disk

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:

Cache boyutu ve işlem yoğunluğuna göre değişir. Örnek: 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. Rate limit gibi yoğun erişim senaryolarında CPU yüksek, RAM düşük olabilir. Response cache gibi büyük veri senaryolarında RAM yüksek olabilir.

TOPLAM:

CPU: 40 core (Cache: 12 core örnek değer, gerçek ihtiyaca göre değişir)
RAM: 82 GB (Cache: 8 GB örnek değer, gerçek ihtiyaca göre değişir)
Disk: ~3 TB