[Deploy] Amazon Web Service

Deploy 배포

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

 

배포 4단계

1. Development 개발

- Local 컴퓨터 환경에서 개발 및 테스트

- Sample Data 이용

- 변경사항이 있어도 문제되지 않음

- 모든 구성원이 각자의 환경에서 진행

 

2. Intergration 통합

- 각자의 환경에서 개발된 부분을 취합

- 코드간 conflict(충돌)가 없는지 확인하는 단계

- 작성한 코드가 다른 코드에 문제를 발생시키지 않는지 확인

 

3. Staging

- production 단계와 가장 유사한 환경에서 테스트 진행

- 복제된 실제 데이터를 이용해서 다양한 환경에서 테스트

- 모든 관계자들이 검증하는 단계(+마케팅팀, 디자인팀)

 

4. Production

- 실제로 서비스가 제공되는 단계(출시)

- 실제 데이터가 이용되기 때문에 문제가 생기면 안 됨

- 개발 환경과 구분된 환경

 

 

환경 설정과 코드 분리

작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면 설정을 환경 변수에 저장

코드 변경 없이 배포 때마다 쉽게 변경할 수 있음, 설정 파일과 달리 실수로 코드 저장소에 올라갈 가능성도 낮음

 

혼자서 개발부터 배포까지 하는 상황이라면 큰 문제 없이 Production 환경 구성 가능

여럿이 함께하는 프로젝트라면 node 버전 제각각,

인증 정보나 데이터베이스 등에 접근하기 위해 사용하는 엔드포인트도 제각각이기 때문에

-> Development 환경과 Production 환경은 서로 다를 수 있기 때문에 배포에서는 환경 설정을 코드와 분리하는 것이 중요

 

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

- 절대경로 대신 상대경로 사용

- 환경에 따라 포트를 분기할 수 있도록 환경 변수(envvars 혹은 env) 설정

- 개발 환경 자체를 통일시키는 솔루션 사용(docker: 환경 자체를 메타데이터로 담아서 모든 개발 환경을 통일시키는 가상화 도구)

 

애플리케이션의 모든 설정이 정상적으로 분리되었는지 확인할 수 있는 방법은

어떠한 인증정보도 유출시키지 않고 코드가 지금 당장 오픈 소스가 될 수 있는지 확인해보는 것

 

 

Cloud Computing

인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 것

 

클라우드 컴퓨팅 등장 배경

서버실 -> 데이터 센터 -> 클라우드 컴퓨팅

 

서버실

전산실(서버실)에 컴퓨터를 배치하고 인터넷을 연결하여 서비스 제공,

서버의 요청 수용 능력이 한계에 도달하면

같은 공간에 더 많은 컴퓨터 추가하여 요청을 나누어 처리하거나

기존 컴퓨터의 성능 업그레이드

 

- 문제점

1. 주기적인 관리 필요

고장/ 연결이 안되는 컴퓨터가 생긴다면 이를 해결하기 위한 인력 및 비용 필요

-> 관리할 컴퓨터 및 전자기기 수가 많아지는 만큼 투입되어야 하는 인력 및 비용도 증가

 

2. 공간의 한계

공간(서버실)이 부족하여 컴퓨터를 추가로 설치할 수 없는 경우

-> 컴퓨터의 성능을 높이거나 부피를 줄여 같은 공간에 더 많은 컴퓨터를 배치

 

=> 추가 서버 증설이 어렵게되자 일부 거대 기업은 데이터 센터라는 건물을 세우기 시작(=온프레미스)

이때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작

(서버의 자원과 공간 및 네트워크 환경을 제공하는 클라우드 컴퓨팅 시작)

 

현대의 클라우드 컴퓨팅은 가상화(Virtualization) 기술의 발전으로 물리적인 컴퓨터가 아닌 가상 컴퓨터를 대여

 

온프레미스 형식과 차별화되는 장점

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

2. 고정적인 비용이 들어가는 온프레미스와 달리 사용한 만큼의 요금만 지불하면 됨(온디맨드, 종량제, 후불제)

3. 컴퓨터의 스냅샷(이미지)을 이용해 다른 컴퓨터로 즉시 이주(migration) 가능

 

클라우드 컴퓨팅 단점

운영 환경 자체가 클라우드 제공자에게 종속되어, 클라우드 제공자의 규제를 지켜야하며

클라우드 서비스에 문제가 생기면 서비스를 배포하고 관리하는 환경에도 영향을 미침

 

운영 환경이 특정 클라우드 사업자(vendor)에게 종속된다

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

-> AWS 같은 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만 클라우드 서비스 자체에 대한 이해가 더욱 중요함

 

클라우드의 목적에 따른 구분

모든 것을 서비스화 Everythins as a Service

 

SaaS(Software as a Service)

클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우

(네트워크, 하드웨어, 운영체제, 플랫폼/데이터베이스, 애플리케이션)

 

PaaS(Platform as a Service)

클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우

(네트워크, 하드웨어, 운영체제, 플랫폼/데이터베이스)

 

IaaS(Infrastructure as a Service)

클라우드 제공자가 가상 컴퓨터까지 제공하는 경우

(네트워크, 하드웨어) (ex. AWS)

 

클라우드 서비스 업체의 장점

1. 신속한 인프라 구축

2. 유연한 인프라 관리

3. 예상치 못한 트래픽 폭주 대응

4. 손쉬운 글로벌 서비스

5. 강력한 보안과 장애 없는 서비스

6. 합리적인 요금제(종량제)

 

배포 플랫폼: aws, heroku, DigitalOcean, Microsoft Azure, Firebase

 

 

AWS(Amazon Web Service)

아마존이 자사의 노하우를 살려 제공하고 있는 '클라우드 컴퓨팅 서비스'(데이터 센터 유휴자원 대여부터 시작)

운영체제(OS), 웹 서버, DB 서버 등 필요한 소프트웨어까지 통째로 사용할 수 있는 편리한 서비스

다양한 서비스를 조합하여 모든 애플리케이션과 인프라를 구축할 수 있음

- 여러 사업자에게 각각 빌려야 했던 인프라를 일괄로 빌릴 수 있게됨

 

제공 서비스(165개 이상)

- 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 모바일, 개발자 도구, 관리 도구, IoT, 보안, 엔터프라이즈 애플리케이션 등

 

AWS 특징

1. 서비스를 조합하기 쉬움

AWS에서 제공하는 서비스만으로도 필요한 기능 대부분 구축 가능

AWS와 AWS 외부 시스템을 조합하여 구축하기 쉬움

2. 필요한 만큼 사용하고 부족해질때마다 추가할 수 있음

종량제, Ondemand ↔ 정액제

3. 네트워크 및 서버가 매우 큰 규모가 아니라면 네트워크나 서버 전문가가 아니더라도 사용 가능

4. 전세계 31개 리전 99개의 시설(가용 영역)에서 데이터 센터를 운영하고 있어 글로벌로 확장 시 확장하고자 하는 지역과 지리적으로 가까운 리전에서 서비스 시작이 가능함

5. 한국어 지원 및 원화 결제 가능, 보안 관련하여 법령, 규정, 프라이버시 기준을 준수하고 있는 안전한 서비스

 

 

AWS 서비스

1. EC2(Elastic Compute Cloud)

AWS에서 원격으로 제어할 수 있는 가상의 컴퓨터를 한 대 빌리는 것

사용한만큼 비용을 지불하고 필요에 따라 성능, 용량을 탄력적으로 조절할 수 있음

 

빌린 컴퓨터는 직접 사용하는 컴퓨터와 다르게 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에

컴퓨터를 조작하기 위해 네트워크(인터넷)를 통해서 컴퓨터를 제어해야 한다는 차이점이 있을 뿐 일반적인 컴퓨터와 다른 점이 없음

 

EC2를 통해서 할 수 있는 가장 기본적인 일은 웹 서버를 설치하여 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것

 

Instance = AWS에서 빌리는 컴퓨터 1대

인스턴스 생성 = AMI를 토대로 운영체제, CPU, RAM, 런타임 등이 구성된 컴퓨터를 빌리는 것

 

EC2 장점

1. 구성 시간이 짧음(PC 구매 배송 > 클릭 몇 번)

2. AMI를 통해 용도에 따라 다양한 운영체제 선택 가능 + CPU, RAM, 용량도 선택하여 구성 가능

3. 사용한만큼 비용 지불(종량제)

 

AMI(Amazon Machine Image)

인스턴스를 생성하는데 필요한 소프트웨어 구성이 기재된 템플릿(운영체제, 애플리케이션 서버, 애플리케이션)

많은 양의 Image가 AWS에 미리 준비되어 있음

- 운영체제(윈도우, 우분투, 리눅스 등)만 깔려있는 템플릿

- 특정 런타임(우분투+node.js, 윈도우+JVM 등)이 이미 설치되어 있는 템플릿 등

-> 사용 용도에 맞게 운영체제, 런타임 등이 구성된 Setting을 선택하거나 필요하다면 직접 구성할 수도 있음

 

 

2. RDS(Relational Database Service)

AWS에서 제공하는 관계형 데이터베이스 서비스

 

RDS 이점

1. 데이터베이스 유지 보수와 관련된 일을 RDS에서 자동 관리함

-> 초기 설정과 데이터베이스에 저장된 데이터 관리만 하면 됨

2. 다양한 데이터베이스 엔진 선택 가능(ORACLE, Amazon Aurora, SQLServer, MySQL, MariaDB, PostgreSQL)

 

RDS 사용 이점

EC2 인스턴스에 데이터베이스 엔진을 설치하지 않고 RDS를 사용하는 이유

EC2 인스턴스가 자동으로 관리하는 부분이 적어 사용자가 시간을 투자하여 관리해주어야 하는 부분이 많음

- 데이터베이스 엔진의 설치, 버전 관리

- 데이터 백업

- 가용성과 내구성이 확보되지 않음

(데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커짐)

- 데이터베이스 규모를 확장이 어려움

 

3. S3(Simple Storage Service)

AWS가 제공하는 클라우드 스토리지 서비스

파일 저장을 위한 파일 서버로 이용하거나

정적 웹 사이트 호스팅을 위해 사용

 

클라우드 스토리지

: 인터넷 공간에 데이터를 저장하는 저장소(네이버 MYBOX, OneDrive, Google Drive)

-> 뛰어난 접근성(특정 컴퓨터의 하드 디스크가 아니라서 웹 환경에서 언제 어디서나 접근 가능)

 

S3 이점

1. 높은 확장성

스토리지 규모를 자유롭게 확장/축소 가능

스토리지 용량을 무한 확장할 수 있음

 

2. 강한 내구성(99.999999999%)

저장된 파일 유실 가능성이 적어짐

 

3. 높은 가용성(연간 99.99%)

저장된 파일들을 정상적으로 사용할 수 있는 시간이 긺

(1년 동안 S3에 파일을 저장한 경우 8.76시간 동안만 장애가 발생함)

 

4. 다양한 스토리지 클래스 제공

사용자의 저장소 활용 목적에 따라 효율적인 스토리지 클래스를 선택할 수 있음

대표적인 클래스 Standard, Glacier

 

- Standard

범용적인 목적으로 사용하기 좋음, 가장 일반적으로 사용되는 스토리지 클래스.

데이터에 빠르게 접근 가능, 데이터 액세스 요청에 대한 처리 속도가 빠름.

보관 비용이 비싸기 때문에 데이터 장기 보관 목적으로는 효율적인 선택지가 아님

 

- Glacier

장기 보관 목적.

데이터 액세스 속도는 느리지만 데이터 보관 비용이 매우 저렴

 

- One Zone-IA

AZ를 하나만 쓰는 클래스. 저렴. 

잘 사용하지 않으나 자연재해로부터 안전한 지역에서 사용하는 경우가 있음(데이터 소실 위험 낮음)

 

이 외에도 Standard-IA, S3 Glacier Deep Archive 등 존재

 

5. 정적 웹 사이트 호스팅 가능(버킷)

정적 파일: 서버의 개입 없이 생성된 파일

<-> 동적 파일: 클라이언트가 서버에 요청을 보내 서버가 요청에 맞춰 그 자리에서 생성한 파일

웹 호스팅: 서버의 한 공간을 임대하여 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스

 

버킷(저장 공간)에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하여 정적 웹 사이트를 배포

활성화를 위해 공용 액세스 차단 해제, 버킷 정책을 모든 사용자로 설정 필요

 

버킷: 파일이 담기는 바구니(최상위 디렉토리)

- S3에 저장되는 모든 파일은 버킷 안에 저장됨(무한)

- 각각의 버킷의 이름은 버킷이 속해 있는(생성된) 리전에서 유일해야 함

- 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저 접근 권한을 설정할 수 있음

 

객체: 버킷에 담기는 파일. S3에서 저장소에 데이터 저장 시 키-값 쌍으로 데이터를 저장하기 때문에 객체라 부름

- 실제 저장되는 데이터인 파일과, 객체의 생성일, 크기, 유형 같은 객체에 대한 정보가 담긴 메타데이터로 구성(최대 크기 5TB)

- 모든 객체는 고유한 키를 가짐

- URL 주소를 통해 객체에 접근 가능

http://[버킷 이름].S3.amazonaws.com/[객체의 키]

 

 

AWS가 제공하는 서비스가 높은 가용성과 높은 내구성을 보장하는 방법

리전(Region): AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치

-> 리전에 따라 제공되는 서비스와 제공되지 않는 서비스가 있어, 제공하지 않는 AWS 서비스는 다른 리전을 선택해 사용해야 함

가용 영역(Availability Zone): 각 리전 안에 존재하는 데이터 센터(IDC)

 

가용 영역은 각각 개별적인 위치에 떨어져서 존재하기 때문에

한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도

다른 가용 영역에 백업해놓은 데이터를 활용해 서버가 문제없이 가동되게 함

 

 

배포 전략 Deployment Strategy

클라이언트를 정적 파일로 빌드하여 AWS S3을 이용해 배포

빌드: 불필요한 데이터를 없애고, 통합/압축하여 배포하기 최적화된 상태를 만드는 것

-> 데이터의 용량이 줄어들고 웹 사이트 로딩 속도가 빨라짐

 

일반적인 의미의 빌드: 소스 코드를 실행 가능한 번들로 변환하는 컴파일 과정

웹 앱에서의 빌드: 웹 앱을 HTML, CSS, JS 형태로 배포하는 경우에 배포 가능한 정적 파일 형태로 만들어주는 것

 

asset 자체가 정적인 경우 그대로 배포하면 됨

React의 경우 npm run build 명령을 사용해서 정적 파일 형태의 결과물을 만들어 낸 후 배포

사용하고 있는 환경에 따라 빌드 과정은 다를 수 있음

 

AWS에서 제공하는 CDN 서비스인 CloudFront를 통해서 각지의 데이터 센터에 데이터를 분산시켜서 저장해 두었다가 가까운 지역에서 데이터를 주는 방식으로 물리적 거리가 먼 사용자에게도 콘텐츠를 더 빨리 배포할 수 있음(더 빠르게 서비스 제공)

 

AWS EC2 서비스를 통해 서버 코드 구동

RDS 서비스를 이용하여 EC2를 통해 배포된 서버의 데이터를 저장하고 제공하는 데이터베이스 배포

 

S3, EC2를 이용해서 배포된 서비스는 IP 주소 혹은 AWS에서 제공하는 긴 도메인(서비스와 관련 없음)을 통해 접근할 수 있음

직관적인 도메인을 통해 서비스에 접속하려면 AWS의 서비스 중 Route53(DNS) 이용

 

 

 

 

 

개발 시 어디서 문제가 생기는지 알기 위해 기능 하나를 구현할 때마다 배포를 반복하는데 이 과정이 번거로움

-> 배포 자동화

 

 

 

 

23.02.02

코스 S4U9 Deploy AWS