AWS Infra에 대한 전반적인 이해를 목적으로, 주요 키워드에 대한 내용을 살펴봄으로써 차후 실습 시 도움 되는 것을 목표로 합니다.
누군가에게는 도움되길 바라는 마음으로 정리합니다.
( 내용 중 조금이라도 이상한 부분 있다면 언제든지 댓글 남겨주시면 감사합니다. ^0^ )
- AWS Global Infrastructure
- VPC, Subnet
- Internet Gateway
- Route Table
- Security Group & NACL
- NAT
- ELB (ALB, NLB, GLB)
- Route 53
AWS Global Infrastructure
- Networking
→ VPC(Amazon Virtual Private Cloud) - Storage, Servers, Virtulization
→ EC2(Amazon Elastic Compute Cloud) - O/S
→ AMI(Amazon Machine Image)
참조 : https://aws.amazon.com/ko/about-aws/global-infrastructure/
Region & AZ(Availability Zone : 가용영역)
- Region이란 AWS가 전세계에서 데이터 센터를 클러스터링하는 물리적 위치를 말한다. AWS Region은 영역 내에서 격리되고 물리적으로 분리된 여러 개의 가용 영역(AZ)으로 구성된다. 각 Region에서는 최소 2개 이상의 가용 영역(AZ)을 제공한다.
- 가용 영역이란 리전의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터 센터를 뜻한다. 가용영역 활용 시 단일 데이터 센터를 사용하는 것보다 더 높은 가용성과 내결함성을 갖춘 서비스 운영이 가능하다.
Region 예시.
-> 현재 다양한 국가에 AWS 서비스가 제공되는 것을 확인할 수 있다.
ex) ap-northeast-2(한국) / ap-southeast-1(싱가포르) …
AZ 가용 영역 예시.
-> 서울 리전은 현재 4개의 가용 영역이 존재한다.
ex) ap-northeast-2a / ap-northeast-2b …
VPC (Virtual Private Cloud) & Subnet
VPC
VPC는 사용자를 위한 전용 가상 네트워크이다. 기존에 IDC 센터에서 사용자만을 위한 네트워크망을 제공해준 것처럼 AWS에서 제공한다.
VPC 특징으로는 아래와 같다.
- VPC는 라우터를 제공한다. 라우터를 통해 VPC 네트워크에서 트래픽 제어가 가능하다.
- 인터넷 게이트웨이(IGW)를 붙일 수 있다.
- 생성 시 주소 범위를 CIDR(Classless Inter-Domain Routing) 블록 형태(ex. 10.0.0.0/16)로 지정할 수 있다.
- 더 알아보기
Subnet
사용자는 VPC 구축 후 Public, Private 서브넷을 자유롭게 생성할 수 있다. 서브넷 생성 시 VPC에서 지정한 CIDR 블록 범위 내 IP 주소를 지정해야 되며, 인터넷 연결 여부에 따라 Public / Private 서브넷으로 구분된다.
각 서브넷에서는 AWS 리소스를 보호하기 위해 보안 그룹(Security Group) 및 네트워크 액세스 제어 목록(NACL)을 포함한 다중 보안 계층을 사용할 수 있다.
서브넷 인스턴스에서 인터넷에 연결하기 위해선 IGW(Internet Gateway)를 연결해야 된다.
Internet Gateway
인터넷 게이트웨이는 VPC와 인터넷 간에 통신할 수 있게 해 줌으로써, 수평 확장되고 가용성이 높은 VPC 구성 요소이다. 인터넷 게이트웨이 목표로는
- 인터넷 트래픽을 VPC 라우팅 테이블 제공
- 퍼블릭 IP 주소가 할당된 인스턴스에 대해 NAT(네트워크 주소 변환)을 수행
인터넷 액세스 활성화시키기 위해서는 아래와 같이 3가지 설정에 대해 점검하기 바랍니다.
- 인터넷 게이트웨이를 생성해 VPC에 연결.
- Public Subnet 인스턴스에 IP 주소가 있는지 확인.
- NACL, Security Group에서 인*아웃바운드 정책 확인.
Route Table
라우트 테이블은 Subnet 또는 Gateway의 네트워크 트래픽이 전송되는 위치를 결정하는 규칙 세트이다. 즉, 라우트 테이블을 사용해 네트워크 트래픽이 전달되는 위치를 제어한다. 각 서브넷에 라우트 테이블을 지정함으로써 네트워크 안에서 트래픽이 발생할 때 최적의 목적지를 선택할 수 있도록 한다. 아래 예시로 살펴보자.
“10.0.0.0/16”은 VPC 생성 시 기본적으로 생성되는 CIDR 블록 형태로써, 해당 IP 트래픽 발생 시 IGW로 향하지 않고 VPC 내부에서 목적지를 찾는다는 의미이다. “0.0.0.0/0”은 local 트래픽 외 모든 트래픽은 인터넷으로 라우팅 하는 것이다
Security Group & NACL(Network Access Control List)
네트워크 접근 제어목록(NACL)은 Subnet에 대한 방화벽 역할로써 인바운드 트래픽과 아웃바운드 트래픽을 각각 제어해야 된다.
보안 그룹(Security Group)은 가상 방화벽의 기능을 수행하며 타겟 리소스인 인스턴스(ex. EC2)에 인바운드 및 아웃바운드 트래픽을 제어한다.
보안 그룹과 NACL 모두 인바운드와 아웃바운드 트래픽을 제어하지만, 몇가지 차이점이 존재한다.
Security Group vs NACL
| Security Group | NACL |
| 인스턴스 레벨에서 운영. | 서브넷 레벨에서 운영 |
| 허용 규칙만 지원 | 허용 및 거부 규칙 지원 |
| 상태 저장: 규칙에 관계없이 반환 트래픽이 자동으로 허용 | 상태 비저장: 반환 트래픽이 규칙에 의해 명시적으로 허용되어야 함. |
| 트래픽 허용 여부에 대한 규칙 순서 존재 X | 트래픽 허용 여부에 대한 규칙 순서 존재 O 번호가 가장 낮은 규칙부터 순서대로 처리 |
| 인스턴스 시작 시 누군가 보안 그룹을 지정하거나, 나중에 보안 그룹을 인스턴스와 연결하는 경우에만 인스턴스에 적용됨 |
연결된 서브넷 안에 존재하는 모든 인스턴스에 자동 적용 |
AWS 인프라 구축 시 보안그룹과 NACL은 아래 그림과 같다.
이때 유념해야 될 부분은 상태 저장(Stateful)과 상태 비저장(Stateless)에 대해 확인이 필요하다. 보안그룹의 경우 트래픽에 관한 상태를 저장함으로써(Stateful) 허용 가능한 트래픽에 대해서는 자동적으로 리턴 할 수 있다.
반면, NACL의 경우 트래픽에 대한 상태를 저장하지 않아(Stateless) 요청 값을 허용해도 리턴 값이 자동적으로 가능하다고 볼 수 없다. 따라서 인바운드 및 아웃바운드에 대한 각각의 정책을 확인해야 된다.
NAT (Network Address Translation)
- NAT Gateway는 네트워크 주소 변환(IP, Port) 서비스이다.
- NAT를 이용하는 이유는 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함이다.
- Private Subnet 인스턴스는 Public Subnet에 위치한 NAT Gateway를 통해 인터넷에 액세스 할 수 있다.
- Public Subnet은 Public용 Routing Table의 IGW 항목을 참조하게 되고 Private Subnet은 Private용 Routing Table에 IGW 항목이 없기 때문에 인터넷 통신이 되지 않는다. 출발지가 Private Subnet의 EC2 가 인터넷상의 통신을 하고자 한다면 NAT Gateway 를 통해야 한다.
-> Public Subnet 라우팅 테이블
→ Private Subnet 라우팅 테이블
추가로 "NAT Gateway 사용 사례"에 관한 자세한 정보는 아래 docs를 살펴보자
-> https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/nat-gateway-scenarios.html
NAT Instance, NAT Gateway
NAT Instacne란 네트워크 주소 변환을 제공하는 AMI(Amazon Machine Image)로써 EC2의 인스턴스를 NAT 인스턴스로 시작할 수 있다. Bastion으로 겸용 할 수 있으나 현재는 Amazon 공식 문서에서 언급하듯이 NAT Gateway로 마이그레이션을 권장하고 있다.
출처 : https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_NAT_Instance.html
NAT 게이트웨이는 Public 또는 Private 유형 중 하나를 지정한다.
- Public - Private 서브넷 인스턴스는 Public NAT Gateway를 통해 인터넷 연결이 가능하며, 인터넷에서 허용하지 않는 인바운드를 사전에 차단 할 수 있다.
- Private - Private 서브넷 인스턴스는 Private NAT Gateway를 통해 다른 VPC 네트워크에 연결할 수 있다. 트래픽을 NAT 게이트웨이에서 Trasit Gateway 또는 가상 프라이빗 게이트웨이를 통해 트래픽을 라우팅할 수 있다. 유의사항으로는
- 탄력적 IP 주소를 프라이빗 NAT 게이트웨이에 연결할 수 없다.
- Private NAT Gateway를 사용해 VPC 인터넷 게이트웨이를 연결 할 수 있지만, Private NAT Gateway → IGW 트래픽이 발생하는 경우 IGW가 트래픽을 삭제한다.
ELB(Elastic Load Balancing)
ELB는 둘 이상의 가용영역(Availability Zone)에 존재하는 리소스(ex. 인스턴스 등)에 네트워크 트래픽을 자동으로 분산시킬 수 있다. 상태가 양호한 대상으로만 트래픽을 라우팅하고 수신 트래픽의 변화에 따라 로드 밸런서 용량을 자동 조정한다.
Load balancer benefits
- 로드 밸런서를 이용해서 애플리케이션의 가용성(avaliability)과 내결함성(Fault-tolerance)이 높아지고, 필요에 따라 컴퓨팅 리소스를 추가 및 제거할 수 있다.
- 로드 밸런서가 인스턴스 상태를 지속 모니터링 함으로써 정상적인 대상에게만 클라이언트의 요청 값을 전달한다.
ELB 특징
ELB는 AWS의 VPC에 탑재되어, 사용자의 요청을 받고 이를 VPC내 리소스(ex. EC2 등)에 적절히 부하 분산한다. 그렇기에 ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스 집합인 대상 그룹(Target Group)으로 구성되어 있다. 그리고 부하 분산 대상인 대상 그룹 리소스들은 헬스 체크(Health Check)를 사용해 상태를 확인한다.
Application Load Balancer
OSI 7계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서로써 HTTP/HTTPS, WebSocket 등을 활용하는 로드밸런서이다. 또한 EC2를 대신하여 SSL 암복호화를 수행 할 수 있다.
Network Load Balancer
전송계층(Transport Layer)의 특성을 이용하는 로드밸런서다. TCP와 UDP 요청을 받아 부하분산을 실시하지만, HTTP, HTTPS, WebSocket 등과 같이 상위 계층(Layer 5 ~ Layer 7)은 이해하지 못해 부하 분산이 불가능합니다.
Gateway Load Balancer
GWLB는 OSI 계층 중 네트워크 계층(Network Layer)을 활용한다. 외부에서 내부로 유입되는 트래픽과 내부에서 외부로 나가는 트래픽을 다른 네트워크(VPC)의 게이트웨이 역할로 동작 할 수 있습니다.
위의 이미지는 GWLB의 전체적인 아키텍처를 보여주고 있습니다. IGW을 통해 들어온 클라이언트 요청 트래픽은 파랑색. 서비스에서 외부로 나갈때 트래픽은 주황색으로 표시되어 있으며, 서비스와 보안을 분리한 아키텍처 구성으로써 확장 및 배포가 용이합니다.
Internet-facing vs Internal Load Balancer
인터넷(Internet-facing) 로드 밸런서는 인터넷을 통해 클라이언트의 요청을 라우팅 할 수 있다. 내부(Internal) 로드 밸런서는 인터넷과 동일하게 DNS와 IP 주소가 부여되어 있지만, VPC내부에 존재하는 클라이언트 요청만 라우팅 할 수 있다.
-> Internet-facing ⇒ Frontend
-> Internal ⇒ Backend
ALB vs NLB 차이점은?
| ALB(Application ~) | NLB(Network ~) | |
| 네트워크 계층 | Layer 7 응용계층(Application Layer) |
Layer 4 전송계층(Transport Layer) |
| 특징 | HTTP의 URI, Payload, Http Header, Cookie 등의 내용을 기준으로 분산 | TCP / UDP 포트 정보를 기준으로 분산 |
| Listen | HTTP, HTTPS, gRPC | TCP, UDP, TLS |
| Target Group | IP, Instance, Lambda | IP, Instance, ALB |
| IP | 유동적 | 고정 IP |
Route 53
Route53은 가용성과 확장성이 우수한 DNS 웹 서비스입니다. 즉, 도메인 주소를 IP 주소로 변환해주는 역할을 하며, 사용자의 요청을 EC2, ELB, S3 버킷 등 AWS에서 실행되는 인프라에 효과적으로 연결이 가능합니다.
주요 기능으로는 아래와 같습니다.
1. 도메인 등록
- 일반적으로 후이즈, 가비아 등과 같이 도메인 등록대행자 서비스 회사들과 같이 도메인 등록하는 방식을 지원합니다.
2. DNS 라우팅출처
- 일반적으로 DNS 서비스에서 제공하는 시스템과 동일하게 제공하고 있습니다.
3. 리소스 상태 확인(Health Check)
- 관리자가 지정한 시간 간격으로 엔드포인트에 요청을 전송 할 수 있다
- 엔드포인트가 비정상적이라고 판단될 때 AWS에서 제공하는 CloudWatch를 통해 지정된 수신자에게 알람을 전송 할 수 있다
기타 용어
- 고가용성 : 전체 시스템에 대한 개념으로써, 목표는 사람이 개입하지 않아도 시스템이 지속적으로 운영이 가능하며, 가동 중지를 최소화하도록 보장하는 성질을 말합니다.
- 내결함성 : 시스템의 일부 구성 요소가 작동하지 않더라도 계속 작동할 수 있는 기능. 애플리케이선 구성 요소에 내장된 중복 기능이라고 볼 수 있습니다. 예를 들면, AWS S3의 경우 리전 내 여러 시설에서 각 디바이스의 모든 데이터를 중복 저장하는 경우 내결함성이 우수하다고 말할 수 있습니다.
- 고가용성 vs 내결함성 차이 : 서비스 안정적 운영에 대한 목표는 같으나 두 접근 방식 간에는 중요한 차이점이 있습니다. 고가용성이란 시스템 성능이 부정적인 영향을 받지 않도록 설계된 것이지만, 내결함성은 성능에 대한 이슈를 크게 고려하지 않습니다.
'DevOps' 카테고리의 다른 글
| 배포전략(Deployment Strategy) (0) | 2022.10.07 |
|---|---|
| AWS Infra 설명서 : IAM (0) | 2022.10.06 |
| CI/CD 참고 (0) | 2022.03.17 |
| 3. Jenkins + git push 연동 (0) | 2019.08.25 |
| 2. Jenkins Job 등록 및 Github 연동 (0) | 2019.08.15 |