1. 클라이언트 배포를 위한 환경 설정

• 실습에 적용한  repository의 클라이언트는 JavaScript, React를 이용해 작성되었다
• 배포를 실습하기 전에 로컬 환경에서 Build 과정에 필요한 환경을 준비한다
• EC2 인스턴스가 아닌 개인 PC, 로컬에서 진행해야 한다

 1) nvm 설치

https://github.com/nvm-sh/nvm#install--update-script

• 버전이 최신 버전으로 바뀌어 있을 수 있으니 확인한다

• 아래 명령어를 터미널에 입력하여 wget 명령어로 nvm 설치를 시도한다

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

• Command 'wget' not found 메세지와 함께 설치가 진행되지 않는 경우에는 Package Manager를 이용해 wget을 설치한다

# Ubuntu
sudo apt update
sudo apt install wget

# macOS
brew update
brew install wget

2) nvm 설치 확인

•  콘솔 화면에 'Close and reopen your terminal to start using nvm'이 출력되면 설치가 정상적으로 된 것이다

• Close and reopen your terminal to start using nvm or run the following to use it now(터미널을 닫았다가 다시 열어 nvm 사용을 시작하거나 다음을 실행하여 지금 사용하십시오.)
  - 터미널을 닫았다가 다시 시작하는게 편한다

• 터미널을 다시 시작한 후 다음 명령어를 이용하여 nvm 패키지 버전을 확인한다

nvm --version

• 버전이 확인되면 NVM 설치가 성공한 것이다
  - nvm을 찾을 수 없다는 에러가 발생하여 다시 설치한 후 아래 명령어를 실행했다
  - 정상적으로 버전이 확인된다

 3) node.js 설치

• nvm은 node.js의 다양한 버전을 쉽게 설치할 수 있다
• nvm을 이용해 node.js를 설치한다
• 아래 명령어와 같이 설치하려는 node 버전을 적어 준다
  - LTS(Long-Term Support)는 node.js에서 지원하는 기간이 길다는 의미이다

nvm install --lts

• 설치된 node의 버전을 확인한다

node -v

2. S3 호스팅

 1) S3 버킷을 이용한 정적 웹 사이트 호스팅 과정

• 정적 웹 사이트를 호스팅하는 과정은 4 단계로 요약된다
  - 첫 번째로 구현이 완성된 정적 웹 페이지를 빌드한다
  - 빌드 후 S3 대시보드에 접속하여 버킷을 생성한다
  - 생성한 버킷을 정적 웹 사이트 호스팅 용으로 구성한다
  - 빌드된 정적 웹 페이지를 버킷에 업로드한다
• 업로드가 완료되면 퍼블릭 액세스 차단 설정을 해제하고, 다른 사용자의 접근 권한을 부여하는 버킷 정책을 생성한다
• 모든 과정이 끝나면 사용자들이 버킷에 업로드된 정적 웹 페이지에 접속할 수 있다

 2) 정적 웹 페이지 빌드

• 빌드(build)는 작성한 코드의 불필요한 데이터를 없애고, 통합 및 압축하여 배포에 적합한 상태를 만드는 과정이다
• 빌드 과정을 통해 코드를 담고 있는 데이터의 용량은 줄어들고, 웹 사이트의 로딩 속도는 빨라진다
• 클라이언트 프로젝트를 빌드하기 전에 터미널(WSL)을 이용하여 client 디렉토리로 이동한 후 클라이언트의 의존성 모듈을 설치한다
  - client 디렉토리는 실습용 프로젝트 코드를 clone한 폴더에서 진행한다

$ cd client
$ npm install

• 클라이언트의 경우 환경변수는 .env 파일에 선언한다
• 실습 Repository에서  .env.example 파일을 찾아서 예시에 있는 주소를 입력한다
  - 요청을 보내는 서버의 주소를 환경 변수치에 담을 때는 필히 'http://' 나 'https://'를 포함해야 하며, 특정 포트에서 작동하는 경우 포트 번호까지 꼭 작성한다
  - 아래 이미지는 미리 .env로 변경한 다음 이미지이다
• 최종적으로 이 파일의 이름은 .env.example이 아닌 .env여야 한다
  - 슬라이드의 명령어를 통해 파일의 이름을 변경할 수 있다

• 해당 파일(.env 혹은 .env.example) client 디렉토리 내부에 위치하며, CLI에서 ls -a 혹은 ls -al 명령어로 확인할 수 있다
  - 파일을 수정할 수 있는 에디터(nano, vi 등)를 이용해 서버의 주소를 작성 후 저장한다
  - 파일 수정 명령어는 mv .env.example .env 이다

•  환경 변수를 제대로 설정하지 않으면 서버에 요청을 제대로 보내지 못하게 되고, 그 결과로 정상적인 응답을 받아올 수 없다

   2-2) 빌드 진행

•  터미널에 'npm run build' 명령어를 입력하여 빌드 과정을 진행한다

npm run build

• 터미널 화면에 'Compiled Successfully'라는 문구가 보이며 빌드 과정이 마무리된다

• 빌드 과정이 끝나면 client 디렉터리에 'build' 폴더가 생성된 것을 확인할 수 있다

• 터미널에서 ls 명령어를 통해서도 확인할 수 있고, 파일탐색기(파인더) 혹은 IDE로도 확인할 수 있다

3) 버킷 생성

• AWS 홈페이지에 로그인을 한다
• 메인 콘솔 창에서 S3를 검색하여 S3 메인 화면에 접속한다

 

• S3 메인 화면으로 이동하여 '버킷 만들기' 버튼을 클릭한다 

• 버킷 만들기에서는 여러 옵션을 지정할 수 있다
• '일반 구성' 옵션에 있는 내용만 완성한다
  - 버킷 이름을 작성한다
    : 버킷 이름은 각 리전에서 중복되지 않는 고유한 이름이어야 한다
    : 원하는 이름으로 버킷 이름을 작성한다

• 버킷 이름 작성이 완료되면, 화면의 가장 아래에 있는 '버킷 만들기'라는 버튼을 클릭한다

• 버킷이 성공적으로 생성되었다는 메시지와 아래 화면으로 이동된다

 3) 정적 구성

• 생성한 버킷을 클릭한다

• 속성 메뉴를 눌러 이동한다

• 속성 메뉴 화면에서 페이지의 스크롤을 가장 아래로 내린다
• '정적 웹 사이트 호스팅' 옵션이 보이면 '편집' 버튼을 클릭한다

• 정적 웹 사이트 호스팅의 활성화/비활성화 여부를 묻는 창이 나온다
• '활성화' 옵션을 선택한다

• 활성화를 선택하면 여러 옵션을 추가로 변경할 수 있다
• 인덱스 문서를 작성한다
  - 인덱스 문서 부분에는 웹 사이트 주소에 처음 접속했을 때 보일 기본 페이지를 지정한다
  - '인덱스 문서' 기입란에 'index.html'을 작성한다
• '오류 문서' 부분은 공란으로 비워놔도 된다
  - 오류 발생 시 메인 페이지를 반환하기 위해서 'error.index.html'을 기입한다

• '변경 사항 저장' 버튼을 클릭한다

 

• 변경 사항이 저장되면, '정적 웹 사이트 호스팅을 편집했습니다'는 메시지와 함께 속성 메뉴 페이지로 리디렉션 된다
• 페이지의 가장 아래로 스크롤을 내려서 방금 편집했던 정적 웹 사이트 호스팅 옵션 부분으로 이동한다
• 예전에 존재하지 않았던 버킷 웹 사이트 엔드 포인트가 생성되었다
• 해당 주소를 클릭한다

• 에러 메시지를 확인할 수 있다
• 이유는 버킷에 정적 웹 페이지 파일을 아직 업로드하지 않았고, 퍼블릭 액세스 설정 변경과 정책 생성을 하지 않았기 때문이다

• 속성 메뉴 옆에 있는 '객체' 메뉴를 클릭해서 이동한다

• 객체 메뉴로 이동하여 '업로드' 버튼을 클릭한다

• build 폴더 안에 포함된 내용을 업로드 한다
  - client 폴더 안에 있는 build 폴더를 열어 안에 있는 파일을 모두 드래그하여 이동한다

 

• 객체를 업로드하는 페이지에 필요한 파일을 드래그& 드랍 형식으로 업로드 할 수 있다
• 주의 할 부분은 build 폴더 자체를 업로드하는 게 아닌 build 폴더 안에 저장된 파일만 업로드해야 한다
• build 폴더 안에 있는 파일들이 업로드 대기 목록에 추가되었으면 '업로드' 버튼을 클릭한다

• 업로드가 완료되면  '업로드 성공' 메시지를 확인할 수 있다
• 확인 후 '닫기'를 클릭한다

 3-1) 퍼블릭 액세스 차단 옵션 해제 및 정책 생성

• S3 메인 화면으로 이동하여 생성한 버킷을 클릭한다
• '권한' 메뉴를 클릭한다
• 권한 메뉴에서 '퍼블릭 액세스 차단(버킷 설정)'이라는 옵션에서 '편집' 버튼을 클릭한다

• '모든 퍼블릭 액세스 차단' 옵션의 체크 박스를 해제하고  '변경 사항 저장' 버튼을 클릭한다

• '변경 사항 저장' 버튼을 클릭하면 경고 창이 뜨는데, '확인'을 기입하고 확인을 클릭한다

• 버킷 퍼블릭 액세스 차단을 변경하고 나면 다시 권한 메뉴로 리디렉션 된다
• 퍼블릭 액세스 차단(버킷 설정) 옵션 밑에 있는 '버킷 정책' 옵션을 찾아서 '편집' 버튼을 클릭한다

• '정책 생성기' 버튼을 클릭한다

• 새 창이 뜨면서 AWS Policy Generator 페이지에 접속된다
• 여기서 버킷 정책을 생성한다
• 'Select Type of Policy' 옵션에서는 'S3 Bucket Policy'를 선택한다
• 'Principal' 옵션은 권한을 적용할 사용자를 정한다
  - 모두에게 공개할 것이므로 *(별표)를 입력한다
• 'Actions' 옵션에서는 'GetObject'를 선택한다
  - 버킷에 접근하는 모든 사용자가 버킷 내에 저장된 객체 데이터를 읽을 수 있다
  - 버킷을 웹 사이트 용도로 구성할 때 선택한다
• ARN에는 앞서 작성한 버킷 이름을 정확하게 작성합니다. 예) arn:aws:s3:::practice-bucket-deploy/*

AWS Policy Generator

• 'Generate Policy' 버튼을 누르면 정책이 생성된다

• 정책은 JSON 형태로 생성된다
• 생성된 정책을 드래그해서 복사한 뒤 Close 버튼을 누른다

• 버킷 정책 편집 페이지로 돌아가서 복사한 Json 파일을 정책에 붙여 넣고 '변경 사항 저장' 버튼을 클릭한다

• 모든 과정이 완료되었다
• 성공적으로 완료되었는지 테스트하기 위해서 속성 메뉴로 이동한다
• 정적 웹 사이트 호스팅 옵션을 찾은 뒤, 버킷 웹 사이트 엔드 포인트 주소를 클릭하여 테스트를 진행한다
• 브라우저에 정상적으로 화면이 출력된다면 성공적으로 마무리된 것이다

1. EC2(Elastic Compute Cloud)

 1) 개요

• 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스이다
• 클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 서비스를 제공하는 시스템이다
• 사용한 만큼의 비용을 지불하기 때문에 '탄력적인'이라는 의미의 Elastic 단어를 사용한다
• 비용적인 부분뿐만이 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다
• EC2 서비스는 AWS에서 비용, 성능, 용량 면에서 탄력적인 클라우드 컴퓨터를 제공하는 서비스라고 할 수 있다

 2) 장점

• 구성하는 데 필요한 시간이 짧다
  - PC를 구매할 경우 배송까지의 시간이 필요하지만 EC2 서비스는 몇 번의 클릭만으로 PC를 구성할 수 있다
• AMI를 통해서 필요한 용도에 따라 다양한 운영체제에 대한 선택이 가능하다
  - EC2에서는 AMI라는 다양한 템플릿을 제공한다
  - 필요에 따라 손쉽게 운영체제를 선택하고 구성할 수 있다
  - CPU와 RAM, 용량도 쉽게 구성할 수 있다

 3) Instance

• EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다
• 아마존에서 전 세계에 만들어 놓은 데이터 센터(인프라)에 컴퓨터가 위치하고 있다
• 컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다
• EC2를 통해 웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공할 수 있다
• 인스턴스는 1대의 컴퓨터를 의미하는 단위이다
• AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 한다

 4) AMI(AmazonMachine Image)

• 소프트웨어 구성이 기재된 템플릿이다
• 템플릿 종류로는
  - 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿과
  - 특정 런타임이 설치되어 있는 템플릿이 제공된다(우분투 + node.js, 윈도우 + JVM 등)
• 사용 용도에 맞게 운영체제, 런타임 등이 구성된 템플릿을 선택할 수 있다 

 

• Instance는 선택한 AMI를 토대로 구성된다
• AWS에는 상당히 많은 양의 AMI 세팅이 준비되어 있어서 쉽게 인스턴스의 운영체제를 구성할 수 있다
• 세팅되어 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있다

 

2. RDS(Relational Database Service)

3. S3(Simple Storage Service)

•  AWS에서 제공하는 클라우드 스토리지 서비스이다

• 인터넷 공간에 데이터를 저장하는 저장소를 말한다
• 컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스이다
• 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스이다
• 클라우드 스토리지 서비스의 장점
  - 뛰어난 접근성을 가지고 있다
  - 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다
  - 컴퓨터 외에 웹에 접속이 가능한 전자기기를 활용하여 클라우드 스토리지에 저장된 데이터에 접속할 수 있다

 2) S3 장점

• 뛰어난 접근성을 가지고 있다
• 높은 확장성을 가지고 있어서 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장/축소할 수 있다
• 스토리지의 용량을 무한히 확장할 수 있다
• 사용한 만큼만 비용을 지불하면 되므로 비용적인 측면에서 매우 효율적이다
• 99.999999999%의 내구성을 보장하기 때문에 저장된 파일의 유실 가능성이 적다
  - S3에 저장된 파일을 잃어버릴 확률보다, 길을 걷다가 벼락을 맞을 확률(약 0.0000007%의 확률)이 700배나 높다
• 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있다
  - 파일들을 정상적으로 사용할 수 있는 시간이 길어진다
  - 1년 동안 S3에 파일을 저장했을 시, 8.76 시간 동안만 스토리지 이용에 장애가 발생할 수도 있다
• 다양한 스토리지 클래스를 제공한다
  - 저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라진다
  - 대표적으로 많이 선택하는 스토리지 클래스는 Standard 클래스와 Glacier 클래스이다
    : Standard 클래스는 범용적인 목적으로 사용하기에 적합하다
      - 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르다
      - 보관 비용이 높게 발생하기 때문에 데이터를 오래 보관하는 목적으로는 비효율적이다
• 정적 웹 사이트 호스팅이 가능하다
  - 정적 파일은 서버의 개입 없이 생성된 파일이다
  - 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 생성한 파일을 '동적' 파일이라고 한다
  - 웹 호스팅(Web Hosting)이란 서버의 한 공간을 임대해 주는 서비스이다
   : 개인 또는 단체는 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있다
   : S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다
   : 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다

 3) 리전(Region)

• AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치이다
• 지도의 주황색 동그라미 안에 숫자가 리전에 위치한 가용 영역의 수이다
• 가용 영역(Availability Zone)은 각 리전 안에 존재하는 데이터 센터(IDC)를 말한다
• 가용 영역은 각각 개별적인 위치에 존재한다
• 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 한다
• 리전의 가동 방식을 통해 AWS에서 제공하는 서비스들의 높은 가용성과 내구성을 보장한다

• S3에 저장되는 파일들이 담기는 바구니이다
• 파일을 저장하는 최상위 디렉터리이다
• S3에서 저장되는 모든 파일은 버킷 안에 저장된다
• 버킷에는 무한한 양의 파일을 저장할 수 있다
• 각각의 버킷은 이름을 가지고 있다
• 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다
• 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다

 5) 객체(Object)

4. 배포

• 개발한 서비스를 사용자가 이용할 수 있도록 하는 것을 배포라고 한다
• 개발한 서비스를 사용자들에게 Client를 어떻게 제공할지 그리고 Client를 받은 사용자들이 서비스를 이용하기 위한 요청을 처리할 Server를 어떻게 제공할 것인지 Server의 데이터를 저장하고 제공할 Database는 어떻게 제공할 것인지를 결정해야 한다

 1) Client 코드 제공

• AWS에서 제공하는 서비스인 S3라는 서비스를 통해 사용자들에게 Client를 제공할 수 있다
• 로컬 환경에서는 자체 개발 서버 (예, create-react-app)를 이용해서 클라이언트 앱을 실행시킨다
• 클라이언트를 위해서 EC2 인스턴스를 사용할 필요는 없다
  - 클라이언트 앱을 정적 파일로 빌드하여 제공하므로 S3를 이용해서 클라이언트를 배포한다

 2) 빌드(Build)

• 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/ 압축하여 배포에 최적화된 상태를 만드는 것이다
• 빌드 과정을 진행하면 데이터의 용량이 줄어들고, 웹 사이트의 로딩 속도가 빨라진다
• 일반적인 의미의 빌드는, 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미한다
• 웹 앱에서와같이 HTML, CSS, JS의 형태로 배포하는 경우는 조금 다르다
  - 웹 앱은 배포 가능한 정적 파일(static files)의 형태로 만들어야 한다
  - asset 자체가 정적인 경우에는 그대로 배포하면 된다
  - React의 경우에는 npm run build와 같은 명령을 사용하여 정적 파일 형태의 결과물을 만들어 낸 후 배포한다
  - 사용하고 있는 환경에 따라 빌드 과정은 다를 수 있다

 3) 데이터 제공

• AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터센터에 데이터를 분산시켜서 저장한다
• AWS는 사용자와 가까운 지역의 센터에서 데이터를 주는 방식으로 사용자에게 빠른 서비스를 제공한다

 4) 도메인 접속

• 지금까지 이용했던 서비스는 www.google.com과 같은 도메인 주소를 이용해서 접근하였다
• google 사이트에 접속하기 위해서 172.217.151.228이라는 IP주소를 입력하지는 않았다
• S3, EC2를 이용해서 배포된 서비스는 IP주소 혹은 AWS에서 제공하는 서비스와는 전혀 상관없는 긴 도메인주소를 통해 접근하게 된다
• TodoList 서비스를 제공할 경우
  - www.todolist.ap-northeast-2.compute.amazonaws.com 주소보다는 www.todolist.com주소 일 때
  - 직관적으로 서비스를 이해할 수 있고 짧은 주소를 통해 서비스에 접근할 수 있다
• AWS에서 제공하는 Route 53 서비스를 이용하면 직관적인 도메인 주소를 통해서 서비스에 접근하도록 할 수 있다