Python SDK ile Azure Blob Storage Yaşam Döngüsü Yönetimi

· Hasan Aydın · 4 dk okuma · Python , Azure , Bulut

Merhabalar, bu yazıda Azure Blob Storage'ın yaşam döngüsü yönetimi (lifecycle management) tarafına Python SDK üzerinden bakacağız. Konu kulağa kuru gelebilir ama inanın bana, ay sonu faturasına bakınca insanın yüzünü güldüren tek özelliklerden biri bu. Hadi başlayalım.

Şöyle bir senaryo: bir uygulama log'larını, kullanıcıların yüklediği medya dosyalarını, bir de gece bittikten sonra kimsenin dönüp bakmadığı geçici raporları aynı container'a atıyorsunuz. İlk gün hepsi sıcak (Hot) katmanda, mantıklı. Ama bir ay sonra hâlâ Hot'ta duruyor olmaları hiç mantıklı değil. İşte yaşam döngüsü politikaları tam burada devreye giriyor.

Katmanları kısaca hatırlayalım

Azure'da dört erişim katmanı var ve fiyat farkı ciddi:

  • Hot: Depolama pahalı, erişim ucuz. Sürekli okuduğunuz veriler için.
  • Cool: Depolama daha ucuz, erişim biraz daha pahalı. En az 30 gün bekleyecek veriler.
  • Cold: Daha da ucuz. 90 gün ve üzeri bekleyecekler.
  • Archive: En ucuz depolama, en pahalı erişim. Geri çağırması saatler sürebilir.

Archive ile Hot arasındaki depolama maliyet farkı kabaca on katı civarında. Ama Archive'dan bir blob'u geri istediğinizde hem para hem zaman ödüyorsunuz; bunu bir kenara not edin, birazdan dönece­ğiz.

Politikayı SDK ile kurmak

Yaşam döngüsü politikası storage account seviyesinde tanımlanır, container seviyesinde değil. Bu yüzden management SDK kullanıyoruz, blob SDK değil. Önce gerekli paketleri kuruyoruz:

pip install azure-storage-blob azure-mgmt-storage azure-identity

Şimdi bir politika tanımlayalım. Üç farklı prefix için üç farklı kuralımız olsun: logs/ altındakiler kademe kademe arşive gitsin, temp/ altındakiler ertesi gün silinsin, media/ altındakiler bir hafta sonra Cool'a düşsün.

from azure.identity import DefaultAzureCredential
from azure.mgmt.storage import StorageManagementClient
from azure.mgmt.storage.models import (
    ManagementPolicy, ManagementPolicySchema, ManagementPolicyRule,
    ManagementPolicyDefinition, ManagementPolicyFilter,
    ManagementPolicyAction, ManagementPolicyBaseBlob,
    DateAfterModification,
)

credential = DefaultAzureCredential()
client = StorageManagementClient(credential, '<SubId>')

log_rule = ManagementPolicyRule(
    name='log-tiering',
    enabled=True,
    type='Lifecycle',
    definition=ManagementPolicyDefinition(
        filters=ManagementPolicyFilter(
            blob_types=['blockBlob'],
            prefix_match=['logs/'],
        ),
        actions=ManagementPolicyAction(
            base_blob=ManagementPolicyBaseBlob(
                tier_to_cool=DateAfterModification(days_after_modification_greater_than=30),
                tier_to_archive=DateAfterModification(days_after_modification_greater_than=90),
                delete=DateAfterModification(days_after_modification_greater_than=365),
            ),
        ),
    ),
)

policy = ManagementPolicy(policy=ManagementPolicySchema(rules=[log_rule]))

client.management_policies.create_or_update(
    resource_group_name='<RgName>',
    account_name='<AcctName>',
    management_policy_name='default',  # bu isim sabit, 'default' olmak zorunda
    properties=policy,
)

Burada dikkat: management_policy_name her zaman 'default'. Buraya yaratıcı bir isim yazarsanız Azure kabul etmez. Bir de filtreleri prefix bazlı yazıyoruz; yani container içinde mantıklı bir klasör yapısı kurduysanız hayatınız çok kolaylaşır.

Yerleşik politikanın yetmediği yer

Yerleşik politika sadece son değişiklik veya oluşturulma zamanına bakar. Ama bazen son erişim, dosya boyutu ya da metadata'ya göre karar vermek isteriz. Bu durumda blob SDK ile kendi mantığımızı yazıp bir Azure Function ile zamanlamak en temiz çözüm:

from azure.storage.blob import BlobServiceClient
from datetime import datetime, timedelta, timezone

svc = BlobServiceClient(account_url='<Url>', credential=credential)

def cool_down_idle(container, days=30):
    cont = svc.get_container_client(container)
    cutoff = datetime.now(timezone.utc) - timedelta(days=days)
    for blob in cont.list_blobs(include=['metadata']):
        if blob.last_accessed_on and blob.last_accessed_on < cutoff:
            if blob.blob_tier == 'Hot':
                cont.get_blob_client(blob.name).set_standard_blob_tier('Cool')

last_accessed_on özelliği için storage account üzerinde access time tracking'i açmış olmanız gerekiyor; varsayılanda kapalıdır. Açmadan bu kontrolü yazarsanız her blob için None döner ve hiçbir şey hareket etmez.

Sık karşılaşılan tuzaklar

  • Politikayı kurar kurmaz tetiklenmesini beklemek: Azure politikayı bir kerede koşturmaz, günde bir kez değerlendirir. Test ederken sabırlı olun, dakikalar içinde sonuç beklemeyin.
  • Archive'a geçirip ertesi gün geri istemek: Hot'a rehydrate etmek hem saatler sürer hem de okuduğunuz veri başına ücretlendirilir. Archive'a sadece gerçekten 'unutulacak' veri gönderin.
  • Erken silme cezasını unutmak: Cool'da 30, Cold'da 90, Archive'da 180 günden önce silerseniz Azure kalan günlerin maliyetini sizden almaya devam eder. Yaşam döngüsünüzü buna göre kurun.
  • Snapshot'ları temizlememek: Base blob'u Cool'a çekersiniz ama snapshot'lar Hot'ta kalır. snapshot action'ı da politikaya eklemeyi unutmayın.
  • Politikayı kurup hiç doğrulamamak: list_blobs ile katman dağılımını periyodik raporlayın. Bence bu olmadan maliyet kazandığınızı gerçekten bilemezsiniz.

Kapanış

Yaşam döngüsü yönetimi Azure'da en hızlı geri dönüş veren optimizasyonlardan biri; bir öğleden sonra ayırıp doğru kurarsanız, ay sonunda farkını net görüyorsunuz. Şahsen ben yerleşik politikayı temel kuralları için, blob SDK'sını da metadata ya da boyut tabanlı özel mantık için kullanmayı tercih ediyorum - ikisi birbirini güzel tamamlıyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.