Cloudfront - S3 - EC2 도입 ( BE 배포과정 )

Cloudfront - S3 는 여기 👇👇

https://behoney.tistory.com/54

Cloudfront - S3 - EC2 도입 ( FE 배포과정 )

📚   개요

내가 적용하려 했던 구조가 국내에서는 내용이 없어서 해외꺼를 수도없이 뒤지고 나서야 어떠한 구조로 돌아가는지 이해를 했다.

이해를 하는 과정까지 너무 오래시간이 걸렸다.. 잘못된 정보들과 뒤섞이다보니 혼돈이 심했고 이러한 방식으로 했던 예제가 전혀 없었기에 많이 헤맸다.

 

나는 MSA 구조를 만들기 위해서 독립된 기능을 수행하는 서버를 여러개 만들었다.

근데 여기서 문제인것이, 기존의 알려진 MSA 구조를 이행하려면 인스턴스를 여러개 만들어야만 하는데

나같은 가난한 자들은 솔직히 그게 부담스럽다.

 

그래서 간이 MSA 느낌으로 한 EC2 인스턴스 내에서 포트를 나누는 것으로 합의를 봤다.

기존의 알려진 MSA는 EC2 인스턴스를 여러개 오픈하고 각 서버를 배포한다.

그리고 그 서버들에 ELB를 적용하던 Gateway를 적용하던 해서 트래픽을 분산하거나 MSA 구조를 완성하는데

 

전통적인 MSA

나의 MSA

나는 가난해서 인스턴스가 하나이므로 하나의 인스턴스 내부에서 포트를 나눴다.

 

여기서 문제가 발생한점은 Cloudfront와 EC2간의 소통에서 발생했다.

Cloudfront 는 이미 HTTPS 가 적용이 되어있는 상태였는데

HTTPS - HTTP 간의 통신은 보안상 막혀있다.

물론 다 방법은 있지만 정말 위험하고 권장되지않는 방식이여서

EC2에 HTTPS 를 적용하려 하였다.

 

방법은 두가지였다.

1. SSL 인증서를 구매해서 서버측에 두고 서버를 HTTPS 방식으로 오픈한다.

2. ELB를 EC2와 연결하고 ELB에 SSL을 연결한다.

 

나는 1번 방식을 하기엔 또 돈이없다.

( 사설 SSL 을 만들어서 사용하면 크롬 브라우저에서 인증되지 않은 인증서 라면서 막는다. )

고급 - 안전하지 않음 - 안전하지 않은 사이트로 이동을 눌러서 사이트를 뚫어주지 않으면 서버에서 데이터를 못가져온다.

클라이언트에게 이렇게 접근을 하라그러면 누가 하겠는가 피싱사이튼줄 알지

 

그래서 나는 2번 방식을 선택했다.

 

여기서 또 문제가 발생했다.

HTTPS 를 적용하는 과정에서 HTTP로 접근 시 HTTPS 로 변환해주어야 하는데

대부분의 커뮤니티에서 MSA 를 구축할때 인스턴스를 여러개 두고 인스턴스마다 하나의 서버를 둔 다음

인스턴스의 80번포트와 어플리케이션의 포트를 포트포워딩해서 도메인으로 접근 시 서버로 접근이 되도록 하였다.

하지만 나는 어플리케이션마다 포트가 있고 각자의 포트가 있기에 인스턴스의 80번 포트 하나에 포워딩을 할 수 없었다.

물론 하려면 하지만 그렇게하면 의미가 없다. 포트를 나눠서 트래픽을 분산한다는 마인드. 효과는 미미하지만 있긴있다.

아무튼 이러한 구조를 찾아보니 이렇게 하는 사람이 아무도 없었다.. ( 국내에는 )

다들 부잔가?

 

문제는 포트 여러개로 접근 할 때 어떤 방식으로 접근하는지 모르겠고, 설정을 어떻게 하는지 몰랐다.

 

기존 내가 생각했던 방식

실제 방식

⚙️ 설정

ELB 내부에서 두가지에 대해서 설정을 해주어야한다.

• Listener
• Target Group

이걸 보고 잘 생각해보고 구현해보자.

참고로 ACM 의 리전은 내가 배포한 EC2 , ELB와 같은 리전이어야한다.

😎 구현결과

프론트의 응답속도는 약 1.9초 -> 900ms 가 되었다.

캐시 되었을 경우 400ms 까지 내려가준다.

구글의 Light House 를 통해서 분석을 해보니

이미지 리소스의 크기가 너무 커서 시간이 오래걸리는 것으로 나온다.

이미지를 축소할건 하고 품질을 낮춘뒤 webp로 형식을 변환하여 리소스의 크기를 극한으로 줄여봐야겠다.

 

기존의 구조

장점

프론트와 백엔드가 같은 인스턴스 안에 존재하니 React 와 Node간의 소통에서 네트워크 리소스가 들지 않는다.

 

단점

각 이미지들이 차지하는 저장용량이 크다.

CPU에 부하가 더 심하다.

사용자가 처음 React 화면을 보는데까지 상대적으로 시간이 더 걸린다.

 

변경된 구조

 

장점

React 화면을 받는데 시간이 단축된다.

EC2의 부담이 줄어든다.

수정 사항이 있을 때 빌드와 배포가 쉽다.

https 적용이 용이하다.

 

단점

노력이라는 리소스가 커진다.

네트워크 통신에 들어가는 리소스가 커진다.