Dağıtık Cache

Apinizer için dağıtık Cache Server’ları oluşturabilir ve yapılandırabilirsiniz. Cache Server’ları Gateway pod’larından bağımsız namespace’lerde çalışabilir, esnek altyapı yönetimi sağlar. Hem yönetilen hem de uzak Cache Server dağıtımlarını yapılandırabilirsiniz.

Dağıtık Cache, Apinizer’ın throttling, quota, OAuth2 token’ları ve yük dengeleme bilgileri gibi paylaşılan verileri saklayan cache altyapısıdır. Cache Server’ları artık Gateway pod’larından ayrı Kubernetes namespace’lerinde çalışabilir, daha esnek bir altyapı yönetimi sağlar.

​

Cache Server Genel Bakış

Cache Server (apinizer-cache), Apinizer’da gerek duyulan cache değerlerinin tutulduğu ortamdır. Dağıtık önbellekleme için Hazelcast teknolojisini kullanır ve Apinizer tarafından yönetilebilir veya mevcut bir uzak Cache Server dağıtımına bağlanabilir.

Namespace Bağımsızlığı:

Cache Server pod’ları artık Gateway pod’larından farklı bir Kubernetes namespace’inde çalışabilir. Bu, daha esnek bir altyapı yönetimi sağlar ve Gateway ve Cache iş yüklerini ayırmanıza olanak tanır. Gateway pod’ları diğer namespace’lerdeki Cache Server’larına Kubernetes service discovery kullanarak erişebilir (örn: http://cache-http-service.apinizer-cache.svc.cluster.local:8090).

​

Cache Server Yapılandırması

​

Deployment Tipi Seçimi

Cache Server oluştururken, deployment tipini seçmeniz gerekir:

​

Apinizer Tarafından Yönetilen

Apinizer, Kubernetes API kullanarak cache dağıtımını otomatik olarak oluşturur ve yönetir. Apinizer, namespace, deployment, service ve tüm gerekli Kubernetes kaynaklarını otomatik olarak oluşturacaktır.

Bu seçeneği şu durumlarda kullanın:

• Apinizer’ın tüm cache yaşam döngüsünü yönetmesini istiyorsanız
• Otomatik kaynak sağlama ve yönetime ihtiyacınız varsa
• Basitleştirilmiş Cache Server yönetimi istiyorsanız

​

Uzak Cache Server

Manuel olarak YAML ile dağıtılmış mevcut bir Cache Server pod’una bağlanın. Apinizer yalnızca bağlantı detaylarını kaydedecek, dağıtımı yönetmeyecektir.

Bu seçeneği şu durumlarda kullanın:

• Apinizer dışında yönetilen mevcut bir Cache Server dağıtımınız varsa
• Apinizer tarafından desteklenmeyen özel Cache Server yapılandırmalarına ihtiyacınız varsa
• Başka bir sistem tarafından dağıtılmış bir Cache Server kullanmak istiyorsanız

Uzak Cache Server Gereksinimleri:

Cache Server pod’unuzun çalıştığından ve erişilebilir olduğundan emin olun. Apinizer yalnızca bağlantı detaylarını kaydedecek, dağıtımı yönetmeyecektir. Uzak Cache Server dağıtımının bakımından siz sorumlusunuz.

​

Namespace Yapılandırması

Önemli: Namespace yapılandırması Cache Server oluşturulduktan sonra değiştirilemez. Oluşturma sırasında doğru namespace’i seçtiğinizden emin olun.

​

Yeni Namespace Oluştur

Yeni bir namespace oluştururken, özel bir namespace adı belirtebilirsiniz. Namespace, RFC 1123 DNS etiket standartlarına uygun olmalıdır:

• 3 ile 63 karakter arasında olmalıdır
• Sadece küçük harf alfanumerik karakterler (a-z, 0-9) veya tire (-) kullanılabilir
• Küçük harf alfanumerik bir karakterle başlamalı ve bitmelidir
• Örnekler: my-namespace, prod-env, 123-abc

​

Mevcut Namespace Kullan

Cache Server’ın dağıtılacağı mevcut bir Kubernetes namespace’i seçebilirsiniz. Bu şu durumlarda kullanışlıdır:

• Mevcut bir namespace’i yeniden kullanmak istiyorsanız
• Belirli namespace’leri gerektiren namespace yönetim politikalarınız varsa
• Başka bir sistem tarafından yönetilen bir namespace’te Cache Server’ları dağıtmak istiyorsanız

Namespace Bağımsızlığı:

Cache Server’ları Gateway pod’larından farklı namespace’lerde çalışabilir. Bu şunları yapmanıza olanak tanır:

• Daha iyi kaynak yönetimi için Gateway ve Cache iş yüklerini ayırma
• Gateway ve Cache namespace’lerine farklı güvenlik politikaları uygulama
• Gateway ve Cache’i bağımsız olarak ölçeklendirme
• Cache altyapısı için özel namespace’ler kullanma

Gateway pod’ları diğer namespace’lerdeki Cache Server’larına Kubernetes service discovery formatı kullanarak erişebilir: http://service-name.namespace.svc.cluster.local:port

​

Cache Management API Yapılandırması

Cache Management API URL’leri, API Manager ve Gateway’in Cache Server uygulaması ile nasıl iletişim kuracağını tanımlar. Yüksek kullanılabilirlik senaryoları için birden fazla API URL’si yapılandırabilirsiniz.

​

Tek API URL Yapılandırması

Temel kurulumlar için, tek bir Cache Management API URL’si yapılandırın:

Format: http://cache-http-service.namespace.svc.cluster.local:8090

Örnek:

• http://cache-http-service.apinizer-cache.svc.cluster.local:8090
• http://cache-http-service.prod.svc.cluster.local:8090

​

Çoklu API URL Yapılandırması

Yüksek kullanılabilirlik için birden fazla Cache Management API URL’si yapılandırabilirsiniz. Her URL şunlara sahip olabilir:

• Ad: API URL için açıklayıcı bir ad
• Health Check Adresi: Health check’ler için kullanılan adres

Kullanım senaryoları:

• Birden fazla namespace arasında yüksek kullanılabilirlik dağıtımları
• Birden fazla cache cluster arasında yük dengeleme
• Felaket kurtarma senaryoları

Cross-Namespace İletişim:

Gateway pod’ları ve Cache Server pod’ları farklı namespace’lerde olduğunda, Kubernetes service discovery formatını kullanın: http://service-name.namespace.svc.cluster.local:port

Bu, Gateway pod’larının namespace konumlarından bağımsız olarak Cache Server’larına erişmesine olanak tanır.

​

Yönetilen Mod Yapılandırması

Apinizer Tarafından Yönetilen seçildiğinde, Apinizer Cache Server için tüm Kubernetes kaynaklarını oluşturur ve yönetir.

​

Kaynak Yapılandırması

Alan	Açıklama
Replica Sayısı	Cache Server pod sayısı. Kubernetes Cluster’daki replicaSet ile eş değerdir.
CPU	Pod’un kullanacağı maksimum CPU core sayısı.
Bellek	Pod’un kullanacağı maksimum bellek değeri.
Bellek Birimi	Bellek için gerekli olan değerin birimi seçilir; MB, GB.

Bellek Boyutlandirma Rehberi:

Cache Server, 1 GB uzerindeki container’larda ZGC kullanir ve heap oranini %50-55 olarak ayarlar. Kalan bellek ZGC, JVM dahili yapilari ve Hazelcast native yapilari tarafindan kullanilir. Toplam container belleginin yaklasik %40’i cache verisi icin kullanilabilir.

Container Bellek	GC	Heap	Cache Verisi Icin Kullanilabilir	Yaklasik Kayit Sayisi (500 B/kayit)
2 GB	ZGC	~1.024 MB	~700 MB	~1,4 milyon
4 GB	ZGC	~2.250 MB	~1.800 MB	~3,7 milyon
8 GB	ZGC	~4.500 MB	~4.000 MB	~8 milyon

Boyutlandirma formulu:

Onerilen Container Bellek = (Beklenen Cache Veri Boyutu / 0,4) + 1 GB

Ornegin 2 GB cache verisi tutmak icin: (2000 MB / 0,4) + 1000 MB = 6 GB container

Kayit sayisi tahminleri, ortalama 500 byte kayit boyutu varsayar (key, response body, header ve Hazelcast metadata dahil). Gercek kayit boyutlari onbelleklenen response body boyutuna gore degisir. Gercek kayit sayilarini ve bellek kullanimini Cache Dashboard’dan izleyebilirsiniz.

GC ve Bellek Profili: Apinizer, Cache Server’in container bellegine gore uygun GC algoritmasini otomatik olarak secer. 1 GB uzerindeki container’larda ZGC secilir ve heap orani %50-55 olarak ayarlanir. 1 GB ve altindaki container’larda G1GC kullanilir ve heap orani %50’dir. ZGC, buyuk heap boyutlarinda G1GC ile yasanabilen Hazelcast cluster partition timeout riskini azaltan sub-millisecond GC duraklamalari saglar. JAVA_OPTS ile otomatik GC secimini gecersiz kilabilirsiniz. Detaylar icin JVM Garbage Collector Ayarlama sayfasina bakin.

​

Kubernetes Service Yapılandırması

Cache Server uygulamasını açığa çıkarmak için Kubernetes servislerini yapılandırabilirsiniz:

Servis Seçenekleri:

• Kubernetes Service Oluştur: Cache Server erişimi için Kubernetes Service oluşturmayı etkinleştir
• Servis Adı: Kubernetes Service’in adı (varsayılan: cache-server-service)
• Servis Tipi:
  • ClusterIP: Varsayılan tip. Servis yalnızca cluster içinden erişilebilir. API Manager/Gateway ve Cache Server arasındaki dahili iletişim için en iyisidir.
  • NodePort: Servis her node’da belirli bir port üzerinden erişilebilir (30000-32767 aralığı)

Servis Silme:

Kubernetes Service oluşturmayı devre dışı bırakırsanız, daha önce oluşturulan Kubernetes Service Kubernetes’ten silinecektir. Devre dışı bırakmadan önce bunun istediğiniz şey olduğundan emin olun.

​

Ek Değişkenler

Pod içinde çalıştırılacak varsayılan ve opsiyonel değişkenler ve değerleri tanımlanır.

Tomcat Ayarları:

Değişken	Açıklama	Varsayılan	CPU’ya Göre Önerilen Değerler
SERVER_TOMCAT_MAX_THREADS	Tomcat’in işleyebileceği maksimum eşzamanlı istek sayısı	1024	1 CPU: 256, 2 CPU: 1024, 4 CPU: 2048, 8 CPU: 4096
SERVER_TOMCAT_MIN_SPARE_THREADS	Tomcat’in her zaman hazır tutacağı minimum thread sayısı	512	1 CPU: 128, 2 CPU: 256, 4 CPU: 512, 8 CPU: 1024
SERVER_TOMCAT_ACCEPT_COUNT	Tüm thread’ler meşgulken kuyrukta bekleyebilecek maksimum bağlantı sayısı	512	1 CPU: 256, 2 CPU: 512, 4 CPU: 1024, 8 CPU: 2048
SERVER_TOMCAT_MAX_CONNECTIONS	Tomcat’in aynı anda kabul edebileceği maksimum bağlantı sayısı	8192	1 CPU: 2048, 2 CPU: 4096, 4 CPU: 8192, 8 CPU: 16384
SERVER_TOMCAT_CONNECTION_TIMEOUT	Bağlantı zaman aşımı süresi (milisaniye)	20000 (20 saniye)	-
SERVER_TOMCAT_KEEPALIVE_TIMEOUT	Keep-alive bağlantı zaman aşımı süresi (milisaniye)	60000 (60 saniye)	-
SERVER_TOMCAT_MAX_KEEPALIVE_REQUESTS	Keep-alive bağlantısı üzerinden işlenebilecek maksimum istek sayısı	10000	-
SERVER_TOMCAT_PROCESSOR_CACHE	İşlemci önbelleğindeki maksimum processor sayısı	512	-

Hazelcast Ayarları:

Değişken	Açıklama	Varsayılan
HAZELCAST_CLIENT_SMART	Hazelcast client’ın akıllı yönlendirme kullanıp kullanmayacağı	true
HAZELCAST_IO_WRITE_THROUGH	Hazelcast write-through modunun açık olup olmadığı	false
HAZELCAST_MAP_LOAD_CHUNK_SIZE	Hazelcast map yüklenirken kullanılacak chunk boyutu	10000
HAZELCAST_MAP_LOAD_BATCH_SIZE	Hazelcast map yüklenirken kullanılacak batch boyutu	10000
HAZELCAST_MAPCONFIG_BACKUPCOUNT	Hazelcast map verisinin kaç yedek kopyasının saklanacağı	1
HAZELCAST_MAPCONFIG_READBACKUPDATA	Yedek kopyalardan okuma yapılıp yapılmayacağı	false
HAZELCAST_MAPCONFIG_ASYNCBACKUPCOUNT	Asenkron yedekleme kopya sayısı	0
HAZELCAST_PARTITION_COUNT	Hazelcast partition sayısı	271
HAZELCAST_OPERATION_RESPONSEQUEUE_IDLESTRATEGY	Hazelcast operation response queue idle stratejisi (block/backoff)	block
HAZELCAST_OPERATION_THREAD_COUNT	EntryProcessor performansı için Hazelcast operasyon thread sayısı	8 (CPU core sayısı)
HAZELCAST_OPERATION_GENERIC_THREAD_COUNT	Background işlemler için Hazelcast genel operasyon thread sayısı	4 (CPU core sayısı / 2)
HAZELCAST_SERIALIZATION_USE_NATIVE_BYTE_ORDER	Serialization için native byte order kullanımı (performans optimizasyonu)	true
HAZELCAST_MAX_NO_HEARTBEAT_SECONDS	Member’ın ölü sayılması için maksimum heartbeat yokluğu süresi (saniye)	300
HAZELCAST_HEARTBEAT_INTERVAL_SECONDS	Cluster member’lar arası heartbeat aralığı (saniye)	5
HAZELCAST_MASTER_CONFIRMATION_INTERVAL_SECONDS	Master confirmation aralığı (saniye)	30
HAZELCAST_SOCKET_KEEP_ALIVE	TCP socket keep-alive özelliği	true
HAZELCAST_SOCKET_NO_DELAY	TCP_NODELAY aktif (küçük paketler için düşük latency)	true
HAZELCAST_OPERATION_CALL_TIMEOUT_MILLIS	Operasyon çağrı timeout’u (milisaniye)	60000 (60 saniye)
HAZELCAST_OPERATION_BACKUP_TIMEOUT_MILLIS	Backup operasyon timeout’u (milisaniye)	5000 (5 saniye)
HAZELCAST_MAP_WRITE_DELAY_SECONDS	Write-behind gecikme süresi (saniye)	5
HAZELCAST_MAP_WRITE_BATCH_SIZE	Write-behind batch boyutu	100
HAZELCAST_MAP_WRITE_COALESCING	Write-behind coalescing özelliği	true
HAZELCAST_MAP_WRITE_BEHIND_QUEUE_CAPACITY	Write-behind kuyruk kapasitesi	100000
HAZELCAST_MAP_MAX_SIZE	Her Hazelcast map icin node basina maksimum kayit sayisi. Asildiginda LRU (en az kullanilan) politikasiyla eski kayitlar otomatik temizlenir.	10000
HAZELCAST_SPLITBRAIN_PROTECTION_ENABLED	Split-brain protection açık/kapalı (3+ node cluster’lar için)	false
HAZELCAST_SPLITBRAIN_QUORUM_SIZE	Split-brain protection için minimum quorum boyutu	2
HAZELCAST_CP_MEMBER_COUNT	CP Subsystem member sayısı (0 = devre dışı)	0
HAZELCAST_CP_GROUP_SIZE	CP Subsystem group boyutu	3
HAZELCAST_CP_SESSION_TTL_SECONDS	CP Subsystem session TTL (saniye)	300
HAZELCAST_CP_SESSION_HEARTBEAT_SECONDS	CP Subsystem session heartbeat aralığı (saniye)	5
HAZELCAST_MERGE_BATCH_SIZE	Merge policy batch boyutu	100
CACHE_SERVICE_NAME	Cache Server’ın Kubernetes üzerinden diğer Cache Server pod’larına erişebilmesi için gerekli servis adı	cache-hz-service
CACHE_QUOTA_TIMEZONE	Cache’de günlük kota bilgilerinin sıfırlanma zamanı için timezone (örn: +03:00)	00:00
CACHE_LAZY_MODE	Cache Server pod’larının ilk açılışta veritabanındaki değerleri tek seferde yüklemeye çalışması istenmiyorsa “lazy” olarak ayarlanabilir	eager
METRICS_ENABLED	Metrik toplama özelliğinin açık olup olmadığı	false

HAZELCAST_OPERATION_RESPONSEQUEUE_IDLESTRATEGY

Eğer bu parametreyi “backoff” ayarlarsanız: Cache Server pod’unun CPU limitinin %90-100’ünü sürekli kullanacaktır. Bu durum %5-10 performans artışı sağlayabilir ancak Cache Server pod’unun CPU kaynaklarının limitini tüketir.

CACHE_QUOTA_TIMEZONE:

Cache’de günlük kota bilgileri de tutulmaktadır. Günlük kota bilgileri UTC timezone’a göre sıfırlanır. Eğer günlük değişen kotanın başlangıç zamanını kendi yerel saatinize göre sıfırlanmasını istiyorsanız ek değişkenlere CACHE_QUOTA_TIMEZONE değerini ekleyebilirsiniz. Buraya eklenen değerin “+03:00” şeklinde yazılması gereklidir.

CACHE_LAZY_MODE:

Cache Server pod’larının ilk açılışta veritabanındaki değerleri tek seferde yüklemeye çalışması istenmiyorsa CACHE_LAZY_MODE değeri “lazy” olarak eklenebilir. Bu durumda öncelik pod’un açılmasına verilir ve değerler pod açıldıktan sonra da yüklenmeye devam edebilir. Veritabanında yüksek miktarda kayıt varsa bu değerin girilmesi önerilir.

​

Host Alias Yapılandırması

Cache Server için host alias’ları yapılandırın. Host alias’lar IP adreslerini hostname’lere eşlemenize olanak tanır.

Kullanım senaryoları:

• DNS’te olmayan hostname’leri çözümleme
• Dahili IP adreslerini kullanıcı dostu hostname’lere eşleme
• Özel hostname çözümleme yapılandırması

Örnek Kullanım:

IP Adresi	Host İsimleri
10.10.10.10	alias_name, other_alias_name

​

Node İsim Listesi Yapılandırması

Cache Server pod’larının hangi Kubernetes node’larında zamanlanacağını yapılandırın. Hiçbir node seçilmezse, pod’lar herhangi bir node’da zamanlanabilir.

Kullanım senaryoları:

• Cache Server pod’larını belirli yüksek bellekli node’larda zamanlama
• Cache iş yüklerini özel node’lara izole etme
• Cache Server pod’larının SSD depolamalı node’larda çalışmasını sağlama

​

Uzak Mod Yapılandırması

Uzak Cache Server seçildiğinde, mevcut Cache Server dağıtımı için bağlantı detaylarını yapılandırmanız gerekir.

​

Temel Bilgiler

Alan	Açıklama
Ad	Cache Server yapılandırması için açıklayıcı bir ad
Açıklama	Cache Server için isteğe bağlı açıklama
Cache Management API URL	Cache Server’ınızın health check adresi. Örnek: http://cache-http-service.prod.svc.cluster.local:8090

​

Bağlantı Testi

Yapılandırmayı kaydetmeden önce uzak Cache Server’a bağlantıyı test edebilirsiniz. Test şunları doğrular:

• Cache Server’a ağ bağlantısı
• Health check endpoint erişilebilirliği
• API yanıt doğrulaması

Uzak Cache Server Gereksinimleri:

Uzak Cache Server olarak kaydetmeden önce Cache Server pod’unuzun çalıştığından ve erişilebilir olduğundan emin olun. Apinizer yalnızca bağlantı detaylarını kaydedecek, dağıtımı yönetmeyecektir.

​

Cache Server İşlemleri

​

Cache Server Oluşturma

1. Deployment Tipi Seç

   İhtiyaçlarınıza göre Apinizer Tarafından Yönetilen veya Uzak Cache Server arasından seçim yapın.

2. Namespace Yapılandır

   Mevcut bir namespace seçin veya yeni bir tane oluşturun. Namespace’in oluşturulduktan sonra değiştirilemeyeceğini unutmayın.

3. Cache Management API Yapılandır

   API Manager ve Gateway iletişimi için bir veya daha fazla Cache Management API URL’si yapılandırın.

4. Kaynakları Yapılandır (Sadece Yönetilen Mod)

   Yönetilen mod kullanıyorsanız, replica sayısı, CPU, bellek ve ek değişkenleri yapılandırın.

5. Yapılandırmayı Kaydet

   Cache Server yapılandırmasını kaydedin. Yönetilen mod için, Apinizer gerekli Kubernetes kaynaklarını oluşturacaktır.

​

Cache Server Güncelleme

Cache Server yapılandırmasının çeşitli yönlerini güncelleyebilirsiniz:

• Temel Bilgiler: Ad ve açıklama
• Kaynak Yapılandırması: Replica sayısı, CPU, bellek (Sadece yönetilen mod)
• Ek Değişkenler: Ortam değişkenleri ve Java seçenekleri
• Kubernetes Service Yapılandırması: Servis tipi ve ayarları (Sadece yönetilen mod)
• Host Aliases: Host alias eşlemeleri
• Node İsim Listesi: Pod zamanlama tercihleri
• Cache Management API Ayarları: API URL yapılandırmaları

Namespace Değişikliği:

Namespace, Cache Server oluşturulduktan sonra değiştirilemez. Namespace’i değiştirmeniz gerekiyorsa, Cache Server yapılandırmasını silip yeniden oluşturmanız gerekir.

​

Cache Server Silme

Cache Server’ı sildiğinizde:

• Bu Cache Server ile ilgili tüm yapılandırmalar silinecektir
• Yönetilen mod için, Kubernetes kaynakları (deployments, services) kaldırılacaktır
• Silinen Cache Server geri yüklenemez

Dikkat: Silme işlemi tamamlandığında, bu Cache Server’ı kullanan Gateway pod’ları cache’e erişimini kaybedecektir. Cache Server’ı silmeden önce Gateway yapılandırmalarını güncellediğinizden emin olun.

​

Cache Dashboard

Cache Dashboard sayfasından cache içeriklerini görüntüleyebilir, yönetebilir ve silme işlemleri gerçekleştirebilirsiniz. Cache Dashboard sayfasına Cache Server listesinden ilgili Cache Server’ın Cache Monitor butonuna tıklayarak erişebilirsiniz.

​

Cluster Members

Cache Dashboard sayfasının üst kısmında Hazelcast cluster üyelerinin bilgileri görüntülenir. Her cluster member için host ve port bilgileri gösterilir.

​

Kategorize Edilmiş Cache Listesi

Cache’ler kategorilere göre gruplandırılmıştır:

• Response Caching: API Proxy response cache’leri (detaylı tablo: API Proxy Group, API Proxy, Method, Project bilgileri ile)
• Rate Limiting: Rate limiting cache’leri
• Authentication: Kimlik doğrulama cache’leri
• Resilience: Dayanıklılık cache’leri (Circuit Breaker, Retry vb.)
• Generic: Diğer genel cache’ler

Her kategori için:

• Type: Cache tipi
• Description: Cache açıklaması
• Count: Cache içindeki kayıt sayısı
• Size: Cache’in bellek kullanımı (KB)

​

Response Caching Detayları

Response Caching kategorisindeki cache’ler için ek bilgiler görüntülenir:

• API Proxy Group: API Proxy Group adı
• API Proxy: API Proxy adı
• Method: HTTP method
• Project: Proje adı

​

Cache Keys Görüntüleme

Bir cache’e tıklayarak o cache’in key’lerini görüntüleyebilirsiniz:

• Key Listesi: Cache içindeki tüm key’ler listelenir
• Pagination: Key’ler sayfalama ile gösterilir (10, 20, 30 kayıt seçenekleri)
• Key Detayları: Bir key’e tıklayarak cache içeriğini JSON formatında görüntüleyebilirsiniz

​

Cache İşlemleri

Cache Dashboard üzerinden aşağıdaki işlemleri gerçekleştirebilirsiniz:

• View Keys: Cache’in key’lerini görüntüleme
• View Data: Key’e ait cache içeriğini JSON formatında görüntüleme
• Delete Key: Tek bir key’i silme
• Delete All: Tüm cache içeriğini silme

Cache Silme İşlemleri:

Cache silme işlemleri geri alınamaz. Production ortamlarında cache silme işlemlerini dikkatli yapın. Özellikle Rate Limiting ve Authentication cache’lerinin silinmesi, sistem davranışını etkileyebilir.

​

Diagnostics

Cache Server’ın detaylı sistem metriklerine, JVM bilgilerine, thread durumlarına ve Hazelcast cluster bilgilerine erişebilirsiniz. Diagnostics sayfasına Cache Server listesinden ilgili Cache Server’ın Diagnostics butonuna tıklayarak erişebilirsiniz.

Diagnostics özellikleri, kullanımı ve detaylı bilgiler için Environment Diagnostics sayfasına bakın.

​

En İyi Uygulamalar

​

Namespace Yönetimi

• Mümkün olduğunda cache altyapısı için özel namespace’ler kullanın
• Namespace’ler için adlandırma kurallarını takip edin (küçük harf, alfanumerik, tire)
• Cache Server pod’ları için namespace kaynak kotalarını göz önünde bulundurun

​

Yüksek Kullanılabilirlik

• Artıklık için birden fazla Cache Management API URL’si yapılandırın
• Hata toleransı için birden fazla Cache Server pod replica’sı kullanın
• Cache Server pod’larını farklı Kubernetes node’larına dağıtın

​

Performans Optimizasyonu

• Cache boyutu gereksinimlerine göre uygun CPU ve bellek yapılandırın
• Büyük veritabanları için CACHE_LAZY_MODE=lazy kullanın
• İş yükünüze göre Hazelcast parametrelerini ayarlayın
• Kaynak tahsisini optimize etmek için cache metriklerini izleyin

​

Güvenlik

• Dahili iletişim için ClusterIP servisleri kullanın
• Cross-namespace erişim için uygun ağ politikaları yapılandırın
• Mümkün olduğunda cache management API için TLS/HTTPS kullanın
• Cache Server görüntülerini düzenli olarak güncelleyin

Cache mimarisi ve kullanımı hakkında daha fazla bilgi için Önbellek Bileşeni sayfasına bakın.