개발용 인프라 구축

 

새 학기를 맞이하여 개발팀에 AI 개발자 2명과 백엔드 개발자 1명을 새로 영입했습니다.

본격적인 개발을 시작하기 전에, AWS를 활용하여 새로운 개발용 인프라를 구축하기로 결정했습니다.

 

 

개발 환경을 고려하여 비용 효율성을 높이기 위해, Private Subnet에 MariaDB 서버를 배치하는 대신, 하나의 EC2 인스턴스에 여러 컨테이너를 배포하는 방식을 선택했습니다.

 

구체적으로, docker-compose를 사용하여 한 대의 EC2 인스턴스에 1개의 Nginx, 2개의 웹 애플리케이션 서버(WAS), 그리고 MariaDB와 Redis를 함께 올렸습니다.

 

이렇게 함으로써, 개발 환경을 효율적으로 관리하고 비용을 절감할 수 있게 되었습니다.

 

 

 

해당 인프라의 요청 흐름은 대략 아래와 같습니다.

 

 

외부 트래픽 → 인터넷 게이트웨이 → VPC → 라우팅 테이블 → public 서브넷 → 내부 인스턴스

 

VPC

 

VPC는 클라우드 환경에서 사용자 전용의 사설 네트워크입니다.

 

VPC를 사용해야하는 이유는 무엇일까?

 

VPC가 없다면, 인스턴스들을 논리적으로 분리하지 못 하고, 인터넷이 인스턴스들과 다 연결되어있어야합니다.

 

 

반면, VPC가 있다면, 논리적으로 분리가 가능하고 해당 VPC에 있는 인터넷 게이트와 인터넷만 연결되어있으면 됩니다. 즉, 시스템의 복잡도를 낮출 수 있습니다. 

 

 

서브넷

서브넷은 VPC를 더 잘게 쪼갠 것이다.

 

 

네트워크 내에는 여러 서브넷이 존재하며, 서브넷을 사용하는 이유는 아래와 같습니다.

 

• 역할 분리: 서비스의 공개 여부에 따라 리소스를 구분합니다. 예를 들어, 로드 밸런서는 외부에 공개되는 반면, 데이터베이스 서버는 외부에 공개되어서는 안 됩니다.
  
  
• 기기 분리: AWS 내에서 물리적 이중화를 통해 기기 고장에 대비합니다. 이는 장애 발생 시 서비스의 연속성을 보장하기 위함입니다.

 

서브넷에는 크게 두 가지 유형이 있습니다.

 

• Public 서브넷: 인터넷 게이트웨이에 연결되어 외부 인터넷과 통신할 수 있는 서브넷입니다.
  
  
• Private 서브넷: 인터넷 게이트웨이에 연결되지 않고, 내부 네트워크에서만 사용되는 서브넷입니다.

 

개발 환경에서는 비용 절감을 위해 MariaDB를 직접 사용하지 않았기 때문에, public 서브넷만을 사용하였습니다.

이렇게 하면 외부 인터넷과의 연결이 필요한 리소스에 대해 접근성을 확보하면서도, 불필요한 비용을 줄일 수 있습니다.

 

인터넷 게이트웨이

 

VPC에서 생성된 네트워크와 인터넷(VPC 외부) 사이의 통신을 가능하게 하는 관문이다. 인터넷 게이트웨이가 없으면, 외부와의 통신이 되지 않는다.

 

 

즉, 인터넷 게이트웨이는 VPC와 외부 인터넷 간의 주요 연결 통로 역할을 합니다.

그리고, 인터넷 게이트웨이를 통해 들어오고 나가는 트래픽을 관리하고 해당 트래픽이 어느 서브넷과 연결 되는 지 또한 관리합니다.

마지막으로, 사설 IP 주소와 공인 IP 주소간의 상호 변환을 담당합니다.

 

 

라우팅 테이블

서브넷 혹은 게이트웨이를 통해서 네트워크 트래픽이 어디로 향하는 지에 대해 결정할 대 사용한다.

 

 

라우팅 테이블에는 메인 라우팅 테이블, 서브넷 라우팅 테이블, 게이트웨이 라우팅 테이블 등이 있다.

 

개발집에서 사용하는 것은 메인 라우팅 테이블로 서브넷과 직접 연결하는 서브넷 라우팅 테이블과 VPC의 퍼블릭 서브넷과 인터넷 게이트웨이가 연결된 게이트웨이 라우팅 테이블을 사용한다.

 

라우팅 테이블의 구성은 아래와 같다.

 

• Destination : IPv4의 모든 주소를 나타내는 0.0.0.0/0
• Target : igw - id

 

로드 밸런서

 

로드 밸런서의 본래 역할은 가용 영역에 있는 대상으로 들어오는 트래픽을 자동으로 분산시켜주는 서비스이다.

 

 

로드 밸런서는 일반적으로 트래픽을 여러 서버에 분산시켜 부하를 관리하는 데 사용합니다.

하지만, 개발집의 개발 환경에서는 로드 밸런서를 SSL 처리를 위해 사용하였습니다.

 

왜냐하면, 개발 환경에서는 하나의 EC2 인스턴스에 여러 애플리케이션과 서비스를 운영하고 있기 때문에, 웹 서버에 부담이 쉽게 가중될 수 있습니다.

 

이를 해결하기 위해, SSL 처리 작업을 ELB(Application Load Balancer)가 담당하도록 설정했습니다. 이렇게 하면 EC2 인스턴스에 가해지는 부하를 줄일 수 있습니다.

 

특히, 사용 중인 EC2 인스턴스가 t2.micro 타입인 점을 고려할 때, 이러한 부하 분산 및 처리 최적화는 더욱 중요합니다. t2.micro 인스턴스는 제한된 컴퓨팅 리소스를 가지고 있기 때문에, ELB를 통해 SSL 처리를 분리함으로써 인스턴스의 성능을 보다 효율적으로 관리할 수 있습니다.

Load Balancer가 SSL 처리를 수행하는 간략한 구조는 아래와 같다.

 

해당 구조를 간단히 설명하자면, 서버로 Request가 들어오면, Load Balancer는 요청이 htttps인 지 확인한다.

만약, https라면 요청을 그대로 target group의 8080번 포트로 요청을 Forwarding하고 아니라면, https로 redirection을 한다.

(SSL 처리를 Load Balancer에서 수행하고 있다.)

• http(port 80), https(port 443)은 클라이언트에서 외부 서버로 가는 것
• Load Balancer에서 내부 서버로 이동하는 것은 8080포트를 이용한 포트 포워딩이다.(Spring Boot의 Default Port)

 

지금까지 AWS를 활용하여 구축한 개발용 인프라였습니다.