[3일차] EC2 SAA 레벨, EC2 인스턴스 스토리지

프라이빗 vs 퍼블릭 vs 탄력적 IP

public IP

공용 IP를 통해 다른 서버와 통신할 수 있다. 인터넷 전역에 접속할 수 있다.
전체 웹에서 유일한 것으로 같은 공용 IP를 가질 수 없다.

private IP

사설 IP는 사설 네트워크 안에서 통신할 때 사용한다. 외부와는 통신이 어렵다.

하지만, 인터넷 게이트웨이를 이용하게 되면 사설 네트워크에 있는 인스턴스도 다른 서버에 접속할 수 있게 된다.
사설 네트워크 안에서만 IP가 유일하면 된다. 지정된 범위의 IP만 사설 IP로 사용될 수 있다.

Elastic IP

인스턴스에 고정된 공용 IP를 사용하려고 하면 탄력적 IP가 필요하다.
계정당 탄력적 IP를 5개만 쓸 수 있다. 탄력적 IP는 사용하지 않는 것이 좋다.

대신 임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋습니다
또는 로드 밸런서를 사용해서 공용 IP를 전혀 사용하지 않을 수 있다.

Placement Groups

EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할 때 사용한다.

• 배치 그룹을 만들 때 사용하는 전략
  • Cluster(클러스터) 단일 가용 영역 내에서 지연 시간이 짧은 설정으로 인스턴스를 그룹화한다.
    
  • Spread(분산 배치) 인스턴스가 다른 하드웨어에 분산된다. 가용 영역별로 7개의 EC2 인스턴스만 가질 수 있다. 중요한 애플리케이션이 있는 경우 분산 배치 그룹을 사용한다.
    
  • Partition(분할 배치) 분산 배치와 비슷하게 인스턴스를 분산한다. 분할 배치는 여러 파티션에 인스턴스가 분할되어 있고, 이 파티션은 가용 영역 내의 다양한 랙(하드웨어) 세트에 의존한다. Hadoop, Cassandra, Kafka와 같은 애플리케이션을 실행할 수 있다.

Cluster

모든 EC2 인스턴스가 동일한 랙에 있다. → 동일한 하드웨어와 동일한 가용 영역에 있다.

• 장점
  엄청난 네트워크를 얻을 수 있다.
  빨리 완료되어야 하는 빅데이터 작업을 수행할 수 있다.
  짧은 지연 시간과 높은 네트워크 처리량을 필요로 하는 경우에 사용한다.

• 단점
  랙에 실패가 발생하면(하드웨어에 실패가 발생하면) 모든 EC2 인스턴스가 동시에 실패한다.
  전체 스택에 걸쳐 실패가 전파될 위험이 있다.
  

Spread

모든 EC2 인스턴스가 다른 하드웨어에 위치하게 된다.

• 장점
  여러 가용 영역에 걸쳐 있을 수 있어서 동시 실패 위험을 최소화할 수 있다.
  가용성을 극대화하고 위험을 줄여야 하는 애플리케이션에서 사용한다.
  → 크리티컬 애플리케이션

• 단점
  가용 영역당 7개의 인스턴스로 제한된다. → 배치 그룹의 규모에 제한이 있다.
  크기가 적당하지만 너무 크지 않은 애플리케이션에서만 쓸 수 있다.

Partition

여러 가용 영역의 파티션에 인스턴스를 분산할 수 있다. 가용 영역당 최대 7개의 파티션이 있을 수 있다.

• 장점
  각 파티션은 AWS의 랙을 나타낸다. 파티션이 많으면 인스턴스가 여러 하드웨어 랙에 분산되어 서로 랙 실패로부터 안전하다.
  파티션을 인식하는 빅데이터 어플리케이션에서 사용된다.

Elastic Network Interfaces(ENI)

VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타낸다.

ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해준다.

• 특징
  • 주요 사설 IPv4와 하나 이상의 보조 IPv4를 가질 수 있다.
  • 각 ENI는 사설 IPv4당 탄력적 IPv4를 갖거나 하나의 공용 IPv4를 가질 수 있다.
  • ENI에 하나 이상의 보안 그룹을 연결할 수 있다.
  • EC2 인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2 인스턴스에서 이동시킬 수 있다.
  • ENI는 특정 가용 영역 즉 AZ에 바인딩된다.

EC2 Hibernate(절전모드)

인스턴스를 중지 또는 종료

• 인스턴스 중지 EBS 디스크 데이터는 다시 시작할 때까지 그대로 유지된다.
  
• 인스턴스 종료 루트 볼륨이 삭제되게 했다면 인스턴스도 삭제된다. 하지만 그렇게 설정하지 않은 다른 볼륨은 인스턴스가 종료되더라도 그대로 남는다.
  

인스턴스 시작

1. 운영 체제가 부팅되기 시작한다.
2. EC2 사용자 데이터 스크립트가 실행된다.
3. 운영 체제가 부팅이 완료되고 애플리케이션도 실행되고 캐시도 구성되기 시작한다.
   ➡️ 시간이 오래 걸린다.

절전모드(Hibernate)

인스턴스가 절전 모드가 되면
RAM에 있던 인 메모리 상태는 그대로 보존된다. → 인스턴스 부팅이 더 빨라진다.
운영 체제를 완전히 중지하거나 다시 시작하지 않고 그대로 멈춰둔다.

• 사용 사례
  • 오래 실행되는 프로세스를 갖고 있고 중지하지 않을 때
  • RAM 상태를 저장하고 싶을 때
  • 빠르게 재부팅을 하고 싶을 때
  • 서비스 초기화가 시간을 많이 잡아먹어 서비스가 중단 없이 인스턴스를 절전 모드로 전환하고 싶을 때

EBS Volume

“network USB stick”

EBS(Elastic Block Store)로 인스턴스가 실행되는 동안 연결 가능한 네트워크 드라이브이다.

EBS 볼륨을 사용하면, 인스턴스가 종료된 후에도 데이터를 지속할 수 있다.

CCP 레벨의 EBS 볼륨은 한번에 하나의 인스턴스에만 마운트될 수 있다.

EBS 볼륨 생성은 특정 가용 영역에서만 가능하다. EBS 볼륨이 us-east-1a에서 생성된 경우 us-east-1b에는 연결이 불가능하다.

볼륨이기 때문에 용량을 미리 결정해야 한다.

꼭 EC2 인스턴스에 연결될 필요는 없다.

Delete on Termination attribute

EC2 인스턴스를 생성할 때 콘솔에서 EBS 볼륨을 생성하면 삭제 옵션이 있다.

기본 설정으로는 루트 볼륨에 체크되어 있고 새로운 EBS 볼륨에는 체크가 되어 있지 않다.

체크가 되어 있으면, 인스턴스 종료와 함께 EBS 볼륨이 삭제 된다.

• 실제 사용 예시
  인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우
  데이터를 저장하고자 하는 등의 경우
  ➡️ 루트 볼륨의 종료 시 삭제 속성을 비활성화 한다.

EBS Snapshots

: EBS 볼륨의 특정 시점에 대한 백업

다른 가용영역이나 다른 리전에도 복사할 수 있다.

EBS 스냅샷 기능

• EBS Snapshot Archive
  최대 75%까지 저렴한 아카이브 티어로 스냅샷을 옮길 수 있는 기능이다.
  스냅샷을 아카이브 티어로 옮기면 아카이브를 복원하는 데 24시간에서 최대 72시간이 걸린다. 즉시 복원되지 않는다.

• Recycle Bin for EBS Snapshots
  EBS 스냅샷을 삭제하는 경우 영구 삭제하는 대신에 휴지통에 넣을 수 있다.
  실수로 삭제하는 경우, 휴지통에서 복원할 수 있다.
  휴지통에 보관되는 기간은 1일에서 1년 사이로 설정할 수 있다.

• Fast Snapshot Restore(FSR)
  빠른 스냅샷 복원이다.
  스냅샷을 완전 초기화해 첫 사용에서의 지연 시간을 없애는 기능이다.
  스냅샷이 아주 크고 EBS 볼륨 또는 EC2 인스턴스를 빠르게 초기화해야 할 때 유용하다.
  대신 비용이 많이 든다.

AMI

AMI는 ‘Amazon Machine Image'를 뜻하는 말로, EC2 인스턴스를 통해 만든 이미지를 의미한다.
AMI로 AWS를 구축할 수도 있고, 원하는 대로 변경할 수도 있다.
EC2 인스턴스에 설치하고자 하는 모든 소프트웨어를 AMI가 미리 패키징해준다.
AMI를 특정 지역에 구축한 다음 다른 지역으로 복사해서 AWS의 글로벌 인프라를 활용할 수도 있다.

EC2 인스턴스 실행 방법

• Public AMI
• 직접 AMI 만들기
• AWS Marketplace AMI 사용하기

AMI process

1. EC2 인스턴스를 원하는대로 설정한다.
2. 인스턴스를 중지해 데이터 무결성을 확보한다.
3. 이 인스턴스를 바탕으로 AMI를 build한다. 여기에서 EBS 스냅샷이 생성된다.
4. 다른 AMI에서 인스턴스를 실행한다.
   

EC2 Instance Store

EC2 인스턴스는 가상머신이지만 실제로는 하드웨어 서버에 연결되어 있다. 이런 서버는 해당 서버에 물리적으로 연결된 디스크 공간을 가진다.
➡️ 이를 EC2 인스턴스 스토어라고 부른다.

EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용할 수 있다.

주의할 점은 EC2 인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실된다. 장기적으로 데이터를 보관할 수 없다.
➡️ 버퍼, 캐시, 스크래치 데이터나 임시 콘텐츠를 사용하는 경우 적합하다.

EC2 인스턴스가 연결된 하드웨어에 장애가 발생하면 데이터 손실에 대한 위험이 존재한다.
따라서 EC2 인스턴스 스토어를 사용할 때에는 데이터를 백업해 두거나 복제해 둬야 한다.

EBS Volume Types

1. gp2/gp3(SSD)
   범용 SSD 볼륨으로 다양한 워크로드에 대한 가격과 성능의 절충안이 된다.

2. io1/io2(SSD)
   최고 성능을 자랑하는 SSD 볼륨
   지연시간이 낮고, 대용량 워크로드에 사용된다.
   

3. st1(HDD)
   저비용의 HDD 볼륨
   잦은 접근과 처리량이 많은 워크로드에 사용된다.
   

4. sc1(HDD)
   가장 비용이 적게 드는 HDD 볼륨
   접근 빈도가 낮은 워크로드에 사용된다.

EC2 인스턴스에는 gp2/gp3와 io1/io2만이 부팅 볼륨으로 사용될 수 있다. 루트 OS가 실행될 위치에 해당한다.

General Purpose SSD

짧은 지연 시간을 자랑하며 효율적인 비용의 스토리지이다.

시스템 부팅 볼륨, 가상 데스크톱, 개발, 테스트 환경에서 사용할 수 있다.

크기는 1GB에서 16TB까지 다양하다.

• gp2
  오래된 버전의 볼륨
  최대 3,000 IOPS
  볼륨과 IOPS가 연결되어 있다.

• gp3
  최신 세대의 볼륨
  기본 성능으로 3,000 IOPS와 초당 125MB의 처리량을 제공한다.
  각각 IOPS는 최대 16,000, 처리량은 1,000MB/s까지 증가시킬 수 있다.
  ➡️ 연결되어 있지 않다.
  

Provisioned IOPS(PIOPS) SSD

IOPS 성능을 유지할 필요가 있는 주요 비즈니스 애플리케이션이나 16,000 IOPS 이상을 요하는 애플리케이션에 적합하다.

일반적으로 데이터베이스 워크로드에 적합하다.

gp2 또는 gp3 볼륨에서 io1 또는 io2 볼륨으로 바꾸는 것이 좋다.

io2를 사용하는 것이 더 합리적이다.

Hard Disk Drives(HDD)

부팅 볼륨일 수 없다.
최대 16TB까지 확장되며 두 가지 종류의 볼륨을 제공한다.

• st1
  빅데이터나 데이터 웨어하우징 로그 처리에 적합하다.
  최대 처리량은 초당 500MB 그리고 최대 IOPS는 500이다.

• sc1
  아카이브 데이터용
  접근 빈도가 낮은 데이터에 적합하다.
  최저 비용으로 데이터를 저장할 때에 사용한다.
  최대 처리량은 초당 250MB 최대 IOPS도 250이다.
  

32,000 IOPS 이상을 요할 때에는 io1 또는 io2 볼륨의 EC2 Nitro가 필요하다.

EBS Multi-Attach - io1/io2 family

하나의 EBS 볼륨을 같은 가용 영역에 있는 여러 EC2 인스턴스에 연결할 수 있게 해준다.

EBS 볼륨 중 io1과 io2 제품군에서만 사용할 수 있는 기능이다.

각 인스턴스는 고성능 볼륨에 대한 읽기 및 쓰기 권한을 전부 가진다. 동시에 읽고 쓸 수 있다.

• 사용 사례
  애플리케이션 가용성을 높이기 위해 Teradata처럼 클러스터링된 Linux 애플리케이션
  애플리케이션이 동시 쓰기 작업을 관리해야 할 때 사용한다.
  

다중 연결 기능은 해당 가용 영역 내에서만 사용할 수 있다. 한 AZ에서 다른 AZ로 EBS 볼륨을 연결할 수 없다.
다중 연결은 한 번에 16개의 EC2 인스턴스만 같은 볼륨에 연결할 수 있다.

Amazon EFS - Elastic File System

EFS는 관리형 NFS 즉, 네트워크 파일 시스템입니다

여러 EC2 인스턴스에 마운트될 수 있고 이 EC2 인스턴스들은 여러 가용 영역에 있을 수 있다.

가용성이 높고 확장성도 높다. 가격도 비싸다.(gp2 EBS 볼륨의 3배)

➡️ 모든 인스턴스를 EFS를 통해 같은 네트워크 파일 시스템에 동시에 연결할 수 있다.

• 사용 사례
  웹 서버, 데이터 공유, WordPress
  

내부적으로는 NFS 프로토콜을 사용한다.

EFS에 대한 액세스를 제어하기 위해서는 보안 그룹을 설정해야 한다.

Windows가 아닌 Linux 기반 AMI와 호환된다.

KMS를 사용해 EFS 드라이브에 저장 데이터 암호화를 활성화할 수 있다.

미리 용량을 계획하지 않아도 된다. 파일 시스템이 자동으로 확장되고 사용량에 따라 요금을 지불한다. 사용한 GB당 데이터 비용을 지불한다.

EFS 성능

• EFS Scale
  수천 개의 NFS 클라이언트에서 EFS에 동시 액세스할 수 있게 확장된다.
  처리량은 초당 10GB

• Performance mode
  용량을 미리 프로비저닝하지 않아도 네트워크 파일 시스템이 자동 확장된다.
  

• General purpose
  기본 설정으로 지연 시간에 민감한 웹 서버, CMS와 같은 곳에서 사용한다.
  

• Max I/O
  I/O를 최대화하고 싶을 때 사용한다.
  지연 시간, 처리량 병렬 처리 성능이 향상된다.
  파일 시스템에 빅 데이터나 미디어 처리 작업이 있을 때 유용하다.
  

• Throughput mode

  • Bursting 기본값 파일 시스템 크기와 비례한 용량을 가진다.
    
  • Provisioned 버스팅 모드에서는 사용 공간이 많을수록 버스팅 용량과 처리량이 늘어나는데 프로비저닝 모드에서는 스토리지 크기에 상관없이 처리량을 설정할 수 있다.
    

EFS - Storage Classes

• 스토리지 계층
  일정 기간 후에 파일을 다른 계층으로 옮긴다.
  • Standard
    액세스가 빈번한 파일
  • Infrequent access(EFS-IA)
    파일을 검색할 경우 검색에 대한 비용이 발생한다.
    하지만 EFS-IA에 파일을 저장하는 비용은 낮다.

• 가용성과 내구성 측면 옵션
  • Standard EFS를 다중 AZ에 설정한다. 프로덕션 사용 사례에 적합하다.
    
  • One Zone EFS를 하나의 AZ에 설정한다. 개발할 때 좋다. 백업이 기본적으로 활성화된다. EFS-IA 스토리지 계층과 호환 된다.