S3/MinIO’da Çapraz Bölge Replikasyon Nasıl Kurulur? Versiyonlama, Failover ve DR Runbook’ta Yol Haritası

Yağmurlu Bir Öğleden Sonra: Küçük Bir Panik, Büyük Bir Ders

Hiç başınıza geldi mi? Ofiste herkes işine dalmışken aniden ürün görselleri yüklenmemeye başlar, loglar geç düşer, bir şeyler ters gider ama kimse tam yerini bulamaz. Geçen ay böyle bir öğleden sonra yaşadık. Ağır bir kesinti değil, ufak bir sarsıntıydı. Ama o kısa an bana şunu tekrar hatırlattı: çapraz bölge replikasyon sadece “bir gün lazım olur” diye kurulmaz, günlük huzurun sigortasıdır. Bir duble kahveyle ekran başına çakıldım ve aklımdan şu geçti: “Yarın yine böyle olsa, tek bir komutla diğer bölgeye akışı çevirebilecek miyiz?”

Bu yazıda tam da bunu konuşacağız. S3/MinIO tarafında çapraz bölge replikasyonunu kurarken neden versiyonlama işin kalbidir, failover sırasında panik yapmadan nasıl yön değiştirirsiniz ve bir DR runbook nasıl yazılır ki o zor günde sayfayı açıp sadece uygulayasınız… Hepsini sıcak, günlük dille ve gerçek hayattan örneklerle anlatacağım. Mesela şöyle düşünün: Bir düğmeye basıp trafiği başka şehre, başka veri merkezine kaydırıyorsunuz; ama bunun tıkır tıkır işlemesi için bugün atacağınız küçük adımlar yarın büyük fark yaratıyor.

Neden Çapraz Bölge Replikasyon? Küçük Sarsıntılar, Büyük Rahatlık

Bir fotoğrafın yolculuğu ve fiberin nazı

Bir e-ticaret uygulamasında ürün görseli yüklenir, indirilir, CDN önbelleğine düşer. Her şey yolunda giderken bir bölgede ağ sıkışırsa ya da depolama katmanında ufak bir gecikme olsa herkes aynı anda hisseder. Tam bu noktada S3/MinIO’da çapraz bölge replikasyonu devreye girer; objeleriniz bir başka bölgede de yaşar. Böylece tek bir aksaklık tüm işi durdurmaz. Mesela bir bölgede yazma trafiği yavaşladı diyelim; diğer bölgedeki kopya okuyucu trafiği rahatça besler, uygulama nefes alır.

RTO ve RPO’yu günlük dile çevirmek

Teknik terimleri sevdirmenin yolu, onları mutfak tezgahına indirmek. RTO, “sistemi ne kadar sürede ayağa kaldırmak istiyorsun?” sorusunun cevabı. RPO ise “en fazla ne kadar veri kaybına katlanırsın?” gibi. Mesela RTO’nuz 15 dakikaysa, otomatik failover ve önceden test edilmiş komutlar şart. RPO’nuz dakikalar mertebesindeyse, replikasyon gecikmesini sürekli izlemek ve ufak kuyruğu eritmek için doğru kurallar kritik. Bu iki hedefi gerçekçi seçtiğinizde, replikasyon ve runbook kendiliğinden şekilleniyor.

Versiyonlama: Replikasyonun Kalp Atışı

Neden versiyonlama olmadan yola çıkılmaz?

Replikasyon deyince ilk tuğla versiyonlama. Çünkü her objenin bir version ID’si olduğunda sadece içeriği değil, değişimlerin tarihi de karşıya aktarılır. Yanlışlıkla silinen bir görsel, üstüne yazılan bir konfig dosyası, hepsi geri çağrılabilir olur. S3 dünyasında bu kural nettir: replikasyonun sağlıklı ve izlenebilir olması için versioning açık olmalı. Detayları merak ederseniz, S3 tarafında versioning mantığının güzel bir özeti şu sayfada: S3 Versioning kavramları.

Silme işaretleri, geri dönüş ve hayatı kolaylaştıran küçük nüanslar

Versiyonlama açıkken silme işlemi aslında bir delete marker olarak yazılır. Bu işaret, “bu anahtarın son hali silinmiş” demek. Replikasyon kurallarınızı doğru yapılandırırsanız bu silme işaretleri de karşıya taşınır. Böylece iki uçta tutarlılık korunur. Ama bazen bu işaretleri replikasyondan hariç tutmak isteyebilirsiniz; örneğin, felaket durumunda karşı tarafta dosyanın kalmasını tercih eden ekipler gördüm. Burada amaç neyse kural onu izlemeli. Kısaca: Versioning, silme işaretleri ve yaşam döngüsü (lifecycle) kuralları birlikte düşünüldüğünde, replikasyon hem güvenli hem de esnek olur.

Uygulama-tutarlı olmak neden önemli?

Objeleri kopyalamak güzel, ama veritabanı gibi durum bilgisi taşıyan bileşenlerle birlikte ele almak daha güzel. Örneğin bir siparişin görselleri ve kayıtları farklı zamanlarda giderse küçük bir kafa karışıklığı olabilir. Bu yüzden, obje replikasyonuna eşlik eden uygulama-tutarlı yedekler tatlı bir ikili olur. Bu konuyu sakince anlatan şu yazıya göz atmak işinize yarayabilir: uygulama‑tutarlı yedekler nasıl alınır.

MinIO ve S3’de CRR’yi Kurmak: İlk Tuğladan Son Taşa

Temeller: kimlik bilgileri, kurallar, şifreleme

İlk adım basit: Hem kaynak hem hedef kovada versioning açık olmalı. Sonra, replikasyonun kullanacağı kimlik bilgilerine en az yetkiyle (yalnızca ilgili kovalar üzerinde okuma/yazma ve listeme) erişim verirsiniz. Ardından bir kural tanımlarsınız: Hangi prefix’ler, hangi etiketler, hangi meta bilgileri gidecek? Kimi zaman sadece images/ altını, kimi zaman tüm kovayı replikasyona dahil edersiniz. Şifreleme kullanıyorsanız, KMS anahtarlarına karşı uçta da erişim sağlandığından emin olun; aksi halde kopyalar yolda kalır.

MinIO ile pratik bir akış

MinIO tarafında replikasyon, bucket remote tanımlayıp ardından kural eklemekle başlar. Bir örnek akışı şöyle düşünün: önce mc alias set ile kaynak ve hedefe bağlanırsınız, mc admin bucket remote add ile hedefi iliştirirsiniz, sonra mc replicate add ile kuralı yazarsınız. Kuralları mc replicate ls ile görür, durumu mc replicate status ile izlersiniz. Adımların tamamı için MinIO’nun net bir dokümantasyonu var; pratik için şu sayfayı favoriye atabilirsiniz: MinIO Bucket Replication.

Kurulum öncesi MinIO’yu üretim-hazır hale getirmek, TLS ve policy’leri temizce ayarlamak işleri çok kolaylaştırır. Benim kafamı dağıtan detayları bir kere düzene sokmuştum; merak ederseniz burada uzun uzun anlatmıştım: VPS üzerinde MinIO ile S3‑uyumlu depolama.

AWS S3 tarafında kural mantığı

S3’te de mantık benzer: versioning’i açar, IAM rolüyle hedef kovaya yazma yetkisini verirsiniz, sonra replikasyon kuralını yazarsınız. S3’ün GUI’deki akışı adım adım ilerler; ekranda prefix ve etiketlere göre kapsamı daraltır, metadata ve şifreleme ayarlarına dokunursunuz. Kavramların üstünden tek tek geçmek isterseniz, şu özet sayfa iş görür: Amazon S3 Replication rehberi.

Eski objeler ne olacak?

Replikasyon kurulduktan sonra genelde yeni objeler akar. Peki ya yıllardır biriken dosyalar? Burada “geriye dönük kopyalama” dediğimiz bir kezlik taşıma devreye girer. MinIO’da bunu mc mirror ile, S3’te ise aws s3 sync ya da eşdeğer araçlarla yaparsınız. Bu sayede geçmişi bir seferde taşıyıp, ilerleyen zamanda replikasyona bırakırsınız. Böylece dünün arşivi ve bugünün trafiği aynı resimde buluşur.

Failover Nasıl Planlanır? Paniksiz Yön Değiştirmek

DNS, uygulama ayarı ve gözünüzde büyüyen o an

Failover, en sade haliyle “trafiği başka yere döndürmek”. Bunu bazen DNS katmanında, bazen uygulama konfiginde yaparsınız. İyi bir pratik, hem DNS hem uygulama düzeyinde hazır yollar bırakmaktır. Örneğin CDN origin’ini bir CNAME ile soyutlamak, uygulamanın S3 endpoint’ini tek bir ortam değişkeninden almak gibi. Çok bölgeli akışları sakin sakin kurmak için şu yazı hoş bir çerçeve veriyor: çok bölgeli mimariler ve DNS geo‑routing.

Yazma trafiği: dondur, Degrade et veya çift yaz

Asıl kıymetli soru, yazma trafiğini failover sırasında ne yapacağınız. En sorunsuz yöntem, kısa bir pencere için yazmaları dondurup okuyucuyu yeni bölgeden beslemektir. Bazı takımlar “degrade” modda yalnızca kritik yazmalara izin verir. Çift yazmak (aynı anda iki bölgeye) kulağa hoş gelse de pratikte çatallanmaları yönetmek zorlar; o yüzden bunu gerçekten iyi sağlık kontrolleri ve idempotent tasarım olmadan önermem. Kendi sisteminizin doğasını biliyorsunuz; burada tek doğru yok, süper net bir runbook var.

DNS’te güven ve çoklu sağlayıcı

DNS katmanında tek bir sağlayıcıya bağlı kalmak istemezseniz, zone’larınızı kodla yönetmek huzur verir. Zero-downtime geçişleri ve çoklu sağlayıcıyı adım adım örnekleriyle anlatan şu rehber, bu işin omzunu ferahlatır: octoDNS ile çoklu sağlayıcı DNS. Failover anında bir TXT kaydıyla ekip iletişimini senkronize etmek, değişiklikleri pull-request’le taşımak bile başlı başına stres azaltır.

DR Runbook: O Zor Günün Sakin Defteri

Runbook’un omurgası: kim, ne zaman, hangi sırayla?

Felaket anında tek ihtiyacınız olan şey, önceden denenmiş net adımlar. Runbook’u bir hikaye gibi kurgulayın: Tetiği kim çekiyor? İlk 5 dakikada neye bakılıyor? 15. dakikada hangi komutla hangi değişim yapılıyor? 60. dakikada hangi teyitler alınıyor? Bir örnek akış düşünüyorum: Gözlem paneli gecikmeyi gösterir, sorumlu kişi “durumu değerlendir” çağrısını açar, yazmalar kısa süreliğine dondurulur, DNS’te origin işaretlenir, uygulama endpoint’i ikinci bölgeye çevrilir, ardından okuma-yazma küçük bir testle doğrulanır, iletişim kanallarında durum güncellenir.

Komutlar ve kontrol listeleri, ama insanca

Runbook’un içine kısa ve net komutlar koyun. Mesela replikasyon kuyruğunu görmek için MinIO’da mc replicate status, S3’te nesnel gecikmeyi anlayacak basit bir “kalp atışı” objesi yüklemek, CDN’de purge çağrısının küçük bir örneği. Her adımın sonunda “olması gereken durum”u bir cümleyle yazın. “DNS güncellendi, yeni origin 200 döndürüyor, kontrol listesi A, B, C tamam.” Gözünüz kapalı uygulayacağınız bir düzen kurduğunuzda, felaket günü sıradan bir bakım gününe benziyor.

Ön hazırlıklar: roller, erişimler, yedek kanallar

Runbook, yalnızca teknik adımlar değil; roller ve erişimler de işin içinde. Kim DNS’e yazabilir? Kim KMS’te anahtarları yönetir? Kim uygulama konfigini değiştirir? Bir kişinin ulaşamadığı durumda devreye girecek yedek sorumlu kim? Bu küçük notlar o anın büyük ilacı. Ayrıca ekip içi iletişim için birincil ve ikincil kanal belirleyin; birinde sorun olursa diğeriyle devam edin. Bir de ufacık tüyo: Runbook’u yazdıktan sonra “tatbikat runbook’u” ekleyin; nasıl prova yapılacağı, ne kadar sürede tamamlanacağı orada dursun.

Gecikmeyi İzlemek, Test Etmek ve Geri Dönüş

Replikasyon gecikmesi: kalp atışı objesi

Günlük hayatta gecikmeyi görmek için minik bir numara seviyorum: Her 30 saniyede bir “kalp atışı” objesi yazın; içinde yazıldığı zamanı tutan küçük bir metin olsun. Hedef bölgede bu objeyi okuyup zaman farkını ölçtüğünüzde RPO gerçekliği gözünüzün önünde belirir. Grafikte 1-2 dakikalık dalgalanmalar normaldir; aniden yükselirse bilirsiniz ki bir şey ağırlaşıyor. İşte o zaman devreye giren otopilot değil, önceden konuşulmuş karar ağacı ve runbook olmalı.

Oyun günü: küçük kesinti, büyük öğrenme

Ayda bir “oyun günü” yapın. DNS’te küçük bir değişim, uygulama konfiginde endpoint switching, küçük bir yazma dondurma deneyi. Her provada yeni bir ayrıntı öğrenirsiniz: Bir izin eksikmiş, bir TTL çok uzunmuş, bir dashboard’daki metrik adını kimse hatırlamıyormuş. Bu küçük tökezlemeler, gerçek gün geldiğinde en büyük hazineniz. Hatta isterseniz oyun gününü düzenli bir ritme bağlayın; herkes önceden bilsin, kimseye sürpriz olmasın.

Güvenlik, Yaşam Döngüsü ve Küçük Tuzaklar

Şifreleme, KMS ve asgari yetki

Replikasyonun güvenli olması için iki temel şeye dikkat: uçtan uca şifreleme ve asgari yetki. S3 SSE-KMS veya MinIO KMS kullanıyorsanız, hedefte aynı anahtarla deşifre edip depolayabildiğinizden emin olun. Anahtarların kim tarafından yönetildiği runbook’ta net olsun. IAM ya da policy tarafında geniş yıldızlı yetkiler yerine, yalnızca ihtiyaç duyulan kovalar ve eylemler için politika yazmak çok şey değiştirir.

Lifecycle kuralları ve replikasyon ilişkisi

Yaşam döngüsü politikalarıyla bir objeyi soğuk katmana taşıyorsunuz diyelim. Replikasyon kuralınız buna nasıl tepki veriyor? Kimi zaman önce replikasyon, sonra arşiv; bazen tam tersi mantıklıdır. Burada işinize yarayan küçük bir not: Kuralların sırasını ve kapsamlarını yazılı hale getirip örnek bir anahtar üzerinde denemek, ileride sürprizleri keser. S3 tarafında kavram akışlarını gözden geçirmek için şu özet güzeldir: S3 replikasyon kavramları.

Kısır döngü ve loop’lardan kaçınmak

İki yönlü replikasyon kurarken “A’dan B’ye, B’den A’ya” şeklinde bir loop yaratmadığınızdan emin olun. Genelde her kovaya bir “owner” rol atar ve yalnızca bir tarafa doğru akarız. Eğer gerçekten iki yön gerekiyorsa, tag bazlı ayrım veya prefix bazlı bölme iyi sonuç verir. MinIO/S3’te kural dizaynını biraz esneterek bu tuzaktan kolayca sıyrılabilirsiniz.

Gerçek Dünyadan Bir Akış: Küçük Bir Plan, Büyük Bir Huzur

Bir akşamlık plan, günlerce rahat uyku

Bir müşteride şöyle ilerlemiştik: Önce MinIO’da iki bölgeyi hazırladık, TLS ve policy’leri oturttuk, sonra kaynak kovada versioning’i açıp hedefe remote tanımladık. Sadece images/ ve attachments/ altını replikasyona dahil ettik, arada bir mc mirror ile eski arşivi topladık. Uygulama tarafında S3 endpoint’i tek bir değişkende tutuldu; CDN origin’i CNAME ile soyutlandı. DNS katmanında çoklu sağlayıcı stratejisini kodla yönetmeye başladık. Bir akşam tatbikat yaptık: Yazmaları 3 dakika dondurduk, DNS’i yeni origin’e çevirdik, smoke test’leri koşturduk, sonra geri aldık. O gece kimse geç saatlere kadar beklemedi; runbook soru işaretlerini toplayıp gerçek hayata indirince, telaş sessizce dağıldı.

CDN ve cache ısısı

Failover’da kullanıcıların hissettiği şey çoğu zaman “görsellerin ilk açılışı”. CDN katmanında origin değişince küçük bir soğuma olabilir. Bunu azaltmak için sık kullanılan yolları önceden ısıtmak, kritik sayfaları tatbikattan önce hızlıca dolaştırmak işe yarar. Küçük dokunuş, büyük etki. Bu arada çok bölgeli akışları mimari düzeyde düşünmek isterseniz şu makale hoş bir çerçeve sunuyor: çok bölgeli mimariler rehberi.

Kapanış: Bugün Atılan Küçük Adımlar, Yarın Büyük Sükûnet

Derli toplu bir özet ve küçük bir teşvik

Toparlayalım. S3/MinIO’da çapraz bölge replikasyon kurarken önce versioning’i açın, replikasyon kurallarını iş hedefinize göre yazın, şifreleme ve yetkileri sadeleştirin. Failover planınızı DNS ve uygulama seviyesinde hazırlayın; mümkünse her iki yolda da birer “tek tuş” bırakın. Runbook’u bir akış olarak kurgulayın: ilk 5 dakika, 15 dakika, 60 dakika… Tatbikatı düzene bağlayın; kalp atışı objesiyle gecikmeyi ölçün; küçük dersleri ekipçe not alın. Bir de konu derinleştikçe DNS tarafındaki dayanıklılığı artırmak için yukarıda paylaştığım çoklu sağlayıcı DNS rehberi kenarda dursun.

Eğer henüz MinIO kurulumunuza başlamadıysanız veya üretim ayarlarını gözden geçirmek istiyorsanız, şu rehber de elinizin altında bulunsun: MinIO’yu üretim‑hazır kurmak. Yolunuz S3 tarafına düşerse, resmi dokümanların kavram sayfalarını da seversiniz: S3 Versioning ve S3 Replication. Umarım bu yol haritası, yağmurlu bir öğleden sonra sizi telaştan uzak tutar. Küçük adımlarla başlayın, bir akşam tatbikatı yapın, runbook’u duvara asın. Bir dahaki yazıda görüşmek üzere.