EFS는 NAS가 아닙니다.

많은 업체들이 DX(디지털 트렌스포매이션)를(을) 진행하며 1차적인 Public Cloud 마이그레이션으로 ReHost전략을 택합니다. 하이브리드 형태로 유지할때 일원화의 이슈도 있고요.(관리 운영의 편함을 위하여)

 

이때 가장 조심해야 할 점이 온 프레미스 레거시 환경에서 자주 로그 수집을 위해 사용하는 NAS를 AWS로 마이그레이션 하는 경우이다. 온프레미스의 경우 같은 IDC또는 대역내 렉의 장비로 바로 연결 된다. 그렇기에 대부분의 경우 IOPS의 이슈나 Throughput이슈가 없다. 

 

AWS로 이전하는 경우 해당 NAS를 EFS로 자주 마이그레이션 하는데...동일한 형태로 사용하면 이런 지표를 자주 보게될 것이다

EFS 크래딧 잔여량과 Throughput

EFS는 성능 모드와 처리량 모드 이렇게 두개의 모드로 나뉜다.

Performance mode

• General Purpose
• Max I/O

우선 이 두가지 모드의 차이는 지연시간과 PercentIOLimit 지표의 비율이다. EFS는 초당 읽기 쓰기 작업의 제한이 있다. 물론 이는 EFS용량에 따라 주어지는 IOPS와 관계가 있다. 만약 실시간으로 로그를 쓰고 로그를 ZIP으로 압축하는 등의 작업을 한다면 범용 모드로 사용할때 해당 로그를 저장하고 압축하는 작업에 문제가 생길수 있다. 예를 들어 Spring Logback을 사용하여 로테이션을 돌리고 압축하는 경우 이 모듈에 이상이 생겨 크게는 서비스 장애로 이어질 수 있다.

 

대체로 웹 서비스 환경이나 콘텐츠를 관리하는등 단순 공유 디렉터리 파일 서비스로는 문제가 없겠으나 높은 수준의 집계및 초당 처리량이라면 최대 I/O성능 모드를 선택하거나 사전에 더미 파일을 넣어 사용량을 최대한 끌어 올려 놓자!!

 

Throughput mode

• Bursting
• Provisioned

이슈의 주범인 처리량 모드이다. 저 버스팅이란 놈이 큰 문제다. 평소에는 분명 이슈가 없을것이다. 초기에 테스트 하는경우도 이 처리량 모드에 대한 이해가 없이 도입한다면 '잉 잘되는군!!' 하고 넘어갈 수 있다.

버스팅 동작의 예이다. 일단 초기 1TiB 미만의 사이즈인 경우 100MiB/s의 처리량으로 버스팅 할 수 있다. 기준 처리량은 스토리지 GiB당 50KiB/s이다. 만약 오픈을 했을때 50Gb의 용량을 확보 하고 있다면? 2.5MiB/s의 처리량이 기준 처리량이 된다. 다만 읽기 처리량은 다른 처리량의 1/3 비율로 측정 하기 때문에 읽기 전용인 경우 7.5MiB/s가 될것이다. 그 이상 사용하는 경우 크레딧을 지속적으로 소모한다. 

 

크레딧은 언제 쌓이냐고??? 기준치 이하로 쓰면 그만큼 쌓인다. 크레딧은 1TiB보다 작으면 2.1TiB까지 쌓이고 그보다 큰 경우 1TiB당 2.1TiB만큼 주어진다. 

위처럼 파일 시스템 크기에 따라 사용 가능한 처리량이 상이하다. 그렇기에 초기 서비스가 오픈 되었을때 프로비저닝 할게 아니라면 더미파일로 처리량을 끌어 올려 놓아라!!

 

버스트 크레딧을 소모하는 경우 아주 무서운 일이 벌어진다.(EC2 T시리즈랑 비슷하다고 보면된다.)

 

프로비저닝모드는 말 그대로 TiB당 MiB/s의 비율이 높은 어플리케이션이나 버스팅 처리량 모드에서 허용하는 것 보다 더 많은 처리량을 요구하는 경우 사용이 가능하다. 위에서 언급한것과 같이 초기 오픈때 트래픽이 몰리는 것을 대비하여 미리 프로비저닝 할 수 있다. 참고로 프로비저닝된 처리량은 100MiB/s로 했을때 파일 시스템 크기가 2테라가 넘어가는 경우 범용 모드의 요금을 부과한다. 

 

그냥 스토리지 사용을 안 해도 미리 확보해 놓고 사용하는거와 같다.

범용 모드에서는 초당 35,000개의 파일 작업 제한이 있습니다. 데이터 또는 메타데이터를 읽는 작업은 하나의 파일 작업을 사용하고, 데이터를 쓰거나 메타데이터를 업데이트하는 작업은 5개의 파일 작업을 사용합니다. 즉, 파일 시스템은 초당 35,000개의 읽기 작업 또는 7,000개의 쓰기 작업이나 두 작업의 일부 조합을 지원할 수 있습니다. 예를 들어, 읽기 작업 20,000개와 쓰기 작업 3,000개(읽기 20,000개 x 읽기당 파일 작업 1개 + 쓰기 3,000개 x 쓰기당 파일 작업 5개 = 35,000개 파일 작업)를 지원할 수 있습니다. 파일 작업은 모든 연결 클라이언트에서 계산됩니다.

 

그렇다면 NAS와 왜 다를까?

EFS는 기본적으로 AZ간 동기적으로 복제가 된다. NFSv4 프로토콜로 연결이 되나 이것은 앞단 스위치에서의 역할이고 내부적으로 지리적으로 떨어져 있는 IDC간 동기적으로 복제가 되는 형태이다. 그리고 AWS의 EFS장비 또한 노후화 되고 수시로 교체가 이루어진다. 참고로 이런 시스템 구조때문에 간혹 몇초간 원인을 알 수 없는 지연이 발생하기도 한다.

• 이 부분은 Tcpdump로 확인했는데 순간적으로 5~10초 지연이 있어 Support에 문의하니 해당 시간 장비 교체하는 도중 오류가 있다더라...

EFS는 편하다. 하지만 이러한 구조나 사용 방법을 자세하게 알고 적용해야한다.

일반적인 온프레미스 NAS와 같이 사용하는 경우 낭패를 볼 수있다.

 

EFS는 그냥 단순하게 NFSv4프로토콜을 지원하는 스토리지 서비스일 뿐 NAS가 아니다.