Bulut Depolama Katmanları: Hot, Cool ve Archive Karşılaştırması

Tarafındankomut
0 Yorum

Bulut ortamında depolama maliyetleri, çoğu zaman hesaplanmayan bir gider kalemi olarak karşımıza çıkar. Yeni bir proje kuruyorsunuz, her şeyi default ayarlarla S3’e ya da Azure Blob’a atıyorsunuz, aylar sonra faturaya bakıp şaşırıyorsunuz. İşte bu noktada depolama katmanları devreye giriyor. Hot, Cool ve Archive katmanlarını doğru kullanmak, ciddi maliyet optimizasyonu sağlarken veri erişim ihtiyaçlarınızı da karşılayabilir. Bu yazıda bu üç katmanı derinlemesiyle inceleyeceğiz, gerçek senaryolar üzerinden karşılaştıracağız ve hangi verinin nerede durması gerektiğini somut örneklerle göstereceğiz.

Depolama Katmanları Neden Var?

Bulut sağlayıcıları bir şeyi çok erken fark etti: Tüm veriler eşit değil. Bir e-ticaret sitesinin bugünkü sipariş verileriyle iki yıl önceki sipariş verileri aynı erişim sıklığına sahip değil. Biri her saniye sorgulanıyor, diğeri belki yılda bir kez yasal gereklilik nedeniyle açılıyor.

Bu gerçekten hareketle bulut sağlayıcıları farklı maliyet/performans profilleri sunan katmanlı depolama sistemleri geliştirdi. Temel mantık şu: Ne kadar sık erişirsen o kadar pahalı depola, erişim azaldıkça daha ucuz ancak erişimi daha yavaş olan katmanlara taşı.

Üç ana kategori var:

  • Hot (Sık Erişilen): Yüksek depolama maliyeti, düşük erişim maliyeti, anlık erişim
  • Cool/Warm (Seyrek Erişilen): Orta depolama maliyeti, orta erişim maliyeti, birkaç saniye gecikme
  • Archive (Arşiv): Çok düşük depolama maliyeti, yüksek erişim maliyeti, saatler süren geri yükleme

AWS S3 Üzerinde Katmanlar

AWS, S3 ile bu konsepti en gelişmiş hale getiren sağlayıcılardan biri. Birkaç farklı storage class sunuyor ama temel üçlüye odaklanacağız.

S3 Standard (Hot)

Varsayılan katman. Aktif uygulamalar, sık erişilen medya dosyaları, anlık analiz verileri için kullanılır. Gecikme milisaniye seviyesinde, dayanıklılık %99.999999999 (11 dokuz).

S3 Standard-IA ve S3 Glacier Instant Retrieval (Cool)

Standard-IA (Infrequent Access) ayda birkaç kez erişilen veriler için tasarlanmış. Depolama maliyeti düşük ama her GET isteğinde ek bir erişim ücreti ödüyorsunuz. En az 30 gün depolama zorunluluğu var.

S3 Glacier ve S3 Glacier Deep Archive (Archive)

Glacier Flexible Retrieval için geri yükleme süresi dakikalar ile saatler arasında değişiyor. Deep Archive ise en ucuz seçenek, ama 12 saate kadar beklemeniz gerekebilir. Uzun vadeli yasal saklama, felaket kurtarma yedekleri için ideal.

S3 Intelligent-Tiering

AWS’nin otomatik katmanlama özelliği. Erişim pattern’larını izleyerek veriyi otomatik olarak uygun katmana taşıyor. Her nesne için küçük bir izleme ücreti var ama büyük veri kümelerinde kendini amorti ediyor.

# S3 bucket oluşturma ve versioning aktifleştirme
aws s3api create-bucket 
  --bucket my-tiered-storage-bucket 
  --region eu-west-1 
  --create-bucket-configuration LocationConstraint=eu-west-1

aws s3api put-bucket-versioning 
  --bucket my-tiered-storage-bucket 
  --versioning-configuration Status=Enabled
# Lifecycle policy JSON dosyası oluşturma
cat > lifecycle-policy.json << 'EOF'
{
  "Rules": [
    {
      "ID": "TransitionToIA",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        },
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ]
    }
  ]
}
EOF

# Lifecycle policy uygulama
aws s3api put-bucket-lifecycle-configuration 
  --bucket my-tiered-storage-bucket 
  --lifecycle-configuration file://lifecycle-policy.json

Bu lifecycle policy ile log dosyalarınız 30 günde bir Standard-IA’ya, 90 günde Glacier’a, 365 günde ise Deep Archive’a geçiyor. Hiçbir manuel işlem gerektirmiyor.

# Mevcut dosyaları farklı storage class ile yükleme
aws s3 cp localfile.txt s3://my-tiered-storage-bucket/archive/ 
  --storage-class GLACIER

# Bucket içindeki nesnelerin storage class bilgilerini listele
aws s3api list-objects-v2 
  --bucket my-tiered-storage-bucket 
  --query 'Contents[].{Key:Key,StorageClass:StorageClass,Size:Size}' 
  --output table

# Glacier'dan dosya geri yükleme (Expedited: 1-5 dakika, Standard: 3-5 saat)
aws s3api restore-object 
  --bucket my-tiered-storage-bucket 
  --key archive/old-backup.tar.gz 
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Expedited"}}'

Azure Blob Storage Katmanları

Azure, benzer bir yapıyı Blob Storage üzerinden sunuyor. Hot, Cool ve Archive olmak üzere üç katman var. Burada ilginç olan şu: Azure’da katman değiştirme blob seviyesinde yapılabiliyor, yani aynı container içinde farklı katmanlarda dosyalarınız olabilir.

Azure Hot Tier

Günlük kullanılan veriler için. Web uygulamalarının statik içerikleri, aktif veri tabanı yedekleri, işlenmekte olan dosyalar. Depolama GB başına maliyeti en yüksek ama işlem maliyeti en düşük.

Azure Cool Tier

En az 30 gün tutulacak, seyrek erişilen veriler için. Kısa vadeli yedekleme, eski proje dosyaları. İlginç bir detay: Cool tier’da early deletion ücreti var, 30 günden önce silerseniz kalan süre için ücret ödersiniz.

Azure Archive Tier

En az 180 gün tutulacak veriler için tasarlanmış. Erişim gerektiğinde blob önce “rehydrate” edilmeli, bu işlem High Priority ile saatler, Standard Priority ile 15 saate kadar sürebilir. Rehydration işleminin kendisi de ücretli.

# Azure CLI ile storage account oluşturma
az storage account create 
  --name mystorageaccount001 
  --resource-group myResourceGroup 
  --location westeurope 
  --sku Standard_LRS 
  --kind StorageV2 
  --access-tier Hot

# Container oluşturma
az storage container create 
  --name mycontainer 
  --account-name mystorageaccount001 
  --auth-mode login

# Dosyayı Cool tier'a yükleme
az storage blob upload 
  --container-name mycontainer 
  --file ./backup-2023.tar.gz 
  --name backup-2023.tar.gz 
  --account-name mystorageaccount001 
  --tier Cool

# Mevcut bir blob'un tier'ini değiştirme
az storage blob set-tier 
  --container-name mycontainer 
  --name old-backup-2022.tar.gz 
  --tier Archive 
  --account-name mystorageaccount001
# Azure Lifecycle Management Policy JSON
cat > azure-lifecycle.json << 'EOF'
{
  "rules": [
    {
      "name": "archiveOldBackups",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["backups/"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            },
            "delete": {
              "daysAfterModificationGreaterThan": 730
            }
          }
        }
      }
    }
  ]
}
EOF

# Policy uygulama
az storage account management-policy create 
  --account-name mystorageaccount001 
  --resource-group myResourceGroup 
  --policy @azure-lifecycle.json
# Archive'dan rehydrate etme
az storage blob set-tier 
  --container-name mycontainer 
  --name archived-file.tar.gz 
  --tier Hot 
  --rehydrate-priority High 
  --account-name mystorageaccount001

# Blob durumunu kontrol etme (rehydration tamamlandı mı?)
az storage blob show 
  --container-name mycontainer 
  --name archived-file.tar.gz 
  --account-name mystorageaccount001 
  --query "properties.archiveStatus"

Google Cloud Storage Katmanları

GCP’de storage class’lar biraz farklı isimlendirilmiş ama mantık aynı:

  • Standard Storage: Hot verilere karşılık geliyor
  • Nearline Storage: Ayda en az bir kez erişilen veriler, minimum 30 gün
  • Coldline Storage: 3 ayda bir erişilen veriler, minimum 90 gün
  • Archive Storage: Yılda bir kereden az erişilen veriler, minimum 365 gün

GCP’nin güzel özelliği Object Lifecycle Management. Basit JSON tanımıyla otomatik geçişler kurabiliyorsunuz.

# GCS bucket oluşturma
gsutil mb -c STANDARD -l EU gs://my-tiered-bucket-example

# Lifecycle policy JSON
cat > gcs-lifecycle.json << 'EOF'
{
  "rule": [
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "NEARLINE"
      },
      "condition": {
        "age": 30,
        "matchesStorageClass": ["STANDARD"]
      }
    },
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "COLDLINE"
      },
      "condition": {
        "age": 90,
        "matchesStorageClass": ["NEARLINE"]
      }
    },
    {
      "action": {
        "type": "SetStorageClass",
        "storageClass": "ARCHIVE"
      },
      "condition": {
        "age": 365,
        "matchesStorageClass": ["COLDLINE"]
      }
    }
  ]
}
EOF

gsutil lifecycle set gcs-lifecycle.json gs://my-tiered-bucket-example

# Mevcut lifecycle policy görüntüleme
gsutil lifecycle get gs://my-tiered-bucket-example

# Dosyayı Coldline olarak yükleme
gsutil -o GSUtil:default_project_id=my-project 
  cp -s COLDLINE ./annual-report-2022.pdf 
  gs://my-tiered-bucket-example/reports/

Gerçek Dünya Senaryoları

Senaryo 1: E-Ticaret Platformu Log Yönetimi

Bir e-ticaret platformunun uygulama loglarını yönettiğinizi düşünün. Günde yaklaşık 50 GB log üretiliyor. Şu andaki durum: Her şey S3 Standard’da, yıllık maliyet uçuyor.

Çözüm stratejisi:

  • Son 7 gün: S3 Standard (aktif debug ve monitoring için anlık erişim şart)
  • 7-30 gün: S3 Standard-IA (bir şeyler ters gittiğinde araştırma için erişiyorsunuz, ama her gün değil)
  • 30-365 gün: S3 Glacier Instant Retrieval (aylık raporlar için ara sıra erişim)
  • 365 gün sonrası: S3 Glacier Deep Archive (yasal saklama zorunluluğu, erişim neredeyse yok)

Bu stratejiyle yaklaşık %60-70 maliyet düşüşü sağlayabilirsiniz. 50 GB günlük log için yıllık S3 Standard maliyeti ciddi bir rakam, katmanlı yaklaşımla bu maliyet dramatik şekilde azalıyor.

Senaryo 2: Medya Şirketi Video Arşivi

Bir medya şirketinin 10 yıllık video arşivini yönetiyorsunuz. Yeni yayınlar sürekli erişiliyor, eski içerikler ise nadiren açılıyor.

  • Son 3 ay içindeki içerikler: Hot tier (aktif streaming, yüksek erişim)
  • 3 ay ile 2 yıl arası: Cool tier (talep üzerine yayın, seyrek erişim)
  • 2 yıldan eski: Archive tier (lisans yenileme veya özel talep durumunda geri yükleme)

Burada dikkat edilmesi gereken nokta: Bir arşiv içeriğine talep geldiğinde rehydration süresini kullanıcıya açıkça belirtmek gerekiyor. “Bu içerik 2-4 saat içinde hazır olacak” mesajı beklenmedik bir deneyim yaratabilir.

Senaryo 3: Fintech Şirketinde Yasal Saklama

Finans sektöründe işlem kayıtları genellikle 5-7 yıl saklanmak zorunda. Her ay yüzlerce GB işlem verisi oluşuyor ve bunların büyük çoğunluğuna bir daha asla erişilmeyecek, ancak denetim durumunda hazır olması şart.

Bu senaryo için Deep Archive veya Azure Archive mükemmel bir fit. Depolama maliyeti minimumda, erişim gecikmeyi yasal denetimler zaten tolere eder. Ama burada kritik bir nokta var: Şifreleme ve erişim kontrolü eksiksiz olmalı, çünkü bu verilerin güvenliği hem yasal hem kurumsal bir zorunluluk.

Katman Seçiminde Dikkat Edilmesi Gereken Noktalar

Minimum Depolama Süresi Tuzağı

Her sağlayıcıda farklı minimum depolama süresi var:

  • Azure Cool: 30 gün minimum
  • S3 Standard-IA: 30 gün minimum
  • S3 Glacier: 90 gün minimum
  • Azure Archive: 180 gün minimum
  • S3 Glacier Deep Archive: 180 gün minimum
  • GCS Archive: 365 gün minimum

Eğer bir dosyayı bu sürelerden önce silerseniz veya katman değiştirirseniz, kalan süre için ücret ödüyorsunuz. Bu yüzden yaşam döngüsü politikalarını iyi planlamak çok önemli.

Erişim Maliyeti Hesabı

Sık erişilen veriler için Cool veya Archive kullanmak paradoksal şekilde daha pahalıya patlayabilir. Örneğin:

  • S3 Standard: 1000 GET isteği için $0.0004
  • S3 Glacier Instant Retrieval: 1000 GET isteği için $0.01

25 kat daha pahalı erişim maliyeti, düşük depolama maliyetini çabuk ezip geçebilir. Erişim pattern’larınızı gerçekten analiz edin, varsayımlara güvenmeyin.

Veri Transfer Maliyetleri

Özellikle rehydration işlemlerinde veri transfer maliyetleri göz ardı edilemez. Glacier Deep Archive’dan terabaytlarca veri çekecekseniz, bu işlemin maliyetini önceden hesaplayan bir tahmin yapın.

# AWS Cost Explorer ile storage maliyetlerini analiz etme
aws ce get-cost-and-usage 
  --time-period Start=2024-01-01,End=2024-12-31 
  --granularity MONTHLY 
  --metrics "UnblendedCost" 
  --group-by Type=DIMENSION,Key=SERVICE 
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Simple Storage Service"]}}'

# S3 Storage Lens ile erişim pattern analizi
aws s3control get-storage-lens-dashboard 
  --config-id my-storage-lens 
  --account-id 123456789012 
  --region us-east-1

Katmanlar Arası Otomatik Geçiş Stratejileri

Manuel katman yönetimi ölçeklenmiyor. Yüzlerce bucket, binlerce prefix ile uğraşırken automation şart. İşte benim production’da kullandığım basit bir Python scripti:

#!/usr/bin/env python3
import boto3
from datetime import datetime, timezone, timedelta

def analyze_bucket_costs(bucket_name):
    s3 = boto3.client('s3')
    paginator = s3.get_paginator('list_objects_v2')
    
    storage_summary = {
        'STANDARD': {'count': 0, 'size': 0},
        'STANDARD_IA': {'count': 0, 'size': 0},
        'GLACIER': {'count': 0, 'size': 0},
        'DEEP_ARCHIVE': {'count': 0, 'size': 0}
    }
    
    cutoff_date = datetime.now(timezone.utc) - timedelta(days=30)
    
    for page in paginator.paginate(Bucket=bucket_name):
        for obj in page.get('Contents', []):
            storage_class = obj.get('StorageClass', 'STANDARD')
            if storage_class in storage_summary:
                storage_summary[storage_class]['count'] += 1
                storage_summary[storage_class]['size'] += obj['Size']
            
            # 30 gunden eski Standard dosyalari raporla
            if (storage_class == 'STANDARD' and 
                obj['LastModified'] < cutoff_date):
                size_gb = obj['Size'] / (1024**3)
                print(f"Tasinmasi onerilir: {obj['Key']} "
                      f"({size_gb:.2f} GB, {obj['LastModified'].date()})")
    
    print("n--- Storage Class Ozeti ---")
    for sc, data in storage_summary.items():
        size_gb = data['size'] / (1024**3)
        print(f"{sc}: {data['count']} dosya, {size_gb:.2f} GB")

if __name__ == "__main__":
    analyze_bucket_costs("my-tiered-storage-bucket")

Bu script ile hangi dosyaların katman geçişi için aday olduğunu hızlıca görebiliyorsunuz. Production’da bunu weekly çalışan bir Lambda fonksiyonuna çevirip raporu Slack’e gönderebilirsiniz.

Monitoring ve Alerting

Katmanlı depolama sisteminde görünürlük kritik. Hangi katmanda ne kadar veri var, rehydration işlemleri başarılı mı tamamlandı, beklenmedik erişim maliyeti var mı? Bunları takip etmek için cloud-native araçları kullanın.

AWS’de CloudWatch Storage Metrics, Azure’da Azure Monitor, GCP’de Cloud Monitoring ile depolama katmanlarınıza dair kapsamlı metrikler elde edebilirsiniz. Özellikle şu alertleri kurmakta fayda var:

  • Beklenmedik Archive/Glacier retrieve işlemleri (biri yanlışlıkla büyük bir restore başlatmış olabilir)
  • Lifecycle policy hatalar (geçiş gerçekleşmiyorsa maliyetler artmaya devam eder)
  • Belirli bir eşiğin üzerinde rehydration maliyeti

Sonuç

Depolama katmanları, bulut maliyetlerini kontrol altında tutmanın en etkili yollarından biri. Ama körü körüne “her şeyi Archive’a atalım” yaklaşımı da felakete davet çıkarmak olur. Doğru strateji, veri erişim pattern’larınızı anlamak ve buna göre yaşam döngüsü politikaları kurmaktan geçiyor.

Başlangıç için şu adımları öneririm: Önce mevcut depolama maliyetlerinizi analiz edin, hangi bucket’lar en çok yer kaplıyor, bu verilere ne sıklıkta erişiliyor? Sonra basit bir lifecycle policy ile işe başlayın. 30 gün sonra Standard-IA, 90 gün sonra Glacier gibi. İlk ay sonuçlara bakın, beklenmedik bir şey var mı? Erişim maliyetleri arttı mı? Buna göre fine-tune edin.

Minimum depolama süresi tuzaklarına dikkat edin, erişim maliyetlerini hesaba katın ve kesinlikle automation kurun. Manuel katman yönetimi ölçeklenmiyor. Doğru uygulandığında depolama katmanları, faturanızı %40 ile %70 arasında düşürebilir; bu ciddi bir rakam, üzerine düşünmeye değer.

Bir yanıt yazın

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