프로젝트:샐로그 / 배포 2 (AWS/Domain)
이전 포스트에 이어 이번에는 AWS 설정과 로드밸런서 사용, 무료 도메인 연결을 작성한다.
앞선 글에서는 로컬에서 깃헙, 깃헙 액션스를 활용하여 도커로 이미지를 말아 올리고 ec2에서 해당 이미지를 바탕으로 배포하는 과정이었다.
사실 이 과정 중 빠진게 하나 있는데, ec2 안에는 당연한 얘기지만 도커가 설치되어 있어야 한다.
우선 ec2 구성과 도커 설치까지 살펴보자.
Ec2 인스턴스
ec2는 기본적으로 아마존 리눅스 2023 AMI 버전을 사용했다.
사실 프리티어라 선택 폭이 그리 넓지 않았다.
인스턴스 유형은 t2.micro로 지정하였고 이외의 설정은 기본 값으로 두었다.
프리티어가 아닌 계정에서의 설정법이 궁금하긴 하지만, 그렇다고 요금 폭탄을 받을 순 없다…
그렇게 해서 salog라는 이름의 ec2 인스턴스가 생성되었다.
사실 이전 프로젝트에서 활용했던 방식대로 vpc에 퍼블릭/프라이빗 서브넷을 나누어 bastion host를 두고 배포용 ec2에 우회해서 들어가게끔 설정하려다가 일단은 단순히 퍼블릭 서브넷에 배치해두었다.
다른 문제보다 사실 ec2가 bastion host와 배포용, 두 개가 필요하기 때문에 프리티어 시간이 너무 빨리 흘러 요금이 발생할 여지가 있기 때문에 이번에는 이렇게 하였다.
추후 보안 강화를 위해 앞서 말한 방식을 적용할 수도 있다.
지금은 키페어로 접속하고 있으며, 배포용 ec2도 인터넷과 통신이 가능하다.
또한, 퍼블릭 ipv4 주소를 자동 할당 했기 때문에 문제 없이 접속된다.
현재는 아직 구현된 기능이 없고 프로젝트 자체도 DB에 연결된 상태가 아닌 빈 프로젝트이기 때문에 RDS는 연결하지 않았다.
일단 “배포”를 성공시키는 게 목표였기 때문에 어느정도 프로젝트 단계가 진행되면 그 때가서 연결할 것이다.
이렇게 아무것도 없는 단순히 스프링 실행만되는 프로젝트를 배포한 이유는 멘토였던 분에게 들었던 얘기 때문이다.
“일단 시작하자마자 배포부터 하세요.”가 그 분이 말씀하셨던 건데, 이렇게 자동 배포 환경을 미리 구성해놓으면, 추후 어떤 기능이 활성화 될 때마다 프론트에서 접속하여 확인할 수 있고 나중가서 배포 때문에 골머리 아플 일이 없기 때문이다.
간단히 말하면, 협업과 개발 시 편리함 때문이 되겠다.
서론이 길었는데, ec2 인스턴스를 생성했으니 이제 ssh 프로토콜로 접속하여 도커를 설치해야 깃헙 액션에서 실행하는 명령을 수행할 수 있다.
주의할 점은 ubuntu 환경에서 실행할 수 있는 명령어가 많이 나오는데,
우리는 아마존 리눅스 2023 AMI 버전을 사용하고 있기 때문에 명령어가 다르다.
Amazon Linux 2023 AMI OS 기반에서 도커를 설치하는 명령어는 다음과 같다.
- 패키지 업데이트
1
sudo yum update -y
- 아마존 엑스트라 패키지 설치 (도커 설치)
1
sudo amazon-linux-extras install docker
- 도커 서비스 시작
1
sudo service docker start
이 세 단계를 거쳐 도커를 설치하고, 사용할 수 있다.
혹시 yum-utils 패키지가 없어 도커 설치에 에러가 발생하면
1
sudo yum install -y yum-utils
이 명령어를 사용하여 해당 패키지를 설치하면 된다.
추가적으로 sudo 명령 없이 관리자 접근을 하고 싶다면
1
sudo usermod -a -G docker ec2-user
이 명령어로 ec2 사용자의 기본값인 ec2-user를 도커 그룹에 추가하면 된다.
(다른 이름으로 되어 있다면 해당 사용자 이름을 추가해주자.)
이제 ec2에 도커가 설치되었고, ec2 내부에서 당장 더 이상 해야할 것은 없다.
도커만 설치되어 있어도 깃헙 액션스가 명령을 실행할 수 있게 되기 때문이다.
ec2 외적으로는 제일 중요한 보안 그룹을 설정해야한다.
ec2 보안 그룹 설정
이 보안 그룹 설정은 거짓말을 안한다.
애초에 AWS 설정 자체가 거짓이 없기 때문에 무언가 잘 못 되어 있으면 거의 100% 내 탓이다.
이 “내 탓”을 가장 많이 느낀 부분이 보안 그룹이었는데, 특히나 이 전에 진행했던 프로젝트는 vpc/서브넷 때문에 복잡해서 더욱 힘들었다.
이번에는 해당 설정을 사용하지 않기 때문에 인바운드/아웃바운드 규칙을 적절히 설정해주면 된다.
기본적으로 인바운드는 ec2로의 접근 / 아웃바운드는 ec2에서의 접근 트래픽을 설정한다.
주의할 것은 이 보안 그룹 규칙은 반영이 즉각적으로 되기 때문에 수정하기 전후 딜레이가 거의 없다.
다시 말해, 수정하고 나서 안된다? 기다리지말고 그냥 설정을 잘 못한 것이다.
우선 인 바운드 규칙이다.
ec2로의 접근은 ip를 제한할 필요가 없다. 웹 애플리케이션을 사용하는 모든 이가 통신 할 수 있어야 하기 때문이다.
단, 통신 유형은 웹 애플리케이션 통신에 사용되는 http와 https를 기본으로 열어 두었고, 나와 팀원들이, 즉, 개발자가 접근할 수 있도록 ssh 유형도 오픈해 놓았다.
다음은 아웃 바운드 규칙이다.
ec2가 인터넷과 통신해야한다면 아웃 바운드 규칙은 전부 열어놓는 편이 좋다.
특히 무언가를 설치해야할 때, ec2가 패키지 관리자에 접근할 수 있어야하고,
OS를 업데이트할 때도 필요하다.
이렇게 보안 그룹 규칙 설정을 살펴보았다.
혹여나 다음에 bastions host를 사용하여 보안을 강화한다면 내용에 변경이 있을 것이다.
여기까지 진행되었다면 이미 배포는 성공이다.
도메인을 별도로 사용하지 않는다면 사실상 끝이다.
그런데 도메인을 사용하지 않으면 ec2 주소로 접속해야하기 때문에 퍼블릭 ip나 DNS 모양새가 그리 이쁘지않다.
그래서 무료 도메인을 발급받아 사용했다.
도메인 내용으로 들어가기 앞서 ELB(Elastic Load Balancer)에 대한 이야기부터 할 것이다.
로드밸런서는 기본적으로 네트워크 트래픽을 여러 서버에 분산시킴으로 한 서버에 부하가 집중되는 것을 방지하거나 특정 서버에 문제 발생 시 정상 가동 중인 서버로 리디렉션 해주는 기술이다.
다시 말해, 트래픽 급증이 예상되거나 서버 다운에 대한 예방 차원으로 개발자가 서버를 추가로 배치하고 로드밸런서로 연결하여 처리 능력을 증가시킬 수 있다.
혹은 오토 스케일링 그룹과 같은 서버를 자동으로 늘리거나 줄이는 별도의 서비스를 사용해도 된다.
이러한 장점으로 인해 위와 같은 처리를 해주면 서버에 장애가 발생해도 무중단 서비스가 가능한 것이다.
특히 보안이 강화된 HTTPS 프로토콜을 사용하려면 SSL/TLS 인증서가 필요한데, 로드밸런서가 SSL/TLS 암호화와 복호화 작업을 처리할 수 있기 때문에 서버의 부하를 줄이는데에 도움을 준다.
이러한 이유로 우리의 웹 애플리케이션은 HTTPS 프로토콜로 클라이언트에게 제공될 것이기 때문에 로드밸런서를 사용하는 게 적합하다고 판단했다.
또한, 추후 대용량 트래픽 핸들링 시 서버를 늘려주는 작업도 진행해볼 수 있을 것이다.
앞서 말했듯이 HTTPS 프로토콜을 사용하려면 SSL/TLS 인증서가 필요하다.
우리는 ACM(Amazon Certificate Manager)를 통해 인증서를 발급 받았다.
이 인증서는 로드밸런서를 사용하지 않을 시에는 ec2 인스턴스에 직접 설치할 수 있고, 로드밸런서가 아닌 클라우드 프론트 서비스를 사용하여 종단간(end-to-end)으로 제공할 수 있다.
다만 AWS 공식에서는 종단간으로 SSL/TLS를 제공하는 것이 권장되기 때문에, 그리고 지금은 서버 배포이기 때문에 로드밸런서에 인증서를 적용했다.
HTTPS 프로토콜을 사용하기 위해 반드시 로드밸런서를 사용해야 되는 것은 아니라는 것을 알고 넘어가자.
로드밸런서의 생성과정은 다음과 같다.
1. 로드 밸런서를 생성하고, 유형은 ALB를 선택한다.
2. 로드밸런서는 인터넷 경계에서 동작시킬 것이고 ec2가 배치된 vpc 서브넷을 매핑한다.
3. 보안 그룹은 https/http 프로토콜만 허용한다.
- 필요 이상으로 또 다른 프로토콜을 허용해 줄 필요는 없다. 통신하는 프로토콜만 열어준다.
4. 리스너 및 라우팅 설정은 아래와 같다.
- 여기서 리스너는 https 프로토콜만 지정해준다.
- http 프로토콜로 들어오는 요청은 https 프로토콜로 리디렉션 해줄 것이다.
- 지정 시 배포용 ec2 인스턴스로 전달하게 끔 대상그룹을 생성해준다.
5. 보안 정책은 권장된 기본값으로, 인증서는 ACM에서 발급받는다.
- ACM에서 발급 받은 인증서를 선택해주면 된다.
- 없다면 ACM 인증서 요청으로 링크를 타고 들어가 생성하면 된다.
- ACM 사용법은 로드밸런서가 끝나고 작성할 것이다.
이 과정을 거쳐 로드밸런서를 생성하고 나면 즉시 동작한다.
다만 아래와 같이
보안을 생각하여 http 프로토콜로 들어오는 요청을 https로 리디렉션 해주어야 한다.
현재는 다른 서브넷에 서버가 배치되어 있지 않기 때문에 분산 처리에 대한 이점은 얻지 못한다.
단순히 SSL/TLS 인증서 사용과 해독에 대한 이점만 취할 수 있다.
ACM 서비스를 사용하여 인증서를 발급 받는 방법은 간단하다.
우선 ACM으로 접속하여 인증서 발급을 신청하면 되는데, 사용할 도메인이 미리 있어야한다.
우리는 무료로 도메인을 발급해주는 내도메인.한국에서 도메인을 발급 받았다.
몇 가지의 선택지가 있는데 그 중에서 제일 무난해 보이는 것으로 선택했다.
이 도메인을 발급 받고 나면 ACM에서 사용할 도메인 주소를 넣고 유형은 cname으로 인증 받아야한다.
cname은 단순히 별칭을 의미한다.
예를 들어 기본 도메인 명이 salog.kro.kr이라고 하면 그 앞에 별칭을 지어줄 수 있다.
그림에서 볼 수 있듯이 cname을 www를 붙여 완성했고, 값은 elb 주소로 되어 있기 때문에 www.salog.kro.kr 로 접속하게 되면 값에 할당된 주소로 리디렉션되는 식이다.
이러한 원리를 이용해 ACM에서도 인증받을 수 있다.
다시 돌아와, 인증 받을 도메인에는 실제 동작하고, 인증 받기 위한 도메인을 작성하고, cname 이름과 cname 값을 ACM에서 알려준 대로 도메인 사이트에 입력하고 수정한 다음 조금 기다리면 승인이 완료된다.
이런식으로 되어 있다.
도메인 사이트에서 ACM cname 이름 대로 수정할 시 주소가 동일하게 되어야한다.
이 과정까지 거치면 SSL/TLS 인증서 발급과 로드밸런서 설정, 연결은 끝났다.
이제 발급 받은 인증서를 로드밸런서 생성 시에 연결해주면 정상적으로 https 프로토콜로 통신할 수 있게 된다.
도메인 사용은 덤으로..
실제로 https 프로토콜 리스너에 인증서가 삽입된 모습이다.
이제 배포는 끝났다.
지금까지 설명한 흐름은
클라이언트가 ELB에 요청을 보내면 ELB가 해당 요청을 서버(ec2)로 리디렉션 해주고
서버에서 요청 처리에 대한 응답을 ELB로 보내고, ELB가 다시 클라이언트에게 전송한다.
도메인은 요청/응답을 전송 해주는 것은 아니고 주소를 변환만 해준다.
이로써 자동 배포 구성은 끝이났다.
추후 bastion host 를 사용하거나 서버를 스케일링 하게 된다면 배포3으로 작성할 예정이다.
구현 중에는 마주친 에러에 대한 핸들링을 작성할 것이라 자주 올라오진 않을 것이다.
도커를 제외하면 특별히 복잡하거나 처음 접해본 설정 구성은 없었다.
개발이라는 것이 경험한 만큼 성장하는 구조로 되어 있어 힘들지만 재밌다.
특히 서버 개발자는 배포에 관한 내용도 숙지를 하고 있어야하기 때문에 여러 번의 프로젝트가 도움이 되었다고 생각한다.