[aws](5) Instance Storage Section

What's an EBS Volume?

Elastic Block Store Volume
인스턴스가 실행중인동안 연결 가능한 네트워크 드라이브
인스턴스가 종료된 후에도 데이터를 지속할 수 있음 > EBS를 쓰는 이유
우리가 인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있음
CCP 레벨의 EBS 볼륨은 한번에 하나의 인스턴스에만 마운트할 수 있음
EBS 볼륨은 하나의 가용 영역에 귀속됨
ex) EBS 볼륨이 us-east-1a에서 생성이 된 경우 us-east-1b에서는 연결이 불가능함
Think of them as a network USB stick
프리티어 : 매달 30GB의 ESB를 제공함

네트워크 드라이브 : 인스턴스와 EBS 볼륨이 서로 통신을 하기 위해서는 네트워크를 필요로 함,
인스턴스에서 분리될 수 있고 다시 부착될 수도 있음
EBS 볼륨은 특정한 가용 영역에 고정되어 있음 :
An EBS in us-east-1a cannot be attached to us-east-1b
To move a volume across, you first need to snapshot it
Have a provisioned capacity (size in GBs, and IOPS) EBS 볼륨의 성능을 미리 지정
You get billed for all the provisioned capacity
You can increase the capacity of the drive over time
하나의 인스턴스에 두개의 EBS 볼륨을 마운트하는 것은 가능함
EBS 볼륨을 생성하고 인스턴스에 연결하지 않고 그대로 둘 수도 있음

EBS - Delete on Termination attribute

EC2 인스턴스를 통해 EBS 볼륨을 생성하는 경우
종료시 삭제 속성이 있음
Controls the EBS behaviour when an EC2 instance terminates: By defalut, the root EBS volume is delete 기본적으로 종료시 삭제 활성화
By default, any other attatched EBS volume is not deleted 기본적으로 종료시 삭제 비활성화
Use case: preserve root volume when instance is terminated

인스턴스 스토리지

EBS 콘솔

볼륨생성
가용영역은 인스턴스의 가용영역과 동일하게

하나는 내 머신의 루트 볼륨 하나는 내가 만든거

인스턴스에 연결

가용영역을 다르게 지정하여 EBS 볼륨을 하나 더 생성함

cannot attach

EBS Snapshots

언제든 원하는 시점에 EBS 볼륨을 가지고 와서
백업이라고 불리기도 하는 스냅샷을 생성 가능함
추후에 EBS 볼륨을 삭제하더라도 해당 시점에 대한 백업으로 복원 가능함
Not necessary to detach volume to do snapshot, but recommeneded
가용영역 또는 리전에 걸쳐 스냅샷을 복제할 수 있음

ex) us-east-1a 의 EBS 볼륨을 us-east-1b 로 전송할때
1.해당 ebs 볼륨을 ec2 인스턴스에 연결하는 방식 사용
2.그 다음 스냅샷을 생성함
3.스냅샷에 문제가 없는지 확인
4.인스턴스 종료
5.스냅샷이 생기면 다른 가용영역에 새로운 EBS 볼륨을 복원 가능함

이 스냅샷은 내가 원하는 어느 리전에 위치시킬 수 있음
스냅샷을 다른 리전으로 복사
어플리케이션을 복원
재해복구를 위해 데이터를 다른곳에 보관

스냅샷에서 볼륨 생성
이 볼륨은 스냅샷의 콘텐츠를 정확히 포함하게 됨

첫번째는 전에 생성된 볼륨이고
아래는 스냅샷으로 복원된 새로운 볼륨
스냅샷의 가용영역이 다르다는 것에 집중해야함
볼륨을 다른 가용영역으로 쉽게 이동시킬 수 있음

AMI

Amazon Machin Image
AMI are a custiomization of an EC2 instance
aws에서 생성한 ami를 사용하거나 사용자 지정 ami를 만들 수 있음

you add your own sortware, configuration, os, monitoring
자체적으로 AMI를 생성하면 부팅과 구성에 시간이 단축됨 > 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징됨
AMI are built for a sepcific region and can be copied across regions
AMI를 특정 리전에 맞도록 구축하고 이들을 원하는 리전에 복사해두거나 AWS 글로벌 인프라를 활용할 수 있음
You can lauch EC2 instances from:
A public AMI: aws provided(항상 쓰던 것)
your own AMI: you make and maintain them yourself
An AWS Marketplace AMI : 다른 사용자가 만들어서 판매하는 AMI

AMI Process

1. start an EC2 instance and customize it
2. Stop the instance (데이터 무결성을 위해)
3. Build an AMI - this will also create EBS snapshots EBS 스냅샷이 생성됨
4. Launch instances from other AMIs 다른 AMI에서 인스턴스를 실행할 수 있음

ex) us-east-1a 인스턴스가 있고
us-east-1b에 동일한 인스턴스를 생성하는 상황

1a에서 Custom AMI를 생성함
1b에서는 해당 AMI로부터 인스턴스를 실행하여
EC2 인스턴스의 사본을 생성함



인스턴스가 시작될 때
index.html 파일을 생성하는 메세지를 사용자 지정하고 ec2를 사용자 부팅했을 때 하나의 명령만 실행되도록 하는 거
본 AMI에 이미 httpd 파일이 설치되었으니 따로 설치하지 않아도됨 > 인덱스페이지 로딩 속도가 빠름
아파치 httpd 서버가 이미 설치된 상태이기 때문에 시간 소요 없이 표시됨

EC2 Instance Store

EBS volumes are network drives with good but limited performance
성능 자체는 뛰어나지만 이보다 더 높은 성능을 요구할 때도 있고 이때는 인스턴스에 연결된 하드웨어 디스크 성능이 향상되어야 함
인스터느는 가상 머신이지만 실제로 하드웨어 서버에 연결도어 있음
이와 같은 서버는 하드웨어 서버에 물리적으로 연결된 디스크 공간을 가짐
특정 유형의 인스턴스는 EC2 인스턴스 스토어라고 불리며 이는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가르킨다
이 EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용할 수 있음
인스턴스 스토어를 중지 도는 종료하면 해당 스토리지 도한 손실됨 > 임시 스토리지임
Ec2 인스턴스 스토어는 장기적으로 데이터를 저장하는 공간은 될 수 없음(장기간은 EBS가 적합)
Good for buffer / cache / scratch data / temporary content
EC2 인스턴스의 기본 서버에 장애가 발생할 시에는 해당 EC2 인스턴스가 연결된 하드웨어에도 장애가 발생하므로 데이터 손실에 대한 위험이 있음
데이터 백업과 Replication을 해둬라 ~

EBS Volume Types

EBS Volumes come in 6 types
gp2 / gp3 ssd : General purpose SSD volume 다양한 워크로드에 대해 가격과 성능의 절충안
io1 / io2 ssd : Highest-performance SSD volume 최고 성능, 미션 크리티컬, 지연시간이 낮고 대용량의 워크로드에 쓰임
st1 hdd : 저비용의 hdd volume 잦은 접근과 처리량이 많은 워크로드
sc1 hdd : 가장 저비용의 hdd volume 접근 빈도가 낮은 워크로드
EBS볼륨은 사이즈, 처리량 , IOPS(초당 IO 작업수)
Only gp2/gp3 and io1/io2 can be used as boot volumes

General Purpose SSD

짧은 지연 시간, 효율적인 비용의 스토리지
시스템 부트 볼륨, 가상 데스크톱, 개발과 테스트 환경에서 사용 가능함
1GB-16TB
gp3: newer generation volume IOPS와 처리량을 독자적으로 설정
기본 성능으로 3000 IOPS와 초당 125MB의 처리량을 제공함
IOPS는 최대 16000까지, 처리량은 1000MB/s까지 각각 증대 가능함
gp2: older version IOPS와 처리량 연결
Small gp2 volumes can burst IOPS to 3000
볼륨과 IOPS가 연결되어 있음 최대 16000까지 늘릴 수 있음
3IOPS당 1GB means at 5334GB we are at the max IOPS
gp2 / gp3

Provisioned IOPS PIOPS SSD

Critical business applications with sustained IOPS performance
16000 IOPS 이상을 요하는 어플리케이션에 적합함
32000 IOPS면 무조건 io1 or io2의 EC2 Nitro
EBS io1 또는 io2 볼륨 유형을 사용할 때 달성할 수 있는 최대 IOPS는 64,000
데이터베이스 워크 로드에 적합함 (스토리지 성능과 일관성에 아주 민감한 경우)
io1 / io2
4GB-16TB
Mac PIOP: 64000 for Nitro EC2 instances & 32000 for other
프로비저닝된 IOPS를 스토리지 크기와 독자적으로 증가시킬 수 있음
io2는 io1과 동일한 비용으로 내구성과 기가 당 IOPS의 수가 더 높음 > io2를 사용하는 것이 더 합리적임
io2 Block Express (4GB-64TB):
좀 더 고성능의 볼륨 Sub millisecond laltency
Max PIOPS: 256000 with an IOPS: GB ratio of 1000:1
EBS io2 Block Express 볼륨 유형을 사용할 때 달성할 수 있는 최대 IOPS는 256,000 입니다.
EBS 다중 연결을 지원하는 PIOPS의 유형이 있다

Hard Disk Drives

Cannot be a boot volume 부트 볼륨일 수 없고 이전 유형의 볼륨에 해당된다
125 MB to 16 TB
OPtimized HDD 처리량 최적화 HDD (st1) : 빅데이터, 데이터 웨어하우스, 로그 프로세싱
Max throughput 500MB - max IOPS 500

Cold HDD (sc1): 아카이브 데이터용
접근 빈도가 낮은 데이터
최저 비용으로 데이터를 저장할 때 사용함
Max throughput 250MB - max IOPS 250

EBS multi attach io1/io2 family

원래 EBS 볼륨은 단일한 EC2 인스턴스에만 연결할 수 있음 > EBS다중 연결을 제외하고
다중 연결로 동일한 EBS 볼륨을 동일한 가용 영역의 여러 인스턴스에 연결하여 사용 가능함
사용 상황:
클러스터 된 리눅스 애플리케이션에서 애플리케이션의 가용성을 높ㅇ야 하는 경우 ex Teradata
해당 애플리케이션은 동일한 볼륨에서의 동시 쓰기 작업을 관리할 수 있어야함
반드시 cluster-aware file system을 사용해야함 not XFS, EX4, etc..
io1, io2인 경우에만 다중 연결이 가능함

EBS encryption

암호화된 EBS 볼륨을 생성함:
볼륨 내에서 암호화된 저장 데이터를 가져옴
인스턴스와 볼륨 간에 전송되는 모든 데이터가 암호화됨
모든 스냅샷 암호화
스냅샷으로부터 생성된 모든 볼륨이 암호화됨
기존 암호화와 해독 메커니즘이 투명하게 처리됨 > 모든 작업이 Ec2와 ebs에서 처리됨으로 사용자가 별도 액션을 하지 않아도 됨
Encryption has a minimal implac on latency
EBS encrytion leverages keys from KMS (AES-256)
암호회되지 않은 스냅샷을 복사할 때 암호화를 활성화함
암호화되지 않은 EBS 볼륨을 어떻게 암호화할까 ? 가 중요함

encrypt an unencrypted EBS volume

볼륨의 EBS 스냅샷을 생성함
복사 횟수로 EBS 스냅샷을 암호화함 using copy function
스냅샷에서 새 EBS 볼륨을 생성함 (새 볼륨은 암호화되어있음)
암호화된 볼륨을 원본 인스턴스에 연결할 수 있음

Elastic File System EFS

다수의 가용 영역에 걸쳐 다수의 인스턴스에 마운트할 수 있는 관리형 NFS 네트워크 파일 시스템
EFS works with EC2 instances in multiAZ 다중 AZ에서 동작함 > EFS와 EBS의 가장 큰 차이
EBS는 단일 가용 영역에 묶여 있지만 EFS는 다중 가용 영역에 걸쳐 마운트가 가능함
가용성, 확장성, 비용 많이듦 (gp2 드라이브 비용의 약 3배) pay per use 너무 많은 데이터를 저장하지 않는 경우 EBS보다 EFS가 저렴함

EFS 드라이브의 모든 EC2 인스턴스가 동일한 파일에 대한 접근 권한을 갖는다
Use cases: content management, web serving, data sharing, Wordpress
User NFSv4.1 protocol
EFS 파일 시스템에 접근하려면 보안 그룹(security group)을 이용해야 함 > 네트워크 보안
EFS는 리눅스 기반 AMI에서만 작동함(윈도우즈 안됨)
KMS 키를 사용하여 EFS 유휴시 암호화를 설정할 수 있음
POSIX file system (~linux) 으로 표준 파일 API를 가짐
파일 시스템은 자동으로 확장되며 쓰는 만큼 비용을 내는 방식임 capacity planning이 필요 없다

EFS - performance & stroage classes

EFS scale: 수천명의 동시 클라이언트와 초당 최대 10GB의처리량
파일 시스템 자체가 페타바이트 스케일까지 확장될수 있으므로 용량을 따로 설정할 필요가 없음
Performance mode (set at EFS creation time)
General purpose (default): 웹 서버 운영이나 지연시간에 미감한 파일이 있는 경우(여러 작은 용량 파일에 신속하게 접속해야함) EX 웹서버 CMS
Max I/O: 빅데이터와 같은 대규모 데이터 처리하는 경우 높은 지연시간, 처리량 향상, 병렬적 EX big data, media processing
Throughput mode 처리량 모드
Bursting : 1TB = 50MB/s + burst of up to 100MB/s 1TB 스토리지에 대해 초당 50MB를 저장할 수 있고 여기에 초당 100MB까지 확장 가능함
(파일 시스템의 크기에 따라 처리량이 증가함)
Provisioned: set your throughput regardless of storagesize EX 1GB/s for 1TB storage 스토리지 크기와 상관없이 처리량 설정 1테라 스토리지여도 1기가/s의 처리량을 요청할 수 있음
(파일 시스템 자체는 작으나 높은 처리량을 요구할 때)
이미 파일시스템의 크기가 정해져있음
Storage Tiers 파일에 대한 수명 주기 관리 기능 : move file after N days
EX 30일이 지나면 새로운 계층으로 파일을 이동시킴
standard : for frequently accessed files
EFS-IA : infrequent access 빈도가 낮은 접근 파일을 저장하는 저비용의 장소

EFS 는 여러 가용영역에 걸쳐 다중으로 마운트 가능함
그래서 각 AZ에 대한 보안 그룹의 정의가 필요함

ec2 인ㅅ턴스가 efs 파일 시스템에 접근한다는 의미

my-efs-demo가 ec2-efs로부터 오는 트래픽을 허용하도록 보안그룹 설정해줘야함

my-efs-demo에 인바운드룰 추가

sudo mount -t efs -o tls fs-:/ efs

동일한 파일을 두 인스턴스에서 동시에 읽고쓰기가 가능함 : 공유 네트워크 파일 시스템

EBS vs EFS

EBS: 한번에 하나의 인스턴스에만 연결이 가능함
특정 가용 영역에 한정됨
gp2 : 디스크 크기가 늘어나면 IO도 함께 증가함
io1 : IO를 볼륨 크기와 관계없이 독립적으로 증가함 중요한 데이터베이스를 실행할 때 좋은 방법

To migrate an EBS volume across AZ:
take a snapshot
Restore the snapshot to another AZ
EBS 스냅샷이나 백업을 만들 때에는 EBS 볼륨 내의 IO를 전부 사용하게 되니 인스턴스가 EBS를 사용중이 아닐 때에만 실행해야함
인스턴스가 종료되면 인스턴스 내의 루트 EBS 볼륨도 기본적으로 종료됨

EFS: Mounting 100s of instances across AZ
( 원래는 EFS는 글로벌이지만 EFS 마운트 타겟을 사용해 특정 AZ에서 EC2 인스턴스들과 EFS 드라이브를 연결해줄수 있음
WordPress 같은 웹사이트 파일을 공유할 때도 EFS를 씀
Only for Linux Instances POSIX
EFS가 EBS보다 비싸다
스토리지 티어로 EFS-IA를 사용하고 라이프 사이클 폴리시를 사용하면 비용 절감이 가능함
EFS는 사용한만큼만 비용이 청구됨( EBS는 드라이브의 크기에 따라 실제 사용량이 아닌 정해진 사용량을 지불하는 형식)
다수의 인스턴스에 걸쳐 연결해야 하는 네트워크 파일 시스템에 적합함

• 인스턴스 스토어는 인스턴스에 IO를 최대로 사용하게끔 해주지만 인스턴스가 망가지면 함께 망가지는 임시 드라이브임

기본적으로 루트 볼륨 유형은 종료 시 삭제 속성이 기본적으로 선택되어 있으므로 삭제됩니다. 다른 EBS 볼륨 유형은 종료 시 삭제 속성이 기본적으로 비활성화되어 있으므로 삭제되지 않습니다.

AMI는 특정 AWS 리전용으로 각 리전 마다 고유하게 구축됩니다. 다른 AWS 리전의 AMI를 사용하여 EC2 인스턴스를 런칭할 수는 없지만 AMI를 대상 AWS 리전에 복사한 다음 이를 사용하여 EC2 인스턴스를 생성할 수 있습니다.

EC2 인스턴스를 생성할 때 다음과 같은 EBS 볼륨 유형만 부팅 볼륨으로 사용할 수 있습니다: gp2, gp3, io1, io2 및 마그네틱(표준).

EBS 볼륨은 특정 AZ에 대해 생성됩니다. EBS 스냅샷을 사용하여 서로 다른 AZ 간에 마이그레이션할 수 있습니다.