AWS EC2 Instance Türleri ve Doğru Instance Seçim Rehberi

Tarafındankomut
0 Comments

AWS’de yeni bir proje başlatırken ya da mevcut altyapını optimize etmeye çalışırken, karşına çıkan ilk büyük karar instance türü seçimidir. Yanlış seçim, hem performans sorunlarına hem de gereksiz maliyetlere yol açar. Bu rehberde EC2 instance türlerini derinlemesine inceleyeceğiz ve hangi senaryoda ne kullanman gerektiğini pratik örneklerle açıklayacağız.

EC2 Instance Ailelerini Anlamak

AWS, instance’ları iş yüküne göre optimize edilmiş farklı ailelere ayırır. Her ailenin bir kodu vardır ve bu kodu okumayı öğrenmek, doğru seçim yapmanın temel adımıdır.

Instance adını oluşturan parçaları ele alalım: m7g.2xlarge gibi bir isimde ilk harf aileyi (m = general purpose), sayı nesili (7 = 7. nesil), sonraki harf işlemci/özellik tipini (g = Graviton), nokta sonrası ise boyutu ifade eder.

Genel Amaçlı Instance’lar (M ve T Serisi)

M serisi, dengeli CPU ve RAM oranı sunar. Production ortamlar için varsayılan tercih bu seridir.

T serisi, burstable performance sunar. Temel bir CPU kredisi sistemi üzerinde çalışır. Geliştirme ortamları, düşük trafikli uygulamalar ve test sunucuları için idealdir.

# Mevcut instance tipini öğrenmek
curl -s http://169.254.169.254/latest/meta-data/instance-type

# Instance metadata'sına erişim (IMDSv2 ile)
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" 
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" 
  http://169.254.169.254/latest/meta-data/instance-type

T3 instance’larında CPU kredisi durumunu izlemek kritik önem taşır. Kredi bittiğinde instance ciddi şekilde yavaşlar.

# AWS CLI ile CPU kredi bakiyesini kontrol et
aws cloudwatch get-metric-statistics 
  --namespace AWS/EC2 
  --metric-name CPUCreditBalance 
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 
  --start-time 2024-01-01T00:00:00Z 
  --end-time 2024-01-01T23:59:59Z 
  --period 3600 
  --statistics Average 
  --region us-east-1

Compute Optimized Instance’lar (C Serisi)

C serisi, yüksek CPU performansı gerektiren iş yükleri için tasarlanmıştır. CPU/RAM oranı, M serisine kıyasla CPU lehine daha yüksektir.

Kullanım alanları:

  • Yüksek trafikli web sunucuları
  • Batch processing işlemleri
  • Video encoding ve medya transcoding
  • Bilimsel hesaplamalar
  • Makine öğrenmesi inference

Gerçek dünya örneği: Bir video streaming platformunda FFmpeg ile 4K video transcoding yapıyorsanız, m5.2xlarge yerine c5.2xlarge kullanmak hem daha hızlı işlem süresi hem de daha iyi maliyet/performans oranı sağlar.

# C serisi instance üzerinde CPU performansını test et
sysbench cpu --cpu-max-prime=20000 --num-threads=$(nproc) run

# FFmpeg ile transcoding performansı ölç
time ffmpeg -i input_4k.mp4 
  -vcodec libx264 
  -preset fast 
  -crf 23 
  output_1080p.mp4

Memory Optimized Instance’lar (R, X ve Z Serisi)

R serisi, yüksek RAM gerektiren uygulamalar için standart tercih. RAM/CPU oranı M serisinin yaklaşık iki katıdır.

X serisi, devasa RAM kapasitesi sunar. X2gd.16xlarge ile 1024 GB RAM’e kadar çıkabilirsiniz. SAP HANA gibi in-memory database’ler için kullanılır.

Z serisi, yüksek frekansla çalışan tek bir işleme ihtiyaç duyan, lisans bazlı yazılımlar (Oracle gibi) için tercih edilir. Çekirdek başına lisans maliyetini düşürmek isteyenler için idealdir.

R serisi kullanım senaryoları:

  • Redis ve Memcached gibi in-memory cache sunucuları
  • Büyük veritabanları (PostgreSQL, MySQL, MongoDB)
  • Hadoop ve Spark cluster’ları
  • SAP uygulamaları
# Memory kullanımını detaylı izle
watch -n 5 'free -h && echo "---" && 
  ps aux --sort=-%mem | head -20'

# Redis bellek kullanımını kontrol et
redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

Storage Optimized Instance’lar (I, D ve H Serisi)

I serisi, NVMe SSD tabanlı yerel depolama sunar. Çok düşük latency gerektiren OLTP veritabanları için kullanılır.

D serisi, HDD tabanlı yoğun depolama sunar. Büyük veri analitiği, data warehouse ve Hadoop workload’ları için tercih edilir.

I serisi özellikleri:

  • i3.16xlarge: 25 TB NVMe SSD
  • Sub-millisecond disk latency
  • Yüksek IOPS kapasitesi
  • Cassandra, MongoDB, Elasticsearch gibi NoSQL DB’ler için ideal
# Disk I/O performansını test et
fio --name=randwrite 
  --ioengine=libaio 
  --iodepth=32 
  --rw=randwrite 
  --bs=4k 
  --direct=1 
  --size=10G 
  --numjobs=4 
  --runtime=60 
  --group_reporting

# Mevcut disk IOPS'u izle
iostat -x 1 10

Accelerated Computing Instance’lar (P, G, Trn ve Inf Serisi)

GPU gerektiren iş yükleri için bu ailelere bakman gerekir.

P serisi, NVIDIA A100 ve H100 GPU’lar ile makine öğrenmesi training için kullanılır. p4d.24xlarge’da 8 adet A100 GPU bulunur.

G serisi, grafik yoğun uygulamalar ve ML inference için kullanılır. Virtual desktop altyapıları (VDI) için de tercih edilir.

Trn serisi, AWS’in kendi geliştirdiği Trainium çipleriyle ML training yapar. P serisine göre daha maliyet etkin olabilir.

Inf serisi, Inferentia çipleriyle ML inference yapar. Özellikle büyük dil modelleri için optimize edilmiştir.

# GPU instance'da NVIDIA GPU durumunu kontrol et
nvidia-smi

# GPU bellek kullanımını izle
nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu 
  --format=csv -l 5

# CUDA'nın kurulu olup olmadığını kontrol et
nvcc --version && python3 -c "import torch; print(torch.cuda.is_available())"

Graviton İşlemciler: ARM Tabanlı Seçenek

AWS’in kendi geliştirdiği Graviton işlemciler (g eki ile gösterilir), geleneksel x86 instance’lara kıyasla ciddi maliyet avantajı sunar. Graviton3 tabanlı m7g, c7g, r7g gibi instance’lar genellikle muadillerine göre yüzde 20-40 daha ucuz olur ve benzer ya da daha iyi performans sağlar.

# Graviton instance mimarisini doğrula
uname -m
# Çıktı: aarch64

# Uygulamanın ARM64 için derlenip derlenmediğini kontrol et
file /usr/bin/nginx

# Docker üzerinde ARM64 image kontrolü
docker inspect nginx:latest | grep Architecture

Graviton’a geçiş öncesi kontrol listesi:

  • Tüm bağımlılıkların ARM64 destekleyip desteklemediğini kontrol et
  • Özel kernel modülleri varsa yeniden derleme gerekebilir
  • JVM tabanlı uygulamalar genellikle sorunsuz çalışır
  • Python ve Node.js uygulamaları büyük ölçüde sorunsuz geçiş yapar

Instance Seçiminde Karar Süreci

Adım 1: İş Yükünü Tanımla

Önce şunu netleştir: Darboğazın CPU mu, RAM mi, disk I/O mu, yoksa ağ bandwidthı mı?

# Mevcut sunucuda kaynak kullanımını analiz et (göç öncesi)
# CPU kullanımı
mpstat -P ALL 1 60 | tail -20

# Memory kullanımı
vmstat -s | head -10

# Disk I/O
iotop -b -n 5 | head -30

# Network trafiği
iftop -t -s 30 2>/dev/null | tail -20

Adım 2: Boyutlandırma (Sizing)

Aşırı boyutlandırmaktan kaç: Bir t3.micro yeterliyken m5.2xlarge almak para israfıdır.

Yetersiz boyutlandırmaktan kaç: Production’da performans sorunları yaşamak, aceleyle instance yükseltmesi yapmak hem zahmetlidir hem de downtime riski taşır.

İdeal yaklaşım: Başlangıçta biraz fazla al, CloudWatch metrikleriyle izle, ardından optimize et.

# AWS CLI ile instance önerisi için Compute Optimizer sonuçlarını çek
aws compute-optimizer get-ec2-instance-recommendations 
  --region us-east-1 
  --output json | jq '.instanceRecommendations[] | {
    instance: .instanceArn,
    currentType: .currentInstanceType,
    recommendedType: .recommendationOptions[0].instanceType,
    estimatedSavings: .recommendationOptions[0].estimatedMonthlySavings
  }'

Adım 3: Maliyet Optimizasyonu

On-Demand vs Reserved vs Spot:

On-Demand:

  • Saatlik ödeme
  • Commitment yok
  • Development, test ortamları için ideal
  • Unpredictable workload’lar için

Reserved Instances (RI):

  • 1 veya 3 yıllık commitment
  • Yüzde 30-72 arası tasarruf
  • Production baseline workload’lar için ideal
  • Standard RI, Convertible RI ve Scheduled RI seçenekleri var

Spot Instances:

  • Yüzde 60-90 tasarruf mümkün
  • Kesintiye uğrayabilir (2 dakika önceden uyarı verilir)
  • Batch processing, ML training, stateless uygulamalar için ideal
  • Kritik production workload’lar için tek başına kullanma
# Spot instance fiyat geçmişini sorgula
aws ec2 describe-spot-price-history 
  --instance-types m5.xlarge 
  --product-descriptions "Linux/UNIX" 
  --availability-zone us-east-1a 
  --start-time 2024-01-01T00:00:00Z 
  --query 'SpotPriceHistory[*].{Time:Timestamp,Price:SpotPrice}' 
  --output table

# Spot instance başlatma
aws ec2 run-instances 
  --image-id ami-0abcdef1234567890 
  --instance-type m5.xlarge 
  --instance-market-options MarketType=spot,SpotOptions={MaxPrice=0.05,SpotInstanceType=one-time} 
  --key-name my-key-pair 
  --security-group-ids sg-12345678 
  --subnet-id subnet-12345678

Gerçek Dünya Senaryoları

Senaryo 1: E-ticaret Web Uygulaması

Orta ölçekli bir e-ticaret platformu için tipik stack:

  • Web katmanı: t3.medium (düşük trafik dönemlerinde) veya c5.large (yoğun trafik için). Auto Scaling Group ile 2-10 instance arasında ölçeklendir.
  • Application server: m5.xlarge. Dengeli CPU/RAM oranı çoğu web framework için yeterli.
  • Veritabanı (RDS): r5.large. Yüksek RAM, buffer pool için kritik.
  • Redis cache: r6g.medium. Graviton ile maliyet tasarrufu.
  • Elasticsearch: r5.large. Full-text search için bellek kritik.

Senaryo 2: Büyük Veri İşleme Pipeline’ı

Gece çalışan batch ETL işlemleri için:

  • Spot instance ile c5.4xlarge veya m5.4xlarge kullan
  • EMR cluster için i3 serisi tercih et
  • İş tamamlandığında instance’ları kapat, sadece kullandığın kadar öde
# Spot interruption notice'ı yakala ve graceful shutdown yap
#!/bin/bash
# spot-interruption-handler.sh

METADATA_URL="http://169.254.169.254/latest/meta-data/spot/interruption-notice"
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" 
  -H "X-aws-ec2-metadata-token-ttl-seconds: 30")

while true; do
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" 
    -H "X-aws-ec2-metadata-token: $TOKEN" 
    $METADATA_URL)
  
  if [ "$HTTP_CODE" -eq 200 ]; then
    echo "$(date): Spot interruption notice alindi! Graceful shutdown basliyor..."
    # Mevcut işi checkpoint'e kaydet
    # Gerekli cleanup işlemlerini yap
    systemctl stop myapp
    aws s3 sync /data/checkpoint s3://my-bucket/checkpoint/
    break
  fi
  
  sleep 5
done

Senaryo 3: ML Model Training

PyTorch ile büyük bir modeli train edeceksen:

  • Geliştirme/deneme: g4dn.xlarge (1x T4 GPU, makul fiyat)
  • Ciddi training: p3.8xlarge (4x V100 GPU) veya p4d.24xlarge (8x A100)
  • Maliyet odaklı training: trn1.32xlarge (AWS Trainium)
  • Inference: inf2.xlarge (AWS Inferentia)

Instance Performansını İzleme

Doğru instance seçseniz bile izleme yapmadan optimize edemezsiniz.

# CloudWatch'a özel metrik gönder
#!/bin/bash
# custom-metrics.sh

INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $(curl -s -X PUT 
  http://169.254.169.254/latest/api/token 
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 30')" 
  http://169.254.169.254/latest/meta-data/instance-id)

# Memory kullanımını CloudWatch'a gönder
MEMORY_USAGE=$(free | grep Mem | awk '{printf "%.2f", $3/$2 * 100.0}')

aws cloudwatch put-metric-data 
  --namespace "CustomMetrics/EC2" 
  --metric-name "MemoryUtilization" 
  --value $MEMORY_USAGE 
  --unit Percent 
  --dimensions InstanceId=$INSTANCE_ID 
  --region us-east-1

echo "Memory kullanimi: %$MEMORY_USAGE gonderildi"

İzlenmesi gereken temel metrikler:

  • CPUUtilization: Sürekli yüzde 80 üzerindeyse CPU optimize instance’a geç
  • CPUCreditBalance: T serisi için kritik, sıfıra yaklaştığında uyarı kur
  • NetworkIn/NetworkOut: Ağ yoğun uygulamalar için network optimized instance düşün
  • EBSReadOps/EBSWriteOps: Disk I/O bottleneck varsa storage optimized’a geç
  • MemoryUtilization: CloudWatch agent ile custom metrik olarak topla

Sık Yapılan Hatalar

Yanlış aile seçimi: Veritabanı için M serisi yerine C serisi seçmek. CPU yeterlidir ama RAM yetersiz gelir ve swap kullanımı başlar.

Nesil atlamak: m3 veya m4 hala kullanıyorsanız m7g’ye geçiş hem performans hem maliyet açısından büyük fark yaratır. AWS yeni nesillere geçişi teşvik etmek için eski nesilleri zaman zaman fiyat avantajsız bırakır.

T serisi production kullanımı: T3 instance’lar geliştirme için harika ama production’da CPU burst ihtiyacı öngörülemez şekilde artabilir. Unlimited mod aktifse ek ücret alınır.

EBS optimizasyonunu ihmal etmek: Bazı eski instance tipleri EBS-optimized değildir. Modern instance’ların tamamı varsayılan olarak EBS-optimized gelir.

Reserved Instance’ları yanlış planlamak: 3 yıllık commitment alıp 6 ay sonra instance tipi değiştirme ihtiyacı duyabilirsin. Convertible RI bu riski azaltır.

Migrate Sırasında Instance Değiştirme

# Instance tipini değiştirmek için stop gerekli
# Önce snapshot al
aws ec2 create-snapshot 
  --volume-id vol-1234567890abcdef0 
  --description "Pre-migration snapshot $(date +%Y%m%d)"

# Instance'ı durdur
aws ec2 stop-instances --instance-ids i-1234567890abcdef0

# Instance tipini değiştir
aws ec2 modify-instance-attribute 
  --instance-id i-1234567890abcdef0 
  --instance-type Value=m5.2xlarge

# Instance'ı başlat
aws ec2 start-instances --instance-ids i-1234567890abcdef0

# Yeni tipi doğrula
aws ec2 describe-instances 
  --instance-ids i-1234567890abcdef0 
  --query 'Reservations[0].Instances[0].InstanceType'

Sonuç

EC2 instance seçimi tek seferlik bir karar değil, sürekli optimize etmen gereken bir süreçtir. Başlangıçta iş yükünü doğru analiz et, uygun aileyi seç, boyutlandırmayı veri ile destekle ve maliyet optimizasyonu için Reserved veya Spot seçeneklerini değerlendir.

Genel öneriler şöyle özetlenebilir: Yeni başlıyorsan m7g serisi iyi bir başlangıç noktasıdır. Graviton işlemciler artık olgunlaştı ve çoğu workload için sorunsuz çalışıyor. CPU ağırlıklı işler için c serisi, bellek ağırlıklı işler için r serisi mantıklı tercih. ML işleri için p veya trn serisine bak. Dev/test ortamları için mutlaka t3 veya t4g kullan, burada tasarruf edersin.

AWS Compute Optimizer’ı aktif et ve aylık önerilerini incele. Ücretsiz bir hizmet ve sana hangi instance’ların over-provisioned olduğunu söyler. Sysadmin olarak en büyük değeri, doğru altyapıyı doğru fiyata çalıştırmakla yaratırsın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir