피드로 돌아가기
Dev.toInfrastructure
원문 읽기
S3 Files 도입을 통한 Lambda의 /tmp 의존성 제거 및 파일 처리 구조 단순화
S3 Files Killed My Least Favorite Lambda Pattern
AI 요약
Context
기존 S3-Lambda 아키텍처는 Download-Process-Upload라는 반복적 플러밍 로직에 의존함. 이로 인해 10GB의 /tmp 용량 제한과 파일 처리 실패 시 전체 재다운로드라는 비효율적 병목 지점이 발생함.
Technical Solution
- Amazon EFS 기반의 NFS v4.1+ 파일 시스템을 S3 버킷에 마운트하여 디렉토리 트리 형태로 제공하는 구조 채택
- 'Stage and Commit' 전략을 통해 NFS 마운트 지점의 쓰기 작업을 수분 내에 S3로 자동 동기화하는 메커니즘 구현
- 128KB 미만 소형 파일은 EFS 캐싱 레이어에 저장하여 약 1ms 수준의 초저지연 액세스 보장
- 1MiB 이상 대용량 순차 읽기 시 캐시를 우회하여 S3에서 Parallel GET 요청으로 직접 스트리밍하는 최적화 적용
- 파일 경로 기반 도구(ffmpeg, trivy 등)가 S3 API 구현 없이 표준 open() 함수로 데이터에 접근 가능한 추상화 계층 제공
- NFS Close-to-open 일관성과 S3의 Strong Consistency를 분리하여 각각의 시맨틱을 유지하는 이중 레이어 설계
실천 포인트
1. ffmpeg, Tesseract 등 파일 경로 기반 외부 라이브러리 사용 여부 확인
2. 처리 대상 파일 크기가 Lambda /tmp 제한(10GB)을 초과하는 케이스 존재 여부 검토
3. 다수 Lambda 인스턴스가 동일한 대용량 참조 파일을 반복 다운로드하는 패턴 식별
4. 단순 JSON 변환이 아닌 미디어/문서/코드 분석 등 파일 헤비한 워크로드인지 판별