woongs dogfoot

EBS (Elastic Block Store)

• EBS : 인스턴스가 실행중일 때 연결 가능한 네트워크 드라이브 (like network "USB", 실제 물리적인 연결은 없지만 네트워크를 통해 연결)
  
  
  

• 특징

1. 인스턴스가 종료되어도 데이터를 유지시킬 수 있다. (EC2 인스턴스 부팅 후, EBS Volume 마운트하면 재사용 가능)
2. CCP 레벨에서는 한 개 EBS에 하나의 인스턴스만 마운트할 수 있다. (한 개 인스턴스에는 여러개 EBS 마운트 가능, 어소시에이트 레벨에서는 EBS 다중연결 가능)
3. 동일 가용영역의 인스턴스만만 마운트 가능하다.
4. 네트워크가 필요하다. (EC2 인스턴스에서 다른 EC2 인스턴스로 옮겨 마운트될 수 있음. but, 네트워크 지연이 발생할 수 있음)
5. 스냅샷이라는 기능을 활용하면 다른 가용영역으로 EBS Volume을 옮길 수 있다.
6. 용량 및 성능을 미리 정해야 한다. (용량 및 성능에 따라 비용 청구)
7. EC2 인스턴스를 생성할 때 EBS도 동시에 생성하는 경우, EC2 인스턴스 종료 시에 EBS도 삭제될 수 있는 옵션이 있다. (default는 삭제)
   
   
   

• EBS Snapshots : EBS Volume의 특정 시점에 대한 백업 -> 다른 AZ나 Region에 복사할 수 있음 (Copy Snapshot)
• 기능

1. EBS Snapshot Archive : Standard teer에 비해 75% 저렴한 EBS 스냅샷 저장소 (Archive teer), 아카이브에서 복원 시 24시간에서 최대 72시간까지 소요됨
2. EBS Snapshot 휴지통 : EBS 스냅샷 휴지통, EBS 스냅샷을 삭제하는 경우에 영구 삭제되지 않고 휴지통으로 이동됨. (실수방지)
   • Regention Rule 생성을 통해 휴지통 보관 설정을 진행할 수 있음
3. Fast Snapshot Restore (FSR) : 빠른 스냅샷 복원, 스냅샷의 완전한 초기화를 통해 사용 시의 지연시간을 없앰 -> 고비용 수반

AMI (Amazone Machine Image)

• AMI : EC2 인스턴스를 통해 만든 image, 커스터마이징 가능 (like docker image)
  
  
  

• 특징

1. AMI를 이용하면 부팅을 위한 소프트웨어들이 모두 패키징(설치시간 단축)되어 있기 때문에 EC2 인스턴스의 부팅시간을 줄여줄 수 있음
2. 특정 지역에서 만든 AMI를 다른 지역에서 활용하여 EC2 인스턴스를 생성할 수 있음 (AMI를 복사해서 다른 region으로 옮겨야 함)
3. AWS 마켓플레이스에서 다른 커스터마이징 AMI를 구할 수 있음 (public AMI : AWS에서 제공)
   
   
   

• AMI 생성순서

1. EC2 인스턴스 생성
2. EC2 인스턴스 중지
3. AMI 생성
   • EBS Snapshot 생성

EC2 Instance Store

• EC2 Instance Store : EC2 Instance와 연결될 Volume이 동일 하드웨어 서버에 위치한 Volume
• Network Driver를 통해 연결된 EBS Volume 보다 더 높은 network 성능을 요구할 수도 있음 -> EC2 Instance Store 활용 필요
• EC2 Instance Store가 중지되면 데이터 또한 손실됨 -> 장기적으로 저장할 용도의 저장소는 안됨
• Use Case : Buffer, Cache, Temporary Contents 등
• 필요에 따라 데이터를 백업하거나 복제해야 함.
  
  
  

EBS Volume Types

• IOPS : I/O Ops per Sec, 초당 I/O 작업 수, 높을 수록 파일을 읽고 쓰는게 빨라짐
  
  
  

1. gp2/gp3 (SSD) : 가격과 성능이 적절한 균형을 이룸

   • gp2/gp3 : 범용 SSD
   • 저지연/비용효율적
   • System boot volumes, 가상 데스크톱, 개발, 테스트 환경으로 활용
   • 1GiB ~ 16TiB
   • gp3 : gp2에 비해 최신 세대의 volume, 기본설정 3000IOPS/초당 125MB의 처리량
   • gp3 : 최대 IOPS16,000/초당 1,000MB의 처리량, volume size와 IOPS는 독립적
   • gp2 : gp3에 비해 small size, 최대 3,000 IOPS
   • gp2 : volume size와 IOPS는 서로 연결되어 있고 3 IOPS per GB
   • gp2 : 최대 IOPS는 16,000이고 3 IOPS per GB라서 volume size가 5,334GB일 경우 최대치인 16,000 IOPS를 넘게됨
     
     
     

2. io1/io2 (SSD) : 높은 성능의 SSD Volume, 지연 시간이 낮고 대용량의 workload에 쓰임

   • io1/io2 : Provisioned IOPS SSD
   • boot volume 활용 o
   • 4GiB ~ 16TiB
   • IOPS 성능 유지가 필요할 때 활용
   • 16,000 IOPS 이상을 요구하는 application에 활용
   • 스토리지 성능과 일관성에 민감한 Database workload에 적합
   • Nitro EC2에서는 최대 64,000IOPS까지 가능, 아닌 경우 최대 32,000IOPS까지 가능
   • gp3의 경우처럼 IOPS를 스토리지 크기와 독립적으로 증가시킬 수 있음
   • io2 : io1과 동일한 비용으로 내구성과 기기당 IOPS수가 더 높음 (io2 > io1 합리적)
   • io2 block express (4GiB ~ 64TiB) : 좀 더 고성능의 Volume, ms미만의 지연시간, IOPS : GB = 1000 : 1 일 때 최대 256,000 IOPS
     
     
     

3. st1 (HDD) : 저비용의 HDD Volume, 잦은 접근과 처리량이 많은 workload에 쓰임

   • boot volume 활용 x
   • 125MiB ~ 16TiB
   • 처리량 최적화 HDD, 최대처리량 500MiB/s, 최대 IOPS : 500
   • Big Data, Data Warehouse, Log처리 등에 적합
     
     
     

4. sc1 (HDD) : 가장 적은 비용의 HDD Volume, 접근 빈도가 낮은 workload에 쓰임

   • cold HDD
   • 아카이브 데이터 용도, 접근 빈도가 낮은 데이터에 적합
   • 최저비용으로 데이터를 저장할 떄 사용
   • 최대처리량 250MB, 최대 IOPS 250
     
     
     

• EBS Volume의 유형은 크기/처리량/IOPS(I/O Ops per Sec, 초당 I/O 작업 수)에 따라 결정됨
• EC2 인스턴스(root OS 실행)의 Boot Volume으로는 gp2/gp3 유형과 io1/io2 유형만 활용 가능
• EBS Volume Types 정리 : https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html
  
  
  

EBS Multi-Attach

• EBS Multi-Attach : 동일 가용영역 내에서 하나의 EBS에 여러 EC2 인스턴스를 연결하는 기능 (io1/io2 volume 한정)
• 모든 EC2 인스턴스는 읽기/쓰기 권한을 모두 가짐
• EC2 인스턴스 간에 동시쓰기 작업 등의 case에서 활용됨
• 최대 16개의 EC2 인스턴스 제한
• cluster-aware file system을 활용해야 함 (not XFS, EX4)
  
  
  

EBS Encyption

• EBS Volume 암호화 유형

1. volume 내부의 데이터 암호화
2. 인스턴스-volume간 데이터통신 암호화
3. volume의 snapshot 암호화
4. snapshot으로 생성한 volume 암호화
   
   
   

• 특징

1. 암호화는 EC2와 EBS의 백그라운드에서 알아서 처리됨
2. 지연시간에는 거의 영향이 없음
3. KMS에서 암호화 키를 생성
4. 암호화되지 않은 EBS에서 생성된 snapshot은 암호화되지 않음
   
   
   

• 암호화되지 않고 생성된 EBS 암호화 방법 - 1

1. EBS snapshot 생성
2. 복사 기능을 통해 EBS snapshot 암호화 (Actions - Copy snapshot)
3. EBS snapshot을 이용해 volume을 생성하면, 해당 volume도 암호화
4. 암호화된 volume을 원래의 EC2 인스턴스에 연결
   
   
   

• 암호화되지 않고 생성된 EBS 암호화 방법 - 2

1. EBS snapshot 생성
2. Create volume from snapshot
3. 암호화 체크 후 생성
   
   
   

EFS (Elastic File System)

• EFS : 관리형 NFS protocol, 네트워크 파일 시스템
  
  
  

• 특징

1. 많은 인스턴스에 마운트될 수 있음
2. 마운트된 인스턴스는 서로 다른 가용영역에 존재할 수 있음 (EFS의 강점)
3. 가용성 및 확장성이 좋으나 비용이 비쌈 (GP2 EBS의 약 3배)
4. 사용량에 따라 비용을 지불함 (미리 용량을 정하지 않음, 용량이 자동으로 확장됨, EFS의 강점)
5. 엑세스 제어를 위해 보안그룹을 활용함
6. linux기반 AMI만 호환됨
7. KMS를 활용하여 암호화를 활성화시킬 수 있음
8. linux 표준 파일시스템(POSIX) 활용
9. EC2에서 EFS설정 시, EFS와의 연결을 위해 자동으로 보안그룹(Security Group)을 생성하여 EFS에 연결함
   
   
   

• 성능

1. scale : 수천개의 클라이언트와 10GB이상의 처리량 확보, PetaByte 규모로 자동 확장
2. performance mode
   • general purpose(default) : 지연 시간에 민감한 case에서 활용됨 (ex. 웹서버, CMS 등)
   • Max I/O : 처리량 최대화 -> 처리량이 높고 병렬성이 좋음 (ex. 빅데이터 처리, 미디어 처리 등)
3. Throughput Mode
   • Bursting : 1TB, 초당 50MiB~100MiB 을 더한 것 (스토리지가 늘어날 수록 처리량 증가)
   • Provisioned : 스토리지 크기에 상관 없이 처리량 설정 (1TB 스토리지에서 초당 1GiB를 처리)
   • Elastic : workload에 따라 처리량을 자동 조절, workload를 예측하기 어려울 때 유용
     
     
     

• Storage classes

1. Storage Tiers : 며칠 후(수명주기) 파일을 다른계층으로 자동으로 옮김 (ex. 표준계층은 자주 사용하는 파일을 위한 계층이고, EFS-1A는 자주 사용하지 않는 파일을 위한 계층인데, EFS-1A 계층에서는 파일 검색이 오래걸림, 하지만 비용 감소)
2. 가용성과 내구성
   • 다중 가용영역으로 EFS를 설정할 수 있음 (가용성, prd환경에 적합)
   • One-Zone EFS (EFS One Zone-IA) : 하나의 가용영역, 백업 활성화, 엑세스 빈도가 낮은 Storage Tier와 호환 -> 비용할인이 많이 됨

• use case

1. 콘텐츠 관리
2. 웹 서버
3. 데이터 공유
4. wordpress
   
   
   

EBS vs EFS