AWS를 사용해 무중단 배포 자동화 환경 구축하기 시리즈
VPC와 기본 리소스
서버 구축의 첫번째 단계로 AWS의 VPC (Virtual Private Cloud) 와 기본 리소스들의 개념을 알아보도록 하겠습니다.
리전 & 가용영역
VPC에 대해 알아보기 전에, 리전 & 가용영역 에 대해 알아보겠습니다.
AWS에는 리전이라는 개념이 있습니다. AWS는 전 세계에 데이터 센터를 두고 있는데요, 이 데이터 센터를 클리스터링하는 물리적 위치를 리전이라고 합니다. 각 리전은 지리 영역 내에서 격리되고 물리적으로 분리된 여러 개의 가용영역(Availability Zone) 으로 구성됩니다. 사용자는 리전을 선택하여 VPC 를 구성할 수 있습니다.
가용영역(Availability Zone)은 AWS 리전의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성됩니다. N개의 가용영을 사용하면 1개의 가용영역을 사용하는 것보다 높은 가용성, 내결함성 및 확장성을 갖춘 어플리케이션과 데이터베이스를 운영할 수 있습니다. 쉽게 말해 물리적으로 영역이 분리되어 있기 때문에 한 영역에 장애가 발생해도 다른 영역에 트래픽이 몰리게 되어 컴퓨터의 자원 사용률은 높아지겠지만 시스템이 먹통이 되는 현상은 피할 수 있게 됩니다. 물론 컴퓨터 자원에 따라 물리적인 컴퓨터 수를 조절하는 오토 스케일링 그룹을 사용하면 자원 사용률은 상관 없는 이야기이긴 합니다.
VPC
VPC 는 Virtual Private Cloud의 약자로, 아마존은 공식적으로 다음과 같이 설명하고 있습니다.
Amazon Virtual Private Cloud(VPC)를 사용하면 AWS 클라우드에서 논리적으로 격리된 공간을 프로비저닝하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경을 완벽하게 제어할 수 있습니다. VPC에서 IPv4와 IPv6를 모두 사용하여 리소스와 애플리케이션에 안전하고 쉽게 액세스할 수 있습니다.
즉, “AWS는 논리적으로 격리된 공간을 프로비저닝 하여 독립된 하나의 가상 블록을 제공하며, VPC는 AWS가 제공한 가상 블록을 기반으로 한 사용자의 계정 전용 가상 네트워크” 라고 생각하면 쉬울것 같습니다.
이 가상 블록은 내부 리소스들을 모두 public 으로 공개할 수 있지만, 대부분의 사용자들이 내부 리소스들을 모두 private 으로 두고 그 private 리소스들에 접근할 수 있는 하나의 Public EC2 인스턴스(Bastion Host) 를 두고 사용하는 편입니다. (Bastion Host 에 대해서 는 추후에 다시 다루도록 하겠습니다.)
VPC 는 2019년부터 강제되었기 때문에 AWS에서 제공하는 대부분의 서비스는 VPC 없이는 사용할수가 없게 되었습니다.
하나의 VPC를 만들면 기본적으로 생성되는 리소스들이 있습니다. 개인적으로 AWS를 이용해 서버 구축을 하려면 필수로 알아야 한다고 생각되는 개념들인데요. 하나하나 짚어보도록 하겠습니다.
CIDR
AWS 콘솔을 이용해 VPC를 생성하려고 하면 CIDR 블록 을 지정해야 한다는 문구를 만날 수 있습니다. 결론부터 말하자면 CIDR은 “IP주소 할당 기법” 입니다.
CIDR 블록은 IP 주소와 슬래쉬가 뒤에 따라오는 넷마스크 형태의 숫자로 구성되어 있습니다. 슬래쉬 뒤에 오는 숫자는 IP의 범위를 나타냅니다.
예를 들어 IP 172.31.0.0/32 는 정확히 172.31.0.0 를 가리킵니다. IP의 범위는 지정된 IP부터 2^(32-n)개 입니다. 만약 숫자가 16이면 2^(32-16) = 65,536 개의 IP 주소를 의미합니다.
VPC 내부의 자원들은 각각의 프라이빗 ip를 가지는데요, 이때 CIDR 블록의 범위 안에서 IP를 할당받게 됩니다. VPC 범위 내에서 할당 가능한 IP가 모두 할당되면 더이상 리소스를 만들수 없습니다. 한 VPC 의 최대 크기는 16입니다. 즉, 65,356개의 IP를 사용할 수 있으며, 이보다 큰 VPC는 생성할 수 없습니다. (물론 그럴일은 잘 없겠지요.)
CIDR 블록을 만들때 주의해야할 사항이 있습니다. 만약 사설망 대역이 아닌 인터넷과 연결되어 있는 경우 문제가 될 수 있습니다. 예를 들어 3.51.0.0/16를 블록으로 지정한 경우 이 VPC 에서 3.51.0.0/16로 접속하는 트래픽은 VPC 내부로 라우팅됩니다. 그런데 3.51.0.0/16 범위는 외부 인터넷에서 사용할 수 있는 범위의 IP 입니다. 따라서 이 VPC 내부에서는 3.51.0.0/16 에 속한 인터넷 IP에 접근하는 것이 불가능 합니다. 외부로의 연결이 필요한 경우라면 무조건 사설망 대역을 사용해야 하며, 그렇지 않더라도 사설망 대역을 사용하는 것이 권장되는 편입니다. 사설 IP 대역에는 아래 3가지 대역이 있습니다.
- Class A : 10.0.0.0 ~ 10.255.255.255
- Class B : 172.16.0.0 ~ 172.31.255.255
- Class C : 192.168.0.0 ~ 192.168.255.255
서브넷
VPC를 리전에 생성한것 만으로는 아무것도 할 수 없습니다. VPC는 내부적으로 다시 CIDR 블록으로 나뉘어지고, 서브넷은 실제 VPC 내부에서 리소스가 생성되는 물리적 공간인 가용영역(Availability Zone) 과 연결됩니다.
VPC가 논리적인 범위라면, 서브넷은 VPC 내부에서 실제로 리소스가 생성될 수 있는 가상 네트워크라고 생각하면 될 것 같습니다. AWS 콘솔에서 어떤 리소스(ex. EC2, RDS)를 생성할 때, VPC만 지정하는 경우는 없습니다. 서브넷도 함께 지정하는데요, 보통 서브넷을 지정하면 VPC는 자동으로 지정되는 형태를 띕니다.
하나의 VPC는 N개의 서브넷을 가질 수 있습니다. 서브넷의 최대 크기는 VPC의 크기와 같습니다. (넷마스크 16 ~ 28의 범위) 보통 한 리전 내의 사용 가능한 가용영역을 고려하여 적절한 갯수의 서브넷을 가용영역 내부에 생성합니다. 이렇게 각각 가용영역 내부에 동일한 형태의 별도의 서브넷을 가지면 한개의 가용영역에 장애가 생겨도 트래픽 분산 측면에서 쉽게 장애에 대응할 수 있겠지요.
장애 대응 측면에서 서브넷을 가용영역만큼 나누는 경우 사용할 리전에서 사용가능한 가용영역의 갯수를 미리 파악 할 필요가 있습니다. (서울 리전의 경우 4개) 모든 가용영역 사용할 필요는 없지만 보통 2개 이상의 가용영역을 구성하는게 일반적입니다.
퍼블릭 서브넷 & 프라이빗 서브넷
서브넷도 어떻게 설정하느냐에 따라 두가지로 나뉠 수 있습니다. 먼저 퍼블릭 서브넷은 VPC 내부에 있더라도 외부에서 퍼블릭 IP (탄력적 IP) 를 통해 들어올 수 있는 서브넷을 의미합니다.
보통 퍼블릿 서브넷에 Bastion Host를 두어 같은 VPC 내부에 있는 프라이빗 서브넷, RDS 등에 접근 하곤 합니다. Bastion Host에 대해선 추후 서버 구축시 자세히 다루도록 하겠습니다.
프라이빗 서브넷은 외부에서 직접 들어올수도, 나갈 수도 없는 VPC 내부에 단절된 네트워크를 사용하는 서브넷입니다. 프라이빗 서브넷에 들어오려면 퍼블릭 자원(Load Balancer 등) 을 통해 들어와야 하며 프라이빗 서브넷에서 외부 인터넷에 연결하려면 “퍼블릭 서브넷에 있으며 탄력적 IP에 연결된 NAT Gateway”를 통해 나가야 합니다.
NAT Gateway
NAT Gateway는 프라이빗 서브넷이 인터넷과 통신할때 필요로 하는 아웃바운드 리소스 입니다. 프라이빗 서브넷에 아웃바운드 트래픽이 필요한 경우가 있습니다. (ex. 외부 연동 API 서버 호출, OS 패키지 업데이트 등) 이때, 퍼블릭 서브넷에 존재하는 NAT Gateway는 프라이빗 서브넷의 아웃바운드 요청을 받아 인터넷 게이트웨이로 연결하는 역할을 합니다.
인터넷 게이트웨이
VPC는 독립된 네트워크 환경입니다. 따라서 아무 설정을 하지 않는다면 내부 서브넷 설정이 어떻든 간에 인터넷을 사용할 수 없습니다. 이때 인터넷에 연결하기 위해 필요한 것이 인터넷 게이트웨이 입니다. 외부 인터넷과 VPC를 연결해 주는 관문이 되는 것이지요.
라우터 & 라우팅 테이블
한 서브넷 안에서 네트워크 요청이 발생하면 미리 정의된 라우팅 테이블에 따라 라우터로 향하게 됩니다.
라우터는 최종 목적지이고, 라우팅 테이블은 목적지(라우터)에 도달하기 위한 네트워크 노선 이라고 이해하면 쉽습니다.
위에서 장황하게 설명하긴 했지만 A서브넷에 연결된 라우팅 테이블의 0.0.0.0/0 즉, 기본 경로가 인터넷 게이트웨이와 직접 연결되어 있으면 퍼블릭 서브넷이고 인터넷 게이트웨이와 직접 연결되어 있지 않거나 NAT Gateway와 연결되어 있으면 프라이빗 서브넷이 되는 것입니다.
보안그룹 (Security Group)
위의 인터넷 게이트웨이 & 라우터 & 라우팅 테이블이 VPC 와 서브넷간의 트래픽을 제어한다면, 보안그룹은 EC2 인스턴스의 인바운드, 아웃바운드를 포트 번호별로 제어하기 위한 설정입니다.
퍼블릭 서브넷에 존재하더라도 관련된 보안그룹의 포트가 오픈되어 있지 않다면 직접 인스턴스로 접근할 수 없습니다. 개인적으로 최종 방화벽(?) 같은 느낌이라고 생각합니다.
마치며…
VPC와 그를 사용하고자 할 때 필요한 여러 리소스들에 대해 알아보았습니다. 사실 저도 글로만 쓰면서 헷갈리는 것들이 있었는데요, 다음 포스팅에는 하나하나 직접 만들면서 자세히 알아보도록 하겠습니다.