[AWS] EC2 Instance Storage

feedback

1. Shared Responsibility Model for IAM

AWS 보안에 대한 책임은 사용자와 AWS 모두에게 부여된다. AWS는 모든 인프라에 대해 책임이 있고, 사용자는 인프라 사용에 관한 책임이 존재한다. '인프라에 대한 책임'이란, 제공하는 모든것에 책임이 있다는 의미이다. 그리고 '인프라 사용에 대한 책임'이란, 구성원들에 대한 규칙이나 규약같은것은 사용자가 관리해야한다는 의미이다. 비밀번호를 자주 교체하도록 요구하는것도 사용자의 책임이며, IAM을 적절하게 사용하는것도 사용자의 책임이다. 

---

2. EC2의 약정은 1년 또는 3년

EC2는 On-Demand로 사용하는 만큼 금액을 지불할수도 있지만, 약정을 걸어 요금 할인을 받는 방법도 존재한다. 약정은 1년 또는 3년 단위로 걸 수 있으며, 오랜 기간 사용을 약속한 경우 더 많은 할인을 제공받을 수 있다.

---

3. EC2 Instance Type

EC2 Instance는 사용 목적에 따라 다양하게 존재한다. m5.2xlarge같은 이름이 인스턴스에 부여될 수 있는데, m은 instance class, 5는 generation(instance가 개선된다면 6가 되는것), 그리고 2xlarge는 instance의 크기를 의미한다. 목적에 따라 크게 네 종류로 구분해볼수 있다.

 

먼저 웹서버나 code repositories같은곳에 사용될 수 있고, 컴퓨팅, 메모리, 그리고 네트워킹의 균형이 좋은 1) General Purpose instance 있다. t2.micro가 범용 인스턴스의 한 예이다. 그리고 집약적인 작업에 최적화된 2) Compute Optimized instance가 있다. 이를 이용하면 Batch processing workloads나, 고성능 컴퓨팅, 그리고 머신러닝 따위를 사용할 수 있다. 그리고 대규모 데이터셋을 처리할때 필요한 3) Memory Optimized instance가 있다. 큰 비구조화 데이터를 실시간으로 처리하는 어플리케이션에 사용되기도하며, 구조화/비구조화 DB에서 높은 성능을 보여준다. 마지막으로 4) Storage Optimized instance가 있다. 이는 OLTP에 사용되기도 한다.

 

---

1) EBS

Whats' an EBS Volume?

EBS(Elastic Block Store) Volume은 instance가 실행중인 동안 연결 가능한 네트워크 드라이브이다. 다시말해, instance가 종료된 후에도 데이터가 지속가능하게 해준다. 쉽게 한번더 말하자면, Network ver. USB라고 생각하면 된다. 주의할점은, 일반적으로 EBS가 한번에 하나의 instace에 연결될 수 있다는 것이다. 하나의 instance에 여러 EBS를 부착하는것은 가능하지만, 하나의 EBS를 여러 instance에 부착하는것은 일반적으로 불가능하다(Multi-Attach가 있지만 예외로 취급). 다음으로는, 특정 availability zone에 제한되서 사용된다는 점이다. 즉, EBS를 사용하려면 instance와 같은 AZ에 존재해야한다. 예를들어, us-east-1a에 있는 EBS Volume은 us-east-1b에서 사용할 수 없다. 만약 사용하고싶다면, snapshot이 필요하다.

 

꼭 필요한 경우만 연결하는 EBS도 존재

 

 

EBS Snapshots

Snapshots은 특정 시점의 EBS volume의 backup을 생성하는 것이다. Snapshot을 이용할때는, EBS를 detach상태로 유지하는것이 권장된다. Snapshot은 restore할때 다른 가용 영역(AZ)에서 복구하는것도 가능하기 때문에, 가용영역이 달라서 attach되지 못하는 부분을 해결 가능하다.

 

Snapshots은 두 가지 이동경로가 존재할 수 있다. 첫번째로는 1)EBS Snapshot Archive이고, 두번째는 2) Recycle Bin for EBS Snapshots 이다. Archive로 이동하는 목적은 비용이 75%가량 저렴해지기 때문이다. 그러나, restore하는데 24시간에서 72시간가량 소요되기때문에, 급히 복구할만큼 중요도가 높지 않은 snapshot이 저장된다. 그리고 snapshot을 삭제하면 Recycle Bin으로 이동한다. 그러나 이동된다고 바로 삭제되는 것은 아니다. Bin에서도 저장 기간을 설정할수 있고, 저장 기간 내에 복구한다면 삭제한 snapshot을 다시 이용할 수 있다.

 

 

 

AMI

AMI는 Amazon Machine Image의 약어이다. 쉽게말해, 사용자 지정 EC2 instace라고 생각하면 된다. 이를 이용하면 사전에 software, configuration, operating system, monitoring 등을 모두 설정 가능하다. 설치하고자 하는 모든 software가 AMI를 통해 사전에 패키징 되기 때문에 부팅이 빨라진다는 장점을 가진다. AMI는 특정한 region에서 생성된다 (EBS는 특정 가용영역에서 제한). 그러나 EBS와 유사하게 region간 복사가 가능하다.

 

AMI는 크게 3가지 종류가 있는데, AWS에서 제공하는 Public AMI, 자신이 생성한 AMI, 그리고 Marketplace에서 판매되는 AMI이다. 자신이 유용한 AMI를 생성한다면, Marketplace에서 판매하는것도 가능하다.

 

 

AMI Process (from an EC2 instance)

먼저, EC2 instance를 생성하고 costomize 한뒤에, 무결성(integrity) 확보를 위해서 instance를 종료한다. 그리고 나서 AMI를 생성하고(이때 드러나진 않지만 EBS snapshot 또한 생성), 이를 이용해서 instance의 사본을 생성하는것이 가능해진다.

 

 

 

EC2 Image Builder

AMI 생성, 유지, 검증까지의 과정을 자동화 해주는 것이 EC2 Image Buidler이다. 먼저, Image Builder에서 instance를 생성하고 사용자가 지정한 Components들을 설치한다. 그리고 새로운 AMI를 만들고, AMI에서 생성된 EC2 instance가 잘 실행되는지, 안전한지 검증하는 과정을 거친다. 그리고 검증이 끝나면 설정한 region으로 배포되는 과정을 진행한다. 이 과정은 주기적으로 실행하는것도 가능하다(예를들어 주마다, 또는 업데이트 될때마다).

 

 

 

2) EC2 Instance Store

EBS voloums는 좋은 network drives이지만, 제한된 성능을 보인다. 그래서 성능적 향상을 원한다면 EC2 Instance Store을 사용하는것이 방법이다. EC2 Instance Store는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가리킨다. 높은 성능을 낸다는 것이 장점이지만, 장기적으로 데이터를 보관하기에는 부적합하다. Store가 중지되거나 fail한다면 데이터 손실의 위험이 존재하기 때문이다. 때문에 필요에 따라 백업이나 복제가 필요하며, 장기적인 데이터보관을 원한다면 EBS를 사용하는 것이 옳다.

 

---

3) EFS - Elastic File System

EC2 instance에 연결 될 수 있는 세번째 Storage로, 한번에 수백개의 EC2 instance에 마운트가 가능하다는 특장점이 있다 (EBS Volume은 한번에 한개). 또한 instance가 다른 AZ에 있어도 동시에 연결이 가능하다. 이렇게 좀더 접근성이 뛰어나지만 EBS에 비해 상대적으로 비싸다. Capacity planning은 존재하지않고, 사용한만큼 비용을 지불하는 형태이다.

 

EBS vs. EFS

EBS는 특정 가용역역에 한정해서 적용되는 Storage인 반면, EFS는 AZ에 상관없이 동시에 마운트 가능하다. EBS같은 경우도 스냅샷을 이용하면 다른 AZ에서 EBS를 이용하는것이 가능하지만 이는 사본에 불과하다. 즉, 동기화된 형태가 아니다. 그러나 EFS를 이용하면 다른 AZ에 있는 instance와 모든 내용을 공유하는것이 가능해진다.

 

 

EFS Infrequenet Access (EFS-IA)

EFS는 자주 이용하지 않는 파일에 대해서 비용을 자동으로 절감할수 있도록 도와준다. EFS는 자동으로 잘 사용하지 않는 파일을 EFS IA이란 곳으로 옮겨주는데, 이 장소는 EFS Standard에 비해 비용을 최대 92%나 절감할수 있는 곳이다. 파일이 Standard에 있던, IA에 있던 사용자가 파일에 접근하는 방식은 동일하다. 파일을 오랫동안 사용하지 않아 EFS-IA에 파일이 보관되었다가도, 파일에 다시 접근하면 EFS Standard로 되돌아가는 형태이다.

 

 

 

Shared Responsibility Model for EC2 Storage

Storage의 복제가 잘 되도록하며, 장애를 해결하고 교체하는것은 AWS의 책임이다. 또한, 직원이 함부로 고객의 data에 접근하게 하는것도 AWS의 의무이다. 반면, 고객은 Storage의 특성을 잘 알고 사용할 필요가 있다. 예를들어, EC2 Instance Storage같은 경우는 데이터 손실의 위험이 존재하는데, 이의 특성을 인지하고 데이터를 미리 백업해둬야 한다. 이는 사용자의 책임이다.장기적인 데이터 보관을 이용한다면 EBS Volume을 사용하는 것이 옳다. 다시말해, 목적에 맞게 적합한 Storage를 사용하는것은 사용자의 책임이다.

 

---

Amazon FSx

FSx는 타사의 고성능 파일 시스템을 이용하고싶을때 사용된다. AWS의 EFS나 S3가 아닌 다른 Storage를 사용하려면 FSx를 이용해 파일시스템 관리가 가능하다. FSx는 Fully managed service 이다. 

 

FSx에서는 1) FSx for Windows File Server와 2) FSx for Lustre를 기억하는것이 중요하다.

1) FSx for Windows File Server

그림에서처럼 2개의 AZ에 걸쳐 FSx를 배포하면, 이 파일 시스템을 윈도우 장치에 마운트하는것이 가능해진다. SMB protocol을 이용해 Window 파일 서버에 엑세스하는 것도 가능하며, 윈도우 기반의 EC2 instance에도 엑세스 가능하다 (Can be accessed from AWS or your on-premise infrastructure).

 

 

2) FSx for Lustre

FSx for Lustre는 고성능 컴퓨팅을 위한 확장가능한 완전 관리형 Storage이다. HPC를 위한 Storage라고 한다면 FSx for Lustre를 떠올려도 좋다. 이 저장소는 머신러닝, 분석, 비디오 처리, 그리고 금융 모델링 등에서 쓰이며 초당 수백만건의 IO작업을 수행하고 지연시간을 밀리초 미만이다. Computing instance에 직접 연결해서 사용되는 형태이며, 데이터를 S3 버킷에 저장한다.