배포 - AWS 기초

배포 – Amazon Web Service(AWS) 사용 기초

가상화 기술의 발전과 AWS의 등장으로 우리는 직접 서버를 구축하고 관리할 필요없이 클라우드 컴퓨팅으로 서버를 사용할 수 있다
→ 클릭 몇 번으로 서버 사용 및 확장이 가능해짐

 

• AWS 서비스는 프리티어 로 이용하면 대부분 무료이나, 요구 조건을 충족하지 못하면 소액 과금이 부과될 수 있으므로 꼭 주의하자!

학습 목표

* Cloud와 Deployment의 의미 이해와 나의 코드 배포하기
- 클라우드 컴퓨팅
- 애플리케이션 배포의 변천

* AWS의 각 서비스의 목적
- S3의 목적과, 정적 웹 사이트 배포 방법
- EC2의 주요 용어(AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
- EC2의 인스턴스 시작/중지/종료
- RDS와 EC2에서의 MySQL 사용의 차이점
- CloudFront의 목적
- 로드 밸런서 중 ELB, 그 중에서 Application Load Balancer의 목적
- Route 53의 목적 이해와, 도메인을 연결한 HTTPS로 배포하기

* 배포 시 발생하는 문제와 트러블슈팅
- 서버를 프로세스로 작동시키고, 로그 확인하기
- 빌드 및 배포시 필요한 환경 설정

Cloud Computing

• 클라우드 컴퓨팅 등장 이전의 방식: 일반적인 서버실
  → 서버실에 컴퓨터를 배치하고 인터넷 연결해서 서비스 제공
  → 수용량 한계 시: 수평적 확장(컴퓨터 추가) 또는 수직적 확장(성능 개선)
• 이러한 기존 방식의 한계
  → 주기적인 유지관리 필요(인력 및 비용 증가)
  → 공간의 한계(서버실 공간의 제약)

이러한 한계를 극복하기 위해 일부 대형 기업들은 데이터 센터 라는 거대 건물(거대 서버실)을 세움
→ 데이터 센터의 남는 유휴 자원을 대여하는 서비스가 등장하게 됨
→ 서버의 자원과 공간 및 네트워크 환경의 제공을 빌려 사용(대여)하는클라우드 컴퓨팅의 등장

클라우드의 등장

• 온프레미스: 앞서 언급한, 서버의 자원과 공간 및 네트워크를 제공하는 환경을 의미
• 현대의 클라우드 컴퓨팅은 물리적인 컴퓨터가 아닌 가상화 기술을 이용한 가상 컴퓨터를 대여하는 방식
  (온프레미스와는 차이)
• 가상화 기술을 사용하는 (최근의) 클라우드 컴퓨팅의 장점

* 1. 필요할 때 마다 컴퓨팅 능력을 유연하게 조절 가능

* 2. 사용한 만큼만 요금 지급(cf. 온프레미스: 고정적인 비용)

* 3. 다른 컴퓨터로 즉시 이주(migration) 가능: snapshot(*이미지)를 이용

• 이러한 클라우드 컴퓨팅도 단점이 존재

* 운영 환경 자체가 클라우드 제공자(서비스)에게 종속됨
- 클라우드 서비스에 문제가 생기면, 내 앱의 운영에도 문제가 생김
→  ex: aws의 서버 장애로 특정 서비스가 지연되는 경우

- 백엔드 자체가 특정회사의 기술로만 구성해야 하는 경우가 발생할 수도 있음

뿐만 아니라 보안이 중요한 경우 온프레미스를 선호하기도 함
(cf. 클라우드의 경우, 데이터(정보)가 그 리전이 속한 지역의 법을 따르므로 나라 간 법 적용 등 문제 있음)

클라우드 서비스의 형태

기본 제공 서비스 범위에 따라 크게 3가지로 나뉜다

* SaaS(Software as a Service)
- 클라우드 제공자가 당장 사용가능한 소프트웨어까지 제공하는 경우

* PaaS(Platform as a Service)
- 클라우드 제공자가 데이터베이스/개발 플랫폼까지 제공하는 경우

* IaaS(Infrastructure as a Service)
- 클라우드 제공자가 가상컴퓨터까지만 제공하는 경우

AWS의 경우 IaaS에 가깝다고 보면 된다

출처: codestates

 

Deployment(배포)

배포란 개발한 서비스를 사용자들이 이용가능하게 하는 과정

배포 과정은 기본적으로 4단계 절차로 나뉜다

• Development → Integration → Staging → Production

Development 단계

• local 컴퓨터 환경에서 개발 및 테스트하는 단계
• 실제 데이터를 이용하지 않고 더미 데이터(sample data)를 이용한 테스트
• 변경 사항이 있어도 문제가 되지 않음
• 모든 구성원이 각자의 환경에서 진행

Integration 단계

• 각자의 환경에서 작성한 코드를 합치는 단계
• 코드 간 conflict가 없는지 확인
• 작성한 코드가 다른 코드에 문제를 발생시키지 않는지 확인

Staging 단계

• 실제 출시 단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행
• 실제 데이터를 복사해서 문제가 없는지 다양한 환경에서 테스트
• 모든 관계자들에게 검증하는 단계(예상했던 결과가 맞는지?)

Production 단계

• 개발된 서비스를 출시하는 단계
• 코드를 구동하고 서비스를 제공
• 실제로 서비스가 제공/운영되는 단계

환경 설정과 코드의 분리: 환경 변수를 이용

development 환경과 production 환경은 서로 다를 수가 있고, 협업 시 각자의 구성원이 사용하는 환경도 다 다를 수 있다(node 버전 및 db 패스워드 등등)

 

이런 부분들을 코드에 다 담을 수가 없다
→ 환경의 차이를 이해하고, 환경 설정을 코드와 분리하는 것이 중요

 

작성한 코드를 다른 환경에서 정상 작동할 수 있게 하려면 설정을 환경 변수(env)에 저장해야 한다

• 환경 설정을 코드로부터 분리하는 방법

* 절대경로 대신 상대경로를 사용

* 환경에 따라 포트를 분기할 수 있도록 환경변수를 설정

* `docker`와 같은 개발 환경 자체를 통일시키는 솔루션의 사용
→ 환경 자체를 메타데이터로 담아서 모든 개발환경을 통일시켜줌

Amazon Web Service(AWS)

배포를 위한 플랫폼은 대표적으로 heroku, aws, microsoft azure, firebase 등이 있는데,
여기서는 가장 대표적인 플랫폼인 AWS의 기능에 대해 알아보자

EC2(Elastic Compute Cloud)

AWS에서 제공하는 클라우드 컴퓨팅 서비스
→ 간단히, AWS에서 원격으로 제어할 수 있는 가상의 컴퓨터 한대를 빌리는 것
→ 인스턴스를 빌린다고 보면 되고, 주로 서버 작업 용도로 사용

• EC2에서 Elastic의 의미?
  → Elastic = 탄력있는, 유연함
  → 후불제 pc방처럼 사용한 만큼만 탄력적으로 비용을 지불하는 것(성능, 용량적 부분도 탄력적)

EC2 사용의 장점

• 구성하는데 필요한 시간이 짧음
  → 몇번의 클릭만으로 가능
• 다양한 운영체제에 대한 선택이 가능
  → AMI라는 템플릿을 통해 손쉽게 운영체제 선택 및 구성 가능(사양 구성도 손쉽게 가능)

Instance

인스턴스는 컴퓨터 1대를 의미하는 단위
AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다고 함

AMI(Amazon Machine Image)

인스턴스를 생성하는데 필요한 소프트웨어 구성(os, 앱 서버, 애플리케이션 등)이 포함된 템플릿
→ 간단히, 이미지 템플릿

 

이미지 종류로는 단순히 운영체제만 깔린 템플릿도 있고, 특정 런타임이 같이 설치된 템플릿도 있다
(ex. 우분투+node.js, 윈도우+jvm 등)

 

AWS에서 빌릴 pc는 사용 용도에 맞게 운영체제, 런타임 등이 구성된 setting을 선택할 수 있다

 

이미 셋팅된 AMI 이외에도 필요 시 직접 AMI를 구성할 수도 있다

즉, 정리하면 EC2 인스턴스를 생성한다는 것은 AMI를 토대로 setting된 pc를 빌린다는 것

RDS(Relational Database Service)

AWS에서 제공하는 관계형 데이터베이스 서비스
→ 이름 그대로 RDBMS 용도로 사용하는 서비스

• 인스턴스에 mySQL 같은거 설치해서 쓰면 될 거 같은데, 왜 굳이 이걸 사용할까?
  → mySQL 설치해서 쓰는 것과 RDS 이용하는 것은 마치, 개인 소유 차량과 렌터카 대여 차량으로 비유 가능
  → 유지보수 부분을 AWS에서 전부 담당해 주니깐, 유저는 그냥 쓰기만 하면 된다

RDS 사용의 이점

• EC2 인스턴스에 직접 DB 설치 사용
  → 직접 관리해야 할 부분이 많음

이 부분들을 직접 관리해야 한다

* 데이터베이스 규모 확장
* 가용성, 내구성 확보
* 데이터 백업
* 데이터베이스 설치/관리

• RDS 사용
  → 데이터 유지보수와 관련된 부분을 aws가 자동관리(앞서 언급된 부분들을)
  → 사용자는 초기 설정을 제외하고는 데이터베이스에 저장된 데이터만 관리하면 됨(편의성 up)
  → 또한, 다양한 데이터베이스 엔진 선택지도 제공

S3(Simple Storage Service)

먼저 클라우드 스토리지 개념을 알아야 한다

• 클라우드 스토리지: 인터넷 공간에 데이터를 저장하는 저장소
  → google drive, 네이버 mybox, 마이크로소프트 onedrive

S3는 AWS에서 제공하는 클라우드 스토리지 서비스
→ 간단히 말하면, 클라이언트 용도로 쓸 파일들을 빌드해서 S3 버킷에 올리면 된다(주로, 정적 웹사이트 호스팅 용)

S3 사용의 이점

* 확장성
- 쉽게 스토리지 규모를 축소/확장 가능
- 데이터를 무한히 저장 가능(단, 사용한 만큼만 비용 부담)

* 강력한 내구성
- 저장된 파일을 유실할 가능성이 적음
- 99.999999999% 의 내구성을 보장(벼락 맞을 확률이 유실할 확률의 700배)

* 높은 가용성
- 스토리지에 저장된 파일을 정상적으로 사용할 수 있는 시간이 길어짐
- 연간 99.99%의 가용성 보장
→ 1년 동안 S3에 파일을 저장하면 약 8.76시간만 이를 이용하는데 있어 장애가 발생한다는 뜻

* 다양한 스토리지 클래스를 제공
- 저장소의 사용 목적에 따른 다양한 선택지를 제공한다는 뜻
- standard 클래스: 범용적인 목적으로 사용(가장 일반적), 데이터에 자주 액세스할 때 사용, 대신 보관 비용이 높음
- glacier 클래스: 데이터 장기보관 목적, 액세스 속도는 상대적으로 느리지만 보관 비용이 저렴

* 정적 웹 사이트 호스팅이 가능
- 정적 파일: 서버의 개입 없이 클라이언트에게 제공된(생성된) 파일
- 동적 파일: 클라이언트가 서버에 요청을 보내면 그에 맞추어 생성한 파일
- 웹 호스팅: 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어 주는 서비스
→ S3 에서는 버킷을 통해 정적 웹 사이트 호스팅이 가능하다
→ 버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹사이트 호스팅 용도로 구성하면 됨

버킷

S3에 저장되는 파일들이 담기는 바구니(파일을 저장하는 최상위 디렉토리)
→ S3에 저장되는 모든 파일은 버킷 안에 저장되어야 함

• 버킷은 무한히 많은 파일을 저장 가능
• 버킷의 이름은 (버킷이 속한) 각 리전(버킷이 생성된 지역)에서 고유해야 함
• 버킷의 정책을 생성하여 해당 버킷에 대한 (다른 유저의) 액세스 권한을 부여 가능

객체

객체는 버킷에 담기는 파일을 뜻함
→ S3에서 저장소에 데이터를 저장할 때, 키-밸류 페어 형식으로 데이터를 저장하기 때문에 이렇게 부름

* 객체는 파일과 메타데이터로 구성

* 파일의 값에는 실제 데이터를 저장(최대 5TB까지 가능)

* 파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할(모든 객체는 고유한 키를 가짐)

* 메타데이터는 객체를 설명하는 데이터(객체의 생성일, 크기, 유형 등)

* 모든 객체는 고유한 URL 주소를 가짐
→ URL 주소를 통해 객체에 접근 가능

* URL 주소 형식
→ http://[버킷의 이름].S3.amazonaws.com/[객체의 키]

배포 전략(Deploy Strategy)

개발한 Client, Server, Database를 어떻게 배포할 것인가에 대한 부분

Client 배포

작성한 Client 코드 배포
→ AWS 서비스 중 하나인 S3를 이용해서 사용자에게 Client application을 제공 가능

• 로컬 환경에는 자체 개발 서버(ex. create-react-app)을 이용해서 클라이언트 앱을 실행시켰는데, 그렇다면 클라이언트를 위해 EC2 인스턴스를 사용해야 하는가의 의문?
  → 그렇지 않다. 클라이언트를 정적 파일로 빌드하여 배포하면 된다
  → 따라서, S3를 이용해 배포하는 것
• 빌드?
  불필요한 데이터를 없애고, 통합/압축하여 배포하기 좋은 최적화된 상태를 만드는 것
  데이터의 용량이 줄어들고 웹 사이트 로딩 속도가 빨리짐
  → 일반적인 의미의 빌드는 소스코드를 실행 가능한 번들로 변환하는(번들링하는) 컴파일 과정을 의미
  → 빌드 과정은 사용하고 있는 환경에 따라 다를 수 있다

웹 앱과 같이 HTML, JS, CSS의 형태로 배포하는 경우
웹앱을 배포가능한 정적 파일(static files)의 형태로 만들어 줘야 한다

 

asset 자체가 정적인 경우는 그대로 배포하면 됨
react의 경우 npm run build 를 통해 정적 파일의 결과물을 만들어서 배포
→ 즉, npm run build 명령어로 만들어진 build 폴더 내의 모든 파일을 버킷에 업로드

 

• 사용자가 멀리 있는데 더 빠르게 서비스를 제공하고 싶으면?
  → CDN을 이용
  → aws의 CDN 서비스인 CloudFront(proxy server의 개념)

Server Application 배포

사용자들이 S3와 CloudFront를 통해서 Client Application을 제공받았다는 가정

 

Client Application을 통해 요청과 응답을 주고 받을 Server는 어떻게 배포?
→ AWS EC2 서비스를 통해 가상의 PC를 빌려 서버 코드를 구동

Database 배포

AWS의 관계형 데이터베이스 특화 서비스인 RDS 서비스를 이용하자

DNS

AWS에서 제공하는 Route53 서비스를 이용하여 직관적인 도메인 주소로 서비스에 접근하도록 설정 가능
→ EC2와 S3로 배포된 서비스의 IP 퍼블릭 DNS는 직관적이지 않고 매우 길다

 

ex) dadsa2qeq.aws.dasd213.amazon.com 대충 이런식

 

이를 내가 원하는 직관적인 도메인명으로 서비스에 접근하도록 설정하는 것
→ 물론 좋은 도메인명은 비싸다

주의: 도메인을 따로 어디서 구하거나(무료 사이트 이용) Route53에서 판매도 하는 도메인 주소를 구입해서 라우팅 작업을 해야 하는데
이 부분에서 과금이 좀 생길 수 있으니 잘 체크해야 한다(cost explorer 를 항상 체크해야 함!)