Dağıtık Cache
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:8090http://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
İhtiyaçlarınıza göre Apinizer Tarafından Yönetilen veya Uzak Cache Server arasından seçim yapın.
Mevcut bir namespace seçin veya yeni bir tane oluşturun. Namespace'in oluşturulduktan sonra değiştirilemeyeceğini unutmayın.
API Manager ve Gateway iletişimi için bir veya daha fazla Cache Management API URL'si yapılandırın.
Yönetilen mod kullanıyorsanız, replica sayısı, CPU, bellek ve ek değişkenleri yapılandırın.
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=lazykullanı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.