TIL 62: [배포] Amazon Web Service

 

 

Cloud와 On-premise

기본적으로 두 시스템은 모두 사이트, 애플리케이션, 게임 등의 서비스를 만들 때 필요한 자원들을 구성하는 방법에 대한 것입니다.

On-premise는 집을 짓는다고할 때 집을 지을 때 필요한 자재 구매부터 건물 도면, 시공, 건축, 인테리어까지 모든 과정을 혼자서 다 하는 방법입니다. 데이터센터에서 제공하는 서버의 자원과 공간 및 네트워크 환경이 여기에 해당됩니다.

Cloud도 집을 짓는다고 가정하면, 집을 만드는 과정에서 집 짓는 과정의 일부에서는 전문가의 도움을 받는 것입니다. 

결론적으로 On-premise와 Cloud의 차이점은 "서비스를 제공할 때 사용하는 IT 자원을 누가 관리하느냐"입니다. On-premise의 경우 서비스를 공급하는 서비스 제공자가 IT 자원 관리 주체이고, Cloud의 경우 서비스를 공부하는 제공자는 IT 자원을 사용할 뿐, 대부분의 IT자원은 클라우드 서비스 제공자가 관리합니다.

	Cloud	On-premise
비용	사용한 만큼 지불 + 초기비용 없음	초기비용 O + 유지보수 비용
확장성	유리 / 유연 / 편리	불리
구축에 걸리는 시간	짧다	오래 걸린다

 

 

Deploy

배포(Deploy)란 개발한 서비스를 사용자들이 이용가능하게 하는 일련의 과정입니다. 기본적으로 4단계를 거쳐서 배포하게됩니다.

Development 단계는 각자의 컴퓨터에서 코드를 작성하고 테스트 하는 과정입니다. 개발단계이기 때문에 실제 데이터를 이용하지 않고 더미데이터를 이용해서 테스트합니다. 

Intergration 단계에서는 각자의 컴퓨터에서 작성한 코드를 합치는 과정입니다. 내가 작성한 코드가 다른 코드를 침범해서 오류를 일으키지 않는지, 코드간에 conflict가 있지는 않는지 확인하는 과정을 거칩니다.

Staging 단계에서는 실제 출시단계인 Production 단계와 가장 유사한 환경에서 테스트를 진행합니다. 실제 데이터를 복사해서 문제가 있지 않은지 등 다양한 환경에서 테스트를 진행합니다. 또한 서비스와 관련된 부서 혹은 인원의 확인 과정을 거칩니다. 예를 들면 작성된 코드가 마케팅팀 혹은 디자인팀 예상했던 결과인지에 확인을 거치는 과정입니다.

Production 단계에서는 개발된 서비스를 출시하는 단계입니다. 사용자가 접속할 수 있는 Production 환경에서 코드를 구동하고 서비스를 제공합니다. 실제 데이터를 가지고 서비스가 운영되기 때문에 문제가 생기면 안되는 단계입니다.

 

개발한 서비스를 어떻게 배포하는 걸까요? 사용자들에게 Client를 어떻게 제공할지, 그리고 Client를 받은 사용자들이 서비스를 이용하기 위한 요청을 처리할 Server를 어떻게 제공할 것인지, Server의 데이터를 저장하고 제공할 Database는 어떻게 제공할 것인지 생각해 봐야 합니다. 먼저 Client를 배포하기 위해서는 빌드를 해야합니다. 여기서 빌드란 불필요한 데이터를 없애고, 여러 갈래로 퍼져있는 데이터들을 통합/압축하여 배포하기에 최적화된 상태를 만드는 것입니다. 이 덕분에 웹 사이트의 로딩 속도가 빨라집니다. 또 다른 정의로는 소스코드를 실행 가능한 번들로 변환하는 컴파일 과정을 의미합니다. 

지구 반대편에 있는 사용자들에게 빠르게 서비스를 제공하기 위해 CDN 서비스를 사요할 수 있습니다. CloudFront를 통해서 각지의 데이터센터에 데이터를 분산시켜서 저장해 뒀다가 가까운 지역에서 데이터를 주는 방식으로 사용자에게 더 빠르게 서비스를 제공할 수 있습니다.

AWS EC2 서비스를 통해 손쉽게 서버를 구성하고 서비스를 제공할 수 있습니다.

또한 RDS 서비스를 이용하여 EC2를 통해 배포된 Server Application의 데이터를 저장, 제공하는 데이터베이스를 배포할 수 있습니다.

 

 

 

EC2 (Elastic Compute Cloud)

인스턴스

EC2란 AWS에서 제공하는 클라우드 컴퓨팅 서비스입니다. 클라우드 컴퓨팅은 인터넷(클라우드)를 통해 서버, 스토리지 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스입니다. EC2의 장점은 구성하는데 필요한 시간이 짧다는 것입니다. 또한 AMI(Amazon Machine Image)를 통해서 필요한 용도에 따라 다양한 운영체제(템플릿) 선택이 가능하다는 것입니다. 또한 CPU, RAM, 용량도 쉽게 구성할 수 있습니다. 이미 세팅되엉 있는 AMI 이외에도 필요에 따라 직접 AMI를 구성할 수도 있습니다. 이렇게 보면 EC2를 통해 컴퓨터 한 대를 빌릴 수 있는 것입니다. 따라서 AWS에서 컴퓨터를 빌리는 것을 인스턴스(1대의 컴퓨터)를 생성한다고 합니다.

 

SSH 프로토콜

인스턴스를 생성할 때 .pem을 다운받아 SSH 프로토콜을 통해 원격접속을 합니다. 여기서 SSH 프로토콜이란 서로 다른 PC가 인터넷과 같은 Public Network를 통해 통신을 하 떄 보안상 안전하게 통신하기 위한 통신 규약입니다. 주고 받는 데이터를 암호화해서 해당 키 페어를 가지지 않은 사람은 통신되는 데이터를 알아볼 수 없기 때문에 보안상 안전한 통신 방법입니다. 이렇게 접속을 하면 원격으로 인스턴스를 제어할 수 있습니다. 만약 다운로드했던 키 페어 파일(.pem)의 권한이 누구나 접근할 수 있는 걸로 되어있으면 인스턴스는 연결을 거부합니다. 따라서 이 때 chmod 400 [다운로드한 키 페어파일의 경로] 명령어를 입력하여 권한을 수정합니다. 4(소유자) 0(그룹) 0 (전체)

 

권한을 변경해준 후 SSH를 통해 연결하기 위해서는 아래와 같은 명령어를 작성해줍니다.

ssh -i "test" ubuntu @ec2-15-164-251-231.ap-northeast-2.compute.amaxonaws.com

이 뜻은 ssh 프로토콜을 통해 test라는 이름의 Key를 가지고 ubuntu라는 사용자 이름으로 ec2-15-164-251-231.ap-northeast-2.compute.amaxonaws.com 주소의 가상 PC에 접속하겠다는 뜻입니다.

 

 

보안그룹

보안그룹이란 인스턴스로 들어가고 인스턴스에서 나가는 트래픽에 대한 가상 방화벽입니다. 인스턴스로 들어가는 트래픽은 인바운드, 인스턴스에서 나가는 트래픽을 아웃바운드라고 합니다. 인바운드 규칙에 허용되지 않은 규칙은 인스턴스로 접근하지 못하도록 필터링됩니다.

 

 

PM2 (Process Manage)

PM2는 프로세스를 전문적으로 관리해주는 프로그램입니다. 여기서 프로세스는 컴퓨터 프로그램이 실행될 때 프로그램 실행에 필요한 내용이 메모리에 적재된 것을 말합니다. 즉, 실행 중인 프로그램입니다. ssh를 통해 EC2에 접속하고 터미널을 종료하면 로컬에 띄워져있던 ssh 프로세스가 강제 종료됩니다. ssh 프로세스가 종료되면 EC2 상의 프로세스 그리고 EC2 상의 node 프로세스도 종료됩니다. ssh 접속 여부와 상관없이 node 프로세스가 늘 실행되도록 해주는 것이 PM2입니다. pm2를 설치한 후 아래와 같은 명령어를 통해 터미널을 종료하더라고 node.js 애플리케이션이 프로세스로 실행되거나 중지되도록 할 수 있습니다. 

• pm2 stop: 프로세스 중지
• pm2 restart: 프로세스 재시작
• pm2 ls: 프로세스 목록 보기
• pm2 log: 프로세스 로그 보기

PM2에 관리자 권한을 부여하기 위해서는 'authbind --deep' 명령어를 앞에 추가해야합니다.

 

RDS (Relational Database Service)

RDS는 AWS에서 제공하는 관계형 데이터베이스 서비스입니다. 물론 EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해서 데이터를 관리할 수 있습니다. 하지만 이 경우 사용자가 일일이 시간을 투자해서 데이터베이스 엔진 설치 및 버전관리, 데이터 백업 등을 해야합니다. 이에 더해 가용성과 내구성이 확보되지 않기에 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커집니다.

RDS를 사용할 경우 데이터베이스 유지보수와 관련된 일들은 RDS에서 전적으로 자동 관리하기 때문에, 사용자는 초기 설정만 해놓으면 큰 편의성을 느낄 수 있습니다. 

 

 

S3 (Simple Storage Service)

S3는 AWS에서 제공하는 클라우드 스토리지 서비스입니다. 여기서 클라우드 스토리지란 인터넷 공간에 저장하는 저장소입니다. 구글의 Google Drive, 네이버의 MYBOX가 여기에 해당됩니다. S3는 뛰어난 접근성을 가지고 있으며, 데이터를 무한히 저장가능한 확장성을 지니고 있습니다. 또한 내구성이 높아 파일을 유실할 가능성이 매우 적습니다. 가용성도 높습니다. 즉, 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 깁니다. S3에는 다양한 스토리지 클래스를 제공함에 따라 효율적으로 데이터를 관리할 수 있습니다. 대표적인 클래스로는 Standard 클래스와 Glacier 클래스가 있습니다. Standard 클래스는 범용적인 목적으로 사용하기 좋습니다. 접근 속도가 빠르지만  오래 보관하는 목적으로는 효율적인 선택지가 아닙니다. Glacier 클래스는 장기적인 보관 목적으로 사용됩니다.

 

S3를 사용하면 좋은 점은 정적 웹사이트 호스팅이 가능합니다. 여기서 정적 사이트라 서버의 개입없이 생성된 사이트를 말합니다. 그리고 웹 호스팅이랑 서버의 한 공간을 빌려 원하는 서비스를 배포하는 것을 말합니다. 여기서 서버의 한 공간은 버킷이라고 불립니다. 버킷이란 S3에 저장되는 파일들이 담기는 바구니입니다. 버킷에는 무한한 양의 파일을 저장할 수 있으며, 각각의 버킷의 이름은 리전에서 유일해야 합니다. 또한 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있습니다. 버킷에 담기는 파일을 객체라고 부릅니다. 객체라고 부르는 이유는 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문입니다. S3에 저장되는 객체는 파일과 메타데이터로 구성됩니다. 메타데이터는 객체의 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터입니다.

 

 

Region

EC2, RDS, S3 서비스는 공통적으로 높은 가용성과 내구성을 보장합니다. 이렇게 보장할 수 있는 이유는 AWS는 다양한 지역에 Region(리전)이 있기 때문입니다. 여기서 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻합니다. 각 리전 안에 존재하는 데이터 센터는 가용영역이라고 합니다. 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 합니다. 이런 가동 방식 덕분에 높은 가용성과 내구성을 보장합니다.