Private vs Public (IPv4)
- Public IP
- 공용 IP는 곧 기기가 인터넷상에서 식별 될 수 있음을 의미한다.
- 각 공용 IP는 전체 웹에서 유일한 것이어야 한다.
- IP가 있으면 Google 검색으로 그 IP의 지리적 위치를 쉽게 찾을 수 있다.
- Private IP
- 기기가 오직 사설 네트워크 안에서만 식별될 수 있다.
- 따라서 IP가 사설 네트워크 안에서만 유일한 것이면 된다.
- 기기가 사설 네트워크에 있을 때 NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결된다.
- 지정된 범위의 IP만 사설 IP로 사용될 수 있다.
Elastic IPs
- EC2 인스턴스를 시작하고 중지할 때 공용 IP가 바뀔 수 있다.(이를 방지할 수 있는게 Elastic IP이다)
- Elastic IP는 IPv4이다.
- 특정 EC2 인스턴스에 할당 시켜줄 수 있는 IP이다.
- 한 인스턴스에서 다른 인스턴스로 빠르게 이동함으로써 인스턴스 또는 소프트웨어의 오류를 마스킹할 때 사용할 수 있다.
- 계정당 탄력적 IP를 5개만 쓸 수 있다.
- 하지만 탄력적 IP는 사용하지 않는 것이 좋다. 대신 임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋다.
Private vs Public IP In AWS EC2
- 기본값으로 EC2 기기는 내부 AWS 네트워크엔 사설 IP를 쓰고, WWW(World Wide Web)에서는 공용 IP를 사용한다.
- EC2 기기에 SSH를 할 땐 사설 IP를 사용할 수 없다. 왜냐면 VPN을 쓰지 않는 이상 같은 네트워크에 있는 게 아니기 때문이다.
- 그렇기 때문에 VPN이 없다면 공용 IP만 사용할 수 있다.
- 그리고 기기가 멈췄다가 다시 시작하면 공용 IP가 바뀔 수도 있다.
Placement Groups(배치 그룹)
- EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할 때 사용한다.
- 배치 그룹을 만들 때 세 가지 전략을 사용할 수 있다.
- Cluster Placement Group : 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화 하는 전략
- Spread Placement Group : 인스턴스가 다른 하드웨어에 분산되는 전략. 가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다는 제한 사항이 있다. critical application에 주로 적용한다.
- Partition Placement Group : 분산 배치 그룹과 비슷하게 인스턴스를 분산하는 것이지만 분산 배치 그룹은 여러 파티션에 인스턴스가 분할되어 있고, 가용 영역 내의 다양한 하드웨어 rack 세트에 의존한다. 즉, 다른 실패로부터 격리되지 않았다. 하지만 Partition은 다른 오류 파티션과 격리된다. 즉 그룹당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고 이를 통해 Hadoop, Cassandra, Kafka 같은 애플리케이션을 실행할 수 있다는 것이다.
Placement Groups Cluster
- 모든 EC2 인스턴스가 동일한 rack에 있다.(즉, 동일한 하드웨어와 동일한 가용 영역에 있다)
- 같은 하드웨어에 배치되기 때문에 매우 빠른 네트워크 속도를 갖게 된다.
- 하지만 rack에 실패가 발생하면, 즉 하드웨어에 실패가 발생하면 모든 EC2 인스턴스가 동시에 실패한다는 것이다. 때문에 전체 스택에 걸쳐 실패가 전파될 위험을 높아진다.
- 빅데이터 작업을 수행하는데 적합하다.
- 극히 짧은 지연 시간과 높은 네트워크 처리량을 필요로 하는 애플리케이션에 대한 요청이 있는 경우엔 이런 실패를 겪을 위험을 감수할 수도 있다.
Placement Groups Spread
- 모든 EC2 인스턴스가 다른 하드웨어에 위치하게 된다.(위의 그림에서 볼 수 있듯이 3개의 가용 영역과 6개의 EC2가 있고 각 EC2 인스턴스는 서로 다른 하드웨어에 있다.)
- 장점 : 여러 가용 영역에 걸쳐 있을 수 있으며 동시 실패의 위험이 감소한다.
- 단점 : 이 구성에서 배치 그룹의 가용 영역당 7개의 인스턴스로 제한된다. 즉 배치 그룹의 규모에 제한이 있다. 때문에 크기ㅏ 적당하지만 너무 크지 않은 애플리케이션에서만 쓸 수 있다.
- 사용 사례는 가용성을 극대화하고, 위험을 줄여야 하는 애플리케이션이다.
- 그리고 일반적으로는 인스턴스 오류를 서로 격리해야 하는 크리티컬 애플리케이션의 경우에 적합하다.
- 기억해야 될 점은 배치 그룹 마다 가용 영역 별 인스턴스 수는 7개로 제한된다.
Placement Groups Partition
- 각 파티션은 AWS의 rack을 나타낸다. 파티션이 많으면 인스턴스가 여러 하드웨어 랙에 분산되어 서로의 rack 실패로부터 안전하다.
- 따라서 가용 영역당 최대 7개의 파티션이 있을 수 있고, 이러한 파티션은 동일한 리전의 여러 가용 영역에 걸쳐 있을 수 있다.
- 설정으로 최대 수백 개 EC2 인스턴스를 얻을 수 있다.
- 다른 파티션의 인스턴스와 동일한 하드웨어의 물리적 rack을 공유하지 않으므로 각 파티션은 실패로부터 격리된다.
- 이러한 EC2 인스턴스가 어떤 파티션에 있는지 알기 위해 메타데이터 서비스를 사용하여 액세스하는 옵션이 있다.
- 파티션들 전반에 걸쳐 데이터와 서버를 퍼뜨려 두도록 파티션 인식 가능한 애플리케이션의 경우 사용한다.
- 일반적인 사용 사례는 HDFS, Hbase, Cassandra 및 Apache Kafka를 사용하여 파티션을 인식하는 빅 데이터 애플리케이션이 있다.
Elastic Network Interfaces(ENI)
- VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타낸다.
- ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해준다.
- ENI는 다음과 같은 속성을 가진다.
- Primary Private IPv4와 하나 이상의 보조 IPv4를 가질 수 있다.
- 각 ENI는 사설 IPv4 당 탄력적인 IPv4를 갖거나 혹은 하나의 공용 IPv4를 가질 수 있으므로 사실 및 공용 IP가 한 개씩 제공된다.
- ENI에 하나 이상의 보안 그룹을 연결할 수 있다.(Mac 주소 및 기타 항목을 연결 할 수도 있다.)
- EC2 인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2 인스턴스에서 이동시킬 수 있다.
- ENI는 특정 가용 영역에 바인딩 된다.
EC2 Hibernate
- RAM에 있던 인 메로리 상태는 그대로 보존되는 모드
- 다시 말해, 인스턴스 부팅이 더 빨라진다. 운영체제를 완전히 중지하거나 다시 시작하지 않고 그대로 멈춰뒀기 때문이다. RAM에 기록되었던 인 메모리 상태는 루트 경로의 EBS 볼륨에 기록되기 때문에 루트 EBS 볼륨을 암호화 해야됨
- 위의 그림처럼 RAM에 데이터가 있는 상태의 인스턴스를 절전 모드로 전환하면 실행 중인 인스턴스는 중지 상태로 전환되고 RAM의 내용은 EBS 볼륨에 덤프된다. 그리고 인스턴스를 종료하면 RAM이 사라진다. 인스턴스를 종료하면 RAM은 사라진다. 하지만 EBS볼륨에는 여전히 RAM에 dump된게 있기 때문에 인스턴스를 다시 실행하면 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져간다.
- 이렇게하면 EC2 인스턴스를 중지한 적이 없는 것처럼 된다.
- 사용 사례 : 오래 실행되는 프로세르를 갖고 있고 중지하지 않을 때, RAM 상태를 저장하고 싶을 때, 빠르게 재부팅하고 싶을 때
- Hibernate는 베어 메탈 인스턴스에는 적용할 수 없고, Linux, Windows 등의 여러 운영체제에서 사용할 수 있다.
- EBS에만 저장이 가능하며, 암호화가 필요하다
- On-demand, Reserved, Spot 등의 여러 종류의 인스턴스에 사용할 수 있다.
- 절전 모드는 최대 60일까지 사용할 수 있다.