[AWS] 스팟, IP, 배치그룹, ENI

EC2 spot instance 작동 과정

1. max spot price (spot instance에 대해 지불가능한 최대 spot 가격) 정의
2. 인스턴스의 spot 가격이 우리가 정한 max spot price보다 낮으면 해당 인스턴스 유지
2-1. hourly spot price: offer과 capacity에 따라 달라짐
2-2. 현재 spot 가격이 max spot price 초과할경우 1 인스턴스를 중지(stop)하고 spot 가격이 max spot price 아래로 내려가면 중단했던 곳부터 인스턴스 다시 시작 2 인스턴스에서 state가 필요하지 않다면 걍 인스턴스 끄면 (terminate) 됨. grace period 2분 주어짐,,
- batch 작업, 데이터분석, failure로부터 resilient(탄력있는) workload에서 쓰임
- 중요한 작업, DB에는 부적합

 

spot instance request 과정!!
1 spot request에서는 원하는 인스턴스 수, 최대 가격, 시작 사양 (AMI) 등을 정의
2 유효한 기간 정의(무한대도 가능)
3 request 유형: one time request/persistent request 선택
  - one time: spot req 완료되는 즉시 인스턴스 시작, 이후 request 사라짐
  - persistent: spot req가 유효한 기간 동안은 인스턴스들도 유효함 -> 인스턴스가 어떤 이유로든 중지되거나, spot price 기준으로 중단되는경우 요청이 다시 실행되고, 유효성이 확인되면 인스턴스가 다시 시작됨 -> 그래서 persistent 모드에서 인스턴스 중지했는데 spot req가 여전히 active할 경우, spot req는 자동으로 인스턴스를 다시 시작시킬만큼 똑똑함......

spot request 취소하려면 spot request가 open, active, 혹은 disabled 상태여야 함
spot instance 종료하려면
spot 요청 취소 -> 그다음에 관련 spot instances 종료해야됨!!!⭐️
왜냐하면, spot instance를 먼저 종료하면, AWS는 spot request로 다시 돌아가서 인스턴스 시작해버릴거임...

 

Spot Fleet
: Spot instance를 set단위로 정의 + On-Demand Instances (Optional)

- spot fleet은 내가 정의한 price constraints로 목표 용량 채우려고 할 것 (인스턴스 타입, OS, AZ 등 가능한 Launch pools를 정의

 -> fleet이 가장 적합한 launch pool 선택. 예산에 도달하거나 원하는 용량에 도달하면 instance 시작을 중지)

- ⭐️⭐️⭐️⭐️spot fleet에 spot instance를 할당하는 방법 유형⭐️⭐️⭐️⭐️
  1. lowestPrice: 가장 싼 pool에서 인스턴스 시작 (cost optimization 굿, short workload에 적합)
  2. diversified: 모든 pools에 걸쳐있음 (availability 굿, long workload에 적합. 한 pool이 사라져도 다른 풀은 여전히 활성화돼있기 때문)
  3. capacityOptimized: 원하는 인스턴스 수에 맞는 최적의 용량을 가진 pool 받음
  4. priceCapacityOptimized (recommended): 1 먼저 용량이 젤 큰 pools 선택 2 그중 가격이 젤 낮은 pool 선택 (대부분 workloads한테 최적)

=> spot fleet 정의하면 여러 개의 런치 풀과 여러 인스턴스 (할당) 유형 정의 가능!!!
=>> 결국 spot fleet에서 최저가 할인 또는 최저가 전략 선택하면, spot fleet이 자동으로 제일 싼 spot instance 요청함. Spot instance 기본으로 비용 절감 가능!!

 

간단한 spot instance 요청하는건 내가원하는 인스턴스 유형과 AZ를 정확히 알 때 하는 거고,
spot fleet 요청하는건 조건을 만족하는 모든 인스턴스 유형과 AZ를 선택하는 거임!!

 

 

Public IP와 Private IP (IPv4)
- 네트워크는 IPv4와 IPv6 두종료의 ip 있음
- IPv4: 1.160.10.240 (숫자 4개로 구성됨, 온라인에서 흔함)
- IPv6: 1900:4545:3:200:f8ff:fe21:67cf (숫자랑 문자열이 혼합된 긴 string형태, IoT에서 흔함)

IPv4
- IPv4는 0~255 사이 숫자 4개의 조합으로, 총 37억개 다른 주소가 나옴

 

Private vs Public IP 예시
- 서버끼리 통신할 때는 public ip 사용해서 통신함
- 회사 내에서 통신할 때는 private 네트워크를 사용하는데, private 네트워크 안의 모든 컴퓨터가 private ip 사용해 통신
- 하지만 회사에서 Internet Gateway (public ip)을 설치해 이용하게 되면, 이 컴퓨터들도 다른 서버들에 액세스하게 됨
=> public ip는 인터넷 전역에 액세스 가능, private ip는 private network 안에서만 액세스 가능

 

Public, Private ip 차이점!!!
Public IP:
- 기기가 인터넷상(www)에서 식별될 수 있음을 의미
- 각 공용 ip는 전체 웹에서 유일해야 함(두개의 머신이 같은 public ip 가질 수 없음!!!)
- public ip 있으면 그 ip의 geo-location 쉽게 찾을 수 있음

Private IP:
- private network 안에서만 기기 식별 가능
- ip가 private network 안에서만 유일한 거면 됨
- 하지만 두 개의 다른 회사는 같은 private ip를 가질 수 있음
- 기기가 private network에 있을 때 NAT 장치와 프록시역할을 할 internet gateway를 통해 인터넷에 연결됨
(프록시: 보안상의 이유로 직접 통신할 수 없는 두 점 사이에서 통신할 경우 중계기로서 대리로 통신)
(NAT: 라우터 등의 장비를 사용하여 다수의 사설 IP를 공인 IP 주소로 변환)
- 지정된 범위의 ip만 private ip로 사용될 수 있음

 

Elastic IP (탄력적 IP)
- EC2 인스턴스를 시작하고 중지할 때 public ip가 바뀜
- 인스턴스에 고정된 public ip를 사용하면 elastic IP가 필요할 것
=> public IPv4인데, 삭제하지 않는 한 계속 갖고있게 됨
- 한 번에 한 인스턴스에만 첨부 가능
- 한 인스턴스에서 다른 인스턴스로 빠르게 이동해서 인스턴스나 SW 오류를 마스킹할 수 있다 -> 되게 드문 경우임. 계정당 탄력적 ip를 5개만 쓸 수 있기 때문
- 되도록 쓰지 말자, 대신 임의의 public IP를 써서 DNS 이름을 할당하자. 혹은 load balancer를 써서 public ip를 아예 안 쓸 수도 있음

 

EC2의 경우

1. EC2는 디폴트로 내부 AWS 네트워크에는 private ip 사용하고, WWW에는 public ip를 사용
2. EC2 기기에 SSH를 할 때
  a. private ip 사용 불가 (vpn 쓰지 않는 이상 같은 네트워크에 있지 않으니까)
  b. 오직 public ip만 사용 가능
3. 내 기기가 멈췄다가 다시 시작하면 public ip가 바뀔 수 있음!!!

 

실습!!

• ssh -i EC2Tutorial.pem ec2-user@공용ip 쓰면 내 사설ip 이름으로 명령어 칠 수 있는거 확인가능
  
  • 하지만 ssh 연결할 때 private ip 쓸 수는 없음 -> AWS 사설 네트워크에 연결되어있는 상태가 아니고, 그냥 인터넷으로 AWS에 연결되어있는 상태이기 때문 -> public ip를 쓰면 public network에서 aws에 액세스 가능해서, public network가 인터넷 역할을 하게 되는 거임~!!
• 인스턴스 중지했다 다시 시작하면 Public ip 바뀜. 하지만 private ip는 그대로임 (바뀔 필요가 없기 때문)
• 만약 중지했다 다시 시작해도 public ip가 안 바뀌길 원하는 경우 -> elastic ip allocate 해서 해당 인스턴스에 associate해주면 됨

Placement Groups
: EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어 -> placement groups 사용을 정의함으로써 가능

Placement Group 만들 때 3가지 전략

1. Cluster: 한 AZ에서 latency 낮은 그룹 안으로 인스턴스 그룹화. performance 높지만 risk도 높음
2. Spread: 인스턴스를 HW에 분산시킴 (AZ별로 분산된 그룹당 최대 7개 인스턴스). 중요한 애플리케이션 있는 경우 사용
3. Partition: spread와 비슷. 여러 partition에 인스턴스가 나뉘어있고, 이 partition은 AZ 내의 다양한 HW rack 세트에 의존 -> 인스턴스가 여전히 분산되어 있지만, 다른 실패로부터 격리되지 않음 (하지만 partition은 다른 오류 partition과 격리되어야함). -> 그룹당 수백개의 EC2 인스턴스를 통해 확장가능하고, 이를 통해 Hadoop같은 애플리케이션을 실행할 수 있는 것

(rack: 서버 또는 네트워크 장비들을 넣어두는 철체 프레임)

 

1. Cluster
: 모든 EC2 인스턴스가 같은 rack 안에 있음 -> 같은 HW와 같은 AZ에 있다는 뜻

장점: 네트워크 성능 굿 (latency 매우 짧음. Bandwidth: 10 Gbps)
단점: rack에 fail 생기면 모든 인스턴스가 동시에 fail됨. 전체 스택에 걸쳐 fail이 퍼질 위험부담 큼

use case:

• 빨리 끝내야 하는 빅데이터 작업
• low latency와 high network throughput(처리량) 필요한 애플리케이션

2. Spread
: 모든 EC2 인스턴스가 다른 하드웨어에 위치

장점: 여러 AZ에 걸쳐있음, 동시 실패의 위험 낮음 (HW1이 실패해도 HW2는 돌아갈거니까)
단점: placement group의 AZ당 7개 인스턴스만 사용 가능⭐️ (너무 큰 애플리케이션은 사용불가)

use case:

• high availability, low risk 필요한 애플리케이션
• 인스턴스 오류를 서로 격리해야하는 중요한 애플리케이션
  
  

3. Partition
: AZ의 partition에 인스턴스를 분산 가능. AZ당 7개까지 partition 생성 가능.

 

• 각 partition은 AWS의 rack을 나타냄. 파티션이 많으면 각 인스턴스가 여러 HW rack에 분산되어 서로 rack 실패로부터 안전
• 이런 Partition은 동일한 region의 여러 AZ에 걸쳐 있을 수 있어, 최대 수백 개 EC2 인스턴스를 얻을 수 있음
• 파티션 속 인스턴스는 다른 파티션과 rack을 공유하지 않음 -> partition 2가 실패해도 partition 1, 3 등은 멀쩡하단 뜻
• EC2 인스턴스는 metadata로 partition 정보 접근 가능

use case:
partitions 전반에 걸친 데이터와 서버를 퍼뜨리도록 partition 인식 가능한 애플리케이션 (HDFS, HBase, 카산드라, 카프카)

 

Elastic Network Interface (ENI)
: VPC (AWS Virtual Private Cloud)의 논리적 component, virtual network card를 나타냄. EC2 인스턴스가 네트워크에 액세스할 수 있게 해줌

- ENI의 속성:

1. primary private IPv4와 하나 이상의 secondary IPv4를 가질 수 있음 (한 인스턴스에 여러 보조 ENI 추가해서 여러 private IPv4 사용 가능) -> public IPv4 1개, private IPv4 1개이상 이렇게 갖게 됨
2. 각 ENI는 private IPv4당 Elastic IPv4를 갖거나 하나의 public IPv4를 가질 수 있으므로, private 및 public ip가 하나씩 나옴
3. ENI에 하나 이상의 security group 연결 가능
4. Mac 주소 연결 가능

- EC2 인스턴스와 독립적으로 생성된 ENI를 장애 조치를 위해 즉시(on the fly) 옮겨서 그 인스턴스로 연결 가능. 예를들어 인스턴스1에 Eth0과 Eth1이라는 ENI가 붙어있고 인스턴스2에 Eth0가 붙어있었는데 인스턴스2에 문제가 생기면, 인스턴스1의 Eth1을 옮겨와서 인스턴스2에 붙이고, Eth1의 private ip 사용 가능 -> failover (장애 조치)에 매우 유용!!

- 특정 AZ에 바인딩됨 (특정 AZ에서 ENI 만들면 거기서만 바인딩 가능)