# Yerel diskteki dosyaları S3'e taşırken EFS ara çözüm olur mu?

> EFS'i ara durak yapmayın; Flysystem'in s3 diskine geçip okuma ve yazmayı Storage::disk() üzerinden yapın ve dual-read ile kesintisiz taşıyın.

- Soruldu: 2026-05-01
- Yanıtlandı: 2026-05-05
- Soran: Kaan
- Etiketler: mimari, altyapi, olcekleme
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/yerel-diskten-s3-e-gecerken-efs-ara-cozum-mu/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Uygulamam kullanıcı görsellerini yerel diskte tutuyor ve imaj manipülasyonu için yerel kütüphaneler kullanıyor. Yatay ölçekleme (autoscaling) isteyince bu darboğaz oluyor.

S3'e geçişte legacy koda en az dokunarak ve gecikmeyi en aza indirerek dönüşümü nasıl yönetirim? EFS ara çözüm olur mu, yoksa doğrudan object storage adaptör mimarisi mi kurmalıyım?


Kısa cevap: EFS'i **hedef** olarak seçme — tuzak. Asıl çözüm bir object-storage adaptörü; Laravel'de zaten elindeki Flysystem ile bu çok kısa bir iş.

Sizin engeliniz "yerel disk" değil aslında, "paylaşılan mount varsayımı". Kod bir ham path bekliyor; ölçeklenince o path düğümler arasında paylaşılmıyor.

1. **EFS hedef olarak tuzaktır.** "Yerel disk" engelini kaldırır ama sizi bir ağ dosya sisteminde tutar: daha kötü gecikme, daha yüksek maliyet ve **aynı coupling** (kod hâlâ paylaşılan mount sanıyor). EFS'i yalnızca koda gerçekten dokunamadığınız kısa ömürlü bir köprü olarak kullanın, varış noktası olarak değil.
2. **Doğru hamle object-storage adaptörü.** Laravel'de Flysystem zaten var; disk'i `s3` yapın ve her okuma/yazmayı ham path yerine `Storage::disk()` üzerinden geçirin. İş mantığınız "dosya nerede" bilmesin; framework'ün verdiği soyutlamanın arkasına saklanın. Bu can sıkıcı derecede kanıtlanmış (boring) ve tam da bu yüzden doğru.
3. **İmaj manipülasyonunu paylaşılan mount varsaymayın.** Dosyayı geçici bir `tmp` dosyasına çekip işleyin, ya da bir worker + presigned URL ile yapın. Manipülasyonun "disk hep burada" varsayımını kırın; girdi/çıktıyı object storage'dan alın, sonucu yazın.
4. **Legacy churn'ü minimumda tutun.** Tüm dosya erişimini framework'ün filesystem abstraction'ının arkasına alın; çağrı yerlerini tek tek `s3`'e taşımak yerine tek bir disk konfigürasyonuyla devredin. Dokunduğunuz yüzey ne kadar küçükse risk o kadar az.
5. **Geçişi dual-read ile yapın.** Bir süre **önce S3'e bakın, yoksa yerel diske düşün** mantığıyla çalışın; arka planda mevcut görselleri backfill edin. Hepsi taşındığında okumayı tamamen S3'e çevirin ve yerel diski devreden çıkarın.

**Sonuç:** EFS'e para ve gecikme yatırmayın. Ben olsam doğrudan Flysystem `s3` diskine geçer, her şeyi `Storage::disk()` üzerinden okur/yazar, manipülasyonu temp dosya/worker ile çözerdim. Dual-read ile sıfır kesintiyle geçer, backfill bitince yerel diski kaldırırdım. Sıkıcı ama bir kere kurup unutacağınız türden bir mimari.

## İlgili Yazılar

- [Neden Boring Architecture'ı Tercih Ediyorum](https://sade.dev/tr/journal/neden-boring-architecture) — sade.dev
- [Graceful degradation: kritik olmayan servisleri yük altında nasıl izole ederim?](https://www.muhammetsafak.com.tr/sor-bakalim/graceful-degradation-kritik-olmayan-servisleri-izole-etmek/) — Sor Bakalım
- [Multi-tenant SaaS'ta veritabanı izolasyonu: ayrı DB mi, şema mı, tenant_id mi?](https://www.muhammetsafak.com.tr/sor-bakalim/multi-tenant-saas-veritabani-izolasyon-stratejisi/) — Sor Bakalım
- [API sunucumu Cloudflare Tunnel arkasına alıp 443'ü internete kapatmalı mıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/api-sunucusunu-cloudflare-tunnel-arkasina-mi-almali/) — Sor Bakalım