EBS 볼륨은 Elastic Block Store의 약자로 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브를 말한다.
EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터를 지속할 수 있다. 이것이 바로 EBS 볼륨을 사용하는 목적이다. 인스턴스 A를 사용하다가 종료 후 인스턴스 B를 다시 만든 뒤에 이전 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있는 것이다.
CCP 레벨에서의 EBS 볼륨은 한번에 하나의 인스턴스에만 마운트할 수 있다. 또한 EBS 볼륨을 생성할 때는 특정 가용 영역에서만 가능하다. 예를 들어 EBS 볼륨이 us-east-1a 에서 생성된 경우 us-east-1b 에는 연결이 불가능하다.
EBS 볼륨이란 물리적 연결이 없는 USB라고 생각하면 된다. USB처럼 한번에 하나의 컴퓨터에만 연결할 수 있지만 물리적인 연결이 아닌 네트워크를 통해 연결되는 방식인 것이다.
프리 티어에선 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공한다.
EBS 볼륨은 네트워크 드라이브고 물리적 드라이브가 아니다.
즉, 인스턴스와 EBS 볼륨이 서로 통신하기 위해선 네트워크를 필요로 한다. 그리고 네트워크가 사용되기 때문에 컴퓨터가 다른 서버에 도달할 때 지연이 생길 수 있다. EBS 볼륨은 네트워크 드라이브이므로 EC2 인스턴스에서 분리될 수 있고, 매우 빠르게 다른 인스턴스로 연결될 수 있다. 이 때문에 대체 작동 등의 경우에 굉장히 유용하다.
EBS 볼륨은 특정한 가용 영역에 고정되어 있으므로 다른 가용 영역으로 연결은 불가능하지만 스냅샷을 이용하면 다른 가용 영역으로도 볼륨을 옮길 수 있다. 또한 볼륨이기 때문에 미리 용량을 결정해야 한다. 따라서 원하는 양의 GB 및 IOPS(단위 초당 전송 수)를 미리 지정해야 한다.
기본적으로 사용자가 원하는 EBS 볼륨의 성능을 미리 정의하는 식이다. 그러면 해당 프로비전 용량에 따라 요금이 청구되고 더 좋은 성능이나 큰 사이즈가 필요하면 이후에 용량을 늘릴 수도 있다. EBS 볼륨을 생성한 후 연결하지 않고 그대로 둘 수도 있다.
마지막으로 EC2 인스턴스를 통해 EBS 볼륨을 생성하는 경우 종료 시 삭제 속성이 있다. 기본 설정으로는 루트 볼륨에 체크되어 있고 새로운 EBS 볼륨에는 체크가 되어 있지 않다. 이 옵션을 통해 EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있다. 또한 종료 시 삭제 기능의 활성화 여부는 원하는 대로 조작이 가능하다.
인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우 또는 데이터를 저장하고자 하는 경우에는 루트 볼륨의 종료 시 삭제 속성을 비활성화하면 된다.
EBS 볼륨을 가지고 스냅샷을 생성할 수 있는데 이때 스냅샷은 사용자가 원하는 시점에 대한 백업이라고 할 수 있다. 원하는 시점의 상태를 백업으로 남겨 놓는다는 개념인 것이다. 스냅샷을 남겨놓으면 해당 EBS 볼륨이 추후 삭제된다고 해도 남겨놓은 스냅샷을 통해 복구할 수 있다.
백업 생성을 위해 백업 전 볼륨을 분리시킬 필요는 없으나 분리를 권장
스냅샷이 필요한 이유는 복구에 사용하는 것 말고도 여러 가용 영역과 리전 간 복제에도 쓸 수 있기 때문이다. 글로벌 인프라 활용을 위해 데이터 일부를 AWS 내의 다른 리전으로 전송할 수 있는 것이다.
us-east-1a가용 영역에 있는 EBS 볼륨을us-east-1b로 전송하고자 할 때 EC2 인스턴스에 연결된 EBS 볼륨을 가지고 스냅샷을 만들어 전송에 사용한다. 이제 이 스냅샷은 사용자의 리전 내에 있으니 해당 EBS 스냅샷을 다른 가용 영역 내의 새 EBS 볼륨 복구 시 사용할 수 있다. 해당 복구 작업이 끝나면 새 EBS 볼륨을us-east-1b의 EC2 인스턴스에 연결하면 된다.
EBS 스냅샷 아카이브 특성을 이용하면 사용자의 스냅샷을 또 다른 스토리지 티어인 “아카이브 티어”로 옮길 수 있다. 비용이 75%나 저렴한 티어이다.
수동, 혹은 사용자가 설정한 방법에 따라서 아카이브 티어로 스냅샷을 옮길 수 있지만, 이 아카이브를 이용하면 아카이브로부터 스냅샷을 복구하는데 24 ~ 72시간의 시간이 소요되므로 여기 저장하는 스냅샷은 급하게 복구하지 않아도 되는 스냅샷이어야 한다.
비용을 낮추는 목적으로 사용할 수 있다.
기본적으로 스냅샷을 삭제하면 다시 복구할 수가 없지만 EBS 스냅샷 휴지통을 설정해 두면 삭제한 모든 스냅샷이 휴지통에 보관된다. 그리고 하루부터 일 년 사이의 기간 중 설정한 기간에 따라 스냅샷이 휴지통에서 삭제된다.
실수로 스냅샷을 삭제했을 때를 대비하는 목적으로 사용할 수 있다.
AMI란 Amazon Machine Image의 약자로 사용자 지정 EC2 인스턴스를 나타낸다. 따라서 AWS에서 생성한 AMI를 사용하거나 사용자 지정 AMI를 만들 수도 있다.
각자의 소프트웨어 구성에 대해 운영 체제를 정의 및 설정하며 모니터링 도구를 설정할 수도 있는데 이때 자체적으로 AMI를 생성하면 부팅과 구성에 시간이 단축된다. 이는 사용자의 EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징되기 때문이다. 따라서 AMI를 자체적으로 구성하고 특정 리전에 맞도록 구축함으로써 이들을 원하는 리전에 복사해 놓거나 AWS 글로벌 인프라를 활용할 수 있는 것이다.
위에서 언급했듯이 사용자가 직접 AMI를 생성할 수도 있다. 사용자가 따로 AMI를 생성하고 유지할 수 있도록 자동화하는 도구가 있지만 이는 클라우드 사용자가 직접 해야 하는 작업이다. AWS는 기능만 제공할 뿐 해당 기능을 알아보고 사용하는 주체는 사용자이다.
끝으로 AWS 마켓 플레이스 AMI에서도 EC2 인스턴스의 실행이 가능하다. 이는 다른 사용자가 만들어서 판매하는 AMI로 자주 찾아볼 수 있다. AWS의 공급 업체가 자체적으로 AMI나 구성이 좋은 소프트웨어를 생성하고, 사용자는 시간 절약을 위해 마켓 플레이스에서 AMI를 구매하는 것이다. (물론 사용자도 마켓 플레이스에서 AMI를 판매할 수 있다)
EC2 인스턴스 사본 만들기
us-east-1a영역에 인스턴스가 있고,us-east-1b영역에 동일한 인스턴스를 만들려고 한다.먼저
us-east-1a영역에서 사용 중인 인스턴스의 AMI를 생성한다. 이후us-east-1b에서 인스턴스 생성 시 앞에서 만들어 둔 AMI를 선택 후 인스턴스를 만들면 된다.
- 이때
us-east-1a인스턴스 생성 시 적용한 사용자 데이터가 있다면 인스턴스를 복사하기 위해 사용자 데이터를 다시 입력하지 않아도 된다.
EC2 이미지 빌더는 가상 머신이나 컨테이너 이미지 생성을 자동화할 때 사용된다. EC2 이미지 빌더를 사용하여 EC2 인스턴스에 대한 AMI의 생성, 유지, 검증 및 테스트를 자동화할 수 있다. EC2 이미지 빌더는 지역 서비스지만 AMI를 여러 지역에 배포할 수 있으므로 사용자의 애플리케이션과 워크플로우가 글로벌화될 수 있다.
또한 EC2 이미지 빌더는 일정에 따라 실행될 수 있다. 주간 일정 또는 패키지 업데이트 시 실행하거나 수동으로도 실행할 수 있다. 그리고 무료 서비스이므로 기본 리소스에 대해서만 비용을 지불하면 된다. 이것은 이 프로세스 중에 사용자가 EC2 인스턴스를 생성하면, 이 인스턴스에 대한 비용을 지불한다는 것이다. 그리고 AMI가 생성되고 배포되면 그 위치에 관계 없이 해당 AMI의 저장 비용을 지불하게 된다.
EC2 이미지 빌더 예시
EC2 이미지 빌더 서비스가 실행될 때 빌더 EC2 인스턴스를 생성한다. 그리고 그 인스턴스는 구성 요소를 구축하고 소프트웨어를 사용자 정의하게 된다. 예를 들어 자바 설치, CLI 업데이트, 소프트웨어 시스템 업데이트, 방화벽 설치 등 해당 인스턴스에서 어떤 작업이든 수행하고, 작업이 완료되면 EC2 인스턴스에서 AMI가 생성된다.생성 후 검증을 위해 EC2 이미지 빌더는 해당 AMI에서 테스트 EC2 인스턴스를 자동으로 생성한다. 그리고 사용자가 미리 정의한 여러 테스트를 실행하는데 만약 원하지 않는다면 건너뛸 수 있다. 이렇게 AMI를 테스트 한 이후 배포되는 것이다.
EC2 인스턴스는 가상 머신이지만 실제로는 하드웨어 서버에 연결되어 있다. 이와 같은 서버에는 해당 서버에 물리적으로 연결된 디스크 공간을 갖는다. 따라서 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불리며 이는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가리킨다.
이 EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용할 수 있다. 이들이 훌륭한 처리량을 갖추고 있어서 매우 향상된 디스크 성능을 필요로 할 때 활용할 수 있도록 확보할 필요가 있다.
이때 주의할 점은 EC2 인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실된다는 것이다. 이와 같은 이유로 이를 임시 스토리지라고 부르며 EC2 인스턴스 스토어가 장기적으로 데이터를 보관할 만한 장소가 될 수 없음을 보여 준다.
마지막으로 EC2 인스턴스의 기본 서버에 장애가 발생할 시에는 해당 인스턴스가 연결된 하드웨어에도 장애가 발생하므로 데이터 손실에 대한 위험이 존재한다. 따라서 EC2 인스턴스 스토어를 사용할 땐 필요에 따라 데이터를 백업해 두거나 복제해 둬야 한다.
인스턴스 스토어의 사용처
버퍼나 캐시, 스크래치 데이터 또는 임시 컨텐츠를 사용하려는 경우 이들을 보관할 좋은 장소가 되지만 장기적인 스토리지는 될 수 없다. (장기 스토리지의 경우 EBS가 적합)
인스턴스 스토어와 EBS 볼륨의 차이
크기가 i3인 인스턴스 스토어의 Read IOPS/Write IOPS는 성능이 가장 뛰어날 때 각각 330만/140만에 달한다. BP2 유형의 EBS 볼륨의 경우에는 3.2만 IOPS 정도이기 때문에 성능의 차이가 많이 난다.→ EC2 인스턴스에 성능이 아주 뛰어난 하드웨어가 연결된 것이 보이는 경우 로컬 EC2 인스턴스 스토어를 생각
EFS는 Elastic File System을 뜻하며 관리형 네트워크 파일 시스템이다. EFS의 개념이자 장점은 이 시스템을 한 번에 수백 개의 EC2 인스턴스에 마운트할 수 있다는 것이다. 이전에 본 EBS 볼륨은 한 번에 한 EC2 인스턴스에만 연결할 수 있었다면 EFS 드라이브는 한 번에 수백 개의 EC2 인스턴스에 마운트할 수 있다. 이로써 공유 네트워크 파일 시스템(공유 NFS)가 구축되는 것이다.
EFS는 Linux EC2 인스턴스에서만 사용할 수 있다. 그리고 여러 가용 영역에서 사용 가능하다. 즉, 하나의 가용 영역에 있는 인스턴스에 연결되었다고 해도 같은 EFS 볼륨을 다른 가용 영역의 인스턴스와 연결할 수 있는 것이다.
EFS는 가용성과 확장성이 높은 만큼 비싸다. gp2 EBS 볼륨에 비하면 3배 가량 비싸다. 하지만 사용량에 따라 지불하고 요금제가 없다. 즉, EFS 드라이브에 20GB의 데이터를 저장한다면 20GB에 해당하는 비용만 내면 된다.
EFS-IA는 EFS에서 알아 둬야 할 스토리지 클래스이다.
스토리지 클래스는 파일 액세스 빈도에 따라 비용 최적화 과정을 거친다. 자주 쓰지 않는 파일을 골라내는 것인데 EFS-IA 스토리지 클래스는 EFS 표준 스토리지 클래스보다 데이터를 저장함에 있어서 그 비용이 92% 더 저렴하다.
EFS-IA 스토리지 클래스를 활성화시키면 EFS가 자동으로 수명 주기 정책에 따라서 마지막으로 액세스한 시점을 기반으로 사용자의 파일을 이동시킨다.
애플리케이션의 관점에서 봐도 그 과정 자체가 보이는 것이 아니어서 단점이 없다. EFS 표준이든 EFS-IA든 파일에 앱이 액세스하는 방식은 똑같기 때문이다. 그리고 EFS의 비용 최적화는 자체적으로 이뤄지는 작업이다.
EFS-IA 예시
어떤 파일을 60일 동안 아무도 액세스 하지 않았고, 정의한 수명 주기 정책이 있고, EFS-IA 스토리지 클래스가 활성화 상태일 경우 해당 파일을 다른 스토리지 클래스(=EFS-IA)로 옮기도록 할 수 있다. 이 작업은 자동으로 이뤄지며 다음에 해당 파일에 액세스하면 다시 EFS 표준 스토리지 클래스로 이동할 것이다.
결론: 사용자의 책임은 애초에 백업을 하는 것
Amazon FSx는 AWS에서 타사의 고성능 파일 시스템을 얻는 관리형 서비스이다. 그래서 EFS나 S3가 아닌 다른 것을 사용하고자 할 때 FSx를 사용해서 파일 시스템을 관리할 수 있다.
제공하는 FSx의 종류
- Amazon FSx For Lustre
- Amazon FSx For Windows File Server
- Amazon FSx For NetApp ONTAP
Windows 인스턴스 전용의 완전 관리형이며 높은 안정성과 확장성을 가진 Windows 기본 파일 공유 시스템이다.
그래서 일반적으로 2개의 가용 영역에 걸쳐 FSx를 배포하면 이 파일 시스템을 Windows 장치에 마운트할 수 있도록 하는 SMB 프로토콜과 Windows NTFS와 같은 모든 Windows 기본 프로토콜을 지원한다.
기업 데이터 센터가 Windows를 사용할 때 SMB를 통해 Windows 파일 서버에 액세스할 수 있고, Windows 기반의 EC2 또한 이 Windows 파일 서버에 액세스할 수 있다. 따라서 Amazon FSx는 SMB 프로토콜과 Windows NTFS로 Windows 파일 서버를 배포하는 방식이다.
이 또한 Microsoft 유형의 제공 사항이며 사용자 보안을 위해 Microsoft Active Directory와 통합하기 때문이다. 그리고 Amazon FSx의 Windows 파일 서버는 온프레미스 인프라에서 직접 액세스할 수 있다.
Lustre용 FSx는 고성능 컴퓨팅을 위한 완전 관리형의 고성능이며 확장 가능한 파일 스토리지이다. 그래서 HPC용 스토리지라고 하면 Lustre용 FSx를 생각하면 된다.
이는 머신 러닝과 같은 고성능 컴퓨팅과 분석, 비디오 처리와 재무 모델링에 사용된다. 또, 초당 수백 GB의 데이터를 교환하고, 초당 수백만 건의 IOPS를 실행하며 지연 시간은 밀리초 미만을 가지는 고성능 파일 시스템이다.
Amazon FSx For Lustre의 원리는 기업의 데이터 센터 또는 AWS 내에 있는 컴퓨팅 인스턴스에 직접 연결하는 것이다. 그리고 백엔드에서 Amazon FSx For Lustre는 데이터를 Amazon S3 버킷에 저장한다.
Lustre는 Linux와 Cluster에서 파생되었다. 그래서 프로세싱과 같은 클러스터를 생각하면 Lustre용 FSx가 무엇인지 기억할 수 있을 것이다.
FSX에 대한 자세한 정보는 https://jibinary.tistory.com/281를 참고