Her Servis İçin Ayrı ALB Oluşturmayı Bırakın: Terraform ile Çoklu Servis Yönlendirmesinde Uzmanlaşın ve Binlerce Dolar Tasarruf Edin ⚡
Bulut tabanlı mimarilerde, özellikle AWS üzerinde, her mikroservis veya uygulama için ayrı bir Application Load Balancer (ALB) oluşturmak yaygın bir alışkanlık haline geldi. Ancak bu yaklaşım, zamanla hem maliyetleri fahiş seviyelere çıkarabilir hem de operasyonel karmaşıklığı artırarak yönetim kabusuna dönüşebilir. Bu makalede, tek bir ALB üzerinden çoklu servis yönlendirmesi yaparak hem binlerce dolar tasarruf etmenin hem de altyapı yönetimini basitleştirmenin yollarını Terraform ile adım adım inceleyeceğiz.
Problem Tanımı: Neden Her Servis İçin Ayrı ALB Kötü Bir Fikir?
Her servis için ayrı bir ALB kullanmak ilk bakışta basit ve izole bir çözüm gibi görünse de, ölçek büyüdükçe ciddi dezavantajları ortaya çıkar. Bu dezavantajlar, hem finansal hem de operasyonel yükleri beraberinde getirir.
Maliyet Yükü: Gizli Giderler
AWS ALB’ler, çalıştıkları süre boyunca saatlik ücretlendirilir ve bu ücretlendirme, kullanılan kapasiteye göre değişiklik gösterir. Onlarca servisiniz olduğunda, her biri için ayrı bir ALB’nin saatlik maliyeti birikerek yıllık bazda on binlerce dolara ulaşabilir. Bu maliyetler genellikle göz ardı edilir veya “işin doğası” olarak kabul edilir, ancak optimize edilebilir büyük bir gider kalemidir.
Operasyonel Karmaşıklık: Yönetim Kabusu
Her ALB’nin kendine ait bir yaşam döngüsü, sertifika yönetimi, güvenlik grubu ayarları ve izleme mekanizmaları bulunur. Yüzlerce servisiniz olduğunda, bu ALBlere ait konfigürasyonları yönetmek, güncellemek ve sorun gidermek devasa bir iş yükü oluşturur. Bu durum, DevOps ekipleri için sürekli bir yönetim kabusuna dönüşebilir.
Kaynak İsrafı ve Performans Etkisi
Çoğu zaman, ayrı ayrı oluşturulan ALBlere gelen trafik yoğunluğu düşük olabilir. Bu, her bir ALB’nin ayrılmış kaynaklarının tam kapasiteyle kullanılmadığı anlamına gelir. Ayrıca, çok sayıda ALB’nin aynı VPC içinde çalışması, IP adresi tüketimi ve ağ kaynakları üzerinde gereksiz bir yük oluşturarak performansı olumsuz etkileyebilir.
Çoklu Servis Yönlendirmesi Nedir ve Nasıl Çalışır?
Çoklu servis yönlendirmesi, tek bir Application Load Balancer (ALB) kullanarak farklı URL yollarına (path-based routing) veya farklı host adlarına (host-based routing) gelen istekleri, farklı arka uç servislerine yönlendirme yeteneğidir. Bu sayede, tüm servisleriniz için tek bir giriş noktası oluşturmuş olursunuz.
ALB’nin Temel Yapısı ve Listener’lar
Bir ALB, gelen trafiği dinlemek için bir veya daha fazla “Listener” kullanır. Listener’lar, belirli bir port ve protokol (örneğin, HTTP:80 veya HTTPS:443) üzerindeki bağlantıları bekler. Gelen her istek, bu listener’lar tarafından karşılanır ve yönlendirme kurallarına göre işlenir.
Hedef Grupları (Target Groups): Servislerin Kalbi
Hedef Grupları, ALB’nin trafiği yönlendireceği arka uç servislerinin (EC2 instance’ları, ECS görevleri, Lambda fonksiyonları vb.) bir koleksiyonudur. Her bir hedef grubu, belirli bir servise aittir ve kendi sağlık kontrolü (health check) ayarları bulunur. Çoklu servis yönlendirmesinde, her bir servisiniz için ayrı bir hedef grubu tanımlarsınız.
Kural Tabanlı Yönlendirme: Akıllı Trafik Yönetimi
ALB Listener’ları, gelen istekleri nasıl işleyeceklerini belirleyen bir dizi kurala sahiptir. Bu kurallar, isteğin host başlığına, URL yoluna, HTTP metoduna veya sorgu parametrelerine göre trafiği farklı hedef gruplarına yönlendirebilir. Örneğin, /api/users ile başlayan istekleri “Kullanıcı Servisi” hedef grubuna, /api/products ile başlayan istekleri ise “Ürün Servisi” hedef grubuna yönlendirebilirsiniz.
Terraform ile Tek ALB Üzerinden Çoklu Servis Yönlendirmesi Kurulumu
Terraform, altyapınızı kod olarak (Infrastructure as Code – IaC) yönetmenizi sağlayan güçlü bir araçtır. Tek bir ALB üzerinden çoklu servis yönlendirmesi yapmak için Terraform kullanmak, hem tutarlılık hem de otomasyon sağlar.
Temel ALB ve Listener Tanımlaması
İlk adım, bir ALB ve onun için bir veya daha fazla listener oluşturmaktır. Genellikle HTTPS:443 portu üzerinden bir listener tanımlanır ve SSL sertifikası ilişkilendirilir.
resource "aws_lb" "main" {
name = "multi-service-alb"
internal = false
load_balancer_type = "application"
security_groups = [aws_security_group.alb_sg.id]
subnets = var.public_subnet_ids
tags = {
Environment = "Production"
ManagedBy = "Terraform"
}
}
resource "aws_lb_listener" "https" {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-2016-08"
certificate_arn = var.acm_certificate_arn
default_action {
type = "fixed-response"
fixed_response {
content_type = "text/plain"
message_body = "404 Not Found - No matching rule"
status_code = "404"
}
}
}
Çoklu Hedef Grupları Oluşturma
Her bir mikroservisiniz veya uygulamanız için ayrı bir hedef grubu oluşturmanız gerekir. Bu örnekte, iki farklı servis için hedef grupları tanımlıyoruz.
resource "aws_lb_target_group" "users_service" {
name = "users-service-tg"
port = 80
protocol = "HTTP"
vpc_id = var.vpc_id
health_check {
path = "/health"
protocol = "HTTP"
matcher = "200"
interval = 30
timeout = 5
healthy_threshold = 2
unhealthy_threshold = 2
}
tags = {
Service = "Users"
}
}
resource "aws_lb_target_group" "products_service" {
name = "products-service-tg"
port = 80
protocol = "HTTP"
vpc_id = var.vpc_id
health_check {
path = "/health"
protocol = "HTTP"
matcher = "200"
interval = 30
timeout = 5
healthy_threshold = 2
unhealthy_threshold = 2
}
tags = {
Service = "Products"
}
}
Kural Tabanlı Yönlendirme Kuralları
Şimdi, listener'ımıza gelen isteklere göre trafiği doğru hedef grubuna yönlendirecek kuralları ekleyelim. Bu örnekte, URL yoluna göre yönlendirme yapıyoruz.
resource "aws_lb_listener_rule" "users_rule" {
listener_arn = aws_lb_listener.https.arn
priority = 100 # Düşük sayılar daha yüksek öncelik demektir
action {
type = "forward"
target_group_arn = aws_lb_target_group.users_service.arn
}
condition {
path_pattern {
values = ["/api/users*", "/users*"]
}
}
}
resource "aws_lb_listener_rule" "products_rule" {
listener_arn = aws_lb_listener.https.arn
priority = 99 # Daha yüksek öncelik
action {
type = "forward"
target_group_arn = aws_lb_target_group.products_service.arn
}
condition {
path_pattern {
values = ["/api/products*", "/products*"]
}
}
}
Bu yapılandırma ile, /api/users veya /users ile başlayan tüm istekler users_service hedef grubuna, /api/products veya /products ile başlayan istekler ise products_service hedef grubuna yönlendirilecektir. Diğer tüm istekler, listener'ın varsayılan eylemi olan 404 yanıtını alacaktır.
Gelişmiş Yönlendirme Stratejileri ve Kullanım Senaryoları
Tek bir ALB, sadece basit yol tabanlı yönlendirmeyle sınırlı değildir. Çok daha karmaşık ve esnek senaryoları destekleyebilir.
Blue/Green ve Canary Dağıtımlar
ALB kuralları, yeni sürümleri güvenli bir şekilde dağıtmak için kullanılabilir. Blue/Green dağıtımda, yeni sürüm (Green) ayrı bir hedef grubunda çalışırken, trafik anında Blue'dan Green'e geçirilir. Canary dağıtımda ise, trafiğin küçük bir yüzdesi yeni sürüme yönlendirilir ve sorun olup olmadığı izlenir. Her iki senaryo da ALB kurallarını değiştirerek kolayca yönetilebilir.
Mikroservis Mimarileri için İdeal Çözüm
Mikroservis mimarileri, genellikle çok sayıda küçük, bağımsız servisten oluşur. Tek bir ALB ile tüm bu servislere tek bir giriş noktası sağlamak, ağ yapılandırmasını basitleştirir ve servis keşfi yükünü azaltır. Her servis kendi hedef grubuna sahip olur ve ALB, gelen isteği doğru servise yönlendirir.
A/B Testleri ve Deneysel Özellikler
Kullanıcıların belirli bir yüzdesini yeni bir özelliğe veya farklı bir kullanıcı arayüzüne yönlendirmek için ALB kurallarını kullanabilirsiniz. Örneğin, HTTP başlıklarına veya çerezlere göre kullanıcıları farklı hedef gruplarına yönlendirerek A/B testleri yapabilir ve deneysel özelliklerin etkisini ölçebilirsiniz.
Maliyet ve Operasyonel Avantajlar
Tek bir ALB kullanmanın getirdiği faydalar sadece karmaşıklığı azaltmakla kalmaz, aynı zamanda somut maliyet tasarrufları ve operasyonel verimlilik sağlar.
Doğrudan Maliyet Tasarrufu
En belirgin avantaj, ALB maliyetlerinden yapılan doğrudan tasarruftur. Bir ALB'nin maliyeti, birden fazla ALB'nin toplam maliyetinden çok daha düşüktür. Onlarca ALB yerine tek bir ALB kullanmak, yıllık bazda binlerce, hatta on binlerce dolar tasarruf etmenizi sağlayabilir.
Yönetim Kolaylığı ve Hız
Daha az ALB demek, daha az konfigürasyon, daha az güvenlik grubu, daha az sertifika yönetimi demektir. Bu, DevOps ekiplerinin altyapıyı yönetmek için harcadığı zamanı önemli ölçüde azaltır. Yeni bir servis eklemek veya mevcut bir servisi güncellemek, sadece birkaç Terraform kuralı değişikliğiyle hızlıca yapılabilir.
Kaynak Verimliliği ve Ölçeklenebilirlik
Tek bir ALB, gelen tüm trafiği yönettiği için daha verimli bir şekilde ölçeklenebilir. AWS, ALB'yi otomatik olarak ölçeklendirirken, tüm servislerin trafiğini tek bir noktada toplayarak daha iyi bir kapasite kullanımı sağlar. Bu, gereksiz kaynak tahsisini önler ve genel verimliliği artırır.
Potansiyel Zorluklar ve Çözümler
Her ne kadar tek ALB yaklaşımı birçok avantaj sunsa da, bazı potansiyel zorlukları da beraberinde getirebilir. Bu zorlukları önceden bilmek ve çözümlerini uygulamak önemlidir.
Karmaşık Kural Setleri ve Yönetimi
Çok sayıda servis ve yönlendirme kuralı olduğunda, ALB listener kuralları karmaşık hale gelebilir. Bu karmaşıklığı yönetmek için Terraform modüllerini kullanarak kuralları mantıksal gruplara ayırabilir, açıklayıcı isimlendirme standartları belirleyebilir ve düzenli kod incelemeleri yapabilirsiniz.
Performans İzleme ve Hata Ayıklama
Tüm trafiğin tek bir ALB üzerinden geçmesi, performans sorunlarının veya hataların kaynağını bulmayı zorlaştırabilir. AWS CloudWatch, ELB erişim günlükleri ve entegre izleme araçları (Datadog, New Relic vb.) kullanarak detaylı metrikler toplamak ve proaktif uyarılar kurmak bu sorunu çözebilir. Her servisin kendi izleme metriklerini ayrı ayrı sunması, sorunun kaynağını tespit etmeyi kolaylaştırır.
Tek Hata Noktası Riski ve Yüksek Erişilebilirlik
Tek bir ALB kullanmak, teorik olarak bir "tek hata noktası" riski taşıyabilir. Ancak AWS ALB'ler, varsayılan olarak yüksek erişilebilirlik ve hata toleransı sağlamak üzere tasarlanmıştır. Birden fazla Availability Zone'da (AZ) dağıtılarak ve otomatik ölçeklendirme ile bu risk minimize edilir. Yine de, ALB'nin doğru şekilde yapılandırıldığından ve tüm AZ'leri kapsadığından emin olmak önemlidir.
Sonuç
Her servis için ayrı bir ALB oluşturma alışkanlığından vazgeçmek ve tek bir ALB üzerinden çoklu servis yönlendirmesine geçmek, AWS altyapı maliyetlerinizde önemli tasarruflar sağlayabilir ve operasyonel verimliliği artırabilir. Terraform gibi araçlarla bu geçişi otomatikleştirmek, altyapınızın tutarlı, yönetilebilir ve ölçeklenebilir olmasını sağlar. Mikroservis mimarileri, A/B testleri ve Blue/Green dağıtımlar gibi modern geliştirme pratiklerini destekleyen bu yaklaşım, bulut stratejinizin önemli bir parçası olmalıdır. Akıllıca planlanmış ve uygulanmış bir tek ALB stratejisi ile hem cüzdanınızı hem de DevOps ekibinizin iş yükünü hafifletebilirsiniz.
Sıkça Sorulan Sorular (SSS)
1. Bu yaklaşım ne zaman uygun değildir?
Çok yüksek ve öngörülemeyen trafik dalgalanmaları olan, birbirinden tamamen bağımsız ve farklı güvenlik gereksinimleri olan servisler için ayrı ALB'ler daha uygun olabilir. Ayrıca, farklı AWS hesaplarında bulunan servisler için de ayrı ALB'ler tercih edilebilir.
2. Mevcut ALB'lerimi nasıl bu yapıya taşıyabilirim?
Mevcut servislerinizi yeni, merkezi ALB'ye taşımak için kademeli bir yaklaşım izleyebilirsiniz. İlk olarak, yeni ALB'yi ve hedef gruplarını Terraform ile oluşturun. Ardından, eski ALB'lerinizdeki trafik kurallarını yavaş yavaş yeni ALB'ye yönlendirin. Blue/Green veya Canary dağıtım stratejilerini kullanarak riski minimize edebilirsiniz.
3. Güvenlik açısından bir dezavantajı var mı?
Tek bir ALB, tüm trafiği tek bir noktadan yönettiği için güvenlik politikalarını merkezi olarak uygulamayı kolaylaştırır. Ancak, tüm servisler aynı ALB'yi kullandığından, bir güvenlik açığı tüm servisleri etkileyebilir. Bu riski azaltmak için sıkı güvenlik grubu kuralları, WAF entegrasyonu ve düzenli güvenlik denetimleri önemlidir.
4. Trafik yükü çok yüksekse performans sorunları yaşar mıyım?
AWS ALB'ler, yüksek trafik yüklerini yönetmek üzere tasarlanmıştır ve otomatik olarak ölçeklenir. Tek bir ALB'nin performans sorunları yaşama olasılığı düşüktür. Ancak, çok sayıda karmaşık kural veya aşırı yoğun HTTP istekleri (örneğin, DDoS saldırıları) ALB'yi zorlayabilir. Bu durumda, AWS WAF gibi ek güvenlik ve performans katmanları entegre etmek faydalı olacaktır.