Google Cloud Storage'ta bucket, sınıf ve yaşam döngüsü nasıl yönetilir

Yönetimin üç katmanı: proje, bucket, nesne

Cloud Storage'ta veri üç katmanda durur. En üstte bir Google Cloud projesi vardır; faturalama ve yetkilendirme bu katmana bağlanır. Projenin içinde bucket (kova) bulunur; bucket'ın adı küresel olarak benzersizdir, konumu ve varsayılan depolama sınıfı ise oluşturulurken seçilir. En altta nesneler yer alır: bir dosya ve ona bağlı üst veri.

Önemli bir ayrım: Cloud Storage klasörlü bir dosya sistemi değildir. Nesne adındaki eğik çizgiler yalnızca bir adlandırma düzenidir; konsol bunları klasör gibi gösterir. Bu yüzden "klasörü taşı" gibi işlemler aslında her nesneyi tek tek yeniden yazmak anlamına gelir ve büyük veri kümelerinde maliyet ile süre yaratır. Ad düzenini en baştan doğru kurmak, sonradan taşıma ihtiyacını azaltır.

Yönetim işi bu yüzden dört soruya iner: veri nerede durmalı (konum), ne kadar sık okunacak (sınıf), kim erişecek (erişim denetimi) ve zamanla ne olacak (yaşam döngüsü). Aşağıdaki bölümler bu soruları sırayla ele alır.

Bucket oluştururken verilen kararlar

Konsolda Cloud Storage bölümünden bucket oluşturma akışı, sırasıyla ad, konum türü, depolama sınıfı ve erişim denetimi seçimini ister. Konum türü şu seçeneklerden biridir: tek bölge (region), çift bölge (dual-region) ve çoklu bölge (multi-region). Tek bölge, verinin Compute Engine ya da Kubernetes gibi aynı bölgedeki kaynaklarla yan yana çalışacağı durumlarda mantıklıdır. Çift bölge, iki bölgeye yayılan coğrafi yedeklilik sağlar. Çoklu bölge ise dünya genelinden erişilen içerik için uygundur.

Komut satırından aynı iş şöyle yapılır:

• gcloud storage buckets create gs://ORNEK-BUCKET --location=BOLGE --default-storage-class=STANDARD --uniform-bucket-level-access

Bucket'ın konumu sonradan değiştirilemez; bu yüzden gecikme, mevzuat (verinin ülke içinde kalması gibi) ve yedeklilik ihtiyacını oluşturmadan önce netleştirin. Varsayılan sınıf ise sonradan değiştirilebilir, ancak bu değişiklik mevcut nesneleri etkilemez; yalnızca bundan sonra yüklenecek nesneler için geçerli olur.

Depolama sınıfları: hangisi hangi veri için

Sınıf seçimindeki asıl ölçüt, verinin ne sıklıkla okunacağı ya da değiştirileceğidir. Resmî dokümantasyondaki sınıf tanımları şöyle özetlenebilir:

• Standard: sık erişilen (sıcak) veri ve kısa süre tutulan veri için. Sınıf belirtmezseniz varsayılan budur.
• Nearline: yaklaşık ayda bir ya da daha seyrek okunan veri için; yedekler ve arşivlenen içerikler tipik örnektir.
• Coldline: en fazla üç ayda bir okunan veri için.
• Archive: yılda birden de seyrek erişilen, hukuki saklama ve felaket kurtarma gibi veriler için en düşük maliyetli sınıf.

Soğuyan sınıflarda depolama maliyeti düşer, ancak erişim maliyeti artar ve her sınıfın asgari saklama süresi vardır. Yani sık okuyacağınız veriyi Archive'a koymak tasarruf değil, fatura sürprizi demektir. Güncel fiyat ve süre ayrıntıları için Google Cloud'un resmî fiyatlandırma sayfasına bakın.

Bir de Autoclass seçeneği vardır: sınıf geçişlerini erişim örüntüsüne göre Cloud Storage kendisi yönetir. Erişim düzeni öngörülemeyen veri kümelerinde kural yazma yükünü kaldırır; Autoclass etkin bir bucket'ta ise elle sınıf değiştiren yaşam döngüsü kuralları kullanılamaz.

Yaşam döngüsü kurallarıyla sınıf geçişi ve silme

Elle sınıf değiştirmek yerine nesne yaşam döngüsü yönetimi (Object Lifecycle Management) kullanılır. Bir yapılandırma bir dizi kuraldan oluşur; her kuralın tam olarak bir eylemi ve bir ya da daha fazla koşulu vardır. Bir nesne kuralın tüm koşullarını sağlarsa eylem uygulanır.

Sık kullanılan eylemler: SetStorageClass (sınıfı değiştir), Delete (sil) ve AbortIncompleteMultipartUpload (yarım kalan yüklemeleri temizle). Sık kullanılan koşullar: nesne yaşı (age), oluşturulma tarihi, ad öneki (matchesPrefix) ve soneki (matchesSuffix), mevcut sınıf (matchesStorageClass), boyut aralığı ve sürümlü bucket'larda daha yeni sürüm sayısı.

Örnek bir politika kurgusu: log dosyaları için ad önekini "loglar/" yapın; belirli bir yaşı aşan nesneleri Nearline'a, daha sonra Coldline'a, en sonunda silmeye alın. Küçük nesnelerde her sınıf değişikliği ayrı bir işlem ücreti doğurduğundan, boyut koşuluyla çok küçük nesneleri kural dışında bırakmak gerekebilir.

Dikkat edilecek noktalar: eylemler eşzamansız çalışır, yani koşul sağlandığı anda değil bir süre sonra uygulanır; yapılandırma değişikliklerinin devreye girmesi de gecikebilir. Geçersiz bir yapılandırma hata döndürür ve mevcut yapılandırma yerinde kalır. Kural yazarken tek bir nesneye birden çok kural uyarsa Delete eylemi SetStorageClass'tan önceliklidir.

Erişim denetimi: IAM, ACL ve tek tip erişim

Cloud Storage'ta erişim iki mekanizmayla verilebilir: IAM ve eski nesne bazlı ACL'ler. Aralarındaki fark yönetilebilirlik açısından belirleyicidir. Tek tip bucket düzeyinde erişim (uniform bucket-level access) etkinleştirildiğinde ACL'ler devre dışı kalır ve bucket ile içindeki tüm nesnelere erişim yalnızca IAM ile belirlenir. ACL okuma ya da değiştirme istekleri hata verir.

Bunun pratik sonucu: bucket düzeyinde verilen bir IAM rolü bucket'taki bütün nesneler için geçerlidir. Farklı erişim gereksinimleri olan verileri (örneğin herkese açık görseller ile dahili raporlar) ayrı bucket'lara bölmeniz gerekir. Bu, ilk tasarımda bucket sınırlarını erişim sınırlarına göre çizmeniz demektir.

Genel kural olarak kişiler yerine gruplara rol verin, ihtiyaç duyulandan geniş rol (örneğin tüm nesneleri silebilen) vermeyin ve bucket'ı internete açmak gerekiyorsa bunu bilinçli ve belgelenmiş bir istisna olarak yapın. Herkese açık erişimi engelleyen genel erişim engelleme ayarı bu tür kazaları önlemek için vardır; resmî dokümantasyondaki ayrıntılarına başvurun.

Gizli verilerde erişim kayıtlarını (denetim günlüklerini) açmayı ve kimin hangi bucket'a baktığını izlemeyi alışkanlık haline getirin.

Veri taşıma, sürümleme ve silme güvenliği

Veriyi Cloud Storage'a taşırken araç seçimi kaynağa göre değişir. Birkaç dosya için konsoldan yükleme yeterlidir; büyük ve sürekli senkron gereken içerikte komut satırı aracının eşzamanlı kopyalama özellikleri, diğer bulutlardan ya da şirket içi sistemlerden toplu aktarımda ise Google'ın veri aktarım servisleri kullanılır. Hangi aracın uygun olduğu, veri hacmi ve ağ bant genişliğiyle ilişkilidir; karar vermeden önce küçük bir deneme aktarımı yapıp süreyi ölçmek en güvenli yoldur.

Silme tarafında şu koruma katmanları bilinmelidir. Nesne sürümleme, üzerine yazılan ya da silinen nesnenin eski sürümünü saklar. Yumuşak silme (soft delete) varsayılan olarak etkindir ve silinen nesneyi belirli bir süre geri getirilebilir tutar. Saklama politikaları ve nesne tutma (hold) ise ilgili süre dolana kadar silinmeyi tümden engeller. Bunların hepsi depolama alanı tüketir; bu yüzden sürümlü bucket'larda eski sürümleri ayıklayan bir yaşam döngüsü kuralı (örneğin yalnızca belirli sayıda yeni sürümü tutmak) yazmadığınız sürece maliyet sessizce büyür.

Bir sınıf değişikliğini yaşam döngüsü kuralı dışında yapmanız gerekirse, nesneyi hedef sınıfla yeniden yazmak (rewrite) gerekir; bu işlem de nesne sayısıyla orantılı işlem maliyeti getirir.

Maliyeti ve düzeni bozan sık hatalar

Sahada tekrar eden hatalar şunlardır:

• Her şeyi Standard'da bırakmak. Yıllardır okunmayan yedekler sıcak sınıfta pahalıya durur; basit bir yaşam döngüsü kuralı bunu çözer.
• Soğuk sınıfa aşırı erken geçmek. Verinin geri okunma ihtimali varsa erişim ve asgari saklama süresi maliyeti tasarrufu silebilir.
• Bucket'ı tek bir kova gibi kullanmak. Farklı erişim ve saklama gereksinimleri olan veriyi karıştırınca ne tek tip erişim ne de tek yaşam döngüsü politikası uygulanabilir olur.
• Nesne adını sonradan düşünmek. Anlamsız adlar, önek bazlı kuralları ve yetkilendirmeyi imkânsız kılar.
• Yarım kalan çok parçalı yüklemeleri temizlememek. Bu parçalar görünmeden depolama tüketir; AbortIncompleteMultipartUpload kuralı bunun içindir.
• Konumu hafife almak. Bucket bölgesi sonradan değiştirilemez; yanlış seçim, veriyi yeni bucket'a taşımak anlamına gelir.

Sağlıklı bir yönetim rutini, her bucket için sahibi, amacı, sınıf stratejisi ve yaşam döngüsü politikasını yazılı tutmak ve belirli aralıklarla fatura raporlarını bucket bazında incelemektir.

Bu beceriyi Mindset programında çalışmak

Mindset kataloğundaki Google Cloud Storage ve Veri Sınıfları Yönetimi eğitimi, bulut mühendisleri, altyapı ve DevOps ekipleri ile veri depolama maliyetinden sorumlu yöneticiler için uygundur: müfredatta Cloud Storage mimarisi ve kova tasarımı, depolama sınıfları ve seçim kriterleri, nesne yaşam döngüsü yönetimi, erişim kontrolü ve maliyet optimizasyonu ayrı modüller olarak yer alıyor.

Bu yapı, bu sayfadaki dört soruyu (konum, sınıf, erişim, yaşam döngüsü) bir ekibin kendi verisi üzerinde uygulamaya dönüştürmeye uygundur; kurumsal ekipler için ortak bir depolama standardı oluşturma ihtiyacına karşılık gelir.