서버의 자원과 공간, 및 네트워크 환경 제공
필요할 때마다 컴퓨팅 능력을 유연하게 조절
사용한 만큼의 요금만 지급
다른 컴퓨터로 즉시 이주가 가능
이처럼 운영 환경 자체가 클라우드 제공자에게 종속되어 버리므로, 클라우드 서비스에 문제가 생기면 내가 배포하고 관리하는 환경에도 영향을 미친다.
운영환경이 특정 클라우드 사업자(vendor)에게 종속된다는 얘기는, 백엔드 구성 자체가 특정 회사의 기술로만 구성 해야만 하는 경우가 발생할 수도 있다.
배포에서는, 환경의 차이를 이해하고 환경 설정을 코드와 분리하는 것이 중요하다.
작성한 코드가 다른 환경에서 정상 작동할 수 있게 하려면, 설정을 환경 변수 (envvars나 env라고도 불림)에 저장해야 한다.
작성한 코드가 다른 환경에서 정상 동작할 수 있게 하려면?
EC2는 아마존 웹 서비스에서 제공하는 클라우드 컴퓨팅 서비스이다.
클라우드 컴퓨팅은 인터넷(클라우드)을 통해 서버, 스토리지, 데이터베이스 등의 컴퓨팅 서비스를 제공하는 서비스이다.
정리하면 아마존에서 가상의 컴퓨터를 한 대 빌리는 것과 같다.
아마존 EC2를 통해서 할 수 있는 가장 기본적인 일은
웹서버를 설치하고 웹 서버를 통해서 사용자가 웹 브라우저를 통해 요청하는 서비스를 제공하는 것이 가장 기본적인 사용방법이다.
AWS에서 컴퓨터를 빌리는 것을 인스턴스를 생성한다
인스턴트를 생성하는데 필요한 소프트웨어 구성(운영체제, 애플리케이션 서버, 애플리케이션)이 포함된 템플릿
이미지 종류로는 단순히 운영체제(윈도우, 우분투 리눅스 등)만 깔려있는 템플릿을 선택할 수도 있고, 아예 특정 런타임이 설치되어있는 템플릿이 제공되는 경우도 있다. (우분투 + node.js, 윈도우 + JVM 등)
AWS EC2 인스턴스를 생성한다는 것은 AMI를 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것이다.
Relational Database Service의 약자로 AWS에서 제공하는 관계형 데이터베이스 서비스이다.
EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 한다.
게다가 가용성과 내구성이 확보되지 않기에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵다.
그에 반해 RDS를 이용하면 데이터베이스 유지보수와 관련된 일들을 RDS에서 전적으로 자동 관리합니다. 사용자가 해야할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있다.
기타 RDS 이용 시 얻을 수 있는 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점이다.
AWS에서 제공하는 클라우드 스토리지 서비스
가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어진다.
버킷이란 S3에 파일을 저장하는 최상위 디렉터리라고 설명할 수 있다.
S3에서 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한한 양의 파일을 저장할 수 있다. 그리고 각각의 버킷은 이름을 가지고 있는데, 버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다.
또한 버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.
S3에서 버킷에 담기는 파일을 객체라고 부른다. S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문이다.
파일의 키는 각각의 객체를 고유하게 만들어주는 식별자 역할을 한다. 파일의 키를 이용하여 원하는 객체를 검색할 수 있다.
AWS 메뉴에서 EC2 서비스를 검색하고 접속하여 인스턴스 시작 버튼을 클릭하여 인스턴스 생성을 시작
원격접속을 위해서 필요한 Key를 생성하고 다운로드하는 과정이다.
새 키 페어 생성 메뉴를 확인한 후 키 페어의 이름을 정한 뒤 키 페어를 다운로드하면 인스턴스 시작 버튼이 활성화된다.
EC2 프라이빗 키 파일(.pem 파일)경로
=> ~/Downloads/AWS_Deploy_pratice.pem
인스턴스 생성 마지막 단계에서 다운로드 한 파일은 SSH 통신을 위한 키 페어 중 프라이빗 키가 기록된 파일입니다. .pem 확장자를 가지고 있다.
해당 키 페어 파일은 EC2 인스턴스에 연결을 할때 사용하는 암호가 담긴 파일이다. 따라서 pem파일은 관리에 유의해야 한다.
생성한 인스턴스에 원격접속하여 원격으로 인스턴스를 제어할 수 있다.인스턴스에 원격접속을 하기 위해서 필요한 것이 인스턴스를 생성할 때 다운로드한 키 페어 파일(.pem)이다.
로컬 터미널에서 SSH프로토콜을 이용해서 인스턴스와 연결이 가능하다. 하지만 먼저 다운로드했던 키 페어 파일(.pem)의 권한을 수정해 줘야 한다.
pem 파일에 누구나 접근할 수 있는 권한이 부여되어 있다면 인스턴스는 연결을 거부한다.
키 페어 파일(.pem)의 권한을 수정하지 않은 경우 권한이 너무 open되어 있다는 경고 메시지와 함께 접속이 거절된다.
때문에 위와 같이 chmod 400 [다운로드한 키 페어파일(.pem)의 경로]
명령어를 입력하여 키 페어 파일(.pem)의 권한을 수정해야 한다.
ssh -i ~/Downloads/AWS_Deploy.pem ubuntu@ec2-13-125-109-202.ap-northeast-2.compute.amazonaws.com
접속 성공!
이제 명령어를 통해 AWS에서 빌린 가상PC를 사용할 수 있다.
EC2 인스턴스에 처음 접속하면 서버를 구동하는 데 필요한 개발 환경을 구축하는 것부터 시작해야 한다.
1. sudo apt update
2. nvm 설치 Installing and Updating
3. nvm --version
확인
4. nvm install node
설치
5. sudo apt install npm
: node.js의 설치가 끝나면 npm 명령어가 정상적으로 입력되지 않는 상황을 방지
git clone 명령어를 통해 EC2 인스턴스에 프로젝트 코드를 클론
관리자 권한으로 서버를 시작하기 위해서는 sudo npm start 명령어를 입력해야 한다.
퍼블릭 IPv4 주소와 퍼블릭 IPv4 DNS는 형태만 다를 뿐 같은 주소
보안 그룹은 AWS에서 임대한 인스턴스의 가상 방화벽이다.
인바운드와 아웃바운드에 대한 규칙을 설정할 수 있다.
인바운드
인바운드 규칙은 EC2인스턴스로 들어오는 트래픽에 대한 규칙
인바운드 규칙에 허용되지 않은 규칙은 인스턴스로 접근하지 못하도록 필터링 된다.
EC2 인스턴스를 생성하면 기본적으로 SSH 접속을 위한 SSH 규칙만 생성되어 있다.
아웃바운드
아웃바운드 규칙은 EC2 인스턴스에서 나가는 트래픽에 대한 규칙이다.
EC2 인스턴스를 생성하면 기본적으로 나가는 모든 트래픽을 허용한다.
node 프로세스가 ssh 접속 여부와는 상관없이 늘 실행되게 만들 수는 없을까?
PM2는 node.js로 실행되는 프로그램(프로세스)를 관리해주며, 백그라운드에서 실행되게 만들 수 있다.