사이드 프로젝트를 AWS에 배포하는 과정을 기술합니다.
인프라 구성도
저희 사이드 프로젝트는 5월부터 약 한 달간 운영되는 서비스로 트래픽을 전혀 예상할 수 없고 비용을 최대한 아끼는 쪽으로 인프라를 구성할 계획입니다.
이번 시간에는 간단히 설명을 진행하고 이후 시리즈로 각 단계별로 자세히 다뤄보겠습니다.
배포
배포는 GithubAction과 CodeDeploy를 통해 이루어집니다.
release 브랜치에 코드가 merge 혹은 push 되면 Github Action에 의해 빌드되고 S3로 ZIP파일이 업로드됩니다. 이후 EC2에 CodeDeploy Agent가 S3에 접근하여 각각에 EC2에 배포를 진행합니다. EC2에는 Nginx가 리버스 프록시로 사용하고 뒤에 각각의 애플리케이션이 배포됩니다. 무중단 배포를 위해서 블루-그린 방식으로 배포됩니다.
서브네팅
퍼블릭 서브넷에 로드밸런서와 EC2가 올라가고 프라이빗 서브넷에 RDS가 올라갑니다. EC2 또한 프라이빗 서브넷에 배치시킨 것이 좋지만 배포 진행 시에 NAT Gateway나 VPC엔드포인트가 필요하기에 비용절감을 위해 퍼블릭에 배치하였습니다. 또한 각각의 서브넷은 서로 다른 가용영역에 배치하여 고가용성을 높이는 것이 좋지만 네트워크 전송 비용이 발생하여 하나의 가용영역에 배치하였습니다.
로드밸런서
하나의 로드밸런서에서 URL의 서브도메인으로 프론트엔드 서버가 있는 오토스케일링 그룹과 백엔드 서버가 있는 오토스케일링 그룹으로 라우팅 합니다. 이는 하나의 도메인과 하나의 WAF를 사용하여 비용을 절감하기 위함입니다.
EC2
프론트엔드 서버와 백엔드 서버 두 개의 EC2가 존재하며 각각 다른 오토스케일링 그룹으로 묶여있습니다. 각 서버에는 Nginx가 리버스 프록시 역할을 하며 Nginx와 애플리케이션 모두 컨테이너로 올라갑니다.
S3
S3에서는 버킷정책을 통해 특정 조건에만 이미지 파일을 제공할 수 있도록 합니다.
용어 설명
VPC
AWS의 가상 네트워크로 AWS 계정을 생성하면 기본 VPC 네트워크가 생성됩니다. VPC는 여러 가용 영역(물리적 서버)에 걸쳐 생성할 수 있습니다.
서브넷
현재 인터넷상에서 컴퓨터나 장치들이 통신하기 위해 Ipv4 주소 체계를 주로 사용하고 있습니다. IPv4는 32비트 주소 체계를 사용하여 2^32, 약 4억 개의 주소를 나타낼 수 있습니다. 처음 설계 시에는 충분히 전 인류가 충분히 나눠 쓸 수 있을 거라 생각했지만 곧 턱없이 부족하다는 걸 깨닫고 IPv6라는 체계를 만들기도 했지만 여전히 IPv4를 많이 사용하고 있습니다. IPv4 체계에서는 부족한 개수를 보완하기 위해 공인 IP와 사설 IP, 서브넷을 사용하며, 네트워크 영역을 나눕니다.
공인 IP는 인터넷에서 공개적으로 사용 가능한 IP 주소이며, 인터넷 서비스 제공자(ISP)로부터 할당받습니다. 이는 인터넷상에서 고유한 IP 주소를 갖게 됩니다. 반면에, 사설 IP는 내부 네트워크에서 사용하는 IP 주소로, 공인 IP 주소와는 달리 인터넷에서 접근할 수 없습니다.
예를 들어, 회사 내부에서 사용하는 서버와 컴퓨터는 사설 IP 주소를 가지며, 인터넷과 통신하는 라우터나 게이트웨이(공유기라고 생각하면 쉬워요)는 공인 IP 주소를 사용합니다.
서브넷은 네트워크를 분할하여 관리하기 위한 방법으로, 각 서브넷은 고유한 IP 주소 범위를 가지고 있습니다. 이때, 사설 IP 주소는 서브넷 내에서 사용되는 IP 주소 범위를 나타내며, 공인 IP 주소는 서브넷을 통해 인터넷과 통신할 때 사용됩니다. 일반적으로, 서브넷은 사설 IP 주소 범위를 사용하여 내부 네트워크를 관리하고, 공인 IP 주소는 인터넷과 통신하기 위해 사용됩니다. 서브넷을 통해 내부 네트워크를 효율적으로 관리할 수 있으며, 보안성도 높일 수 있습니다.
NAT Gateway
NAT(Network Address Translation) Gateway는 사설 네트워크와 인터넷 사이에서 동작하는 네트워크 장비로, 사설 네트워크의 호스트들이 인터넷에 접속하기 위해 필요한 IP 주소 변환을 처리합니다. NAT Gateway는 인터넷에 연결된 공인 IP 주소를 갖는 네트워크 인터페이스와 사설 IP 주소를 갖는 로컬 네트워크 인터페이스를 가지고 있으며, 로컬 네트워크의 호스트들이 인터넷에 접속할 때는 NAT Gateway를 경유하여 공인 IP 주소로 패킷을 전송합니다. NAT Gateway는 이러한 패킷을 받아서 출발지 주소를 자신의 주소로 변경한 후에 인터넷으로 전송하며, 인터넷에서 도착한 응답 패킷을 다시 출발지 주소를 변환하여 로컬 네트워크의 호스트에게 전달합니다. NAT Gateway를 사용하면, 사설 네트워크의 호스트들은 공인 IP 주소를 할당받지 않고도 인터넷에 접속할 수 있으며, 동시에 로컬 네트워크의 보안성도 높일 수 있습니다.
VPC Endpoint
VPC(Virtual Private Cloud) 엔드포인트는 AWS 내에서 VPC와 AWS 서비스 간의 네트워크 트래픽을 안전하게 전송하기 위한 서비스입니다. VPC 엔드포인트를 사용하면 VPC 내의 인스턴스와 AWS 서비스 간의 네트워크 트래픽을 공용 인터넷을 거치지 않고 AWS의 전용 네트워크를 통해 안전하게 전송할 수 있습니다.
오토스케일링 그룹
보통 클라우드 서비스를 사용할 때, 인스턴스(가상 머신)를 직접 생성하고 관리해야 합니다. 이 경우에는 사용자의 트래픽이 많아지면, 수동으로 인스턴스를 추가로 생성해야 하며, 트래픽이 줄어들면, 인스턴스를 수동으로 줄여야 합니다. 이런 일은 매우 번거로운 작업이며, 또한 실수로 인해 서버에 장애가 발생할 수도 있습니다. 이런 문제를 해결하기 위해, 오토 스케일링 그룹을 사용하면, 서버 인스턴스의 수를 자동으로 증가시키거나 감소시켜, 트래픽의 변화에 대응할 수 있습니다.
WAF
WAF(Web Application Firewall)란 웹 애플리케이션에서 발생할 수 있는 다양한 보안 위협을 탐지하고 차단하는 보안 장치입니다. 일반적으로, 웹 애플리케이션은 외부에서 접근 가능한 인터넷상에 위치하므로 다양한 보안 위협에 노출됩니다. 이러한 보안 위협에는 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 브루트포스 공격 등이 있습니다. 이러한 보안 위협은 웹 애플리케이션에 대한 취약점을 이용하여 공격자가 악성 코드를 주입하거나 원치 않는 데이터를 노출시키는 등의 피해를 입힐 수 있습니다. WAF는 이러한 공격을 방지하기 위해 웹 애플리케이션에 대한 모든 트래픽을 모니터링하고, 악성 행위를 감지하면 차단합니다.
블루그린 배포 방식
블루 그린 배포(Blue-Green Deployment)란, 실제 운영 중인 서비스와 완전히 동일한 환경(Blue Environment)과 새로운 버전의 서비스를 배포할 환경(Green Environment)을 따로 구성하여, 배포를 전환하는 방식입니다. 기존 서비스를 운영 중인 Blue Environment와 배포할 Green Environment를 병렬로 운영하며, Green Environment에서 새로운 버전의 서비스를 배포하고 Blue Environment에서는 기존 버전을 계속 운영합니다. 그리고 Green Environment에서 배포한 새로운 버전의 서비스가 안정화되면, Blue Environment에서 Green Environment로 트래픽을 전환하면서 새로운 버전의 서비스를 운영할 수 있습니다. 이 방식은 기존 서비스의 운영 중단 없이 새로운 버전을 안전하게 배포할 수 있는 장점이 있습니다. 또한, 문제가 발생할 경우, Blue Environment로 즉시 롤백이 가능하기 때문에 배포 롤백 시간을 최소화할 수 있습니다.
'DevOps > AWS' 카테고리의 다른 글
[Github Actions] NestJS 애플리케이션 AWS에 배포하기 06 (0) | 2023.03.23 |
---|---|
[RDS] NestJS 애플리케이션 AWS에 배포하기 04 (0) | 2023.03.19 |
[ALB, EC2] NestJS 애플리케이션 AWS에 배포하기 03 (0) | 2023.03.17 |
[VPC, Subnet] NestJS 애플리케이션 AWS에 배포하기 02 (0) | 2023.03.16 |
[Build & Deploy 리소스] NestJS 애플리케이션 AWS에 배포하기 05 (0) | 2023.03.16 |