들어가기
클라우드 컴퓨팅 수업을 듣게 되면서 평소에 써보고 싶었던 AWS 서비스를 마음껏 써볼 수 있게 됐습니다.
저번 주 수업 내용은 Public Subnet과 Private Subnet을 구축해 보는 것이었고 이번 주 수업 내용은 Private Subnet에 EC2 3대를 배치하고 ELB로 로드밸런싱을 해보는 것이었습니다.
수업 복습도 할 겸 차례대로 다시 한 번 구축해보려합니다.
VPC
VPC는 Virtual Private Cloud의 약자로 한 리전의 여러 가용영역(AZ)에 걸쳐서 가상의 네트워크를 만드는 AWS 서비스입니다.
VPC는 CIDR로 자체 IP범위를 지정해 줄 수 있습니다. 예를 들어 10.0.0.0/16 를 VPC의 IP범위로 설정하게 되면 10.0 구간까진 고정돼고 뒤에 0.0은 Flexible하게 내부 네트워크에서 사용할 수 있게 됩니다.
즉 VPC내부 네트워크는 2^16 (약 6만5천)개의 private 주소를 할당받을 수 있습니다.
VPC내부엔 Subnet이라는 더 작은 단위의 네트워크를 추가로 구성할 수 있습니다.
1번 Subnet -> 10.0.1.0/24 [내부에 251개의 IP 할당 가능]
2번 Subnet -> 10.0.2.0/24 [내부에 251개의 IP 할당 가능]
3번 Subnet -> 10.0.3.0/24 [내부에 251개의 IP 할당 가능]
서브넷 구성으로 Private IP를 통해 더 세밀하게 라우팅을 할 수 있게 됩니다.
여러 가용영역(같은 리전안에서 물리적으로 떨어진 서로 다른 데이터 센터)의 서버(EC2, S3 등)를 하나의 가상네트워크로 묶어 줄 수 있습니다.
Public Private Subnet
서브넷은 크게 Public/Private Subnet으로 구분할 수 있습니다.
뜻 그대로 Public Subnet은 바깥과 직접적 인터넷 통신이 가능한 서브넷이고
Private Subnet은 바깥과 직접적인 통신이 불가능한 서브넷입니다.
VPC 구성 요소 중엔 라우팅 테이블(Routing Table)이 존재합니다. 이 라우팅 테이블은 서브넷에 연결해 서브넷의 아웃바운드 트래픽(바깥으로 나가는 트래픽) 규칙을 정의할 수 있습니다.
Public Subnet의 0.0.0.0/0(Anyway IPv4)로 나가는 트래픽은 igw(인터넷 게이트웨이)로 전달됩니다.
인터넷 게이트웨이가 VPC 내부와 인터넷 사이 패킷 전달을 가능하게 해줍니다.
이렇게 인터넷게이트웨이와 라우팅 테이블이 설정된 서브넷을 Public Subnet이라 합니다.
Private Subnet은 기본적으로 인터넷게이트웨이와 연결하지 않고 외부의 접근이 없도록 만듭니다.
다만 Private Subnet 내부에서 인터넷이 필요한 경우(소프트웨어 업데이트) 바깥 세상과 소통해야하는데 이때 Public Subnet 내부에 NAT(Network Address Translation)을 이용해 인터넷으로 트래픽을 보낼 수 있습니다.
NAT는 VPC에서 나가는 트래픽을 공인 IP로 변환해 통신하고 돌아오는 응답을 Private Subnet 내부로 전달합니다.
하지만 직접적으로 NAT를 통해 바깥에서 내부로 통신은 불가능합니다.
이렇게 하면 Private Subnet을 바깥으로부터 보호할 수 있게됩니다.
ELB도 같은 맥락으로 바깥과의 통신은 ELB만이 하게 되고 내부 웹서버들은 Private Subnet에 위치해 직접적인 통신을 막을 수 있습니다.
VPC 생성
VPC 서비스에서 좌측 VPC메뉴로 들어가 VPC를 생성하겠습니다.
VPC 서비스에서 VPC를 생성합니다.
VPC만 과 VPC등 두 가지 선택지 중에서 VPC등을 선택하면 자동으로 Public Private Subnet이 구성되고 IGW(인터넷게이트웨이)와 NAT를 한꺼번에 연결해 주지만 저는 공부중이기 때문에 우선 VPC만 옵션으로 생성하겠습니다.
저는 IPv4 CIDR을 10.0.0.0/16으로 설정했습니다.
VPC(10.0.0.0/16)와 라우팅 테이블 하나를 자동으로 만들어줍니다.
Public Subnet , Private Subnet
좌측 메뉴에서 이제 서브넷 메뉴로 가 Public Private 서브넷을 각각 생성하겠습니다.
어떤 VPC에 서브넷이 될 지 선택합니다.
밑에 새 서브넷 추가를 눌러 Private 서브넷까지 구성하겠습니다.
사실 이렇게만 구성한다고 해서 위에 두 서브넷이 Public Private이 되는건 아닙니다.
퍼블릭 서브넷용 라우팅 테이블과 IGT(인터넷게이트웨이)를 구성해야 퍼블릿 서브넷이 완성되고
프라이빗 서브넷용 라우팅 테이블과 NAT를 구성해야 프라이빗 서브넷이 완성됩니다.
서브넷의 라우팅 테이블
다시 한 번 언급하자면 라우팅 테이블은 서브넷에서 바깥으로 나가는(아웃바운드) 트래픽의 규칙을 정의하는 용도입니다.
이제 라우팅 테이블을 서브넷에 각각 연결하면 됩니다.
작업에 라우팅 테이블 연결 편집으로 연결할 수 있습니다.
퍼블릭 프라이빗 모두 각자 연결해줍니다.
VPC메뉴로 돌아와 리소스맵을 보니 잘 연결이 돼있음을 시각적으로 확인할 수 있습니다.
Internet Gate Way 연결하기
아직까지도 퍼블릭 서브넷은 퍼블릭 서브넷의 역할을 하지 못합니다.
인터넷 게이트웨이를 설정해 바깥으로 트래픽이 나갈 수 있도록 설정해야합니다.
이제 이 인터넷게이트웨이를 우리가 만든 VPC에 연결합니다.
VPC에 연결한 뒤에 리소스맵을 보면
생성은 됐지만 라우팅 테이블에 연결돼있지 않습니다.
라우팅 테이블에 0.0.0.0/0(인터넷)으로 나가는 트래픽은 IGW로 가도록 설정해야 IGW가 트래픽을 전달할 수 있습니다.
라우팅 편집에 들어갑니다.
연결해주고나서 다시 리소스맵을 보면!
인터넷 게이트웨이가 잘 연결돼 있습니다.
11/5 수정
저도 삽질을 오래 했는데... 위 처럼 설정하면 밑에서 도입할 ELB가 잘 동작할 수 없습니다.
우선 목표를 제 목표부터 뚜렷하게 해야할 것 같은데요.
제 목표는 EC2 두 대를 VPC Private Subnet에 위치시켜 외부와 차단시킨 채로 ELB를 통해서만 통신할 수 있도록 하는 것입니다.
우선 ELB는 가용영역 2개를 선택해야 생성할 수 있습니다. (물리적으로 분산돼있어야 가용성을 높일 수 있다는것을 같습니다.)
그렇기 때문에 프라이빗 네트워크도 2개를 생성하고 NAT만 연결합니다.
AWS는 NAT를 가용영역마다 하나씩 생성하길 추천하는데 이것도 가용성을 위한 일입니다.
그리고 ELB의 대상 그룹(Target Group)은 Private Subnet에 있는 EC2 인스턴스를 타겟으로 잡아주고
ELB를 실제 생성할 때 인터넷 경계로 설정하고 가용영역 설정에선 IGW와 연결된 Public Subnet을 설정해줘야 부하분산이 제대로 작동합니다.
즉 밑에 2개의 EC2 부하분산을 위한 ELB를 위해서는 VPC 그림이
위처럼 나오는 것이 아니라
이렇게 나와야 합니다.
다시 정리하자면
ELB 생성 시 가용영역 2개 선택을 위해 최소 2개 가용영역을 생성하고 각 가용 영역에 Private Subnet을 각각 생성합니다.
각 private subnet에 EC2를 띄운 뒤에 IGW과 연결된 Public Subnet을 또 가용영역 마다 2개 생성합니다.
위 리소스맵에서 NAT는 굳이 2개 생성하진 않았습니다.
EC2에 Nginx 설치해 테스트해보기
EC2를 띄우는 건 자세히 설명하지는 않겠습니다.
아래 네트워크 설정에서 VPC와 Public Subnet을 설정해주는 것이 가장 중요합니다.
그 외엔 일반적인 EC2처럼 생성하면됩니다.
ssh 접속과 웹서버 접속이 가능하도록 아래와 같이 인바운드 규칙을 설정해줍니다.
ssh로 EC2에 진입해 간단히 nginx를 설치하겠습니다.
공인 IP로 아주 잘 연결되는걸 볼 수 있네요.
Private Subnet에 EC2를 생성하고 Public Subnet EC2에서 Private Subnet EC2 접속하기
위와 같은 방식으로 Private Subent에 EC2하나를 생성해보겠습니다.
마찬가지로 네트워크 설정이 가장 중요합니다.
Public Subnet과 달리 퍼블릭 IP를 할당하더라도 IGW가 연결돼있지 않기 때문에 직접 외부에서 접속할 수 없습니다.
public subnet에 생성한 EC2에 ssh 개인키를 저장하고 해당 EC2에서 private EC2로 접속해보겠습니다.
만약 에러가 난다면 pem 파일 권한 문제이거나 private subnet의 ec2 인바운드 규칙을 설정해야합니다.
pem 파일은 sudo chmod 400 파일명으로 권한을 주고
아웃바운드는 VPC Private IP 범위 그대로 주겠습니다.
성공적으로 잘 연결이 됐습니다.
이제 여기서 EC2를 설치해볼까요?
계속 연결 시도만 하고 절대 되지 않습니다.
저희는 아직 Private Subnet에서 트래픽이 나가도록 설정하지 않았습니다.
NAT를 구성해서 라우팅 테이블에 설정해줘야 밖으로 트래픽이 나가고 해당 트래픽의 응답을 받을 수 있습니다.
NAT 구성하고 Private Subnet Routing Table에 설정
VPC메뉴에서 NAT 게이트웨이 메뉴를 선택하고 NAT 게이트웨이를 생성해줍니다.
NAT는 퍼블릿 서브넷에 구성하고 탄력적 IP를 할당한 뒤에 생성합니다.
연결 유형에 대한 AWS 문서의 설명 내용입니다.
저희는 바깥과 통신해야하니 퍼블릭을 선택해야합니다.
생성한 뒤에 private subnet 용 라우팅 테이블 편집으로 가서 NAT를 연결합니다.
다시 nginx를 다운로드 해보겠습니다.
install도 잘 되고 Nginx가 아주 잘 실행되고 있습니다. 트래픽이 NAT를 거쳐 잘 나갔다는 뜻이죠.
Private Subnet에 EC2 하나 더 생성... 그런데 AMI를 곁들인...
EC2를 처음부터 만들지 않고 이미지(AMI)를 생성하고 이미지를 바탕으로 인스턴스를 바로 생성하면 간편하게 EC2를 만들 수 있습니다.
다만, 네트워크 설정은 위 EC2 생성과 동일하게 설정해줘야합니다.
새롭게 생성한 Private Subnet의 EC2에 Private IP로 접속합니다.
그리곤 systemctl status nginx로 nginx 상태를 보겠습니다.
AMI로 EC2를 생성한 덕분에 nginx를 설치하지 않아도 구동이 되고 있습니다.
Private Subnet의 EC2에 설치한 Nginx 테스트하기
Private Subnet의 EC2는 NAT가 있어도 밖에서 안으로 접속은 불가능합니다.
애초에 NAT의 목적은 밖에서 안으로 트래픽 전달은 하지 않도록 하고 안에서 밖으로만 전달하기위함입니다.
그렇다면 Public Subnet의 EC2에서 wget http://{private ip}로 확인해 보겠습니다.
우선 Private Subnet의 EC2 인바운드 규칙에서 80포트를 VPC Private IP 범위로 열어주겠습니다.
ELB
Private Subnet EC2는 밖으론 나갈 수 있지만 밖에서 안으로는 들어올 수가 없습니다.
ELB를 사용하면 인터넷은 ELB를 거쳐서 EC2에 도달할 수 있습니다.
사실 ELB는 VPC의 Private Subnet으로 접근하는 것 자체가 목적은 아닙니다.
타겟그룹들에게 부하를 분산하는 것이 본래의 목적입니다. 하지만 Private Subnet을 구성하고 ELB를 앞단에 두면 보안적으로도 우수하고 부하까지 분산할 수 있어 같이 잘 쓰이는 것 같습니다.
EC2 서비스의 대상 그룹 탭에 들어가 그룹을 생성해야합니다.
저희는 서브넷 안에 EC2들의 로드를 분산할 것이기 때문에 인스턴스 유형을 선택합니다.
다른건 그대로 두고 VPC만 저희가 만든 VPC로 설정합니다.
11/5 수정
각 각 다른 가용영역의 Private Subnet에 위치한 EC2 두개를 선택해야합니다.
Private Subent의 두 EC2를 선택합니다.
이제 로드밸런서 탭에 가서 로드밸런서를 생성합니다.
AWS의 로드밸런서는 ALB, NLB, GLB 세 가지 존재합니다.
ALB는 L7 Layer(Application Layer)에서 부하를 분산합니다. 즉 HTTP, HTTPS 트래픽을 분산 시키는데 IP, Port, 패킷 내용을 기준으로 부하를 세밀하게 분산시킬 수 있습니다.
NLB는 L4 Layer(Network Layer)에서 부하를 분산합니다. IP,Port를 기준으로 부하를 분산하고 더 낮은 계층에서 더 적은 헤더정보를 보고 부하를 분산하기에 ALB보다 빠릅니다.
GLB는 로드밸런싱과 더불어 인증, 로깅 등 여러 사전작업을 같이 처리할 수 있습니다.
우선 저희는 ALB를 앞에 두겠습니다.
체계에서 내부를 선택하면 바깥 트래픽을 받을 수 없기 때문에 인터넷 경계로 설정합니다.
인터넷 경계 옵션을 선택한 ELB를 생성할 때 하기쉬운 실수는 VPC 서브넷을 결정하는 과정입니다.
VPC를 선택하고 Public Subnet이 존재하는 가용영역을 선택합니다.
ALB가 80포트를 리스닝하도록 설정하고 라우팅은 앞서 설정한 대상그룹으로 선택합니다.
ALB가 프로비저닝 되는 동안 private subnet ec2의 index.html을 서로 다르게 변경해서 로드밸런싱을 테스트해보겠습니다.
Nginx index.html 수정
첫 번째 Private Subnet EC2에 들어가
cd /var/www/html 로 이동해 index.nginx-debian.html 을 수정합니다.
저는 간단하게만 수정했습니다.
오른쪽 아래 DNS이름을 복사해 접속해보면 ALB의 부하분산을 볼 수 있습니다.
'Cloud Service' 카테고리의 다른 글
| AWS ELB + AutoScaling [Scale Out] (6) | 2024.11.06 |
|---|
