Object Storage Maliyet Optimizasyonu: Lifecycle Policy, Cold Storage ve Bant Genişliği

Object storage artık sadece yedek dosyaları park ettiğimiz bir alan değil; web siteleri, mobil uygulamalar, video platformları, log arşivleri ve yedekleme stratejilerinin kalbi haline geldi. Güzel tarafı, neredeyse sınırsız ölçeklenebilmesi. Zor tarafı ise; doğru tasarlamazsanız depolama, istek ve bant genişliği maliyetlerinin çok hızlı şişmesi. DCHost tarafında onlarca müşterinin object storage kullanımını incelerken gördüğümüz ortak nokta şu: Teknik mimari genelde iyi, ama lifecycle policy, cold storage ve bant genişliği yönetimi çoğu zaman “sonradan düşünülmüş” oluyor.

Bu yazıda tam olarak buraya odaklanacağız. Hangi veri ne kadar süre sıcak kalmalı, ne zaman cold storage’a inmeli, ne zaman tamamen silinmeli? CDN ve önbellekleme ile object storage egress (çıkış) trafiğini nasıl azaltırsınız? Log, yedek, medya ve statik dosya senaryolarında, pratik olarak hangi kuralları yazmalısınız? DCHost altyapısında kendi projelerimizi nasıl kurguluyoruz, bunu da örneklerle anlatacağım. Amacımız, performanstan veya dayanıklılıktan ödün vermeden, faturayı teknik olarak optimize etmek.

Object Storage Maliyetlerini Oluşturan Temel Kalemler

Maliyet optimizasyonu yapmadan önce, faturayı hangi kalemlerin şişirdiğini netleştirmek gerekiyor. Çoğu object storage hizmetinde üç ana başlık vardır:

• Depolama maliyeti: GB/ay başına ücret. Sıcak (hot), seyrek erişilen (infrequent) ve arşiv (archive) katmanlarına göre değişir.
• İstek maliyeti: PUT, GET, LIST, COPY gibi API çağrılarının sayısına göre ücretlendirme.
• Bant genişliği (egress) maliyeti: Object storage’tan internet yönüne veya bölgeler arası veri çıkışı.

Depolama tarafı genelde öngörülebilir olsa da asıl sürprizler istek sayıları ve bant genişliğinde ortaya çıkar. Özellikle sık listeleme (LIST), küçük dosya sayısının çok fazla olması, CDN kullanılmadan doğrudan bucket’tan servis edilen görseller ve logların hiç temizlenmemesi, faturayı kısa sürede katlayabilir.

Daha önce object storage ile medya offload stratejisi yazımızda performans ve mimari tarafını detaylandırmıştık. Bu yazıda ise ağırlığı doğrudan maliyet kalemlerine ve politika tasarımına vereceğiz.

Veri Sınıflandırması: Maliyet Optimizasyonunun Temeli

Lifecycle policy yazmadan önce mutlaka bir veri sınıflandırması yapmanız gerekiyor. Object storage’a attığınız her dosya için şu sorulara cevap vermelisiniz:

• Bu veriye ne sıklıkla erişiliyor?
• Bu veriyi ne kadar süre saklamak zorundayım? (hukuki, operasyonel, iş gereksinimleri)
• Bu veriye erişim gecikmesi (ör. birkaç dakika geç gelmesi) benim için kabul edilebilir mi?

Genelde üç ana kategoriye ayırmak pratik olur:

Sık Erişilen (Hot) Veri

Örnekler:

• Kullanıcıların sık görüntülediği ürün görselleri
• Aktif kullanılmakta olan uygulama yedeklerinin son birkaç günü
• Son 7–14 güne ait uygulama logları (hata ayıklama için)

Bu veriler için hot tier kullanmak mantıklıdır. Amaç, düşük erişim gecikmesi ve yüksek performanstır; GB başı fiyat diğer katmanlara göre biraz daha yüksektir.

Seyrek Erişilen (Warm/Cold) Veri

Örnekler:

• 3 ay önceki loglar (nadiren inceleniyor, ama gerektiğinde ulaşmak istiyoruz)
• Ayda bir dönen raporlar, ihracat dosyaları
• Müşteri yedeklerinin 1–3 ay arası dönemi

Bu veriye anlık değil, ihtiyaç halinde erişiyoruz. Genelde infrequent access (IA) veya cold katmanlar burada devreye girer. GB başı depolama maliyeti düşer, ama erişim (get) maliyeti ve geri çağırma süreleri artabilir.

Arşiv (Archive) Veri

Örnekler:

• Yasal olarak 5 yıl saklamak zorunda olduğunuz finansal kayıtların export’ları
• Eski proje yedekleri (sırf “ne olur ne olmaz” diye saklananlar)
• Nadiren açacağınız, büyük boyutlu eski medya arşivleri

Bu veriye belki yılda bir kez bakılacak, belki de hiç bakılmayacak. Burada en ucuz depolama katmanı devreye girer; ancak:

• Erişim gecikmesi dakikalar-saatler olabilir,
• Minimum saklama süresi (örneğin 90 gün) şartı olabilir,
• Erken silme veya sık okuma yaptığınızda ek ücretler çıkabilir.

Lifecycle Policy ile Otomatik Maliyet Yönetimi

Lifecycle policy, bucket seviyesinde yazdığınız ve object’lerin zaman içindeki yolculuğunu belirleyen kurallar bütünüdür. Temel aksiyonlar:

• Transition: Belirli bir süre sonra nesneyi daha soğuk bir katmana taşımak (hot → cold → archive).
• Expiration: Nesneyi tamamen silmek.
• NoncurrentVersionExpiration: Versiyonlama açıksa eski versiyonları belli sürede silmek.

Tipik Lifecycle Senaryosu: Log Arşivi

Log dosyaları object storage maliyetlerini en çok şişiren kalemlerden biridir. DCHost tarafında sık kullandığımız örnek bir politika şöyle:

• Günlük log dosyaları her gece object storage’a yükleniyor.
• 0–14 gün: Hot tier (sık analiz, hızlı erişim için).
• 15–90 gün: Cold / IA tier (nadiren sorgulama için).
• 90. günden sonra: Otomatik silme (Expiration).

Böyle bir kural seti ile hem KVKK/GDPR uyumlu log saklama süresi yönetimi yapıyor, hem de “5 yıllık logları sıcak depoda tutma” hatasından kaçınıyoruz.

Uygulama Yedekleri İçin Lifecycle Örneği

Yedekler çoğu zaman bilinçsizce sonsuza kadar saklanıyor. Bu da hem maliyet, hem de hukuki risk yaratıyor. Pratik bir politika:

• 0–7 gün: Günlük yedekler hot tier.
• 8–30 gün: Haftalık yedekler cold tier, günlükler silinir.
• 31–365 gün: Aylık tam yedekler archive tier.
• 365+ gün: Otomatik silme (özellikle hassas veri barındırıyorsanız).

Bu yaklaşım, 3-2-1 yedekleme stratejisi ile de uyumlu çalışır: Bir kopya object storage’ta, bir kopya farklı bir bölgede ya da farklı bir sağlayıcıda, bir kopya da mümkünse offline veya immutable.

Versiyonlama ve Eski Sürümlerin Sessiz Faturası

Bucket’ta versioning açtığınızda, her dosya güncellemesinde eski sürüm de saklanır. Bu, özellikle fidye yazılımına karşı çok değerli bir sigorta; ama aynı zamanda görünmeyen bir maliyet kalemi.

Önerimiz:

• Versioning’i kapatmak yerine, NoncurrentVersionExpiration kullanın.
• Örneğin: Son sürüm her zaman kalsın, eski sürümler 30 gün sonra otomatik silinsin.
• Sık değişen büyük dosyalar (örn. sık güncellenen export’lar) için versiyonlamayı ayrı bir bucket’ta yönetin.

Cold Storage ve Arşiv Katmanları ile Gerçek Tasarruf

Cold storage, doğru kullanıldığında depolama maliyetini dramatik şekilde düşürebilir. Ancak burada yapılan en büyük hata, cold/archvie katmanlarının “göm ve unut” yerine “ucuz hot storage” gibi kullanılması.

Cold Storage Kullanırken Dikkat Edilmesi Gerekenler

• Erişim modeli: Ayda birkaç kez okunan veriler için cold tier mantıklıdır. Günlük rapora konu olacak verileri cold’a indirirseniz, her okuma başına ekstra maliyet ödersiniz.
• Minimum saklama süresi: Bazı katmanlar için minimum saklama günü vardır (örn. 30–90 gün). Veriyi erken silerseniz, silinen günler için de ücret alınabilir.
• Toplu geri çağırma (bulk restore): Arşivdeki verileri aynı anda büyük miktarda geri çağırmak, hem gecikme hem maliyet yaratır. Geri çağırma işlemlerini parçalara bölmek daha sağlıklıdır.

Yedekleme Araçlarıyla Cold Storage Entegrasyonu

Pratikte cold storage’ı manuel taşımak yerine, yedekleme ve senkronizasyon araçları ile otomatikleştirmek çok daha verimlidir. Örneğin:

• rclone: Class parametreleri ile dosyaları doğrudan IA/Archive katmanlarına yazabilir, lifecycle’a ekstra esneklik katabilirsiniz. Detaylar için rclone ile S3 uyumlu yedek senkronizasyonu yazımıza göz atabilirsiniz.
• restic / borg: S3 uyumlu uzak yedekleme çözümleri class/transition politikalarıyla birlikte kullanıldığında, uzun vadeli arşiv maliyetini ciddi şekilde düşürebiliyor.

DCHost altyapısında, hem kendi iç sistemlerimizde hem de müşterilerimizde genelde şu yaklaşımı uyguluyoruz: Günlük yedekler hot tier’da, haftalık ve aylık yedeklerin bir kısmı cold tier’da, daha eski snapshot’lar ise archive tier’da tutuluyor. Bu sayede “en çok lazım olan” veri en hızlı yerde, “sadece mecburen saklanan” veri ise en ucuz yerde kalıyor.

Bant Genişliği (Egress) Maliyetini Kontrol Altına Almak

Object storage maliyetlerini optimize ederken, sadece GB/ay depolama ücretine odaklanmak büyük bir hata olur. Özellikle yüksek trafikli web sitelerinde asıl faturayı çoğu zaman bant genişliği kalemi keser.

CDN Kullanarak Object Storage Trafiğini Azaltmak

Statik dosyaları (görseller, CSS/JS, video önizlemeleri vb.) doğrudan bucket URL’si üzerinden son kullanıcıya servis etmek, object storage’ı bir nevi web sunucusu gibi kullanmak anlamına gelir. Bu da:

• Çok sayıda GET isteği
• Yüksek egress trafiği
• Bucket üzerinde gereksiz yük

demektir.

Bunun yerine, object storage’ı origin, CDN’i ise son kullanıcıya en yakın cache katmanı olarak kullanmak gerekir. CDN ne zaman gerekir? yazımızda da anlattığımız gibi, CDN sayesinde:

• Tekrar gelen istekler CDN’den karşılanır, object storage’a gitmez.
• Cache-Control, ETag ve varyant ayarları ile cache hit oranı arttıkça egress maliyeti düşer.
• Kullanıcılara en yakın edge noktasından cevap verildiği için performans da iyileşir.

Akıllı Önbellekleme Kuralları ile Faturayı Dengelemek

CDN kullanırken, her şeyi sonsuza kadar cache’lemek de her şeyi hiç cache’lememek kadar hatalı. İyi bir strateji için:

• Değişmeyen dosyalar: Versiyonlu CSS/JS (style.abc123.css gibi) için uzun TTL (7–30 gün), immutable mantıklıdır.
• Ürün görselleri gibi nadir değişenler: 1–7 gün TTL, invalidation veya versiyonlu URL stratejisi.
• Sık değişen JSON/API yanıtları: CDN yerine uygulama katmanında kısa süreli (ör. Redis) cache.

Özellikle tarayıcı ve CDN önbellekleme ayarlarını doğru yaptığınızda, object storage egress trafiğinin ciddi şekilde azaldığını gözle görebiliyorsunuz.

Küçük Dosya Fırtınası: Thumbnail ve Log Senaryoları

Birkaç KB’lik ama milyonlarca nesneden oluşan bucket’lar, istek sayısı bazlı ücretlendirilen sistemlerde tatsız sürprizler yaratır. Öneriler:

• Küçük log dosyalarını sıkıştırarak (gzip) tek bir günlük dosyada toplamak.
• Thumbnail’leri dinamik üretmek yerine, kullanıcı yüklediği anda farklı boyutlarda üretip object storage’a yazmak ve CDN üzerinden önbelleklemek.
• Gereksiz küçük varyantları (ör. 10 farklı boyutlu görsel) azaltmak; gerçekten kullanılan 3–4 boyuta düşürmek.

Bölgeler Arası Trafik ve Veri Yerelleştirme

Eğer veriyi farklı veri merkezleri veya bölgeler arasında replike ediyorsanız, regionlar arası trafiğin de maliyete yansıdığını unutmamak gerekir. Özellikle:

• Uygulama Türkiye’de, object storage uzak bir bölgede ise her istek cross-region egress demektir.
• Log ve yedekler için cross-region replikasyon tercih ediyorsanız, lifecycle ile eski veriyi yerel arşive taşıma opsiyonunu düşünün.

DCHost tarafında Türkiye ve Avrupa bölgesinde object storage kullanan müşterilerimiz için, uygulama sunucusunun (VPS/dedicated) mümkün olduğunca aynı bölgede konumlandırılmasını öneriyoruz. Böylece hem gecikme, hem de cross-region trafiği azalıyor.

Örnek Senaryo: Orta Ölçekli E-Ticaret Sitesi

Somutlaştıralım. Diyelim ki:

• Günde 200 bin sayfa görüntülemesi olan bir e-ticaret siteniz var.
• Tüm ürün görsellerini object storage’ta tutuyorsunuz.
• Günde 10 GB uygulama logu ve 50 GB yedek üretiyorsunuz.

Bu senaryoda tipik optimizasyon akışı şöyle ilerler:

1) Medya Dosyaları

• Tüm görseller object storage’ta bir bucket’ta tutulur.
• Bucket, CDN’in origin’i olarak tanımlanır.
• Görsel URL’leri versiyonlu hale getirilir (image.jpg?v=123 veya image-123.jpg).
• CDN’de ürün görselleri için 7 günlük TTL tanımlanır.
• Ortalama cache hit oranı %80 üzerine çıktığında, object storage egress trafiği dramatik şekilde düşer.

2) Log Yönetimi

• Uygulama logları günlük dosyalar halinde sıkıştırılarak (gzip) object storage’a atılır.
• Lifecycle policy:
  • 0–14 gün: Hot tier
  • 15–90 gün: Cold tier
  • 90+ gün: Sil
• Log analizi için gerektiğinde yalnızca ilgili günlerin dosyaları indirilir.

3) Yedekleme Stratejisi

• Her gece tam yedekler DCHost VPS üzerinde çalışan bir yedekleme ajanı ile object storage’a atılır.
• Haftalık ve aylık yedekler için restic/borg benzeri otomatik yedekleme akışı kurulur.
• Lifecycle policy:
  • Günlükler: 7 gün sonra sil.
  • Haftalıklar: 8–30 gün arası cold tier.
  • Aylıklar: 31–365 gün arası archive tier, sonra sil.

Bu üç adımı uyguladığınızda, hem depolama hem de bant genişliği maliyetinde gözle görülür bir düşüş yaşarsınız. Üstelik bunu manuel müdahale gerektirmeyen otomatik kurallarla yapmış olursunuz.

DCHost Altyapısında Object Storage İçin Pratik Öneriler

DCHost olarak hem müşterilerimize sunduğumuz S3-uyumlu object storage hizmetlerinde, hem de müşterilerin kendi kurduğu MinIO/CEPH kümelerinde sıkça gördüğümüz birkaç iyi uygulamayı toparlayalım.

1) Bucket Tasarımını İş Yüküne Göre Yapın

Her şeyi tek bucket’a atmak yerine, iş yüküne göre ayırmak büyük avantaj sağlar:

• media-prod
• logs-prod
• backups-db
• backups-files

Böylece her bucket için ayrı lifecycle policy, erişim yetkisi (IAM/policy) ve replikasyon stratejisi tanımlayabilirsiniz. Örneğin:

• logs-prod için agresif silme ve cold storage kuralları,
• media-prod için uzun TTL ve CDN entegrasyonu,
• backups-* için uzun süreli arşiv ve immutable/lock politikaları.

2) Uygulama Tarafında Dosya Boyutunu Akıllıca Kullanın

Object storage maliyetini azaltmanın en basit ama en çok atlanan yollarından biri de dosya boyutunu azaltmak:

• Görselleri webp/avif formatına dönüştürmek.
• Standart bir görsel boyutu seti belirlemek (ör. 320, 768, 1280px) ve fazlasını üretmemek.
• Log dosyalarını mutlaka sıkıştırarak yazmak.

WebP/AVIF ve CDN ile görsel optimizasyonu odaklı yazımızda, hem SEO hem de bant genişliği açısından bu dönüşümün ne kadar kritik olduğunu detaylandırmıştık.

3) Trafik ve Bant Genişliğini Ölçmeden Optimizasyon Yapmayın

Bazı projelerde toplam maliyetin %70’i depolamadan değil, egress’ten geliyor. Bu yüzden öncelikle:

• Hangi bucket ne kadar trafik üretiyor?
• Hangi dosya tipleri en çok istek alıyor?
• CDN hit oranı nedir?

gibi sorulara cevap almalısınız. DCHost müşterilerimizde, object storage + CDN + web sunucusu loglarını birlikte analiz edip, trafik ve bant genişliği ihtiyacı hesaplaması ile gerçekçi bir tablo çıkarmayı seviyoruz. Çoğu zaman asıl kazanç noktası, başta tahmin ettiğiniz yer çıkmıyor.

4) Kendi S3-Uyumlu Depolamanızı Kurarken de Aynı Prensipleri Uygulayın

Bazı ekipler, DCHost üzerindeki VPS veya dedicated sunucularda MinIO/CEPH gibi çözümlerle kendi S3-uyumlu object storage altyapısını kuruyor. Bu durumda dış sağlayıcı faturasını azaltmış oluyorsunuz, evet; ama:

• Disk, network ve CPU kullanımınız yine sizin maliyetiniz.
• Yedekleme, replikasyon ve izleme sorumluluğu tamamen size ait.

Bu yüzden, kendi S3 altyapınızı kursanız bile lifecycle policy, cold storage benzeri sınıflar, log/yedek yönetimi ve bant genişliği kontrolü prensiplerini bire bir uygulamanız gerekiyor. VPS üzerinde MinIO ile S3-uyumlu depolama kurulum rehberi yazımız, bu senaryo için iyi bir başlangıç olabilir.

Sonuç: Object Storage Faturasını Mimariniz Yönetmeli, Siz Değil

Object storage, ölçeklenebilirlik açısından harika; ama yanlış kullanıldığında sessizce büyüyen bir maliyet kalemi. İyi haber şu ki, burada yapacağınız optimizasyonların çoğu bir kere doğru tasarlayıp lifecycle policy, cold storage sınıfları ve bant genişliği kurallarıyla otomatikleştirilebiliyor. Loglar, yedekler, medya ve statik dosyalar için ayrı bucket’lar; her bucket için mantıklı bir saklama süresi ve katman geçiş politikası; CDN ve tarayıcı önbellekleme ile egress’in akıllıca azaltılması… Bunları oturttuğunuzda fatura, tahmin edilebilir ve kontrol edilebilir hale geliyor.

DCHost olarak hem S3-uyumlu object storage çözümlerimizde, hem de VPS/dedicated ve colocation ortamlarında çalışan kendi depolama kümelerinizde bu yaklaşımı benimsiyoruz: Önce erişim modelini ve saklama gereksinimini netleştirmek, sonra mimariyi buna göre kurmak. Projelerinizde lifecycle policy, cold storage ve bant genişliği tarafını elden geçirmek isterseniz, mevcut yapıyı birlikte analiz edip adım adım iyileştirme planı çıkarmak mümkün. Kısacası; object storage’ı korkmadan, ama faturanızı da sürprizlere bırakmadan kullanmak istiyorsanız, mimariyi bugün konuşmak yarınki maliyetlerden her zaman daha ucuz.