AWS로 배포하기 (EC2 서버 + AWS Route 53 도메인 연결 + HTTPS 인증서 등록)

김태훈·2023년 5월 28일

프로젝트1

목록 보기

4/4

학교 프로젝트로 만든 칵테일 웹 어플리케이션을 배포하는 단계를 정리해보자 !
순서는 다음과 같다.
1. EC2서버를 프리티어에서 t3.medium으로 옮긴 이유
2. EC2서버 퍼블릭 IP 고정하기
3. EC2 서버 포트 포워딩
4. 도메인- https 인증서 연결하기
5. 로드밸런서 적용 이유
6. 타겟그룹 만들기
7. 로드밸런서 만들기
8. 로드 밸런서와 도메인 연결하기
9. 리다이렉션

1. EC2 서버 free tier -> t3.medium으로

EC2 서버 free tier에서의 문제

npm install 로 필요한 패키지 다운로드 받는중 서버 뻗어버리는 문제가 발생
-> free tier는 메모리 1 giga, volume 8 giga를 제공해주는데, Cloud Watch 메모리 사용량을 보니 부족하다고 판단했다.
이를 해결하기 위한 방법으로 Swap Memory를 활용했다. 서버가 ubuntu이므로 linux 기준의 swap memory라는 사실을 잊지 말자 !

Swap Memory
https://ioflood.com/blog/2022/12/12/what-is-swap-memory-exactly-swap-and-ram-explained/
스왑 메모리란, 실제 메모리 Ram이 가득 찬 경우 디스크 공간을 이용하여 부족한 메모리를 대체할 수 있는 메모리이다. Virtual Memory라고 하기도 한다.

그래서, fallocate 명령어를 활용하여 swapfile로 메모리를 할당하게 하였다.
보통, swap memory는 할당된 램 메모리의 2배 이상으로 설정할 것임을 권장한다. 따라서 2g를 swapfile에 할당해주었다.

sudo swapoff /swapfile
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile 
sudo swapon /swapfile

fallocate swapfile에 2g 할당
swapfile 읽기 쓰기 권한 부여
mkswap 으로 swap 영역 설정
swapon 으로 swap 공간에 swap file 추가하여 즉시 사용하게 함

이후에 부팅시에도 swapfile을 활성화하는 설정을 할 수 있다. 하지만 install만 되면 되므로 필요하지 않다고 생각 -> 그래서 이렇게 하고 npm install을 진행했다.

위와 같은 과정은 다음의 과정이다
sudo vi /etc/fstab 
/swapfile swap swap defaults 0 0
아랫 줄을 해당 파일의 마지막에 삽입하면 된다.

성공적으로 install이 되었다.

하지만, 문제는 npm build에도 있었는데, build하는 과정에서 한번 또 터졌다.
그래서, 이걸로는 안되나.. 해서

df -h

해서 volume 확인해보니까 760메가정도 남아있었고, 이미지와 같은 file system을 사용할 것이기 때문에, 더이상 스왑 메모리로 활용하는 방안으로 문제를 막기에는 또 터져버릴 것 같았다.
그래서, 학교에서 AWS 관련 지원금도 주는 것을 적극 활용하여 t3.medium으로 쿨하게 스펙을 올려버렸다.

스펙 올리니까 바로 해결이 되었다.

2. EC2 서버 퍼블릭 IP를 고정하기

EC2 서버가 죽고나서 다시 재실행을 누를 때, 퍼블릭 IP가 바뀌는 것을 발견했다. 이렇게 되면, 매번 껐다 킬 때마다, IP정보를 수정해야 하므로 귀찮으므로, ELASTIC IP를 활용하여 IP를 고정시켰다.
이건 짱 쉬우니까 패스 !
이렇게 되면 퍼블릭 IP가 Elastic IP로 아예 고정 된다.

3. EC2 서버 포트포워딩

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3030

우리의 서버포트는 3030번이므로, 80번 포트를 3030번으로 포트포워딩하여, 외부에서 80번으로 들어올 경우, 우리의 서버로 들어오게끔 설정해주었다. 이의 전제는, 당연히 EC2서버의 인바운드 규칙으로 80번을 열어주어야만 하겠다. 후의 443포트도 연결할 것이기 때문에 443도 추가, DB서버도 EC2에 다 넣어버렸으므로, 3306 포트도 추가!

다음은 EC2서버의 포트포워딩 정보를 확인한 화면이다.

sudo iptables -t nat -L --line-numbers

4. 도메인 - HTTPS 연결

당연한 것은 EC2의 프라이빗 IP와 퍼블릭 IP가 있는데, 프라이빗은 내부에서만 볼 수 있는 것이고, 다른 사람들이 우리 서버에 접근하거나, 우리가 직접 ssh로 서버에 접속할 때에도, 퍼블릭 ip를 이용하게 된다.
따라서 퍼블릭 ip와 도메인을 연결하는 작업이 필요하다.

1. 도메인 미리 만들기 (등록까지 시간이 걸리므로)

도메인을 미리 만드는 작업이 필요하다. 나는 Route53으로 만들었다.
이는 AWS 리소스들과 함께 쓸 수 있도록 도와준다.

2. 도메인 만든 후 레코드 살펴보기 (레코드 설명)

지금은 ALB와 Https 인증까지 다 완료한 상태라서 네가지 유형이 존재한다.
처음 만들면 딱 두가지 유형인 NS와 SOA가 생겼을 것이다.
그러니 따라 했을 때, 4개가 안뜬다고 잘못됐다고 생각하지 말 것!

A
주소 'Address' 를 나타내는 레코드로, 도메인의 IP 주소를 의미한다. 이 포스팅에서 적용한 것은 Loadbalancer 를 적용했는데 (ALB), 도메인네임으로 접속을 하면, ALB의 IP주소로 접속하게 해준다.
NS
'Name Server'를 나타내는 레코드로, 도메인이 등록되어 있는 네임 서버를 의미한다. 이 레코드를 통해서 해당 도메인의 IP주소를 찾기위해 가야할 곳을 알려준다. 따라서 도메인을 등록하면 동시에 등록 된다.
SOA
'Start Of Authority'를 나타내는 레코드로, 도메인 영역에 대한 중요한 정보를 저장한다. 마찬가지로 NS와 함께 도메인 등록과 동시에 생성된다.
CNAME
'Canonical Name'을 나타내는 레코드로, 하위 도메인을 가리킨다고 생각하면 된다.

CNAME 레코드 부연설명 -
예를 들어 blog.example.com에 'example.com' 값이 있는 CNAME 레코드가 있다고 가정해 보겠습니다('블로그'없이).이는 DNS 서버가 blog.example.com에 대한 DNS 레코드에 도달하면,실제로 example.com에 다른 DNS 조회를 트리거하여example.com의IP 주소를 A 레코드를 통하여 반환함을 의미합니다.이 경우 example.com은 blog.example.com의 정식 이름(또는 실제 이름)이라고 말할 수 있습니다.
https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-cname-record/

따라서 호스트 IP주소가 변경되면 DNS A 레코드만 변경되고, A레코드를 가진 도메인(부모 도메인)을 가리키는 자식 도메인들은 루트 도메인에 대한 변경사항을 따르면 된다.
즉, 자식 도메인은 루트 도메인과 항상 같은 IP를 가지고 있다.
다만, 웹 서버에서, URL을 보고 페이지만 다르게 클라이언트로 내려주게 된다.

3. ACM (Amazon Certificate Manager)에서 HTTPS 사용을 위한 SSL/TLS 인증서 발급받기

ACM에 들어가서 인증서를 발급받는 과정이다.
자세히 설명하자면, 기본적으로 https 프로토콜을 도메인과 함께 사용하기 위해서는 도메인에 대한 검증이 필요하다.
그 과정을 하는 단계이고, 인증서를 직접 도메인(IP)와 연결하는 것은 ELB(ALB) 에서 하는 것이다.

여기서 등록한 도메인 이름을 쓰고 (mixbowl-skku.com) 고대로 생성한다.
나는 이미 Route 53의 AWS 도메인 서비스를 이용하였기 때문에, 생성된 인증서에 ID를 클릭해서 'Route 53에서 레코드 생성'을 클릭하여 레코드를 생성하자.
그러면 해당 도메인의 레코드에는 CNAME레코드도 추가된 것을 볼 수 있다. 그럼 끝!

해당 CNAME레코드는, 도메인 이름은 SSL/TLS 인증서와 연결을 해준다는 느낌으로 이해하면 될 것 같다.

CNAME 레코드를 생성하면 브라우저는 HTTPS 인증을 위해 지정된 도메인 이름으로 요청을 전송합니다. HTTPS 인증서가 도메인에 설치되어 있으면 브라우저는 인증서를 확인하고 웹 사이트에 액세스할 수 있습니다.

4. EC2 서버를 생성할 때 생성된 보안그룹 확인하기

EC2 서버의 인바운드 규칙을 설정하면서 EC2 인스턴스를 만들자마자, 보안그룹도 생성이 되었을 텐데 이를 다시 한번 규칙이 잘 정의가 되어있는지 확인하자. 서버내 포함된 DB포트라든지, https, http, ssh 포트 같은 모든 필요한 포트번호를 확인하자.

5. 로드 밸런서 사용 이유 (왜 갑자기?)

로드 밸런서란, 가용영역에 있는 대상으로 들어오는 트래픽을 자동으로 분산시켜주는 서비스이다.
클라이언트에서 개별 서버로 가는 1관문이라고 할 수 있다.
갑자기 트래픽 관련하여 신경 쓸 레벨도 아닌데, 왜 갑자기 로드 밸런서가 나오는지 의아스럽다.

로드 밸런서를 사용하게 되면, 서버들을 하나의 도메인네임으로 묶을 수 있고, 이를 통해 각 서버별로 HTTPS 인증서를 설치할 필요 없이, 로드 밸런서에 HTTPS 인증서를 설치하면, 각 서버에 로드밸런서에서 이미 인증서를 사용하여 보안이 적용된 상태로 클라이언트의 요청을 적용할 수 있기 때문이다.
즉 서버의 과부하 측면을 줄이기 위해서 로드밸런서를 사용하는 것이다.

더불어서 첨삭하자면,
ELB의 종류중 하나인 ALB는 7계층에 놀고 있는 Balancer이다.
HTTPS 프로토콜은 7계층이므로 일단 다른 로드밸런서는 사용이 불가하다.

1) 로드 밸런서의 종류

ALB, NLB, GLB, CLB가 있는데 ALB가 기능이 엄청 많다.

2) 로드밸런서의 구성요소

1. Listener

프로토콜 및 포트를 사용하여 연결 요청을 확인한다.
7계층에서 동작하는 ALB는 HTTP, HTTPS 프로토콜 및 포트번호를 지원한다.
이 때, HTTPS 프로토콜을 사용하는 경우 Listener에 SSL 서버 인증서를 등록해야 한다.

2. Target Group

Listener를 생성할 때, Target Group을 지정하는데, Listener에서 지정한 규칙에 부합하면, Target Group으로 트래픽이 전달되게 된다.
또한, 이를 대상으로 정상 상태의 서버인지 체크하기도 한다. (Health Check)
https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-target-groups.html

3) 로드밸런서 작동 순서

https://velog.io/@znftm97/AWS-EC2%EC%97%90-HTTPS-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0 참고.

클라이언트가 도메인 주소를 통해 요청한다.
Amazon의 DNS 서버에 요청해서 도메인 주소를 통해 ELB의 Network Interface(ALB Node)의 IP 리스트를 클라이언트에게 전달한다.
클라이언트는 IP중 하나를 선택한다.
선택한 IP의 ALB 노드가 요청을 받고, 리스너에게 전달한다.
리스너는 규칙에 맞는 Target group으로 트래픽을 전달한다.
Target group은 라운드로빈 알고리즘을 통해 특정 EC2에 트래픽을 전달하여 요청을 처리한다.

6. 타겟 그룹 만들기 (로드밸런서)

클라이언트로 부터 온 요청이 분산되어 전송되는 도착지인 타겟그룹부터 만들어야 겠다.

기본 유형 선택하는 것이 많은데, 우리는 EC2로 요청을 분산할 것이므로(트래픽이 많아서가 주요 이유이지만, 우리는 https를 편리하게 등록하기 위한 수단임) 인스턴스를 체크하고 만들면 된다.

포트 번호는 해당 EC2 서버의 포트번호를 등록해야 한다.
우리는 이미 포트포워딩으로 80->3030으로 등록을 했기 때문에 80번으로 등록해야 한다.
이 과정을 거치지 않았더라면 3030번으로 해야하겠다.

대상 등록 하기

그 후 반드시, 어떤 인스턴스 그룹에 해당 설정을 등록할 건지 타겟 그룹을 선정해야 함을 잊지 말자.

7. 로드 밸런서 만들기

ALB 만드는 거임 !
이름만 설정하고 나머지는 다 기본값으로 해도 무방.
보안그룹
보안그룹에서는 반드시 EC2를 만들 때 설정한 인바운드 규칙이 들어있는 보안 그룹을 체크해야 한다! 앞에서 다 말했음!
물론 별도로 생성해도 상관없음..! 다만 이경우는 EC2의 해당 보안그룹을 추가해주어야 한다.
Listener 설정

다음과 같이 리스너에 HTTPS 프로토콜을 넣을 수 있다. 앞선 설명을 이해하면 당연한 수순!
그후 보안 리스너에 발급받은 인증서를 추가한다.

그리고 발급!

8. 로드 밸런서와 도메인 연결하기

이렇게 설정하면 된다.
별칭을 사용하여 등록된 로드 밸런서를 불러오면 된다.
이 때에는 유형 A를 등록해야 하겠다.
당연한 것이 IP의 주소(ALB)와 연관된 것이기 때문이다.

9. 리다이렉션

다음과 같이 로드밸런서의 리스너 정보에 프로토콜별로 정리된 것을 볼 수 있는데,
기본으로 HTTPS로 만들기 위해 HTTP로 들어올 경우, HTTPS로 바꾸는 리다이렉션 작업이 필요하다.
근데 기본적으로, 로드밸런서의 HTTPS를 지원하므로 설정하지 않아도 된다고 한다.
하지만 만약 하고 싶다면 저기 규칙탭에서 규칙관리를 누르고, 리다이렉션 설정을 하면 된다.