AWS Fargate 101: Container'larınızın Bakıcıya İhtiyacı Olmadığında

Birçok takımın ulaştığı kademeli bir fark ediş var: EC2 instance’larını yönetmek, feature geliştirmekten daha fazla zaman alır. Bu genellikle rutin bir altyapı incelemesi sırasında, production sunucusunda yine disk alanı sorunlarını çözerken ortaya çıkar; rol sessizce pahalı Linux sistem yöneticiliğine kaymıştır. Bu yazıda Fargate’in ne zaman mantıklı olduğu, ilk deployment’ın nasıl yapılacağı ve EC2 Launch Type ile farklar ele alınıyor.

İşte AWS Fargate’in gerçekten çekici görünmeye başladığı nokta burası. Aşağıda ilk task definition’ınızı nasıl oluşturacağınız, network modu ve EC2 vs Fargate karar kriterleri adım adım ele alınıyor.

Fargate Aslında Nedir (Pazarlama Lafları Olmadan)

Fargate’i “Sadece container’larımı çalıştırmak istiyorum” butonu olarak düşünün. AWS’ye Docker image’ınızı veriyorsunuz, ne kadar CPU ve bellek istediğinizi söylüyorsunuz, gerisini o hallediyor. Patch yapılacak EC2 instance’ı yok, yönetilecek cluster kapasitesi yok, host’un disk alanı bittiği için gece yarısı çağrısı yok. Ölçekleme tamamen AWS tarafında; siz sadece task sayısını ve kaynak ayarlarını tanımlarsınız.

İşe yarayan bir mental model şu: EC2 araba sahibi olmak gibiyse (yağ değişimi, lastik rotasyonu, çıkardığı o garip ses), Fargate Uber çağırmak gibi. Nereye gitmek istediğinizi belirtiyorsunuz (bu container’ı çalıştır), araç bakımını başkası düşünüyor. Fargate EC2 Launch Type’dan farklı olarak siz cluster capacity yönetmiyorsunuz; AWS her task için compute’u otomatik sağlıyor. Bu bölümde ilk deployment, kaynak boyutlandırma ve EC2 ile karar kriterleri ele alınıyor.

Mimari (Ya da: Sihir Nasıl Gerçekleşiyor)

Güzellik görmediğiniz şeyde. Her Fargate task’ı kendi izole ortamında, kendi kernel’i, CPU kaynakları, belleği ve network interface’i ile çalışıyor. Her container için özel bir micro-VM’iniz varmış gibi, ama VM yönetmenin hiçbir yükü olmadan. Multi-tenant senaryolarda bu izolasyon güvenlik ve stabilite sağlar. Öğrenme eğrisi EC2 ECS’e benzer; task definition, service ve cluster kavramları aynı, sadece launch type farklı. İlk deployment için ECS kullanmak EKS’ten daha hızlıdır; Kubernetes ihtiyacınız olmadığı sürece Fargate + ECS ile başlamak mantıklı.

İlk Fargate Deployment’ınız (Gerçek Yöntem)

İşte Fargate’te pratik bir deployment. ECS kullanacağız çünkü, dürüst olmak gerekirse, başlamak için EKS’ten daha basit ve muhtemelen Kubernetes’e ihtiyacınız olduğunu bilmiyorsanız Kubernetes’e ihtiyacınız yok.

İlk olarak, bir task definition oluşturalım. Bu temelde AWS’ye “container’ımın çalışması için ihtiyacı olanlar bunlar” demek:

{
  "family": "my-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "nginx:latest",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Şimdi, insanların genelde hata yaptığı yer: CPU ve bellek değerleri. Bunlar rastgele değil. Fargate’in desteklediği belirli kombinasyonlar var:

CPU (vCPU)	Bellek Değerleri (GB)
0.25	0.5, 1, 2
0.5	1, 2, 3, 4
1	2, 3, 4, 5, 6, 7, 8
2	4-16 (1GB artışlarla)
4	8-30 (1GB artışlarla)
8	16-60 (4GB artışlarla)
16	32-120 (8GB artışlarla)

Yanlış seçin ve AWS size kibarca tekrar denemenizi söyleyecek. Bu genellikle EC2’den bir task definition kopyala-yapıştır yapıldığında ve task’lar başlamadığında ortaya çıkar.

Network Dansı

Fargate sadece awsvpc network modunu destekliyor, bu da her task’ın özel IP’li kendi elastic network interface’ini (ENI) aldığı anlamına geliyor. Bu güvenlik için aslında harika, ama VPC tasarımınızı düşünmeniz gerekiyor.

İşte Terraform kullanarak çalışan bir örnek (çünkü console’da tıklamak çabuk sıkıcı hale geliyor):

resource "aws_ecs_service" "my_app" {
  name  = "my-app-service"
  cluster  = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.my_app.arn
  desired_count  = 2
  launch_type  = "FARGATE"

  network_configuration {
    subnets  = aws_subnet.private[*].id
    security_groups  = [aws_security_group.ecs_tasks.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.my_app.arn
    container_name  = "my-app"
    container_port  = 80
  }
}

# Önemli: Fargate 'ip' target type istiyor, 'instance' değil
resource "aws_lb_target_group" "my_app" {
  name  = "my-app-tg"
  port  = 80
  protocol  = "HTTP"
  vpc_id  = aws_vpc.main.id
  target_type = "ip"  # <-- Bu Fargate için kritik
  
  health_check {
    enabled  = true
    healthy_threshold  = 2
    unhealthy_threshold = 2
    timeout  = 5
    interval  = 30
    path  = "/health"
    matcher  = "200"
  }
}

Fargate Ne Zaman Mantıklı (Ve Ne Zaman Değil)

Hem Fargate hem de EC2’de workload çalıştırırken, kararı çerçevelemenin pratik bir yolu şöyle:

Fargate’i Kullanın:

• Tahmin edilemeyen veya ani yükselen workload’larınız varsa
• Ekibiniz küçükse ve altyapı yerine koda odaklanmayı tercih ediyorsanız
• Birçok küçük, izole servis çalıştırıyorsanız
• Uyumluluk workload izolasyonu gerektiriyorsa
• Zaten “container’larla düşünüyorsanız”

EC2’de Kalın:

• GPU instance’larına ihtiyacınız varsa (Fargate desteklemiyor)
• Özel gereksinimleri olan Windows container’ları çalıştırıyorsanız
• Maliyet birincil endişenizse ve tahmin edilebilir, yüksek kullanımınız varsa
• Privileged container’lar çalıştırmanız veya kernel modülleri yüklemeniz gerekiyorsa
• Önemli tasarruflar için Spot instance’ları kullanmak istiyorsanız

Maliyet Gerçeklik Kontrolü

Fiyatlandırma konusunda dürüst olalım. Fargate, EC2’den hesaplama birimi başına daha pahalı. Gerçek bir serviste tipik bir karşılaştırma şöyle:

# EC2 (t3.medium, 2 vCPU, 4GB RAM)
Aylık: ~$30 (On-Demand)
Aylık: ~$19 (Reserved Instance)

# Fargate (2 vCPU, 4GB RAM)
Aylık: ~$75 (7/24 kullanım)
Aylık: ~$52 (Savings Plans ile)
Aylık: ~$23 (Fargate Spot ile - %70'e varan tasarruf)

Not: AWS fiyatlandırması bölgeye göre değişir ve zaman içinde güncellenir. Bunlar örnek amaçlı yaklaşık maliyetler - güncel fiyatları bölgenizden kontrol edin.

Fargate Spot burada özel bir bahsi hak ediyor. Kullanılmayan EC2 kapasitesinde task’ları çalıştırarak %70’e varan maliyet tasarrufu sunuyor, ancak task’lar 2 dakika önceden haber verilerek kesintiye uğrayabilir. Hataya dayanıklı workload’lar için Fargate’i şaşırtıcı derecede maliyet açısından rekabetçi hale getirebilir.

Ama bu sayıların göstermediği şey:

• OS güncellemelerine harcanan zaman yok
• Cluster kapasite planlaması yok
• Auto-scaling grup konfigürasyonu yok
• Instance sağlık izlemesi yok
• “Eyvah, cluster kapasitemiz bitti” olayları yok

Birçok takım için, ek maliyet operasyonel yükü azaltmaya değer.

Kimsenin Bahsetmediği Tuzaklar

1. Cold Start’lar Gerçek: Yeni availability zone’da ilk task başlatma 30-60 saniye sürebilir. Buna göre plan yapın.

2. ENI Limitleri: Her Fargate task’ının bir ENI’ya ihtiyacı var. VPC’nizin ENI limitine ulaşın, task’lar başlamaz. Bu özellikle yoğun bir deployment gününde ortaya çıkar.

3. SSH Erişimi Yok: Fargate container’larına SSH yapamazsınız. Debug için ECS Exec kullanın:

   aws ecs execute-command \
     --cluster my-cluster \
     --task abc123 \
     --container my-app \
     --interactive \
     --command "/bin/sh"

4. Sadece Geçici Depolama: Task’lar 20GB geçici depolama alır. Daha fazlasına mı ihtiyacınız var? EFS kullanın, ama daha yavaş I/O bekleyin.

5. Platform Versiyonları: Fargate’in platform versiyonları var (1.4.0, 1.3.0, vb.). AWS bunları otomatik günceller, ki genelde sorun olmaz, ama bazen bir şeyleri bozar. Her zaman önce staging’de test edin.

Gerçek Bir Production Setup

İşte production’da bize iyi hizmet eden bir pattern:

Bunu production’da çalıştırmadan çıkan önemli dersler:

1. Load balancing için ALB kullanın - Fargate’in IP tabanlı target’larıyla sorunsuz entegre olur
2. Fargate task’larını private subnet’lere koyun - Outbound internet için NAT gateway’ler kullanın
3. Parameter Store veya Secrets Manager kullanın - Secret’ları image’lara gömeyin
4. Düzgün logging kurun - CloudWatch Logs başlamak için iyi, ama production için Datadog veya benzeri düşünün
5. ENI tahsisini izleyin - İlk tükeneceğiniz kaynak bu

Sonuç

Fargate sihir değil ve her workload için doğru değil. Ama altyapı uzmanı olmadan container çalıştırmak isteyen ekipler için sağlam bir seçim. Evet, EC2’den daha fazla ödeyeceksiniz, ama daha iyi uyuyacaksınız.

Makul bir varsayılan: Yeni container workload’ları için Fargate ile başlayın. AWS maliyetleri kayda değer bir endişe haline geldiğinde, bu genelde iyi bir problemdir; EC2 optimizasyonuna yatırım yapacak kadar ölçeğiniz var demektir.

Container’larınız stateless ve nöbet rotasyonlarınız sessiz olsun.

Kaynaklar

• Architect for AWS Fargate for Amazon ECS - AWS Fargate mimarisini, lansman türlerini ve Fargate ile EC2 arasında seçim kriterlerini açıklayan resmi ECS Geliştirici Kılavuzu.
• Amazon ECS task definition parameters for Fargate - Fargate görevleri için CPU, bellek, ağ modu ve depolama dahil tüm görev tanımı parametrelerinin referansı.
• Fargate platform versions for Amazon ECS - Fargate platform sürümleri, çekirdek ve çalışma zamanı kombinasyonları ile yükseltme dikkat noktaları.
• Amazon ECS task networking options for Fargate - Fargate’te awsvpc ağ modunun çalışma şekli, ENI tahsisi ve görev başına güvenlik grubu ataması.
• AWS Fargate Pricing - ECS ve EKS üzerinde Fargate için vCPU ve GB bellek başına resmi fiyatlandırma; Fargate Spot indirimleri dahil.
• Automatically scale your Amazon ECS service - Fargate iş yükleri için hedef izleme, adım ölçekleme ve zamanlanmış ölçekleme seçeneklerini içeren ECS Hizmet Otomatik Ölçekleme kılavuzu.