무중단 배포 유지하면서 EC2 교체 하기

 

 

최초에 모놀리식 아키텍쳐로 서비스 운영을 하도록 간단하게 인프라를 구축하였습니다.

하지만 작업하면서 MSA를 지향하게 되었고 서비스의 앞단에 프록시서버를 두기로 결정하였습니다.

이 글은 현재 배포되어 있는 커뮤니티 서비스는 중단되지 않으면서 앞단에 프록시 서버를 추가하는 과정을 적어보겠습니다.

 

---

아래 글은 다음 순서로 작성되었습니다

1. 현재 상황 - 작업을 하는 이유

2. 작업 설계 - 어떻게 작업을 진행할 것인가?

3. 작업 진행 - 3단계의 작업 진행 과정

4. 정리하기 

 

 

1. 현재 상황

현재 운영 중인 커뮤니티 서비스가 사용자는 많지 않지만, 실제 유저분들이 사용하고 있는 상황입니다.

누적 조회수가 50 ~ 80정도 되는 것을 확인할 수 있습니다 ㅎㅎ ( 서비스 링크 )

 

 

 

많은 유저가 사용하고 있다고 가정한다면 서버 작업을 위해서 서비스를 닫았을 때 생기는 피해가 상당할 것입니다.

그래서 최대한 사용자는 작업 중이라는 것을 체감하지 못하는 방법으로 작업을 진행해보겠습니다.

 

 

 

2. 작업 설계 - Free Tier의 한계

처음 커뮤니티 서비스를 설계할 당시 monolithic한 아키키텍쳐를 생각했기 때문에 scale-out 정도만 고려하여 인프라를 구축했습니다.

하지만 작업을 진행하면서 microservice로 설계를 지향하게 되었고, ALB에서 비용이 발생한다는 것을 알게 되어 설계 변경이 필요하게 되었습니다.

 

 

그래서 이번 작업은 전체 서비스의 진입점이 될 Reverse Proxy 서버를 앞단에 추가하고 MSA 형태로 가기 위한 밑작업이 되겠습니다.

현재 Free Tier로 AWS를 사용하고 있는 만큼 여러 개의 계정을 사용하게 되어 상황이 조금 더 복잡해 졌습니다.

 

목표하는 작업 방향은 아래와 같습니다. 기존 요청은 그대로 유지하면서 일부 요청은 새로 추가하는 리버스 프록시 서버를 거쳐서 커뮤니티 서비스를 바라보게 하는 방향입니다.

 

 

 

그래서 최종적으로는 모든 요청이 리버스 프록시로 가도록 만드는 것을 목표로 하겠습니다.

 

 

 

 

3. 작업 진행

3-1. HTTP (80) 를 Reverse Proxy에 연결

Free Tier를 사용해야하는 조건이 있기 때문에 2계의 계정이 필요합니다. 노란색으로 표시된 대상들이 계정 A에 의해서 관리되고 있고 해당 계정의 Route53에서 도메인을 관리하고 있습니다.

 

 

Reverse Proxy 서버로 사용될 Nginx가 설치되어있는 EC2에서 SSL 인증서 발급을 시도하니 다음과 같은 에러가 발생합니다.

http 로 특정 경로에 접근할 수 없다는 이유로 발급이 거절됩니다.

 

 

 

인증서를 적용하려고 하는 인스턴스가 아닌 다른 인스턴스로 요청이 가는 것이 한 가지 문제이고, 80 포트로 접근해서 특정 주소를 찾을 수 없다는 것이 다른 하나의 문제로 보입니다. ( 현재는 80으로 오는 요청은 443으로 Redirect 되고 있습니다. )

 

 

 

우선 80 포트로 오는 요청을 Reverse Proxy를 거쳐서 Community Service로 가도록 설정을 한 뒤에 https 설정을 이어서 진행해보겠습니다.

 

 

 

기존의 ALB에서 접근할 수 있는 target group을 만들어 줍니다.

 

기존 80포에서 redirect를 하던 설정을 위에서 만든 target group으로 이동해줍니다.

이후에 reverse proxy 측에서 로그를 확인해보면 요청이 들어오는 것을 볼 수 있습니다.

 

 

3-2. ReverseProxy 측에 SSL 인증서 설정

프론트엔드 도메인과 서버측 도메인을 다르게 사용하고 있는 것에서 살짝 시간을 빼았겼습니다.

위에서는 간단하게 Client라고 표현하였지만 조금 더 구체적으로 살펴보면 중간에 Vercel이 존재하고 있습니다.

Nestjs로 만들어진 웹서버를 Vercel 서비스를 사용해서 배포 중이고, 웹 화면을 보기 위한 주소는 Vercel에서 리다이렉트를 시킵니다.

 

그러면 Reverse Proxy에서는 서버측 도메인만 처리하면 되겠습니다.

80으로 오는 http 요청은 모두 443 https로 리다이이렉트 되도록 설정하였습니다.

HTTPS 등록 과정은 이 글에서 확인해주세요.

 

 

이걸 테스트할 때는 브라우저의 네트워크 탭에서 인터넷 속도를 강제로 느리게하고 테스트하면 좋습니다.

첫 번째 요청이 설정한대로 301로 리다이렉트 되는 것을 볼 수 있습니다.

 

 

 

 

3-3. Route53에서 도메인이 바라보는 대상 수정하기

지금 작업이 진행된 상태를 살펴보겠습니다.

클라이언트에서 https로 오는 요청은 기존에 배포된 커뮤니티 서비스로 전달됩니다. 그리도 http로 오는 요청은 새로 추가한 Reverse Proxy로 전달됩니다. 이 때 ReverseProxy는 80포트로 오는 http 요청을 443으로 다시 리다이렉션을 진행하는 상황입니다. 

 

 

 

이제는 마지막으로 클라이언트에서 보내는 https 요청이 ReverseProxy로 오도록 수정을 해주면 될 것 같습니다.

목표는 다음과 같습니다.

 

 

 

Route53 으로 가서 서버 도메인이 설정되어있는 Record 설정을 찾습니다.

저는 CNAME 타입으로 ALB를 바라보도록 설정이 되어있는 것을 새로 만든 Reverse Proxy 인스턴스를 바라보도록 수정하겠습니다.

ttl 도 낮게 설정해서 빠르게 반영될 수 있도록 합니다.

 

 

 

마지막으로 nginx에 찍히는 로그를 확인해보면~  성공을 확인할 수 있습니다. 

이제 사용하지 않게 된 ALB를 제거하면 끝입니다.

 

 

 

 

4. 정리하기

중간에 새로 만든 Proxy 서버의 보안그룹에서 HTTPS를 허용하지 않은 것을 놓쳐서 무중단 배포는 아니고 살짝 중단 배포가 되었습니다ㅠ

이슈가 있을 때는 보안그룹도 살펴봐야겠습니다.

 

완성된 인프라의 구조입니다.

 

 

 

감사합니다.