Public IP, Private IP, Elastic IP
ip는 ipv4와 ipv6가 있다. ipv4를 주로 사용하지만 AWS는 ipv6도 지원한다.
ipv6는 보통 사물 인터넷에서 많이 쓰인다.
Public IP를 공용 ip라 부르고, Private IP는 사설 ip, Elastic IP는 탄력적 ip라고 부르겠다.
공용 ip가 있다면 인터넷 전역에서 액세스가 가능하다. 전체 웹에서 유니크하기 때문이다.
구글에 공용 ip를 검색하면 지리적 위치 또한 쉽게 찾을 수 있다.
사설 ip는 사설 내트워크 내에서만 접근이 가능하다. 전체 웹에서 유니크하지 않고, 사설 망에서만 유니크하면 된다.
NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결된다.
지정된 일정 ip 범위에서 사설 ip를 이용해야 한다.
EC2를 종료했다가 시작하면 할당뒨 ip가 달라진다. ip를 고정시키기 위해서 탄력적 ip가 필요하다.
탄력적 ip는 고정된 ip를 할당할 수 있다. 참고로 ipv4 기반이다.
삭제하지 않는 한 계속 가지고 있고, 인스턴스 1개에 1개 할당이 가능하다.
한 인스턴스에서 다른 인스턴스로 빠르게 이동함으로써 인스턴스 또는 소프트웨어의 오류를 빠르게 마스킹할 수도 있다.
탄력적 ip는 계정당 5개만 쓸 수 있고, 사용을 하지 않는데 소유하고 있으면 요금이 부과된다.
결론부터 말하면 탄력적 ip는 계정당 5개의 제한이 있으므로 사용하지 않는 것이 좋다.
임의의 공용 ip를 써서 DNS 이름을 할 당하는 것이 좋다.
로드 밸런서를 사용해 공용 ip를 사용하는 것이 제일 좋다.
배치 그룹
EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할 때 사용한다.
배치 그룹을 사용해 이런 전략을 정의할 수 있다.
AWS의 하드웨어와 직접적인 상호 작용을 하지는 않지만, EC2가 각각 어떻게 배치되기를 원하는지 AWS에 알려준다.
배치 그룹을 만들 때는 3가지 전략이 있다.
Cluster
- 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화한다
- 높은 성능을 제공하지만 위험 또한 높다
- 모든 EC2 인스턴스가 동일한 랙에 있다. 즉 동일한 AZ와 하드웨어에 존재한다
- 정말 좋은 네트워크 환경이 필요할 때 사용해야 한다
- 랙에 실패가 발생하거나 하드웨어에 문제가 발생하면 모든 EC2 인스턴스가 동시에 실패한다
- 빅데이터 작업을 수행하기 좋다
- 극히 짧은 지연시간과 높은 네트워크 처리량을 필요로 하는 애플리케이션에서 위험을 감수하고 선택한다
- 애플리케이션에서 매우 높은 대역폭과 짧은 대역폭이 필요한 경우 선택한다
Spread(분산 배치 그룹)
- 분산 배치 그룹은 인스턴스가 다른 하드웨어에 분산된다
- 크리티컬 애플리케이션이 있는 경우 분산 배치 그룹을 사용한다
- 실패 위험을 최소화하기 위해서 사용
- 모든 인스턴스가 다른 하드웨어를 사용한다. 여러 AZ를 사용
- 장애가 격리되며, 동시에 실패할 위험을 분리한다
- 단점은 배치 그룹의 가용 영역당 7개의 인스턴스로 제한된다. 배치 그룹의 규모에 제한이 있다. (매우 중요)
- 적당한 크기의 애플리케이션에서만 쓸 수 있다
- 사용 사례는 가용성을 극대화하고 위험을 줄여야하는 애플리케이션
- 인스턴스 오류를 바로 격리해야하는 크리티컬 애플리케이션의 경우에도 사용한다
Partition(분할 배치 그룹)
- 분산 배치 그룹과 비슷하게 인스턴스를 분산한다.
- 여러 파티션에 인스턴스가 분할되어 있고, 이 파티션은 가용 용역 내의 다양한 하드웨어 랙 세트에 의존한다.
- AZ에 문제가 생기면 같은 AZ의 랙에 존재하는 인스턴스는 장애가 동일하게 발생하는 것 같다
- 여러 가용 영역의 파티션에 인스턴스를 분산할 수 있다
- 각 파티션에는 많은 ec2 인스턴스가 있을 수 있다 (파티션 == AWS 랙)
- 파티션이 많으면 인스턴스가 여러 하드웨어 랙에 분산되어 서로 랙 실패로부터 안전하다
- 가용 영역당 최대 7개의 파티션이 있을 수 있고, 파티션은 동일한 리전의 여러 가용영역에 걸쳐있을 수 있다
- 설정으로 최대 수백 개ec2 인스턴스를 얻을 수 있다. 이게 분산 배치 그룹과의 차이점이다
- 인스턴스와 파티션은 다른 파티션의 인스턴스와 동일한 하드웨어 물리적 랙을 공유하지 않으므로 각 파티션은 실패로부터 격리된다.
- 즉 파티션이 하나가 다운되면 다른 파티션은 정상
- 그리고 이런 ec2 인스턴스가 어디에 있는지 알기 위해 메타데이터 서비스를 사용해 이 정보에 액세스하는 옵션이 있다
- 이건 파티션들 전반에 걸쳐 데이터와 서버를 퍼뜨려 두도록 파티션 인식 가능한 애플리케이션의 경우에 사용한다
- 사례는 HDFS, Hbsase, 카산드라, 아파치 카프카 파티션을 인식하는 빅 애플리케이션이 있다
ENI(탄력적 네트워크 인터페이스)
VPC의 논리적 구성요소이며 가상 네트워크 카드를 가리킨다.
Ec2 인스턴스가 네트워크에 엑세스할 수 있게 해주며, ec2 외부에서도 사용이 가능하다.
예시로는 사설 ip가 있다.
ENI 속성
- 주요 사설 Ipv4와 하나 이상의 보조 ipv4를 가질 수 있다
- 각 eni는 사설 ipv4당 탄력적 ipv4를 갖거나 혹은 하나의 공용 ipv4를 가질 수 있으므로 사설 및 공용 ip가 한 개씩 제공된다
- eni에 하나 이상의 보안 그룹을 연결할 수 있다. mac 주소 및 기타 항목 등
- ec2 인스턴스와 독립적으로 eni를 생성하고 즉시 연결하거나 장애 조치를 위해 ec2 인스턴스에서 이동시킬 수 있다
- eni는 특정 가용영역 즉 az에 바인딩 된다
- 특정 az에서 eni를 생성하면 해당 az에만 바인딩할 수 있다
- 인스턴스에서 다른 인스턴스로 eni를 이동시켜서 사설 ip를 이동시킬 수 있다. 장애 조치에 매우 유용하다
- 사설 정적 ip로 ec2 인스턴스에 액세스하는 경우 장애 조치를 위해 ec2 인스턴스 간에 ip를 이동시킬 수 있다
- 인스턴스와 같이 생긴 eni는 인스턴스를 지우면 삭제되지만, 직접 생성하고 연결한 eni는 인스턴스를 삭제해도 삭제되지 않는다
- EC2에 다수의 ENI를 추가할 수 있다
EC2 hibernate( 절전 모드)
인스턴스를 멈추면 EBS 디스크 데이터는 다시 시작할 때 까지 유지된다.
인스턴스를 종료하면 루트 볼륨이 삭제되게 했다면 인스턴스도 삭제된다.
하지만 그렇게 설정하지 않은 다른 볼륨은 인스턴스가 종료되더라도 남는다.
그리고 인스턴스를 다시 시작하면 os가 부팅되고 ec2 사용자 데이터 스크립트도 실행된다.
그 후 운영체제 부팅이 완료되고 애플리케이션도 실행되고 캐시도 구성되기 시작하므로 시간이 조금 걸린다.
여기서 절전모드가 등장한다
인스턴스가 하이버네이트(절전 모드)가 되면 렘에 있던 인 메모리 상태는 그대로 유지된다,.
운영체제를 끄지 않고 멈춘거라, 부팅이 더 빨라진다.
절전 모드가 되고 백그라운드가 되고 램에 있던 인 메모리 상태는 루트 경로의 ebs볼륨에 기록되기 때문에
루트 ebs 볼륨을 암호화해야 하고 볼륨 용량도 램을 저장하기에 충분해야한다.
ec2 인스턴스가 실행하고 있다고 가정해보자
램에 데이터가 있고 이제 절전 모드를 키면 실행 중인 인스턴스는 중지 상태로 전환되고 램의 내용는 ebs 볼륨에 덤프 된다.
그리고 인스턴스를 종료하면 램이 사라진다.
하지만 ebs 볼륨에는 램이 덤프된게 있으므로 인스턴스를 다시 실행하면 디스크에서 램을 불러와 ec2 인스턴스 메모리로 가져간다.
이러면 ec2 인스턴스를 중지한 적이 없는 것처럼 보인다. 운영체제도 이렇게 알고 중지 한적이 없다고 말한다.
사용 사례
- 오래 실행되는 프로세스를 갖고 있고 중지하지 않을 때
- 램 상태를 저장하고 싶을 때
- 빠르게 재부팅을 하고 싶을 때
- 서비스 초기화가 시간을 많이 잡아먹어 서비스가 중단 없이 인스턴스를 절전 모드로 전환하고 싶을 때
인스턴스 램 크기는 150gb가 최대다. (이건 시험에 안나옴)
많은 타입에서 지원하지만 베어메탈 인스턴스에는 적용할 수 없고
리눅스 윈도우 등의 여러 os에서 사용할 수 있고 루트 볼륨,
즉 ebs에만 저장이 가능하며 ebs 볼륨에 암호화가 필요하고 덤프된 램을 포함할만큼 충분한 용량이 있어야 한다.
온디맨드 예약, 스팟과 같은 모든 종류의 인스턴스에 사용할 수 있다.
절전모드는 최대 60일까지 사용할 수 있음 (강의 기준)
댓글