EC2 Placement groups
EC2 인스턴스가 AWS인프라에 배치되는 방식을 제어하고자 할 때 씀.
배치그룹을 사용하여 이러한 전략을 정의할 수 있다.
AWS의 하드웨어와 직접적인 상호 작용을 하지 않지만, EC2인스턴스가 각각 어떻게 비치되기를 원하는지 AWS에게 알려준다.
배치그룹을 만들 때 3가지 전략을 사용가능
1. Cluster
- 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화할 클러스터 배치 그룹이 있다.
- 인스턴스를 그룹화할 클러스터 배치 그룹이 있다.
이 전략은 높은 성능을 제공하지만 위험 또한 높다!
Cluster Placement group의 경우 모든 EC2 인스턴스가 동일한 rack에 있다!
즉, 동일한 하드웨어와 동일한 가용 영역에 있다는 것
아래 그림을 보면 모든 인스턴스는 동일한 하드웨어에 있다.
cluster placement group을 만들려고 하고 지연 시간이 매우 짧은 10gb속도 정도의 네트워크를 원하기 때문에 이들을 동일한 rack에 배치한다.
단점 : 랙에 실패가 발생하면 즉 하드웨어의 실패가 발생하면 모든 EC2 인스턴스가 동시에 실패한다.
그래서 전체 스택에 걸쳐 실패가 전파될 위험이 높다.
이렇게 위험이 높은 대신에 엄청난 네트워크를 얻을 수 있는 장점이 있다.
그래서 이 네트워크로 매우 빨리 완료되어야 할 빅데이터 작업을 수행할 수 있다.
또는 극히 짧은 지연 시간과 높은 네트워크 처리량을 필요로 하는 애플리케이션에 대한 요청이 있는 경우엔 이런 위험이 있어도 감수할 수도 있다.
결론 : 애플리케이션에 대해 매우 높은 대역폭과 짧은 지연 시간이 필요한 경우 클러스터 배치 그룹이 좋은 방법이 될 수 있다.
2. Spread
- 분산 배치 그룹은 인스턴스가 다른 하드웨어에 분산된다는 의미.
- 여기에는 가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다는 제한 사항이 있다.
- 따라서 크리티컬 애플리케이션이 있는 경우 분산 배치 그룹을 사용한다.
Spread placement group의 경우 실패 위험을 최소화하고자 한다.
이 경우 분산 배치 그룹으로 하게 되면, 모든 EC2 인스턴스가 다른 하드웨어에 위치하게 된다.
위 그림에서 보면 3개의 가용 영역과 6개의 EC2가 있고, 각 EC2인스턴스는 서루 다른 하드웨어에 있다.
장점 :
- 여러 가용 영역에 걸쳐 있을 수 있다.
- 동시 실패의 위험이 감소한다.
예를들면, hardware1이 실패하더라도 hardware2가 실패하지 않을 수 있다.
그래서 Us-east-1a에 있는 두 인스턴스가 동시에 실패할 위험을 분리했다.
단점 :
- 이 구성에서 배치 그룹의 가용 영역당 7개의 인스턴스로 제한이 된다는 점!
- 즉, 배치 그룹의 규모에 제한이 있다.
그래서 크기가 적당하지만 너무 크지 않은 그런 애플리케이션에서만 쓸 수 있다.
사용사례는 가용성을 극대화하고, 위험을 줄여야 하는 애플리케이션이다.
일반적으로는 각 인스턴스가 장애로부터 서로 격리되어야 하는 중요한(critical) 애플리케이션이다.
3. Partition
- 분할 배치 그룹은 분산 배치 그룹과 비슷하게 인스턴스를 분산하려는 것.
- 다만 이건 여러 파티션에 인스턴스가 분할되어 있고, 이 파티션은 가용 영역 내의 다양한 하드웨어 rack 세트에 의존한다.
- 즉, 인스턴스가 여전히 분산되어 있지만, 다른 실패?로부터 격리되지 않았다는 것이다.
- 하지만, 파티션은 다른 오류 파티션과 격리되어야 한다.
- 즉, 그룹당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고, 이를 통해 Hadoop, Cassandra, Kafka같은 애플리케이션을 실행할 수 있다!
여러 가용 영역의 파티션에 인스턴스를 분산할 수도 있다!
가용 영역당 최대 7개의 파티션이 있을 수 있다!
각 파티션에는 많은 EC2 인스턴스가 있을 수 있다!
위 그림에서는 첫 번째파티션 4개, 두 번째 4개, 세 번째 4개있다고 가정한다.
각 파티션은 AWS의 rack을 나타낸다.
파티션이 많으면 인스턴스가 여러 하드웨어 rack에 분산되어 서로의 rack 오류로부터 안전하다.
따라서 가용 영역당 최대 7개의 파티션이 있을 수도 있고, 이러한 파티션은 동일한 리전의 여러 가용 영역에 걸쳐 있을 수 있다. 설정으로 최대 수백 개 EC2 인스턴스를 얻을 수 있다.
이게 분산 배치 그룹유형과의 차이 이다!
인스턴스와 파티션은 다른 파티션의 인스턴스와 동일한 하드웨어 물리적 rack을 공유하지 않으므로, 각 파티션은 오류로부터 격리된다.
즉, 파티션이 하나가 다운되면 만약 Partition 2가 다운되면, Partition 1은 정상이어야한다.
이러한 EC2인스턴스가 어떤 파티션에 있는지 알기 위해 메타데이터 서비스르르 사용하여 이 정보에 액세스하는 옵션이 있다!
언제 분할 배치 그룹을 사용해야할까?
파티션들 전반에 걸쳐 데이터와 서버를 퍼뜨려 두도록 파티션 인식이 가능한 애플리케이션의 경우에 사용한다.
ex) HDFS, Hbase, Cassandra 및 Apache Kafka를 사용하여 파티션을 인식하는 빅 데이터 애플리케이션이 된다.
Elastic Network Interface (ENI)
ENI은 VPC의 논리적 구성 요소이며 가상 네트워크 카드(virtual network card)를 나타낸다.
ENI는 EC2인스턴스가 네트워크에 액세스할 수 있게 해준다.
ENI는 EC2인스턴스 외부에서도 사용된다.
ENI의 속성
- 주요 사설 IPv4와 하나 이상의 보조 IPv4를 가질 수 있다
- EC2에 보조ENI을 얼마든지 추가할 수 있다.
- 각 ENI는 private IPv4를 가지거나, Elastic IPv4를 가지거나 하나의 public IPv4를 가질 수 있음
- ENI에 하나 이상의 보안 그룹을 연결할 수도 있음
- Mac주소 및 기타 항목을 연결할 수도 있음.
EC2인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2인스턴스에서 이동시킬 수도 있다.
참고로 ENI는 특정 가용 영역 즉 AZ에 바인딩된다.
즉, 특정 AZ에서 ENI를 생성하면, 해당 AZ에만 바인딩 할 수 있다.
이 인스턴스에 다른 문제가 생겼는데, 또 다른 ENI가 연결되어 있다고 하자.
그러면, 첫 번째 EC2인스턴스에서 두 번째 EC2인스턴스로 Eth1을 옮겨서 private IP를 이동시킬 수 있다!
그러면 Private IP가 첫 번째 문제 인스턴스에서 두 번째 EC2 인스턴스로 연결되게 된다. 그러면 장애 조치에 매우 유용하다.
private 정적 IP로 EC2 인스턴스에 액세스하는 경우, 장애 조치를 위해 EC2 인스턴스간에 IP를 이동시킬 수 있다.
ENI에 대한 더 자세한 내용은 아래 AWS페이지에 자세히 설명되어있으니 참고하시면 됩니다!
https://aws.amazon.com/ko/blogs/aws/new-elastic-network-interfaces-in-the-virtual-private-cloud/
'AWS' 카테고리의 다른 글
| Route53을 활용해 도메인과 연결하고 ACM인증서 만들어보기 (0) | 2024.06.22 |
|---|---|
| AWS IAM서비스에서 그룹에 유저 추가하는 법 (1) | 2024.01.08 |
