1. EBS(Elastic Block Store) 볼륨이란?
인스턴스가 실행 중일 때 연결할 수 있는 네트워크 드라이브(물리적 드라이브가 아님)로, 네트워크 USB 스틱이라고 이해하면 쉽다.
USB 스틱처럼 한 컴퓨터에서 꺼내 다른 컴퓨터에 꽂는 장치이지만, 물리적 연결이 아닌 네트워크를 통해 연결된다.
-> 인스턴스와 EBS 볼륨이 서로 통신하기 위해서 네트워크가 필요하다.
-> 네트워크를 사용하기 때문에 컴퓨터가 다른 서버에 도달할 때 지연시간이 생길 수 있다
EBS 볼륨은 네트워크 드라이브이기 때문에 EC2 인스턴스에서 분리될 수 있고, 다른 인스턴스로 매우 빠르게 연결할 수도 있다.
EBS 볼륨을 사용하면 인스턴스가 종료되어도 데이터를 지속할 수 있다.
-> 인스턴스를 재생성하고, 이전 EBS 볼륨을 마운트하면, 데이터를 다시 받을 수 있음
(CCP 레벨에서 EBS 볼륨은 하나의 인스턴스에만 마운트할 수 있음)
EBS 볼륨은 특정 AZ(가용 영역)에서만 생성 및 연결할 수 있다.
-> 스냅샷을 이용하면 다른 AZ로 볼륨을 옮길 수 있음
+) 주의해야 할 EBS 볼륨의 속성
EC2 인스턴스를 통해 EBS 볼륨을 생성할 때 '종료 시 삭제'라는 속성을 유의해야 한다.
EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있는 옵션이 있어,
인스턴스가 종료될 때 루트 볼륨을 유지하고 싶을 때 & 데이터를 저장하고 싶을 때 '루트 볼륨 종료 시 삭제 속성을 비활성화'해야 한다.
2. EBS Snapshots
EBS 볼륨의 원하는 시점의 상태를 백업으로 남겨놓고 싶을 때 '스냅샷을 생성'하면 된다.
스냅샷을 이용하면 EBS 볼륨이 삭제되더라도, 백업을 통해 복구할 수 있다.
백업을 통한 복구 이외에도 '가용 영역 & 리전 간 복제'에도 스냅샷을 활용할 수 있다.
스냅샷으로 데이터를 AWS내의 다른 리전으로 전송하여, 글로벌 인프라 활용이 가능한 것!
3. AMI(Amazon Machine Image)
AMI = 사용자 지정 EC2 인스턴스
AWS에서 생성한 AMI를 사용하거나, 자체적으로 사용자 지정 AMI를 만들 수 있다.
사용자들이 소프트웨어 구성, 운영 체제, 모니터링 도구 등등을 추가로 정의하거나 설정할 수 있는데
이 때 AMI를 사용하면 EC2 인스턴스에 설치하려는 모든 소프트웨어를 사전에 패키징할 수 있고, 덕분에 부팅과 구성하는 시간이 단축된다.
AMI는 특정 리전에 맞게 구축되는데, 이를 다른 리전으로 복사할 수도 있어, AWS 글로벌 인프라를 활용하기에 용이하다.
AMI는 사용자가 직접 생성하고 유지할 수 있도록 자동화해주는 도구가 있지만, 이는 클라우드 사용자가 직접 작업해야 한다.
-> AWS가 제공하는 공용 AMI / 마켓플레이스에서 구매할 수 있는 AMI로 EC2 인스턴스를 실행하는 경우가 많다.
+) AMI 처리 방법(from an EC2 Instance)
1. EC2 인스턴스를 시작하고, 이를 사용자 지정으로 바꿔줌
2. 데이터 무결성을 위해 인스턴스를 중지시킴
3. AMI 구축 (이때 EBS 스냅샷도 생성됨)
4. 다른 AMI에서 인스턴스를 실행하여, EC2 인스턴스의 사본을 생성할 수 있음
4. EC2 Image Builder
EC2 이미지 빌더는 가상 머신 or 컨테이너 이미지 생성을 자동화하는데 사용된다.
-> EC2 인스턴스에 대한 AMI 생성, 유지, 검증, 테스트를 자동화할 수 있다.
-> 이미지 빌더는 일정에 따라(매주, 업데이트 될때마다 등등) 실행할 수 있다.
구체적인 작동 방법:
1. EC2 이미지 빌더 서비스가 실행될 때 빌더 EC2 인스턴스를 생성함
2. 생성된 인스턴스는 구성요소를 구축하고, 소프트웨어를 사용자 정의함
3. 해당 인스턴스에서 수행해야 할 작업이 완료되면, EC2 인스턴스에서 AMI가 생성됨(자동화되어 있는 과정임)
4. 생성된 AMI를 검증하기 위해, EC2 이미지 빌더가 자동으로 테스트 EC2 인스턴스를 생성함
5. 사용자가 미리 정의한 여러 테스트를 실행
6. AMI 테스트가 완료되면 배포
5. EC2 Instance Store
EBS 볼륨보다 높은 성능의 하드웨어 드라이브가 필요할 때 'EC2 인스턴스 스토어'를 사용할 수 있다.
EC2 인스턴스 스토어는 EBS 볼륨 대비 매우 향상된 처리량을 갖추고 있다.
-> 인스턴스에 성능이 아주 뛰어난 하드웨어가 연결된 경우, 로컬 EC2 인스턴스 스토어를 떠올릴 수 있다!
인스턴스 스토어를 중지 또는 종료하면 해당 스토리지가 손실된다.
때문에 이를 임시 스토리지라고도 부르며, 장기적으로 데이터를 보관하기에 적합하지 않다. (장기 스토리지는 EBS가 더욱 적합)
-> EC2 인스턴스 스토어는 버퍼, 캐시, 스크래치 데이터, 임시 콘텐츠를 사용할 때 유용하다!
인스턴스의 기본 서버에 장애가 발생할 때, 해당 인스턴스가 연결된 하드웨어에도 장애가 발생하여 데이터 손실의 위험이 있다.
따라서 필요하다면 데이터를 백업/복제해둬야 한다.
6. EFS(Elastic File System)
EFS는 관리형 네트워크 파일 시스템으로,
한 번에 수백 개의 EC2 인스턴스에 마운트할 수 있으며, 여러 AZ에서 사용 가능하다.
-> 공유 네트워크 파일 시스템(NFS) 구축
(<-> EBS 볼륨은 한 번에 하나의 인스턴스에만 연결)
EBS는 특정 AZ에 한정되기 때문에 다른 AZ로 옮기려면 스냅샷을 생성하고, 이를 이용해 새로운 AZ에 해당 EBS 볼륨을 복구해야 한다.
이렇게 옮겨진 EBS 볼륨은 복사본일 뿐, 동기화된 복제본은 아니다.
EFS 는 네트워크 파일 시스템으로, EFS 드라이브 내의 모든 내용은 마운트된 다른 시스템과 공유된다.
아래 이미지 우측의 경우 처럼, AZ 1에 여러 인스턴스가 있고 AZ 2에도 여러 인스턴스가 있을 때,
EFS 드라이브에 이 모든 인스턴스들이 동시에 마운트될 수 있다.
이렇게 모든 파일을 공유할 수 있다는 점이 EBS와의 차이점!
+) EFS Infrequent Access (EFS-IA) w/ 수명 주기 정책
스토리지 클래스는 파일 액세스 빈도에 따라 비용 최적화 과정을 거친다.
EFS-IA 는 EFS 표준 스토리지 클래스보다 액세스 빈도가 낮은 데이터를 저장하며, 비용도 92% 이상 저렴하다.
EFS-IA 스토리지 클래스를 활성화 시키면, 수명 주기 정책에 따라 EFS가 자동으로 파일들을 다른 스토리지 클래스로 옮기며 비용 절감의 효과를 누릴 수 있다.
6. EC2 Storage의 공동 책임 모델
- AWS의 책임
- 인프라에 대한 책임
- EBS 볼륨 & EFS 드라이브의 데이터 복제를 하드웨어에서 수행하는 것에 대한 책임
- 결함이 있는 하드웨어 교체
- AWS 직원이 사용자의 데이터에 접근하지 못하도록 액세스를 막아야 함
- 사용자의 책임
- 백업 설정 / 스냅샷 절차 및 가이드라인 설정 (데이터 손실 막기 위해)
- 데이터 암호화 설정
- 드라이브에 설정하는 모든 데이터에 대한 책임
- EC2 인스턴스 스토어 사용에 관한 리스크 이해(하드웨어에 결함이 생기면 드라이브를 잃게 됨 & 인스턴스 스토어가 있는 인스턴스를 중지하거나 종료하면 데이터를 잃게됨 <- 백업 작업이 필요한 이유)
'AWS' 카테고리의 다른 글
| Load Balancer에 대해 알아보기 - AWS의 대표적인 로드 밸런서 3가지(ALB, NLB, GWLB)까지 (0) | 2025.02.18 |
|---|---|
| 클라우드의 수평/수직 확장성과 고가용성 이해하기 (0) | 2025.02.17 |
| AWS EC2 인스턴스 유형별 선택 전략과 공동 책임 모델 (0) | 2025.02.16 |
| Amazon EC2 - 인스턴스, 보안, 스토리지까지 (0) | 2025.02.15 |
| AWS IAM 개념 정리 2 - 역할, 보안 도구, 모범 사례, 공동 책임 모델 (0) | 2025.02.14 |