지난 글에서 AWS 서비스를 이용하여 Nest 프로젝트를 EC2에 배포하는 과정을 정리해보았습니다.
이번에는 EC2에 있는 Nest와 통신을 하여 데이터를 주고 받아야하기 때문에 https 적용 및 로드밸런서 설정을 같이 해보려고 합니다.
우선 도메인을 적용시키기 위해 도메인을 구매해야 합니다.
가비아가 첫 구매시 도메인 가격이 싸기 때문에 저는 가비아에서 구매했습니다.
이제는 위에서 구입한 도메인을 AWS Route 53에 적용해야합니다.
저희가 Route 53에서 도메인을 구매한게 아니라, 이 과정에서 가비아의 도메인과 Route 53을 서로 연동시키는 추가적인 과정이 있습니다.
이렇게 호스팅 영역을 생성하고, 호스팅의 세부정보 레코드를 보면 다음과 같이 레코드들이 있습니다.
(현재 A와 CNAME은 나중에 추가 예정이고, NS와 SOA 2개만 만들어짐)
여기서 각 레코드들의 유형을 보면 A,NS,SOA,CNAME가 있는데 각 레코드들의 개념은 다음과같습니다.
A 레코드
-저희가 호스팅한 도메인 주소와 서버의 IP주소를 매핑시키는 레코드입니다.
즉 해당 레코드를 만듦으로써, 도메인 주소 클릭시 서버의 IP주소로 바꿔서 서버에 들어올 수 있게 하는 레코드입니다.
NS 레코드 (Name Server)
-네임 서버 레코드로, 해당 도메인에 대한 네임서버 의 권한을 누가 관리하고 있는지 알려주는 레코드입니다.
즉, 해당 레코드를 클릭했을때, DNS 처리과정에서 해당 도메인 DNS 쿼리를 처리할 서버가 지정되어있는 레코드입니다.
이때, DNS 시스템의 안정성과 고가용성을 위해 1개가 아닌 4개의 값이 존재합니다.
SOA 레코드 (Start of Authority)
-NS레코드의 네임서버가 해당 도메인에 관하여 핵심 정보를 가지고 있음을 증명하는 레코드입니다.
즉, SOA 레코드의 값은 NS 레코드 값중 하나이며, 도메인 이름, 도메인 관리아 메일, 도메인 일련번호 등의 필수적인 정보를 가지고 있습니다.
CNAME 레코드 (Canonical Name Record)
-도메인 별명 레코드며, 다른 도메인 주소를 A 레코드의 도메인 주소로 이중매핑 시키는 레코드입니다.
즉, 고정IP가 아닌 유동IP인 상황에서 CNAME 레코드를 활용하여 도메인과 IP 매핑 수정을 최소화 할 수 있는 장점을 가진 레코드입니다.
이제 여기에 있는 NS 레코드를 가비아의 도메인에 적용시킬 것입니다. NS레코드에 존재하는 4개의 값들을 가비아의 도메인 정보에 입력하면됩니다.
가비아 페이지의 '내 서비스 관리 -> 도메인 통합 관리툴 -> 도메인 정보 변경 -> 내도메인 클릭 -> 네임서버 설정'에 들어가서 방금 4개의 값들을 차례대로 1차~4차까지 등록을 하면됩니다.
이제 HTTPS를 적용하기 위해 Certification Manager를 통해 SSL/TLS 인증서를 발급해야 됩니다.
💡 SSL/TLS 인증서는 웹 서버와 클라이언트 간 통신을 암호화하여 데이터를 안전하게 보호하고, 서버의 신원을 인증하는 디지털 인증서입니다. 이를 통해 데이터 도청과 변조를 방지하며, HTTPS를 활성화해 사용자에게 신뢰를 제공합니다.
이렇게 설정 완료를 안후, 인증서 리스트를 확인하면 다음과 같은 창이 나올겁니다.
지금 저는 전에 만들어둔 인증서기 떄문에 '발급됨'이 뜨는데 발급까지 시간이 좀 소요가 됩니다.
이제 인증서 ID를 클릭하고 Route 53에 레코드 생성을 하면됩니다.
그러면 아까 위에 CNAME 레코드가 만들어질겁니다.
한 대의 EC2만 사용할 예정이어도, https를 적용하려면 로드밸런서가 필요합니다.
ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(ECS), AWS Lambda 등으로 다양한 서비스와 연계하여 부하를 분배할수 있다.
로드밸런서 설정전 타겟 그룹을 설정을 먼저 해줘야합니다.
1. 대상유형을 인스턴스로 선택
2. 그룸 이름 작성
3. 포트는 80번으로 선택
4. vpc 선택(EC2와 똑같은 vpc로 선택해야함)
Health check는 타겟 그룹의 EC2 인스턴스가 건강한지 확인하는 방법을 말합니다.
Unhealthy하다면, 로드 밸런서가 해당 타겟 그룹으로 요청(부하)을 보내지 않습니다.
디폴트로 하고 다음 페이지로 넘어가 사용할 인스턴스를 체크하고, 포트 번호를 확인하고 추가해줍니다.
저희는 단순하게 HTTPS를 연결할거니깐 맨 왼쪽에 있는 걸로 선택하여 생성합니다.
1. 로드밸런서 이름 이력
나머지는 안 건드려도 됩니다.
2. VPC를 연결합니다
근데 여기서 VPC는 EC2와 연결된 것과 똑같은 것으로 연결해줘야합니다. 그리고 서브넷은 퍼블릭 서브넷으로 선택해줘야합니다.
3. 필요한 보안그룹을 연결해줍니다
4. HTTP 80, HTTPS 443 에 대한 리스너를 생성합니다.
5. Forward to를 위에서 생성한 타겟 그룹으로 설정합니다.
6. 아까 만들어둔 인증서 선택
아까전에 봤던 사진에서 유형 A 레코드를 추가해줄겁니다.
레코드 이름(서브 도메인)은 사용해도 되고, 안해도 됩니다. 저는 안하고 넘어가겠습니다.
트래픽 라우팅 대상을 위 그림처럼 설정해서, 위에서 생성한 LB를 지정해주어야 합니다.
그리고 레코드를 생성합니다.
자, 이제 호스팅 영역의 레코드 4개가 다 생성되었습니다!
만약 HTTP로 접근을 하게되면 HTTPS로 리다이렉트 되게 규칙을 변경해줍니다.
80번 포트에서 들어오는 요청을 Docker 컨테이너의 3001번 포트로 전달하기 위해서는 nginx를 이용하여 역방향 프록시를 설정해줘야합니다.
nginx를 EC2에 접속하여 설치부터 해주겠습니다.
nginx 설정 파일을 수정하여, 80번 포트에서 들어오는 요청을 Docker 컨테이너의 3001번 포트로 전달하도록 설정합니다
sudo nano /etc/nginx/sites-available/default
server {
listen 80;
server_name lily-server.shop; # 도메인 이름
location / {
proxy_pass http://localhost:3001; # Docker 컨테이너의 3001번 포트로 요청 전달
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
sudo systemctl restart nginx
힘겹게 배포는 성공했지만 배포를 하는 과정에서 AWS 비용이 꽤나 나올 거 같고 프리티어도 곧 끝나서 이 방법 보다는 Vercel로 배포를 다시하려고 한다.
서버리스로 배포를 하면 내가 서버쪽은 신경 안 쓰고 개발에만 집중할 수 있을 거 같고, 초기에는 사용자가 거의 없을거라 비용적으로도 이게 더 적합할 거 같아 지금까지 만든건 없애고 다시 배포를 하려고 합니다.
그래도 이런 과정에서 AWS 서비스들을 한 번씩 써보는 좋은 경험이 되어 나중에 다시 배포하게 되면 좀 더 쉽게 할 수 있을 거 같다
참고
EC2 HTTPS로 연결하기 (2) - 로드밸런서로 리다이렉트 설정하고 Health check 통과하기
ELB(Elastic Load Balancer) 구성 & 사용법 가이드
vpc 생성 참고