AWS(아마존 웹 서비스)

클라우드 컴퓨팅 시스템

클라우드 서비스(Cloud Service)가 보편화 되기 이전까지, 웹을 배포하기 위해서는 별도의 자사(혹은 개인의) 서버용 컴퓨터가 필요했다.

이는 소형 서비스 등에서 불필요한 지출을 야기했다.

하지만, 가상화 기술(Virtualization)의 발전에 따라 클라우드 기술이 보편화되면서부터 각자가 만든 서비스를 타사의 데이터 센터의 메모리에 저장해놓고, 이를 사용대비 비용지출(온디멘드/Ondemand) 방식으로 변화하기 시작했다.

 

이러한 변화는 다음과 같은 장단점을 갖는다.

장점
1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절할 수 있다.
2. 고정비용(온프레미스/Onpremises)이 사용한 만큼의 비용(온디맨드/Ondemand)으로 바뀌었다.
3. 컴퓨터의 스냅샷을 이용해 다른 컴퓨터로 즉시 이주(migration)가 가능해졌다.

단점
1. 클라우드 서비스에 종속될 우려가 있다. (ex. 데이터센터 장애)
2. 서비스 지연 등의 우려가 있다.

 

대표적인 클라우드 서비스에는 SaaS, IaaS, PaaS 세 가지 유형이 있다.

SaaS(Software as a Service) : 클라우드 제공자와 클라우드 서비스를 제공하는 주체가 동일하다. ex. Google Drive

PaaS(Platform as a Service) : 클라우드 제공자가 데이터베이스 및 개발 플랫폼까지만 제공한다. ex. Google App Engine

IaaS(Infrastructure as a Service) : 클라우드 제공자는 네트워크 및 하드웨어만 제공하고 운영체제부터 어플리케이션까지는 개발사가 독자적으로 운용한다. ex. AWS

 

Iaas에 가까울수록 개발사가 클라우드를 이용해 개발할 수 있는 자유도가 증가하고, SaaS에 가까울수록 클라우드 플랫폼에 종속된다.

 

AWS EC2(Elastic Compute Cloud) : 원격으로 제어할 수 있는 컴퓨터를 빌리는 클라우딩 서비스

EC2는 일반 이용자가 google drive라는 구글의 컴퓨터 저장공간을 빌리는 것과 비슷한 개념이지만, AWS에서의 EC2는 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스 전반을 제공하되, 개발 및 운용 자체는 기업(혹은 개인)이 책임진다는 점에서 차이가 있다.

 

EC2 서비스의 장단점을 다음과 같다.

장점
1. 서비스를 구성하는데 소요되는 시간이 짧다. (컴퓨터를 사와서 서비스를 구축하는 것 vs 원격으로 컴퓨터에 접속해서 서비스를 구축하는 것)
2. 다양한 운영체제, CPU, RAM, 용량에 대한 선택이 가능하다. (상황에 따른 비용/효율 취사선택)

 

EC2와 관련된 용어 정리

Instance : 아마존에서 제공하는 원격 서버 ===> 서버 컴퓨터
AMI : 소프트웨어 구성이 기재된 템플릿 ===> 다양한 선택지를 갖고 조립식 컴퓨터를 구성하는 것처럼 활용

 

이와 같이 컴퓨터를 구성하여 공간을 확보했다면 데이터베이스를 구축해야 한다.

AWS에서는 RDS와 S3라는 데이터베이스 구축 서비스를 지원한다.

 

RDS : 관계형 데이터베이스 (Relation Database Service)

관계형 데이터베이스 : 데이터 저장형식 ===> 테이블(표와 비슷한 개념), 행과 열의 구성(스키마)에 따라 데이터를 검색/수정/삭제하기에 용이하다. ex. MySQL, Oracle, SQL Server 등
비관계형 데이터베이스 : 데이터 저장형식 ===> key-value / column-family와 같은 객체 형태로 저장하며 데이터의 구조가 유연(스키마 없음)하여 스케일링(데이터 베이스의 개선 및 재구조화)에 용이하다. ex. MondoDB, 카산드라 등
객체지향 데이터베이스 : 데이터 저장형식 ===> 객체지향 프로그래밍에서 사용되는 객체 자체를 데이터베이스에 저장하는 형식 ex.db4o, 등
객체 스토리지 : 데이터 저장형식 ===> 파일 / 이미지/ 비디오 등의 비정형 데이터를 저장하고 관리 ex. Google 클라우드 스토리지, AWS S3 등

 

EC2에 직접 관계형 데이터베이스를 설치하여 운용할 수 있다. 그럼에도 불구하고 RDS와 S3같은 데이터 베이스를 따로 설치하는 이유는 마치 JS로 모든 서비스를 구축할 수 있지만, 여러 프레임워크와 라이브러리를 갖고 서비스를 구축하는 것과 비슷한 맥락을 갖는다.

 

EC2 데이터 베이스를 구축할 경우 EC2에서만 제공하는 시설 구축/운영체제만을 갖고 데이터베이스를 관리해야 하지만, RDS의 경우 가용성/내구성, 데이터 백업, 데이터베이스의 설치 및 관리까지 엔진에서 관리한다. 

다만, EC2에 직접 관계형 데이터베이스를 구축하는 것과 달리 Oracle, Amazon Aurora, MySQL 등의 엔진을 이용하기에 별도의 비용이 소요된다.

 

S3 : 클라우드 스토리지 서비스 (Simpe Storage Service)

S3는 객체 스토리지 서비스(스토리지:물리적 저장공간 / 데이터:저장되는 정보)를 지원한다. S3는 다양한 스토리지 클래스를 선택할 수 있는데, 대표적으로 Standard 클래스와 Glacier 클래스가 있다.

 

S3는 기본적으로 무한한 저장공간을 제공하지만, 이는 물리적 공간의 무한한 확장이 아닌 AWS에서 제공하는 여러 파티션으로 분할된 데이터를 자체 기술을 통해 효율적으로 관리하여 유동적으로 데이터를 정리 및 여유 공간을 활용한 확장이 가능함을 의미한다.

 

즉, 개발자가 개발한 파일은 여러 바구니에 담겨서 다양한 칸막이를 통해 정리되며 좋은 기술력을 가진 클라우드 업체를 활용하여 이를 유동적이고 효율적으로 접근하고 저장할 수 있게 된다.

Standard 클래스 : 빠른 요청 및 응답 처리 / 장기보관시 보관비용 증가
Glacier 클래스 : 데이터 액세스 속도 느림 / 장기 보관시 비용이 매우 저렴
이외의 클래스 : Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등

 

S3를 이용하는 이유

관계형 데이터베이스가 있음에도 S3를 이용하는 이유는 정적 웹 사이트 호스팅이 가능하기 때문이다.

정적 파일 : 서버 등의 개입없이 생성되는 파일
동적 파일 : 서버 등의 외부 개입으로 새롭게 업데이트되는 파일

 

S3에서는 정적 파일(객체)을 버킷(최상위 디렉토리)에 담아 데이터 베이스로 저장한다.

이는 고유한 식별자인 URL(객체의 키)를 통해 접근할 수 있다.

 

이러한 차이를 가진 데이터베이스는 필요에 따라 RDS와 S3를 적절히 조합하여 사용할 수 있다.

여러 상황에서 두 데이터베이스는 S3에서 데이터베이스로 데이터를 로드, RDS에서 S3로 데이터를 업데이트, RDS에서 S3로 백업 등의 상호작용을 수행한다.

 

Deploy(배포)

이렇듯 여러 형식과 조합으로 개발된 서비스를 외부 IP에서 접근하여 이용할 수 있도록 하는 것이 배포이다.

기본적으로 사용자는 URL을 통해 EC2 공간이 아닌 S3 공간에 접근한다. 이를 위해 서비스는 동적 파일이 아닌 정적 파일로 제공되어야 한다. 이렇듯 동적 파일을 정적 파일로 변환하거나 정적 파일 자체를 제공할 수 있도록 파일을 재구조화하는 것을 빌드(build)라고 한다.

 

빌드의 과정은 다음과 같은 4단계로 나뉜다.

1. 전처리 : Webpack과 같은 라이브러리를 활용하여 여러 모듈을 하나의 파일로 결합한다 (모듈 의존성 해소).
2. 번들링 : 파일을 모아 하나의 번들에 묶는다. (브라우저에서 사용가능한 형태로 변형)
3. 압축 : 압축 알고리즘을 활용하여 파일의 크기를 줄이고 필요한 모듈을 package로 명시하여 필요에 따라 사용할 수 있도록 제공한다.
4. 생성 : 파일 전송 프로토콜(FTP, SCP 등)을 활용하여 배포할 수 있는 형태로 만든다.

 

이렇게 빌드된 파일을 EC2에 저장하고 S3 저장공간을 통해 빠르게 상호작용 할 수 있도록 처리한다. 그 뒤에 AWS에서 제공하는 Route53 서비스를 활용하여 간단한 URL로 저장공간에 접근할 수 있도록 만든다.

 

배포는 빌드와 같이 크게 4단계로 분류하여 살펴볼 수 있다.

1. 개발(development)단계 : 개발자의 로컬에서 개발하고 테스트하는 과정이다.
2. 취합 및 확인(Integration) 단계 : 각 개발자의 환경에서 개발된 부분을 취합하고 충돌을 개선하는 과정이다.
3. 스테이징(Staging) 단계 : 사용자가 실제 사용하는 환경과 가장 유사한 환경에서 테스트하는 과정이며, 이 때는 개발자 뿐만 아니라 마케팅/디자인 팀 등 여러 서비스와 관련된 인원들이 크로스체킹을 할 수 있다.
4. 서비스 제공(Production) 단계 : 실제 서비스 및 데이터를 제공하는 단계이다.

 

이 때, Production 단계에서 개발자가 작성한 코드에 따라 사용자가 실제 이용하는 환경과 차이가 있을 수 있다. 이에 따라 환경변수를 설정해두고, 상대경로를 사용하여 이러한 차이를 통제할 수 있다. 혹은 Docker와 같이 개발 환경을 통일시키는 방법론도 있다.