Amazon Elastic File System
- 관리된 NFS(Network File System)으로 여러 EC2 Instance에 마운트 할 수 있음
- EC2 Instance는 여러 가용영역(AZ)에 있어서 각 AZ에 있는 인스턴스에 대해 EFS 마운트 포인트(eg: /dev/sda/1 .. )
경로를 공유할 수 있도록 하여 파일 전송 및 관리가 편하다
- 높은 가용성과 확장성을 가지고 있음
- gp2 EBS Volume(범용)에 비해 3배정도 비쌈
- 사용할 때 마다 비용을 지불하며, 사전 Provisioning 용량이 없음
gp2 EBS Volume
1) 짧은 지연시간
2) 효율적인 비용의 스토리지
3) 시스템 부트 볼륨에서 가상 데스크탑 개발, 테스트 환경에서 사용가능
4) 1GB - 16TB, 최대 3,000 IOPS
5) 볼륨과 IOPS가 연결되어 있어서 IOPS가 증가하면 볼륨의 GB수를 늘릴때 같이 증가
위 그림처럼 EFS는 가용영역에 대한 EC2 Instance를 모두 공유하며 접근할 수 있는데, 이러기 위해서는 NFS 설정을 잘해둡니다.
이해를 돕기 위해 아래 그림으로 한 번 더 설명 드리겠습니다.
EFS 생성할 때 VPC 셋팅하는 방법입니다. 이는 NFS 관리하는 것이라 보면 되는데, 우선 한 리전에 대해 여러 가용영역은 VPC(이해하기 쉽게 VPN이라 생각해주시면 됩니다.)에 묶여서 통용되어 관리됩니다.
VPN은 현재 기본값으로 셋팅되어 있지만 이는 다른 VPN으로 변경이 가능합니다.
우선 기본 VPN으로 셋팅하고 거기에 탑재할 AZ로 한 리전에 연결된 모든 AZ를 가지고 왔고 각 리전에 따른 서브넷을 셋팅하고 앞으로
이 서브넷을 통해서 각 AZ가 파일 시스템을 공유한다는 것을 의미합니다.
또한 각 가용영역이 하나의(공유) 파일 시스템에 접근하기 위해서 필요한 보안 그룹을 셋팅합니다.
이는 인스턴스 쪽에서 보안그룹 탭에 미리 셋팅해두면 됩니다. (EFS를 이용하기 위한 보안 그룹을 새로 생성)
이렇게 보안그룹을 공유하기에 각 가용영역이 하나의 공유 파일 시스템에 접근하는 하나의 공통 보안 규칙이 생긴 것입니다.
※ EFS 특징
1) 내부적으로 NFS 프로토콜을 사용하며 EFS 접근을 제어하고자 보안 그룹을 위와 같이 설정합니다.
2) EFS는 윈도우 환경에선 할 수 없고 Linux 기반 AMI에만 호환합니다.
3) KMS를 통해 EFS 드라이브의 저장 데이터를 암호화할 수 있습니다.
4) POSIX 파일 시스템, 표준 File api를 사용합니다.
5) EFS 사용 용량을 미리 저장하지 않아도 되며, 파일 시스템은 자동으로 확장되기 때문에 EFS에서 사용하는 데이터의 1GB마다
비용을 지불하면 됩니다.
※ EFS - Performances & Storage classes
1) EFS Scale
- 수 천명의 NFS 클라이언트를 동시에 가질 수 있는 스케일에 10GB/s 이상의 용량을 가집니다.
- 미리 용량을 정해두지 않아도 자동으로 PB(페라바이트) 수준의 스케일로 확장할 수 있습니다. (사용 데이터의 1GB마다 비용 지불)
2) 파일 시스템을 생성할 때 EFS의 성능 모드를 설정할 수 있음
ㄱ. General purpose(Default)
- 지연 시간이 중요한 어플리케이션을 이용할 때 사용합니다.
- 다목적 용도로 사용합니다. 예:) 주로 웹 서비스 제공환경, 콘텐츠 관리 시스템, WordPress에서 스토리지를 사용할 경우 등이 있습니다.
ㄴ. I/O 극대화
- 지연 시간과 용량이 크게 필요할 경우 사용하며, 병렬 처리가 가능합니다. (초당 연산 작업이 최대, 용량 극대화)
- 빅데이터, 미디어 처리 등에 적합
3) 처리량 모드
ㄱ. Bursting mode (default)
- 1TB, 50 Mib/s 정도의 속도로 데이터를 전송합니다. 최대 100Mib/S 까지 가능
- 파일 시스템 크기와 비례한 용량을 가지며, 파일 시스템 크기가 커질수록 용량이 커지고 거기에 맞게 비용도 커집니다.
ㄴ. Provisioned (1~1024MiB/s)
- 프로비저닝도 설정이 가능 > 미리 사용 가능 용량을 받아놓고(프로비져닝) 처리하는 것
- 스토리지 크기와 무관하게 용량을 끌어다 쓸 수 있다는게 장점이지만, 초반 큰 처리량이 필요하단 단점이 있다.
(작은 파일시스템에 유용한 옵션)
4) 가용성 & 확장성
: 하나의 가용영역에서만 인스턴스를 공유하며 파일 시스템을 구축할 것인지, 여러 가용영역에 대해서 인스턴스를 공유하며
파일 시스템을 구축할 것인지 체크하는 부분입니다.
ㄱ. Standard(Reginal NFS)
- 여러 가용 영역에 대해서 데이터를 중복 저장이 가능하며 각 AZ에 인스턴스가 공유된 파일시스템 마운트 포인트를 공유 접근이 가능합니다.
ㄴ. One Zone
- 하나의 가용영역으로 하나의 EFS를 사용합니다. 따라서 가용영역이 다운된다면 EFS 또한 다운됩니다. (비용이 저렴)
5) 생명주기 (Storage Classes)
: 자주 사용하지 않는 객체에 대해서 다른 계층으로 보내놓고 용량 절감, 스토리지 비용절감 등을 하며, 다시 사용한다하면 사용 계층으로 전환할 수도 있음
ㄱ. Standard계층
- 주로 사용하는 파일 및 객체 등을 관리합니다. 기본적으로 셋팅된 계층입니다.
ㄴ. Standard Infrequent Access 계층 (수명주기를 설정해서 그 기간 동안 사용하지 않는 파일 및 객체가 이동하는 계층공간)
- 사용하지 않는 객체나 파일 등이 자동으로 이동되는 계층으로, 비용 및 스토리지 용량 절감을 위해 만들어 둔 계층입니다.
- 다시 IA 밖으로 전환하는 것도 조건 셋팅하여 관리할 수 있습니다.
 |
 |
Network Access 셋팅
1) VPC(Virtual Private Cloud)
- 외부 퍼블릭 클라우드로 이동하기 전에 사설 클라우드 환경에서 보안 그룹이라든지, 네트워크 통신이라든지 관리하는 곳으로
NFS를 생성할 때 어떤 VPC를 사용할 지 체크합니다.
이는, EC2 인스턴스를 파일 시스템에 연결할 때 필요한 작업이며 하나의 VPC에 여러 가용영역이, 그 가용영역에는 여러 인스턴스들이
있고 그 여러 인스턴스들이 파일 시스템을 공유하기 위한 일련의 환경 구축 과정이다.
2) Mount Targets
- EFS 리전 유형 선택, 그 안에 AZ영역을 선택합니다.
- Amazon EFS 파일 시스템을 탑재할 수 있는 NFS V4 엔드포인트를 제공합니다. (파일 시스템이 각 사용 영역에 붙기 위해 필요한
네트워크 파일 시스템에 엔드포인트를 제공한다는 것입니다.)
- 가용영역마다 mount target을 한 개씩 생성해두는 것이 좋다.
- EFS 마운트하는 NFS 셋팅 과정에서 Security Group은 동일하게 줘야 합니다.
이렇게 생성한 EFS(Elastic File System)에 대해 각 가용영역에 인스턴스를 붙이는 작업을 해야 합니다.
따라서 인스턴스 생성할 때 서브넷(파일 시스템 생성할 때 구성해둔 각 가용영역에 따른 서브넷ID)을 셋팅하고
스토리지를 구성할 때 EFS를 공유 조건으로 두면 됩니다.
(파일 시스템 정책은 생략하고 넘어갑니다)
EFS를 사용한다고 설정하고 인스턴스를 생성해보겠습니다.
인스턴스 생성할 때 다른 옵션들은 앞서 EC2 Instance 편에서 셋팅한대로 진행하면 되지만, VPC 셋팅할 땐 파일 시스템에 정의한대로
진행해야 합니다.
VPC 같은 경우도 앞서 파일 시스템에서도 Default로 셋팅했기 때문에 인스턴스 생성도 같은 VPC 내에서 돌아갈 수 있도록 셋팅하고
VPC 내 존재하는 AZ에 대해서 각각 접근하기 위해서 서브넷 정보를 셋팅합니다.
이는 파일 시스템 네트워크 접근 셋팅하는 부분에서 각 가용영역에 대한 서브넷 아이디이며, 내가 만들 가용영역에 대한 서브넷 아이디를
셋팅해주면 됩니다.
스토리지 구성에서 파일 시스템 등록하는데 가용 가능한 리전으로 탑재 지점을 자동 셋팅하는 걸로 처리해주면 됩니다.
단, 여기서 파일 시스템에 대한 액세스를 할 때 보안 그룹이 자동으로 생성되도록 셋팅했기 때문에 파일 시스템에 연결된 각 가용영역
(예: ap-northeast는 4개)에 각각 파일 시스템 접근 보안그룹이 셋팅됩니다.
앞서 EFS에 NFS 셋팅할 때 네트워크 접근 권한에서 공용으로 사용할 보안 그룹을 설정해뒀기 때문에 저 부분은 비활성화 해도 됩니다.
만약 저렇게 계속 활성화를 하고 인스턴스를 생성하게 된다면 보안 그룹이 계속해서 생성될 것이고, 일정 보안그룹 갯수가 넘어가게 되면
인스턴스 생성에도 문제가 발생합니다.
(오류 내용 > 보안그룹이 너무 많아서 인스턴스 생성에 문제가 발생합니다.)
또한 인스턴스 타입이 해당 AZ에서 사용할 수 있는지를 체크해야 합니다.
가용 영역에서 처리되지 않는 인스턴스 타입을 설정해두었다면 인스턴스 생성은 되지 않습니다.
(가령, ap-northeast-1b가 t2.micro를 제공하지 않는 것처럼; 반드시 확인해야 합니다!)
efs-util 부분은 사용자 데이터 스크립트를 각각 연결해서 인스턴스를 생성한다는 의미로, 기본 부팅할 때 처음 돌아가는
셋팅 작업을 각 AZ에 대한 인스턴스에 대해서도 진행할지 말지를 처리하는 것입니다.
이렇게 만들어진 인스턴스(각 가용영역)들에 대해서는 보안그룹이 기본 인스턴스에 셋팅된 보안그룹과
파일시스템에 연결된 보안그룹이 잡히게 됩니다.
파일 시스템으로 연결된 보안그룹을 선택해서 보게 되면 각 인스턴스는 보안그룹을 공유하며 포트 또한 동일한 것을 알 수 있습니다.
이렇게 각각의 가용영역에 대한 인스턴스를 하나씩 접근해서 인스턴스 연결 후 클라우드 서버를 실행했을 때
EFS의 탑재 지점인 /mnt/efs/fs1 인 경로에 대해 파일을 생성하게 된다면, 각기 다른 가용영역에 인스턴스임에도 불구하고
해당 경로에 파일은 공유하여 확인할 수 있습니다. (읽기, 쓰기 권한 OK)
EBS & EFS 문제 정의
- EBS는 기본적으로 가용영역 하나에 대해서 인스턴스를 만들어 진행하는 것이고 네트워크 드라이브로, 한 가용영역에 대해서만 셋팅되며 특정 가용영역 안에 있는 인스턴스들에 다중 접근하기 위해서는 프로비저닝된 IOPS를 받은 io1, io2 EBS 볼륨에 대해서 접근이 가능
- EFS는 한 리전에 대한 여러 가용영역에 대해서 각 인스턴스들이 접근할 수 있으며, 보안그룹을 공유하고 각 서브넷에 마운트된
파일시스템에 대해서 탑재 경로(타겟 포인트)에 대해 동일 접근 및 공유가 가능합니다.
Q1. us-east-1a에서 EC2 인스턴스를 종료했으며 연결된 EBS 볼륨을 이제 사용할 수 있습니다. 팀원이 us-east-1b의 EC2 인스턴스에
연결하려고 하지만 연결할 수 없습니다. 원인은 무엇인가요?
▷ EBS는 기본적으로 특정 가용영역에 묶여 있기 때문에 해당 가용영역에서는 여러 인스턴스를 접근할 수 있지만(프로비저닝 된 IOPS를 사용하는 io1, io2 EBS 볼륨에 대해서..) 각기 다른 가용영역에 대한 인스턴스 접근은 할 수 없습니다.
각기 다른 가용영역에 인스턴스로 생성하기 위해서는 EBS 스냅샷을 이용해서 EBS 볼륨 셋팅을 한 다음에 생성해야 합니다.
Q2. EC2 인스턴스를 시작하여 루트 볼륨 유형과 EBS 볼륨 유형 이 두가지의 EBS 볼륨에 데이터를 저장합니다.
한 달 후 EC2 인스턴스를 종료할 계획인데, 종료할 경우 각 EBS 볼륨에 발생하는 기본 동작은 무엇입니까?
▷ 루브 볼륨 유형은 기본값으로 인스턴스가 종료될 때 같이 종료되는 것으로 셋팅되어 있지만, 새로 만든 EBS 볼륨 유형 같은
경우는 기본값으로 인스턴스 종료시에도 남아 있는 것으로 셋팅되어 있습니다.
따라서 루트 볼륨 유형은 삭제되고 EBS 볼륨 유형은 삭제되지 않습니다.
Q3. N.Virginia 지역 us-east-1의 AMI를 사용하여 모든 AWS 지역에서 EC2 인스턴스를 시작할 수 있습니다.
▷ 거짓
AMI는 하나의 리전에 대한 여러 가용 영역에는 복제 형태로 사용해서 인스턴스를 생성할 수 있지만,
다른 지역에 대해서는 생성할 수 없습니다.
(AMI: EC2 Instance에 연결된 EBS Volume을 모두 백업하는 것 = Snapshot에서 AMI로 생성하게 되면,
당시 인스턴스의 OS 환경과 인스턴스타입(CPU 프로세서), 소프트웨어 및 환경 등을 복제해 사용하게 됩니다.)
-> AMI를 대상 AWS 지역에 복사한 다음 이를 사용해서 인스턴스를 생성하는 것(Snapshot 개념)
Q4. EC2 인스턴스를 생성할 때 부팅 볼륨으로 사용할 수 있는 EBS 볼륨은?
▷ SSD // gp2, gp3, io1, io2 (provisioned)
cf. st1, sc1 -> HDD (부팅 볼륨 X)
Q5. EBS 다중연결
▷ 동일한 AZ의 여러 EC2 인스턴스에 대해서 동일한 EBS 볼륨을 연결하는 것 (프로비전된 EBS 볼륨: io1, io2)
(각 인스턴스는 전체 읽기, 쓰기 권한 부여)
Q6. 8TB gp2 EBS 볼륨을 프로비전했으나 IOPS가 부족합니다. 성능을 높이는 방법은?
▷ io1 볼륨 유형 변경하기
▷ RAID 0에 EBS 볼륨 마운트하기
▷ EBS IOPS는 16,000 IOPS 또는 이에 상응하는 5334GB에서 최고조에 달하기 때문에
여기서 더 EBS 볼륨 크기를 늘릴 순 없습니다.
Q7. 대규모 데이터 세트를 처리하는 여러 AZ에 분산된 EC2 인스턴스 집합이 있습니다.
모든 EC2 인스턴스에서 NFS 드라이브로서 동일한 데이터에 액세스할 수 있도록 하려면 어떤 것을 권장해야 하나요?
▷ 여러 AZ에 대해서 분산된(=AZ마다 존재한 인스턴스) 인스턴스 집합인데 이 인스턴스들이 NFS(네트워크 파일 시스템)으로서
동일한 데이터에 접근을 하려면 공통으로 활용할 EFS를 설정하고 서브넷 ID를 각각 셋팅한 다음 보안 그룹을 동일시하여
NFS의 액세스 규칙으로 설정하면 됩니다.
마운트 포인트가 되는 곳에서 파일을 공유할 수 있습니다. (=> EFS를 사용한다.)
Q8. EC2 인스턴스에서 호스팅되는 애플리케이션용 고성능 로컬 캐시를 원합니다. EC2 인스턴스가 종료될 때 캐시를
잃어도 상관 없을때, 솔루션 아키텍트로서 어떤 스토리지 매커니즘을 권장해야 하나요?
▷ 애플리케이션용 고성능 로컬 캐시(메모리 최적화 인스턴스 >> R시리즈, X1, X2, ... Z1)
- 대규모 비정형 데이터를 실시간으로 처리하거나 인메모리 데이터베이스를 사용하는 등 꽤나 많은 디스크 용량과
I/O 처리가 필요함
▶ EC2 인스턴스 스토어(최고의 디스크 I/O 성능을 제공) = EBS Volume(Instance Store Volume)
▷ 인스턴스 블록 수준의 임시 스토리지 제공, 호스트 컴퓨터에 물리적으로 연결된 디스크
Q9. 기본 저장소에 대해 310,000의 IOPS를 요구하는 고성능 데이터베이스가 있다.
이에 맞는 환경을 셋팅하려면 어떤 것을 고려해야 할까?
▶ EC2 인스턴스 스토어 사용(최고의 디스크 I/O 성능 제공, 고성능 IOPS 처리)
인스턴스 스토어를 사용하는 EC2 인스턴스에서 데이터베이스를 실행할 수 있지만 EC2 인스턴스가 중지되면
데이터가 손실되는 문제가 있음(다시 시작 가능)
이에 대한 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가질 수 있도록 한다.
또 다른 솔루션은 데이터에 대한 백업 메커니즘을 설정하는 것입니다.
요구 사항을 검증하기 위해 아케틱처를 설정하는 방법은 모두 사용자에게 달려 있습니다.
이 사용 사례에서 필요사항은 IOPS이므로 EC2 인스턴스 스토어를 선택하는 것이 맞습니다.
※ EC2 Instance Store Volume(EBS Volume)
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/InstanceStorage.html
EBS io2 Block Express > 최대 256,000 IOPS
EBS io1, io2 드라이브 사용 > 최대 64,000 IOPS
EBS gp2 드라이브 사용 > 최대 16,000 IOPS
'Cloud' 카테고리의 다른 글
| AWS - ELB(CLB) (2) | 2023.01.17 |
|---|---|
| AWS - ELB & ASG (0) | 2023.01.17 |
| AWS - AMI (1) | 2023.01.17 |
| AWS - EBS (0) | 2023.01.17 |
| AWS - EC2 Instance 구매 옵션 (0) | 2023.01.17 |
