AWS Fargate 102: Kimsenin Bahsetmediği Pattern'ler

Fargate 101'de temelleri ele aldık. Bu yazıda, production workload'ları çalıştırırken ortaya çıkan gelişmiş pattern'lerden bahsedelim. Bilirsiniz, troubleshooting sırasında sistemin gerçek mekaniklerini anladığınız o anlar var. Maliyet optimizasyonu, stateful container'lar, monitoring ve güvenli deployment'larla devam ediyoruz.

Maliyet Optimizasyonu: İflas Etmeme Sanatı#

Fargate'in EC2'den daha pahalı olduğunu söylemiştik. İşte maliyetleri azaltmanın etkili yolları var: Spot, right-sizing, ARM ve Savings Plans. AWS faturaları beklenmedik şekilde artmaya başladığında, sistematik optimizasyon kritik hale gelir.

Fargate Spot: Kimsenin Kullanmadığı %70 İndirim#

Fargate Spot normal Fargate gibi, ama AWS 2 dakikalık uyarıyla container'ınızı çekebiliyor. Kulağa korkutucu mu geliyor? Aslında çoğu workload için sorun değil.

İşte akıllıca nasıl kullanılır:

resource "aws_ecs_service" "batch_processor" {  name            = "batch-processor"  cluster         = aws_ecs_cluster.main.id  task_definition = aws_ecs_task_definition.batch.arn    capacity_provider_strategy {    capacity_provider = "FARGATE_SPOT"    weight            = 4    base              = 0  }    capacity_provider_strategy {    capacity_provider = "FARGATE"    weight            = 1    base              = 2  # Her zaman 2'sini normal Fargate'te tut  }    desired_count = 10}

Bu konfigürasyon task'larınızın %80'ini Spot'ta çalıştırır (~%70 tasarruf) ve stabilite için bir baseline'ı normal Fargate'te tutar. Spot interruption oranları yükseldiğinde alarm'lar devreye girer. Bu pattern özellikle şunlar için uygundur:

• Batch işleme job'ları
• Development ve staging ortamları
• Restart'ı kaldırabilen async worker'lar
• CI/CD runner'ları

Kritik bir ders: Her zaman Spot kesintileri için CloudWatch alarm'ları kurun. Kesinti oranları arttığında, trafiği geçici olarak normal Fargate'e kaydırın:

// Spot kesintilerini ele alan Lambda fonksiyonuexport const handleSpotInterruption = async (event: any) => {  const ecs = new AWS.ECS();    // Geçici olarak normal Fargate ağırlığını artır  await ecs.putClusterCapacityProviders({    cluster: 'production',    capacityProviders: ['FARGATE', 'FARGATE_SPOT'],    defaultCapacityProviderStrategy: [      { capacityProvider: 'FARGATE', weight: 10, base: 5 },      { capacityProvider: 'FARGATE_SPOT', weight: 1, base: 0 }    ]  }).promise();    // 30 dakika sonra geri almak için timer ayarla  await scheduleReversion();};

Doğru Boyutlandırma: Goldilocks Problemi#

Birçok ekip OOM kill'lerden kaçınmak için Fargate task'larını fazla provision'lar. İşte doğru kaynak tahsisi için sistematik bir yaklaşım:

1. Büyük başla, ölç, sonra küçült

   bash

   # Cömert kaynaklarla deploy etCPU: 1024Memory: 2048
   # Bir hafta sonra, gerçek kullanımı kontrol etaws cloudwatch get-metric-statistics \  --namespace ECS/ContainerInsights \  --metric-name MemoryUtilized \  --dimensions Name=ServiceName,Value=my-service \  --statistics Average,Maximum \  --start-time 2024-01-01T00:00:00Z \  --end-time 2024-01-08T00:00:00Z \  --period 3600

2. %80 kuralını kullan: %100 değil, peak kullanımın %80'i için boyutlandır. O %20 buffer spike'ları halleder.

3. Farklı ortamlar için farklı boyutlar:

   hcl

   locals {  task_sizes = {    production = {      cpu    = "512"      memory = "1024"    }    staging = {      cpu    = "256"      memory = "512"    }    development = {      cpu    = "256"      memory = "512"    }  }}
   resource "aws_ecs_task_definition" "app" {  cpu    = local.task_sizes[var.environment].cpu  memory = local.task_sizes[var.environment].memory  # ...}

ARM + Savings Plans: Çifte İndirim#

AWS Graviton (ARM) işlemciler %20 daha ucuz ve genelde daha hızlı. Savings Plans ile birleştirin, %20 daha indirim:

# Multi-arch DockerfileFROM --platform=$BUILDPLATFORM node:18-alpine AS builderARG TARGETPLATFORMARG BUILDPLATFORMRUN echo "Building on $BUILDPLATFORM for $TARGETPLATFORM"
# Build adımlarınız burada...
FROM node:18-alpineCOPY --from=builder /app /appCMD ["node", "index.js"]

Her iki mimari için build edin:

docker buildx build \  --platform linux/amd64,linux/arm64 \  --tag myapp:latest \  --push .

Sonra task definition'ınızda:

{  "runtimePlatform": {    "cpuArchitecture": "ARM64",    "operatingSystemFamily": "LINUX"  }}

Node.js servislerini Graviton'a taşımak genellikle %30-40 tasarruf sağlar. Yaygın uyumluluk sorunları arasında x86'ya özel JNI kütüphaneleri olan eski Java uygulamaları var, ancak modern workload'ların çoğu sorunsuz geçiş yapar.

Stateful Workload'lar: Evet, Yapabilirsiniz (Ama Yapmalı mısınız?)#

Herkes container'ların stateless olması gerektiğini söyler. Herkes çoğunlukla haklı. Ama bazen state'e ihtiyacınız olur ve EFS burada hem dostunuz hem düşmanınız.

EFS: İyi, Kötü ve Çirkin#

Fargate ile EFS kurulumu:

resource "aws_efs_file_system" "shared" {  creation_token = "shared-storage"    performance_mode = "generalPurpose"  # veya daha fazla operasyon için "maxIO"  throughput_mode  = "bursting"        # veya tutarlı performans için "provisioned"    lifecycle_policy {    transition_to_ia = "AFTER_30_DAYS"  # Soğuk veride tasarruf  }}
resource "aws_ecs_task_definition" "app" {  # ... diğer konfigürasyon ...    volume {    name = "shared-storage"        efs_volume_configuration {      file_system_id          = aws_efs_file_system.shared.id      root_directory          = "/"      transit_encryption      = "ENABLED"      transit_encryption_port = 2999            authorization_config {        access_point_id = aws_efs_access_point.app.id        iam             = "ENABLED"      }    }  }    container_definitions = jsonencode([{    name = "app"    # ...    mountPoints = [{      sourceVolume  = "shared-storage"      containerPath = "/data"    }]  }])}

Gerçeklik Kontrolü:

• EFS gecikmesi: Operasyon başına 0.25–10ms (metadata daha hızlı; yerel SSD ~0.1ms)
• Throughput: 100MB/s'ye burst, general purpose modda sürdürülen ~10MB/s
• Maliyet: Yaklaşık $0.30/GB/ay (EBS$0.10). Ocak 2024 itibarıyla Fargate daha hızlı kalıcı depolama için EBS volume desteği de sunuyor

EFS Ne Zaman Mantıklı:

• Paylaşılan konfigürasyon dosyaları
• Birden fazla container'ın ihtiyaç duyduğu kullanıcı yüklemeleri
• Build cache'leri (dikkatli kilitlemeyle)
• Kesinlikle paylaşımlı dosya sistemi gereken eski uygulamalar

Ne Zaman Değil:

• Database depolama (sadece RDS kullanın)
• Yüksek frekanslı yazma işlemleri
• Geçici dosyalar (container'ın ephemeral storage'ını kullanın)
• Cache katmanları (ElastiCache kullanın)

Session Affinity Pattern'i#

Bazen sticky session'lara ihtiyacınız olur. Fargate ile nasıl yapılır:

resource "aws_lb_target_group" "app" {  name     = "app-tg"  port     = 80  protocol = "HTTP"  vpc_id   = aws_vpc.main.id  target_type = "ip"    stickiness {    type            = "app_cookie"    cookie_duration = 86400    cookie_name     = "FARGATE_SESSION"  }    health_check {    enabled = true    path    = "/health"    matcher = "200"  }}

Ancak sticky sessions ve auto-scaling iyi anlaşmaz. Task'lar beklenmedik şekilde sonlandığında, o session'lar kaybolur. Daha iyi bir yaklaşım:

1. Session verisini ElastiCache Redis'te sakla
2. Sunucu session'ları yerine JWT token'ları kullan
3. Deployment'lar sırasında bazı kullanıcıların çıkış yapacağını kabul et

Monitoring: Orada Aslında Ne Oluyor?#

Fargate'in altyapıya görünürlüğü azaltması debugging'i zorlaştırır. İşte etkili bir monitoring yaklaşımı:

Fargate Gözlemlenebilirliğinin Üç Direği#

1. CloudWatch Container Insights (Temeller)

   bash

   aws ecs put-account-setting \  --name containerInsights \  --value enabled

   Bu size CPU, bellek, network ve disk metriklerini verir. Temeller için iyi ama application-level şeyleri kaçırır.

2. Distributed Tracing için X-Ray (Bağlantılar)

   javascript

   // Node.js uygulamanıza ekleyinconst AWSXRay = require('aws-xray-sdk-core');const AWS = AWSXRay.captureAWS(require('aws-sdk'));
   // Artık tüm AWS SDK çağrıları trace ediliyorconst s3 = new AWS.S3();await s3.getObject({ Bucket: 'my-bucket', Key: 'file.txt' }).promise();

3. StatsD ile Custom Metrikler (Detaylar)

   typescript

   // StatsD için sidecar container çalıştırınconst taskDef = {  containerDefinitions: [    {      name: "app",      // uygulama config'iniz    },    {      name: "datadog-agent",      image: "datadog/agent:latest",      environment: [        { name: "DD_API_KEY", value: process.env.DD_API_KEY },        { name: "ECS_FARGATE", value: "true" }      ]    }  ]};

Saatleri Kurtaran Debug Pattern'i#

Fargate'e SSH yapamıyor musunuz? ECS Exec kullanın, ama faydalı hale getirin:

# Dockerfile'ınıza bunu ekleyinRUN apk add --no-cache \    curl \    netstat \    ps \    htop \    strace \    tcpdump
# Task definition'da ECS Exec'i etkinleştirinaws ecs update-service \  --cluster production \  --service my-service \  --enable-execute-command
# Profesyonel gibi debug yapınaws ecs execute-command \  --cluster production \  --task abc123 \  --container app \  --interactive \  --command "/bin/sh"
# Container içinde:> netstat -tulpn  # Neyin dinlediğini kontrol et> ps aux          # Tüm process'leri gör> strace -p 1     # System call'ları trace et> tcpdump -i any  # Network trafiğini izle

Blue-Green Deployment'lar: Güvenli Yol#

Fargate + CodeDeploy = zero-downtime deployment'lar. Bizi birçok kötü deploy'dan kurtaran setup:

resource "aws_codedeploy_deployment_group" "app" {  app_name               = aws_codedeploy_app.app.name  deployment_group_name  = "production"  deployment_config_name = "CodeDeployDefault.ECSLinear10PercentEvery1Minutes"    auto_rollback_configuration {    enabled = true    events  = ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]  }    blue_green_deployment_config {    terminate_blue_instances_on_deployment_success {      action                                          = "TERMINATE"      termination_wait_time_in_minutes               = 5    }        deployment_ready_option {      action_on_timeout = "CONTINUE_DEPLOYMENT"    }        green_fleet_provisioning_option {      action = "COPY_AUTO_SCALING_GROUP"    }  }    ecs_service {    cluster_name = aws_ecs_cluster.main.name    service_name = aws_ecs_service.app.name  }}

Killer özellik? CloudWatch alarm'larında otomatik rollback:

const errorRateAlarm = new cloudwatch.Alarm(this, 'ErrorRate', {  metric: new cloudwatch.Metric({    namespace: 'MyApp',    metricName: 'Errors',    statistic: 'Sum'  }),  threshold: 10,  evaluationPeriods: 2});
// Deployment group'a bağladeploymentGroup.addAlarm(errorRateAlarm);

Multi-Region Fargate: Çünkü Felaketler Olur#

Fargate'i region'lar arası çalıştırmak zor değil, ama onları senkronize tutmak öyle. Veri tutarlılığı, failover testi ve maliyet (her region ayrı faturalanır) dikkat edilmesi gereken noktalar. İşte bizim pattern'imiz:

Keşfettiğimiz tuzaklar:

1. Region başına environment variable'lar: Endpoint'leri hardcode etmeyin; her region kendi RDS, S3 ve servis endpoint'lerine sahip olmalı.
2. S3 bucket isimleri global olarak benzersiz olmalı: Region veya account suffix ekleyin.
3. Cross-region gecikme: Region çiftine göre 80–150ms (us-east-1–eu-west-1 genelde ~90ms).
4. Failover anında değil: Route 53 health check'leri tipik 30–60 saniye alır; bunu disaster recovery planınıza yazın.

Production Fargate için Temel Pattern'ler#

Sidecar Pattern'i#

{  "containerDefinitions": [    {      "name": "app",      "dependsOn": [{        "containerName": "envoy",        "condition": "HEALTHY"      }]    },    {      "name": "envoy",      "healthCheck": {        "command": ["CMD-SHELL", "curl -f http://localhost:9901/ready || exit 1"]      }    }  ]}

Init Container Pattern'i (Bir Nevi)#

Fargate'in gerçek init container'ları yok, ama taklit edebilirsiniz:

# Entrypoint script'inizde#!/bin/shecho "Initialization çalıştırılıyor..."/app/init-db.shif [ $? -ne 0 ]; then  echo "Init başarısız, çıkılıyor"  exit 1fiecho "Ana uygulama başlatılıyor..."exec node index.js

Circuit Breaker Pattern'i#

Harici servis çağrıları için circuit breaker kullan. Timeout ve retry ile birlikte cascading failure'ı önle. Bir servis sürekli hata veriyorsa diğerlerinin de çökmesini engeller.

class FargateCircuitBreaker {  private failures = 0;  private lastFailTime = 0;  private readonly threshold = 5;  private readonly timeout = 60000; // 1 dakika    async call<T>(fn: () => Promise<T>): Promise<T> {    if (this.isOpen()) {      throw new Error('Circuit breaker açık');    }        try {      const result = await fn();      this.onSuccess();      return result;    } catch (error) {      this.onFailure();      throw error;    }  }    private isOpen(): boolean {    return this.failures >= this.threshold &&            Date.now() - this.lastFailTime < this.timeout;  }    private onSuccess(): void {    this.failures = 0;  }    private onFailure(): void {    this.failures++;    this.lastFailTime = Date.now();  }}

Unutmayın: Fargate bir İsviçre çakısı gibi. İnanılmaz faydalı, ama dikkatli olmazsanız ara sıra kendinizi kesersiniz.