Amazon EFS

여러 컨테이너와 인스턴스가 같은 파일을 봐야 하는데 각 서버 디스크를 따로 쓰면 업로드 경로와 데이터 동기화가 계속 꼬입니다. 한곳에서 수정한 파일이 다른 실행 환경에 바로 보이지 않으면 공유 저장소가 없는 대가를 매번 치르게 됩니다.

서버가 한두 대일 때는 로컬 디스크에 파일을 두고 필요하면 rsync로 복사하는 방식이 통했습니다. 하지만 서버가 늘어나면 동기화 지연 때문에 한쪽에서 올린 파일이 다른 서버에서 아직 안 보이는 데이터 불일치가 생기기 시작합니다. 서버를 추가할 때마다 동기화 대상에 수동으로 등록해야 했고, 장애가 나면 어느 서버에 최신 복사본이 있는지조차 불분명해져 복구 순서를 정하는 데만 시간을 썼습니다. 앱 레벨 복제도 시도되었지만 파일 잠금과 충돌 처리가 애플리케이션마다 달라서 일관된 공유 계층이 될 수 없었습니다. 이런 한계가 겹치면서 네트워크로 공유되고 자동 복제까지 보장하는 관리형 파일시스템 계층인 EFS가 필요해졌습니다.

EFS는 NFS(여러 서버가 네트워크로 같은 파일 경로를 마운트할 수 있게 하는 파일시스템 방식) 기반의 관리형 파일시스템을 제공하고, 가용 영역별 마운트 타깃을 통해 여러 EC2나 ECS 태스크가 같은 데이터를 공유하게 합니다. Regional 서비스로 여러 AZ에 걸쳐 자동 복제되므로 한 AZ가 장애를 겪어도 다른 AZ에서 같은 파일에 접근할 수 있습니다. 성능 모드는 두 가지입니다. General Purpose 모드는 지연 시간이 낮아 웹 서빙이나 CMS 같은 일반 워크로드에 적합하고, Max I/O 모드는 동시 접속 수가 많은 빅데이터·미디어 처리 워크로드에서 처리량을 우선합니다. 처리량 모드도 Bursting과 Provisioned 중 선택할 수 있어서 예측 가능한 성능이 필요하면 미리 처리량을 확보해 둘 수 있습니다. 일관성 모델은 close-to-open 방식으로, 파일을 닫은 뒤 다른 클라이언트가 열면 최신 내용이 보장됩니다. 필요하면 Direct Connect나 VPN을 통해 온프레미스 서버에서도 같은 파일시스템을 볼 수 있습니다.

EFS와 EBS는 둘 다 저장소지만 접근 방식이 다릅니다. EFS는 여러 컴퓨팅 리소스가 동시에 마운트하는 공유 파일시스템이고, EBS는 보통 한 인스턴스에 붙는 블록 디스크입니다. 여러 서버나 컨테이너가 같은 경로를 함께 봐야 하면 EFS를 보고, 단일 서버에 붙는 고정 디스크가 필요하면 EBS를 보면 됩니다.

가장 대표적인 장면은 미디어 서비스에서 사용자가 업로드한 이미지를 여러 컨테이너가 동시에 읽는 구성입니다. 업로드 서버가 EFS에 파일을 쓰면 썸네일 생성 컨테이너, 검수 워커, CDN 원본 서버가 같은 경로를 마운트해서 별도 복사 없이 바로 읽어갑니다. 또 다른 장면은 리프트앤시프트 마이그레이션에서 기존 온프레미스 앱이 공유 디렉터리에 의존하고 있을 때입니다. NFS 마운트를 EFS로 바꾸면 앱 코드를 고치지 않고도 클라우드에서 같은 파일 공유 구조를 유지할 수 있습니다. 한 서버에만 붙는 로컬 디스크가 필요한 경우에는 과합니다.