aws efs vs ebs

웹사이트를 운영하는데 EFS를 사용해야 할까, EBS를 사용해야 할까 고민하실 수 있습니다.

다만, EBS와 EFS는 용도가 명확히 다르기 때문에, 해당 내용을 인지하시고 사용하시기 바랍니다.

 

웹 호스팅 용도로 사용했다가 504 bad gateway를 마주했습니다.

504 (bad gateway) HTTP Code란 게이트웨이 또는 프록시 제한 시간이 초과되었음을 의미합니다.

만약 설정에 문제가 없었다면 어떤게 문제였을까요?

 

첫째로, EBS가 아닌 EFS를 사용하신다면, 파일 액세스 시간이 불필요하게 증가할 수 있습니다.

이 상황은 웹 앱이 짧은 시간동안 많은 작은 파일에 액세스 할 때마다 증폭되며,

PHP는 특히 로컬 파일 캐싱이 매우 중요합니다.

이것이 소규모 웹 호스팅에 EFS가 적합지 않은 첫 번째 이유입니다.

 

둘째로, EFS 볼륨에 대한 IO 작업은 버스트 크레딧이라는 크기 계층 시스템에 의해 제한됩니다.

버스트 크레딧이 부족할 경우, 애플리케이션에 문제를 야기할 수 있습니다.

EFS 볼륨을 사용하시면 전체 시스템 스캔을 통해서 많은 버스트 크레딧을 소모하기 때문에,

이런 내용도 유의하셔야 합니다.

 

 

1. 규모별 EBS 처리량

규모에 따른 내용으로만 봤을때는, 단순히 100G 이하의 EBS 볼륨은 1,750 mib/초의 처리량을 허용하는 반면

동일한 크기의 NFS 볼륨은 500kib/초의 처리량을 허용함을 나타냅니다

(EFS 볼륨 크기 조정은 아래 표 참조). 처리량이 최대 3,500배 감소합니다.

물론 해당 내용은 극적으로 단순화 시킨 내용입니다.

 

일반적으로 말해서 모든 저장 시스템은 비디오 파일과 같은 대용량 데이터 스트림을 더 효율적으로 검색하고,

Php 파일 무리와 같은 작은 파일을 무작위로 수집할 수 있는 것보다 더 효율적으로 검색합니다.

 

AWS Cloudwatch는 EFS에 대한 여러 성능 지표를 제공합니다. 물론 이들 중 가장 중요한 것은 버스트 크레딧 잔액입니다. 파일 세트를 EFS로 마이그레이션 할 때 버스트 크레딧 잔액에 미치는 영향을 완전히 이해하기 위해 하루 정도 이 메트릭을 모니터링해야 합니다.

 

 

2. 크기별 EBS IOPS

그렇다면, EBS와 EBS는 어떻게 생각하면 될까?

 

EBS는 직접 연결 스토리지에 액세스하는 단일 EC2 인스턴스용으로 설계된 반면,

EFS는 네트워크 연결 스토리지를 공유하는 최대 수천 개의 EC2 인스턴스용으로 설계되었습니다. 

EFS의 분산형 다중 AZ 아키텍처는 EBS보다 작업당 지연 시간이 더 깁니다.

 

따라서 EFS를 사용하실 경우에는, 데이터 복사 시간을 최소화하기 위해 여러 가지 방법을 권장합니다. 

먼저 NFS v4.1 사용, 특히 읽기 및 쓰기 IO 크기 조정을 포함하여 권장되는 마운트 옵션을 사용하고 있는지 확인해야 합니다. 

둘째, 4.0+ Linux 커널 버전이 있는 AMI를 사용하는 것이 좋습니다. 이러한 커널에서 NFS 클라이언트 구현이 많이 개선되었기 때문입니다. 

마지막으로 데이터 복사본을 병렬화하여 기존의 재귀 복사본보다 더 빠르고 효율적으로 파일을 EFS로 마이그레이션 할 수 있는 기회를 찾는 것이 좋습니다. 

데이터 복사본을 병렬화할 수 있는 유틸리티의 예로는 GNU Parallel이 있습니다.

이 스레드에는 웹 서비스 사용 사례에 대한 질문이 많이 있습니다. 오늘날 웹 호스팅에 EFS를 성공적으로 사용하고 있는 고객이 있습니다. 

웹 호스팅 설정을 설계하고 EFS가 적합한지 결정할 때 위에서 언급한 지연 시간 차이를 염두에 두십시오. 

예를 들어 캐싱을 활용할 수 있는지 여부를 평가하는 것이 좋습니다. 

캐싱 솔루션의 한 예는 컴파일된 PHP 스크립트를 메모리에 저장하고 지원에 필요한 네트워크 왕복 횟수를 최소화하는 PHP의 OPcache (http://php.net/manual/en/book.opcache.php )입니다. 

응용 프로그램. EFS 위에서 Wordpress와 같은 PHP 기반 웹 사이트를 실행할 때 OPcache를 사용하는 것이 좋습니다.