#0 Placement Groups (배치 그룹)
Placement Group(배치 그룹)은
EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할 때 쓴다.
=> AWS의 하드웨어와 직접적인 상호 작용은 하지 않지만 EC2 인스턴스가 각각 어떻게 배치되기를 원하는지 AWS에서 알려주는 것이다.
배치 그룹을 만들 때 세 가지 전략을 세울 수 있다.
⭐Cluster (클러스터 배치그룹), Spread (분산 배치 그룹), Partition (분할 배치 그룹)⭐
밑에서 더 자세히 알아보자
1. Cluster (클러스터 배치그룹) : 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화한다.
=> 이 전략은 높은 성능을 가지고 있긴 하지만 위험이 높다
클러스터 배치그룹은 이런 식으로 모든 EC2 인스턴스가 동일한 랙(Rack)에 있는 것,
즉 동일한 하드웨어/가용영역에 있는 것이다.
장점은 같은 랙에 있기 때문에 지연시간이 매우 짧은 10GB정도의 속도를 내게 되는데
단점은 랙에 실패(하드웨어 실패)가 발생하면 모든 EC2 인스턴스가 동시에 실패한다는 것이다..👎
=> 즉, 극히 짧은 지연 시간과 높은 네트워크 처리량을 필요로 하는 애플리케이션 작업에 적절하다.
(엄청 빨리 끝내야 할 빅데이터 작업을 수행하기에 적절)
2. Spread (분산 배치 그룹) : 인스턴스가 다른 하드웨어에 분산된다는 의미
가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다는 제한 사항이 있다.
=> 따라서 (터질 위험 있는)크리티컬 애플리케이션이 있는 경우 이 전략을 사용
분산 배치 그룹은 클러스터 배치 그룹과 완전히 반대이다.
위에서도 조금 언급했듯이 분산 배치 그룹은 실패 위험을 최소화하려는 전략으로 모든 EC2 인스턴스가 다른 하드웨어에 위치하게 된다.
=> 장점은 여러 가용 영역에 걸쳐 있을 수 있고 동시 실패의 위험이 현저히 내려간다.
=> 단점은 배치 그룹의 가용 영역당 7개의 인스턴스로 제한이 되니 배치 그룹의 규모에 제한이 있는 것이다.
(너무 크지 않은 적당한 크기의 애플리케이션만 쓸 수 있다)
3. Partition (분할 배치 그룹) : 분산 배치 그룹과 비슷하게 인스턴스를 분산하려는 것인데 이건 여러 파티션에 인스턴스가 분할되어 있고 이 파티션 자체가 가용 영역 내의 다양한 하드웨어 Rack(랙) 세트에 의존한다.
=> 즉 인스턴스가 여전히 분산되어 있지만 다른 실패로부터 격리되지 않았다는 것
=> 그룹 당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고 Hadoop, Cassandre, Kafka 같은 애플리케이션을 실행할 수 있다.
이런 식으로 여러 가용 영역의 파티션에 인스턴스를 분산할 수 있다.
여기서도 가용 영역당 최대 7개의 파티션이 있을 수 있다.
...
그러면 분할 배치 그룹을 사용하는 이유는 무엇일까?🧐
각 파티션은 AWS의 랙을 나타내는데 파티션이 많으면 인스턴스가 여러 하드웨어 랙에 분산되서
서로의 랙 실패로부터 안전하다는 것이다.
그리고 이 설정으로 최대 수백 개 EC2 인스턴스를 얻을 수 있다!
+) EC2 인스턴스가 어떤 파티션에 있는지 알기 위해 메타데이터 서비스를 사용해서 이 정보에 액세스하는 옵션이 있다
=> 분할 배치 그룹은 파티션들 전반에 걸쳐 데이터와 서버를 퍼뜨려 두도록 파티션 인식 가능한 애플리케이션의 경우가 적절하다.
(HDFS Hbase, Cassandra, Apache Kafka를 사용해서 파티션을 인식하는 빅 데이터 어플리케이션에 적합)
#1 배치 그룹 설정방법 간단하게 알아보기
결과 : 아래와 같이 EC2 인스턴스를 만들 때, 고급 세부 정보에 배치 그룹을 선택하는 옵션을 추가할 수 있다..!
#2 Elastic Network Interfaces (ENI)
VPC의 논리적 구성 요소이고 가상 네트워크 카드를 나타낸다.
그리고 ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해준다. (EC2 외부에서도 사용 가능)
위의 그림을 예를 들어 가용 영역이 하나 있고 하나의 EC2 인스턴스가 있다고 치면 기본 ENI인 EthO에 연결되어 EC2 인스턴스 네트워크 연결(private IP도 가능)을 제공한다.
그리고 ENI는 특정 가용 영역(AZ)에 바인딩 된다 => 특정 AZ에서 ENI를 생성하면 해당 AZ에만 바인딩할 수 있다.
그림 상,하단의 EC2에 다른 문제가 생겼는데 또 다른 ENI가 연결되어 있다고 하자. 그러면 첫 번째 EC2 인스턴스에서 두 번째 EC2 인스턴스로 Eth1을 옮겨서 private IP로 이동시킬 수 있다. 그러면 private IP가 첫 번째 문제 인스턴스에 서 두 번째 EC2 인스턴스로 연결되게 된다..! => 즉 장애 조치에 매우 유용
가령 private 정적 IP로 EC2 인스턴스에 액세스하는 경우, 장애 조치를 위해 EC2 인스턴스 간에 IP를 이동시킬 수 있다.
각 ENI는 다음과 같은 속성을 가질 수 있다 ⬇️
1. 주요 Private IP와 하나 이상의 보조 IPv4를 가질 수 있다
(위의 예시에서는 EthO 하나 있지만 EC2에 보조 ENI를 얼마든지 추가할 수 있다 - 추가하면 EthO1이 되고 또 다른 사설 IPv4가 제공될 것임)
2. 각 ENI는 각 private IP당 Elastic IP를 가질 수 있다.
3. 하나의 public IPv4를 가질 수 있으니 private/public IP가 한 개씩 제공된다.
4. Mac 주소 및 기타 여러 가지를 연결할 수 있다.
...
그리고 EC2 인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2 인스턴스에서 이동시킬 수 있다.
#3 EC2 Hibernate (EC2 절전 모드) - EBS 볼륨에 RAM 상태 저장해두고 끌어오기
인스턴스를 중지하면 EBS 디스크 데이터는 다시 시작할 때까지 그대로 유지될 것이다. 그런데 인스턴스를 종료해버리면 root EBS 볼륨이 삭제되게 했다면 삭제되겠지만 그렇게 설정하지 않은 다른 볼륨들은 인스턴스가 종료되더라도 그대로 남게 된다.
그 상태로 인스턴스를 다시 실행하게 되면 운영 체제가 먼저 부팅되기 시작하고 EC2 유저 데이터 스크립트도 실행된다. 그 뒤에 운영 체제가 부팅이 완료되고 애플리케이션도 실행되고 캐시도 구성되기 시작하므로 과정이 끝날 때까지 시간이 다소 많이 걸린다..😔
...
이때 EC2 Hibernate를 쓰면 RAM에 있던 인 메모리(in-memory) 상태는 그대로 보존된다!
(인스턴스 부팅이 더 빨라진다는 뜻)
RAM에 기록되었던 인 메모리 상태는 root EBS 볼륨에 기록되기 때문에 root EBS 볼륨을 암호화하고 볼륨 용량도 RAM을 저장하기에 충분하다.
<동작 원리>
그림을 빌려 원리를 더 설명하자면 RAM에는 데이터가 있는 상태인데 절전 모드를 켜면 실행 중인 인스턴스는 모두 중지 상태로 전환되고 RAM의 내용은 EBS 볼륨에 덤프된다. (인스턴스가 종료되면 RAM은 사라짐)
그러나 ⭐EBS 볼륨에는 여전히 RAM에게서 덤프된게 있으니까 인스턴스를 다시 실행하면 디스크에서 RAM을 불러와서 EC2 인스턴스 메모리로 가져간다.⭐
=> EC2를 중지한 적 없는 것처럼..!
<사용 케이스 살펴보기>
- 오래 실행되는 프로세스를 갖고 있고 중지하지 않을 때
- RAM 상태를 저장하고 싶을 때
- 빠르게 재부팅하고 싶을 때
- 서비스 초기화사 시간을 많이 잡아먹으니 서비스 중단 없이 인스턴스를 절전 모드로 전환하고 싶을 때 등등
+) 모든 인스턴스 유형(스팟, 예약..)에 적용할 수 있고 절전 모드는 최대 60일까지 사용 가능하다고 한다!
✅짤막한 개념 정리
- 기본값으로 EC2 기기는 내부 AWS 네트워크에는 private IP를 쓰고 www엔 public IP를 쓴다. EC2 기기에 SSH할 때에는 private IP를 쓸 수 없는데 VPN을 쓰지 않는 이상 같은 네트워크에 있는 게 아니기 때문이다. (그래서 VPN이 없으면 public IP만 사용할 수 있다)
'AWS' 카테고리의 다른 글
| AWS Load balancer(로드 밸런서)에 대해 조금 더 자세히 알아보자 (1) (0) | 2024.03.20 |
|---|---|
| EBS에 대해 조금 더 자세히 알아보자 (0) | 2024.03.19 |
| SSH란? 그리고 EC2 Instance Connect 사용과 EC2 인스턴스에 IAM 역할 적용하기, EC2 인스턴스 유형에 따른 추천 방향까지 (1) | 2024.03.17 |
| IAM, EC2 관련 짧은 팁과 Security Group(EC2 방화벽)에 대해 알아보기 (0) | 2024.03.16 |
| AWS의 여러 가지 기타 서비스 (2) (2) | 2024.03.15 |