6) AWS S3를 이용한 웹 호스팅

Index

  1. 에밀리 시간표 웹 페이지
  2. AWS S3란?
  3. 도메인 등록
  4. S3 버킷 생성
  5. 웹 사이트 데이터 업로드
  6. 버킷 정책(Permissions) 설정
  7. 버킷 정적 웹 사이트 호스팅 기능 활성화
  8. 버킷 Record Set 설정

에밀리 시간표 웹 페이지

학생들에게 필요한 기능이 어떤게 있을까 생각하다 에밀리에 시간표 기능을 추가하게 되었습니다. 학생들이 수강하고 있는 수업 데이터를 얻을 수 있으면 좋겠지만 학교 DB에 접근할 수 있는 권한이 없기 때문에 학생들이 직접 에밀리를 통해 시간표를 등록하도록 만들어야 했습니다.

학교 홈페이지에서 제공하는 수업 목록(엑셀 파일)를 활용(파싱)하여 시간표 데이터를 만들고, 이를 학생들이 쉽게 등록 및 수정할 수 있도록 웹 페이지를 만들었습니다 (아무래도 전공도 다양하고 수업의 수도 많다보니 단순히 버튼 및 텍스트로 상호작용하여 시간표를 등록하는것은 불편하다고 판단해 시간이 좀 더 걸리더라도 웹 페이지를 만들기로 결정했었습니다.)

학생들이 많이 사용하는 여러 시간표 앱 및 웹 서비스를 참고해서 다음과 같은 시간표 등록 및 수정 페이지를 만들었습니다.

에밀리 시간표 등록 및 수정 페이지

참고로 에밀리 시간표 등록 및 수정 페이지는 React(Starter-Kit)를 이용해서 만들었습니다. 아무래도 회사에서 React Native를 사용해서 앱을 개발하다보니 React를 사용해 웹 개발을 함에 있어서도 도움이 많이 되었습니다.


AWS S3란?

사용자들이 에밀리 시간표 페이지를 사용할 수 있도록 하기 위해서는 웹 페이지를 호스팅해야합니다. 간단히 호스팅할 수 있는 여러 방법들이 있지만, AWS 공부도 할겸 S3를 이용해 호스팅해보기로 생각했습니다.

먼저 S3에 대해 간단하게 알아보겠습니다. S3(Simple Storage Service)는 파일을 저장하기 위한 Storage입니다. 일반적인 파일시스템의 개념과는 약간 다르며, 파일 이름을 대표하는 key와 파일 자체로 구분되는 Object Storage입니다.

S3는 정적 웹사이트 호스팅 기능을 사용하는 S3 버킷을 Route 53을 통해 도메인과 연결해 사용할 수 있습니다. 여기서 동적 웹 사이트 PHP, JSP 등 서버 측 처리에 의존하는 사이트는 S3를 이용해 호스팅할 수 없습니다. 오직 개별 웹 페이지에서 정적 컨텐츠를 포함하며, 클라이언트 측 스크립트를 포함하고 있는 정적 웹 사이트만이 호스팅 가능합니다. (React의 경우 webpack을 통해 번들링된 파일을 호스팅하면 됩니다.)


도메인 등록

이미 등록된 도메인이 있다면 이 단계를 생략하면 됩니다. 그러나 inuemily.com과 같이 등록된 도메인 이름이 없는 경우, 원하는 도메인 이름을 만들어 등록해야 합니다.

도메인이 없으시다면 AWS의 Route53 - Registered domains를 통해 도메인을 생성하고, AWS가 아닌 다른 서비스로부터 도메인을 사용중 이라면 기존 도메인 DNS 서비스 역할을 하는 AWS Route53으로 마이그레이션을 해야 S3를 이용한 정적 웹사이트 호스팅이 가능합니다. 마이그레이션 관련해서는 AWS 문서를 참고하면 좋을것 같습니다.

저는 다음과 같이 inuemily.com 이라는 도메인을 갖고 있습니다.

에밀리 도메인


S3 버킷 생성

inuemily.com과 같은 루트 도메인, www.inuemily.com과 같은 하위 도메인 양쪽의 요청을 모두 지원하려면 두 개의 버킷을 생성해야합니다. 하나의 버킷에 컨텐츠를 포함하고 다른 버킷은 컨텐츠를 포함하는 버킷에 redirection 하도록 버킷을 구성할 것입니다.

먼저 버킷 이름을 호스팅할 웹 사이트 이름과 일치하게 생성합니다. 저는 inuemily.comwww.inuemily.com 이름으로 버킷을 생성했습니다.

버킷 생성


웹 사이트 데이터 업로드

2개의 버킷을 모두 생상하였다면 루트 도메인 버킷(inuemily.com)에 컨텐츠를 업로드합니다. 두 번째 버킷(www.inuemily.com)은 추후에 이 루트 도메인 버킷으로 redirection 하도록 설정할 것입니다.

S3 버킷에 파일을 업로드하는 방법으로는 1) 드래그 앤 드롭, 2) AWS CLI 사용 과 같이 2가지 방법이 있습니다. 저는 드래그 앤 드롭을 이용해서 파일을 업로드 하였습니다. (webpack으로 번들링되어 나온 public 폴더의 파일들을 업로드 하였습니다.)

루트 버킷에 파일 업로드


버킷 정책(Permissions) 설정

버킷을 생성하고 파일을 업로드했지만 모든 사용자가 버킷에 업로드한 모든 컨텐츠에 접근할 수 있도록 버킷 정책(Permissions)을 설정해야 합니다.

다음의 코드를 복사하여 아래 사진과 같이 버킷 정책을 설정합니다. (10번째 라인의 inuemily.com을 자신의 버킷 이름으로 변경해야 합니다.) 두 번째 버킷에는 파일을 업로드하지 않기 때문에 따로 정책을 설정해주지 않아도 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
{
"Version": "2012-10-17",
"Id": "Policy1484315866648",
"Statement": [
{
"Sid": "Stmt1484315864175",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::inuemily.com/*"
}
]
}

루트 버킷 정책 설정


버킷 정적 웹 사이트 호스팅 기능 활성화

파일 업로드와 정책 설정이 끝난 버킷을 정적 웹 사이트 호스팅으로 사용할 수 있도록 기능을 활성화 해야합니다.

루트 버킷 정적 웹 호스팅 기능 활성화

루트 버킷을 정적 웹 호스팅에 사용하기 때문에 User this bucket to host a website 에 체크를 하고, index document에는 자신이 작성한 웹 페이지의 index page의 파일명을 기재합니다. 저의 경우 좀 전에 버킷에 업로드한 파일을 보면 index.html이 있고, 이 파일이 index page의 파일이기 때문에 index.html을 기재했습니다.

이번에는 두번째 버킷으로 들어오는 요청을 루트 버킷으로 redirection 할 수 있도록 설정을 합니다. 루트 버킷과는 달리 Redirect requests에 체크를 하고, Target bucket or domain에 루트 버킷의 이름을 기재합니다.

두번째 버킷 정적 웹 호스팅 기능 활성화 및 Redirection 설정


버킷 Record Set 설정

이제 마지막 단계입니다. 지금까지 생성하고 설정을 마친 S3 버킷을 Route 53을 사용해 연결합니다. 도메인에 따른 호스팅 영역과 추가하는 별칭 레코드는 IP 주소 대신 S3 웹 사이트 엔드포인트를 사용함으로써 Route 53은 별칭 레코드와 S3 버킷이 존재하는 IP 주소 간 매핑을 유지합니다.

S3 버킷 Route 53 - Record Set 설정

Route 53의 Record Set 까지 설정을 마치면 해당 루트 도메인과 서브 도메인을 통해서 사이트에 접속할 수 있습니다.

참고
AWS - 사용자 지정 도메인으로 정적 웹 사이트 설정
아마존 웹 서비스를 다루는 기술 - 11장

5) AWS Lambda 사용하기

Index

  1. AWS Lambda란?
  2. CloudWatch와 Lambda 구성하기
  3. 정리하며

저번 포스팅에서 작성한 학식 메뉴 크롤링(학식 메뉴를 크롤링해 DB에 저장) 코드를 AWS Labmda를 사용해 일주일에 한번씩 실행되도록 스케쥴링을 해보겠습니다.

AWS(아마존 웹 서비스)에 대한 기본적인 내용은 생략합니다.

AWS Lambda란?

어떠한 이벤트에 따라 Cron 프로세스를 구성하는데에는 다양한 방법이 존재합니다. 서버 인스턴스를 띄워놓고 일정 시간에 이벤트를 발생시키는 것이 일반적인 방법 중 하나이지만 이러한 방법으로 구성할 시에는 해당 시간에 Event를 발생시키는 일을 제외하고는 서버 인스턴스를 낭비하게 됩니다.

AWS Lambda이벤트에 응답하여 코드를 실행하고 자동으로 기본 컴퓨팅 리소스를 관리하는 서버 없는 컴퓨팅 서비스입니다. AWS Lambda를 사용하여 커스텀 로직으로 다른 AWS 서비스를 확장하거나, AWS 규모, 성능 및 보안으로 작동하는 자체 백엔드 서비스를 만들 수 있습니다. AWS Lambda는 Amazon S3 버킷의 객체에 대한 변경 또는 Amazon DynamoDB의 테이블 업데이트와 같은 다양한 이벤트에 대한 응답으로 코드를 자동 실행할 수 있습니다.

AWS Lambda는 코드가 실행되지 않을 때는 요금이 부과되지 않습니다. 즉, 서버 인스턴스를 계속 띄워놓는 것과 비교했을 때 더 저렴합니다. AWS Lambda의 자세한 요금 정책은 AWS 홈페이지에서 확인 가능합니다. (Lambda 함수가 다른 AWS 서비스를 사용하거나 데이터를 전송하는 경우 추가 요금이 부과될 수 있으므로 필히 확인바랍니다.)


CloudWatch와 Lambda 구성하기

1) AWS에 로그인 후 Lambda 서비스를 클릭합니다.

Lambda Function 생성하기 - 1

2) 저와 같이 이미 생성한 Lambda 함수가 있는 경우는 아래와 같이 Create a Lambda Function 버튼을 클릭하고 처음으로 Lambda 함수를 생성하는 경우는 Get Started Now 버튼을 클릭합니다.

Lambda Function 생성하기 - 2

3) Blueprint는 자주 사용되어지는 미리 준비된 Lambda 함수의 환경을 제공합니다. 저희는 Blank Function을 선택해서 직접 trigger(Event)와 환경을 설정합니다.

Lambda Function 생성하기 - 3

4) Lambda를 일정 시간 규칙에 맞게 호출할 것이기 때문에 CloudWatch Events - Schedule를 선택합니다. CloudWatch는 AWS에서 실행되는 애플리케이션을 위한 모니터링 서비스 뿐만 아니라 Schedule도 제공합니다.
(Lambda를 실행시키기 위한 trigger로 다양한 방법이 제공됩니다. 한가지 예시로 S3의 특정 Bucket에 이미지 파일이 업로드 될때마다 ReSizing을 하고싶다면 trigger로 S3를 설정한 후 Bucket과 Event type(Delete, Put, Post, Copy)을 설정하여 해당 Lambda를 수행하도록 할 수 있습니다.)

Lambda Function 생성하기 - 4

5) CloudWatch Events - Schedule의 내용을 작성합니다. Rule nameRule description에는 해당 Schedule의 이름과 설명을 적고, Schedule expression에는 Event를 발생시키고자 하는 주기에 맞게 Cron 식을 작성합니다.
Schedule expression에 작성한 Cron 식에 따라 Event가 발생하는 시간이 달라집니다. Cron 식을 처음 접하시는 분은 AWS 홈페이지1, AWS 홈페이지2를 참고해서 Cron 식을 작성합니다.
단, Cron 식에 사용되는 시간은 UTC를 기준으로 하기 때문에 유의해야 합니다. 제가 작성한 cron 식 (0 13 ? * SUN *)을 기준으로 하면 매주 일요일 22(13+9)시에 이벤트가 발생합니다.

Lambda Function 생성하기 - 5

6-1) 다음과 같이 Lambda function의 이름, 설명, 실행환경(포스팅 기준 Node.js 6.10 이 최신 버전입니다.) 을 작성합니다.

6-2) 다음으로 CloudWatch Events에 의해서 실행될 코드를 기재해야합니다. 코드를 기재하는 방식은 직접 작성, .ZIP 파일로 압축, S3를 이용하는 3가지 방식중 하나로 진행됩니다.
만약 작성한 코드가 aws-sdk를 제외한 외부 라이브러리를 사용하고 있다면 코드와 함께 라이브러리 파일(node_modules)을 압축하여 .ZIP 파일을 업로드 해야합니다.

6-3) 기존에 작성했던 코드에서 수정이 필요합니다. Lambda function의 코드가 에러없이 잘 완료되었는지 callback을 통해 결과를 반환해야합니다. 지난번에 작성했던 코드는 다음과 같이 수정됩니다. (예시를 들기위해 간단하게 작성했을 뿐, 실제 DB에 Insert 하는 부분은 생략되어 있습니다.)
29, 30번째 줄과, 34번째 줄에 추가된 코드에 주의하셔야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
exports.handler = (event, context, callback) => {
const request = require('request');
const cheerio = require('cheerio');

const url = "http://www.inu.ac.kr/com/cop/mainWork/foodList1.do?siteId=inu&id=inu_050110010000&command=week";

request(url, (error, response, body) => {
if (error) throw error;

let $ = cheerio.load(body);

try {
let krDay = '';
let corner = '';
let menu = '';

$('table').find('tr').each(function (index, elem) {
if (index % 6 === 0) {
krDay = $(this).find('th').text().trim();

console.log(`${krDay}`);
} else {
corner = $(this).find('th').text().trim();
menu = $(this).find('th').next().text().trim();

console.log(`${corner} -> ${menu}`);
}

callback(null);
context.succeed();
});
} catch (error) {
console.error(error);
callback(err);
}
});
};

Lambda Function 생성하기 - 6

6_4) 필요에 따라 환경변수(Environment variables)와 Advanced settings를 작성한 후 Role을 작성하고 다음단계로 넘어갑니다. (Handler에 index.handler 라고 작성했기 때문에 .ZIP파일로 압축할때 소스코드(.js)의 파일명은 index가 되어야 합니다)

Lambda Function 생성하기 - 6

7) 지금까지 설정한 옵션을 확인하고 최종적으로 function을 생성합니다.

Lambda Function 생성하기 - 7

8) 생성된 Lambda Function을 테스트할 수 있습니다. Actions -> Configure test event를 통해 테스트를 위한 이벤트를 설정합니다. trigger(Event)로 CloudWatch Events - Schedule를 설정했기 때문에 event template 목록 중 Schedule Event를 선택합니다.

Lambda Function 테스트 - 1
Lambda Function 테스트 - 2

9) 테스트 후 CloudWatch의 로그를 통해서 lambda function 코드에서 출력했던 로그 및 실행결과를 확인할 수 있습니다.

Lambda Function 로그 확인 - 1
Lambda Function 로그 확인 - 2


정리하며

지금까지 진행한 작업은 다음의 이미지 한장으로 정리가 가능합니다. 이번기회에 lambda를 처음 사용해봤지만 앞으로 개인프로젝트에도 실무에서도 자주 사용하게될 것 같습니다.

AWS의 CloudWatch와 Lambda

Qvic 서비스 아키텍처 설계

회사에서 새로운 서비스를 준비하며 이번 9-b 스프린트동안 구축한 Qvic의 AWS 구조는 다음과 같습니다. 각각의 서비스에 대한 자세한 내용은 AWS 사이트와, 책을 참조 하였고, 이번 글에서는 이와 같은 환경을 구축하며 생겼던 문제들과 앞으로는 조금 더 쉽게 구축 할 수 있도록 일련의 과정에 대해 설명하고자 합니다.

Qvic AWS Architecture


1. IAM 생성

IAM은 Identity and Access Management(식별 및 접근 관리)의 약어로 사용자와 그룹을 생성하고 AWS의 각 리소스에 대해 접근제어와 권한관리를 제공한다. 이러한 IAM 을 EC2 Instance를 생성하며 설정할 수가 있는데 이미 만들어진 EC2 Instance에는 IAM 역할을 설정할 수가 없다. (처음에 모르고 하다가 나중에 지우고 다시 EC2를 생성하며 IAM을 설정하는 일이 생길 수 있다.) 물론 IAM 을 설정하지 않아도 EC2 Instance에서 API로 액세스 키와 시크릿 키를 설정해서 AWS 리소스에는 접근할 수 있지만 나중에 Auto Scaling 기능으로 자동으로 생성되는 EC2 인스턴스에 액세스키와 시크릿키를 일일이 설정해주는 것은 상당히 귀찮은 일이다. 이를 위해 먼저 IAM 을 생성한 후 EC2를 생성하는 것이 좋다.
* IAM 생성 후 생성 된 IAM에 권한을 부여하는 것은 나중에도 가능하므로 자세한 내용을 알지 못한다면 일단 생성 후 EC2에 적용만 해놓아도 된다.


2. EC2 생성 -> 개발환경 구축 -> AMI 생성

사용중인 AWS 계정이 Free Tier 라면 t2.micro (1달 750시간 무료) Instance로 생성하여 AMI(Amazon Machine Image)를 생성하는 것도 효율적인 방법이다. 추후에 AMI를 사용하여 EC2를 새로 생성할 수도 있고, 이미 생성된 EC2 Type을 변경할 수도 있다.

EC2의 Instance는 다음과 같이 생성하였다. (모두 Ubuntu Image를 사용하였다. EC2를 생성할때 만들어지는 .pem 파일의 백업은 중요하다!)
Express를 사용하여 프로젝트를 진행하였기 때문에 3000번 포트가 필요하여 Security Group 설정에서 Add Rule을 통해 3000번 포트를 추가해 주었다.

  • Blue-Green Deployment 를 위해 Auto Scaling (자동으로 EC2 인스턴스를 생성하여 서비스를 확장하는 기능) 을 적용한 Prod 용 Instance 2개
  • Dev 용 Instance 1개

먼저 Dev 용으로 Instance를 생성 하였고, 다음과 같은 개발환경을 구축하였다.

  • 기본 ubuntu 계정을 제외하고 팀원들의 각각 사용자 계정 추가 (비밀번호 설정, root 권한을 사용할 수 있도록 설정)
  • 각 사용자마다 .pem 키를 사용하여 로그인 하는 것이 보안상 안전하지만 편의상 비밀번호로 로그인 할 수 있도록 설정 (ssh 의 공개키와 비공개키 개념 필요)
  • node v6.6.0 설치 (사용자가 여러명이고 진행중인 프로젝트마다 node의 버전이 다르다면 nvm 을 설치하는것 추천)
  • git 다운로드 및 ssh 설정
  • bash 및 vim 설정 (만들어진 script 파일을 받아 실행)

다음은 Prod 용 Instance 개발환경 구축이다. Prod 용은 Dev Instance 와는 다르게 Auto Scaling을 적용할 것이기 때문에 Dev Instance 와는 조금 다른 설정이 필요하다. Auto Scaling은 트래픽이 증가하면 자동으로 EC2 Instance를 생성하여 서비스를 확장하기 때문에 자동으로 생성된 EC2 Instance가 자동으로 서비스를 시작 할 수 있도록 구축해야 한다. 따라서 다음과 같은 설정이 필요하다.

  • node v6.6.0 설치
  • git 다운로드 및 ssh 설정
  • bash script 파일

Auto Scaling 그룹을 생성기 전에 설정하는 EC2 생성 옵션 설정에서 'User data' 라는 칸에 자동으로 EC2가 생성된 후 root 권한으로 실행할 스크립트를 작성한다. 이때 git에서 프로젝트를 clone 한 후 자동으로 서비스를 시작하도록 하는 코드가 작성되어야 한다. 이 부분이 어려운 부분은 아니지만 경로 등… 여러가지 설정을 한 후 Auto Scaling이 잘 적용되는지 확인하기 위해서는 생성한 Auto Scaling에 인위적으로 부하를 걸어 Instance가 생성되도록 하고 ‘User data’에 작성한 스크립트가 잘 실행되는지 까지 확인해야 한다. 생각보다 시간이 걸리고 인스턴스를 반복적으로 생성하고 삭제 (과금…) 하는 부분이 부담스러워서 직접 EC2 에 bash script 파일을 작성한 후 ‘User data’ 에서는 이 script를 실행하도록만 작성하였다. 작성한 script는 먼저 만들어 두었던 Dev Instance 에서 테스트 한 후 잘 작동하는 것을 확인한 후 Prod Instance로 옮겼다.
이렇게 생성한 Dev와 Prod 용 Instance를 사용하여 AMI를 생성한다.


3. ELB (Elastic Load Balancing) 사용

Auto Scaling 그룹을 생성 하면서 ELB 를 선택하는 부분이 있기 때문에 ELB를 먼저 생성해야 한다. AWS에서 제공하는 ELB는 2가지가 있다.

AWS - ELB

1. Application load balancer
Layer 7 로드밸런싱을 통해 패킷을 조사하고, HTTP 및 HTTPS 헤더에 접근해서 좀 더 지능적인 부하 분산 작업이 가능하다. 예를들어, URL에 /api 라는 경로를 포함하고 있는 경우, 다른 서버 그룹으로 요청을 보낼 수 있으며 /mobile은 또 다른 서버 그룹으로 보낼 수 있다. 각 애플리케이션 로드밸런서는 10개의 URL 규칙을 만들 수 있으며 이를 통해 여러 개의 마이크로서비스를 독립적으로 실행하고 확장할 수 있다.

2. Classic load balancer
Layer 4 로드밸런싱을 사용하여 네트워크 프로토콜 레벨에서 제공 되며, 실제 패킷을 살펴 보지는 못하기 때문에 HTTP나 HTTPS 같은 특정 프로토콜을 인지하지 않고 부하를 분산한다.

ELB 생성시 주의할 점은 다음과 같다.

  • Express를 사용하기 때문에 3000번 포트를 추가해 준다. (Security Group 설정에서도 추가)
  • 헬스 체크(Health Check) 기능 설정시 3000번 포트로 변경해준다.
  • 헬스 체크 주기(Health Check Interval)와 Threshold는 적절히 설정해준다.
  • 로드밸런싱할 Instance를 추가할 때 생성해 두었던 Prod 한개를 설정한다. (Blue-Green Deployment 를 하기 위해서는 각각의 Instance에 서로 다른 load balancer를 설정해야 한다.)

혹시 Elastic IP가 적용되어 있었다면 제거한다. 앞으로 서비스에 접속할 때는 EC2 Instance에 바로 접속하지 않고 ELB 의 URL로 접속한다. (후에 Route 53에서 자신의 도메인으로 설정할 수 있다.)


4. Auto Scaling 적용

EC2 Instace 생성 옵션을 설정하고, Auto Scaling 그룹을 생성한다. EC2 Instance 생성 옵션을 설정하면서 주의할 점이 몇가지 있다.

  • IAM role 은 자동으로 생성되는 EC2 Instance에서 사용할 IAM 역할이다. IAM 역할을 사용하면 액세스 키와 시크릿 키 없이 AWS API를 사용할 수 있으므로 당장은 AWS API 를 사용하지 않더라도 설정해 두는것이 좋다.
  • Advanced Details를 누르면 나오는 User data는 EC2 Instance가 생성된 후 root 권한으로 자동으로 실행할 script를 입력하는 곳이다. AMI를 생성하며 작성했던 script가 실행되도록 작성한다.
  • #!/bin/bash
    /home/ubuntu/auto_start.sh
  • Express를 사용하기 때문에 Security Group 설정에서 Add Rule을 통해 3000번 포트를 추가해 준다.
  • 미리 생성해 두었던 ELB를 적용한다.

여러가지 설정들이 있는데 이는 나중에 수정이 가능하므로 처음 생성시에 너무 고민하지 않아도 된다. 필요할 때 수정해주고 모르는것은 좀 더 조사해보면서 수정하면 된다.

<종료정책 설정>
처음 Auto Scaling을 만들고 테스트를 하면서 당황했던 것이있다. 처음에 유지되고 있던 1개의 Instance에 인위적으로 부하를 걸면 내가 설정해놓은 정책에 따라 Instance가 자동으로 생성되고, 삭제되게 되는데 마지막에 생성된 Instance가 그대로 남고 원래 존재하던 Instance가 제거 되는 것이다. Auto Scaling이 적용된 Instance에는 자동 생성되는 Instance의 AMI 와는 조금 다르게 환경 구축이 되어있는데 사라져서 당황했었다. 이는 Auto Scaling의 종료정책 때문인데 종료정책의 종류는 다음과 같다.

  • OldestInstance : Auto Scaling은 그룹에서 가장 오래된 Instance를 종료한다.
  • NewestInstance : Auto Scaling은 그룹에서 가장 새로운 Instance를 종료한다.
  • OldestLaunchConfiguration : Auto Scaling은 가장 오래된 시작 구성을 가진 Instance를 종료한다.
  • ClosestToNextInstanceHour : Auto Scaling은 다음 번 결제 시간에 가장 근접한 인스턴스를 종료한다.
  • Default : Auto Scaling은 해당 기본 종료 정책을 사용한다. (기본 종료 정책은 네트워크 아키텍처 전반에서 가용 영역이 균일하게 적용 되도록 설계되어있다.)

위와 같은 종료정책은 Auto Scaling 설정시 설정하는 부분이 아니고 생성한 후 변경해 주어야 하는 부분이라 놓칠 수 있다. 기본 종료 정책이 아닌 다른 정책이 필요하다면 변경해 주어야한다.


5. Route 53

Route 53은 EC2, ELB, S3, CloudFront와 연동 가능한 DNS 서비스이다. Free Tier에서도 무료로 사용이 불가능하다. Route 53을 사용하기 위해서는 도메인이 필요한데 아직 구매하지 않았다면 Route 53 에서 구매하는 것을 추천한다. 외부에서 구매한 도메인은 네임서버를 따로 설정해 주어야한다.
A 레코드를 통해 미리 생성했던 ELB를 쉽게 설정해 줄 수 있다. (후에 Blue-Green Deployment시 2개의 ELB를 서로 교체해주면 된다.)


6. 그외 여러 주의사항

  • Free Tier 에서 한달에 EC2 Instance는 750시간 무료이고 EBS는 30GB가 무료이다. 보통 EC2 Instance만 신경써서 4~5개를 한번에 만들고 후에 제거하고 하는데 EC2 Instance 생성시 따로 EBS 크기를 정해주지 않으면 기본이 8GB이기 때문에 4개만 생성해도 EBS로 인해 과금이 된다. (정지해도 과금이 된다.)
  • Elastic IP는 EC2 Instance 1개에 대해 할당하고 있을때만 무료이다. 만약 EC2 Instance를 중지하거나 제거한다면 Elastic IP도 제거해 주어야 한다.
  • Free Tier 사용시 CloudWatch 의 주기는 5분일때 무료이다. 주기를 줄이면 과금된다.
  • EC2의 개발환경 세팅시 AMI를 자주 만들어주자… AIM 설정이라던가 Auto Scaling의 종료정책을 몰라서 많이 날려먹었다.
  • 예상하지 못한 과금은 무서우니 알림을 설정해놓자.

Linux & Ubuntu 계정 추가 & 설정

AWS의 EC2를 사용하면서 ubuntu에 사용자를 추가해주는 경우가 빈번히 생겨 그 과정을 정리해보려 합니다. 각각의 유저가 자신의 사용자 계정을 사용한다면 자신만의 파일과 작업 공간을 가질 수 있고, 잘못사용해서 시스템에 피해가 생기는 일도 어느정도 예방할 수 있습니다.

EC2 인스턴스에 사용자를 추가하는 작업에는 (1) 사용자를 시스템에 추가하고 (2) 해당 사용자에게 원격으로 로그인하는 방법을 제공하는 두 가지 작업이 포함됩니다.

올바른 방법은 하나의 EC2에서 생성한 각각의 사용자 계정마다 key pair를 생성해 주고, 각 계정에 맞게 설정된 key pair를 통해서만 접속 할 수 있도록 설정을 해야합니다.

그러나 최초 EC2 인스턴스를 생성하며 만들었던 key pair를 모든 사용자가 공유한다던가, password 기반의 로그인을 활성화 하여 ssh key를 사용하지 않고 password 기반으로 로그인을 할 수도 있습니다.

이번 포스팅에서는 (1) 사용자를 시스템에 추가한 후 (2-1) EC2 인스턴스를 생성하며 사용했던 key pair(기본 사용자 로그인시 사용하는 key pair)를 사용하거나, (2-2) password 기반의 로그인을 활성화하여 ssh key를 사용하지않고 로그인할 수 있도록하는 방법에 대해 정리합니다.


1. root password 설정

1
[ubuntu ~] $ sudo passwd root

2. password 기반의 로그인을 활성화하기

1
[ubuntu ~] $ sudo vi /etc/ssh/sshd_config

다음을 수정합니다. no를 yes로 변경합니다.
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

3. root 계정으로 로그인

1
[ubuntu ~] $ su - root

4. 다른 사용자 계정 추가

1
[root ~] $ adduser newuser

5. 새로 생성한 사용자 계정의 비밀번호 변경

1
[root ~] $ sudo passwd newuser

6. 새로 생성한 사용자 계정에 root 권한을 사용할 수 있도록 설정

1
[root ~] $ sudo visudo

다음을 수정합니다.
root ALL=(ALL) ALL 아래에
newuser ALL=(ALL) ALL을 추가합니다.

7. 같은 key pair로 로그인 할 수 있도록 새로 생성한 사용자 계정으로 ubuntu 의 것을 복사

* 이부분에 대한 자세한 내용은 SSH KEY 에 대하여 알아야합니다.
* ubuntu 계정의 .ssh 폴더를 복사해 newuser 계정에 복사합니다.

1
[root ~] $ ssudo cp /home/ubuntu/.ssh /home/newuser/.ssh

8. 복사한 key pair의 소유자를 jmkim으로 변경 (-R : 하위 폴더까지 모두 소유권을 바꿔줌)

1
[root ~] $ sudo chown -R newuser:newuser /home/newuser/.ssh

9. sshd 서비스 재시작

-Ubuntu

1
[root ~] $ sudo service ssh restart

-Linux

1
[root ~] $ sudo service sshd restart

이제 EC2 instance를 생성할때 만들었던 .pem 파일과 설정한 비밀번호를 통해 새로 생성한 계정으로 서버에 접속할 수 있습니다.


참고 : AWS 공식 사이트 - Managing User Accounts on Your Linux Instance

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×