Elastic IPs

• 기본적으로, EC2 인스턴스를 시작하고 중지할 때 퍼블릭 IP는 변화한다.
• 만약 고정된 공공 IP를 사용하고 싶다면 Elastic IP를 사용할 수 있다.
• 이는 퍼블릭 IP이며 지우지 않는 이상 계속 갖고 있게 된다.
• 한 인스턴스 당 하나만 attatch할 수 있다.
• Elastic IP는 사용자 계정의 다른 인스턴스로 주소를 빠르게 remapping해서 인스턴스나 소프트웨어의 오류를 숨길 수 있다.
  - 하지만 이는 상당히 드문 케이스다.
• 사용자는 한 계정 당 5개의 Elastic IP를 가질 수 있다.
• 전반적으로, Elastic IP를 사용하지 않는 것이 좋다.
  - 잘못된 아키텍쳐 결정을 반영하기도 한다.
  - 대신, 공공 IP를 사용해야 하며 여기에 DNS를 할당하는 것이 좋다.
  - 또한, 공공 IP를 사용하지 않고 로드 밸런서를 사용할 수도 있다.
  
• SSH로 EC2 머신에 접근하기 위해서는 공공 IP로 접근해야 한다. 왜냐하면 사적 IP는 개인 네트워크에 속해 있기 때문이다.
  - 즉, 사용자가 AWS와 인터넷으로 연결되어 있기 때문이다.
  - EC2를 중단 후 다시 시작하면 공공 IP는 바뀌지만 사적 IP는 바뀌지 않는다. 왜냐하면 그럴 필요가 없기 때문!

Elastic IP 생성하기

• 생성 방법은 간단하다. 좌측의 Elastic IP address 메뉴에서 Allocate Elastic IP address를 클릭하면 추가 설정할 필요 없이 생성이 가능하다.
• Elastic IP를 생성한 후 사용하지 않으면 요금이 부과된다.
• 생성 후 Actions > Associate Elastic IP address를 클릭한다.
  (아래 IP 주소는 임시 주소로 생성한 것이며 현재 사용 불가)
  
  - Resource type에서 해당 IP를 어디에 attatch할 지(인스턴스/네트워크 인터페이스)를 골라야 한다.
  
  

EC2 배치 그룹(Placement Groups)

• EC2 인스턴스를 어떻게 배치되어야 하는 지를 조정할 때 사용한다.
• 3가지 전략이 있다.
  - Cluster: 인스턴스들을 하나로 묶어서 하나의 AZ에서 저지연 하드웨어 설정을 해줄 수 있다(고성능이지만 위험하다).
  - Spread: 사용자의 인스턴스가 다른 하드웨어 너머로 퍼질 것이라는 의미로, 사용자의 AZ에 퍼져 있는 배치 그룹 당 최대 7개의 인스턴스만 가질 수 있으며 중요한 앱이 있는 경우에 사용하기에 좋다(높은 가용성을 통한 빠른 장애조치).
  - Partition: 인스턴스에 spread 한다는 점에서 스프레드와 유사하지만 이 경우 다른 여러 파티션으로 퍼진다. 해당 partition들은 AZ 내에서 여러 다른 하드웨어 racks에 의존한다.
  • 즉, 퍼져 있지만 특정 인스턴스에 실패가 있다면 파티션 내의 다른 인스턴스들도 영향 받는다(그러나 파티션끼리는 고립되어 있어 영향을 주지 않는다).
  • 그룹 당 수백개의 EC2 인스턴스까지 스케일 할 수 있다(이 방법으로 하둡, Cassandra, Kafka를 실행할 수 있다.).

Cluster

• 인스턴스들이 같은 랙 내에 있다.
  - 이는 같은 하드웨어에 있다는 뜻이며, 또한 같은 AZ 내에 있다는 뜻이다.
• 장점: 향상된 네트워킹(인스턴스끼리 10Gbps bandwith)
• 단점: rack에 fail이 있으면 모든 인스턴스에 실패가 전파된다.
• 사용 예시
  - 빅데이터 업무(빠르게 끝내야 하는)
  - 저 지연/ 고 성능 네트워크가 필요한 애플리케이션

Spread

• 여기서는 실패 위험을 최소화 해야 한다.
• 모든 EC2 인스턴스들은 서로 다른 하드웨어에 위치한다.
• 장점
  - 여러 AZ에 걸쳐 있을 수 있다.
  - 동시에 실패할 확률이 줄어든다.
• 단점
  - 배치 그룹 당 AZ 당 7개의 인스턴스만 가질 수 있다.
  - 즉, 배치 그룹 사이즈에 제한이 있다.
• 사용 예시
  - 고 가용성을 가지며 위험이 낮아야 하는 애플리케이션
  - 실패가 서로 고립되어 있어야 하는 중요한 애플리케이션

Partition

• 여러 개의 AZ에서 구획을 넘어 펼쳐진 인스턴스들을 갖게 된다.
• AZ 당 7개의 partition까지 가질 수 있다.
  - 파티션은 수백 개의 인스턴스를 가질 수 있다(스프레드와의 차이점).
• 각 partition은 AWS의 rack을 의미한다.
  - 많은 partition을 가짐으로써 사용자는 인스턴스가 여러 하드웨어 rack에 분산되도록 할 수 있고 하나의 rack 실패로부터 다른 rack은 보호받을 수 있다.
• 파티션이 다르면 서로 다른 하드웨어와 서로 다른 rack을 사용한다.
  - 따라서 각 partition은 서로 고립되어 있다.
• 사용자는 메타 데이터를 이용해 파티션 별로 설정된 정보에 접근할 수 있다.
• 사용 예시
  - 구획을 인식하는 빅 데이터 앱
  - HDFS, Hbase, Cassandra, Apache Kafka
  

아래에서 배치 그룹 전략을 선택할 수 있다.

• 여기서 배치 그룹을 생성한 후 인스턴스 생성시 만들어진 배치 그룹에 인스턴스를 추가하도록 설정할 수 있다.

EC2 고급 기능

Elastic Network Interfaces(ENI)

• VPC 내의 논리적인 컴포넌트이며 가상 네트워크 card를 의미한다.
• 이를 통해 EC2 인스턴스에 네트워크 접근 권한을 부여하지만 EC2 인스턴스 외부에서 사용된다.
• ENI를 독립적으로 생성해 EC2 인스턴스에 부착할 수 있으며 또한 장애 조치를 위해 EC2 인스턴스에서 뗄 수도 있다.
  - 떼어서 다른 EC2 인스턴스로 옮길 수 있다.
• 특정 AZ에 묶여 있으므로 AZ를 특정한 ENI를 생성할 수 있다.
• ENI를 이용하면 사적 IP, 그리고 네트워킹을 더 많이 제어할 수 있다.

속성

• Primary private IPv4 + 하나 이상의 secondary IPv4
• 하나의 private IPv4 당 하나의 Elastic IP(primary), 그리고 하나의 public IPv4 당 하나의 Elastic IP(secondary)를 갖는다.
• ENI는 하나 이상의 security groups를 갖는다.
• 맥주소를 갖는다.

생성 실습

• EC2 인스턴스 생성할 때 ENI를 함께 생성할 수 있다.
  - 이 경우, 콘솔에서 해당 ENI와 attatch된 인스턴스들을 삭제하면 해당 ENI 역시 삭제 된다.
  - 반면, ENI 메뉴에서 ENI를 따로 생성해 인스턴스를 attatch할 경우 인스턴스 삭제시 ENI는 삭제되지 않는다.
  
• EC2 생성시 ENI를 생성하는 이유는 private IP를 인스턴스 별로 옮길 수 있도록 해 빠르게 장애조치를 하기 위함이다(장애가 난 인스턴스에서 private IP를 떼서 정상 작동하고 있는 인스턴스에 붙이면 된다).
• 아래와 같이 하나의 인스턴스에 두 개의 ENI를 부착할 수 있으며 그러면 해당 인스턴스는 두 개의 private IP를 갖게 된다.
  

EC2 Hibernate

• Hibernate 기능은 최대 절전 모드로, 이를 이용하면 인스턴스를 중단해도 메모리 내 모든 상태가 보존된다.
  - 즉, RAM에 있는 모든 데이터가 보존 된다.
• 만약 인스턴스를 재시작 한다면 인스턴스 부팅이 훨씬 빠를 것이다.
  - 왜냐하면, OS는 중지되거나 다시 시작한 적이 없기 때문이다(메모리 보존).
• 실제로는, RAM의 전체 상태가 루트 EBS 볼륨에 파일로 덤핑 된다.
  - 따라서, 루트 EBS 볼륨은 암호화 되어야 한다.
  

• 위 과정을 보면, RAM에는 암호화된 EBS root volume이 있다.
• 만약 우리가 이를 멈추고 최대 절전 모드(hibernate)로 전환하면 RAM은 root EBS 볼륨에 파일로 덤프 된다.
• 다시 EC2를 시작할 경우 root EBS 볼륨에 있던 RAM은 인스턴스의 RAM으로 이동하며 이후 인스턴스는running 상태가 된다.
• 사용 예시
  - 장기 실행 프로세스를 계속 실행하려는 경우
  - RAM 상태를 저장하려는 경우
  - 초기화(부팅) 하는 데 시간이 많이 걸리는 서비스

이 기능을 사용 가능할 수 있는 인스턴스 종류

• 현재는 C3, C4, C5, M3, M4, M5, R3, R4, R5(C, M, R) 인스턴스에서만 사용 가능하다.
• 인스턴스의 RAM 사이즈가 150 GB보다 작아야 한다.
• bare metal 인스턴스에는 적용 불가능하다.
• AMI: Amazon Linux 2, Liinux AMI, Ubuntu & Windows
• Root Volume: EBS여야 하며 암호화될 수 있고 RAM 사이즈의 덤프를 지원할 만큼 커야 한다.
• 스팟 인스턴스에서는 사용 불가능하다.
• 60일 이상 Hibernate 모드를 사용할 수 없다.

실습

• 인스턴스 생성시 Hibernate behavior 설정이 가능하다.
• 실습용으로 사용되는 t2.micro는 1GB RAM을 가지기 때문에 사용이 가능하다.

EC2 Nitro

• 차세대 EC2 플랫폼의 이름이 Nitro이다.
• 새로운 virtualization 기술이다.
• 기존보다 더 나은 performance를 보인다.
  - 향상된 네트워킹 옵션을 가진다(향상된 네트워킹, HPC, IPv6)
  - 더 빠른 처리 속도의 EBS 볼륨 제공(64000 IOPS의 EBS 볼륨을 원한다면 Nitro가 필요하다/ 반면 최대 32000의 IOPS를 원한다면 Nitro를 사용할 필요가 없다)
  - 향상된 보안
• 사용 가능한 인스턴스 타입
  - Virtualized 된 어떤 것이든 가능하다.
  - 또한, 새로 나온 인스턴스는 EC2 Nitro가 내장되어 있다.
  - bare metal 또한 사용 가능하다.

vCPU

• 한 CPU(코어)에서 여러 개의 스레드를 실행할 수 있는데(multi-threading) 이 때 코어의 수 X 스레드의 수가 vCPU이다.
  - 만약, 한 CPU에서 실행 되는 두 개의 스레드가 있다면 각 스레드는 vCPU(virtual CPU)이다.
• 예를 들어, m5.2xlarge 인스턴스를 런칭할 경우
  - 얻을 수 있는 CPU는 4개이다.
  - CPU 당 2개의 스레드를 가지며 총 8개의 스레드가 된다.
  • 즉, 8개의 vCPU를 갖게 된다.

Optimizaing CPU Options

가끔씩 vCPU 옵션을 변경하고 싶을 때가 있는데(가령, 너무 많은 CPU를 할당해 인스턴스를 시작했을 경우) 만약 vCPU를 반으로 줄이고 싶다면?

사용하려는 인스턴스 유형이 4개의 코어에 스레드 2개씩 갖고 있는 상황이라고 가정하자(8vCPU).

• CPU core 수를 줄인다: 고사양 램 + 조금 더 적은 수의 CPU를 원할 경우
  - 인스턴스의 컴퓨팅 성능은 낮아지지만 앱의 워크로드에 적합한 것은 더 많은 메모리일 수 있다.
  - lincensing costs를 줄이는 데 유용하다.
• Core 당 스레드 수를 줄인다: 만약 고성능 컴퓨팅을 원할 경우(HPC 워크로드) 코어 당 하나의 스레드만 갖는 것이 낫다.

이는 인스턴스 런치 시에 CPU 옵션 지정으로 변경할 수 있다.

Capacity Reservations(용량 예약)

• 이는 추가 용량을 미리 계획하기 위해 사용한다.
• 1년 또는 3년 사용을 약정할 필요가 없으며 그냥 용량 예약을 다시 지정하기만 하면 된다.
• 시작 되자마자 요금 청구서를 받게 된다.
• Savings Plans와 결합해 비용을 절감할 수 있다.
• 만약 특정 기간에 특정 유형의 AZ에서 인스턴스를 시작할 수 있을지 미리 확인해야 하는 경우 EC2 용량 예약을 사용하는 것이 좋다.

오답 노트