AWS

EBS

MinCodeHub 2025. 12. 30. 15:24

EBS

  • Elastic Block Store Volume
  • 인스턴스가 실행되는 동안에는 인스턴스에 연결할 수 없는 네트워크 드라이브
    • 인스턴스와 EBS 볼륨 간의 통신을 위해 네트워크 사용(지연 있음)
    • EC2인스턴스에서 분리하여 다른 인스턴스에 매우 빠르게 연결할 수 있음(장애 조치할 때 편리)
    • 인스턴스가 종료된 후에도 데이터 유지 가능(인스턴스를 다시 생성하고 이전과 동일한 EBS 볼륨을 마운트하면 데이터를 다시 가져올 수 있음)
    • CCP 레벨의 EBS 볼륨은 한 번에 하나의 인스턴스에만 마운트 할 수 있음
  • 특정 가용성 영역에 고정되어 있음 (us-east 1a에 생성된 EBS 볼륨을 us-east 1b의 인스턴스에 연결할 수 없음)
    • 스냅샷을 수행하면 다른 가용성 영역에서 볼륨을 이동할 수 있음
  • 미리 용량을 프로비저닝해야함
    • 원하는 기가바이트 수와 초당IO, 작업 수인 IOPS를 미리 알려줘야함
    • 해당 프로비저닝 용량에 대한 요금이 청구되며, 더 나은 성능이나 더 큰 용량을 원할 경우 늘릴 수 있음

US-EAST-1A

  • 해당 EC2 인스턴스에 하나의 EBS 볼륨을 연결할 수 있음
  • 다른 EC2 인스턴스를 생성하는 경우, 따로 EBS 볼륨을 만들어줘야함
  • 하나의 인스턴스에 두 개의 EBS볼륨이 연결될 수 있음

US-EAST-1B와 같은 다른 AZ에서 다른 EBS 볼륨을 사용하려면 

다른 가용성 영역에서 별도로 생성해야함.(연결 안한 볼륨도 존재 가능)

 

 

EBS 볼륨 종료시 삭제 속성

기본적으로  

Root볼륨에는 체크

새 EBS 볼륨에는 체크되어있지 않음

 

따라서 EC2인스턴스가 종료될 때 EBS 동작을 제어함

Root EBS 볼륨은 인스턴스가 종료되는 것과 함께 삭제됨(다른 EBS볼륨은 삭제 되지 않음)

 

AWS 콘솔에서 위의 사진과 같이 종료 시 삭제를 활성화할지 비활성화할지 선택할 수 있음

 

 

EBS Snapshots

 

  • EBS 볼륨의 백업
  • EBS볼륨과 EC2 인스턴스를 분리할 필요는 없지만 권장
  • 이런 EBS 스냅샷을 다양한 사용 가능성 존이나 다른 지역으로 복사할 수 있음

 

 

EBS 스냅샷 기능

  • EBS Snapshot Archive 아카이브

    • 'archive tier' : 스냅샷을 이동시키는 기능 (75퍼 저렴)
    • 스냅샷을 'archive tier' 로 옮기면 24시간 이내에서 72시간 이내로 아카이브를 복원할 수 있음
  • Recycle Bin 재활용
    • EBS 스냅샷을 영구 삭제하는 대신 삭제하면 Recycle Bin에 들어감
    • 우연히 삭제된 파일을 복구할 수 있음
    • 저장기간은 하루에서 일년 사이로 설정 가능
  • Fast Snapshot Restore(FSR) 빠른 스냅샷 복원
    • 스냅샷의 전체 초기화 강제(첫 번째 사용에 대기 시간이 없도록)
    • 스냅샷이 큰 경우 특히 도움이 됨
    • 비용이 많이 듦

 

AMI

 

  • Amazon 머신 이미지
  • EC2 인스턴스의 사용자 지정
    • 자신만의 소프트웨어 구성(운영체제) 정의 및 셋업 가능
    • 자신만의 AMI를 만들면 부팅 시간과 구성 시간이 더 빨라짐
  • AMI는 특정 지역에 맞게 만들어서 그 지역에 걸쳐 복사 가능
  • 다양한 AMI로부터 EC2 인스턴스를 보낼 수 있음
    • A Public AMI: AWS provided (ex. Amazon Linux 2 AMI)
    • Own AMI: 직접 만든 AMI
    • An AWS Marketplace AMI : 사고 팔 수 있음

 

EC2의 AMI 작동 과정

 

  1. EC2 인스턴스 시작해 사용자 지정
  2. 데이터 무결성을 확인하기 위해 인스턴스를 멈춤
  3. AMI를 구축 (EBS스냅샷도 생성 예정)
  4. 다른 AMI의 인스턴스를 실행 가능

 

EC2 인스턴스 STORE

 

EBS Volume은 성능이 제한되어있고,

더 높은 성능을 원할때는 ec2에 하드웨어 디스크를 연결할 수 있음

 

성능 높은 하드웨어 디스크를 원할 때 EC2 인스턴스 스토어를 활용

 

  • 더 좋은 I/O 성능
  • 인스턴스 스토어가 있는 EC2 인스턴스를 중지하거나 종료하면 스토리지가 손실됨(장기 사용은 EBS)
  • 따라서 인스턴스 스토어는 장기적으로 저장할 수 있는 내구성 있는 장소로 사용할 수 없음
  • 버퍼, 캐시, 스크래치 데이터, 임시 콘텐츠가 필요할 경우 사용 
  • EC2 서버에 장애가 발생하는 경우 EC2 인스턴스에 연결된 하드웨어도 장애가 발생하므로 큰 손실 발생 가능
  • 따라서 EC2 인스턴스 스토어를 사용하기로 결정했으면 백업, 복제해야함

 

 

EBS Volume Type

 

  • gp2/ gp3 (SSD) : 성능의 균형을 맞출 수 이쓴 범용 SSD
    • 지연시간이 짧은 비용 효율적인 스토리지
    • 시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경 등에 사용할 수 있음
    • 1기가바이트 - 16테라 바이트까지 다양
    • gp3 :
      • 최신세대
      • 3000 IOPS와 초당 125 메가바이트의 처리량을 기본으로 제공
      • 독립적으로 16000까지 IOPS와 초당 1000메가바이트의 처리량을 늘릴 수 있음
    • gp2: 
      • 크기와 IOPS가 비례적(GB당 3 IOPS)
      • 볼륨 크기과 IOPS가 연동되어 있음
      • 5334GB크기 일때 최대 IOPS 사용
  • io1 / io2 Block Express(SSD) : 미션 크리티컬한 저지연 및 고처리량 워크로드에 사용되는 최고성능의 SSD볼륨
  • st1 (HDD): 자주 엑세스하는 처리량 집약적인 워크로드를 위해 설계된 저비용 HDD 볼륨
    • 빅데이터, 데이터웨어하우징, 로그 처리
    • 초당 최대 처리량 500MB, 최대  500 IOPS
    • 125GB ~ 16TB 크기
  • sc1(HDD): 엑세스 빈도가 낮은 워크로드를 위해 설계될 예정
    • 초당 최대 처리량 250 MB, 최대 250  IOPS 
    • 125GB ~ 16TB 크기
    • 가장 비용이 낮음

EBS볼륨은 크기, 처리량, 초당 입출력 작업(IOPS) 등 으로 정의됨

 

EC2 인스턴스의 경우 gp2 및 gp3, io1 및 io2만 부팅 볼륨으로 사용할 수 있음

이는 루트 OS가 실행될 위치를 의미

 

프로비저닝된 IOPS볼륨(PIOPS)

 

  • 용도
    • 일관된 IOPS 성능이나 16000이상 IOPS 필요한 경우
    • 스토리지 성능과 일관성에 매우 민감한 DB
  • io1의 경우
    • 최대 PIOPS는 Nitro 인스턴스의 경우 64000, 타 인스턴스는 32000
    • 볼륨 크기에 관계없이 PIOPS 늘릴 수 있음
  • io2 Block Express의 경우
    • IOPS 용량 = 1000: 1 비율로 최대 256,000 IOPS

 

EBS Multi-attach 기능 지원

  • 다중 연결 기능은 같은 EBS 볼륨을 다중 EC2 인스턴스에 같은 사용 가능성 존에 연결하게 함
  • 각 인스턴스는 고성능 볼륨을 위한 읽기 및 쓰기 권한을 갖게 됨
  • 사용사례:
    • 클러스터된 Linux 응용 프로그램의 경우 더 높은 응용 프로그램 가용성을 갖는 것(ex. Teradata 사용 or 동시 작성 작업을 관리해야할 경우)
  • 다중 연결 기능은 지정된 사용 가능성 존에서만 사용 가능
  • 한번에 최대 16개의 EC2 인스턴스를 같은 볼륨 첨부 가능
  • 클러스터 인식을 하는 파일 시스템 사용

 

EFS

  • Elastic File System
  • 여러 EC2에서 사용될 수 있는 네트워크 파일 시스템(NFS), EC2들은 다른 AZ에 있어도 됨
  • 높은 가용성과 확장성, 그러나 비싸고 사용량에 따른 지불
  • 사용 예시: 콘텐츠 관리, 웹 서빙, 데이터 공유, 워드 프레스
  • 내부적으로 NFSv4.1 프로토콜 사용
  • EFS 접근 관리를 위해 보안 그룹 사용
  • 리눅스 기반 AMI에만 호환됨(Windows 불가)
  • KMS를 이용한 암호화 가능
  • POSIX 파일 시스템 사용, 표준 파일 API 가짐
  • 사용에 따라 스케일 자동 확장

성능

  • 수천 개의 클라이언트 동시 처리 및 10GB 이상 처리량
  • 자동으로 PB 수준의 네트워크 파일 시스템 가능
  • 퍼포먼스 모드(EFS 생성 시 설정)
    • 일반(기본): 웹 서버, CMS같은 지연 시간에 민감한 서비스
    • 최대 I/O: 지연 시간은 높으나 최대 처리량(빅데이터, 미디어처리)
  • 처리량 모드
    • Bursting: 1TB용량이라면 초당 50 MB + 버스팅으로 최대 100MB
    • Provisioned: 스토리지 용량에 상관없이 처리량 증가 가능
    • Elastic: 작업에 따라 처리량 자동으로 설정

용량

  • 스토리지 계층
    • 수명주기 관리 기능, 일정 시간 지나면 타 계층으로 파일을 옮길 수 있음
    • 스토리지 티어 간 자동으로 파일을 이동하려면 수명 주기 정책을 구현하면 됨
    • 종류
      • 표준 계층:자주 엑세스 되는 파일용
      • Infrequent Access(EFS-IA) 계층: 파일 검색에는 비용이 들지만 저장에는 적게 듦
      • 아카이브 계층: 거의 액세스되지 않는 데이터용 50% 저렴
  • 가용성, 내구성
    • 스탠다드: 여러 AZ에 걸쳐 존재할 때, 프로덕션 환경일 때 용이
    • One Zone: 하나의 AZ에만 존재, 개발환경이고 저렴한걸 원할때, 스토리지의 IA와 호환되며 기본적으로 백업 존재

 

EBS vs EFS

 

  • EBS
    • 한 ec2 인스턴스에만 연결됨(io1/io2 특수 경우 빼고)
    • 특정 AZ에 구속됨(이동하려면 스냅샷 찍어야)
    • gp2의 경우 디스크 용량과 IO가 비례적으로 증가하나 gp3, io1에서는 독립적으로 증가 가능
    • 백업 시 IO를 사용하기 때문에 애플리케이션이 많은 트래픽을 처리중이라면 사용하면 안됨
  • EFS
    • 여러 AZ에 걸쳐 수백 개의 인스턴스에 연결될 수 있음
    • EBS에 비해 가격대 더 높으나 비용 절감을 위해 스토리지 계측 사용 가능

'AWS' 카테고리의 다른 글

EC2  (0) 2025.12.29