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

İlk kez EC2 instance’larını yönetmekle feature geliştirmekten daha fazla zaman harcadığınızı fark ettiğiniz anı hatırlıyor musunuz? Evet, ben de. Sabah 3’tü, production sunucusuna SSH ile bağlanmış disk alanının neden %98 olduğunu anlamaya çalışıyordum ve aniden çok pahalı bir Linux kutusu bakıcısı olduğumu fark ettim. Bu yazıda Fargate’in ne zaman mantıklı olduğunu, ilk deployment’ı nasıl yapacağınızı ve EC2 Launch Type ile farkları ele alıyorum.

İşte AWS Fargate’in gerçekten çekici görünmeye başladığı an buydu. Aşağıda ilk task definition’ınızı nasıl oluşturacağınızı, network modunu ve EC2 vs Fargate karar kriterlerini adım adım gösteriyorum.

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.

Sonunda kafamda oturmasını sağlayan 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 kriterlerini ele alıyorum.

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)

Size Fargate’te gerçekten nasıl bir şey deploy edeceğinizi göstereyim. 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. Bunu EC2’den bir task definition kopyala-yapıştır yapıp neden başlatılmadığını merak ettikten sonra zor yoldan öğrendim.

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’lar çalıştırdıktan sonra, işte dürüst görüşüm:

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ı. Servislerimizden birinde sayıları hesapladım:

# 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

Bizim için, ek maliyet operasyonel yükü azaltmaya değdi.

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. Bunu nasıl bildiğimi sormayın.

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.

Benim kuralım: 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.