Private vs Public IP (IPv4)
Networking has two sorts of IPs, IPv4 and IPv6
In this course, we will only be using IPv4
Ipv6 is newer and solves problems for the IoT
Ipv4 allows for 3.7 billion different adresses in the public space
회사엔 사설 네트워크가 있고 사설 네트워크에는 기본적으로 사설 IP 범위가 있는데
기본적으로 사설 네트워크 내의 모든 컴퓨터가 사설 IP를 사용하여 서로 통신할 수 있음
반면 공용 게이트웨이인 인터넷 게이트웨이를 이용하게 되면 이 인스턴스들도 다른 서버에 엑세스할 수 있게 됨
공용 IP가 있으면 인터넷 전역에 엑세스할 수 있고
사설 IP가 있으면 사설 네트워크 내에서만 엑세스할 수 있음
public IP:
public ip means the machine can be identified on the internet (www)
Must be unique across the whole web (not two machines can have the same public IP)
Can be geo-located easily
private IP:
private ip means the machine can only be identified on a prvate network only
The IP must be unique across the private network 사설 네트워크 내에서만 유일하면 됨
But tow different private networks (two companies) can have the same IPs 두 개의 다른 회사는 같은 사설 IP를 가질 수 있음
기기가 사설 네트워크에 있을때 NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결됨
지정된 범위의 IP만 사설 IP로 사용될 수 있음
Elastic IPs
EC2를 시작하고 중지할때 공용 IP를 바꿀 수 있음
탄력적 IP는 원하는 만큼 소유하고 한 번에 하나의 EC2 인스턴스에 연결할 수 있는 퍼블릭 IPv4
인스턴스에 고정된 공용 IP를 사용하려면 탄력적 IP가 필요하게 됨
An Elastic IP is a public IPv4 IP you own as you don't delete it
한번에 한 인스턴스에만 첨부할 수 있음!!!
With an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the adress to another instance in your account
계정 당 탄력적 IP 5개까지만 쓸 수 있음
결론적으로 탄력적 IP를 사용하지 않는 것이 좋다!!! > 임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋음(탄력적 IP는 pool architectural decisions)
로드밸런서를 사용해서 퍼블릭 ip를 아예 사용하지 않을 수도 있음
by default, your EC2 machine comes with:
A private IP for the internal AWS Network
A public IP, for the WWW
When we are doing SSH into our EC2 machines:
We can't use a private IP, because we are not in the same network VPN을 쓰지 않는 이상 같은 네트워크에 있는 게 아님
We can only use the public IP
If your machine is stoppend and then started, the public IP can change
인스턴스 중지 후 재시작
아이피가 바뀜
현재는 탄력적 아이피가 부착되지 않은 상태
탄력적 IP 탭에서 탄력적 IP 발급
특정 인스턴스에 부착 가능한 탄력적 IP
연결이 유지되는 한 탄력적 IP도 계속 유지됨
탄력적 아이피를 가지고 있으면 요금이 부가됨
Placement Groups 배치그룹
Ec2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할 때
배치그룹 사용 전략: AWS 하드웨어와 직접적인 상호작용을 하지는 않지만 EC2 인스턴스가 어떻게 배치되기를 원하는지 AWS 에 알려줌
Cluster-clusters instances into a low-latency group in a single Availability zone 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화할 클러스터 배치 그룹 high performance high risk
Spread분산배치그룹-spreads instances across underlying hardware(max 7 instances per group per AZ 가용영역별로 분산된 배치그룹 당 7개의 인스턴스만 가질 수 있다) 중요한 애플리케이션 인스턴스가 다른 하드웨어이 분산됨
Partition분할배치그룹-spreads instances across many different partitions (which rely on different sets of racks) within AZ.scales to 100s of EC2 instances per group 인스턴스가 여러 파티션에 분할되어 있고 이 파티션은 가용 영역 내의 다양한 하드웨어 랙 세트에 의존함
그룹 당 수백개의 EC2 인스턴스를 통해 확장할 수 있음 Hadoop Cassandra Kafka
Cluster placement groups 클러스터배치그룹
Same Rack Same AZ
모든 EC2 인스턴스가 동일한 랙(하드웨어) 동일한 가용영역에 있음
장점: Great Network 10Gbps bandwidth between instances
단점: 하드웨어 문제 발생시 모든 인스턴스가 동시에 실패함
Use case:
애플리케이션에 매우 높은 대역폭과 짧은 지연 시간이 요구되는 경우 사용
빅데이터잡 완벽히 빨라야하는
극히 짧은 지연시간과 높은 네트워크 처리량을 필요로하는 애플리케이션
클러스터 배치 그룹은 EC2 인스턴스를 병렬로 배치하여 고성능 컴퓨팅 및 네트워킹을 제공
Spread placement groups 분산배치그룹
분산배치그룹 실패 위험 최소화
모든 EC2 인스턴스가 전부 다른 하드웨어에 위치함
장점 : 여러 가용 영역에 걸쳐 있을 수 있다 AZ
동시 실패의 위험이 적음 하드웨어1이 실패해도 하드웨어2는 실패안함
us-east-1a 에 있는 두 인스턴스가 동시에 실패할 위험에을 분리
단점: 이 구성에서 배치그룹의 가용영역 당 7개의 인스턴스로 제한됨 > 크기가 너무 크지 않은 애플리케이션에서만 사용 가능함
Use case:
가용성을 극대화하고 위험을 줄여야하는 애플리케이션
인스턴스 오류를 서로 격리해야하는 크리티컬 애플리케이션
배치그룹당 가용영역 당 인스턴스 수는 7개로 제한된다
Partition placement groups 파티션 배치그룹
여러 가용영역에 파티션에 인스턴스를 분산할 수 있음
가용영역당 최대 7개의 파티션이 있을 수 있음 > 파티션에는 많은 인스턴스가 있을 수 있음
각 파티션은 AWS의 랙을 나타냄
파티션이 많으면 인스턴스가 여러개의 하드웨어 랙에 분산되어 서로 랙 실패로부터 분리됨
따라서 가용영역 당 7개의 파티션이 있을 수 있음
이러한 파티션은 동일한 리전의 여러 가용영역에 걸쳐 있을 수 있음
최대 수백개 인스턴스를 설정 가능함
인스턴스와 파티션은 다른 파티션의 인스턴스와 동일한 하드웨어 물리적 랙을 공유하지 않으므로 각 파티션은 실패로부터 격리됨
파티션1이 다운되어도 파티션2는 정상임
EC2 인스턴스가 어떤 파티션에 있는지 알기 위해 메타데이터 서비스를 사용하여 열람 가능
use case:파티션들 전반에 걸쳐 데이터와 서버를 퍼뜨려 두도록 파티션 인식 가능한 애플리케이션 HDFS HBASE Cassandra Kafka 등을 이용하여 파티션을 인식하는 빅데이터 어플리케이션
Elastic Network Interfaces ENI 탄력적 네트워크 인터페이스
Elastic Network Interface (ENI)는 특정 AZ에 바인딩됩니다. ENI를 다른 AZ의 EC2 인스턴스에 연결할 수 없습니다.
VPC의 논리적 구성 요소이며 virtual network card를 나타냄
ENI는 EC2 인스턴스가 네트워크에 엑세스할 수 있게 해줌
인스턴스 외부에서도 사용됨
ex) 가용영역에 하나의 EC2 인스턴스가 있는 상황
primary ENI인 Eth0에 연결되어 EC2 인스턴스에서 사설 ip로의 네트워크 연결을 제공함
ENI가 가질 수 있는 상황들:
primary private IPv4, one or more 보조 IPv4
(EC2에 보조 ENI를 얼마든지 추가해도 됨)
각 ENI에 private IPv4 당 하나의 탄력적 IPv4, Or 퍼블릭 IPv4 를 연결할 수 있음
ENI에 하나 이상의 보안 그룹을 연결 할 수 있음
맥 주소 및 기타 항목을 연결할 수 있음
EC2 인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2 인스턴스에서 이동시킬 수 있음
ENI는 특정 AZ에서 생성하면 그 영역에서만 사용 가능함
EC2 인스턴스가 두개 있을 때,
하나의 인스턴스에 문제가 생겼는데 또 다른 ENI가 연결되어 있음 > 첫번째 EC2 인스턴스에서 두번째 인스턴스로 ETH1을 옮겨 사설 IP 변경이 가능함
두개의 ENI inuse 상태
인스턴스가 있는곳인 ap-northeast-2c에 ENI를 생성하자
새로운 네트워크 인터페이스인 DemoENI 생성함
Available
보조 사설 IPv4를 만든 것
두개의 네티워크 인터페이스가 생김
우리의 ENI는 보조 프라이빗 IP를 제공함
이 ENI는 제어할 수 있기 때문에 하나의 EC2 인스턴스에서 다른 인스턴스로 옮기고 가져올 수 있음
ex) 두 개의 인스턴스가 동일한 애플리케이션에서 실행되고 있고
ENI를 옮겨서 사설 IPv4를 줄 수 있음 > 두 인스턴스 간에 매우 빠른 네트워크 장애 조치가 가능함 한 인스턴스에서 다른 인스턴스로 IP 연결이 가능하기 때문에
인스턴스에서자동으로 연결된 ENI는 자동 삭제되나
내가 만든 ENI는 삭제되지 않음
EC2 Hibernate 절전 기능
We know we can stop, terminate instances
중지 : 데이터가 다음 시작을 위해 유지됨
종료 : EBS 볼륨의 모든 데이터가 인스턴스와 함께 소실되도록 설정되어 있으면 삭제됨
BUT 보조 드라이브로 연결된 EBS 볼륨이고 인스턴스가 종료될 때 소실되지 않도록 설정되어 있으면 데이터는 보존됨
On start, the following happens:
First start: the OS boots & the EC2 User Data script is run
Stop and restart: the OS boots up 인스턴스에 내부 캐시가 있는 경우 캐시가 워밍업됨 > 캐시 워밍업 OS 붓업 속도가 좀 걸릴 수 있음
Introducing EC2 Hibernate:
The in-memory(RAM) state is preserved
The instance boot is much faster OS가 중지되거나 재시작되지 않았기 때문
Under the hood: the RAM state is written to a file in the root EBS volume
The root EBS volume must be encrypted
실행중인 인스턴스가 있고 RAM에 암호화된 Amazon EBS 루트 볼륨이 있으면 중지 후 절전 모드로 전환하면 RAM이 암호화된 EBS 루트 볼륨에 덤프됨 > 인스턴스가 종료되지만 OS가 종료되지 않음 > 다시 시작하면 RAM이 EBS 볼륨에서 인스턴스의 RAM으로 이동하고 인스턴스가 실행됨
Use cases:
장기 실행 프로세스를 계속 실행하려는 경우
RAM state 를 저장하는 경우
시작하는데 시간이 많이 걸리는 서비스의 경우
Good to know
모든 인스턴스를 지원하지 않음
C3,C4, C5, M3, M4, M5, R3, R4, and R5
Instance RAM size - must be less than 150GB
Instance size - not supported for bare metal instances 베어 메탈 인스턴스는 지원하지 않음
AMI - Amazon Linux2, Linux AMI, Ubuntu... & Windows
Root Volume : must be EBS, encrypted, not instance store(인스턴스를 저장할 수 없음), and large
전체 RAM 크기의 덤프를 지원할만큼 충분히 큰 루트 EBS 볼륨이 필요함
온디맨드 인스턴스와 예약 인스턴스에서만 사용 가능함
60일 이상 Hibernated 모드로 유지될 수 없음
uptime //인스턴스가 얼마나 오래 켜져있었는지 알려줘절전모드 없이 인스턴스를 중지하고 재시작했다면 반환값이 0-1분일것
그렇지만 절전모드에서는 반환값이 2-3분 (운영체제 입장에서 인스턴스가 중지된적 없기 때문)
EC2 Nitro
현재 실제로 사용하고 있는 차세대 EC2 인스턴스 이름
더 빠른 속도의 EBS 볼륨이 필요한경우 니트로 유형의 인스턴스를 사용하자
New virtualization technology
Allows for better performance:
Better networking options (enhanced networking, HPC, IPv6)
더 빠른 속도의 EBS 볼륨 (Nitro is necessary for 64000 EBS IOPS - 논니트로 인스턴스는 최대 32000 IOPS)
Better underlying security
Instance types example :
virtualized: A1 C5 C5a C5ad C5d C5n C6g C6gd C6gn D3 D3en G4 I3en Infl M5 M5a M5ad M5d M5dn M5n
Bare metal: a1.metal, c5.metal, c5n.metal, c6g.metal, c6gd.metal
Understanding vCPU
인스턴스를 실행하면 일부 vCPU도 실행됨
aws 에서 인스턴스를 시작하면 거의 모든 곳에서 볼 수 있는 지표가 vCPU
CPU = core
코어는 CPU고 CPU 한 개에서 여러 스레드가 실행될 수 있음 > 멀티스레딩 CPU 한개가 스레드 두개를 가지는 것
Each thread is represented as a virtual CPU (vCPU)
Ex) 4CPU 2 threads per CPU > 8 스레드(vCPU)
Optimizing CPU options
EC2 instances come with a combination
of RAM and vCPU
Capacity Reservations 용량 계획
EC2 용량 예약은 인스턴스를 시작할 때 필요한 용량을 확보할 수 있게 해줌
추가 용량을 미리 계획하기 위한 것
예약에 대한 수동 지정 날짜 혹은 예약된 종료 날짜가 있지만 이건 짧은 예약 개념 (1년 3년 사용을 약정할 필요가 없다)
용량 예약을 다시 지정하기만 하면 해당 용량에 대한 엑세스가 예약됨
따라서 즉시 사용 가능하며 용량을 예약하기 때문에 예약이 시작되면 비용이 청구됨
Specify:
원하는 인스턴스 유형
용량을 예약하려는 AZ > 딱 한개의 AZ만 지정 가능 / 3개의 AZ에 있는 리전에 대한 용량을 예약하는 경우 세 개의 용량 에약을 해야함
용량을 예약할 인스턴스 수를 지정 m5.xlarge를 몇개나 예약하는지
플랫폼, 테넌시 및 인스턴스 유형과 같은 인스턴스 속성 지정
Comebine with Reserved Instances and Savings Plans to do cost saving
용량을 미리 계획하고 특정 기간에 특정 유형의 AZ에서 인스턴스를 시작할 수 있는지 아는 경우 EC2 용량 계획을 쓰는 것이 좋다
