S3 소개



아마존 웹서비스의 S3라는 서비스는 Simple Storage Service이다.

즉 쉽게 파일을 저장할 수 있는 서비스이다.

서버를 구축해서 파일을 저장할 수도 있겠지만, 아마존에서 제공하는 S3를 사용한다면

저장에만 초점을 맞춰서 서비스를 사용할 수 있는 장점이 있다.



S3의 장점은 다음과 같다.


1. 높은 내구도로 중요한 정보를 안심하고 저장할 수 있다.

99.999의 객체 내구도를 가진 인프라이다. 여기서 내구도는 유실될 가능성을 나타낸다.

여러시설과 각 시설에 중복 저장 되므로 서버 하나가 파괴 되더라도 다른 저장소에 남아있다.


2. S3는 저렴한 비용으로 사용이 가능하다.

서버를 운영한다고 하면 인스턴스를 구매해야하고, 이에 따른 비용이 만만치 않다.

S3는 사용하는 만큼만 비용을 내면 되기때문에, 서버에 대한 진입장벽이 낮고,

파일을 액세스 하는 빈도에 따라서, 저장 방식을 다르게 설정함으로 비용이 다르게 적용 된다.


3. 객체 가용성이 높다.

파일이 서비스 되는 기간이 년중 99.999% 이므로 서비스가 중단될 걱정없이

S3를 사용할 수 있게된다.


4. 보안성이 뛰어나다.

SSL을 통해 데이터 전송과 암호화를 하므로 해킹 걱정이 적어진다.


5. 이벤트 알림 전송

S3로 파일이 업로드 되었을 때, 그 사실을 다른 서비스에게 알려서, 서비스를 트리거할 수 있다.

즉, S3와 연계된 서비스들을 사용하는데 상당히 유용하다.


6. 고성능이다.

지역을 선택해서 빠르게 업/다운로드가 가능하다.

또한 지연시간 최소화를 위한 멀티 파트 업로드를 지원한다.







AWS는 다음과 같은 기능을 위해 사용된다.


1. 콘텐츠 저장 및 배포

웹사이트를 만든다고 하면 사용자가 전송한 파일을 S3에 저장한다.

이렇게 저장된 파일을 다시 사용자에게 보여주거나 가공할 수 있다.


2. 빅데이터 분석

빅데이터를 분석하기 위해서는 거대한 데이터를 안전하게 저장해야하는데

이 때 데이터 저장소로써 사용될 수 있다.


3. 재해 복구

예측 할 수 없는 재해가 일어났을 때 여러 저장소에 분산 저장되므로

저장소가 한꺼번에 파괴되지 않는이상 복구가 빠르기 때문에 내구도가 높다.



출처 : 생활코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] S3 소개  (0) 2017.05.23
[AWS] S3  콘솔을 통한 기본 조작 방법  (0) 2017.05.23
[AWS] Nodejs를 위한 AWS SDK  (0) 2017.05.18
[AWS] AWS를 제어하는 방법  (0) 2017.05.17
[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17

S3  콘솔을 통한 기본 조작 방법





S3는 아마존 웹서비스에서 제공하는 대용량 데이터 저장소이다.

우선 AWS 서비스 콘솔에서 S3를 누르면 다음과 같은 화면으로 들어올 수 있다.

여기서 S3을 사용 하기 위한 버킷(Bucket)을 만들어 주어야 한다.

여기서 버킷이란 파일을 저장하기 위한 저장 장치와 같은 의미이다.






Create Bucket을 클릭하면 위와 같은 화면이 뜬다.

여기서 버킷을 이름을 입력한 후 Create를 클릭하면 버킷이 생성된다.

단 여기서 주의 할 점은, 버킷을 이름을 지정할때 AWS에서 중복되지 않는 이름을 넣어야한다.

(스타워즈나 스타트렉 등의 유명한 단어는 이미 있을 확률이 높다)






버킷이 만들어지면 위와같이 empty 화면이 뜰것이다.

파일을 추가 하기위해서는 Upload 버튼을 눌러야 한다.






업로드 버튼을 누르면 다음과 같은 팝업이 뜬다.

여기서 Add files를 누르면 파일을 검색할수 있는 창이 나오는데,

자신이 S3에 보관할 파일을 찾아 선택하도록 하자.

선택이 완료되었으면 오른쪽 하단에 Start Upload를 클릭한다.






파일이 정상적으로 올라가면 empty 였던 창이 파일로 채워지게 된다.

여기서 해당 파일을 클릭하고 오른쪽 상단에 properties를 누르면,

이름과 사이즈 등의 속성이 출력된다.

그중에 link라는 것이 있는데, 이는 외부에서 S3파일로 접근이 가능한 경로이다.

물론, 현재는 저 파일의 권한이 비공개이므로, 공개로 만들어 줘야한다.


여기까지 기본적인 S3서비스를 콘솔을 이용해서 사용하는 방법에 대해 알아보았는데,

실제적인 서비스에서는 이와 같은 GUI방식 접근 하는 일이 드물다.


예를 들어, 애플리케이션, 웹사이트에서, 사용자가 올린 파일이 첨부되는 서비스를 제공한다고 할 때,

사용자가 서버로 파일을 올리면, 미들웨어가 API를 통해서 S3로 파일을 전송해주고,

전송된 결과를 사용자에 보여주는 방식으로 작동하게 된다.



출처 : 생활코딩, 아마존 웹 서비스


저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] S3 소개  (0) 2017.05.23
[AWS] S3  콘솔을 통한 기본 조작 방법  (0) 2017.05.23
[AWS] Nodejs를 위한 AWS SDK  (0) 2017.05.18
[AWS] AWS를 제어하는 방법  (0) 2017.05.17
[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17

Nodejs를 위한 AWS SDK





AWS에서 제공하는 SDK중에서 Javascript Node JS버전을 사용해보자

이를 위해 AWS SDK Javascript Node JS라고 구글에 검색을 하면 

첫 번째 탭에  공식 홈페이지가 나온다.


공식홈페이지를 클릭하면 위 그림과 같이 아마존 홈페이지로 연결되는데

여기서 개발자 안내서를 클릭하자


그러면 Node js에서 AWS SDK를 사용하기 위한 준비 순서가 나온다

우선 당연히 Node js를 위한 실습 환경이 구축 되어야한다.


1
npm install aws-sdk --save
cs


그리고 나서 패키지 관리자인 npm으로 aws-sdk를 설치해준다.

 명령어는 위와 같은 코드를 터미널창에 입력해 주면된다.

주의할 점은 npm init이 되어있는 프로젝트 디렉토리에 설치해야 된다는 것이다.






다음스텝은 Configuration 설정인데, SDK는 바로 사용하는 것이아니라 

몇가지 중요한 설정을 해줘야지 사용이 가능하다.

그래서 Configuration Object라는 것을 만들어야하는데,


1. AWS config 라는 것을 사용하는 방법

2. Passing extra configuration to a service object

두 가지 방법이 있다


1번째 방법을 통해서 설정을 하면 글로벌하게 설정하는것이고,

2번째 방법을 사용하면 각각의 서비스마다 설정을 할 수있게 된다.

여기서에서 말하는 서비스는 AWS에서 제공하는 서비스(EC2나 S3)를 말한다.






또한 이렇게 SDK를 사용하기 위해서 자격 증명은 5가지의 증명 방법이 있다.


첫 번째는 IAM에 role을 만드는 방법이다.

이렇게 만들어진 role을 사용하면 아이디, 패스워드 생략이 가능하다.

(애플리케이션이 AWS EC2 인스턴스 위에서 동작하는 상황이라면 권장됨)


ec2에서 인프라를 다루는 것이 아니라 다른시스템에서 접근한다면 나머지 방법을 사용한다.


두 번째는 홈 디렉토리 및에 .aws를 만들고 credentials라는 약속된 파일을 만들어두면

SDK가 동작할 때 파일이 있는지 없는지를 체크해서 

여기에 적혀있는 아이디와 패스워드를 이용해서 AWS에 접근하게 된다.


세 번째는 환경변수를 설정하는 방법

네 번째는 JSON파일을 따로 만들어서 node js가 읽어서 사용하는 방법

다섯 번째는 하드코딩하는 방법이다.





1
2
3
[default]
aws_access_key_id = <YOUR_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_SECRET_ACCESS_KEY>
cs

이중에서 두 번째 방법을 먼저 사용해 보자

홈 디렉토리에서 aws 디렉토리를 생성한 후에 credentials 파일을 만들어준다.

그리고 생성된 파일안에 위의 소스 코드를 넣자


위 소스에서 <YOUR_ACCESS_KEY_ID> <YOUR_SECRET_ACCESS_KEY>를 채워주기 위해서

AWS 서비스중에 Security and Identity 하위의 IAM에 들어간다.






여기서 좌측 Users 카테고리에 들어가서 파란색 Create User 버튼을 클릭한다.

자신이 원하는 이름을 입력하고 다음 스텝으로 넘어가고

파란색의 Show User Security Credentials를 클릭하면 위와 같은 화면이 나온다.


현재는 유저 이름을 nodejs라고 했는데 이에 따른 Access Key ID와

Secret Access Key가 나온 모습이다.

이걸 카피해서 위 소스 코드 자리에 붙여 넣어 준다.

이 키는 엄청 중요하기 때문에 외부에 유출하지 말고 잘 관리해야한다.


여기까지 완료했으면 다시 user 탭으로 돌아가 우리가 만든 아이디를 클릭해준다.

그리고 permissions 탭에서 Attach polish를 누른다.

많은 리스트중에서 Amazon EC2 full Access를 체크하고 다음 스텝으로 넘어가면

EC2 접근에 대한 모든 권한을 설정한다.





다시 초기 화면으로 돌아오면 많은 카테고리가 나온다.

방금전에 했던 설정은 Configuring the SDK 였다.

설정을 마치고 예제를 원한다면 Common Examples로 들어가서 SDK에 대한 감을 잡도록 하자


또한 상단의 APIs를 클릭하면 API문서가 나온다.

이 페이지 좌측에 EC2를 클릭하면 EC2 서비스에 대한 API와 예제 코드가 나오는데

이를 참고해서 소스를 작성하면 된다.





1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
var express = require('express');
var app = express();
var AWS = require('aws-sdk');
AWS.config.region = 'ap-northeast-2';
var ec2  = new AWS.EC2();
app.get('/'function(req, res){
        res.send('Hello world');
});
app.get('/ec2'function(req, res){
        ec2.describeInstances({}, function(err, data) {
                res.json(data);
        });
});
app.listen(80function(){
        console.log('Connect 80 port');
});
cs


AWS.config.region은 지역 설정이며, ap-northeast-2가 서울을 의미한다.

다음줄에 AWS.EC2 객체를 생성해서 인스턴스를 조정하게 된다.


'/ec2'로 get 요청을 받았을 때 호출되는 ec2.describeinstances는 

인스턴스 목록을 받아오는 것이다.







앞선 소스의 결과는 위와 같은데,

전혀 실용적이지 않지만 SDK로 인스턴스를 제어했다는 것에 의의를 두자.

이와 비슷한 방식으로 메소드를 사용해서 인스턴스의 제어가 가능하다.



출처 : 생활 코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] S3 소개  (0) 2017.05.23
[AWS] S3  콘솔을 통한 기본 조작 방법  (0) 2017.05.23
[AWS] Nodejs를 위한 AWS SDK  (0) 2017.05.18
[AWS] AWS를 제어하는 방법  (0) 2017.05.17
[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17

AWS를 제어하는 방법




이번 포스팅에서는 콘솔, CLI, SDK, API 등에 대해서 알아보자

이것은 AWS의 인프라(EC2, S3)를 제어하는 방법 들이다.


각각의 방법들이 장점과 특색이 있으므로 다 사용하지 않는다고 하더라도

차이를 알고 있다면 상황에따라 사용할수있는 폭이 넓어질 것이다.


우리가 일반적으로 아마존 웹서비스 홈페이지에 접근해서 서비스를 사용하는것은 GUI방식이다.

이 방법의 장점은 익숙하고, 많은것을 배우지 않아도 눈에 보이는걸 바로 사용할 수 있다.

우리는 기본적으로 GUI를 통해 인프라를 제어하는 것을 배웠지만

아마존에서는 이것 외에도 앞서 언급한 방법들을 모두 제공한다.






첫번째로 우리가 사용할 수 있는 방법은 CLI(Command Line Interface)이다.

여기서 말하는 Command Line이란 명령어를 뜻한다.

즉, 키보드로 명령어를 입력해서 컴퓨터를 제어하는 방식이라고 할 수있다.


CLI를 사용하기 위해, 먼저 터미널(콘솔)창을 연다.

그리고 aws ec2 describe-instances라고 입력하고 엔터를 치면 GUI 환경 처럼 인스턴스들의 목록이

위의 그림과 같이 나오게 된다.


이와같은 CLI의 단점은 어떤 명령어가 있는지 알아야된다는 것이다.

그럼에도 불구하고 CLI를 쓰는 이유는, 사용하는 방법만 익히면 GUI보다 편리하게 시스템을 제어할 수 있다는 것이다.


GUI를 사용하려면 로그인, 사이트 접속, 원하는 메뉴 클릭, 목록을 확인해야하지만

CLI에서는 명령어 한줄로 이 모든 기능을 확인할 수 있다.






또 다른 장점으로는 일련의 연속적인 작업을 한꺼번에 시킬 수 있다.

예를 들어서, Public IP에 대한 정보만 알고싶을 때 앞서 입력한 코드에 

| grep PublicIP라고 입력하고 엔터를 치면

인스턴스 정보 중에서 PublicIP가 들어있는 행 만을 출력하므로 더 쉽게 찾을 수 있다.


이렇게 파이프 라인으로 세트를 만들면 자동화된 처리방식으로 한꺼번에 사용이 가능하다.






그다음에는 SDK(Software Development Kit)라는 방식이 있다.

우선 예를 들어, 컴퓨터가 제공하는 기본적인 명령중에 반복적으로 실행하는 명령어가 있다면 

해당 명령어가 실행되는 순서를 언어의 문법에 따라 정의한 후에

거기에 이름을 붙이면 프로그램을 만든 것이다.


바로 이렇게 우리가 프로그래밍을 통해서 

좀더 지능적이고 섬세한 제어를 할 수있도록 AWS에서 제공하는 도구가 SDK이라고 할 수있다.

따라서 이 SDK는 각각의 언어별로 AWS의 인프라를 제어할 수 있도록 명령어의 세트를 제공한다.


위의 코드는 NodeJs(Javascript) SDK로, AWS의 시스템을 제어하는 코드이다.

다시 말해, AWS에서 제공하는 SDK를 자바 스크립트로 로드한 후에

SDK 에서 제공하는 EC2를 제어하는 명령어를 실행시켜서 그 결과를 출력하는 코드이다.

좀더 상세하게 말해서, 위의 코드를 실행하면 EC2의 많은 목록 중에 Public IP만을 출력하게 된다.







다음으로 살펴 볼것은 API(Application Programming Interface)인데

여기서 이야기하는 API는 SDK와 잘 구분이 되지않는 개념이기는 하다.

SDK는 기본적인 명령을 개발자들이 좀더 쉽게 사용하게 만든 것을 SDK라고 하고

API는 RESTful API라고 해서 웹을 통해서 AWS를 제어하거나 그 상태를 알 수 있게 한다.


https://ec2.amazonaws.com/?Action=DescribeInstances


에를 들어 위와 같은 경로로 AWS서버에 접속하면 

우리가 가지고 있는 인스턴스를 위의 그림과 같이 XML 양식으로 응답 해준다.

이렇게 받아온 XML을 파싱해서 사용하게 된다.


API는 기초적이고 원시적인 방법이다.

기초적이라는 것은 쉽다는 것이 아니라 자유도가 높고 공통의 방식이라는 뜻이다.

따라서 웹 API을 통해서 AWS 를 제어하는 방식은 특정한 프로그래밍 언어를 가리지 않으므로

직접 이용한다면 어떤 언어를 사용하건 상관없이 AWS의 인프라를 사용할 수있게된다.


그러나 이를 직접 이용하는 것은 상당히 불편하므로

어렵다는 것을 알기때문에 공통의  API를 만들어 놓고 이를 이용하는 

각 언어버전의 SDK를 아마존에서 제공하게 되는것이다.

아니면 이러한 이유로 CLI나 GUI도 같이 제공하기 때문에

API를 직접 사용하는 일은 잘 없을것이다.




출처 : 생활코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] S3  콘솔을 통한 기본 조작 방법  (0) 2017.05.23
[AWS] Nodejs를 위한 AWS SDK  (0) 2017.05.18
[AWS] AWS를 제어하는 방법  (0) 2017.05.17
[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17
[AWS] Scale Out - ELB 적용  (0) 2017.05.13

Auto Scaling - 생성




앞서 설정한 것은 새로 생성되는 인스턴스에 대한 것 이었고,

언제 어떤 조건에서 만들것이냐 하는 조건을 설정하는 것이 오토 스케일링 그룹이다.

프로그래밍과 비교했을 때 이벤트라고 생각하면 된다.






Group name은 해당 오토 스케일링 그룹의 이름이다.

우리가 먼저 설정한 Launch Configuration이 Group name 위에 있는데, 이는 해당 오토 스케일링이 실행될 경우

미리 설정한 인스턴스가 만들어지는 것을 뜻한다.

Group Size 라는 것은 오토 스케일링을 시작했을때 몇개의 인스턴스로 시작할까를 지정 하는 것이다.

그 다음 subnet이라고 하는것을 클릭해서 안에 있는 내용을 다 적용해준다.

이 Subnet이라고 하는 것은 가용 구역을 나타낸다.

가용 구역은 지역 내에 독립된 데이터 저장소로써 위와 같이 2개를 적용해 주면

번갈아가면서 인스턴스를 만들기때문에 가용구역 1개에서 문제가 일어나도 안정적으로 서비스를 제공할 수 있다.

모든 설정이 마무리 되면 아래의 Advanced Details를 눌러준다.





가장 처음에 Load Balancing이 있는데,

우리가 오토 스케일링을 정의해서 인스턴스를 만들면 

오토 스케일링을 통해 인스턴스를 특정한 로드 밸런서에 자동으로 붙일 수 있다.

그때 사용하는 것이 Load Balancing이다.

따라서 이를 위해 우리가 만들어준 로드 밸런서를 입력해야한다.

나머지는 그대로 두고 다음으로 넘어간다.






이 페이지는 어떤 정책(상황)에 따라 인스턴스를 생성할 것 인지를 지정 한다. 

첫번째 있는 Keep this group at its initial size는 초기에 지정해놓은 사이즈를 유지하는 것이다.

즉, 몇개의 인스턴스로 시작할것인지 지정 했던 내용에 맞추어 인스턴스를 생성한다.

인스턴스의 개수가 가변적이지 않다는 이야기이다.


아래에 Use scaling policies to adjust the capacity of this group은 

컴퓨팅의 필요에 따라서 인스턴스를 늘리고 줄이는 작업을 처리하는것과 관련되어 있다.

인스턴스가 상황에 맞춰서 가변적으로 변하는 것이다.






우리는 가변적으로 처리하기 위해 Use scaling policies to adjust the capacity of this group을 선택한다.

그러면 위의 그림과 같은 페이지가 펼쳐진다.

아래의 scale between ~ 은 생성되는 인스턴스의 상한과 하한을 지정한다.

이를 설정함으로써 인스턴스가 너무 많이 생기거나 적게 생기는 것을 방지할 수 있다.


그아래 Increase Group Size는 어떤 상황에서 인스턴스를 증가시키거나 감소시키는 정책에 해당한다.

Excute policy when에 주황색으로 Add new alarm이라고 적혀있는데,

 이는 오토 스케일링을 통해 만들어 놓은 인스턴스등을  감시를 하는 과정에서 

인스턴스들이 특정한 상태에 도달했을때 알람이 오토 스케일링에 전달 되도록하는 기능이다.






주황색 알람 추가 버튼을 누르면 위와 같은 팝업이 뜬다.

Send a notification 이라고 되어있는 부분은 알람이 울렸을때 이메일이 가게하는 것이다.


다음으로 Whenever에서 CPU Utilization은 CPU 점유율을 뜻한다.

따라서 이 오토 스케일링 으로 인해서 만들어진 컴퓨터들의 CPU 점유율이,  예를 들어 60% 이상이고, 

For at least에서 '이 상태가 5분 이상 지속된다면 알람을 울려라' 라는 식으로 설정이 가능하다.

이와 같은 설정이 끝났으면 알람 설정을 마친다.






Take the action은 위에서 만든 알람이 왔을때 오토 스케일링이 하는 일을 설정한다.

위에서 설정한 내용은 CPU 점유율이 60에서 80사이에 있으면 1대의 인스턴스를 만든 것이고

80이상이 되면 2개의 인스턴스를 한번에 더 만든다는 것이다.


 Increase에 대한 설정이 끝났으면 동일하게 Decrease에 대한 설정도 마무리하고 다음 스텝으로 넘어간다.






오토 스케일링이 동작한다는 것은 단순히 자동화를 넘어, 상당히 중요한 정보이다.

왜냐하면 이러한 상황에는 시스템에 큰 문제가 생겼을수 있기 때문이다.

그래서 특정한 경우에 AWS로부터 통보를 받는 기능이다.


가장 먼저 통보 받을 수단을 설정(send a notification to)하는데, 

누가 이메일을 받을것인지(With these recipients), 

어떤 상태(Whenever instances)에서 받을 것인지에 대한 설정이 가능하다.

만약 복수의 담당자가 통보를 받아야한다면 Add notification을 다시 클릭해 준다.


설정이 완료되었으면 다음 스텝으로 계속 넘어가고 리뷰페이지에서 최종적인 상태를 점검하고

오토스케일링 그룹을 생성한다.






최종적으로 위와 같은 화면이 나오면 성공이다.

인스턴스가 현재 1개이며 최소 1개 최대 3개의 인스턴스를 만든다.

그리고 300초의 대기 시간을 가지며 이후에 인스턴스 생성과 삭제가 가능하다.





로드 밸런서로 들어가보면 위의 그림과 같이 오토 스케일링을 통해서 자동으로 만들어진 인스턴스가 

로드 밸런서에 붙어있는 것을 볼 수 있다.


이와 같이 오토 스케일링을 생성했다면

트래픽이 몰릴 때 자동으로 인스턴스를 생성해서 자동으로 로드 밸런싱을 해줄 수 있다.




출처 : 생활코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] Nodejs를 위한 AWS SDK  (0) 2017.05.18
[AWS] AWS를 제어하는 방법  (0) 2017.05.17
[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17
[AWS] Scale Out - ELB 적용  (0) 2017.05.13
[AWS] Scale Out - ELB 생성  (0) 2017.05.13

Auto Scaling - Launch Configuration






이전 포스팅에서 로드 밸랜서로 인스턴스를 만드는 과정을 살펴보았다.

그러나 현실적으로 사용자가 언제 많이 접속 하는지 알수 없고,

서버 관리자가 항상 서버를 살펴볼수 없으므로

수동으로 계속해서 작업을 할 수 없다.

따라서 기계(AWS)가 자동으로 로드 밸런스를 맞춰주는것이 오토 스케일링이라고 할수 있다.

이로 인해 비용이 효율적으로 발생하며, 탄력적으로 서버를 운영할 수 있다.


1. 전과 마찬가지로 부하 발생기와 테스트할 서버를 생성한다.

2. AMI로 가서 전에 만들어 두었던 웹서버 이미지를 확인 한다.

3. 좌측 카테고리에서 오토 스케일링을 찾아본다.


오토 스케일링은 위의 그림과 같은데, 두개의 구분은 다음과 같다.

Launch Configurations : 특정 이미지를 실제 동작하는 인스턴스로 생성하는 설정을 한다.

Auto Scaling Groups : 위의 설정을 기반으로 실제 오토 스케일링을 만들어준다.






따라서 먼저 Launch Configurations를 눌러준다.

그리고 가운데 있는 Create Auto Scaling group을 클릭한다.






그러면 다음과 같은 화면이 뜨는데

여기서 하단의 Create launch configuration을 클릭해서 우선 설정을 해야한다.





그러면 위와같은 익숙한 화면이 뜨는데 인스턴스를 만들 때 봤던 화면이다.

즉 configuration이란 오토 스케일링에서 사용할 인스턴스를 먼저 만들어야한다는 것이다.

따라서 미리 만들어진 이미지를 사용해서 인스턴스를 만들어준다.

다음에 나오는 성능 화면도 자신이 필요한 스펙에 맞춰 설정하고 넘어간다.






위의 화면은 Launch configuration에 대한 이름을 지정하는 화면이다.

즉, 어떤 이미지를 어떤 인스턴스로 만들것 인가에 대한 설정을 하는 것이다.

이름만 설정해주고 다음 스텝으로 넘어가도록 하자

4, 5번째 Add Storage와 Security Group은 인스턴스 생성과 동일하게 진행한다.






그리고  비밀번호를 생성하라는 화면이 뜨는데,

미리 만들어둔 키 페어가 있으면 Create Launch configuration을 눌러 그냥 넘어간다.


지금까지 한것은 Launch configuration을 만든것이다.

즉, 로드 밸런싱을 위해 자동으로 인스턴스를 생성할 때 

어떤 스펙의 인스턴스를 생성할 것 인가를 지정한 것이다.

따라서 인스턴스가 생성되지 않는다.


지금까지 우리가 만든 인스턴스가 어떠한 조건에서 자동으로 생성할 것 인가에 대한 

Auto Scaling을 다음 포스팅에서 알아보자




출처 : 생활코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] AWS를 제어하는 방법  (0) 2017.05.17
[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17
[AWS] Scale Out - ELB 적용  (0) 2017.05.13
[AWS] Scale Out - ELB 생성  (0) 2017.05.13
[AWS] Scale Out - 흐름과 이론  (0) 2017.05.13

Scale Out - ELB 적용




이전시간에 로드 밸런서를 만들었는데 현재는 비어있는 상태이다.

따라서 인스턴스를 장착하고 서비스를 진행해야한다.


이번시간에는 인스턴스를 만들고 웹서버를 설치해서, 스트레스 테스트를 진행한다.

이를 통해서 부하가 낮아지는지 확인해보자

위와 같이 빠르게 2개의 인스턴스를 만든다





1
2
3
sudo apt-get update;
sudo apt-get install apache2;
sudo apt-get install php5;
cs

그리고 아파치와 php를 위의 명령어를 통해 설치해준다.

php를 이용해서 서버를 열심히 일하게 하는 코드를 작성 해야한다. 




1
2
3
4
5
6
Hello AWS
<?php
    for($i=0$i<10000000$i++){
 
    }
?>
cs


위와 같이 일을 하도록 하는 코드를 작성하여 /var/www/html 안에 index.php로 저장해준다.

그러면 아파치 웹서버는 해당 포트로 접속 했을때  index.php를 실행하게 된다.






ab -n 1000 -c 10 "경로"

리퀘스트 1000개를 10개 동시접속으로 실행하는 코드를 사용하면 

cpu의 점유율이 100퍼센트에 금방 육박하는것을 볼 수 있다.

그렇다면 로드 밸런서를 이용해서 이를 해결해보도록 하자.






우선 로드 밸런서를 사용하려면 웹서버가 2개 이상이어야 한다.

따라서 원래 웹서버를 이미지로 만들고 새로운 인스턴스를 하나 만들어야한다.






그리고 이전에 만든 ELB를 찾아서

Instances -> Edit Instances 버튼을 눌러준다.






그러면 위와 같은 인스턴스 등록창이 나온다.

이때 등록하는 인스턴스들을 눌러서 Save를 클릭하면 ELB 등록이 완료된다.







한가지 조심해야할것은

초기에 Health Check를 등록해 놓았기 때문에, 이 파일이 반드시 있어야한다는 것이다.

이렇게 만들어진 로드 밸런서로 들어가기 위해서는 description에 있는 도메인 으로들어가면 된다.






정상적으로 동작한다면 ELB의 Instances의 상태(status)가 Inservice 단계에 들어오게된다.

여기서 인스턴스를 삭제하기 위해서는 Actions의  Remove from load Balancer를 누르도록 하자.




이제 생성한 2개의 인스턴스에 각각의 터미널로 원격 접속을 실행한다.


sudo tail -f /var/log/apache2/access.log

사용자가 접속할 때의 로그기록을 확인하기 위해 다음과 같은 명령어를 각각 입력한다.


그리고 테스트용 인스턴스에서 해당 로드 밸런서 도메인으로 부하를 걸어주면

2개의 인스턴스에서 균등하게 접속 로그가 갱신되는 것을 확인할 수있다.

로드 밸런서가 잘 동작하고 있는 것이다.

이렇게 ELB를 이용해서 부하를 균등하게 분산해 줄 수있다.






한가지 주의 사항으로는 데이터 베이스까지 다른 컴퓨터에서 쓰도록 나눠질경우 조회, 등록, 삭제 시

각각의 컴퓨터가 따로 데이터 베이스를 사용하기때문에 결과값이 달라진다.

따라서 이를 방지 하기위해 위와 같이 데이터 베이스는 한 컴퓨터에 지정해야한다.



출처 : 생활코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] Auto Scaling - 생성  (0) 2017.05.17
[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17
[AWS] Scale Out - ELB 적용  (0) 2017.05.13
[AWS] Scale Out - ELB 생성  (0) 2017.05.13
[AWS] Scale Out - 흐름과 이론  (0) 2017.05.13
[AWS] Scale Up - 인스턴스 교체  (0) 2017.05.13

Scale Out - ELB 생성





저번 시간에 설명한 Elastic load balancer 생성 방법에 대해 알아보자

로드 밸런서를 구매하려면 비용이 많이 들고, 이를 설치하고 구축하는데 상당히 번거롭다

때문에 AWS에서는 쉽게 로드 밸런서를 만들고 사용할수 있도록 인터페이스를 제공해준다.


EC2에서 좌측 카테고리 중 Load Balancers를 클릭하면 위와 같은 화면이 나온다.

여기서 상단에 Create Load Balancer 버튼을 클릭하면 로드 밸런서를 만들 수 있다.






버튼을 클릭하면 로드 밸런서의 기본을 정의 하는 페이지가 나온다.

여기서 로드 밸런서의 이름을 설정해준다

그리고 가장 밑에 테이블이 하나 나오는데,  로드 밸런스 포트와 인스턴스 포트라는 것이 등장한다.

둘의 차이는 무엇일까







우리가 로드 밸런서를 사용한다고 하는것은 위와 같은 구도를 가진다는 것이다.

이때, 사용자가 로드밸런서에 접근하는 포트가 로드 밸런스 포트라는 것이고,

로드 밸런스는 사용자의 접속을 받아서 다른 웹서버로 보낼 때를 인스턴스 포트라고 한다.


그래서 HTTP로 접속한다고 하면 80번 포트를 기본적으로 사용할것이고,

로드 밸런스 포트도 80번이 된다. 

만약 인스턴스에 있는 웹서버도 기본적인 HTTP 포트를 사용한다고 하면 인스턴스 포트도 80번이다.

그러나 기본적인 포트를 사용하지 않는다고 할 때 Step 1 에서 수정을 해주어야한다.





그리고 Step 2로 넘어가게되는데 인스턴스 생성과 동일하게

Security Group을 만들어 주면 된다.


Step 3 도 next를 클릭해서 넘어가고 위의 그림인 Step 4로 넘어간다.

Step 4는 Configure Health Check로써 어떤 컴퓨터의 상태를 정기적으로 체크해주는 것이다.

체크는 지정된 프로토콜, 포트, 경로로 접근해서 해당 파일이 다운로드 되면 정상으로 본다. 


Response Timeout은 응답을 기다리는 최대 시간이며

Health Check Interval은 체크 간격 시간이다.

Unhealthy Treshold란 몇번의 시도끝에 실패를 하면 좋지 않다고 판단을 내리는 기준이며,

healthy Treshold는 몇번의 시도까지 허용할 것인지에 대한 설정이다





그리고 적용할 인스턴스를 설정하고 다음으로 넘어가면되는데,

만약 인스턴스를 만들지 않았다면 그냥 넘어가면 된다.


Step 6는 태그를 붙이는 것이므로 로드 밸런서의 태그를 넣어주고 

 Step 7에서 리뷰를 거치고 ELB를 Create 해주면 된다.






성공적으로 ELB가 만들어지면 위와같은 그림이 되는데,

이때 ELB에 접그하기 위해서는 아래 Description에 있는 도메인 주소로 접근 하면된다.



출처 : 생활 코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] Auto Scaling - Launch Configuration  (0) 2017.05.17
[AWS] Scale Out - ELB 적용  (0) 2017.05.13
[AWS] Scale Out - ELB 생성  (0) 2017.05.13
[AWS] Scale Out - 흐름과 이론  (0) 2017.05.13
[AWS] Scale Up - 인스턴스 교체  (0) 2017.05.13
[AWS] Scale Up - Elastic IP  (0) 2017.05.13

Scale Out - 흐름과 이론






Scale out이라는 방법론은 여러대의 컴퓨터가 협력해서 동일한 목표를 달성하는,

컴퓨터를 위한 사회를 만드는 것이라고 할 수 있다.

위의 사진은 판도 라는 숲(나무)인데, 각각의 나무들이 아니다.

모든 나무가 같은 뿌리를 공유하며 자라는데, 하나의 나무 라고 할 수 있다.

즉 Scale out은 판도 나무와 같다고 할 수있다.


Scale up으로 규모를 늘리다보면 분명히 한계에 부딪히게 된다.

그 때는 규모를 수직적이 아닌 수평으로 늘리는 Scale Out으로 변경하게 된다.


Scale Out은 복잡하기 때문에 초기에는 반드시 Scale Up을 먼저 고려해주도록 하고

최대한 한계에 도달 했을 때 Scale Out으로 바꿔 주도록 하자.

왜냐하면 Scale Out은 복잡하기 때문에 작은 규모와 수준이라면 Scale Up으로 충분히 커버가 가능하기 때문이다.






Scale out 은 다음과 같이 흘러간다.

적은 사람들이 접속하다가 사용자가 점점 늘어나면서 많은 컴퓨팅 능력을 필요로 한다.

급하게 컴퓨터를 켜서 CPU를 모니터링 하면, 점유율이 100퍼센트에 육박할 경우

이를 해결하기 위한 대책을 내야한다.


먼저 Scale Up으로 서버의 능력을 키우다가 이것마저 한계에 부딪히면

Scale Out으로 해결 해야 한다.


일반적인 웹애플리케이션의 경우 서버에 3개의 프로그램이 깔려있다.


1) 웹서버 : 교환원, 문지기의 역할

2) 데이터베이스 : 가장 중요한 정보를 담고있는 저장소, 금고의 역할

3) 미들웨어: 웹서버와 데이터베이스 사이에 위치하며 웹 애플리케이션의 로직을 담당 하는 역할


따라서 Scale Out으로 컴퓨터를 확장할 경우

이러한 프로그램을 분할 하여 저장할 수 있는 것이다.







예를 들어, 컴퓨터 1대를 사용할 때 3개의 애플리케이션이 모두 1대에 들어있었다면

1대가 추가 될 경우 웹서버, 미들 웨어는 원래 컴퓨터에, 데이터베이스는 다른 컴퓨터에 저장할 수 있다.

사용자 입장에서는 변한것이 없지만 시스템은 조금 복잡해졌다.

그러나  부하를 견딜 수 있으므로 상당히 좋은 장점을 가져간다고 할 수 있다.


조금 더 부하가 늘어난다고 했을 때 컴퓨터를 1대 더 추가한다면

웹서버, 미들 웨어, 데이터베이스를 각각의 컴퓨터에 나눠서 사용할 수도 있을것이다.

여기서 조금 더 발전 시켜 컴퓨터 1대를 더 추가한다면

데이터 베이스를 2개로 나눠 각각의 컴퓨터 저장하고, 

쓰기 작업은 Master DB, 읽기 작업은 Slave DB에서 처리하도록 할 수 있다.


이 상황에서도 컴퓨터가 느리다면 데이터베이스를 더 복제해서 Slave를 늘리고

아직도 데이터 베이스가 느리다면 소위말해 샤딩 이라는 기법을 이용해서 

Master와 slave를 일정 구간 별로 담당하도록 할 수 있다.


데이터베이스는 잘게 쪼개는 것으로 속도를 상승시켰다.

이와 비슷하게 동일한 미들웨어를 여러대의 컴퓨터로 나누어 처리 속도를 상승 시킬 수 있다.







그렇다면 computer 1에 있는 웹서버의 경우는 어떻게 확장을 시킬 수 있을까

사용자가 구글이나 네이버 등의 주소를 주소창에 치고 접속하게 된다면,

컴퓨터는 DNS 서버에 접속해서 이 서버 안에 저장되어있는 도메인에 해당하는 IP로 서버에 연결하게 된다.

즉, DNS 서버는 전화번호 부와 비슷하다고 볼 수있다.


결과적으로 DNS 서버의 설정을 바꾸어서 어떤 사용자가 접속을 하면

위 그림의 Computer 1의 웹서버의 IP를 알려주거나 Computer 8의 IP를 알려주면 되는 것이다.







다른 방법으로 로드 밸런서(Load balancer)를 사용하는 방법이있다.

로드 밸런서는 부하의 균형을 잡아서 골고루 부하가 분산 될수 있도록 도와주는 장치이다.


우리 서버로 접속하는 IP는 각 웹서버가 아니라 로드 밸런서를 가리키는 IP가 된다.

그리고 도메인 역시 웹 서버에 대한 IP를 가리키는 것이 아니라 로드 밸런서를 가리키게 된다.


따라서 로드 밸런서로 들어오면 사용자들에게 제공하는 서비스 부하를 적절히 분산시켜준다.

또한,  computer 8이 죽었다면 이 컴퓨터로 요청을 보내지 않는 기능 등을 제공한다.


이를 위해 AWS 에서는 ELB(Elastic Load Balancer)라는 서비스를 제공한다




출처 : 생활코딩, 아마존 웹 서비스

저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] Scale Out - ELB 적용  (0) 2017.05.13
[AWS] Scale Out - ELB 생성  (0) 2017.05.13
[AWS] Scale Out - 흐름과 이론  (0) 2017.05.13
[AWS] Scale Up - 인스턴스 교체  (0) 2017.05.13
[AWS] Scale Up - Elastic IP  (0) 2017.05.13
[AWS] Scale Up - 스트레스 테스트  (0) 2017.05.13

Scale Up - 인스턴스 교체





본격적으로 인스턴스 교체를 해보자.

먼저, 인스턴스 이미지를 생성해야하는데 이미지를 생성할 인스턴스에서

오른쪽 클릭 -> Image -> create image를 클릭한다.


그러면 위와 같은 이미지의 팝업이 나오는데 모든 항목을 입력해주고 이미지 생성을 클릭한다.

그러면 이미지가 생성되기 시작하는데, 이 때 인스턴스가 정지된다.

따라서 부하가 많이 걸리는 시간대에는 이미지를 생성 하면 안된다.






만약 정상적으로 이미지가 생성되었다면

AMIs 카테고리에 들어가서 방금 생성한 이미지를 확인해 볼 수 있다.






이제 인스턴스 타입을 설정해야하는데 그전에 앞서

변경할 인스턴스를 클릭하고 하단에 Monitor를 보면 CPU상태라던지 

각종 인스턴스에 대한 그래프 정보가 출력된다.


이를 보고 서버 관리자가 적절한 인스턴스 타입을 결정하면 된다.






어떤 타입을 사용할지 결정 되었으면 인스턴스 타입을 변경하기 위해

방금 생성한 이미지 -> 오른쪽 클릭 -> Launch를 클릭한다.


그리고 위와 같이 적절한 타입을 설정한 후 Next 버튼을 눌러 다음 단계로 진행한다.






그리고 리뷰 스텝에서 edit security groups를 눌러 

Security groups를 앞서 생성한 그룹으로 변경해준다.


그 후 패스워드를 지정하고 인스턴스를 생성해준다.






결과적으로 이렇게 새로운 인스턴스가 잘 생성되었다.

원래 wp로 접속하던 사용자들을 wp2로 보내주기 위해서 

Elastic IP를 wp2로 붙여주면 된다.


여기서 주의할점은 Elastic IP은 이미 wp로 할당되었기 때문에

Elastic IP에서 해당 IP를 오른쪽 클릭 -> disassociate address를 눌러 해제시켜준다.

그리고 다시 associate address를 통해 새로 만들어진 인스턴스로 IP를 할당해준다.






Scale Up으로 타입을 변경 해주었을 때 처리속도가 전보도 훨씬 좋아지는 것을 볼 수 있다.

따라서 부하가 적당히 많이 걸릴 때 이미지를 생성해 Scale Up을 해주도록 하자 




출처 : 생활코딩, 아마존 웹 서비스



저작자 표시
신고

'WEB > AWS' 카테고리의 다른 글

[AWS] Scale Out - ELB 생성  (0) 2017.05.13
[AWS] Scale Out - 흐름과 이론  (0) 2017.05.13
[AWS] Scale Up - 인스턴스 교체  (0) 2017.05.13
[AWS] Scale Up - Elastic IP  (0) 2017.05.13
[AWS] Scale Up - 스트레스 테스트  (0) 2017.05.13
[AWS] Scalability  (0) 2017.05.13

+ Recent posts

티스토리 툴바