DEVELOPyo

[ EBS Snapshots *** ]

Snapshot 생성시 데이터 백업과 유사

Snapshot 은 AZ / Region 에 제약이 없음

Snapshot 생성시 IO 를 사용하므로 앱에 부하가 있을 땐 생성하면 안됨

Snapshot 은 S3 에 저장됨

Amazon Data Lifecycle Manager을 사용하여 Snapshot 을 주기적으로 생성 할 수 있음(Scheduling)

- Incremental - only backup changed blocks

- EBS backups use IO and you shouldn't run then while your application is handling a lot of traffic

- Snapshots will be stored in S3 (but you won't directly see them)

- Not necessary to detach volume to do snapshot, but recommended

- Max 100000 snapshots

- can copy snapshots across AZ or Region

- Can make AMI from Snapshot

- EBS volumes restored by snapshots need to be pre-warmed (using fio or dd command to read the entire volume)

- Snapshots can be automated using Amazon Data Lifecycle Manager

[ EBS Migration ]

Snapshot 을 생성하여 Snapshot 을 통해 volume 을 생성하는 방식으로 AZ 제약을 해소할 수 있음

- EBS volumes are only locked to a specific AZ

- To migrate it to a different AZ (or region) :

  1) Snapshot the volume

  2) (optional) Copy the volume to a different region

  3) Create a volume from the snapshot in the AZ of your choice

[ EBS Encryption ]

Snapshot을 암호화 한 후 volume 을 생성 할 경우 volume 도 암호화 됨

- When you create an encrypcted EBS volume, you get the following :

  -- Data at rest is encrypted inside the volume

  -- All the data in flight moving between the instance and the volume is encrypted

  -- All snapshots are encrypted

  -- All volumes created from the snapshot

- Encryption and decryption are handled transparently (you have nothing to do)

- Encryption has a minimal impact on latency

- EBS Encryption leverages keys from KMS (AES-256)

- Copying an unencrypted snapshot allows encryption

- Snapshots of encrypted volumes are encrypted

[ # Encryption : encrypt an unencrypted EBS volume ]

암호화 되어있지 않은 EBS 를 암호화 하는 방법

- Create an EBS snapshot of the volume

- Encrypt the EBS snapshot (using copy)

- Create new EBS volume from the snapshot (the volume will also be encrypted)

- Now you can attach the encrypted volume to the original instance

[ EBS vs Instance Store ]

Instance Store (내장 물리디스크)가 EBS 에 비해 IO 성능이 뛰어나며 buffer/cache 등의 사용엔 유리할 수 있으나 인스턴스를 stop/termination 할 경우 사라짐. 

- Some instance do not come with Root EBS volumes

- Instead, they come with "Instance store" (= ephemeral(단명하는) storage)

- Instance store is physically attached to the machine (EBS is a network drive)

* Pros of Instance Store :

  - Better I/O performance

  - Good for buffer/cache/scratch data temporary content

  - Data survives reboots

* Cons :

  - On stop or termination, the instance store is lost

* Local EC2 Instance Store

  - Physical disk attached to the physical server where your EC2 is

  - Very High IOPS (because physical)

  - Disks up to 7.5 TB (can change over time), stripped to reach 30 TB (can change over time)

  - Block Storage (just like EBS)

  - Cannot be increased in size

  - Risk of data loss if hardware fails

[ EBS RAID configurations ]

# RAID 0 : extension (스트라이핑)

디스크 공간 확장

- Combining 2 or more volumes and getting the total disk space and I/O

- one disk fails, all the data is failed

- An application that needs a lot of IOPS and doesn't need fault-tolerance

- A database that has replication already built-in

- Using this we can have a very big disk with a lot of IOPS

# RAID 1 : instance fault tolerance, mirroring (미러링 설정)

디스크 미러링으로 안정성 향상

- Mirroring a volume to another

- If one disk fails, our logical volume is still working

- Send the data to two EBS volume at the same time

- Application that need increase volume fault tolerance

- Application where you need to service disks

[ EFS - Elastic File System ]

EBS 와 달리 multi AZ 에서 사용 가능

고성능, 고비용

Linux AMI 에서 사용이 가능 (Windows X)

- Managed NFS (network file system) that can be mounted on many EC2

- EFS works with EC2 instances in multi-AZ

- Highly available, scalable, expensive (gp2 3배), pay per use

- Use cases: content management, web serving, data sharing, Wordpress

- Uses NFSv4.1 protocol

- Uses security group to control access to EFS

- Compatible with Linux based AMI (not Windows)

- Encryption at rest using KMS

- POSIX file system(Linux) that has a standard file API

- File system scales automatically, pay-per-use, no capacity planning

# Performance & Storage Classes

EFS 는 자주 access 하지 않는 파일을 주기적으로 EFS-IA (Infrequent access)로 이동시켜 비용 절감을 할 수 있다

1) EFS Scale

  - 1000s of concurrent NFS clients, 10 GB+/s throughput

  - Grow to Petabyte-scale network file system, automatically

2) Performance mode (set at EFS creation time)

  - General purpose (default): latency-sensitive use cases (web server, CMS, etc..)

  - Max I/O - higher latency, throughput, highly parallel (big data, media processing)

3) Storage Tiers (lifecycle management feature - move file after N days) ***

  - Standard : for frequently accessed files

  - Infrequent access(EFS-IA) : cost to retrieve files, lower price to store

[ EBS (Elastic Block System) vs EFS (Elastic File System)]

EBS 와 EFS 의 차이

1. EBS volumes

한번에 하나의 EC2 인스턴스에 마운트 가능

multi AZ 불가

AZ 간 마이그레이션을 원할 경우 snapshot 생성을 통해 가능

 - can be attached to only one instance at a time

 - are locked at the AZ level

 - IO1 : can increase IO independently

 - GP2 : IO increases if the disk size increases

To migrate an EBS volume across AZ

 - Take a snapshot

 - Restore the snapshot to another AZ

 - EBS backups use IO and you shouldn't run them while your application is handling a lot of traffic

Root EBS volumes instances get terminated by default if the EC2 instance gets terminated. (you can disable that)

2. EFS

100여개의 EC2 인스턴스에 마운트 가능

multi AZ 가능

Linux 인스턴스에만 사용 가능

EBS 보다 고성능/고비용

- Mounting 100s of instances across AZ

- EFS share website files (WordPress)

- Only for Linux Instances (POSIX)

- EFS has a higher price point than EBS

- Can leverage EFS-IA for cost saving