API Gateway Nedir? Mikroservisler İçin 7 Güçlü Görev

API Gateway, mobil uygulama, internet sitesi ve diğer istemcilerden gelen API isteklerini karşılayan, doğrulayan ve uygun arka uç servisine yönlendiren merkezi giriş katmanıdır.

Monolitik bir uygulamada istemci genellikle tek bir sunucu adresiyle iletişim kurar. Mikroservis mimarisinde ise kullanıcı, ödeme, sipariş, bildirim ve stok gibi işlevler farklı servislerde çalışabilir.

İstemcinin bütün servis adreslerini, güvenlik yöntemlerini ve sürümlerini bilmesi karmaşıklık oluşturur. API Gateway bu servislerin önünde ortak bir kapı görevi görerek istemciyle arka uç arasındaki iletişimi yönetir.

API Gateway Nedir?

API Gateway, istemci isteklerini kabul eden ve yapılandırılmış kurallara göre uygun arka uç servisine ileten ters proxy tabanlı bir API yönetim bileşenidir.

Bir mobil uygulama doğrudan kullanıcı, sipariş ve ödeme mikroservislerine bağlanmak yerine tek bir API Gateway adresine istek gönderebilir.

Gateway gelen isteği:

1. Kabul eder.
2. Kimlik bilgisini kontrol eder.
3. Hız ve kota politikasını uygular.
4. İsteğin gideceği servisi belirler.
5. Gerekirse veri biçimini dönüştürür.
6. Arka uç servisine iletir.
7. Cevabı istemciye döndürür.

Microsoft’un mikroservis API Gateway rehberinde, bu bileşen istemcilerle uygulama servisleri arasındaki iletişimi yöneten merkezi giriş noktası ve ters proxy olarak tanımlanmaktadır.

API Gateway Nasıl Çalışır?

Örnek bir e-ticaret uygulamasında kullanıcı sipariş ayrıntılarını görüntülemek istesin.

İstemcinin ihtiyaç duyduğu bilgiler farklı servislerde bulunabilir:

• Kullanıcı bilgisi, profil servisinde,
• Sipariş bilgisi, sipariş servisinde,
• Kargo durumu, teslimat servisinde,
• Ödeme bilgisi, ödeme servisinde,
• Ürün bilgisi, katalog servisinde bulunabilir.

API Gateway olmadan istemci bu servislerin her birine ayrı istek göndermek zorunda kalabilir.

Gateway kullanıldığında istemci tek bir istek gönderir. API Gateway gerekli servislerle iletişim kurar, sonuçları birleştirir ve istemciye ortak bir cevap döndürür.

Bu yaklaşım istemcinin mikroservis mimarisinin iç ayrıntılarını bilmesini önler. Servis adresleri veya dağıtım yapısı değiştiğinde mobil uygulamanın yeniden geliştirilmesi gerekmeyebilir.

API Gateway Mimarisinin Temel Bileşenleri

Bir API Gateway mimarisi aşağıdaki bileşenlerden oluşabilir.

İstemciler

Web uygulaması, mobil uygulama, iş ortağı sistemi, akıllı cihaz veya başka bir servis olabilir.

Ağ geçidi

İstekleri karşılayan, politikaları uygulayan ve arka uç servislerine yönlendiren ana bileşendir.

Kimlik sağlayıcısı

Kullanıcı veya uygulamanın kimliğini doğrular ve erişim belirteçleri oluşturabilir.

Mikroservisler

Sipariş, ödeme, kullanıcı, katalog ve bildirim gibi iş yeteneklerini yerine getiren bağımsız servislerdir.

Önbellek

Sık talep edilen cevapların geçici olarak saklanmasını ve bazı isteklerin arka uca gitmeden cevaplanmasını sağlar.

İzleme sistemi

İstek sayısı, gecikme, hata oranı ve servis performansı gibi verileri toplar.

Yapılandırma ve servis keşfi

İsteklerin hangi servise ve sürüme yönlendirileceğini belirler.

Google Cloud’un API Gateway mimari belgesinde, ağ geçidinin API yönetimi, izleme ve kimlik doğrulama görevlerini uygulayan bir katman olduğu belirtilmektedir.

API Gateway İçin 7 Güçlü Görev

1. İstekleri Doğru Servise Yönlendirmek

API Gateway’in en temel görevi gelen isteği doğru mikroservise yönlendirmektir.

Örnek yönlendirme kuralları:

• /users istekleri kullanıcı servisine,
• /orders istekleri sipariş servisine,
• /payments istekleri ödeme servisine,
• /products istekleri katalog servisine gönderilebilir.

İstemci yalnızca ağ geçidinin adresini bilir. Mikroservislerin gerçek adresleri ve çalıştıkları altyapı dışarıya açılmayabilir.

Gateway ayrıca:

• URL yoluna,
• HTTP metoduna,
• Alan adına,
• Başlık bilgisine,
• API sürümüne,
• Kullanıcı veya müşteri grubuna

göre farklı yönlendirme kuralları uygulayabilir.

Yeni bir servis sürümü sınırlı kullanıcı grubuna gönderilerek kademeli dağıtım yapılabilir. Ancak bu kurallar merkezi olarak yönetilmeli ve sürüm kontrolünde tutulmalıdır.

2. Kimlik Doğrulama ve Yetkilendirme

Her mikroservisin aynı kimlik doğrulama işlemini ayrı ayrı yazması tekrar ve güvenlik tutarsızlığı oluşturabilir.

API Gateway şu kontrolleri gerçekleştirebilir:

• Erişim belirtecini doğrulama,
• API anahtarını kontrol etme,
• Belirtecin süresini inceleme,
• Gerekli rol ve kapsam bilgilerini kontrol etme,
• Yetkisiz istekleri reddetme,
• Servise doğrulanmış kimlik bilgisini aktarma.

Bununla birlikte yalnızca Gateway kontrolüne güvenilmemelidir. Hassas mikroservisler kendi kaynakları için gerekli yetkilendirmeyi ayrıca uygulamalıdır.

Gateway kullanıcının genel olarak sisteme giriş yapabildiğini doğrularken ödeme servisi, kullanıcının yalnızca kendi ödeme bilgisine erişebildiğini kontrol edebilir.

3. Hız Sınırlama ve Kota Uygulamak

Kontrolsüz API trafiği sistem kaynaklarını tüketebilir. Hatalı çalışan bir uygulama veya kötü niyetli bir kullanıcı kısa sürede binlerce istek gönderebilir.

API Gateway hız sınırlama politikalarını merkezi olarak uygulayabilir.

Sınırlar şu bilgilere göre belirlenebilir:

• IP adresi,
• Kullanıcı hesabı,
• API anahtarı,
• Uygulama,
• Müşteri paketi,
• Belirli API yolu,
• Zaman aralığı.

Örneğin ücretsiz paket kullanan bir uygulamaya dakikada belirli sayıda istek hakkı verilirken kurumsal müşteriye daha yüksek kota sağlanabilir.

Sınır aşıldığında Gateway uygun bir hata cevabı döndürebilir. İstemci bu durumda üstel bekleme gibi kontrollü tekrar deneme yöntemleri kullanmalıdır.

Hız sınırlama yalnızca saldırı önleme aracı değildir. Kaynakların müşteriler arasında dengeli paylaşılmasına da yardımcı olur.

4. İstek ve Cevapları Dönüştürmek

İstemcinin beklediği veri biçimi ile arka uç servisinin kullandığı biçim farklı olabilir.

API Gateway sınırlı dönüşüm işlemleri yapabilir:

• HTTP başlığı ekleme veya kaldırma,
• URL yapısını değiştirme,
• Eski API sürümünü yeni servise yönlendirme,
• İstek ve cevap alanlarını yeniden adlandırma,
• Protokol dönüşümü,
• Gereksiz alanları cevaplardan çıkarma.

Örneğin eski mobil uygulama /v1/products adresini kullanırken yeni katalog servisi farklı bir yol kullanıyor olabilir. Gateway eski yolu yeni servise yönlendirerek geçiş sürecini kolaylaştırabilir.

Ancak ürün fiyatı hesaplama veya sipariş durumu belirleme gibi iş kuralları API Gateway içerisine yazılmamalıdır. İş mantığı ilgili mikroserviste kalmalıdır.

5. Birden Fazla Servisin Cevabını Birleştirmek

Bir ekranın hazırlanması için birden fazla mikroservise ihtiyaç duyulabilir. İstemcinin her servise ayrı istek göndermesi ağ trafiğini ve uygulama karmaşıklığını artırabilir.

Gateway Aggregation yaklaşımında istemci tek bir istek gönderir. Gateway gerekli mikroservislerden verileri alır ve ortak cevap oluşturur.

Örneğin sipariş özeti ekranında:

• Sipariş servisinden ürünler,
• Kullanıcı servisinden teslimat adresi,
• Ödeme servisinden ödeme durumu,
• Kargo servisinden takip bilgisi alınabilir.

Microsoft’un Gateway Aggregation açıklamasında, birden fazla arka uç çağrısının tek istemci isteği altında birleştirilmesinin istemci ile servisler arasındaki yoğun iletişimi azaltabileceği belirtilmektedir.

Toplama işlemi dikkatli tasarlanmalıdır. Bir servisin yavaşlaması bütün cevabın gecikmesine neden olabilir. Zaman aşımı, kısmi cevap ve hata politikaları önceden belirlenmelidir.

6. Önbellek ve Trafik Optimizasyonu

Sık talep edilen ve kısa süre içerisinde değişmeyen veriler Gateway üzerinde önbelleğe alınabilir.

Önbelleğe uygun örnekler:

• Ürün kategorileri,
• Genel yapılandırma verileri,
• Ülke ve şehir listeleri,
• Herkese açık içerikler,
• Kısa süreli ürün bilgileri.

Önbellek sayesinde:

• Arka uç servislerine giden istek sayısı azalabilir.
• Cevap süresi kısalabilir.
• Sistem yoğun trafik altında daha dayanıklı olabilir.
• Altyapı tüketimi azaltılabilir.

Ancak kullanıcıya özel ve hassas cevaplar yanlışlıkla ortak önbellekte tutulmamalıdır. Önbellek anahtarı, geçerlilik süresi ve temizleme politikası doğru yapılandırılmalıdır.

Fiyat ve stok gibi hızla değişen veriler için uzun süreli önbellek kullanılması müşteriye eski bilgi gösterilmesine neden olabilir.

7. İzleme, Kayıt ve API Yaşam Döngüsünü Yönetmek

Bütün dış API istekleri Gateway üzerinden geçtiği için sistem trafiğini gözlemlemek için önemli bir noktadır.

API Gateway şu verileri toplayabilir:

• Toplam istek sayısı,
• En fazla kullanılan API yolları,
• Cevap süreleri,
• Hata oranları,
• Yetkisiz giriş denemeleri,
• Kota aşımı sayısı,
• Arka uç servis gecikmesi,
• Önbellek kullanım oranı,
• API sürümü dağılımı.

Bu veriler performans sorunu ve kötüye kullanım belirtilerini ortaya çıkarabilir.

Ayrıca API sürümleri, kullanım planları, geliştirici anahtarları ve kullanımdan kaldırma tarihleri merkezi olarak yönetilebilir.

AWS API Gateway belgelerinde, Gateway’in REST, HTTP ve WebSocket API’lerini oluşturma, yayımlama, izleme, sürdürme ve güvenliğini yönetme işlevleri sunduğu açıklanmaktadır.

API Gateway, Load Balancer ve Reverse Proxy Farkı

Bu araçların bazı görevleri benzer görünse de kullanım amaçları farklıdır.

Load Balancer

Trafiği aynı uygulamanın birden fazla çalışan örneği arasında dağıtır. Ana amacı kullanılabilirlik ve kapasite yönetimidir.

Reverse Proxy

İstemci ile arka uç sunucusu arasında çalışır. İstek yönlendirme, TLS sonlandırma ve temel önbellek görevlerini gerçekleştirebilir.

API Gateway

Reverse proxy özelliklerine ek olarak API kimlik doğrulaması, kota, hız sınırlama, dönüşüm, sürümleme, geliştirici erişimi ve API analitiği sunabilir.

Bazı ürünler birden fazla görevi aynı anda yerine getirebilir. Seçim yapılırken ürün adından çok ihtiyaç duyulan özelliklere bakılmalıdır.

API Gateway ile Service Mesh Arasındaki Fark

API Gateway çoğunlukla dış istemcilerden iç servislere gelen kuzey-güney trafiğini yönetir.

Service Mesh ise mikroservislerin kendi aralarındaki doğu-batı trafiğine odaklanır.

Büyük bir sistem hem API Gateway hem de Service Mesh kullanabilir.

Backends for Frontends Yaklaşımı

Web, mobil ve iş ortağı uygulamalarının ihtiyaçları farklı olabilir.

Mobil uygulama daha küçük cevaplar isterken web uygulaması daha fazla ayrıntıya ihtiyaç duyabilir. Bütün istemcilere tek Gateway katmanı sunmak zamanla karmaşık kurallara neden olabilir.

Backends for Frontends, yani BFF yaklaşımında her istemci türü için ayrı arka uç katmanı oluşturulur:

• Mobil BFF,
• Web BFF,
• İş ortağı BFF.

Ana API Gateway ortak güvenlik ve trafik politikalarını uygularken BFF katmanı istemciye özel veri birleştirme işlemlerini gerçekleştirebilir.

API Gateway Kullanmanın Avantajları

• İstemcilere tek giriş noktası sağlar.
• Mikroservislerin iç adreslerini gizler.
• Ortak güvenlik politikalarını merkezileştirir.
• İstemciyi servis yapısından bağımsızlaştırır.
• API kullanımını ölçmeyi kolaylaştırır.
• Kota ve hız sınırlama sağlar.
• API sürüm geçişlerini kolaylaştırabilir.
• Tekrarlanan altyapı kodunu azaltabilir.
• İstemciye özel cevap hazırlanmasına yardımcı olabilir.

API Gateway Kullanmanın Riskleri

Tek hata noktası oluşturması

Gateway çalışmazsa bütün dış API erişimi durabilir. Birden fazla örnek, sağlık kontrolü ve yüksek erişilebilirlik planı kullanılmalıdır.

Ek gecikme oluşturması

Her istek yeni bir ağ katmanından geçer. Ağ geçidinde ağır dönüşümler ve iş mantığı çalıştırılmamalıdır.

Aşırı merkezi yapı

Bütün ekiplerin değişiklik için tek bir Gateway ekibini beklemesi teslimatı yavaşlatabilir. Yapılandırmalar kodla ve kontrollü self-service yöntemlerle yönetilebilir.

İş mantığının Gateway’e taşınması

Gateway ürün fiyatı veya sipariş durumu gibi alan kararlarını vermeye başlarsa mikroservisler birbirine sıkı bağlanabilir.

Hassas verilerin loglanması

Parola, erişim belirteci, banka kartı veya kişisel veri loglara yazılmamalıdır.

Yapılandırma karmaşası

Çok sayıda manuel yönlendirme kuralı zamanla anlaşılmaz hâle gelebilir. Infrastructure as Code ve otomatik test uygulanmalıdır.

API Gateway Güvenliği İçin Öneriler

• Bütün dış bağlantılarda güncel TLS kullanın.
• Kimlik ve erişim belirteçlerini doğrulayın.
• Hız sınırlama politikaları oluşturun.
• API yollarını varsayılan olarak kapalı tutun.
• Yönetim arayüzünü genel internete açmayın.
• Loglarda hassas alanları maskeleyin.
• İstek boyutu ve zaman aşımı sınırları belirleyin.
• Gateway yapılandırmalarını sürüm kontrolünde tutun.
• Arka uç servislerini doğrudan dış erişime kapatın.
• Güvenlik yamalarını düzenli uygulayın.
• Yetkilendirme kontrollerini hassas servislerde tekrar doğrulayın.
• Hata cevaplarında sistem ayrıntılarını göstermeyin.

Takip Edilmesi Gereken API Gateway Metrikleri

• Saniyedeki istek sayısı,
• Ortalama ve yüzdelik cevap süreleri,
• 4xx istemci hataları,
• 5xx sunucu hataları,
• Arka uç servis gecikmesi,
• Yetkilendirme başarısızlıkları,
• Hız sınırına takılan istekler,
• Önbellek isabet oranı,
• Zaman aşımı sayısı,
• Gateway kullanılabilirliği,
• API sürümlerinin kullanım dağılımı.

Yalnızca toplam isteğe bakmak yeterli değildir. Belirli API yolları ve müşteri grupları ayrı incelenmelidir.

API Gateway Kurulum Kontrol Listesi

1. Dışarıya açılacak API’leri belirleyin.
2. İstemci türlerini ve trafik miktarını analiz edin.
3. Kimlik doğrulama yöntemini seçin.
4. Yönlendirme ve sürümleme standardını oluşturun.
5. Hız ve kota politikalarını belirleyin.
6. Zaman aşımı ve tekrar deneme kurallarını hazırlayın.
7. Loglarda maskelenecek alanları tanımlayın.
8. Gateway’i birden fazla örnekle çalıştırın.
9. Yapılandırmaları kodla yönetin.
10. Performans ve güvenlik testlerini tamamlayın.
11. API kullanım raporlarını oluşturun.
12. Eski sürümler için kullanımdan kaldırma planı hazırlayın.

API Gateway Hangi Projelerde Kullanılmalı?

API Gateway özellikle:

• Çok sayıda mikroservis bulunan,
• Mobil ve web istemcileri aynı altyapıyı kullanan,
• Üçüncü taraflara API sunan,
• Müşteri bazlı kota uygulayan,
• API trafiğini merkezi izlemek isteyen,
• Ortak kimlik doğrulama kullanan,
• Birden fazla API sürümü yöneten

projelerde faydalıdır.

Tek bir küçük uygulama ve az sayıda API bulunan projelerde tam özellikli API Gateway gereksiz karmaşıklık oluşturabilir. Basit bir reverse proxy yeterli olabilir.

Türkiye’den geliştirilen yazılım ve API çözümlerinin küresel pazara sunulmasıyla ilgili Yazılım İhracatı Nasıl Yapılır? rehberine de göz atabilirsiniz.

Sonuç

API Gateway, mikroservis mimarisinde istemciler ile arka uç servisleri arasında güvenli ve yönetilebilir bir giriş katmanı oluşturur.

İstek yönlendirme, kimlik doğrulama, hız sınırlama, veri dönüşümü, cevap birleştirme, önbellek ve izleme gibi ortak görevlerin merkezi biçimde uygulanmasına yardımcı olur.

Ancak bütün iş mantığının ağ geçidine taşınması, yüksek erişilebilirliğin ihmal edilmesi ve hassas verilerin loglanması ciddi sorunlara neden olabilir.

Başarılı bir API Gateway mimarisi; hafif, yüksek erişilebilir, otomasyonla yönetilen ve mikroservislerin bağımsızlığını koruyan bir yapı olmalıdır.

Sıkça Sorulan Sorular

API Gateway Türkçede ne anlama gelir?

API Gateway, API ağ geçidi anlamına gelir. İstemci isteklerini karşılayan ve uygun arka uç servisine yönlendiren merkezi giriş katmanıdır.

Her projede API Gateway gerekli mi?

Hayır. Küçük ve basit uygulamalarda reverse proxy yeterli olabilir. Servis ve istemci sayısı arttıkça API Gateway daha faydalı hâle gelir.

API Gateway bir güvenlik duvarı mıdır?

Hayır. Kimlik doğrulama ve hız sınırlama yapabilse de güvenlik duvarının yerini tamamen almaz. Farklı güvenlik katmanları birlikte kullanılmalıdır.

API Gateway ile Load Balancer aynı şey mi?

Hayır. Load Balancer trafiği uygulama örnekleri arasında dağıtır. API Gateway ise API politikaları, kimlik doğrulama, yönlendirme ve kota gibi görevler uygular.

API Gateway veritabanına doğrudan bağlanmalı mı?

Genellikle hayır. Gateway isteği ilgili mikroservise iletmeli, veri erişimi servis tarafından gerçekleştirilmelidir.

API Gateway darboğaz oluşturabilir mi?

Evet. Yetersiz kapasite, ağır dönüşüm işlemleri veya yanlış yapılandırma darboğaz oluşturabilir. Yatay ölçekleme ve performans takibi uygulanmalıdır.