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

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.