Search

AWS

 네트워크 (VPC)

 AWS 서비스

Local → Region → Availability Zone
Region : 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치
Availability Zone : Region의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터센터

 VPC (Virtual Private Cloud)

사용자가 정의한 가상의 네트워크 공간
완전한 네트워크 제어 가능 (IP 범위, Subnet, Route Table, Network ACL, 보안그룹, …)
VPC 내의 모든 EC2 인스턴스들은 사설 IP로 할당
개별 인스턴스에 공인 IP 할당 가능 (Public IP/Elastic IP)
NAT를 통해 사설 IP가 공인 IP로 바뀜

 CIDR(Classless Inter-Domain Routing)

네트워크의 주소와 크기를 표현하는 방식 중 하나

 인터넷 트래픽을 위한 5가지 고려 요소

공인 IP 주소
Public IP : 고정되지 않음
Elastic IP : 계정에 할당 된 고정, 리전 당 기본 5개 (Pool에서 관리)
IGW(인터넷 게이트웨이)와 VPC 연결
인터넷 게이트웨이로 라우팅 구성
NACL(Network Access Control List) 구성
Security Group 허용 정책 구성
Public Subnet : 인터넷이 목적지인 경우 인터넷 게이트웨이로.. (IGW를 가진 서브넷)
Private Subnet : 목적지가 VPC CIDR 주소인 경우 Local로.. (IGW가 없는 서브넷)

 NAT 게이트웨이

Private Subnet의 Private IP가 Public Subnet의 NAT GW를 통해 Elastic IP로 변환
Private 인스턴스가 VPC 외부의 서비스와 연결할 수 있지만 외부의 서비스에서 이 인스턴스의 직접적인 연결을 시작할 수 없도록 막는다.
NAT를 생성하는 AZ의 수가 많아질 수록 비용 증가

 보안

NACL(Allow/Deny)
stateless 방화벽, 서브넷 경계의 방화벽
Security Group(Allow)
stateful 방화벽, AWS 리소스(EC2)에 대한 방화벽

 VPC Best Practice

고가 용성을 위해 Multi-AZ Deployment
Default VPC 는 그대로 두고 Custom VPC 를 생성하여 사용
Tier 를 고려하여 Subnet 설계
대부분의 Resource 는 Private Subnet 에 배치 가능 (ELB,NAT GW 이용)
여러 VPC 를 만드는 경우 겹치지 않는 대역으로 설정하되 큰 네트워크 대역 권장
On-Premise 사설 IP 대역과 겹치지 않는 VPC 대역 설정 권장
Outbound API 또는 서비스 연동의 경우 Public IP 보다는 Elastic IP 사용 (Whitelist)
CloudTrail / VPC Flowlogs / Traffic Mirroring 은 디버깅과 감사에 활용
NACL 은 조직 레벨에서 관리하고 자주 변경하지않는 것이 좋음, 복잡성 증가
Load Balancer 를 사용할 수 있는 경우 EC2 는 Private Subnet 배치
https 의 경우 ACM 이용 Load Balancer 에서 SSL Termination 처리

 VPC간 연결

1.
인터넷 게이트웨이를 통한 연결
2.
동일 리전에서 VPC peering (Transit을 통해 경유연결은 불가능. 각각 연결해야함)

 VPC peering 구성 전에 알아두어야 할 것들.

DNS Host Name을 참조해서, Private IP 주소 반환 가능
IPv4/v6 주소 모두 Peering 가능
IP 주소 대역 중복 할당 불가능
양방향 Peering 불가능

 On-Perm Network 연결

저렴한 연결 옵션은 Site to Site VPN 선택
안정적인 연결 옵션은 Direct Connect 선택
Direct Connect 를 통해
VPC 에 연결(Private VIF) 하거나
S3, DynamoDB 등 AWS 서비스(Public VIF) 에 연결

 VPC Endpoint

가상 장치로서 VPC와 AWS 서비스를 전용 연결(private connection)할 수 있도록 한다.
예를 들어 인스턴스에서 S3에 엑세스 할 때 인터넷 게이트웨이나 NAT 없이 가능
적용하게 되면 Gateway처럼 Route Tables에 등록된다.
gateway 타입과 interface 타입이 있다.

 컴퓨트 (EC2)

EC2 (Amazon Elastic Compute Cloud)
Region의 물리 서버 위에 호스트 서버, 하이퍼바이저를 얹어서 만든 가상 서버의 리소스
AMI (Amazon Machine Image)
인스턴스를 Launch 할 때 필요한 정보를 제공
루트 볼륨을 구성하는 템플릿 (OS, Application, …)
볼륨 블록, 디바이스 매핑
하나의 AMI로 여러 개의 인스턴스를 시작 가능
EC2 인스턴스 스토어
인스턴스 유형
범용 워크로드
컴퓨팅 집약적인 워크로드
메모리 집약적인 워크로드
컴퓨팅 가속화 워크로드
스토리지 집약적인 워크로드

 ECS

ECS의 구성요소

Task Definition
원하는 Docker 컨테이너를 생성할 때 어떤 설정으로 몇 개 이상 설정할지를 정의한 Set이다.
컨테이너의 이미지, CPU/메모리 리소스 할당 설정, port 매핑, volume 설정 같은 것들이 포함되며 기존 docker run 명령에서 가능했던 대부분의 옵션이 설정 가능하다.
컨테이너 오케스트레이션에서는 컨테이너에 필요에 따라서 자동적으로 실행되거나 종료될 수 있다
따라서 매번 이러한 설정들을 지정하기보다는 미리 설정들의 집합을 하나의 단위로 정의해놓고 사용한다
이 단위가 바로 Task Definition이다
한 번 Task Definition을 만들면 이걸 기반으로 특정 설정을 변경할 수 있다
Task Definition은 한 개 이상의 컨테이너에 대해 정의가 가능하며 Task Definition 내부에 정의된 컨테이너 사이는 link 설정으로 연결이 가능하다
Task Definition에서 정의된대로 실제 생성된 Container Set들을 Task라고 부르게 된다
Task
Task Definition에서 정의된대로 배포된 Container Set을 Task라고 부른다
즉, Task 안에는 한 개 이상의 컨테이너들이 포함되어 있으며 ECS에서 컨테이너를 실행하는 최소 단위는 Task이다
Task는 Cluster에 속한 Container Instance(EC2)에 배포되게 한다
또한 Task는 여러 Container Instance(EC2)에 배포 가능하다
Cluster
Task가 배포되는 Container Instance들은 논리적인 그룹으로 묶이게 되는데 이 단위를 Cluster라고 부른다
Task를 배포하기 위한 Instance는 반드시 Cluster에 등록되어야 한다
Container Instance
ECS는 Container 배포(Task 배포)를 EC2 Instance 기반에 올리도록 설계되어있다
Task를 올리기 위해 등록된 EC2 Instance를 Container Instance라고 부른다
ECS를 처음 시작하면 생성되는 Default Cluster에는 Container Instance를 자동으로 할당시켜주기도 하지만 새롭게 Cluster를 생성하게 되면 직접 Container Instace를 만들어야 한다
Container Instance용 AMI 이미지는 AWS측에서 제공해주기 때문에 어렵지 않게 생성이 가능하다
하나의 Container Instance 내부에는 각각의 다른 Task가 여러 개 있을 수 있다
Service
Task들의 Life Cycle을 관리하는 부분을 Service라고 한다
각 Task들은 각자 다른 서비스이다
Task를 Cluster에 몇 개나 배포할 것인지 결정하고 실제 Task들을 외부에 서비스하기 위해 ELB에 연동되는 부분을 관리하게 된다
만약 실행 중인 Task가 어떤 이유로 작동이 중지되면 이것을 자동으로 감지해 새로운 Task를 Cluster에 배포하는 고가용성에 대한 정책도 Service에서 관리한다
즉, 오토스케일링과 로드밸런싱을 관리하는 역할이다