# 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://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ş.

## Kısa cevap

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. Bu varsayımın nereden geldiğini görmek için [Laravel'de dosya yükleme ve görsel işleme yazısındaki](/tr/blog/laravel-ile-dosya-yukleme-ve-gorsel-isleme/) klasik akışa bakmak yeter: her adım diskin orada olduğunu varsayar.

## Neden

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üdür.** Laravel'de Flysystem zaten var; disk'i `s3` yapıp her okuma/yazmayı ham path yerine `Storage::disk()` üzerinden geçirdiğinizde iş mantığınız "dosya nerede" bilmez. Bu can sıkıcı derecede kanıtlanmış (boring) ve tam da bu yüzden doğru.

## Ne yapmalı

1. **Disk'i `s3` yapın, erişimi soyutlamanın arkasına alın.** Çağrı yerlerini tek tek taşımak yerine tek bir disk konfigürasyonuyla devredin. Dokunduğunuz yüzey ne kadar küçükse risk o kadar az.

2. **İmaj manipülasyonunun paylaşılan mount varsayımını kırın.** Dosyayı geçici bir `tmp` dosyasına çekip işleyin, ya da bir worker + presigned URL ile yapın. Girdiyi object storage'dan alın, sonucu oraya yazın.

3. **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://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://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://muhammetsafak.com/tr/sor-bakalim/api-sunucusunu-cloudflare-tunnel-arkasina-mi-almali/) — Sor Bakalım