Deploy Strategy 정리

프로젝트를 재배포 하려고 배포에 대해서 꼼꼼하게 준비하면서 내가 잘못 알고 있었던 개념에 대해서도 많이 알게 되었고,  전체적인 웹의 간략한 흐름도 정리할 수 있었다.

 

따라서 간단하게 배포의 가장 기본적인 단계들에 대해서 정리해보려 한다.(기준은 AWS 기준이다. 그러나 각 단계에 필요한 기능들은 다른 곳에서도 사용할 수 있다.

배포 과정을 공부하려 할 때 각 단계에 대한 설명은 쉽게 찾아볼 수 있어도 전체적인 그림을 그리는 것이 생각보다 시간이 오래 걸려서 이 참에 내가 정리해 보았다!

 

 

1. client side

 

이해하기 쉽게 client side라고 표현했다. 실제로 user가 web의 경우 도메인 주소나 ip 주소를 검색창에 입력해서 해당 서비스의 렌더링 된 화면을 보는 과정이다. 

 

이 과정의 경우는 web과 mobile이 약간 차이가 있지만 그 개념적으로는 비슷하다.

 

web application

• AWS S3 bucket에 client 코드들을 build하여 올려둔다. 
• 그러면 이 S3 bucket 자체에 접근할 수 있는 public IP가 생긴다. 
• user의 경우 위의 S3 bucket의 IP 주소로 직접 접근할 수도 있고, 혹은 Route 53으로 만든 DNS를 통해 S3 bucket에 접근하게 된다.

mobile application

• apk라고 기재해뒀는데, 이는 안드로이드 파일 형식이다. 즉, 모바일 앱을 만든 후, 다양한 프로그램을 통해서 build한다.
• 만든 디바이스에 맞는 파일 확장자로 파일이 만들어지면, 구글플레이스토어나 앱스토어에 올려둔다.
• user가 이를 다운받음으로써 client코드로 이루어진 브라우저 화면이 렌더링 되는 것을 볼 수 있다.

=> 여기서 우리는 client 코드의 공통적인 배포 과정을 엿볼 수 있다.

• user 입장에서 눈으로 보이는 client코드를 일종의 파일처럼 build하여 묶어둔다.
• user는 일종의 이 파일을 다운받아서 내 컴퓨터의 브라우저에 띄우는 것이다

그래서 client코드는 가볍고 의미없는 코드들이 최대한 없어야 한다. (그렇다고 server가 무의미한 코드가 있어도 된다는 것은 아니지만)

 

우리 프로젝트의 경우 모바일 앱이라, 이미 build 및 apk파일 제작도 완료되었으므로, DNS를 위해 Route53을 이용하거나 S3를 이용할 경우는 없다. 그러나 S3의 경우는 일종의 파일서버 개념으로, 웹앱의 클라이언트 배포 뿐 아니라, 여러 static 파일들을 외부로 저장해두는 용도로도 사용되고 있다. 실제로 우리 프로젝트에서도 이미지 저장을 S3에 하고, 그 링크만 DB에 저장해두고 있다.

 

따라서 S3 bucket 만들기와 더불어 DNS에 대해서는 후에 추가적으로 다뤄보고자 한다.

 

a. S3 bucket 생성하기(웹) / 앱 build 하기(모바일) 

•  mobile app의 경우, 우리는 프로젝트를 expo 환경에서 react native를 사용하였으므로 이를 기준으로 build 및 배포했다.(블로그 링크)  -> 해당 블로그는 expo 환경이 아닌 RN 언어만을 썼을 경우 배포하는 방법이며, expo 환경에서의 빌드 및 배포에 대해서도 추후 정리할 예정이다(이는 좀 더 쉽다)
• S3 bucket은 실질적으로 웹앱의 client 배포 뿐 아니라, 파일 서버로서의 기능도 한다. 우리는 모바일 앱 프로젝트 때는 S3 bucket을 파일 서버로 활용했다. 따라서 이를 정리하면서 S2 bucket 만드는 법에 대해서도 정리할 예정이다.

b. DNS_Domain 발급(블로그 링크)

c. Rout 53에 name server 생성하여 도메인 등록 및 관리 / ACM - SSL 인증서 발급 (블로그 링크)

 

 

**아래 단계부터는 웹앱이든 모바일 앱이든 공통적으로 진행해야 하는 사항이므로 자세히 다뤄볼 예정이다. 

해당 글에서는 전체적인 배포 단계에 대해서 알아보고 각 기능과 사용법에 대해서는 별도로 자세하게 정리할 예정이다!

 

2. API Gateway

* 실제 AWS에서 사용하는 방법에 대한 블로그 링크

말 그대로 client에서 server로 통신할 때 사용하는 많은 api들의 대문과 같은 역할을 하는 것이다. 

우리가 개발단계에서야 api 주소는 localhost / 127.0.0.1 이렇게 동일하게 진행하지만, 실제 서버는 여러 컴퓨터에서 운용되고, 서버 주소들도 제각각일 것이다.

따라서 이를 상황에 맞춰서 일일이 주소를 바꿔준다면???

매우 귀찮아질 것이다. 위의 client side 배포에서 진행한 build 과정을 다시 다 겪어야 한다. (client 코드의 api 주소를 다 바꿔주어야 하므로) 따라서 이런 일을 방지 하기 위해 있는 것이 API Gateway 이다. 

 

위의 그림을 보면 이해가 쉬울 것이다. 

따라서 하나의 서버 주소가 없어지거나 변경될 경우 우리는 client 코드를 일일이 바꾸는 것이 아니라, api gateway로 가서 각 작은 문들의 라벨링만 바꿔주면 되는 것이다.

 

3. server side

 

API Gatesway를 통해서 브라우저의 요청이 서버로 전달되어 처리되어야 한다. 이를 진행하기 위해 서버 또한 나의 로컬 컴퓨터에만 잠들어 있는 것이 아니라, 가상의 열린 컴퓨터에서 항시 작동되어야 한다. 그 과정을 위한 각 기능들을 하나하나 설명하려 한다.

 

이 과정에서 서버의 public IP 주소 또한 DNS를 통해 도메인을 관리하고, SSL인증서를 발급받아서 보안 인증 된 https된 주소로 client와 통신해야 한다. client는 https이고, server는 아니라면 서로 통신이 안되기 때문이다.

이 부분에서 내가 잘못 이해하고, client에서만 도메인을 발급해주면 된다고 생각했기 때문에 놓칠 뻔했다. 

 

a. ELB(Elastic load balancer)

*AWS ELB 사용에 대한 설명(블로그 참고)

load balancer의 역할은 서버의 과부하를 막기 위해, 그 때의 상황에 따라서 수평적 확장을 통해 서버가 잘 통신되도록 도와주는 역할이다.

API Gateway를 통해서 서버로 요청이 들어오는데, 하나의 요청이 갑자기 많아지는 경우, 만약에 우리가 load balancer를 쓰지 않고 있다면,

그 요청을 담당하는 서버에 과부하가 올 것이다. 

이 때 같은 요청을 담당하는 복제된 서버 하나가 또 있으면 이 업무를 나눠서 처리할 수 있을 것이다. 이러한 역할을 해주는 것이 ELB 이다.

 

실제로 API Gateway부터 ELB 그리고 instance를 연결한 형태는 아래와 같을 것이다.

b. EC2 instance

AWS EC2는 서버를 구동하기 위한 가상 컴퓨터를 빌려주는 것이다. 

이 곳에서 우리가 만든 서버 코드를 옮겨 놓고 구동시키는 것이다.

* EC2에 대한 설명과 서버 구축 방법(블로그 링크)

 

b-1. Web server

* 블로그에 web server에 대한 설명과 설치 방법에 대해서 정리해 두었으니 참고(블로그 링크)

위의 과정들을 통해 전달된 요청을 api server 코드로 잘 전달해서 요청이 잘 처리 되도록 하는 다리 역할을 하는 곳이다.

 

b-2. Web server 내에 우리가 구현한 server application 연결

해당 과정이 제일 중요한 과정인 듯 하다. (블로그 링크)

web server를 통해 요청이 들어온 경우, 우리가 실제로 요청을 처리해야 하는 server로 잘 전달 해주어야 하기 때문이다.