AWS | 토이프로젝트 운영서버 구축기 (4) - NAT Gateway와 ELB 설정

* 토이 프로젝트를 진행하면서 AWS를 이용하여 Spring 기반의 운영 서버를 구축한 내용을 정리했습니다.

 

 이번 포스팅에서는 프라이빗 EC2 인스턴스에 NAT Gateway와 Load balancer를 연결하는 방법에 대해 알아보겠습니다. 전체적인 인프라 구조와 EC2 생성 방법은 이전 포스팅을 참고해주세요!

 

* 이전 포스팅

AWS | 토이프로젝트 운영서버 구축기 (1) - 인프라 모델링

AWS | 토이프로젝트 운영서버 구축기 (2) - Public subnet EC2 인스턴스 생성

AWS | 토이프로젝트 운영서버 구축기 (3) - Private subnet EC2 인스턴스 생성

 

0. NAT Gateway? Load Balancer?

0-1. NAT Gateway

 프라이빗 서브넷 내의 인스턴스는 같은 VPC 내의 인스턴스와만 통신이 가능하기 때문에 프라이빗 인스턴스 내에서 외부 서비스로의 접근은 막혀있습니다. 하지만, 프라이빗 EC2 인스턴스에 기본적인 개발환경을 세팅하기 위해서는 (ex. Docker, MySQL 다운로드 등..) 외부 서비스로의 접근이 필요합니다. 이 때, NAT 게이트웨이를 설정해주면 외부로의 통신이 가능해집니다. 

 즉, NAT(Network Address Translation) 게이트웨이는 프라이빗 서브넷에 위치한 인스턴스가 외부 인터넷을 사용할 수 있도록 도와주는 서비스 입니다. VPC 내에서 외부로의 접근(아웃바운드)은 허용하나 외부에서 VPC 내로의 접근(인바운드)은 허용하지 않습니다.

0-2. Load Balancer

 로드 밸런서는 서버에 가해지는 부하를 분산해주는 분산처리 시스템입니다. 서버가 여러개의 EC2 인스턴스로 운영이 되거나 하나의 EC2 내의 여러개의 프로세스로 실행 중일 경우, 클라이언트로부터 들어오는 요청은 로드 밸런서에서 전부 모이게 되고 로드 밸런서가 각각의 서버로 요청을 분배하여 효과적으로 처리하도록 도와줍니다. 로드 밸런서는 주기적으로 서버의 Health check를 진행하여 정상 운영 중인 서버로만 요청을 전달합니다.

 

1. NAT Gateway 설정

 프라이빗 EC2 인스턴스에 웹 서버를 띄우기 위해 도커 설치가 필요합니다. yum 명령어로 도커 패키지를 다운로드 받으려 하였는데..!

설치 실패.. 커넥션 타임아웃..

 프라이빗 인스턴스는 같은 VPC내의 인스턴스끼리만 트래픽을 주고 받으니 외부 서비스로 접근이 불가능합니다. 성공적으로 설치하기 위해서 NAT Gateway를 연결해봅시다! AWS 콘솔에서 "VPC 서비스 > NAT 게이트웨이 > NAT 게이트웨이 생성" 메뉴에서 NAT 게이트웨이를 생성합니다.

 

 

 NAT 게이트웨이는 외부 인터넷과 연결이 가능해야 하므로 연결 유형은 퍼블릭, 서브넷도 퍼블릭 서브넷으로 선택해줍니다. 게이트웨이에 고정 IP를 할당해주어야 하므로 탄력적 IP를 할당해주고 NAT 게이트웨이를 생성합니다.

 

 NAT 게이트웨이를 생성했으니 라우팅 테이블 설정을 통해 프라이빗 서브넷 내부에서 외부로의 요청을 NAT 게이트웨이로 향하게 합니다. VPC에는 암시적 라우터가 있으며 라우팅 테이블을 사용하여 네트워크 트래픽이 전달되는 위치를 제어할 수 있습니다. "VPC 서비스 > 라우팅 테이블 > 라우팅 테이블 생성" 메뉴에서 라우팅 테이블을 생성합니다.

cf. AWS 라우팅 테이블 공식 문서

 

 

 이름과 현재 작업중인 VPC를 선택하고 라우팅 테이블을 생성하면 서브넷이 연결되지 않은 라우팅 테이블이 생성됩니다.

 

 

 라우팅 테이블 세부 정보에서 서브넷 연결 편집이 가능합니다.

 

 

 프라이빗 서브넷 내의 인스턴스의 네트워크 트래픽을 NAT 게이트웨이로 향하게 할 라우팅 테이블이므로 프라이빗 서브넷을 선택해줍니다.

 

 

 라우팅 테이블 세부정보에서 라우팅 설정을 편집합니다.

 

 

 기본적으로 VPC IP 범위내의 요청은 모두 local로 향하게 되어있습니다. 라우팅 추가를 통해 모든 트래픽을 NAT 게이트웨이로 향하게 합니다. 

 

정상적으로 세팅이 완료되었다면 도커 다운로드가 가능해집니다.

정상적으로 프라이빗 인스턴스 내의 트래픽이 외부로 전송!

 

2. 도커로 웹 애플리케이션 띄우기

 프라이빗 EC2 인스턴스에 도커 설치가 되었으니 외부에 서비스할 웹 서버를 띄워봅시다. 사용할 도커 이미지는 테스트용 웹 서버 이미지를 개인 도커 허브에 올려두었습니다. 이 웹 서버는 Health check용 API("GET /system/check") 만을 제공합니다.

 

# docker service 실행
> sudo service docker start

# docker container 띄우기
> docker run -d -p 8081:8080 --name api-server1 younger33/aws-test
> docker run -d -p 8082:8080 --name api-server2 younger33/aws-test

# docker container 상태 확인
> docker ps

# application 정상 동작 확인
> curl http://localhost:8081/system/check
> curl http://localhost:8082/system/check

 

 프라이빗 EC2 인스턴스의 8081 포트와 8082 포트에 웹 서버를 실행시켰습니다. 정상적으로 서비스가 동작한다면, "GET /system/check" 요청 시에 "system is running..." 이라는 문자열이 리턴됩니다.

 

 두 개의 웹 서버를 성공적으로 생성하였으나 지금 상태로써는 VPC 외부에서의 접근이 불가하여 정상적인 서비스 제공이 불가능한 상태입니다. 퍼블릭 서브넷에 로드 밸런서를 생성한 후 프라이빗 EC2 인스턴스와 연결하면 로드 밸런서를 통해 외부에서도 접근 가능한 서비스로 만들 수 있습니다.

 

3. ELB (Elastic Load Balancer) 설정

 AWS에서는 간단하게 로드 밸런서를 세팅할 수 있도록 ELB 서비스를 제공합니다. 로드 밸런서와 연결할 타겟 그룹과 로드 밸런서를 생성하고 보안 그룹을 설정하여 외부 브라우저에서 HTTP 요청을 받을 수 있도록 인프라를 구성해보도록 하겠습니다.

3-1. 타겟 그룹 생성

 로드 밸런서에서 분산 처리를 진행할 대상이 되는 타겟 그룹을 생성합니다. 위의 예제를 예시로 들면 프라이빗 EC2 인스턴스의 8081, 8082 포트가 타겟 그룹이 됩니다. "EC2 서비스 > 로드 밸런싱 > 대상 그룹 > 대상 그룹 생성" 메뉴에서 생성이 가능합니다.

cf. 타겟 그룹에 대한 AWS 공식 문서

 

 

 타겟의 타입은 Instance, 프로토콜은 HTTP로 선택합니다. Health checks는 타겟 서비스가 정상적으로 동작하는지 확인할 수 있는 API 경로를 입력합니다. 로드 밸런서에서 주기적으로 설정된 경로로 요청을 보내 서비스가 살아있는지 확인을 수행하며 정상 동작중인 타겟으로만 요청을 전달합니다. 위의 예제에서 생성한 웹 애플리케이션은 /system/check 경로를 통해 서비스의 동작을 확인할 수 있습니다. 

 

 

 다음 설정에서는 타겟을 등록합니다. 웹 애플리케이션이 올라가있는 EC2 인스턴스를 선택하고, 해당 인스턴스 내에서 웹 애플리케이션이 동작하고 있는 포트 번호를 입력합니다. 한 인스턴스 내에 여러 포트에 웹 애플리케이션이 연결되어 있을 경우 콤마(,)로 구분지어 포트를 여러개 설정이 가능합니다.

3-2. 로드 밸런서용 보안 그룹 생성

 로드 밸런서를 생성하기에 앞서 연결할 보안 그룹을 먼저 생성합니다. 외부 웹 서비스용 로드 밸런서이므로 모든곳에서 HTTP, HTTPS 요청을 허용합니다.

 

3-3. 로드 밸런서 생성

 로드 밸런서를 생성하기 위해 모든 준비가 끝났습니다! 로드 밸런서를 생성해봅시다.

 

 AWS에서 제공하는 로드 밸런서는 4가지 타입이 있습니다. 예제에서는 HTTP/HTTPS 프로토콜에 대해 타겟 그룹을 설정해주고 SSL 인증서까지 적용해보고자 하니 ALB를 선택했습니다. 각 타입에 대한 설명은 아래와 같습니다.

 

1. Application Load Balancer (ALB)

 OSI 7계층에서 일곱 번째 계층인 애플리케이션 계층에서 작동하여 HTTP/HTTPS 프로토콜을 지원하는 로드 밸런서 입니다. L7단을 지원하기 때문에 단순 분산 뿐만 아니라 HTTP 헤더정보를 이용한 분산이 가능하여 API 경로에 따라 다른 타겟 그룹을 매핑할 수 있고, ACM(AWS Certificate Manager) 서비스를 이용하면 간단하게 SSL 인증서를 연결할 수 있다. DNS 기반으로 생성되어 IP는 유동적으로 변경된다.

cf. ALB에 대한 AWS 공식 문서

2. Network Load Balancer (NLB)

 OSI 7계층에서 네 번째 계층인 전송 계층에서 작동하여 TCP와 UDP를 지원하는 로드 밸런서 입니다. 애플리케이션 계층의 하위 계층에서 처리가 진행되므로 HTTP 헤더 정보는 분석이 불가하여 API 경로에 따른 매핑은 불가능하고 SSL 인증서는 애플리케이션단에 따로 적용시켜주어야 한다. 공인 IP를 고정하여 사용이 가능하고 네 번째 계층까지만 확인 후 분산 처리를 진행하기 때문에 ALB에 비해 트래픽 처리 속도가 빠르므로 대용량 트래픽의 단순 라우팅에 적합하다.

 cf. NLB에 대한 AWS 공식 문서

 

3. Gateway Load Balancer (GWLB)

 OSI 7계층에서 세 번째 계층인 네트워크 계층에서 작동하는 로드 밸런서 입니다. 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포 및 관리할 수 있습니다. 

cf. GWLB에 대한 AWS 공식 문서

 

4. Classic Load Balancer (CLB)

 OSI 7계층에서 네 번째, 일곱 번째 계층에서 작동하며 AWS에서 초기에 제공하던 로드 밸런서 입니다. 하나의 타겟 그룹만 설정이 가능하여 다른 타겟 그룹을 로드 밸런싱 하고자 한다면 새로운 로드 밸런서를 생성해주어야 하는 번거로움이 있습니다. 즉, 타겟 그룹별로 다른 DNS 주소로 관리되어 불편함이 있습니다. 현재는 레거시로 분류되어 잘 사용되지 않습니다.

cf. CLB에 대한 AWS 공식 문서

cf. 4가지 로드 밸런서에 대한 비교

 

 

 로드 밸런서는 외부에서 접근이 가능하도록 퍼블릭 서브넷에 위치시킵니다. 최소 2개의 가용 영역에 대해 설정해주어야 하므로 가용영역 두 군데에 퍼블릭 서브넷을 지정해주었습니다.

 

 

 위에서 생성한 로드 밸런서용 보안 그룹을 지정해줍니다.

 

 

 다음은 리스너 설정입니다. HTTP 프로토콜 80번 포트에 대해서 위에서 생성한 웹 애플리케이션 타겟 그룹을 지정해줍니다. 이제 로드 밸런서의 80번 포트로 들어오는 HTTP 요청에 대하여 지정된 타겟 그룹으로 요청이 전달되게 됩니다.

 

 

 생성 후 상세 화면입니다. ALB는 고정 IP를 설정할 수 없기 때문에 DNS 이름으로 접근해주어야 합니다. 이제 웹 브라우저에서 로드 밸런서의 DNS로 HTTP 요청을 하면 타겟 웹 애플리케이션으로 요청이 전달됩니다!

하지만, 요청을 하기에 앞서 웹 애플리케이션이 올라가 있는 프라이빗 EC2의 보안 규칙을 설정해주어야 요청이 정상적으로 완료됩니다.

3-4. 프라이빗 EC2 보안 그룹 설정

 로드 밸런서가 프라이빗 EC2로 접근을 할 수 있도록 보안 그룹을 설정합니다. 프라이빗 EC2의 인바운드 규칙에서 로드 밸런서의 보안 그룹에 대해 웹 애플리케이션이 동작하고 있는 8081, 8082포트 접근을 허용해줍니다. 허용을 해주지 않으면 아무리 같은 VPC내의 인스턴스라 하더라도 접근이 불가합니다.

3-5. 로컬 브라우저에서 HTTP 요청

예제용 도커 이미지를 사용했다면 "{로드밸런서 DNS}/system/check" 로 요청에 대해 "system is running..." 문자열이 반환됩니다.

 

 

 

여기까지 프라이빗 EC2 인스턴스 내부에서 외부 인터넷과 통신을 위한 NAT Gateway와 프라이빗 인스턴스의 외부 서비스 제공을 위한 ELB에 대해 알아보았습니다. 다음 포스팅에서는 로드 밸런서에 ACM(AWS Certificate Manager)을 이용하여 SSL 인증서를 적용하는 방법에 대해 알아보겠습니다.