[AWS] VPC 구성하고 ALB 테스트하기

우노·2024년 7월 15일
1
post-custom-banner

지금까지 단일 EC2를 활용하기에 그쳤는데 클라우드 컴퓨팅의 고가용성을 살려서 여러 AZ에 EC2를 두고 VPC를 구성하고 ALB로 로드밸런싱을 테스트해보고자 합니다. 실습인 만큼 퍼블릭으로 로드밸런서를 사용해보고 프라이빗과 NAT Gateway를 연결하는 등을 시도했습니다.

VPC를 구성하려면 네트워크에 대한 이해가 필요하니 개념부터 설명해보겠습니다. 개념 하나마다 글 하나가 나올 수 있는 단어들이라 이 글에서는 간략하게 설명하고 넘어가려고 합니다..

개념

먼저 CSP는 하나의 Region에 여러 Availability Zone을 두고 서비스를 운영합니다. 각각의 AZ는 독립적으로 운영되며 CSP는 하나의 Region에 3개 이상의 AZ를 포함하고 클라우드 리소스 사용자는 여러 AZ에 걸쳐 앱을 배포하여 고가용성, 내결함성을 보장할 수 있습니다. 예를 들어 A, B AZ에 앱을 배포한다면 데이터센터 A에 천재지변으로 문제가 생기더라도 B에 배포한 앱으로 정상적인 운영을 이어갈 수 있습니다.

VPC

= Virtual Private Cloud
퍼블릭 클라우드 환경에서 사용할 수 있는 가상 사설 네트워크입니다. 사설 네트워크를 구축하여 프라이빗 IP를 리소스에 부여하여 각각의 클라우드 리소스를 활용할 수 있습니다.
사용 사례로 필요성을 설명하자면 VPC 없이 세개의 가상머신을 사용해서 앱을 배포한다면 각각의 가상머신에 퍼블릭 IP 할당이 필요하게 됩니다. 같은 앱을 위해 배포한 가상머신끼리도 인터넷을 거쳐 비효율적으로 통신하고 로드밸런싱에도 난항을 겪게 됩니다. 하나의 퍼블릭 IP 내부에 VPC를 구축한다면 리소스를 하나의 네트워크로 묶어 관리할 수 있게 되므로 호출 관리와 VPC 내부에 로드밸런서를 배치가 강점이 될 수 있고 백엔드-데이터베이스 간의 통신도 하나의 네트워크 내부에서 동작하므로 VPC가 없을 때보다 효율적입니다.

Subnet

네트워크 내부의 네트워크로 네트워크를 효율적으로 활용할 수 있게 합니다. 서브넷이 없을 때에는 IP를 클래스로 구분하였습니다. 하지만 할당할 수 있는 호스트가 많은 A 클래스의 효율적인 활용이 어렵고 A 클래스에서 호스트를 찾기까지 시간이 걸리는 등의 문제가 생기며 서브넷으로 IP를 유연하게 나누어쓰기 시작했고 이것이 CIDR(Classless Inter-Domain Routing)입니다. VPC에서는 서브넷을 IP 주소 범위 지정을 위해 사용하며 VPC에서 서브넷으로 네트워크 범위를 나누어 퍼블릭, 프라이빗 등으로 개별적으로 활용할 수 있습니다.

서브넷에서는 Routing Table을 사용합니다. Routing Table은 네트워크 트래픽을 리소스로 라우팅하여 타겟 IP를 찾아가는 길잡이 역할을 담당합니다.

Internet Gateway

수평 확장되고 가용성이 높은 중복 VPC 구성 요소로, VPC와 인터넷 간에 통신할 수 있게 합니다. IP를 이용하여 퍼블릭 서브넷의 리소스를 인터넷에 연결하거나 반대로 인터넷의 리소스가 서브넷에 연결될 수 있습니다.

NAT Gateway

= Network Address Translation Gateway
Network Address Translation는 네트워크 주소 변환으로써 라우터를 통해 트래픽을 주고받을 수 있도록 하며 NAT Gateway는 네트워크 주소 변환 서비스로써 프라이빗 서브넷의 인스턴스의 외부 서비스에서 보내는 인바운드 트래픽은 제한하고 외부 서비스로 보내는 아웃바운드 트래픽은 활성화하는 역할을 합니다.

  • public: default로 위에서 설명한 인바운드, 아웃바운드 트래픽 제어를 수행합니다.
  • private: 외부 서비스가 아닌 다른 VPC 또는 온프레미스 네트워크와의 통신을 지원합니다.

Load Balancer (+AWS ELB)

로드밸런서는 트래픽을 여러 서버로 분산시켜 컴퓨터 자원을 효율적으로 사용할 수 있동록 하며 보통 외부 트래픽을 받아서 내부로 분산 시켜주는 장치를 말합니다.
로드밸런서는 라운드 로빈, 가중 라운드 로빈 등의 로드밸런싱 알고리즘으로 부하를 분산하며 AWS ELB에서는 ALB, NLB, GLB, CLB를 지원합니다.

  • ALB (Application LB) = HTTP/HTTPS 최적화 7계층 로드밸런서
  • NLB (Network LB) = 고성능을 요구하는 TCP, UDP 및 TLS 트래픽에 최적화된 4계층 로드밸런서
  • GLB (Gateway LB) = 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 규모 조정 및 관리
  • CLB (Classic LB) = 구형 로드밸런서 - 4계층 + 7계층 로드밸런서

참고 및 출처: What is Amazon VPC?, AWS Elastic Load Balancing

실습

VPC 구성하기

AZ 두개에 리소스를 배치하여 VPC를 구성해보려고 합니다.
먼저 VPC에서 서브넷을 생성하여 각 AZ와 퍼블릿/프라이빗 별로 네트워크를 지정했습니다.

  • Region: ap-northeast-2 (서울)
  • AZ: ap-northeast-2-a, ap-northeast-2-c
  • VPC IPv4 CIDR: 192.168.0.0/16
  • Subnet
    - private-a: 192.168.1.0/24
    - public-a: 192.168.2.0/24
    - public-c: 192.168.3.0/24
    - public-nat: 192.168.4.0/24 - 성능을 위해서 private과 같은 Region 권장

Public - VPC Internet Gateway 설정

VPC의 인터넷 통신을 위해 인터넷 게이트웨이를 생성하여 VPC에 연결했습니다. 그리고 라우팅 테이블을 생성하여 라우팅 편집을 통해 인터넷 게이트웨이에 연결하고 명시적 서브넷 연결에 public으로 시작하는 서브넷을 추가했습니다.

VPC에 인터넷 게이트웨이가 연결되지 않는다면 퍼블릭IP를 할당받고 보안규칙을 0.0.0.0으로 허용하더라도 해당 인스턴스를 인터넷에 연결할 수 없습니다. 마찬가지로 라우팅 테이블을 설정하지 않으면 타겟 IP를 찾을 수 없으므로 인터넷에 연결되지 않습니다.

그동안 VPC 구성과 인터넷 게이트웨이 없이도 단일 인스턴스로 인터넷과 통신할 수 있었다고 주장해도 그건 이미 default로 제공되는 인터넷 게이트웨이와 라우팅 테이블 등의 네트워크 설정을 활용했기에 가능했던 것입니다.

Private - VPC NAT Gateway 설정

private 서브넷은 이름 그대로 인터넷을 통한 사설 네트워크로의 인바운드 트래픽을 허용하지 않습니다. 하지만 NAT Gateway를 통해 아웃바운드 트래픽을 허용할 수 있습니다.
VPC에서 NAT Gateway를 생성하여 앞서 생성한 public-nat 서브넷을 지정하고 연결 유형을 퍼블릭으로 설정하면 인터넷으로의 아웃바운드 트래픽을 허용할 수 있게됩니다. 프라이빗은 주로 하이브리드 클라우드 환경에서 사용되며 인터넷이 아닌 VPC 네트워크 연결, VPN 연결, 또는 온프레미스 네트워크와 통신할 때 설정할 수 있습니다.

private도 public과 마찬가지로 Routing Table을 생성하고 라우팅 편집을 통해 NAT 게이트웨이에 연결하고 private으로 시작하는 서브넷을 명시적으로 연결합니다.

EC2 네트워크 설정 및 생성

public-nat를 제외한 3개의 서브넷에 연결할 인스턴스를 생성합니다.

  1. 인바운드 규칙에서 SSH와 HTTP를 허용하여 인스턴스에 접근을 허용하는 보안 규칙 생성
  2. OS, 인스턴스 유형 선택
  3. 네트워크 설정에서 VPC와 서브넷을 설정하고 public 서브넷에는 퍼블릭 IP 자동 할당을 활성화

중간 점검 - VPC 리소스 맵

지금까지 생성한 리소스는 다음과 같이 연결되어있으며 public-nat를 제외한 서브넷에 각각 인스턴스가 연결되어있습니다.

ALB 생성, 연결 - Public

EC2 메뉴에서 로드밸런서 생성으로 Application Load Balancer를 생성합니다.
인터넷에서 통신할 것이기 때문에 인터넷 경계로 체계를 설정하고

네트워크 매핑으로 VPC를 설정하고 로드밸런서에 연결할 서브넷을 설정합니다.
보안 그룹도 이전 인스턴스 생성에 사용했던 보안 그룹으로 설정해주었습니다.

ALB 테스트

public-a, public-c 인스턴스에서 간단한 애플리케이션을 돌리고 요청 IP를 확인하는 로그를 찍어보면 다음과 같이 public-a: 192.168.2.0/24, public-c: 192.168.3.0/24에 맞는 IP가 찍히는 것을 알 수 있고 ALB에서 DNS 레코드로 들어가서 새로고침 해도 192.168.2.0과 192.168.3.0이 번갈아서 나오는 것을 알 수 있습니다.

다이어그램

간단하게 그린 다이어그램은 다음과 같지만.. 아직 이 다이어그램에 확신이 생길 만큼 이해하고 있다고 느끼지 못하고 있어서 하나하나 다시 뜯어보려고 합니다.
오류가 보이시는 고수분 계시면 꼭 알려주세요...!!!!

마무리

항상 default 네트워크를 활용하다가 직접 VPC를 구성하는 것이 새로웠고 생각보다 많은 설정이 필요하다는 것을 알게 되었습니다. 그리고 로드밸런서를 직접 활용하고 트래픽이 나눠지는 것을 보며 필요성을 다시금 실감하게 되었습니다.
컴퓨터통신 과목이 종강한지 약 반년이 되었는데 오랜만에 네트워크 개념도 다시 잡고 VPC 다이어그램도 그리고 서비스 설정도 하는 것이 흥미로웠고 IaC로도 VPC 구성해보고 싶다는 생각이 들었습니다..!

IaC-practice Iac로 VPC를 구성을 해보았습니다!

profile
기록하는 감자
post-custom-banner

0개의 댓글