하나의 EC2 안에 테스트 서버까지 구축하기 feat. AWS

계기

release branch에서 master로 병합 전,

즉 실 배포 전에 배포하고 확인할 수 있는 서버가 필요하다고 느껴 테스트 서버를 구축하게 되었다.

 

기존 서버 구성도

기존의 서버 구성은 위와 같았다.

 

docker-compose를 활용하여 api server, postgreSQL, Redis 총 3개의 컨테이너를 묶어서

EC2에 올려 관리하고 있었다.

 

초반엔 단순하게 인스턴스 하나를 늘려야겠다고 생각했지만, 서버 비용이 2배가 된다는 생각에 아찔해져

지금 올려둔 EC2에 테스트 서버를 함께 올리기로 결심했다.

 

 

시도 1

우선 docker compose로 묶어뒀던 구성에서 api server를 분리하고,

ec2 보안 그룹에 test server를 위한 인바운드 규칙을 추가하고

 

Application Load Balancer의 listener에도 test server를 위해 규칙을 추가해주었다.

 

 

그리고 ALB의 기존에 연결되어있던 target group에 3000 port로 하나 더 등록해주었다.

이후

위와 같이 3000번 포트로 테스트 서버를 구동시켜주었다.

 

근데 여기서 간과한 점이 있었다.

 HTTPS가 적용된 프론트에서 HTTP 통신을 사용하고 있는 테스트 서버로 요청을 보내면,

보안이 더 낮은 곳으로는 연결해주지 않기 때문에 위와 같이 에러가 발생하게 된다.

 

시도 2

그래서 테스트 서버에도 실제 서비스하는 api 서버와 동일하게 HTTPS 통신이 이뤄지도록 다시 구성하도록 하겠다.

 

레코드 추가

새로운 레코드를 추가하고

사용 중인 Application Load Balancer와 연결해주었다.

 

타겟 그룹 생성

그리고 3000 포트로 연결해줄 타겟 그룹을 새로 생성하였다.

 

로드 밸런서 Listener 규칙 추가

이제 인증서를 붙여둔 443 Port의 Listener 규칙을 새로 추가해야 한다.

 

아래 규칙은 기존에 정의해둔 규칙으로,

요청이 들어오면 80 포트로 연결된 타겟 그룹의 인스턴스로 요청을 넘기도록 한 것이다.

 

추가한 규칙은 위에 위치한 규칙이다.

이제는 만약 들어온 요청의 호스트가

test.hou27.shop이라면 3000 포트로 연결된 타겟 그룹으로 요청을 넘기게 된다.

 

 

최종 클라우드 구성도

시도 2에서 진행한 후 최종 클라우드의 구성은 위와 같다.

 

이제 추가적으로 인스턴스를 기동 하지 않고도 하나의 인스턴스 내에서 https 통신을 하는 2개의 서버를 운영하면서

테스트와 배포를 효율적으로 진행할 수 있게 되었다.