부트캠프를 진행하며 개인 프로젝트나 팀 프로젝트의 프론트엔드 서버를 AWS를 사용해서 배포를 하였다. 여기서는 가비아를 통해서 도메인을 구입하고 AWS에 배포를 진행하는 것까지 정리를 하겠다.
클라이언트 배포는 도커를 사용해서 배포가 가능하도록 미리 설정이 모두 끝났다는 가정하에 진행하겠다.
이 글에서는 S3 기능을 사용하지않는 SSR(Server Side Rendering) Only에 대해서 설명할 것이다.
AWS에서 사용하는 기능들은 위의 사진에서 S3를 제외한 4가지이며, 해당 기능들을 하나하나씩 연결하는 과정을 아래에 설명할 것이다.
1. AWS & 가비아 가입
이 글에서는 가비아에서 도메인을 구입하고 해당 도메인을 AWS에 연결하여 사용하므로 두 사이트에 모두 가입을 진행한다.
2. 도메인 구입
도메인 구입은 가비아를 통해서 진행한다. 도메인 구입 방법에 대해서는 가비아를 들어가면 쉽게 도메인 구입이 가능하므로 따로 설명을 하지 않겠다.
3. DNS 연결
구입한 도메인 주소와 AWS를 연결한다. AWS에 로그인한 뒤 좌상단의 서비스나 검색창을 이용해서 Route 53에 들어간다.
호스팅 영역을 선택해서 들어간 뒤에 호스팅 영역 생성을 선택한다.
구매한 도메인 주소를 도메인 이름 부분에 입력하고 아래의 유형은 퍼블릭호스팅 영역을 선택한다. 도메인 주소는 www 나 http, https 같은 것 없이 입력을 한다.
모두 입력이 완료되면 최하단에 호스팅 영역 생성을 클릭한다.
생성된 도메인 이름을 클릭하여 레코드를 편집할 것이다.
초기 호스팅 영역이 생성된 상태에서 들어가보면 NS, SOA 영역에 대해서 레코드가 만들어져 있다.
NS (Name Server) : 도메인의 네임서버를 지정.
SOA : 도메인 관련 타임 설정, SOA가 없으면 다른 레코드 등록이 불가능.
여기서 NS 레코드에 등록되어있는 값 / 트래픽 라우팅 대상을 가비아에 등록하도록 한다.
가비아에 접속하여 구매한 도메인 관리에 접속한다. 접속하면 페이지 중간에 아래 사진과 같은 네임서버 영역이 있는데 해당 값들을 AWS의 NS 레코드의 값들로 바꿔준다.
변경이 완료되면 도메인 이름을 웹브라우저의 검색칸에 입력하면 해당 도메인 이름으로 Route 53에 접속이 가능해진다. 해당 과정은 NS 레코드가 가비아에 등록되기까지 어느정도의 시간이 걸리므로 시간을 가지고 기다리도록 한다.
등록이 완료되면 윈도우는 cmd, 맥은 iterm이나 터미널 등에서 확인을 할 수 있는데, dig '도메인 주소' NS 를 입력하여 확인한다. 레코드 등록이 완료되면 아래와 같이 AWS의 NS 레코드가 적용된 값들이 나올 것이다.
dig 명령어로 확인이 완료되면 도메인 연결은 완료!
4. EC2 생성
EC2를 검색하여 들어간 후 인스턴스 시작을 선택한다.
이름은 따로 설정할 필요가 없으며 아래의 아마존 리눅스를 사용하며 AMI가 프리 티어로 사용이 가능한지 확인한다.
AWS에서는 인스턴스를 만들 때 프리티어로 만들 경우 하나의 인스턴스에 대해서 1년간 무료로 제공한다. 정확히는 프리티어로 만들어진 인스턴스의 총 가동시간 750시간에 대해서 무료로 제공한다. 1개월이 최대 744시간이므로 1개의 인스턴스를 한달 내내 가동하여도 무료로 사용이 가능하다. 인스턴스의 갯수가 아닌 총 가동시간에 대해서 비용이 책정되므로 주의하도록한다.
프리티어 확인이 끝나면 바로 아래 키 페어 대해서 키 페어 없이 진행을 선택한다. 키페어는 해당 인스턴스에 SSH 접속을 위해 사용한다.
보안 그룹에서 새로 만드는 경우에는 보안 그룹 생성을 선택하여 새로운 보안 그룹을 만들어준다. 체크된 부분을 선택해주고 스토리지는 기본제공은 8GB이지만, 30GB까지 무료로 제공하므로 필요에 따라서 용량을 조금 더 높여주도록 한다.
인스턴스를 만드는데 성공하면 해당 인스턴스에 접속한다.
인스턴스에 접속하여 하단의 보안 탭에 접속한다. 보안 탭에서 인스턴스를 만들어줄 때 선택했던 보안 그룹에 대해서 수정이 되야하므로 해당 보안 그룹을 클릭한다.
인바운드 규칙 편집 버튼을 클릭한다.
처음 인바운드 규칙 편집에 접속하면 SSH 포트번호 22에 대해서만 설정이 되어있는데 규칙 추가를 선택해서 새로운 규칙을 만들어준다. 사용자 지정 TCP, 포트 범위 3000, 소스 0.0.0.0/0으로 지정하여 규칙을 저장한다.
EC2 인스턴스 생성이 완료되면 다음은 로드밸런서와 인스턴스를 연결한다.
5. 로드밸런서 - EC2 연결
서버의 과부하를 막기 위한 방법으로 인스턴스들을 많이 만들어 서버에 접속하는 트래픽들을 나누어준다. 이 방법을 진행하기 위해서 어떤 인스턴스가 과부하가 적게 걸려있는지 등을 알아서 판단해서 어떤 인스턴스로 트래픽을 보낼지 결정하는게 로드밸런서이다. 즉, 많이 만들어진 인스턴스들을 하나로 묶어서 연동을 시켜야 모두 같은 사이트에 접속이 가능해진다.
EC2에 접속하여 좌측 메뉴에서 쭉 내리다보면 하단에 로드밸런서에 접속한 후에 로드밸런서 생성을 선택한다.
-
세가지 로드밸런서 타입 중에서 가장 좌측의 Application Load Balancer의 Create를 선택한다.
-
로드밸런서 이름을 설정한다.
-
Mapping 영역을 선택한다. 후에 변경이 필요하므로 최소 2개를 선택한다.
-
Listener에서 프로토콜 HTTP에 포트번호 80번으로 설정 후에 하단의 Create targer group을 선택한다.
-
Instances 선택, 타겟 그룹 이름 설정(알아보기 쉽게 '도메인이름-lb' 로 지정.), 포트번호 3000번으로 변경한 뒤 Next를 선택한다.
-
설정된 타겟 그룹에 인스턴스를 포함시켜준다. 인스턴스를 체크하고 Include로 타겟 그룹에 포함 시킨 뒤에 Create target group을 선택한다.
-
로드밸런서 생성으로 돌아와서 위에서 생성한 타겟 그룹을 선택한다.
-
Create Load Balancer를 선택한다.
-
로드밸런서 생성이 완료되면 EC2로 돌아가서 해당 인스턴스의 가용영역을 확인한다.
-
로드밸런서로 돌아가서 로드밸런서를 선택한 뒤에 작업 - 서브넷 편집을 선택하여 8번에서 확인한 인스턴스의 가용영역을 포함하도록 최소 2개를 선택한다.
위의 과정으로 EC2 인스턴스와 로드밸런서의 연결이 완료된다.
6. SSL 인증서 생성
https로 배포하기 위해서 AWS가 지원하는 인증서를 만들어준다. Certificate Manager를 서비스 탭에서 찾거나 검색하여 접속한다. 인증서의 경우에는 인증을 진행할 수 있는 버지니아 북부로 서버를 변경한다. 다른 서버에서도 인증 자체는 진행할 수 있으나 갱신등의 문제가 발생할 수 있으므로 버지니아 북부에서 인증서를 생성한다.
접속 후 인증서 요청을 클릭하고, 인증서의 유형은 퍼블릭 인증서 요청을 선택하여 다음 버튼을 클릭한다.
구입했던 도메인을 입력하고 (http, https, www 등은 적지 않는다.) DNS 검증을 선택한 뒤에 요청 버튼을 클릭한다.
만들어진 인증서에 대해서 해당 도메인 이름을 실제로 사용하는 사람이 소유하고 있는지 확인이 필요하기 때문에 인증이 필요하다. 인증에는 해당 도메인으로 CNAME 라우팅을 보내서 특정 이름의 CNAME을 보내 돌아오는 결과 값이 일치하면 실제 도메인을 소유하고 있다고 판단한다.
만든 인증서에 들어간 뒤 도메인 영역에서 Route 53에서 레코드 생성을 선택한다.
AWS는 자체 지원하는 인증서를 사용할 경우에 자동으로 CNAME 레코드를 생성해준다. 레코드 생성 버튼을 선택한다.
Route 53에 이동해서 확인을 해보면 CNAME 레코드가 자동으로 생성되었음을 확인할 수 있다. 이제 만들어진 인증서를 가지고 CloudFront를 생성한다.
7. CloudFront 생성
서비스 탭, 검색을 사용해서 CloudFront에 들어간다. CloudFront에서 배포 생성 버튼을 클릭한다.
원본 도메인 선택 창에서 만들어놓은 로드밸런서를 선택한다. 사진에는 S3도 활성화 되었지만, S3를 만들지 않고 로드밸런서만 만들었다면 해당 칸만 활성화 될 것이다.
아래로 스크롤을 내려 기본 캐시 동작에서 뷰어 프로토콜 정책을 Redirect HTTP to HTTPS를 클릭하고 허용된 HTTP 방법에서 GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE를 선택한다. 두 설정은 http로 접속을 진행해도 https로 변경해주는 설정과 모든 접속 요청에 대해서 접속을 허용하기 위한 설정이다.
아래로 스크롤을 쭉 내려 설정 탭을 찾는다. 대체 도메인 이름을 찾아 항목 추가를 클릭하고 Route 53에 연결해 두었던 도메인 주소를 입력한다. 바로 아래의 사용자 정의 SSL 인증서에서 만들었던 인증서를 선택한다.
스크롤을 마지막까지 내려서 배포 생성을 클릭한다.
8. Route 53 - CloudFront 연결
Route 53에 도메인에 대해 연결되었다면 해당 도메인에 대해서 어떤 html, css, js 등을 넘겨줘야 하는데 어디에서 해당 파일들을 가져올 지 결정을 해야한다. 이 결정을 하는 것이 CloudFront로 어떤 주소에 대해서는 로드밸런서로 요청이 들어가고 어떤 주소에 대해서는 S3로 요청이 들어가는 식이다. 이 기능을 하기 위해서 Route 53과 CloudFront를 연결한다.
먼저 Route 53에 접속해서 연결해둔 도메인 주소로 들어가 레코드 생성 버튼을 클릭한다.
단순 라우팅을 선택한 뒤에 다음 버튼을 클릭한다.
단순 레코드 정의를 클릭한다.
레코드의 유형은 A 유형으로 만들어준다. 값/트래픽 대상은 CloudFront 배포에 대한 별칭을 선택한다. 해당 값을 선택하면 배포 선택 란이 활성화 되는데 해당 칸을 클릭하면 만들어준 CloudFront가 아래에 선택할 수 있도록 나오므로 해당 CloudFront를 선택한다. 이제 설정이 완료 되었으므로 단순 레코드 정의 버튼을 선택한다.
이제 레코드 생성 버튼을 클릭하여 A 레코드를 만들어준다.
9. EC2 인스턴스에 프론트엔드 클라이언트 실행
이제 마지막으로 EC2 인스턴스에 클라이언트 코드를 다운 받아서 실행시키면 도메인 주소를 입력해서 접속이 가능해진다.
EC2에 들어가 인스턴스를 선택한 후에 연결 버튼을 클릭한다.
이동된 페이지에서 따로 변경할 값 없이 연결 버튼을 클릭한다.
다음과 같은 콘솔 창이 뜨면 서버를 가동하기 위한 환경을 세팅한 뒤에 코드를 다운 받아 실행한다.
환경 세팅과 코드를 clone 받기 위해서 콘솔 창에서 다음의 코드들을 순서대로 실행한다.
curl -sL https://rpm.nodesource.com/setup_14.x | sudo bash
아무런 세팅이나 모듈이 설치되지 않은 상태이므로 nodejs 패키지를 설치한다.
sudo yum install -y nodejs
nodejs를 설치한다.
sudo npm install -g yarn
yarn을 설치한다.
sudo yum install git
y
깃을 설치한다.
git clone '깃주소'
git clone으로 코드를 가져온다.
'깃유저이름'
git id가 아니라 username이라는 점을 명시한다. 해당 값은 Repo가 public일 경우에는 입력하지 않는다.
'깃토큰'
git password가 아니라 토큰이라는 점을 명시한다. 해당 값은 Repo가 public일 경우에는 입력하지 않는다.
cd '경로'
sudo yum install docker
y
docker를 설치한다.
sudo curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose를 설치한다.
sudo amazon-linux-extras install docker
sudo service docker start
sudo usermod -a -G docker ec2-user
AWS 정책상 docker가 꺼져있으므로 docker를 실행한다.
콘솔을 종료 후 재 실행한다.
cd '경로'
docker-compose build
docker로 build를 진행한다.
docker-compose up -d
EC2 콘솔은 오랜시간 사용하지 않으면 콘솔이 멈추는 버그가 있으므로 백그라운드 실행을 통해서 서버가 종료되지 않도록 한다.
docker-compose stop
실행 중인 docker container를 종료할 때 해당 명령어를 입력한다.
마무리
위의 과정을 통해서 프리티어로 SSR 배포를 진행할 수 있다.
위의 프리티어 SSR 배포 방식에 대해서 문제가 있는데 코드가 변경되어 재배포가 필요할 때, docker로 배포하기 때문에 코드 수정 후 clone 받은 코드로 다시 docker-compose build를 진행하면 해당 코드를 가진 새로운 image(os등을 모두 가진)가 만들어지기 때문에 용량 부족의 문제가 발생한다.
만약 같은 용량부족 문제로 고생하고 있다면 인스턴스를 삭제하고 다시 연결하는 것을 추천한다. 재배포를 할 때 다시 설정할 것들은 다음과 같다.
- 인스턴스의 인바운드 보안 규칙을 설정한다. (인스턴스를 새로 만들 때 원래 사용하던 인스턴스의 보안 규칙을 사용하게되면 따로 설정할 필요가 없다.)
- 로드밸런서의 타겟 그룹에 새로 만든 인스턴스를 포함시켜준다.
- 로드밸런서의 서브넷 편집에서 새로 만든 인스턴스의 가용 영역이 포함되도록 변경한다.
- CloudFront에서 캐시 되어있던 정보들을 삭제한다.(해당 과정은 CloudFront에서의 무효화 탭에서
/*을 입력하여 모든 경로에 대해서 캐시가 삭제되도록한다.)
