2-2. [Project] AWS 배포

# AWS를 활용한 배포 전략 

개발한 서비스를 사용자가 이용할 수 있도록 하는 것을 배포라고 합니다.

작성한 Client 코드를 사용자들에게 어떻게 제공할지 생각해 봅시다.
AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있습니다.

로컬 환경에서는 자체 개발 서버 (예, create-react-app)를 이용해서 클라이언트 앱을 실행시키는 것이 보통입니다. 
그럼, 클라이언트를 위해서 EC2 인스턴스를 사용해야 할까요?
그렇지 않습니다. 클라이언트 앱을 정적 파일로 빌드하여 제공합니다. 
따라서 S3를 이용해서 클라이언트를 배포합니다.

이때 필요한 것이 빌드입니다.
빌드란 쉽게 말해서 불필요한 데이터를 없애고,
여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포하기에 최적화된 상태를 만드는 것입니다.
빌드 과정을 진행하기 전과 비교했을 때 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다는 장점이 생깁니다. 

하지만 일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다. 
웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다릅니다. 
웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어 줘야 합니다.

asset 자체가 정적인 경우, 있는 그대로 배포하면 됩니다. 
React의 경우 npm run build와 같은 명령을 사용해서, 정적 파일 형태의 결과물을 만들어 낸 후 배포하면 됩니다. 
사용하고 있는 환경에 따라 빌드 과정은 다를 수 있습니다.

S3로 사용자들에게 Client Application을 제공하고 있는데,
사용자가 지구 반대편에 있다면 어떻게 빠르게 서비스를 제공할 수 있을까요?
AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 뒀다가 
가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.

사용자들이 제공받은 Client Application을 통해서 요청을 전달할 Server Application은 어떻게 배포해야 할까요?
AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다.

AWS에서는 Database 특화 서비스인 RDS 서비스를 제공하고 있습니다.
AWS가 유지 보수 작업을 담당하는 RDS를 이용하여 즉시 데이터베이스를 사용할 수 있습니다.
RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있습니다.

 

여러분이 지금까지 이용했던 서비스는 http://www.google.com과 같은 도메인 주소를 이용해서 접근할 수 있었습니다.
google 사이트에 접속하기 위해서 172.217.161.228이라는 IP 주소를 입력하지는 않았을 것입니다.
처음 배포된 여러분의 서비스는 도메인 주소를 통해 접근할 수 있을까요?

S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 여러분의 서비스와는 전혀 상관없는 긴 도메인 주소를 통해 접근하게 됩니다.
TodoList 서비스를 제공한다고 생각해 봅시다.
http://www.todolist.ap-northeast-2.compute.amazonaws.com 주소보다는 http://www.todolist.com 주소 일 때,
직관적으로 서비스를 이해할 수 있고 짧은 주소를 통해 서비스에 접근할 수 있습니다.

AWS에서 제공하는 Route 53 서비스를 이용하면
직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있습니다.

---

#2. Deploy 

배포란 여러분이 개발한 서비스를 사용자들이 이용 가능하게 하는 일련의 과정입니다.

기본적으로 4단계를 거쳐서 개발한 서비스를 배포하게 됩니다.
Development - Integration - Staging - Production

Development 단계는 각자의 컴퓨터에서 코드를 작성하고 테스트하는 과정입니다.
개발 단계이기 때문에 실제 데이터를 이용하지 않고 더미 데이터를 이용해서 테스트합니다.

Integration 단계는 각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다.
내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드 간에 conflict가 있지는 않은지 확인하는 과정을 거칩니다.

Staging 단계에서는 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행합니다.
실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다.
또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다. 
예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀이 예상했던 결과인지 확인을 거치는 과정입니다.

Production 단계는 개발된 서비스를 출시하는 단계입니다.
사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공합니다.
실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안 되는 단계입니다.

Development 환경과 Production 환경은 서로 다를 수가 있습니다.
배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요합니다.

 

작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면?

설정을 환경 변수(envvars나 env라고도 불림)에 저장해야 합니다. 
환경 변수는 코드 변경 없이 배포 때마다 쉽게 변경할 수 있습니다. 
설정 파일과 달리, 잘못해서 코드 저장소에 올라갈 가능성도 낮습니다.

애플리케이션의 모든 설정이 정상적으로 코드 바깥으로 분리되어 있는지 확인할 수 있는 간단한 방법은 어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인하는 것입니다.

코드 상의 모든 곳에 절대 경로가 아닌 상대 경로를 사용해야 하며, `.env` 등을 이용해 환경 변수를 설정하세요. 
그 외에도 docker와 같은 가상화 도구는 환경 자체를 메타데이터로 담아서 아예 모든 개발 환경을 통일시킵니다.

대표적인 배포 플랫폼으로는 Amazon의 AWS, Microsoft의 Azure, heroku, Firebase 등이 있습니다.