EC2는 IaaS입니다.
EC2는 아래와 같이 여러 가지 서비스를 제공합니다.
- EC2: VM입니다. EC2 인스턴스라고 부릅니다.
- EBS: 데이터를 virtual 드라이브 또는 EBS 볼륨에 저장할 수 있습니다.
- ELB: Load balancer.
- ASG: Automated scailing.
EC2의 인스턴스를 만들 때 여러 옵션이 있는데, 이들 가운데 bootstrap 스크립트(EC2 유저 데이터)에 대해 알고 있어야 합니다.
이것을 써서 머신이 처음 시작될 때 어떤 커맨드를 돌릴 것인지 정해 둘 수 있습니다.
예를 들면 소프트웨어를 깔고, 업데이트하는 등이 있겠죠.
EC2 인스턴스를 만들 때 키 페어가 필요한데,
이 키 페어는 SSH를 통해 인스턴스에 로그인할 때 필요합니다.
(키 페어 타입은 RSA로 하세요.)
이 키 페어 데이터를 담고 있는 파일이 *.pem 파일입니다.
EC2 인스턴스 타입
EC2 인스턴스에는 naming convention이 있으니, 이를 읽을 줄 알면 좋습니다.
예) m5.2xlarge
- m: 인스턴스 클래스
- 5: 제너레이션 (하드웨어 퍼포먼스가 발전할 때마다 올라감)
- 2xlarge: 인스턴스 클래스 크기, 클수록 더 많은 메모리와 CPU를 가짐
인스턴스 클래스마다 어떻게 쓰이는지가 테스트에 나올 수 있습니다.
- 범용 인스턴스: 웹 서버, 코드 스토리지 등. Compute, 메모리, 네트워크 퍼포먼스 밸런스.
- Compute Optimized: 컴퓨터 집약적 작업에 최적화(CPU 위주). 배치 프로세스, 미디어 transcoding, 고성능 웹 서버, HPC, 기계학습, 게임 서버 등.
- 메모리 Optimized: 인메모리 DB, 분산 웹 스케일 캐시 저장소(ElasticCache), 대규모 비정형 데이터를 실시간으로 처리하는 애플리케이션 등.
- 스토리지 Optimized: OLTP 시스템, DB, 인메모리 DB, 데이터 웨어하우스, 분산 파일 시스템 등.
시큐리티 그룹
보안 그룹은 EC2 인스턴스의 트래픽을 컨트롤합니다. 파이어월이죠.
Inbound 룰과 outbound 룰을 정하면 됩니다.
Inbound 룰은 바깥에서 EC2 인스턴스로 들어오는 트래픽에 대한 룰입니다.
디폴트로 모든 트래픽을 막으니, 허용 룰만 만들면 됩니다.
Outbound 룰은 EC2 인스턴스에서 바깥으로 나갈 때의 트래픽에 대한 룰입니다.
예를 들면, EC2에서 어떠한 웹 사이트에도 액세스할 수 있습니다.
디폴트로 모든 트래픽을 열어 두니, 필요한 경우 룰을 만들면 됩니다.
Inbound 룰을 정하는 페이지입니다.
- 유형: 어떤 프로토콜의 트래픽에 대한 룰인지 정합니다. SSH, HTTP 등이 있고 사용자 지정 프로토콜으로 정할 수도 있습니다.
- 프로토콜: 위 유형에 따라 정해집니다. 사용자 지정 프로토콜인 경우 직접 쓰면 됩니다.
- 포트 범위: 위 유형에 따라 정해집니다. 사용자 지정 프로토콜인 경우 직접 쓰면 됩니다.
- 소스: 위 이미지처럼 사용자 지정인 경우는 옆에 있는 칸에서 IP 주소 또는 IP 주소 범위를 쓰면 되고, 사용자 지정 말고는 모든 IPv4, 모든 IPv6, My IP 옵션이 있습니다.
보안 그룹에서 정해 놓은 룰들은 region에 종속됩니다.
그리고 보안 그룹은 EC2 안에 있는 애플리케이션이 아니라 바깥에 있는 파이어월입니다.
따라서 트래픽이 막히면 EC2 인스턴스에 액세스할 수 없습니다.
디폴트 포트는 알고 있는 게 좋겠죠.
- 22: SSH, 리눅스에서 EC2 인스턴스에 로그인할 수 있게 해 주는 역할입니다.
- 21: FTP
- 22: SFTP, 잘못 쓴 거 아닙니다. SSH를 쓰는 FTP입니다.
- 80: HTTP, 보안이 되어 있지 않은 웹 사이트에 액세스할 수 있습니다.
- 443: HTTPS
- 3389: RDP(Remote Desktop Protocol), 윈도즈 인스턴스에 로그인할 수 있게 해 줍니다.
SSH는 CLI를 쓰는 어떠한 터미널(remote 머신)을 컨트롤합니다.
SSH는 CLI 툴로, Mac, 리눅스, 윈도즈 10 이상 버전에서 쓸 수 있습니다.
10 미만 버전이면 PuTTY 쓰시면 되고요. PuTTY = SSH입니다.
어 그리고 다른 방법으로 EC2 인스턴스 커넥트라는 것도 있습니다.
이거는 웹 브라우저로 EC2 인스턴스에 연결하는 도구입니다.
OS 상관없이 다 쓸 수 있지만, 지금은 Amazon Linux2에서만 쓸 수 있습니다.
그리고 EC2 인스턴스에 IAM 롤을 정할 수 있다는 점을 잊지 마시고요.
예를 들어 어떤 IAM 롤에 IAMReadOnlyAccess 권한을 준 뒤,
EC2 인스턴스에 위 IAM 롤을 줬다면 EC2 인스턴스에서 aws iam list-users 쳤을 때 관련 정보가 나올 겁니다.
EC2 인스턴스 옵션
EC2 인스턴스에는 여러 가격 옵션들이 있습니다.
EC2 인스턴스에게 어떤 일을 시킬 것인지에 따라서 어떤 옵션을 고를지 알아야 싸게 쓸 수 있습니다.
테스트에서도 중요한 파트입니다!
- 온 디맨드 인스턴스
- 짧은 일에 알맞습니다.
- OS가 리눅스 또는 윈도즈인 경우 인스턴스가 돌고 나서 첫 1분이 지난 뒤부터, 인스턴스를 쓰는 초 만큼 내면 되기 때문에 가격을 예측할 수 있습니다.
- 다른 OS들은 인스턴스가 돌고 있는 매 시간 단위로 가격이 올라갑니다.
- 조금 비싼 편이지만 선결제를 하지 않아도 되고, 장기 약정도 없습니다.
- 쓰고 싶을 때 쓰고, 멈추고 싶을 때 멈추고, 없애고 싶으면 없애면 됩니다.
- 애플리케이션이 어떻게 될지 알 수 없는, 연속적인 단기 태스크 위주일 때 좋습니다. - 예약 인스턴스
- 최소 1년 이상 써야 합니다. 구체적으로 1년 또는 3년 중에 하나를 고르면 됩니다.
- 온 디맨드에 비해 약 75%의 비용을 절약할 수 있습니다. 당연히 3년이 더 싸겠죠.
- 또 선결제를 해도 되고, 부분적으로만 할 수도 있고, 안 할 수도 있습니다. 선결제가 가장 쌉니다.
- 예약 인스턴스는 3가지로 나뉩니다.
- 예약 인스턴스: DB처럼 일을 계속 해야 할 때 알맞습니다.
- 전환형 예약 인스턴스: 첫 예약 기간이 끝난 뒤 다른 인스턴스로 바꿀 수 있습니다. 대신 할인율은 54%로 조금 낮습니다.
- 정기 예약 인스턴스(지금은 없는 서비스지만 시험에는 나올 수 있음): 기간 내내는 아니지만 긴 기간 동안 특정일, 또는 특정시간에 돌아가는 일에 알맞습니다. 딱 스케줄러가 떠오르네요. - 스폿 인스턴스
- 온 디맨드와 비교했을 때 최대 90%까지 싸게 쓸 수 있는 인스턴스입니다.
- 스폿 인스턴스의 가격은 계속 바뀝니다. 만약 여러분이 낸 가격이 스폿 인스턴스의 현재 가격보다 낮다면 인스턴스가 언제든지 중단될 수 있으므로, 꼭 체크가 필요합니다.
- 싼 대신에 손실 가능성이 있고 신뢰도가 낮습니다.
- 따라서 갑자기 멈춰져도 다시 하기 쉬운 일이 알맞겠죠. 예를 들어 단발성 데이터 분석인 배치, 이미지 processing, 분산된 일들(여러 서버에 일을 나누어 놓아 하나가 안 되면 다른 서버에서 뭔가 할 수 있는), 일의 시작과 끝 시간이 유연한 일들.
- 반대로 중요한 일이나, 특히 DB는 절대 이 인스턴스를 쓰면 안 되겠죠. - 전용 호스트
- 물리적 서버 전체를 예약하고, 인스턴스 배치를 컨트롤할 수 있습니다.
- 즉 AWS 데이터 센터에 있는 하나의 서버를 통으로 빌리는 거죠.
- 전용 호스트를 쓰면 준수 요건(compliance requirements)에 맞추기가 쉽고, 기존의 서버 결합(server-bound) 소프트웨어 라이선스를 쓸 수 있기 때문에 코스트를 줄일 수 있습니다. 어쨌든 서버를 통으로 빌리는 거니까 애초에 비싸긴 하겠죠.
- 3년간 써야 합니다.
- 복잡한 라이선스 모델의 S/W를 쓰거나 자가 라이선스를 가진 케이스, 혹은 강력한 규제나 규정 준수 요건이 있는 케이스, 여러분만 쓸 수 있는 물리적 서버가 필요할 수 있는데 그럴 때 많은 도움이 될 것입니다. - 전용 인스턴스
- 여러분의 전용 H/W에서 돌아가는 EC2 인스턴스를 말합니다.
- 같은 계정의 다른 인스턴스와 H/W를 공유합니다.
- 인스턴스가 어떻게 배치될지는 여러분이 컨트롤할 수 없습니다.
- 전용 호스트와 마찬가지로 지켜야 할 것이 있어 H/W를 다른 사람과 공유하고 싶지 않을 때 알맞습니다.
스폿 인스턴스
만약 현재의 스폿 인스턴스 가격이 여러분이 정한 가격을 넘어버리면 2분의 시간이 주어집니다.
그 안에 인스턴스를 중단시킬 것인지, 종료시킬 것인지 정해야 하죠.
중단한다면,
나중에 스폿 인스턴스의 가격이 여러분이 정한 가격 아래로 내려갈 때 중단했던 그 부분부터 다시 쓸 수 있습니다.
종료시킨다면 인스턴스를 없애는 것이고, 위와 같은 상황이 되었을 때 처음부터 다시 쓸 수 있습니다.
또 다른 전략은 스폿 블록인데요. 곧 없어질 서비스지만 아직 테스트에는 나오고 있으니 한 번 알아봅시다.
이 전략을 쓰면 AWS로부터 인스턴스를 빼앗길 일이 없어집니다.
스폿 인스턴스를 1 to 6시간 안으로 "블록"하여,
AWS가 인스턴스를 "회수"하는 일이 일어나지 않도록 하는 것입니다.
스폿 플리트
스폿 플리트는 강력한 코스트 절감 방법으로,
한 세트의 스폿 인스턴스에 선택적으로 온 디맨스 인스턴스를 섞어 쓰는 것을 말합니다.
여러분은 스폿 플리트에게 코스트와 capacity를 말해 주시면 됩니다.
그러면 스폿 플리트는 정해진 코스트 안으로 타깃 capacity를 만족시키려 할 것입니다.
하나의 launch pool은 여러 인스턴스 타입, OS, AZ를 가지는데,
이러한 풀이 여러 개 있으니 여러분이 생각해야 한다면 꽤 많은 시간이 걸릴 수 있는 일입니다.
스폿 플리트 덕분에 그런 생각은 할 필요가 없죠.
그리고 스폿 인스턴스들을 스폿 플리트 안에 어떻게 할당시킬 건지에 대한 여러 전략이 있습니다.
- lowestPrice: 가장 싼 풀부터 인스턴스를 실행시킵니다. 싸게 쓸 수 있으며, 짧게 끝나는 일을 할 때 알맞습니다.
- diversified: 스폿 인스턴스들을 여러분이 정해 놓은 모든 풀에 걸쳐 분산시킵니다. 가용성이 좋겠죠? 하나의 풀이 중단되더라도 다른 풀은 계속 돌아갈 테니까요. 길게 걸리는 일을 할 때 알맞습니다.
- capacityOptimized: 인스턴스의 개수에 따라 최적화된 용량으로 실행될 것입니다.
만약 정해진 코스트나 capacity를 벗어나게 되면 돌아가고 있는 인스턴스들을 중단 또는 종료시킵니다, 여러분이 정할 수 있습니다.
배치 그룹
배치 그룹은 EC2 인스턴스가 AWS 인프라에 어떻게 배치될지 방식을 컨트롤하고 싶을 때 씁니다.
배치 그룹을 만들 때 3가지 전략 중 하나를 고르게 될 것입니다.
- 클러스터
- 하나의 랙(H/W), 하나의 AZ에 여러 인스턴스를 배치.
- 빠른 네트워크 스피드.
- 랙에 실패가 생기면 모든 EC2 인스턴스가 동시에 실패.
- 빠른 스피드가 필요한 빅 데이터 태스크나, 정말 짧은 지연시간과 높은 네트워크 처리량을 필요로 하는 애플리케이션에 알맞음.
- 스프레드
- 인스턴스들이 다른 랙에 분산 배치됨.
- 위험을 줄일 수 있음.
- 하나의 AZ당 최대 7개의 인스턴스만 배치할 수 있고, 하나의 AZ에 최대 7개의 랙을 가질 수 있음.
- 가용성이 높아야 하는 케이스, 위험을 줄여야 하는 크리티컬 애플리케이션에 알맞음.
- 파티션
- 인스턴스가 여러 파티션에 분산 배치됨.
- AZ마다 최대 7개의 파티션만 배치할 수 있음.
- 파티션마다 배치할 수 있는 EC2 인스턴스의 수에는 리밋이 없음.
- 파티션은 같은 region에 있는 여러 AZ에 걸쳐 있을 수 있음.
- 위험이 파티션별로 고립됨.
- 스프레드보다는 위험이 조금 높음.
- 그룹당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고 이를 통해 Hadoop, Cassandra, Kafka 같은 애플리케이션을 돌릴 수 있음.
- 파티션을 인식할 수 있는 빅 데이터 애플리케이션들을 쓰기에 알맞음.
EBS
EBS(Elastic Block Store) 볼륨은 EC2 인스턴스가 돌아가고 있을 때 쓸 수 있는 네트워크 드라이브입니다.
(Physical 드라이브가 아닙니다!)
볼륨이기 때문에 원하는 capacity, IOPS를 미리 정해 주어야 합니다.
정한 만큼의 코스트가 생길 거고요, 나중에 바꿀 수도 있습니다.
인스턴스와의 커뮤니케이션을 위해 네트워크를 쓰기 때문에 지연이 있을 수 있습니다.
EC2 인스턴스를 끈(shut down) 뒤에도 데이터들은 남아 있습니다.
서로 독립적인 거니까요.
따라서 인스턴스를 다시 만들고 이전 EBS 볼륨을 마운트 하면 그 데이터들을 다시 쓸 수 있습니다.
다른 인스턴스에 빠르게 커넥션을 만들 수도 있고요.
그리고 EBS 볼륨들은 AZ에 종속되어 있습니다.
다른 AZ에 옮기고 싶으면 스냅숏을 쓰면 됩니다.
다음은 테스트에 나올 수 있는데요, EC2 인스턴스를 없앨 때 EBS 볼륨을 같이 없앨 수 있습니다.
루트 볼륨은 디폴트 값으로 체크가 되어 있고요, 나머지 볼륨에 대해서는 그렇지 않습니다.
여러분이 원하시는 대로 세팅을 바꾸시면 됩니다.
AMI
EC2 인스턴스의 베이스가 되는 AMI(Amazon Machine Image)에 대해 조금 알아보고 갑시다.
쉽게 말하자면 커스텀 EC2 인스턴스라 할 수 있습니다.
- 여러 S/W들, 세팅들, OS, 모니터링 시스템 등을 정해 놓을 수 있습니다.
- 미리 다 정해 놔서 부팅 및 세팅 타임이 많이 줄어들겠죠.
- 어떤 region에 맞게 짤 수도 있고, 다른 region에 복사도 할 수 있고요.
이러한 AMI는 AWS에서 만들어 놓은 게 있고요, 여러분이 만들 수도 있고요, 마켓플레이스에서 구할 수도 있습니다.
AMI 프로세스는 다음과 같습니다.
- EC2 인스턴스를 켠 뒤 customize.
- 인스턴스를 끈 뒤 데이터 무결성 확보.
- 빌드 AMI, EBS 스냅숏도 만들어짐.
EC2 인스턴스 스토어
EBS 볼륨은 네트워크 드라이브라 퍼포먼스에 리밋이 있습니다.
높은 퍼포먼스가 있어야 된다면 EC2 인스턴스 스토어를 쓰세요.
EC2 인스턴스는 VM이지만 하드웨어 서버랑 커넥션이 있습니다.
EC2 인스턴스 스토어를 쓸 때 잊으면 안 되는 점이 있는데,
스토어가 멈추게 되면 인스턴스 스토어의 콘텐츠들을 잃게 될 수 있습니다.
그래서 EC2 인스턴스 스토어를 temporarily 스토리지라 부릅니다.
따라서 버퍼, 캐시 같이 잠깐 쓰는 콘텐츠를 담는 것이 좋겠죠.
또한 EC2 인스턴스에 에러가 생기면 스토어에도 이펙트가 가서 콘텐츠를 잃을 수 있습니다.
그러니 백업이나 복제본을 만들어 둬야 할 수 있습니다.
EC2 인스턴스는 AWS 네트워크에선 프라이빗 IP 어드레스를, WWW에선 퍼블릭 IP 어드레스를 씁니다.
EC2 인스턴스를 멈췄다가 다시 시작하면 퍼블릭 IP 어드레스가 바뀝니다.
만약 멈췄다가 다시 시작해야 하는데 어드레스가 바뀌는 게 싫다면 EIP를 쓰세요.
※ EIP는 만들어 놓고 쓰지 않으면 코스트가 생깁니다.
ENI
ENI(Elastic Network Interface)에 대해 알아봅시다.
VPC의 엘리먼트 가운데 하나로, virtual 네트워크 카드입니다.
ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해 줍니다.
EC2 인스턴스를 만들면 디폴트 ENI인 Eth0에 이어져
바로 EC2 인스턴스에게 네트워크를 쓸 수 있게 해 줍니다.
ENI들은 아래와 같은 캐릭터들을 갖습니다.
- 프라이빗 IPv4를 갖고, 하나 이상의 보조 IPv4를 가질 수 있습니다.
- 프라이빗 IPv4마다 EIP 어드레스를 가질 수 있습니다.
- 하나의 퍼블릭 IPv4를 가질 수 있습니다.
- 하나 이상의 시큐리티 그룹에 들어갈 수 있습니다.
ENI는 EC2 인스턴스에 종속되는 게 아니라, AZ에 종속됩니다.
그냥 ENI를 따로 만들 수도 있고요.
EC2 인스턴스 장애 조치를 위해 여러 ENI를 이을 수도 있습니다.
A 인스턴스에 Eth0, Eth1를 이어 놓고 B 인스턴스에 Eth0을 이었다 칩시다.
A 인스턴스에 에러가 생겼을 때 Eth1을 B로 옮겨서 프라이빗 IP 어드레스를 이동시킬 수 있는 겁니다.
이를 위해선 EC2 인스턴스의 네트워크 인터페이스 메뉴에서 액션 메뉴의 Detach 아이템을 쓰면 됩니다.
ENI에 코스트는 붙지 않습니다.
EC2 Hibernate
EC2의 새 기능인 절전 모드(hibernate)에 대해 알아봅시다.
EC2 인스턴스를 처음으로 시작할 땐 OS를 부팅시키고 유저 데이터에서 스크립트를 돌립니다.
그 다음에 애플리케이션을 돌리고, 캐시도 준비시킵니다.
가벼운 일은 아니죠?
그래서 절전 모드가 생겼습니다.
절전 모드를 하면 메모리가 보존됩니다. OS를 멈추지도 않고요.
그래서 절전 모드에서 인스턴스를 다시 시작하면 부팅이 굉장히 빨리 되겠죠.
어떻게 메모리가 보존되는 걸까요?
램의 스테이트를 루트 EBS 볼륨에 넣는 겁니다, 따라서 이 볼륨을 암호화해 놓을 필요가 있습니다.
흐름은 위와 같습니다.
메모리가 인스턴스에서 암호화된 EBS 루트 볼륨으로,
나중에는 다시 인스턴스로 가는 걸 볼 수 있죠.
유즈 케이스로는 오래 돌아가는 프로세스, 초기화가 오래 걸리는 서비스인 케이스 등이 있습니다.
절전 모드는 나온지 그렇게 오래 되지 않아 아직 에러가 있을 수 있다 합니다.
모든 EC2 인스턴스가 절전 모드를 쓸 수 있는 것은 아닙니다.
인스턴스 타입에 따라 갈립니다.
인스턴스의 램 사이즈는 150GB 아래여야 하고요.
스폿 인스턴스에서는 못 씁니다.
그리고 60일 넘게 절전 모드로 둘 수 없습니다.
EC2 니트로
니트로 시스템은 다음 제너레이션의 EC2 인스턴스를 위한 디폴트 플랫폼입니다.
낡은 virtualization 기술을 업그레이드했습니다.
퍼포먼스가 올라갔습니다, 디테일하게 보자면 아래와 같습니다.
- 더 나아진 네트워킹 옵션들을 고를 수 있습니다. 예를 들어 HPC, IPv6 등이 있습니다.
- 더 빠른 EBS 볼륨을 오퍼합니다. 니트로 없이는 32000IOPS까지만 오퍼하는데 니트로를 쓰면 64000IOPS까지도 오퍼합니다.
두 번째는 vCPU입니다.
예를 들어 m5.2xlarge에는 physical 코어가 4개가 있고 코어당 디폴트 스레드는 2개 있으면 vCPU는 8개가 있다고 합니다.
(https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html#cpu-options-gen-purpose)
vCPU에 대해 알고 있는 것은 'CPU 옵션의 optimization을 할 수 있다'로 이어집니다.
예를 들어 하이 퍼포먼스 램이 필요한데 많은 코어는 필요하지 않을 때,
코어 수를 줄여 돈을 아낄 수 있거든요. AWS에게 물어 보면 해 주고요.
아니면 코어당 스레드 수를 줄일 수도 있습니다.
예를 들어 HPC로 쓸 때는 코어당 하나의 스레드만 갖는 게 유리하거든요.
이런 경우에도 AWS에게 해 달라고 말할 수 있습니다.
위 링크에서 볼 수 있듯이 고를 수 있는 옵션들을 쉼표로 나누어 놓은 것을 볼 수 있습니다.
이 옵션들은 인스턴스를 시작할 때만 바꿀 수 있습니다.
EC2 Capacity Reservation
EC2 인스턴스를 시작할 때 바라는 capacity를 가질 수 있게 해 줍니다.
Reservation에 대해 날짜를 정하고, 언제까지 가지고 있을 건지도 정할 수 있습니다.
다만 이 reservation은 짧은 reservation입니다. 1년 또는 3년, 이런 게 아닙니다.
어떤 피리어드에 어떤 인스턴스 타입을, 어떤 AZ에서 인스턴스를 시작해야 하는지 알 때 도움이 될 것입니다.
EBS 볼륨 타입
- gp2 / gp3
- General-purpose의 SSD 볼륨.
- Efficient 코스트, 짧은 지연.
- 1GB to 16TB.
- gp2는 볼륨과 IOPS가 이어져 있기 때문에 볼륨을 늘리면 IOPS도 늘어남.
- gp3는 가장 새로운 볼륨으로 볼륨과 IOPS가 이어져 있지 않음.
- io1 / io2 (Provisioned IOPS SSD ; PIOPS SSD)
- 가장 좋은 퍼포먼스의 SSD 볼륨.
- 4GB to 16TB.
- 낮은 지연, 대용량의 일에 알맞음.
- IOPS 퍼포먼스가 어느 정도 있어야 하는 중요한 비즈니스 애플리케이션에 알맞음.
- 16000IOPS 이상의 퍼포먼스를 바라는 애플리케이션(DB 등)에 알맞음.
- 맥시멈 32000IOPS까지 올릴 수 있으며, 니트로라면 64000IOPS까지 올릴 수 있음.
- gp3처럼 볼륨과 IOPS가 이어져 있지 않음.
- io1 < io2: 코스트가 똑같아도 더 튼튼하고 IOPS 높음.
- io2 블록 익스프레스: 4GB to 64TB. 밀리세컨드 단위의 지연을 뽐내는 하이 퍼포먼스 볼륨. 256000IOPS까지 올릴 수 있음.
- st1
- 싼 HDD 볼륨.
- 액세스가 자주 일어나면서 높은 처리량이 필요한 일에 알맞음.
- 빅 데이터, 데이터 웨어하우스, 로그 등에 쓰임.
- sc1
- 가장 싼 HDD 볼륨.
- 콜드 볼륨이라고 부르기도 함.
- 액세스가 가끔 일어나는 일에 알맞음.
EBS의 부팅 볼륨은 SDD 볼륨들만 될 수 있습니다.
디폴트로 EBS는 하나의 EC2 인스턴스에만 이을 수 있습니다.
io1, io2는 빼고요. 얘네는 하나의 EBS 볼륨에 여러 EC2 인스턴스를 이을 수 있습니다, 같은 AZ에 있으면요.
EBS Encryption
인스턴스와 볼륨 사이 주고 받는 모든 데이터가 암호화되고,
모든 스냅숏이 암호화되고,
스냅숏으로 만든 모든 볼륨도 암호화됩니다.
암호화가 지연시간에 미치는 이펙트는 거의 없습니다.
암호화를 위해 KMS 키를 씁니다.
아래는 EBS 볼륨을 암호화하는 방법입니다.
- 먼저 볼륨의 EBS 스냅숏을 만듭니다.
- copy 함수로 EBS 스냅숏을 암호화합니다.
- 스냅숏으로 만들어진 볼륨들은 암호화됩니다.
- 이제 암호화된 볼륨을 오리지널 인스턴스와 이을 수 있습니다.
EFS (Elastic File System)
여러 AZ에 걸쳐 여러 EC2 인스턴스에 마운트 할 수 있는 managed NFS(네트워크 파일 시스템)입니다.
여러 AZ에 걸쳐 쓸 수 있다는 게 EBS와의 가장 큰 차이점입니다.
가용성과 확장성이 뛰어나고, 그만큼 비싸기도 합니다.
(쓰는 만큼 capacity가 늘거나 줄어듭니다, PB 단위까지 늘어납니다.)
쓴 만큼만 내면 되기는 하니까 잘 쓰기만 한다면 좋을 겁니다.
EFS는 시큐리티 그룹에 묶여 있고, 여러 EC2가 시큐리티 그룹을 통해 EFS와 커넥션을 만듭니다.
한 번에 하나의 EC2 인스턴스와만 커넥션을 만들 수 있습니다.
유즈 케이스: 콘텐츠 관리, 웹 서비스, 데이터 공유 등이 있습니다.
EFS는 윈도즈가 아닌 리눅스 based AMI에서만 쓸 수 있습니다.
최대 1000명의 동시 클라이언트를 다룰 수 있고 초당 10GB 이상의 처리량을 자랑합니다.
그리고 2가지 모드가 있습니다. EFS를 만들 때 퍼포먼스 모드와 처리량 모드를 정해 주어야 합니다.
모드마다 2가지 옵션이 있습니다.
먼저 퍼포먼스 모드에서는,
1. 범용 모드는 디폴트 모드로, 범용성이 좋습니다. 지연시간에 민감한 경우 알맞습니다.
2. Max I/O 모드는 지연시간은 좀 더 길지만 처리량이 높고 병렬성도 높습니다. 빅 데이터나 미디어 작업에 알맞습니다.
두 번째 모드는 처리량 모드입니다.
1. 디폴트는 bursting 처리량 모드로, 1TB의 storage에 대해 초당 50MB를 저장할 수 있고 초당 100MB까지 확장이 가능합니다.
2. Provisioned 처리량 모드는 storage의 크기에 상관없이 처리량을 정하고 싶을 때 쓰면 됩니다. 예를 들어 1TB의 storage에 대해 초당 1GB의 처리량을 요청할 수 있습니다.
스토리지 레벨
마지막으로 테스트에 나올 수 있는 또 다른 토픽입니다.
파일에 대한 수명 주기 매니지먼트 기능으로, 디폴트 값이면 30일이 지나면 새로운 레벨로 파일을 옮깁니다.
1. 자주 액세스하는 파일은 스탠더드 계층에 남아 있습니다.
2. 로 코스트의 액세스 빈도가 낮은 파일은 EFS-IA(Infrequent Access) 계층으로 옮겨집니다. 디폴트 값이면 30일 이후입니다. 여기에 있는 파일들은 가져올 때마다 코스트가 생깁니다.
