EC2(4)-EFS(Elastic File System)

Amazon EFS - Elastic File system

• EFS: 관리형 NFS(Network File System)

  • 수 많은 인스턴스에 마운트될 수 있다.
  • 서로 다른 가용 영역에 있을 수도 있다.
  • 가용성이 높고 확장성이 뛰어나고 비싸다. (gp2의 약 3배)
  • 사용량에 따라 비용을 지불하기 때문에 미리 용량을 프로비저닝할 필요가 있다.
  • EFS를 위한 보안 그룹을 설정하면 좋다.
    

• Use cases
  콘텐츠 관리, 웹 서비스, 데이터 공유, Wordpress

• 내부적으로 NFS 프로토콜을 사용하고, EFS에 대한 액세스를 제어하려면 보안 그룹을 설정해야한다

• 리눅스 기반 AMI만 호환이 가능하다(윈도우는 불가)

• KMS를 사용해 EFS 드라이브에서 미사용 암호화를 활성화할 수 있다.

• 리눅스 표준 파일 시스템 -> POSIX 파일 시스템을 사용하고 표쥰 파일 API가 있다.

• 용량을 미리 계획할 필요가 없다. -> 파일 시스템은 자동으로 확장되고 EFS 사용량에 따라 비용을 지불

성능

• EFS Scale
  • 동시 NFS 클라이언트 수천 개와 10GB 이상의 처리량을 확보 가능하다.
  • PB 규모의 네트워크 파일 시스템으로 자동 확장 가능.
• 성능 모드(EFS 생성시 설정)
  • 1) 범용(기본값): 지연 시간에 민감한 경우 사용된다. (ex: 웹 서버, CMS)
  • 2) 최대 I/O모드: 지연 시간이 더 긴 네트워크 파일 시스템이지만 처리량이 높고 병렬성이 높다.
    처리량과 초당 연산이 최대가 된다.
    (ex: 빅 데이터 애플리케이션, 미디어 처리)
• 처리량 모드
  • 1) 버스팅(Bursing): 1TB = 50MB/s + 100MB/s
    파일시스템 크기와 비례한 용량을 가진다.
  • 2) 프로비저닝(Provisioned): 스토리지 크기에 관계없이 처리량을 설정하고 싶은 경우 사용.
    파일시스템을 어느속도로 읽을지 설정 가능
    작은 파일 시스템에 유용하지만 초반에는 큰 처리량이 필요하다.
    -> 이전에는 스토리지가 늘어날수록 처리량이 증가하지만 프로비저닝은 1TB에서 1GB/s 처리 가능.
    --> 스토리지와 처리량을 분리했기 때문
  • 3) 앨라스틱(Elastic): 워크로드에 따라 처리량을 자동을 조절
    -> ex) 워크로드에 따라서 읽기 3GB/s, 쓰기 1GB/s 까지 가능하다.
    --> 워크로드를 예측하기 어려울때 유용

스토리지 클래스

• 스토리지 계층(수명주기 관리 기능 - N일후 파일을 다른 계층으로 옮길 수 있는 기능)
  • 사용 예
    - 표준 계층은 자주 액세스하는 파일을 위한 계층을 두고,
    - 자주 액세스하지 않는 계층은 EFS-IA(Infrequent Access)계층 이용
    • EFS-IA(Infrequent Access)
      EFS-IA계층에서 파일 검색할 경우 비용이 발생
      그러나 EFS-IA에 저장하면 비용이 감소
      EFS-IA를 사용하려면 수명 주기 정책을 설정해야 한다.
      
      -> 수명 주기 정책을 통해 60일 동안 사용하지않는 파일을 EFS-IA로 자동으로 옮겨 비용을 줄인다.
• 가용성과 내구성
  • 표준: 다중 AZ로 EFS 설정 가능 -> 프로덕션에 적합
    왜? 가용 영역 하나가 다운되도 EFS 파일 시스템에 영향을 미치지 않기 때문
  • 단일 영역(One Zone): 단일 AZ, 개발에 적합, 기본적으로 백업 가능이 활성화되있음
    액세스 빈도가 낮은 스토리지 계층(IA)과 호환된다. (EFS One Zone-IA 라고도 한다.)
    -> 약 90%로 할인이 많이 된다.
• 언제 EFS를 사용해야하고 네트워크 파일 시스템에 어떤 옵션을 설정해야하는가(시험)

EBS VS EFS

• EBS
  • 한 번에 하나의 인스턴스(io1/io2의 다중 첨부기능 제외)
  • AZ 수준에 잠겨 있다.
  • gp2 볼륨은 디스크 크기가 증가하면 IOPS도 증가
  • io1 독립적으로 IOPS를 늘릴 수 있다.
  • AZ간 EBS 볼륨을 마이그레이션하려면 스냅샷을 만들어야 한다.
    스냅샷으로 다른 AZ로 복원 가능
  • EBS 볼륨 백업은 IO를 사용해 애플리케이션이 많은 트래픽을 처리할 경우 실행하면 안된다.
    인스턴스 성능에 영향을 미치기 때문
  • 인스턴스의 루트 EBS볼륨은 인스턴스가 종료되면 기본적으로 종료 된다.
    설정으로 남기게 볼륨을 남길 수 있다.
• EFS
  • 네트워크 파일 시스템, 여러 가용성 영역에 여러개의 인스턴스를 참조를 목표
    -> 하나의 EFS 파일 시스템으로 서로 다른 AZ에서 서로 다른 마운트 대상을 가질 수 있다.
    -> 여러 인스턴스가 하나의 파일 시스템을 공유할 수 있다.
  • 예를들어 WordPress의 경우이다. linux 인스턴스 전용
    Posix 시스템을 사용하기 때문
  • EFS는 EBS보다 가격이 높지만 EFS-IA로 비용 절감 가능

+ 인스턴스 스토어

• 물리적으로 인스턴스에 연결되어 있어 인스턴스가 손실되면 스토리지도 손실