AWS의 핵심 개념들 및 서비스들

Cloud Computing

기존 서버의 방식에서는 한 공간에 컴퓨터를 설치하여 서버를 운용했다.
그리고 서버 수용 능력이 한계에 도달하면 컴퓨터를 추가로 설치하거나 각 컴퓨터의 성능을 높이기도 했다.
그러나 이와 같은 서버 관리 방법에는 다음과 같은 문제점들이 있다.

1. 주기적인 관리 필요 → 인력 및 비용 투자 증가
2. 공간의 한계

서버 증설 작업이 까다롭다 보니, 일부 거대 기업은 데이터 센터라는 거대한 건물을 세우기 시작했다.
그리고 이때부터 데이터 센터의 유휴 자원을 대여하는 서비스가 등장하기 시작했다.
(이러한 환경을 Off-premise라고 부른다.)
즉 서버의 자원과 공간 및 네트워크 환경을 빌려서 사용하는 Cloud Computing이 시작된 것이다.

 

장점

데이터 센터와도 비슷한 역할을 하지만, 물리적 컴퓨터가 아닌 가상 컴퓨터를 대여한다는 점이 다르다.
이는 Virtualization 기술의 발전으로부터 비롯되었다.
가상화 기술을 사용하는 클라우드 서비스는 On-premise software와 다르게 다음과 같은 장점을 가져갈 수 있다.

1. 필요할 때마다 컴퓨팅 능력을 유연하게 조절 가능
2. On-premise는 고정적인 비용 / Off-Premise는 사용한 만큼만 지불
3. 컴퓨터의 스냅샷을 이용해서 다른 컴퓨터로 즉시 migration 가능

 

단점

간혹 뉴스 등을 통해서 AWS의 장애로 특정 서비스의 서버가 지연되었다는 기사를 봤을 것이다.
이처럼 운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 사용자가 배포하고 관리하는 환경에도 영향을 미친다.
운영 환경이 특정 클라우드 사업자(vendor)에게 종속된다는 것은, 백엔드 구성 자체가 특정 회사의 기술로만 구성해야 하는 경우가 발생할 수도 있다는 뜻이다.
따라서 AWS와 같은 대표적인 클라우드 사업자가 제공하는 기술을 익히는 것도 중요하지만, 인프라 자체에 대한 이해가 더더욱 중요하다.

 

클라우드 서비스의 형태

SaaS (Software as a Service)

클라우드 제공자가 당장 사용 가능한 소프트웨어를 제공하는 경우 대부분 SaaS에 해당

 

PaaS (Platform as a Service)

클라우드 제공자가 데이터베이스, 개발 플랫폼까지 제공하는 경우 대부분 PaaS에 해당

 

IaaS (Infrastructure as a Service)

클라우드 제공자가 가상 컴퓨터까지 제공하는 경우 대부분 IaaS에 해당

 

Deploy

배포는 개발한 서비스를 사용자들이 이용 가능하도록 하는 일련의 과정이다.
개별적으로 추가적인 과정이 있을 수도 있지만, 기본적으로는 다음의 4단계를 거쳐서 서비스를 배포한다.

 

1. Development

• Local 환경에서 개발 및 테스트
• Sample Data 사용
• 변경 사항이 있어도 문제가 없음
• 모든 구성원이 각자의 환경에서 개발

 

2. Integration

• 각자의 환경에서 개발된 부분들을 취합
• 코드 간 Conflict가 없는지 검증

 

3. Staging

• Production 단계와 가장 유사한 환경에서 테스트 진행
• 복제된 실제 데이터를 사용하여 테스트
• 모든 관계자들에게 검증받는 단계

 

4. Production

• 개발 환경과는 구분된 환경
• 실제 데이터 사용
• 실제로 서비스가 제공되는 단계

 

환경 설정을 코드와 분리하기

Development 환경과 Production 환경은 서로 다를 수 있다.
여러 명이 함께 프로젝트를 진행한다면 node 버전이나 인증 정보, 데이터베이스 엔드포인트 및 비밀번호가 다 제각각이라서 통합하기 어려울 것이다.
따라서 배포할 때는 환경의 차이를 이해하여, 환경 설정을 코드와 분리하는 것이 중요하다.

 

또한 다음과 같은 원칙을 지켜주면 더 좋을 것이다.

• 절대 경로 대신 상대 경로 사용
• 환경에 따라 포트를 분기할 수 있도록 환경 변수 설정
• Docker와 같은 개발 환경 자체를 통일시키는 Solution을 이용

 

AWS - EC2(Elastic Compute Cloud)

EC2란, AWS에서 제공하는 클라우드 컴퓨팅 서비스이며, 쉽게 말해서 AWS에서 원격으로 제어할 수 있는 가상 컴퓨터 한 대를 빌리는 것이다.
사용한 만큼 비용을 지불하기 때문에 탄력적이라는 의미의 Elastic이라는 단어가 붙어있다.
Elastic은 비용적인 부분 뿐만 아니라 필요에 따라 성능, 용량을 자유롭게 조절할 수 있다는 의미도 가진다.

 

EC2의 장점

• 구성하는 데 필요한 시간이 짧음
• 다양한 운영체제 및 CPU, RAM, 용량 선택 가능

 

Instance

EC2는 컴퓨터를 한 대 빌리는 것이므로 컴퓨터로 할 수 있는 모든 일을 할 수 있다.
또한 빌린 컴퓨터는 아마존이 전 세계에 만들어 놓은 데이터 센터(인프라)에 만들어져 있기 때문에 컴퓨터를 조작하기 위해 네트워크를 통해 제어해야 한다는 차별점이 있을 뿐, 일반적인 컴퓨터와 다른 점이 없다.
EC2를 통해 할 수 있는 가장 기본적인 일은 웹 서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것이다.
Instance는 1대의 컴퓨터를 의미하는 단위이다.
AWS에서 컴퓨터를 빌리는 것을 Instance를 생성한다고 말한다.

 

AMI (Amazone Machine Image)

AMI는 소프트웨어 구성이 기재된 템플릿이다.
단순히 운영체제만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어 있는 템플릿이 제공되는 경우도 있다.
(우분투 + node.js / Windows + JVM 등)
Instance 또한 선택한 AMI를 토대로 구성되며, 상당히 많은 AMI 세팅이 준비되어 있기 때문에 손쉽게 Instance의 운영체제를 구성할 수 있다.
그리고 준비되어 있는 AMI 이외에도 직접 AMI를 구성할 수도 있다.

 

RDS (Relational Database Service)

RDS는 AWS에서 제공하는 관계형 데이터베이스 서비스이다.
그런데 EC2 Instance에 RD 엔진을 설치한다면 굳이 AWS의 RDS를 사용할 필요가 없을텐데 왜 굳이 관계형 데이터베이스에 대한 서비스를 따로 분리했을까?
이러한 의문점을 해결하기 위해서 '개인 소유 차량'과 '렌터카에서 대여한 차량'을 연상해보면 편하다.

 

EC2 Instance에 직접 데이터베이스를 설치하고 관리하는 것은 개인 소유 차량을 이용하는 것과 비슷하다.
이렇게 되면 유지 보수 및 비용 처리를 온전히 사용자가 부담한다.
데이터베이스를 관리하는 시간과 노력을 더 들여야만 한다는 뜻이다.
또한 EC2 Instance에 직접 데이터베이스를 설치하려면 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업까지 모두 사용자가 부담해야 하는 작업이다.
게다가 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못하게 될 확률이 크며, 추후에 데이터베이스의 규모를 확장하기 어렵다.

 

반면에, AWS의 RDS를 이용하면 렌터카 회사에서 차량을 대여하듯이, 대여 차량에 관련하여 들어가게 될 시간과 노력을 렌터카 회사에서 대신 처리해준다.
RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리해주며, 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기 때문에 편의성을 가져갈 수 있다.
또한 RDS는 다양한 데이터베이스 엔진 선택지를 제공한다.

S3 (Simple Storage Service)

Cloud Storage

S3를 이해하기 위해서, Cloud Storage에 대한 개념을 짚고 갈 필요가 있다.
Cloud Storage는 인터넷 공간에 데이터를 저장하는 저장소이다.
우리는 알게 모르게 Google의 Google Drive나, Naver의 MYBOX, Microsoft의 Onedrive 같은 서비스를 사용했을 것이다.
이들은 Cloud Storage의 좋은 예시들이다.
Cloud Storage Service는 뛰어난 접근성을 가진다.
웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있다.

 

S3의 장점

• 확장성 : 데이터를 무한히 저장할 수 있음 / 이에 대해 사용한 만큼만 비용 지불
• 내구성 : 99.999999999%의 내구성 보장
• 가용성 : 99.99%의 가용성 보장 / 저장된 파일을 정상적으로 사용할 수 있는 기간이 길어짐
• 다양한 Storage Class 제공
  • S3 Standard : 일반적으로 가장 많이 사용되는 Storage Class / 데이터에 빠르게 접근 가능
  • S3 Glacier : 데이터 장기 보관 목적 / 액세스 속도는 느리지만 비용이 저렴
• 정적 웹 사이트 호스팅 가능 : 버킷을 제공하여 정적 파일을 담게 하고, 버킷을 통해 웹 사이트 배포

 

※ 버킷

• 파일을 담는 바구니 (최상위 디렉토리)
• 무한히 많은 파일 저장 가능
• 버킷의 이름은 각 리전(버킷이 생성된 지역)에서 고유해야 함
• 버킷 정책을 생성하여 다른 유저의 액세스 권한 부여 가능
• Key-Value 형태로 데이터를 저장하기 때문에 버킷에 담기는 파일을 '객체'라 부름
• 객체는 파일과 메타데이터로 구성되며 모든 객체는 고유한 키를 가짐
  • 파일의 Key는 각각의 객체를 고유하게 만드는 식별자 역할 / 이를 통해 원하는 객체 검색 가능
  • 파일의 Value는 실제데이터 / 데이터의 최대 크기는 5TB
  • 메타데이터는 객체의 생성일, 크기, 유형과 같은 정보가 담긴 데이터
• 모든 객체는 고유 URL 주소를 가져서, 이를 통해 객체에 접근
  • URL 주소 형식 : http://[버킷의 이름].S3.amazonaws.com/[객체의 키]

 

배포 전략

Client

웹 서비스를 배포하려면 사용자들에게 Client를 어떻게 제공할지, 그리고 Client를 받은 사용자들이 서비스를 이용하기 위한 요청을 처리할 Server를 어떻게 제공할 것인지, Server의 데이터를 제공할 Database는 어떻게 제공할 것인지 생각해봐야 한다.
우선 Client는, S3 서비스를 활용해서 제공해줄 수 있다.
Client를 위해서 EC2 Instance를 사용할 필요는 없다.
S3가 Client를 정적 파일로 Build해서 제공하기 때문이다.

 

Build

• 불필요한 데이터를 없애고, 통합 및 압축한 뒤 배포를 위한 최적화 상태를 만드는 것
• 데이터의 용량을 줄여주고 웹 사이트 로딩 속도를 빠르게 해줌

웹 개발을 진행할 때, 일반적으로 사용하는 Build의 의미는 살짝 다르다.

• 소스 코드를 실행 가능한 번들로 변환하는 컴파일 과정
• 웹 앱을 배포 가능한 static file들로 만드는 작업
• asset 자체가 정적인 경우, 그대로 배포 가능
  • React의 경우 npm run build와 같은 명령어를 사용해서 간단하게 Build

 

CloudFront (AWS의 CDN 서비스)

CloudFront를 이용하면 세계 각지의 데이터 센터에 데이터를 분산시켜서 저장해뒀다가, 요청이 있을 경우 가까운 데이터 센터에서 데이터를 주는 방식으로 사용자에게 더욱 빠르게 서비스를 제공할 수 있다.

 

Server

Server는 EC2 서비스를 활용해서 손쉽게 구성하고 제공할 수 있다.
또한 RDS 서비스를 활용하여 EC2를 통해 배포된 Server Application의 데이터를 저장하고 제공하는 데이터베이스를 배포할 수 있다.

 

DNS

S3, EC2를 이용해서 배포된 서비스는 IP주소 혹은 www.your-app.ap-northeast-2.compute.amazonaws.com과 같은 긴 도메인 주소를 통해 접근하게 된다.
이를 해결하기 위해서는 AWS에서 제공하는 Route 53 서비스를 이용해서 직관적인 도메인 주소를 설정해야 한다.

 

AWS의 많은 서비스들을 이용하는 이유

사실 EC2에 서비스를 통째로 모아둘 수 있다.
그럼에도 불구하고 S3와 RDS 등을 이용하는 이유는 EC2에 장애가 발생했을 때에도 다른 서비스들은 정상적으로 작동하게 하기 위해서이다.
하지만 최근 RDS 비용 이슈가 있어서 EC2에 RDS는 탑재하는 경향이 있다.