이 기사에 대하여

Elastic File Syestem에 대해 설명하는 영업 자료 기사적인 느낌.
아직 EFS를 만진 적이 없는 사람, 조사하고 있는 도중의 사람, 장점을 모르는 사람 전용입니다.

"지금부터 NFS 인스턴스를 구축한다고? 그렇다면 Elastic File System을 시도하지 않겠습니까?"

Elastic File System은

Amazon Web Services에서 제공하는 완전 관리형 파일 시스템.

・용량의 걱정 없음(사이징 불필요의 종량 과금).
・메인터넌스의 걱정 없음.
・EFS에의 파일 전송시는 암호화되어 고시큐어.

라는 최강의 파일 시스템.

EBS와 비교하면 비용이 3배이거나, IOPS 속도는 범용 SSD에 비해 조금 느리거나,
백업에는 Amazon Backup 설정이 필요하지만,
그런 단점 지우기 정도의 메리트나 구성안의 폭이 늘어나는 서비스이다.

오랜 과제였던 Autoscaling시의 조상 반환 대책이 이 일발로 해결되었다.
(지금까지는 별도 NFS 인스턴스 세워, 그것의 매니지드 어떻게 하는 법이라든지 사이징 어떻게 하는 법이라든지 하지 않으면 안 되어 힘들었다)

원래 파일 시스템은 무엇입니까?

조사한 가운데 가장 알기 쉬웠던 것은 이하 기사.

【자세히 개요】Linux 파일 시스템의 종류나 작성 방법 정리!

게다가, 한층 더 스스로 정리한 도해가 이하.
이 파일 시스템은 일반적으로 서버 시작 시 자동으로 마운트되므로,
평소에는 의식하는 일이 없다.
이 파일 시스템이 없으면, 「디렉토리 어디?」 「파일 어디?」라고 상태가 되어 버린다.


게다가 Autoscaling의 조상 돌아가는 것이 어떤 상태라고 말하면 이하.
절각 부하 분산으로 ELB를 물리치고 있는데, 그 아래의 컨텐츠가 낡다고 하는 상태.
각 파일 시스템은 각 로컬 호스트 EBS를 보러가는 상태이므로,
보는 사람에 의해 콘텐츠가 새롭거나 낡거나 하는 것은 매우 마즈이.

그런 때의 구세주가 Elastic File System

이것이라면, 보러 가는 디렉토리는 1개만이 되어, 좌우 어느 쪽의 인스턴스로 컨텐츠를 갱신했다고 해도 좌우의 인스턴스는 같은 것을 돌려준다.
인스턴스가 몇 늘어나더라도, 언제 늘어나도 EFS에 마운트만 하고 있으면 조상 반환은 발생하지 않는다.
물론, fstab등으로 기동시에 마운트하는 설정이라든가 필요하게 되어 오는데, 거기는 누군가의 기사 보고 실제로 만들어 보길 바란다.

요약

Elastic File System은 가능성의 덩어리 같은 서비스이므로, 아직 만지지 않은 사람, 제안한 적이없는 사람은 꼭 만져 보길 바란다.
ownCloud라든지 온라인 스토리지를 이것으로 구축할 수 없는지 검토중.