파일 flush 문제 공유 (NFS)

https://spody.tistory.com/216

직전에 작성한 글로부터 이어집니다.

NFS(Network File System)를 곁들인 저장소

쉘 스크립트나 Python을 통해 flush를 직접 유도했음에도 불구하고, 운영 환경에서는 여전히 깨진 파일이 다운로드되었음. 이를 확인한 결과, 해당 파일이 저장된 위치는 NFS 마운트 스토리지였다.

NFS 환경 특성

• NFS export 옵션 중 sync, async가 있음
• 옵션이 명시되지 않으면 기본값은 async → flush 지연

NFS export 옵션 설명

• sync:
  • 클라이언트의 write() 요청마다 NFS 서버가 디스크에 즉시 flush한 후 OK 응답 반환
  • 안정성 높음, 성능 낮음
• async (기본값):
  • write() → 클라이언트 커널 캐시에 저장 → 일정 시간 후 NFS 서버에 전송
  • 서버에서도 메모리에 저장 후 나중에 flush (2단계 지연)
  • fsync() 호출 → 클라이언트는 COMMIT 요청을 보내지만, 서버 flush 시점은 커널이 결정
  • 이로 인해 flush 전에 장애 발생 시 데이터 손실 가능성 있음

NFS 환경에서 flush 요약

• 백엔드 서버는 NFS 마운트 스토리지에 파일을 저장하고 있음
• NFS의 async 설정 때문에 flush 요청이 디스크에 즉시 반영되지 않음
• flush()나 fsync(), mv 등을 해도 NFS 서버의 커널 스케줄러가 flush 시점을 결정하기 때문에 클라이언트 입장에서 flush가 즉시 완료되었는지는 보장되지 않음

최종 해결 방안

• NFS export 옵션을 sync로 바꾸는 건 성능 리스크가 커서 적용 어려움
• 엑셀 파일은 사용자가 다운로드 받기만 하면 되므로, 3초 대기 정도는 큰 무리가 없음
• 따라서 엑셀 path를 반환하기 전 sleep 3을 넣는 것이 현재 환경에선 가장 현실적인 대응