EC2 Instance Storage

EBS Volume

EBS 볼륨이란?

: EBS(Elastic Block Store) 볼륨은 인스턴스가 실행중인 동안 연결 가능한 네트워크 드라이브임, 모르는 사이에도 계속 사용해왔었음

: EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터를 지속할 수 있다.

: 따라서 인스턴스를 재생성하고 다시 이전 EBS 볼륨을 마운트해서 데이터를 다시 받을 수 있다.

: 하나의 인스턴스마다 하나의 볼륨만 마운트 할 수 있다. (CCP레벨에 EBS 볼륨이 해당함. 여기서 CCP레벨은 1 볼륨은 1 인스턴스 만 가능, 어소시에이트레벨은 다중연결)

: EBS 볼륨 생성은 특정 가용영역에서만 사용 가능함. 따라서 us-east-1a에서 생성되면 us-east-1b에 있는 EC2에 연결이 불가능함 (스냅샷이라는 방법을 사용하면 방법은 있음)

-> 실습을 해보면 EBS 볼륨을 만드는 과정에서 가용영역을 설정할 수 있고 연결하려고 해보면 다른 가용영역의 EC2는 목록에 나오지도 않음

: 네트워크 USB 스틱이라고 생각하면 됨. 다만 이게 물리연결이 아니라 네트워크 연결. (도커랑 비슷한듯?)

 

EBS 볼륨 특징

: 범용 SSD 혹은 마그네틱 유형으로 제공됨

: 네트워크 연결이므로 지연이 발생할 수 있다.

: 또한 USB 스틱과 같으므로 EC2에서 연결/해제가 가능하고 다른 EC2에 연결 가능함

: 볼륨이기 때문에 용량을 미리 정해야 한다.

: 1인스턴스에는 여러개의 EBS 볼륨 연결 가능함. 반대로 EBS볼륨을 아무 인스턴스에도 연결하지 않은 상태도 가능함

 

EBS 볼륨의 종료시 삭제

: EC2 인스턴스를 통해 EBS 볼륨을 생성하는 경우 종료시 삭제라고 하는 속성이 있다.

: 기본적으로 root EBS 볼륨은 종료시 삭제 설정이 되어있고 다른 EBS볼륨은 체크 옵션이 해제되어 있다.

-> 인스턴스 생성시 디폴트 EBS를 설정할 수 있었고 그 과정에서 종료시 삭제 옵션도 설정할 수 있었음

 

이렇게 만든 볼륨을 실제로 사용하는 방법?

: format EBS volume attach EC2를 검색해서 알아보면 됨

 

EBS Snapshots

: 스냅샷을 생성할 수 있는데, 이때 우리가 원하는 시점에 대한 백업이라고 할 수 있다.

: EBS가 추후 삭제되더라도 해당 백업을 통해서 복구할 수 있음

: 백업시 EBS를 인스턴스에서 깔끔하게 분리하는 것을 권장함

: 복구에도 사용할 수 있으나, 여러 가용영역과 리전간에 복제에도 쓸 수 있다. 따라서 글로벌 인프라 활용성이 있음

: 예를 들어 1a라는 가용영역에 만들어진 EBS 볼륨의 스냅샷을 떠서 1b라는 가용영역에 restore 기능으로 볼륨을 새로 생성 후 1b에 있는 다른 인스턴스에 연결할 수 있다.

 

EBS sanpshot Archive

: 또 다른 스토리지 티어인 '아카이브 티어'로 옮길 수 있다. 비용이 75%나 저렴한 티어임

: 단 복구 시간이 24 ~72시간으로 급한 복구 볼륨은 적당하지 않음

: 스냅샷을 기존 표준 티어에 다른 데이터들과 저장해두는것보단 장기적으로 가격이 저렴한 아카이브로 저장해 놓는것이 좋음

 

EBS snapshot 휴지통

: 스냅샷 휴지통을 설정해 놓으면 바로 삭제되지 않고 휴지통에서 설정한 기간동안 보관된 후 영구삭제 됨

 

AMI

AMI 개요

: AMI (Amazon Machine lmage)

: 사용자 지정 EC2 인스턴스를 나타낸다.

: 각자의 소프트웨어 구성에 대해 운영체제를 정의 및 설정하며, 모니터링 도구를 설정할 수 있는데,  이떄 자체적으로 AMI를 설정하면 부팅과 구성에 시간이 단축됨

: 이는 EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징되기 때문임.

: 자체적으로 AMI를 구성할때 특정 리전에 맞도록 구축함으로써 이들을 원하는 리전에 복사해 넣거나 AWS 글로벌 인프라를 활용할 수 있는 것임

: 따라서 여러종류의 AMI에 EC2 인스턴스를 실행할 수 있는데, 디폴트는 AWS가 제공하는 공용 AMI를 사용하였음

: AWS 마켓플레이스에서 다른 사람이 만든 AMI를 구매할 수도 있다.

 

 

EC2 인스턴스에서의 AMI 프로세스

1. 먼저 EC2 인스턴스를 생성하고 사용자 지정으로 바꾸어 준다.

2. 다음으로 인스턴스를 중지시키고 데이터 무결성을 확보한다.

3. 그리고 AMI를 구축하는데 이때 표시되지는 않지만 EBS 스냅샷 또한 생성된다.

4. 끝으로 다른 AMI에서 인스턴스를 실행할 수 있게 된다.

 

다른 인스턴스로 동일하게 AMI를 적용하는 방법

: 1A 가용영역에 있는 인스턴스에서 사용자 AMI를 생성하고, 1B 가용영역에 있는 인스턴스에서 그 AMI를 실행시키면 인스턴스 사본을 만들 수 있음 (도커 이미지와 비슷한건가?)

-> 실제로 실습해보면 AMI를 생성해서 환경설정정보를 복사하고 그것을 새 인스턴스에서 적용할 떄, 사용자 데이터(인스턴스생성시 도커파일과 같이 환경설정 코드 문서)를 굳이 넣지 않아도 알아서 환경설정이 된다. 따라서 인스턴스 생성속도(부팅)이 빨리 되는 효과를 얻음

 

EC2 Image Builder

EC2 Image Builder란?

: 가상 머신이나 컨테이너 이미지 생성을 자동화하는데 사용함

: EC2 이미지 빌더를 사용하여 EC2 인스턴스에 대한 AMI의 생성, 유지, 검증 및 테스트를 자동화 할 수 있다

: EC2 이미지 빌더 서비스라는 것이 있고, 그것이 실행될때 빌더 EC2 인스턴스를 생성함, 그리고 그 EC2 인스턴스는 구성 요소를 구축하고 소프트웨어를 사용자 정의하게 된다. 예를들어 자바 설치, CLI 업데이트, 소프트웨어 시스템 업데잍, 방화벽 설치나 어플리케이션 설치든 해당 EC2 인스턴스에서 어떤 작업이든 수행하고 작업이 완료되면 EC2 인스턴스에서 AMI가 생성된다.

: 이 모든것이 자동화 되어 있다.

: AMI가 생성되어도 이를 검증해야 하므로 EC2 이미지 빌더는 해당 AMI에서 테스트 EC2 인스턴스를 자동으로 생성한다. 

: 그리고 사용자가 미리 정의한 여러 테스트를 실행할 것임, 테스트를 안하도록 설정할 수도 있다.

: EC2 이미지 빌더는 지역서비스 이지만, AMI를 여러 지역에 배포할 수 있으므로 애플리케이션과 워크플로우가 글로벌화 될 수 있다.

: EC2 이미지 빌더는 일정에 따라 실행될 수 있으므로 주간 일정을 정의할 수 있으며, 패키지가 업데이트 될때마다 실행하거나 수동으로 실행할 수 있는 실행 트리거도 설정할 수 있다.

: 무료 서비스이므로 기본 리소스(생성된 인스턴스비용, AMI 저장 비용) 대해서만 비용을 지불하면 된다. 

 

EFS

EFS(Elastic File System)란?

: EBS 같이 인스턴스에 연결할 수 있는 스토리지 종류중에 하나임

: EFS는 엘라스틱 파일 시스템을 뜻하고 관리형 네트워크 파일 시스템이었음

: EBS 볼륨은 한번에 1개 EC2 인스턴스에만 연결할 수 있었다면, EFS는 한번에 수백개의 EC2 인스턴스에 마운트 할 수 있음

: 이로써 공유 네트워크 파일 시스템, 즉 공유 NFS(Network File System)가 구축된다.

: EFS는 Linux EC2 인스턴스에서만 사용할 수 있다.

: 여러 가용영역에서도 사용할 수 있는데, a 가용영역에서 쓰이고 있는 EFS를 다른 가용영역의 인스턴스와 연결할 수 도 있음

: EFS는 가용성과 확장성이 상당한만큼 그 비용도 상당하다. gp2 EBS 볼륨에 비하면 3배가량 비쌈

: 단 사용량에 따라 지불하고 요금제는 없음. 즉 EFS 드라이브에서 20GB의 데이터를 저장한다고 하면, 해당 20GB에 대한 비용만 내면 된다.

 

EBS vs EFS

: EBS는 1스토리지당 1인스턴스만 연결이 가능하고, 다른 가용영역으로 옮기려면 스냅샷을 생성하고 복구하는 방식으로 옮겨야함. 따라서 동기화되는 복사본도 아님. 반면 EFS는 스냅샷을 사용할 필요도 없고, 완전 동기화임

 

 

EFS Infrequent Access (EFS-IA)

: EFS에서 빈도가 낮은 엑세스

: 스토리지 클래스는 파일 엑세스 빈도에 따라 비용 최적과 과정을 거치고 자주 사용하지 않는 파일을 걸러낸다.

: EFS-IA 스토리지 클래스는 EFS 표준 스토리지 클래스보다 데이터를 저장함에 있어 92% 더 저렴하다.

: EFS-IA 스토리지 클래스를 활성화 시키면, EFS가 자동으로 수명 주기 정책에 따라서 마지막으로 액세스한 시점을 기반으로 우리의 파일을 이동시킨다. 가령 EFS 파일 시스템에서 EFS 표준 스토리지 클래스에 총 4개의 파일이 있고, 마지막 파일은 60일 동안 액세스가 되지 않았다면, 이때 정의한 수명 주기 정책이 있고, EFS-IA 스토리지 클래스가 활성화 상태이면, 60일이 지난 파일의 경우 해당 파일을 다른 스토지 클래스로 옮기도록 할 수 있고 이때 그 클래스가 EFS-IA가 된다. 이렇게 하면 비용을 절감할 수 있다.

: 다음에 해당 파일에 액세스하면, 다시 EFS 표준 스토리지 클래스로 이동할 것이다.

: 애플리케이션 관점에서도 딱히 단점이 없다. 따라서 EFS의 비용 최적화는 자체적으로 이루어지는 작업임

 

공동책임

: AWS는 인프라에 책임이 있고 복제 수행등이나 하드웨어 장애등 모두 AWS 책임이다.

: 백업 설정이나 스냅샷 절치 가이드라인 설정, 데이터 보안등은 사용자 책임

 

EC2 Instance Store

EC2 Instance Store란?

: 지금까지 알아본 네트워크 드라이브 방법들은 성능 자체는 좋지만 어느정도 한계가 있음

: 이때 인스턴스에 연결된 하드웨어 디스크 성능이 향상되어야 한다

: EC2 인스턴스는 가상 머신이지만, 실제로는 하드웨어서버에 연결되어 있다. 이런 서버는 해당 서버와 물리적으로 연결된 디스크 공간을 갖는데, 따라서 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불리며 이는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가리킨다.

: 이 EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용 할 수 있고 매우 큰 처리능력과 향상된 디스크 성능을 요할때 활용할 수 있다.

: EC2 인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실되므로 주의해야하고 이런 점때문에 임시 스토리지로 활용해야 한다.  따라서 버퍼나 캐시, 스크래치데이터에 쓰임

 

FSx

FSx란?

: AWS에서 타사의 고성능 시스템을 얻는 관리형 서비스이다.

: 그래서 EFS나 S3가 아닌 다른 것을 사용하려면 FSx를 사용해서 파일 시스템을 관리 할 수 있다.

: 대표적으로 Windows용과 Lustre용이 있는데, 각각 운영체제에 최적화된 프로토콜을 가지고 있어 클라이언트는 알맞는것을 선택하면 된다.

: 특히 Lustre용은 S3 버켓에 데이터를 저장하고 그것을 사용하고 있다.