Service Mesh, mikroservisler arasındaki iletişimin güvenli, gözlemlenebilir ve kontrol edilebilir şekilde yönetilmesini sağlayan özel bir altyapı katmanıdır. Türkçede “servis ağı” olarak ifade edilebilen bu yapı; trafik yönlendirme, şifreleme, yük dengeleme, hata yönetimi ve telemetri toplama gibi işlemleri uygulama kodundan ayırır.
Modern bir uygulama onlarca veya yüzlerce mikroservisten oluşabilir. Bir kullanıcı isteği hedefe ulaşmadan önce API Gateway, kullanıcı servisi, sipariş servisi, ödeme servisi ve veritabanı gibi birçok bileşenden geçebilir. Servis sayısı arttıkça bu iletişimin yönetilmesi de zorlaşır.
Service Mesh, servisler arasındaki bu karmaşık trafiği merkezi politikalarla yöneterek yazılım ekiplerinin iş mantığına odaklanmasına yardımcı olur.
Service Mesh Nedir?
Service Mesh, dağıtık bir sistem içerisinde servislerin birbiriyle nasıl iletişim kuracağını yöneten altyapı katmanıdır. İletişim trafiği genellikle uygulamanın yanında veya ağ seviyesinde çalışan proxy bileşenleri üzerinden geçirilir.
Bu proxy bileşenleri aşağıdaki işlemleri gerçekleştirebilir:
- İsteklerin doğru servise yönlendirilmesi
- Servisler arasında yük dengeleme
- Bağlantıların şifrelenmesi
- Kimlik ve yetki kontrolü
- Hatalı isteklerin yeniden denenmesi
- Gecikme ve hata metriklerinin toplanması
- Yeni sürümlere kontrollü trafik aktarılması
Istio’nun Service Mesh açıklamasına göre bu altyapı katmanı uygulama kodunu değiştirmeden güvenlik, gözlemlenebilirlik ve gelişmiş trafik yönetimi özellikleri sağlayabilir.
Service Mesh Nasıl Çalışır?
Service Mesh mimarisi temel olarak veri düzlemi ve kontrol düzlemi olmak üzere iki bölümden oluşur.
Veri Düzlemi
Veri düzlemi, servisler arasında taşınan gerçek uygulama trafiğini yönetir. Proxy bileşenleri gelen ve giden istekleri yakalayarak ilgili güvenlik ve yönlendirme politikalarını uygular.
Sidecar modelinde her uygulama örneğinin yanında ayrı bir proxy çalışır. Uygulama başka bir servise doğrudan bağlanmak yerine önce kendi proxy bileşenine istek gönderir.
Bazı yeni Service Mesh yaklaşımları ise her uygulamanın yanında proxy çalıştırmak yerine düğüm veya ağ seviyesinde ortak bileşenler kullanabilir.
Kontrol Düzlemi
Kontrol düzlemi, veri düzlemindeki proxy bileşenlerinin nasıl davranacağını belirler. Trafik kuralları, güvenlik politikaları, servis kimlikleri ve yönlendirme ayarları merkezi olarak buradan yönetilir.
Kontrol düzlemi gerçek uygulama trafiğini doğrudan taşımak yerine veri düzlemine gerekli yapılandırmaları gönderir.
Linkerd belgelerinde de proxy ağının veri düzlemini, bu proxy’leri yöneten merkezi yapının ise kontrol düzlemini oluşturduğu belirtilmektedir.
Service Mesh ile API Gateway Arasındaki Fark Nedir?
API Gateway ve Service Mesh benzer trafik yönetimi özelliklerine sahip olsa da farklı iletişim alanlarına odaklanır.
API Gateway çoğunlukla kullanıcıların veya harici uygulamaların sisteme gönderdiği kuzey-güney trafiğini yönetir. Kimlik doğrulama, hız sınırlama, API anahtarları ve dış isteklerin uygun servise yönlendirilmesi gibi işlemleri gerçekleştirir.
Service Mesh ise sistemin içerisindeki servisler arasında gerçekleşen doğu-batı trafiğine odaklanır. Bir mikroservisin başka bir mikroservisle nasıl iletişim kuracağını kontrol eder.
Örneğin:
- Mobil uygulama → API Gateway → Sipariş Servisi
- Sipariş Servisi → Service Mesh → Ödeme Servisi
- Ödeme Servisi → Service Mesh → Stok Servisi
Bu iki teknoloji rakip değildir. Büyük mikroservis mimarilerinde birlikte kullanılabilir. Konuyu daha ayrıntılı incelemek için API Gateway rehberine de göz atabilirsiniz.
Mikroservisleri Güçlendiren 7 Kritik Service Mesh Avantajı
1. Merkezi Trafik Yönetimi Sağlar
Mikroservislerde isteklerin hangi servis örneğine gönderileceği, hatalı servislere nasıl davranılacağı ve farklı sürümlere ne kadar trafik aktarılacağı önemlidir.
Service Mesh sayesinde trafik davranışı uygulama kodundan bağımsız politikalarla yönetilebilir. Ekipler servislerin kodunu değiştirmeden yönlendirme kuralları oluşturabilir.
Uygulanabilecek trafik kontrolleri şunlardır:
- Yüzde tabanlı trafik dağıtımı
- Başlık veya kullanıcı grubuna göre yönlendirme
- Servis sürümleri arasında trafik bölme
- Belirli servislerin erişimini sınırlandırma
- Farklı kümeler arasında trafik yönetimi
- Hatalı hedefleri geçici olarak devre dışı bırakma
Merkezi yönetim, farklı ekipler tarafından geliştirilen servislerin ortak trafik kurallarına uymasını kolaylaştırır.
2. Servisler Arasında Güvenli İletişim Kurar
Mikroservisler aynı kurum ağı içerisinde bulunsa bile aralarındaki iletişimin otomatik olarak güvenli kabul edilmemesi gerekir. Ele geçirilen bir servis veya cihaz, ağ içerisindeki diğer sistemlere saldırmak için kullanılabilir.
Service Mesh çözümleri servisler arasındaki bağlantıları karşılıklı TLS, yani mTLS ile şifreleyebilir. Normal TLS bağlantısında çoğunlukla sunucunun kimliği doğrulanırken mTLS bağlantısında iletişimin iki tarafı da birbirinin kimliğini doğrular.
Böylece:
- Servisler birbirlerinin kimliğini doğrulayabilir.
- Ağ trafiği şifrelenebilir.
- Yetkisiz servis bağlantıları engellenebilir.
- Sertifika yenileme işlemleri otomatikleştirilebilir.
- Servis bazlı erişim politikaları uygulanabilir.
Bu yapı Zero Trust mimarisi ilkelerinin servisler arasındaki iletişime uygulanmasına yardımcı olur.
3. Gözlemlenebilirliği Artırır
Mikroservis tabanlı uygulamalarda bir isteğin hangi servislerden geçtiğini anlamak zor olabilir. Service Mesh, proxy üzerinden geçen trafik için otomatik olarak metrik ve bağlantı bilgileri oluşturabilir.
Takip edilebilecek temel veriler şunlardır:
- İstek sayısı
- Başarı ve hata oranı
- Servis yanıt süresi
- Trafik hacmi
- Yeniden deneme sayısı
- Bağlantı durumu
- Kaynak ve hedef servis
- Farklı sürümlerin performansı
Bu veriler, bir servisin diğer servisleri nasıl etkilediğini anlamayı kolaylaştırır. Service Mesh tek başına bütün uygulama bağlamını sağlamayabilir; ancak observability yaklaşımını güçlü trafik telemetrisiyle destekler.
4. Hatalara Karşı Dayanıklılık Sağlar
Dağıtık sistemlerde bir servisin geçici olarak yavaşlaması veya cevap vermemesi diğer servisleri de etkileyebilir. Kontrolsüz biçimde yapılan yeniden denemeler ise problemi büyüterek bütün sistemi zorlayabilir.
Service Mesh aşağıdaki dayanıklılık politikalarını merkezi olarak uygulayabilir:
- Zaman aşımı
- Sınırlı yeniden deneme
- Devre kesici
- Hatalı servisi yük dengelemeden çıkarma
- Alternatif servise yönlendirme
- Bağlantı havuzu yönetimi
- Hata enjeksiyonu testleri
Ancak yeniden deneme politikaları dikkatli hazırlanmalıdır. Ödeme oluşturma gibi aynı işlemin tekrarlanmasının sorun oluşturabileceği isteklerde idempotency kontrolü yapılmalıdır.
5. Akıllı Yük Dengeleme Sunar
Bir mikroservisin aynı anda çalışan çok sayıda örneği bulunabilir. Gelen isteklerin bu örnekler arasında dengeli biçimde dağıtılması gerekir.
Service Mesh yalnızca bağlantı sayısına değil, servislerin gecikme ve hata durumlarına göre de yük dağılımı gerçekleştirebilir. Sağlıksız veya yavaşlayan bir servis örneği geçici olarak havuzdan çıkarılabilir.
Böylece:
- Tek bir servis örneğinin aşırı yüklenmesi önlenebilir.
- Trafik sağlıklı servislere aktarılabilir.
- Kullanıcıların hata yaşama ihtimali azaltılabilir.
- Küme ve bölgeler arasında yönlendirme yapılabilir.
- gRPC ve HTTP tabanlı trafik daha ayrıntılı yönetilebilir.
Yük dengeleme politikası belirlenirken uygulamanın oturum, veri tutarlılığı ve gecikme gereksinimleri dikkate alınmalıdır.
6. Canary ve A/B Dağıtımlarını Kolaylaştırır
Yeni bir yazılım sürümünü bütün kullanıcılara aynı anda açmak önemli bir risk oluşturabilir. Service Mesh, trafiğin küçük bir bölümünü yeni sürüme yönlendirerek kontrollü dağıtım yapılmasına yardımcı olur.
Örneğin trafiğin yüzde 5’i yeni sürüme, kalan yüzde 95’i mevcut kararlı sürüme gönderilebilir. Yeni sürümde hata oranı artmıyorsa trafik oranı aşamalı olarak yükseltilebilir.
Service Mesh ile şu dağıtım yöntemleri uygulanabilir:
- Canary deployment
- Blue-green deployment
- A/B testi
- Kullanıcı grubuna göre sürüm yönlendirme
- Bölge bazlı kontrollü yayın
- Sorun durumunda hızlı trafik geri alma
Istio trafik yönetimi belgeleri, sanal servisler ve yönlendirme kuralları kullanılarak isteklerin belirli hizmet sürümlerine aktarılabildiğini açıklamaktadır.
7. Geliştiricilerin İş Mantığına Odaklanmasını Sağlar
Trafik güvenliği, yeniden deneme, telemetri ve yük dengeleme kodlarının her servise ayrı ayrı eklenmesi gerekirken uygulamalar arasında tutarsızlık oluşabilir.
Bir ekip Java, başka bir ekip Go ve diğer ekip Node.js kullanıyorsa aynı iletişim özelliklerinin farklı kütüphanelerle uygulanması gerekebilir.
Service Mesh bu sorumlulukları platform katmanına taşıyarak ortak politikalar oluşturur. Böylece geliştiriciler daha çok ürünün işlevlerine odaklanabilir.
Platform ekipleri ise güvenlik ve trafik kurallarını merkezi olarak yönetebilir. Ancak bu avantajın elde edilebilmesi için Service Mesh altyapısının ekipler tarafından anlaşılması ve doğru işletilmesi gerekir.
Service Mesh Hangi Durumlarda Kullanılmalıdır?
Service Mesh özellikle şu koşullarda faydalı olabilir:
- Çok sayıda mikroservis bulunuyorsa
- Servisler farklı programlama dilleriyle geliştiriliyorsa
- Kubernetes veya benzeri bir orkestrasyon sistemi kullanılıyorsa
- Servisler arasında mTLS uygulanması gerekiyorsa
- Gelişmiş trafik yönlendirme ihtiyacı bulunuyorsa
- Canary dağıtımları düzenli yapılıyorsa
- Servis iletişiminin gözlemlenmesi zorlaşıyorsa
- Birden fazla küme veya bulut ortamı kullanılıyorsa
- Ortak güvenlik politikaları uygulanmak isteniyorsa
Küçük bir uygulamada iki veya üç servis için Service Mesh kullanmak gereksiz operasyonel karmaşıklık oluşturabilir. Teknoloji, yalnızca popüler olduğu için değil, somut bir iletişim sorununu çözdüğü zaman kullanılmalıdır.
Service Mesh Kullanmanın Zorlukları
Service Mesh önemli avantajlar sunmasına rağmen ücretsiz bir katman değildir. Proxy ve kontrol düzlemi bileşenleri işlemci, bellek ve ağ kaynağı tüketebilir.
Karşılaşılabilecek zorluklar şunlardır:
- Altyapı karmaşıklığının artması
- Ek kaynak tüketimi
- Proxy kaynaklı gecikme
- Yapılandırma hataları
- Sertifika ve politika yönetimi
- Sorun giderme sürecinin değişmesi
- Ekibin yeni kavramları öğrenme ihtiyacı
- Sürüm yükseltme ve bakım sorumluluğu
Service Mesh kurulmadan önce mevcut gecikme değerleri ve kaynak kullanımı ölçülmelidir. Pilot uygulama sonrasında oluşan ek maliyet ve sağlanan fayda karşılaştırılmalıdır.
Istio ve Linkerd Arasındaki Fark Nedir?
Istio, gelişmiş trafik yönetimi, güvenlik politikaları ve farklı dağıtım seçenekleri sunan kapsamlı bir Service Mesh çözümüdür. Sidecar modelinin yanında ambient veri düzlemi seçeneğine de sahiptir.
Linkerd ise Kubernetes ortamlarında sadelik ve düşük kaynak tüketimine odaklanan bir Service Mesh çözümüdür. Kendisine özel hafif bir proxy kullanır.
Hangi çözümün daha uygun olduğu şu faktörlere göre değişebilir:
- İhtiyaç duyulan trafik özellikleri
- Küme büyüklüğü
- Ekibin operasyonel deneyimi
- Kaynak tüketimi beklentisi
- Çoklu küme gereksinimi
- Güvenlik politikalarının karmaşıklığı
- Mevcut gözlemlenebilirlik araçları
Karar verilmeden önce küçük bir pilot kümede iki çözümün de ölçülmesi faydalıdır.
Service Mesh Kurulumuna Nasıl Başlanır?
İlk olarak servisler arasındaki mevcut trafik haritası çıkarılmalıdır. Hangi servislerin birbiriyle iletişim kurduğu ve kritik işlem yolları belirlenmelidir.
Daha sonra küçük ve düşük riskli bir uygulama pilot olarak seçilebilir. Pilot süreçte şu metrikler takip edilebilir:
- İstek gecikmesi
- Hata oranı
- Proxy kaynak tüketimi
- Dağıtım süresi
- Sorun tespit süresi
- Politika yönetiminin kolaylığı
Pilot başarılı olduktan sonra kritik olmayan servisler aşamalı olarak mesh içerisine alınabilir. Bütün servislerin tek seferde taşınması yerine kontrollü geçiş yapılmalıdır.
Service Mesh Kurarken Yapılan Hatalar
Yaygın hatalar şunlardır:
- İhtiyaç belirlemeden teknoloji seçmek
- Bütün servisleri aynı anda mesh içerisine almak
- Proxy kaynak tüketimini ölçmemek
- Yanlış yeniden deneme politikaları oluşturmak
- Uygulama gözlemlenebilirliğini tamamen Service Mesh’e bırakmak
- Güvenlik politikalarını test etmemek
- Kontrol düzlemi için yedeklilik planlamamak
- Geliştirici ekiplerini sürece dahil etmemek
- Sürüm güncelleme planı hazırlamamak
- Başarı ölçütleri belirlememek
Service Mesh, kötü tasarlanmış mikroservis mimarisini tek başına düzeltemez. Servis sınırları, API sözleşmeleri ve veri yönetimi doğru tasarlanmalıdır.
Sıkça Sorulan Sorular
Service Mesh Türkçede ne anlama gelir?
Service Mesh, Türkçede “servis ağı” olarak ifade edilebilir. Mikroservislerin kendi aralarındaki iletişimini yöneten altyapı katmanıdır.
Service Mesh yalnızca Kubernetes için mi kullanılır?
Hayır. Kubernetes en yaygın kullanım ortamıdır ancak bazı Service Mesh çözümleri sanal makineleri ve farklı çalışma ortamlarını da destekleyebilir.
Service Mesh, API Gateway’in yerine geçer mi?
Genellikle hayır. API Gateway dış istemci trafiğine, Service Mesh ise sistem içerisindeki servisler arası trafiğe odaklanır.
Service Mesh uygulama kodunu değiştirir mi?
Birçok özellik uygulama kodunda değişiklik yapmadan eklenebilir. Ancak dağıtık tracing bağlamının aktarılması gibi bazı özellikler uygulama desteği gerektirebilir.
Service Mesh performansı düşürür mü?
Proxy katmanı ek kaynak tüketimi ve gecikme oluşturabilir. Etkinin büyüklüğü kullanılan çözüm, trafik türü ve yapılandırmaya göre değişir. Pilot test yapılmalıdır.
Sonuç
Service Mesh, büyüyen mikroservis mimarilerinde servisler arasındaki iletişimi güvenli, dayanıklı ve gözlemlenebilir hale getiren güçlü bir altyapı katmanıdır.
Merkezi trafik yönetimi, mTLS, telemetri, yük dengeleme ve kontrollü dağıtım özellikleri önemli avantajlar sağlar. Buna karşılık ek operasyonel karmaşıklık ve kaynak tüketimi oluşturabileceği unutulmamalıdır.
En doğru yaklaşım, küçük bir pilot projeyle başlayarak Service Mesh’in oluşturduğu maliyeti ve sağladığı faydayı gerçek sistem verileri üzerinden değerlendirmektir.
