Mimari

Bu sayfa, Apinizer platformunun teknik mimarisini kapsamlı bir şekilde açıklar. Platformun Kubernetes-native mimari yaklaşımı, temel bileşenleri (API Manager, API Gateway), ortam (Environment) yapısı, dağıtım esnekliği, ölçeklenebilirlik, yüksek erişilebilirlik (HA) ve harici sistem entegrasyonları hakkında detaylı bilgiler içerir.

​

1. Temel Mimari Yaklaşım ve Bileşenler

Apinizer platformu, modern API Management gereksinimlerini karşılamak üzere tasarlanmış, Kubernetes-native, modüler ve dağıtık bir mimariye sahiptir. Platform, Control Plane (API Manager) ve Data Plane (API Gateway) ayrımı ile yüksek performans, ölçeklenebilirlik ve esneklik sağlar.

​

Mimari Tipi

Apinizer, modüler, dağıtık ve yatay ölçeklenebilir (Horizontally Scalable) bir mimariye sahiptir. Bu mimari sayesinde:

• Bağımsız Ölçeklendirme: Bileşenler bağımsız olarak ölçeklendirilebilir. API Gateway’ler API Manager’dan bağımsız olarak ölçeklenebilir.
• Yüksek Performans: Yüksek trafikli ortamlarda performans sorunları yaşanmaz. Local Cache kullanımı ile düşük gecikme sağlanır.
• Kaynak Optimizasyonu: Kaynak kullanımı optimize edilir. Her bileşen için uygun kaynak tahsisi yapılabilir.
• Kesintisiz Çalışma: Sistem kesintisiz çalışabilir. Bileşenlerin çökmesi durumunda otomatik failover mekanizmaları devreye girer.

​

Temel Bileşenler (High-Level)

Apinizer platformu aşağıdaki temel bileşenlerden oluşur:

​

API Manager (Yönetim Konsolu)

API Manager, Apinizer platformunun Control Plane (Yönetim Düzlemi) bileşenidir. Platformun tüm yönetimsel işlemlerinden sorumludur ve API Gateway’lerin konfigürasyonunu yönetir. Mimari Rolü: API Manager, platformun merkezi yönetim bileşenidir. Tüm konfigürasyon değişiklikleri, API tanımlamaları ve sistem ayarları bu bileşen üzerinden yapılır. API Manager’da yapılan değişiklikler, Management API aracılığıyla API Gateway (Worker) bileşenlerine iletilir ve bu bileşenlerin Local Cache’lerine yüklenir. API Gateway ile İlişkisi: API Manager ve API Gateway, modern API Management mimarisindeki Control Plane ve Data Plane ayrımını temsil eder. API Manager, konfigürasyon ve yönetim işlemlerinden sorumluyken; Gateway, gerçek API trafiğinin işlendiği yüksek performanslı bileşendir. Bu ayrım sayesinde Gateway, API Manager’dan bağımsız olarak ölçeklendirilebilir ve yüksek trafikli ortamlarda performans sorunları yaşanmaz.

​

API Gateway

API Gateway, Apinizer platformunun Data Plane (Veri Düzlemi) bileşenidir. Gerçek API trafiğinin işlendiği, yüksek performanslı ve ölçeklenebilir bileşendir. Mimari Rolü: API Gateway, platformun trafik işleme katmanıdır. Tüm API trafiği bu bileşen üzerinden geçer. Gateway bileşenleri, Worker olarak adlandırılır ve her Worker, bağımsız bir pod/container olarak çalışır. Bu mimari sayesinde trafik artışına göre Worker sayısı artırılarak sistem yatay olarak ölçeklendirilebilir. Local Cache ve Bağımsız Çalışma: Her Worker’ın kendi Local Cache’i vardır. Worker başlatıldığında, Management API üzerinden konfigürasyonları MongoDB’den çeker ve Local Cache’e yükler. Bu sayede her API isteği için veritabanına erişim gerekmez ve yüksek performans sağlanır. API Gateway, API Manager’dan bağımsız olarak çalışabilir; API Manager çalışmıyor olsa bile, Worker’lar Local Cache’lerindeki konfigürasyonlarla API trafiğini işlemeye devam eder. Cache mimarisi hakkında daha fazla bilgi için Önbellek Bileşeni sayfasına bakabilirsiniz. Alt Bileşenler: API Gateway içinde Proxy Handler (Policy Enforcement Point), Token Provider API, Db-2-Api, Script2API ve MockAPI gibi alt bileşenler bulunur. Bu bileşenler, farklı türde API isteklerini işlemek ve backend servislere yönlendirmek için kullanılır.

​

Ortam (Environment)

Apinizer Platformu’nda bir Ortam (Environment), API Gateway’lerin (Worker’ların) çalıştığı, kendisine ait bir erişim adresi ve ayarları olan, diğer Ortam’lardan yalıtılmış olarak ve kendisine ayrılmış CPU ve RAM gibi kaynakları kullanarak çalışan sanal sunucu alanıdır. Kubernetes Namespace Karşılığı: Ortam, Kubernetes bağlamında Namespace ifadesine karşılık gelir. Kubernetes kümeleri büyük miktarda bağlantısız iş yüklerini eş zamanlı olarak yönetebilir. Kubernetes, küme içindeki nesnelerin karmaşasını gidermek için Namespace adı verilen bir kavramdan faydalanır. Namespace’ler nesnelerin birbirleriyle gruplanmasına ve bu grupların bir birim olarak filtrelenip kontrol edilmesine olanak sağlar. Ortam Yapısı: Bir Ortam, birden fazla API Gateway (Worker) grubundan oluşur. Her Ortam içinde:

• Worker Pod’ları: API Proxy’lerin çalıştığı pod’lar. Her Worker pod’u bağımsız bir API Gateway instance’ıdır ve kendi Local Cache’ine sahiptir.
• Cache Pod’ları: Dağıtılmış önbellek (Hazelcast) pod’ları. Worker’lar arasında paylaşılan cache verilerini tutar.

Ortam İzolasyonu: Her Ortam, diğer Ortam’lardan tamamen izole edilmiştir:

• Kaynak İzolasyonu: Her Ortam’a ayrılmış CPU ve RAM kaynakları vardır. Bir Ortam’daki kaynak kullanımı diğer Ortam’ları etkilemez.
• Ağ İzolasyonu: Her Ortam’ın kendisine ait erişim adresi ve network ayarları vardır. Farklı Ortam’lar farklı URL’ler üzerinden erişilebilir.
• Konfigürasyon İzolasyonu: Her Ortam’ın kendi konfigürasyon ayarları vardır. API Proxy’ler bir veya birden fazla Ortam’a yüklenebilir ve her Ortam’da farklı konfigürasyonlarla çalışabilir.

Birden Çok Ortam Kullanım Senaryoları: 1. Yaşam Döngüsü Yönetimi: Geliştirme (Development), Test, Üretim (Production) gibi farklı amaca yönelik Ortam’lar oluşturularak API yaşam döngüsü yönetilir:

• Development Ortamı: Geliştirme aşamasındaki API’ler için kullanılır
• Test Ortamı: Test ve QA süreçleri için kullanılır
• Staging Ortamı: Production’a geçmeden önce son kontroller için kullanılır
• Production Ortamı: Canlı sistem için kullanılır

2. Kaynak İzolasyonu: Çok kaynak tüketen API’leri gruplandırarak izole çalışmalarını sağlamak, böylece diğer API’lerin performansının kötü etkilenmesine engel olmak:

• Yüksek trafikli API’ler ayrı bir Ortam’da çalıştırılabilir
• Kritik API’ler için dedicated Ortam’lar oluşturulabilir
• Farklı müşteri veya departmanlar için ayrı Ortam’lar kullanılabilir

3. Coğrafi Dağıtım: Farklı lokasyonlarda farklı Ortam’lar oluşturularak coğrafi dağıtım sağlanabilir:

• Her lokasyonun kendi Ortam’ı olabilir
• Lokasyon bazlı trafik yönlendirmesi yapılabilir
• Lokal veri saklama gereksinimleri karşılanabilir

​

Mimari Düzlem

Apinizer platformu, modern API Management mimarisine uygun olarak Data Plane (Gateway) ve Control Plane (Management) olmak üzere iki ana düzlemden oluşur. API Gateway İstek İşleme Akışı: Yukarıdaki diyagram, API Gateway’in (Worker) bir API isteğini nasıl işlediğini gösterir:

1. Route Matching: Gelen istek Route Matching bileşeni tarafından karşılanır. Path, Host, Method ve Header bilgilerine göre uygun API Proxy bulunur ve MessageContext oluşturulur.
2. Policy Enforcement (Request Pipeline): MessageContext, Request Pipeline’dan geçer ve 4 kategori politikalar sırayla uygulanır:
   • Güvenlik Politikaları
   • Trafik Yönetimi Politikaları
   • Mesaj Doğrulama Politikaları
   • Mesaj Dönüşümü Politikaları
   Mesaj işleme ve politika uygulama hakkında detaylı bilgi için Mesaj İşleme ve Politika Uygulama sayfasına bakabilirsiniz.
3. Routing Decision: Politikalar başarıyla uygulandıktan sonra, RoutingHandlerFactory tarafından uygun handler seçilir. Routing hakkında daha fazla bilgi için ilgili sayfaya bakabilirsiniz.
4. Service Handler: Seçilen handler (Backend API, Db-2-Api, MockAPI, Script2API vb.) isteği işler.
5. Response Pipeline: Backend’den gelen yanıt, Response Pipeline’dan geçer (transformation, encryption, logging vb.).
6. Response: İşlenmiş yanıt istemciye döndürülür.

API Proxy İşleme Akışı: Proxy Handler içinde uygulanan politikalar dört ana kategoride gruplandırılır: Güvenlik, Trafik Yönetimi, Mesaj Doğrulama ve Mesaj Dönüşümü. Bu politikalar Request Pipeline ve Response Pipeline üzerinden sırayla uygulanır. Detaylı bilgi için Mesaj İşleme ve Politika Uygulama sayfasına bakabilirsiniz.

​

Dağıtılmış Önbellek (Distributed Cache)

Apinizer, dağıtılmış önbellekte saklayarak hem bileşenlerinin paylaştığı verileri yönetir, hem de performans iyileştirmesi sağlar.

​

2. Dağıtım Esnekliği ve Çalışma Ortamları

Apinizer, Kubernetes-native bir platformdur ve modern cloud-native mimari prensiplerine uygun olarak tasarlanmıştır. Platform, Java tabanlı olarak geliştirilmiştir ve bu sayede geniş bir uyumluluk ve esneklik sunar.

​

Kubernetes-Native Mimari

Apinizer, Kubernetes ekosistemi üzerine inşa edilmiş bir platformdur. Tüm bileşenleri Kubernetes pod’ları olarak çalışır ve Kubernetes’in yerel özelliklerinden (deployment, service, configmap, secret vb.) tam olarak yararlanır. Bu mimari yaklaşım sayesinde:

• Standart Kubernetes API’leri: Kubernetes’in standart API’leri ve kaynakları kullanılır
• Native Ölçeklendirme: Kubernetes Horizontal Pod Autoscaler (HPA) ve Vertical Pod Autoscaler (VPA) ile otomatik ölçeklendirme
• Service Discovery: Kubernetes Service Discovery mekanizması ile bileşenler arası iletişim
• ConfigMap ve Secret Yönetimi: Konfigürasyon ve hassas veriler Kubernetes native kaynakları ile yönetilir
• Health Checks: Kubernetes liveness ve readiness probe’ları ile sağlık kontrolü
• Resource Management: CPU ve bellek kaynakları Kubernetes limit ve request mekanizmaları ile yönetilir

​

Desteklenen Kubernetes Platformları

Apinizer, Kubernetes standardını destekleyen tüm platformlarda sorunsuz çalışır. Bu platformlar şunları içerir: Kurumsal Kubernetes Platformları:

• Kubernetes: Standart Kubernetes cluster’ları (herhangi bir dağıtım)
• Red Hat OpenShift: OpenShift 3.11 ve üzeri tüm versiyonlar
• VMware Tanzu: Tanzu Kubernetes Grid ve Tanzu Application Platform
• Rancher Kubernetes Engine (RKE2): Rancher tarafından yönetilen Kubernetes cluster’ları

Public Cloud Kubernetes Servisleri: Apinizer, major public cloud sağlayıcılarının yönetilen Kubernetes servislerinde kolayca konumlandırılabilir:

• Amazon EKS (Elastic Kubernetes Service): AWS bulut altyapısında tam destek
• Microsoft AKS (Azure Kubernetes Service): Azure bulut altyapısında tam destek
• Google GKE (Google Kubernetes Engine): Google Cloud Platform’da tam destek

Bu cloud servislerinde Apinizer’ı konumlandırmak için standart Kubernetes deployment yöntemleri kullanılır. Cloud sağlayıcılarının yönetilen Kubernetes servisleri sayesinde, altyapı yönetimi yükü azalır ve platformun kurulumu ve yönetimi daha da kolaylaşır.

​

Platform Bağımsızlığı

Apinizer’ın Java tabanlı olması ve Kubernetes-native mimarisi sayesinde, Kubernetes’in çalıştığı her ortamda sorunsuz çalışır. Bu durum şu avantajları sağlar:

• İşletim Sistemi Bağımsızlığı: Kubernetes’in desteklediği tüm işletim sistemlerinde çalışır (Linux, Windows Server vb.)
• Altyapı Bağımsızlığı: Fiziksel sunucular, sanal makineler (VMware, Hyper-V, KVM), veya cloud ortamlarında çalışabilir
• Cloud Provider Bağımsızlığı: Herhangi bir cloud sağlayıcısında veya on-premise ortamda çalışabilir
• Kubernetes Dağıtımı Bağımsızlığı: Standart Kubernetes, OpenShift, Tanzu gibi farklı Kubernetes dağıtımlarında çalışır

​

Rootless Container Desteği

Apinizer container imajları rootless (root kullanıcısı olmadan) olarak sağlanır. Bu özellik sayesinde:

• Güvenlik: Container’lar root kullanıcısı olmadan çalışır, güvenlik riskleri azalır
• Uyumluluk: Tüm container orchestration platformlarında çalışabilir
• Compliance: Güvenlik standartlarına ve compliance gereksinimlerine daha iyi uyum sağlar
• Esneklik: Kısıtlamalı ortamlarda bile çalışabilir

​

DMZ ve LAN Ayrımı

Apinizer platformu, kurumsal güvenlik mimarisine uygun olarak DMZ (Demilitarized Zone) ve LAN (Local Area Network) bölgelerinde farklı bileşenlerin çalışmasını destekler. Bu mimari yaklaşım, güvenlik duvarları ve ağ segmentasyonu ile uyumlu çalışarak hassas bileşenlerin korunmasını ve güvenli API erişiminin sağlanmasını mümkün kılar. Mimari Prensipler: Apinizer’ın API Gateway bileşenleri, API Manager’dan bağımsız çalışabildiği için, güvenlik ve performans gereksinimlerine göre farklı ağ bölgelerinde ve hatta farklı lokasyonlarda konumlandırılabilir. Bu esneklik sayesinde:

• Gateway’ler DMZ’de, API Manager LAN’da konumlandırılabilir
• Gateway’ler coğrafi olarak dağıtık lokasyonlarda çalıştırılabilir
• Her lokasyondaki Gateway’ler kendi Local Cache’lerine sahiptir
• API Manager’a sadece konfigürasyon değişiklikleri için ihtiyaç duyulur

DMZ Bölgesi - Dış Erişim Katmanı: DMZ, internet ve dış ağlardan gelen trafiğin karşılandığı güvenli ara bölgedir. Bu bölgede şu Apinizer bileşenleri çalışır:

• API Gateway (Worker) Modülleri: İstemcilerden ve dış kurumlardan gelen API isteklerini karşılayan Proxy Handler’lar. Bu gateway’ler:
  • Dış istemcilerden gelen trafiği işler
  • TLS/SSL sonlandırması yapar
  • Kimlik doğrulama ve yetkilendirme politikalarını uygular
  • Rate limiting ve throttling işlemlerini gerçekleştirir
  • Backend servislere yönlendirme yapar
  • Local Cache’lerinde konfigürasyonları tutar
• API Portal: Dış geliştiriciler ve partner kurumlar için API keşif ve dokümantasyon portalı. Portal, DMZ’de konumlandırılarak dış erişime açılır.
• Load Balancer: Trafik dağıtımı ve yük dengeleme işlemlerini gerçekleştirir. Dış trafik önce Load Balancer’a gelir, ardından Gateway pod’larına dağıtılır.

DMZ’den LAN’a İletişim: DMZ’deki Gateway’ler, çalışmaları için LAN’daki bazı servislere bağlanır:

• MongoDB Cluster: Konfigürasyon verilerini almak için (başlangıçta ve konfigürasyon değişikliklerinde)
• Logging Servisleri: API trafik log’larını göndermek için (Elasticsearch, Kafka vb.)
• Kubernetes Control Plane: Pod yönetimi ve servis keşfi için

Bu bağlantılar güvenlik duvarları üzerinden kontrollü bir şekilde yapılır ve sadece gerekli portlar açılır. LAN Bölgesi - İç Yönetim Katmanı: LAN, kurum içi ağ bölgesidir ve hassas yönetim bileşenleri burada konumlandırılır:

• API Manager Modülü: Platformun merkezi yönetim bileşeni. Bu bileşen:
  • Web tabanlı yönetim konsolu sağlar
  • API Proxy tanımlamaları ve konfigürasyonları yönetir
  • Kullanıcı ve rol yönetimi yapar
  • Monitoring ve analytics işlemlerini gerçekleştirir
  • Konfigürasyon değişikliklerini Gateway’lere iletir
• MongoDB Cluster: Tüm konfigürasyon ve metadata verilerinin saklandığı merkezi veritabanı. Gateway’ler başlangıçta ve konfigürasyon değişikliklerinde bu veritabanından veri çeker.
• Elasticsearch Cluster: API trafik log’larının ve analitik verilerin saklandığı log yönetim sistemi. API Manager’ın Analytics özellikleri bu verileri kullanır.
• Kafka Cluster: Yüksek hacimli log akışı için kullanılan mesajlaşma platformu (opsiyonel).
• Dağıtılmış Cache (Hazelcast): Quota, throttling, OAuth2 token gibi paylaşılan verilerin tutulduğu cache sistemi. Cache Server’lar Gateway pod’larından bağımsız namespace’lerde çalışabilir ve Kubernetes service discovery ile erişilebilir.
• İç Gateway’ler: Kurum içi API trafiği için kullanılan Gateway’ler (opsiyonel). Bu gateway’ler LAN içindeki servisler arası iletişimi yönetir.

Güvenlik ve Ağ Segmentasyonu: Bu mimari yaklaşım şu güvenlik avantajlarını sağlar:

• Ağ İzolasyonu: Hassas yönetim bileşenleri (API Manager, MongoDB) dış ağlardan izole edilir
• Kontrollü Erişim: DMZ’den LAN’a sadece gerekli bağlantılar açılır ve güvenlik duvarları ile kontrol edilir
• Saldırı Yüzeyinin Azaltılması: Dış erişime açık olan sadece Gateway’ler ve Portal’dır
• Defense in Depth: Çok katmanlı güvenlik yaklaşımı ile koruma sağlanır

Coğrafi Dağıtım ve Lokasyon Bağımsızlığı: API Gateway’lerin API Manager’dan bağımsız çalışabilmesi sayesinde, Gateway’ler farklı lokasyonlarda ve hatta farklı coğrafi bölgelerde konumlandırılabilir:

• Edge Lokasyonlar: Kullanıcılara yakın lokasyonlarda Gateway’ler konumlandırılabilir (düşük gecikme)
• Bölgesel Dağıtım: Farklı ülkeler veya bölgelerde Gateway’ler çalıştırılabilir
• Hybrid Cloud: Gateway’ler hem on-premise hem de cloud ortamlarında çalışabilir
• Multi-Cloud: Farklı cloud sağlayıcılarında Gateway’ler konumlandırılabilir

Her lokasyondaki Gateway’ler:

• Kendi Local Cache’lerine sahiptir ve konfigürasyonları burada tutar
• API Manager’a sadece konfigürasyon güncellemeleri için bağlanır
• Rutin API trafiği işleme sırasında API Manager’a bağımlı değildir
• Lokal MongoDB replikasından veya merkezi MongoDB’den konfigürasyon alabilir

​

3. Ölçeklenebilirlik ve Yüksek Erişilebilirlik (HA)

Apinizer platformu, yüksek trafikli ve kritik iş uygulamaları için gerekli olan ölçeklenebilirlik ve yüksek erişilebilirlik özelliklerini sağlar. API Gateway’in kesintisiz çalışma ve performans gereksinimlerini karşılamak üzere tasarlanmıştır.

​

Yatay Ölçekleme

Apinizer platformu, tüm bileşenlerinin ihtiyaca göre yatay olarak ölçeklendirilmesini destekler. Bu sayede trafik artışına göre sistem kapasitesi artırılabilir ve kaynak kullanımı optimize edilir. API Gateway (Worker) Ölçeklendirme: API Gateway bileşenleri, trafik artışına göre kolayca ölçeklendirilebilir:

• Manuel Ölçeklendirme: Trafik artışına göre Worker sayısı manuel olarak artırılabilir. Kubernetes deployment replica sayısı artırılarak yeni Worker pod’ları oluşturulur.
• Otomatik Ölçeklendirme (HPA): Kubernetes Horizontal Pod Autoscaler (HPA) kullanılarak CPU ve bellek kullanımına göre otomatik ölçeklendirme yapılabilir. HPA, belirlenen eşik değerlerini aştığında yeni pod’lar oluşturur, kullanım düştüğünde pod’ları kaldırır.
• Yüksek Erişilebilirlik: Her ortamda birden fazla Worker ile yüksek erişilebilirlik sağlanır. Tek bir Worker’ın çökmesi durumunda diğer Worker’lar trafiği işlemeye devam eder.
• Lokasyon Bazlı Ölçeklendirme: Farklı lokasyonlardaki Gateway’ler bağımsız olarak ölçeklendirilebilir. Her lokasyonun kendi trafik gereksinimlerine göre Worker sayısı ayarlanabilir.

API Manager Ölçeklendirme: API Manager bileşeni de yatay olarak ölçeklendirilebilir:

• Yönetim Yükü Dağıtımı: Yüksek yönetim trafiği olan ortamlarda API Manager pod’ları çoğaltılabilir
• Load Balancing: API Manager pod’ları arasında yük dengeleme yapılır

Cache Ölçeklendirme: Dağıtılmış cache sistemi (Hazelcast) dinamik olarak ölçeklendirilebilir:

• Dinamik Cluster Genişletme: Hazelcast cluster’ına yeni node’lar eklenebilir, mevcut node’lar kaldırılabilir
• Otomatik Veri Dağıtımı: Yeni node eklendiğinde veriler otomatik olarak yeniden dağıtılır
• Replikasyon: Veriler birden fazla node’da replike edilir, tek node çökmesi durumunda veri kaybı olmaz
• Partition Yönetimi: Veriler partition’lara ayrılır ve farklı node’larda tutulur
• Namespace Bağımsızlığı: Cache Server’lar Gateway pod’larından bağımsız namespace’lerde çalışabilir ve bağımsız olarak ölçeklendirilebilir

Database Ölçeklendirme: Veritabanı bileşenleri de ölçeklendirilebilir:

• MongoDB Replica Set: MongoDB replica set ile okuma performansı artırılabilir. Okuma işlemleri secondary node’lara dağıtılabilir.
• MongoDB Sharding: Sharding ile yatay ölçeklendirme yapılabilir. Veriler farklı shard’lara dağıtılır.
• Elasticsearch Cluster Genişletme: Elasticsearch cluster’ına yeni node’lar eklenerek kapasite artırılabilir. Index’ler farklı node’lara dağıtılır.

​

Gateway Bağımsızlığı

API Gateway bileşenleri, API Manager’dan bağımsız olarak çalışabilir ve ölçeklendirilebilir. Bu mimari özellik, yüksek trafikli ortamlarda kritik öneme sahiptir. Bağımsız Çalışma:

• Local Cache: Her Worker kendi Local Cache’ine sahiptir ve konfigürasyonları burada tutar. Bu sayede her API isteği için veritabanına erişim gerekmez.
• Konfigürasyon Bağımsızlığı: Worker’lar başlangıçta konfigürasyonları MongoDB’den alır ve Local Cache’e yükler. Konfigürasyon değişiklikleri Management API üzerinden otomatik olarak Worker’lara iletilir.
• Rutin Trafik İşleme: API Manager çalışmıyor olsa bile, Worker’lar Local Cache’lerindeki konfigürasyonlarla API trafiğini işlemeye devam eder. Sadece yeni konfigürasyon değişiklikleri için API Manager’a ihtiyaç duyulur.

Bağımsız Ölçeklendirme:

• API Manager Tek Instance: API Manager modülü tek instance olarak çalışabilir. Yönetim trafiği genellikle API trafiğinden çok daha düşüktür.
• Worker Çoklu Instance: Worker modülleri trafik gereksinimine göre bağımsız olarak ölçeklenebilir. Yüksek trafikli ortamlarda yüzlerce Worker çalıştırılabilir.
• Lokasyon Bağımsızlığı: Gateway’ler farklı lokasyonlarda, farklı Kubernetes cluster’larında çalıştırılabilir. Her lokasyonun kendi Worker’ları ve Local Cache’leri vardır.
• Kaynak Optimizasyonu: Worker’lar için yüksek CPU ve bellek, API Manager için daha düşük kaynaklar tahsis edilebilir.

​

Yüksek Erişilebilirlik (HA)

Apinizer platformu, Kubernetes Yüksek Erişilebilirlik Kümesi (HA Cluster) üzerinde çalıştırılarak kesintisiz hizmet sunma yeteneği sağlar. Sistem bileşenlerinin çökmesi durumunda bile hizmet kesintisiz devam eder. HA Mimarisi:

• Kubernetes HA Cluster: Platform, en az 3 Master Node ile yüksek erişilebilirlik sağlayan Kubernetes cluster’larında çalışır. Master Node’lardan biri çökse bile cluster çalışmaya devam eder.
• Load Balancer VIP: Tüm erişimler Load Balancer VIP üzerinden yapılır. Load Balancer, sağlıklı pod’lara trafik yönlendirir.
• Pod Anti-Affinity: Pod’lar farklı node’lara dağıtılır. Pod anti-affinity kuralları ile aynı node’da birden fazla pod çalışması engellenir.
• Health Check ve Readiness Probe: Kubernetes liveness ve readiness probe’ları ile pod’ların sağlık durumu sürekli kontrol edilir. Sağlıksız pod’lar otomatik olarak yeniden başlatılır veya trafikten çıkarılır.

HA Özellikleri:

• API Manager Redundancy: API Manager modülü için yedekleme stratejileri uygulanır. Birden fazla API Manager pod’u çalıştırılabilir ve aralarında yük dengeleme yapılır. API Manager pod’u çökse bile, Gateway’ler Local Cache’lerindeki konfigürasyonlarla çalışmaya devam eder.
• Worker Redundancy: Her ortamda birden fazla Worker ile yüksek erişilebilirlik sağlanır. Worker’lar farklı node’lara dağıtılır ve tek bir Worker’ın çökmesi durumunda diğer Worker’lar trafiği işlemeye devam eder. Load Balancer sağlıklı Worker’lara trafik yönlendirir.
• Database Replication: MongoDB replica set ile veri güvenliği sağlanır. Veriler birden fazla node’da replike edilir. Primary node çökse bile, otomatik olarak secondary node’lardan biri primary olur ve veri kaybı olmaz.
• Cache Replication: Hazelcast’in built-in replication özellikleri ile cache verileri birden fazla node’da tutulur. Tek bir cache node’unun çökmesi durumunda veriler diğer node’lardan erişilebilir.
• Elasticsearch Replication: Elasticsearch index’leri birden fazla node’da replike edilir. Tek node çökmesi durumunda veriler diğer node’lardan erişilebilir.
• Automatic Failover: Otomatik yedekleme ve geçiş mekanizmaları ile sistem bileşenlerinin çökmesi durumunda otomatik olarak yedek bileşenlere geçiş yapılır. Bu geçiş kullanıcılar için şeffaftır ve hizmet kesintisi olmaz.

Kubernetes HA Cluster Özellikleri:

• En Az 3 Master Node: Kubernetes control plane için en az 3 master node ile yüksek erişilebilirlik sağlanır. Master node’lardan biri çökse bile cluster çalışmaya devam eder.
• Load Balancer VIP Erişimi: Tüm erişimler Load Balancer VIP üzerinden yapılır. Load Balancer, sağlıklı pod’lara trafik yönlendirir ve çökme durumunda otomatik olarak yedek pod’lara geçiş yapar.
• Pod Anti-Affinity Kuralları: Pod’lar farklı node’lara dağıtılır. Bu sayede tek bir node’un çökmesi durumunda bile hizmet devam eder.
• Health Check ve Readiness Probe’ları: Kubernetes liveness ve readiness probe’ları ile pod’ların sağlık durumu sürekli kontrol edilir. Sağlıksız pod’lar otomatik olarak yeniden başlatılır veya trafikten çıkarılır.
• Node Failure Tolerance: Worker node’lardan biri veya birkaçı çökse bile, diğer node’lardaki pod’lar hizmet vermeye devam eder. Kubernetes otomatik olarak çöken node’lardaki pod’ları diğer sağlıklı node’larda yeniden oluşturur.

Coğrafi Yüksek Erişilebilirlik:

• Multi-Region Deployment: Gateway’ler farklı coğrafi bölgelerde konumlandırılabilir. Bir bölgede sorun olsa bile diğer bölgelerdeki Gateway’ler hizmet vermeye devam eder.
• Active-Active Configuration: Farklı lokasyonlardaki Gateway’ler aktif-aktif modda çalışabilir. Trafik tüm lokasyonlara dağıtılır ve bir lokasyon çökse bile diğer lokasyonlar hizmet vermeye devam eder.
• DNS-Based Failover: DNS tabanlı failover mekanizmaları ile bir lokasyon çökse bile trafik otomatik olarak diğer lokasyonlara yönlendirilir.

​

4. Harici Sistem Bağlantıları

Apinizer platformu, mevcut IT altyapınızla entegre çalışabilmek için geniş bir entegrasyon yelpazesi sunar. Platform, kimlik doğrulama sistemleri, log yönetim sistemleri, mesajlaşma platformları, veritabanları ve çeşitli harici servislerle entegrasyon yapabilir.

​

Kimlik Doğrulama Entegrasyonları

Apinizer, kurumsal kimlik doğrulama sistemleriyle entegre çalışarak güvenli API erişimi sağlar:

• LDAP/Active Directory: Kurumsal LDAP ve Active Directory sistemleri ile kullanıcı kimlik doğrulama. Kullanıcı bilgileri ve grup üyelikleri LDAP/AD’den alınır ve API erişim kontrolü için kullanılır.
• OAuth2 Sağlayıcılar: Popüler OAuth2 sağlayıcıları ile entegrasyon:
  • Google OAuth2
  • Microsoft Azure AD
  • Okta
  • Diğer OAuth2 uyumlu kimlik sağlayıcıları
• OIDC (OpenID Connect): OAuth2’nin üzerine inşa edilmiş kimlik katmanı. OIDC, kimlik doğrulama ve kullanıcı bilgisi almak için standart bir protokol sağlar. ID token’ları ve user info endpoint’leri ile kullanıcı kimlik bilgileri alınabilir. OIDC uyumlu kimlik sağlayıcıları ile entegrasyon yapılabilir.
• SAML (Security Assertion Markup Language): Single Sign-On (SSO) desteği ile kullanıcıların tek bir kimlik bilgisi ile tüm sistemlere erişmesini sağlar. SAML 2.0 protokolü desteklenir.
• JWT (JSON Web Token): Token tabanlı kimlik doğrulama. JWT token’ları oluşturulur, doğrulanır ve yenilenir. Custom claim’ler ve token imzalama algoritmaları desteklenir.

​

Log ve Monitoring Entegrasyonları

API trafik log’ları ve sistem metrikleri, merkezi log yönetim ve monitoring sistemlerine entegre edilebilir. Apinizer, API Creator ve API Integrator modülleri aracılığıyla aşağıdaki log ve monitoring sistemleri ile entegrasyon yapabilir: Merkezi Log Yönetim Sistemleri:

• Elasticsearch: Merkezi log yönetimi için Elasticsearch cluster’ına log gönderimi. API Manager’ın Analytics özellikleri için gerekli olmakla birlikte, harici Elasticsearch sistemlerine de log gönderilebilir. Index yönetimi ve lifecycle politikaları desteklenir.
• Graylog: Graylog log yönetim sistemine entegrasyon. Graylog GELF (Graylog Extended Log Format) protokolü ile log gönderimi yapılabilir. Centralized log aggregation ve analysis için kullanılır.
• Splunk: Splunk log analizi ve raporlama sistemine log gönderimi. Splunk Universal Forwarder veya HTTP Event Collector (HEC) üzerinden entegrasyon yapılabilir. Splunk index’lerine log kayıtları gönderilir.
• Logback: Logback logging framework’üne log gönderimi. Logback appender’ları kullanılarak log’lar farklı hedeflere (dosya, veritabanı, network vb.) gönderilebilir.
• Syslog: Syslog protokolü ile log sunucularına gönderim. RFC 3164 ve RFC 5424 standartları desteklenir. UDP ve TCP protokolleri ile syslog server’lara log gönderilebilir.

Mesajlaşma ve Streaming Platformları:

• Apache Kafka: Yüksek hacimli log akışı için Kafka topic’lerine log gönderimi. Kafka producer API kullanılarak log’lar asenkron olarak Kafka’ya gönderilir. Partition stratejileri ve compression desteği sağlanır.
• RabbitMQ: Mesaj kuyruğu yönetimi için RabbitMQ entegrasyonu. Exchange ve queue yapılandırmaları ile log mesajları routing yapılabilir.
• ActiveMQ: Apache ActiveMQ mesajlaşma platformuna log gönderimi. JMS (Java Message Service) protokolü ile log mesajları gönderilebilir.

Monitoring ve Metrik Sistemleri:

• Prometheus: Metrik toplama ve izleme için Prometheus formatında metrikler export edilir. Prometheus scrape endpoint’leri sağlanır ve custom metrikler tanımlanabilir. Counter, Gauge, Histogram ve Summary metrik tipleri desteklenir.
• Grafana: Görselleştirme ve dashboard’lar için Grafana entegrasyonu. Prometheus veya Elasticsearch veri kaynaklarından veri çekilerek dashboard’lar oluşturulabilir. Custom panel’ler ve alerting kuralları tanımlanabilir.

Event-Driven Entegrasyonlar:

• Webhook: Olay tabanlı bildirimler için HTTP/HTTPS webhook endpoint’lerine POST istekleri gönderilir. Custom header’lar ve payload formatları desteklenir. Retry mekanizmaları ve timeout ayarları yapılabilir. Log olayları ve sistem event’leri webhook’lar aracılığıyla harici sistemlere bildirilebilir.

​

Mesajlaşma Entegrasyonları

Yüksek hacimli log akışı ve olay tabanlı bildirimler için mesajlaşma platformları ile entegrasyon:

• Apache Kafka: Yüksek hacimli log akışı için Kafka topic’lerine log gönderimi. Kafka producer API kullanılarak log’lar asenkron olarak Kafka’ya gönderilir. Partition stratejileri ve compression desteği sağlanır.
• RabbitMQ: Mesaj kuyruğu yönetimi için RabbitMQ entegrasyonu. Exchange ve queue yapılandırmaları ile mesaj routing yapılabilir.
• Apache ActiveMQ: Apache ActiveMQ mesajlaşma platformuna entegrasyon. JMS (Java Message Service) protokolü ile mesaj gönderimi ve alımı yapılabilir. Topic ve Queue destination’ları desteklenir.
• Webhook: Olay tabanlı bildirimler için HTTP/HTTPS webhook endpoint’lerine POST istekleri gönderilir. Custom header’lar ve payload formatları desteklenir. Retry mekanizmaları ve timeout ayarları yapılabilir.

​

API Integrator Konnektörleri

API Integrator modülü, çeşitli harici sistemlerle entegrasyon yapmak için geniş bir konnektör yelpazesi sunar. Bu konnektörler sayesinde API’ler oluşturulabilir, veritabanlarına erişilebilir ve çeşitli aksiyonlar gerçekleştirilebilir. Veritabanı Konnektörleri: API Creator ve API Integrator modülleri, aşağıdaki veritabanları ile entegrasyon yapabilir. Veritabanı bağlantıları ve konnektörler hakkında detaylı bilgi için ilgili sayfalara bakabilirsiniz. İlişkisel Veritabanları:

• Oracle Database: Oracle DB bağlantıları, SQL sorguları ve Stored Procedure çalıştırma
• MySQL: MySQL ve MariaDB veritabanlarına bağlantı ve sorgu işlemleri
• PostgreSQL: PostgreSQL veritabanı entegrasyonu ve advanced özellikler
• SQL Server: Microsoft SQL Server bağlantıları ve T-SQL sorguları
• IBM Db2: IBM Db2 veritabanı entegrasyonu
• SAP Sybase: SAP Sybase veritabanı bağlantıları

NoSQL ve Big Data Veritabanları:

• MongoDB: MongoDB document database entegrasyonu, collection sorguları ve aggregation işlemleri
• Apache Hive: Hadoop Hive entegrasyonu ile büyük veri sorguları
• Apache Impala: Yüksek performanslı SQL sorguları için Impala entegrasyonu
• Trino (PrestoSQL): Distributed SQL query engine entegrasyonu, çoklu veri kaynağı sorguları

Aksiyon Konnektörleri: API Integrator, çeşitli aksiyonlar gerçekleştirmek için aşağıdaki konnektörleri sağlar:

• API Call: REST ve SOAP API’lerine çağrı yapma. HTTP/HTTPS istekleri, authentication (Basic, OAuth2, API Key), request/response transformation ve error handling desteği.
• Database: Veritabanı işlemleri gerçekleştirme. SQL sorguları çalıştırma, Stored Procedure çağırma, transaction yönetimi ve connection pooling.
• Email (SMTP): E-posta gönderme. SMTP sunucularına bağlanarak e-posta gönderimi, HTML ve plain text format desteği, attachment ekleme.
• Notification: Bildirim gönderme. PagerDuty, Opsgenie gibi incident management sistemlerine bildirim gönderme, custom notification servislerine entegrasyon.
• Linux Script: Linux sunucularında script çalıştırma. SSH üzerinden remote script execution, shell script ve command execution.
• Script: JavaScript veya Groovy script’leri çalıştırma. Custom iş mantığı implementasyonu, veri dönüşümü ve hesaplamalar.
• SNMP: Simple Network Management Protocol işlemleri. SNMP trap gönderme, SNMP GET/SET işlemleri, network device monitoring.

Entegrasyon Senaryoları: Bu konnektörler sayesinde şu gibi entegrasyon senaryoları gerçekleştirilebilir:

• Veritabanı API’leri: Mevcut veritabanlarınızı RESTful API’lere dönüştürme
• Veri Senkronizasyonu: Farklı sistemler arasında veri senkronizasyonu
• Event-Driven İşlemler: Olay tabanlı tetiklemeler ve aksiyonlar
• Bildirim Sistemleri: Alarm ve olay durumlarında otomatik bildirimler
• Veri Dönüşümü: Farklı formatlar arasında veri dönüşümü ve mapping
• Orkestrasyon: Birden fazla sistemin koordineli çalışması

​

5. Veri ve Log Katmanı

Apinizer Platformu’nda veri ve log katmanı, sistemin veri saklama ve loglama ihtiyaçlarını karşılar. Bu katman, konfigürasyon verileri, API trafiği logları, analitik veriler ve diğer sistem verilerinin saklanması ve yönetilmesinden sorumludur. Platform, konfigürasyon verileri ve log verileri için ayrı veritabanları kullanarak performans, güvenlik ve ölçeklenebilirlik sağlar.

​

Konfigürasyon Veritabanı (Metadata)

Apinizer platformunun tüm konfigürasyon ve meta verilerinin tutulduğu merkezi bileşendir. Platform üzerinde yapılan her türlü yapılandırma, ayar ve tanımlama bu veritabanında saklanır. Apinizer, MongoDB ve PostgreSQL gibi popüler veritabanlarını destekler. Veritabanı bağlantıları hakkında detaylı bilgi için Bağlantılar sayfasına bakabilirsiniz. Mimari Rolü: Veritabanı, Apinizer’ın “hafızası” görevini üstlenir. API Manager üzerinden yapılan tüm değişiklikler burada saklanır ve API Gateway bileşenleri (Worker’lar) konfigürasyonları buradan alarak kendi Local Cache’lerine yükler. Bu mimari sayesinde konfigürasyonlar merkezi olarak yönetilir ve tüm Worker’lar aynı konfigürasyonlarla çalışır. MongoDB Kullanımı: MongoDB, Apinizer platformunun tüm konfigürasyon verilerini ve metadata’yı saklamak için kullanılır. Platform üzerinde tanımlanan ve yapılandırılan her şey bu veritabanında tutulur: Veritabanı Gereksinimleri:

• Replica Set Yapılandırması: MongoDB’nin Replica Set yapılandırması ile çalışması zorunludur (tek node dahi olsa Replica Set olarak yapılandırılmalıdır)
• Standalone Instance: Standalone Instance kullanılmamalıdır
• Yüksek Erişilebilirlik: Yüksek erişilebilirlik için en az 3 node önerilir
• Veri Güvenliği: Replica Set sayesinde veri replikasyonu ve otomatik failover sağlanır

​

Analitik Depolama ve Log Yönetimi

API trafik kayıtlarının saklanması ve yönetimi için Apinizer, esnek bir log yönetim mimarisi sunar. API Manager üzerinden API Trafiklerini izlemek ve raporlamak istiyorsanız Elasticsearch gereklidir. Bunun yanı sıra, connector’ler aracılığıyla API Trafik kayıtları asenkron olarak birden fazla farklı hedefe gönderilebilir. Elasticsearch - API Manager Entegrasyonu: API Manager üzerinden API Trafiklerini izlemek, analiz etmek ve raporlamak için Elasticsearch kullanılır. Elasticsearch, API Manager’ın Analytics ve Monitoring özelliklerinin çalışması için zorunludur. Analytics Engine hakkında detaylı bilgi için Analytics Engine sayfasına bakabilirsiniz. Elasticsearch’te Tutulan Veriler: Elasticsearch Gereksinimleri:

• Index Lifecycle Management (ILM): Log verilerinin yaşam döngüsü yönetimi için ILM politikaları kullanılır
• Yedekleme ve Snapshot: Düzenli snapshot’lar alınarak veri güvenliği sağlanır
• Kapasite Planlama: Log verilerinin büyümesine göre kapasite planlaması yapılır ve ölçeklendirme yapılır

Connector’ler ile Asenkron Log Gönderimi: Elasticsearch’e ek olarak, API Trafik kayıtları connector’ler aracılığıyla asenkron olarak birden fazla farklı hedefe gönderilebilir. Bu sayede log verilerinizi merkezi log yönetim sistemlerinize, mesajlaşma platformlarınıza veya veritabanlarınıza aktarabilirsiniz. Desteklenen Connector’ler:

• ActiveMQ: Apache ActiveMQ mesajlaşma platformuna log gönderimi
• Database: Veritabanlarına (Oracle, PostgreSQL, MySQL vb.) log kayıtlarının yazılması
• Elasticsearch: Elasticsearch cluster’ına log gönderimi (API Manager entegrasyonu için gerekli)
• Graylog: Graylog log yönetim sistemine log gönderimi
• Kafka: Apache Kafka mesajlaşma platformuna yüksek hacimli log akışı
• Logback: Logback logging framework’üne log gönderimi
• RabbitMQ: RabbitMQ mesaj kuyruğu sistemine log gönderimi
• Syslog: Syslog protokolü ile log sunucularına gönderim
• Webhook: HTTP/HTTPS webhook endpoint’lerine log gönderimi

Bu connector’ler sayesinde API Trafik kayıtlarınızı mevcut log yönetim altyapınıza entegre edebilir, merkezi log toplama sistemlerinize aktarabilir veya gerçek zamanlı analiz için mesajlaşma platformlarınıza gönderebilirsiniz.

​

Neden Ayrı Veritabanları?

Apinizer, konfigürasyon verileri ve log verileri için ayrı veritabanları kullanır. Bu mimari yaklaşım şu avantajları sağlar: Performans Optimizasyonu:

• Ayrı Ölçeklendirme: Konfigürasyon ve log verileri farklı performans gereksinimlerine sahiptir. Her veritabanı kendi gereksinimlerine göre ölçeklendirilebilir.
• Özel Optimizasyonlar: Her veritabanı kendi kullanım senaryosuna göre optimize edilebilir. MongoDB konfigürasyon verileri için optimize edilirken, Elasticsearch log ve analitik veriler için optimize edilir.
• Kaynak İzolasyonu: Yüksek trafikli log yazma işlemleri konfigürasyon okuma/yazma işlemlerini etkilemez. Bu sayede API Manager’ın performansı korunur.

Güvenlik ve Erişim Kontrolü:

• Ayrı Erişim Politikaları: Log verilerine erişim daha kısıtlı tutulabilir. Konfigürasyon veritabanına sadece API Manager erişirken, log veritabanına farklı sistemler erişebilir.
• Veri Maskeleme: Hassas verilerin log’larda maskelenmesi için özel işlemler yapılabilir. Konfigürasyon veritabanında hassas bilgiler şifrelenmiş olarak tutulur.
• Compliance: Farklı veri türleri için farklı compliance gereksinimleri karşılanabilir. Log verileri için retention politikaları, konfigürasyon verileri için backup stratejileri uygulanabilir.

Ölçeklenebilirlik:

• Horizontal Scaling: Her veritabanı bağımsız olarak ölçeklendirilebilir. Log verilerinin büyümesi konfigürasyon veritabanını etkilemez.
• Kapasite Yönetimi: Log verilerinin büyümesi konfigürasyon veritabanını etkilemez. Her veritabanı için ayrı kapasite planlaması yapılabilir.
• Maliyet Optimizasyonu: Her veritabanı için uygun kaynak tahsisi yapılabilir. Konfigürasyon veritabanı için daha az kaynak, log veritabanı için daha fazla kaynak tahsis edilebilir.