블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Google 앱앤진에 node.js 애플리케이션을 배포하기


조대협 (http://bcho.tistory.com)

PaaS 서비스란?

PaaS란 Platform as a service의 약자로, 간단하게 설명하면, Linux VM등에 직접 node.js나 기반 환경을 설치하고 디스크와 네트워크 구성, 오토스케일링등의 구성이 필요 없이, 개발자가 작성한 코드만 올려주면, 이 모든 것을 클라우드에서 대행해주는 서비스의 형태이다.

인프라 운영을 위한 별도의 작업이 필요하지 않기 때문에, 숫자가 적은 기업이나 개발에만 집중하고 싶은 기업에는 적절한 모델이라고 볼 수 있다.

근래에 스타트업 비지니스가 발달하고 또한 사용하는 기술 스택들이 복잡해짐에 따라 각각의 기술 스택에 대한 설치나 운영에 대한 인력을 두기보다는 PaaS와 같은 매니지드 서비스를 이용해서 애플리케이션을 개발하는  방식이 스타트업을 중심으로 많이 이루어지고 있다.

구글 클라우드 소개

구글 클라우드는 전세계에 걸쳐 유투브와 구글 검색, 이메일등의 서비스를 하는 구글의 인프라의 경험을 구글 외부의 개발자들에게 개방하기 위해서 개발된 클라우드 서비스이다.

글로벌을 대상으로 서비스를 하던 경험을 기반으로 글로벌 그리고 대용량 서비스에 적절한 특징들을 많이 가지고 있는데, 그 중에서 눈여겨 볼만한것이 네트워크와 빅데이타 서비스이다.

네트워크

구글은 자체 서비스를 위해서 전세계에 걸쳐서 많은 네트워크 망을 가지고 있다. 특히 전세계에 걸쳐 70개 이상의 Pop (Point of Presence)라는 서버들을 보유하고 있는데, 구글 클라우드에서 동작하는 애플리케이션은 클라이언트가 직접 그 데이타 센터의 서버로 인터넷을 통해서 접속하는 것이 아니라, 먼저 가장 가까운 Pop 서버로 연결이 된 후, Pop 서버와 구글 클라우드 데이타 센터간은 구글의 전용 광케이블을 이용해서 접속이 되기 때문에 빠른 네트워크 성능을 보장한다.

예를 들어 한국에서 미국의 서버를 접속하게 되면 일반 인터넷망을 타는 것이 아니라, 가까운 일본에 있는 구글 Pop 서버를 접속한 후에, 구글 광케이블망을 통해서 미국 데이타 센터에 접속하게 된다. 얼마전 7월에 일본-미국을 연결하는 20TB의 구글 클라우드 전용망이 오픈되었기 때문에, 훨씬 더 빠른 접속 속도를 보장받을 수 있다.

이런 특징 때문에, 구글 클라우드를 사용할 경우 여러 국가에 서비스를 제공하는 글로벌 서비스의 경우 이러한 망 가속의 잇점을 볼 수 있다.


또한 내부 네트워크 역시, 1 CPU당 2 GB의 대역폭을 제공한다. (실제 테스트해보면 1.6~1.8 GB정도가 나온다) 최대 8 CPU에 16 GB의 대역폭 까지 지원하기 때문에, 내부 노드간 연산이 많거나 또는 노드간 통신이 많은 클러스터링 솔루션을 사용할때 별도의 비용을 지불하지 않고도 넉넉한 네트워크 대역폭 사용이 가능하다.

빅데이타

구글은 사람들에게 알려진바와 같이 데이타를 기반으로 한 서비스에 강하며 특히 빅데이타를 처리하는 능력이 뛰어난 회사이다. 이러한 빅데이타 처리 기술이 클라우드 서비스로 제공되는데, 알파고와 같은 예측 통계학적인 머신러닝이나 딥러닝 이외에도, 분석 통계학적인 데이타 분석 서비스가 많은데 그중에서 특출난 서비스들로 Pub/Sub, Dataflow, BigQuery 등이 있다.

Pub/Sub은 전달 보장이 가능한 대용량 큐 시스템이다. 오픈소스 Kafka와 같은 서비스라고 보면 되고, 이러한 분산큐를 직접 깔아서 운영하기 어려운 사람들에게 쉽게 대용량 큐 서비스를 제공한다.

Dataflow는 스트리밍 및 배치 분석 시스템인데, Spark Streaming이나 Apache Flink와 같은 스트리밍 프레임웍과 유사하다고 보면된다. 윈도우,트리거,워터마크와 같은 스트리밍 서비스에서 발전된 개념을 이미 내장하고 있다.

마지막으로 BigQuery는 대용량 데이타 저장/분석 시스템으로 SQL과 같은 문법으로 데이타 분석이 가능하며, 데이타 저장 비용은 구글에서도 가장 싸다는 데이타 저장소인 CloudStorage 보다 저렴하며, 1000억개, 4TB의 레코드에 대해서 like 검색을 하는데 소요되는 시간이 불과 30여초로, 빠른 성능을 보장한다. (이 30초 동안에 CPU가 수천개, DISK역시 수천개가 사용된다.)


구글 클라우드 앱앤진

오늘 살펴볼 서비스는 구글 클라우드 중에서도 앱앤진이라는 PaaS 서비스이다. 구글은 처음 클라우드 서비스를 시작할때 PaaS 기반의 서비스를 제공하였고, 내부적으로도 PaaS 서비스를 오랫동안 제공해온 만큼, 진보된 형태의 PaaS 플랫폼을 가지고 있다.

그중에서 이번에는 새롭게 앱앤진 Flex environment 라는 새로운 서비스를 소개 하였다.

Flex environment에는 기존의 Java,PHP뿐 아니라, 요즘 스타트업등에서 많이 사용되는 Python, Ruby on rails 그리고 node.js를 지원한다.

그리고 재미있는 점 중의 하나는 일반적인 PaaS가 VM에 대한 로그인 (telnet 이나 SSH)를 지원하지 않는데 반하여, Flex environment 는 SSH 로그인을 제공함으로써, 고급 사용자들에게 많은 기능과 디버깅에 있어서 편의성을 제공한다.

계정 가입

자아 그러면 이제, 구글 앱앤진 Flex environment를 이용하여, node.js 애플리케이션을 배포해보도록 하자.

먼저 GCP 클라우드를 사용하기 위해서는 구글 계정에 가입한다. 기존에 gmail 계정이 있으면 gmail 계정을 사용하면 된다. http://www.google.com/cloud 로 가서, 좌측 상당에 Try it Free 버튼을 눌러서 구글 클라우드에 가입한다.




다음 콘솔에서 상단의 Google Cloud Platform 을 누르면 좌측에 메뉴가 나타나는데, 메뉴 중에서 “결제" 메뉴를 선택한후 결제 계정 추가를 통해서 개인 신용 카드 정보를 등록한다.


개인 신용 카드 정보를 등록해야 모든 서비스를 제한 없이 사용할 수 있다.  단 Trial의 경우 자동으로 한달간 300$의 비용을 사용할 수 있는 크레딧이 자동으로 등록되니, 이 범위를 넘지 않으면 자동으로 결제가 되는 일이 없으니 크게 걱정할 필요는 없다. (사용자가 Plan을 올려야 실제 카드에서 결재가 된다. 그전에는 사용자의 카드에서 결재가 되지 않으니 걱정하지 마시기를)


프로젝트 생성

계정 생성 및 결제 계정 세팅이 끝났으면 프로젝트를 생성한다.

프로젝트는 VM이나 네트워크 자원, SQL등 클라우드 내의 자원을 묶어서 관리하는 하나의 집합이다. 여러 사람이 하나의 클라우드를 사용할때 이렇게 프로젝트를 별도로 만들어서 별도로 과금을 하거나 각 시스템이나 팀별로 프로젝트를 나눠서 정의하면 관리하기가 용이하다.


화면 우측 상단에서 프로젝트 생성 메뉴를  선택하여 프로젝트를 생성한다.



프로젝트 생성 버튼을 누르면 아래와 같이 프로젝트 명을 입력 받는 창이 나온다. 여기에 프로젝트명을 넣으면 된다.


node.js 애플리케이션 준비

클라우드 프로젝트가 준비되었으면, 이제 구글 클라우드에 배포할 node.js 애플리케이션을 준비해보자.

Node.js 애플리케이션은 Express 프레임웍을 이용한 간단한 웹 애플리케이션을 작성해서 배포하도록 한다.

기본적으로 nodejs와 npm이 설치되어 있다고 가정한다. 이 글에서는 node.js 4.4.4 버전과 npm 2.15.1 버전을 기준으로 작성하였다.

Express generator 설치

Express 프로젝트는 Express 프로젝트 고유의 디렉토리 구조와 의존되는 파일들을 가지고 있다. 그래서 프로젝트를 생성하려면 Express generator가 필요하다. Express generator가 Express 프로젝트에 맞는 프로젝트 구조를 생성해주는데, Express generator를 설치하려면 아래 그림과 같이

% npm install express-generator -g

명령을 사용하면 설치가 된다.



프로젝트 생성

Express generator 설치가 끝났으면 이제, express 프로젝트를 생성해보자.

다음 명령어를 이용하여 helloappengine이라는 Express 프로젝트를 생성한다.

% express --session --ejs --css stylus helloappengine




Express 프로젝트 및 Express 프레임웍에 대해서는 http://bcho.tistory.com/887 http://bcho.tistory.com/888 글을 참고하기 바란다.

코드 수정

생성된 코드에서  ~/routes/index.js 파일을 다음과 같이 수정한다.


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

 res.render('index', { title: 'Hello Appengine' });

 console.log('Hello Appengine');

});


module.exports = router;


의존성 모듈 설치와 node.js 런타임 버전 정의

Express 애플리케이션 개발이 다 끝났다. Express 애플리케이션을 실행하려면, Express 프로젝트에 필요한 모듈들을 설치해야 하는데, 의존 모듈들은 ~/package.json에 이미 자동으로 생성되어 있다.

이 파일을 다음과 같이 수정한다.

“engines”라는 항목에 node.js의 버전을 아래와 같이 명기하는데, 이는 구글 앱앤진이 이 애플리케이션을 수행할때 어느 버전의 node.js를 가지고 수행을 할지를 지정한다.


{

 "name": "helloappengine",

 "version": "0.0.0",

 "private": true,

 "scripts": {

   "start": "node ./bin/www"

 },

 "engines":{

    "node":"4.4.4"

 },

 "dependencies": {

   "body-parser": "~1.15.1",

   "cookie-parser": "~1.4.3",

   "debug": "~2.2.0",

   "ejs": "~2.4.1",

   "express": "~4.13.4",

   "morgan": "~1.7.0",

   "serve-favicon": "~2.3.0",

   "stylus": "0.54.5"

 }

}




이 의존성 모듈 설치는 package.json 파일이 있는 디렉토리에서 아래와 같이

% npm install

명령어만 실행해주면 자동으로 설치된다.


테스트

샘플 애플리케이션 개발 및, 이를 실행하기 위한 환경 설정이 모두 끝났다.

그러면 이제 샘플 애플리케이션을 로컬에서 실행해보자.

실행은 ~/ 디렉토리에서 다음과 같은 명령을 실행하면된다.

% node ./bin/www



실행한 후, 결과를 확인하려면 http://localhost:3000 번으로 접속하면 아래와 같은 결과가 나오는 것을 확인할 수 있다.



구글 앱앤진으로 배포 준비

애플리케이션 개발 및 테스트가 끝났으면 이제 구글 앱앤진으로 이 애플리케이션을 배포해보자.

app.yaml 파일 작성

구글 앱앤진 Flex environment 로 애플리케이션을 배포하기 위해서는 애플리케이션에 대한 기본 정보를 app.yaml에 정의해야 한다. 이 파일은 배포할 node.js 애플리케이션이 있는 ~/ 디렉토리에 위치 시킨다.

runtime은 어떤 언어 (node.js , ruby 등)을 지정하고, VM으로 실행할지를 vm:true 로 정의한다.


runtime: nodejs
vm: true


Google Cloud SDK 설치

다음으로 배포를 하려면, gcloud라는 명령을 사용해야 하는데, 이 명령어는 Google Cloud SDK를 설치해야 사용할 수 있다. Google Cloud SDK는 https://cloud.google.com/sdk/downloads 에서 다운 받아서 설치한다.

Google cloud SDK 설정하기

Google cloud SDK 설치가 끝났으면, 혹시 google cloud SDK가 업데이트 되었을 수 있으니, 다음 명령어를 이용하여 최신 SDK로 업데이트 한다. (알파,베타 버전과 같은 신 기능이 들어가면 업데이트가 된다.)


% gcloud component update


라는 명령어를 수행하면 다음과 같이 업데이트 된 내용이 나오면서 업데이트 를 할 것인지 물어보고 “Y”를 선택하면 자동으로 Google Cloud SDK를 업데이트 한다.



Google Cloud SDK 배포가 끝났으면 gcloud 명령을 이용하기 위해서 초기화 작업을 해야 한다. 초기화 작업은 gcloud 명령을 사용했을때, 내 구글 클라우드 프로젝트 중 어느 프로젝트에 명령을 내릴 것인지, 그리고 어떠한 구글 계정을 사용할것인지 그리고 명령을 내릴때 어떤 리전을 디폴트로 해서 명령을 내릴것인지를 정하는 것이다. 사용자에 따라서 여러개의 프로젝트를 가질 수 도 있고, 또한 관리 목적상 여러개의 클라우드 계정을 가질 수 도 있기 때문이다.

초기화 방법은 다음과 같이 명령어를 실행하면 된다

% gcloud init

이 명령을 사용하면, 앞에서 언급한 바와 같이, gcloud 명령을 내릴 때 사용할 계정과, 디폴트 프로젝트 그리고, 리전을 선택하게 된다.


이제 배포를 위한 모든 준비가 끝났다.

구글 앱앤진으로 배포

이제 배포를 해보자. 배포는 매우매우 쉽다.

앞서 작성한 Express 애플리케이션이 있는 ~/ 디렉토리에 가서 다음 명령어를 수행하면 된다.

% gcloud app deploy

명령을 실행하면 다음과 같이 node.js 애플리케이션이 배포 되는 과정을 볼 수 있다.

배포는 수분이 소요된다. (내부적으로는 Docker 컨테이너를 이용하여 배포가 된다.)

서비스 기동확인

배포가 완료되면 자동으로 서비스가 기동이 된다.

서비스 기동 확인은 http:{프로젝트명}.appspot.com 으로 자동으로 서비스가 뜨게 된다.

해당 URL을 접속해보자. 여기서는 프로젝트명이 “useful-hour-138023”이다.


서비스가 정상적으로 기동 됨을 확인하였다.

모니터링

구글 클라우드 콘솔에 들어가 보면 현재 기동중인 node.js 앱을 확인할 수 있다.

콘솔에서 “App Engine”을 선택하면 다음과 같은 화면이 나온다.



아래 Instances 부분을 보면 Flexible 이라는 이름으로 현재 2개의 인스턴스가 기동되고 있고, 평균 QPS (Query Per Second : 초당 처리량)이 10.898 인것을 확인할 수 있다.


매니지드 서비스이기 때문에, 부하가 늘어나면 자동으로 인스턴스를 추가하고 줄어들면 자동으로 삭제하여 부하에 탄력적으로 대응을 자동으로 해준다.


로그 모니터링은 클라우드 콘솔에서 “Logging”이라는 메뉴를 선택하면 아래와 같은 화면이 나온다.


앱앤진 관련 request log 및 기타 로그들이 다 나오는데, 앞서 샘플코드에서 console.log(“Hello Appengine”) 명령어를 이용하여 Stdout으로 “Hello Appengine”이라는 문자열을 출력하도록 하였기 때문에, 이 문자열이 제대로 출력되었는지를 확인해보자.

App Engine 을 선택하고, 다음 “stdout”을 선택하면 위와 같이 앱앤진의 Stdout으로 출력한 로그들만 볼 수 있는데, 위와 같이 “Hello Appengine” 문자열이 출력된것을 확인할 수 있다.

수정 및 재 배포

그러면 다음으로 애플리케이션을 수정해서 배포해보자. routes/index.js를 다음과 같이 수정해보자


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

 res.render('index', { title: 'Hello Appengine is updated' });

 console.log('Hello Appengine is updated');

});


module.exports = router;



코드 수정이 끝났으면 배포를 해보자. 재 배포 역시 간단하게

%gcloud app deploy

명령어를 수행하면 간단하게 배포가 된다.

배포가 완료된 후 URL로 들어가서 확인을 해보면


애플리케이션이 업데이트 된것을 확인할 수 있다.

롤백

앱앤진의 장점 중에 하나가 배포도 쉽지만, 롤백도 매우 쉽게 가능하다는 것이다.

클라우드 콘솔에서 App Engine을 선택하고, 아래와 같이 Versions라는 메뉴를 선택하면 아래와 같은 그림을 볼 수 있다.




현재 두개의 버전이 배포되어 있고, 위의 최신 버전에 Traffic Allocation이 100%로 되어 있는 것을 확인할 수 있다. 이는 새로 배포된 버전으로만 트래픽이 100% 가고 있다는 의미인데, 롤백은 트래픽을 예전 버전으로 라우팅 해주고, 새버전의 서비스를 정지 시키면 된다.


아래 그림과 같이 예전 버전을 선택한 후에, 상단 메뉴에서 “Migrate Traffic”을 선택한다.



그러면 아래와 같이 트래픽이 이전 버전으로 100% 가고 있음을 확인할 수 있다.

그리고 나서 새 버전을 선택한 후 상단의 STOP 버튼을 눌러주면 아래 그림과 같이 새버전의 상태가 Serving 에서 Stopped로 변경된것을 확인할 수 있다.




예전 버전으로 롤백이 잘 되었는지를 확인해보자.

아래 그림처럼 예전 버전으로 롤백이 되었음을 확인할 수 있다.



버전별로 트래픽 분산하기

앱앤진의 장점 중의 하나가 여러 버전을 유지할 수 있고, 버전간에 트래픽을 자유롭게 조절할 수 있다. 예를 들어서 v1으로 90%, v2로 10% 의 트래픽을 보내는 것등이 가능하다.


이렇게 트래픽을 조절하는 것은 크게 2가지 방법으로 활용이 가능한데, 서버단의 A/B 테스팅과 카날리 테스팅이다.

A/B 테스팅은 사용자를 두개 이상의 집단으로 나눈후, 기능 A,B 에 대한 반응을 본 후, 반응이 좋은 기능을 선택하는 방식으로, 모바일 클라이언트단에서 많이 사용되고, 서버단에는 구현이 쉽지 않았는데, 트래픽을 버전별로 나눠서 주는 기능을 사용하면 손쉽게 A/B 테스팅을 수행할 수 있다.


다음으로 카날리 테스트는 옛날에 광부들이 광산에 들어갈때 카나리아 새를 데리고 들어가서 유독가스가 나오면 카나리아 새가 먼저 죽는 것을 보고 위험을 감지하는 방법에서 유래된것으로 서버 배포에서는 전체 사용자를 대상으로 새 버전을 배포하는 것이 아니라 1~2%의 사용자에게 배포해보고 문제가 없으면 전체 사용자에게 배포하는 개념으로, 마찬가지로 v2에 1~2%의 트래픽만 할당하고 나머지 98~99%는 v1에 할당하는 방식으로, 해서 v2에 대한 안정성 검증을 한 후에, v2를 전체 배포 하는데 활용할 수 있다.


버전간 트래픽 비율을 지정하는 방법은 클라우드 콘솔의 앱앤진 메뉴에서 Version을 선택하고 상단 메뉴에서 → 가 두개 겹쳐진 아이콘 (맨 우측)

를 선택하면 아래와 같이 Split traffic 이라는 메뉴가 나온다.

여기서 1개 이상의 Version을 추가한 후에, 각 버전으로 보낼 트래픽의 비중 (%)을 정의한다.






위의 예제에서는 xxx4403 버전으로 30%, xxxx3136 버전으로 70%의 트래픽을 보내도록 하였다.

설정을 완료한 후에 SAVE를 누르고, 다시 Version 부분을 보면, 수분 있다가 아래 그림과 같이 xxxx3136 버전에 70% 트래픽이 xxx4403 버전으로 가게 된다.


부가 기능에 대해서

구글 클라우드에서 앱앤진만 쓸 수 있는 몇가지 좋은 서비스 들이 있는데, 다음과 같다.

매니지드 memcached

앱앤진에서는 구글 매니지드 memcached 서비스를 사용할 수 있다 별도의 설정 없이 바로 사용이 가능하며, 최대 100GB 까지 사용이 가능하다. (100GB 이상도 요청하면 사용이 가능) Shared memcached의 경우에는 별도의 비용없이 일반적인 캐쉬로 사용이 가능하지만, 용량이나 성능등이 보장이 되지 않으니 주의가 필요하다.

https://cloud.google.com/appengine/docs/python/memcache/

보안 스캐닝 (Security Scanning)

매우 유용한 기능중의 하나가 보안 스캐닝 기능이다 앱앤진 메뉴에서 Security Scanning이라는 메뉴를 선택하면 앱앤진으로 개발한 웹 사이트에 대한 보안 스캐닝을 할 수 있는데, 한번만 스캐닝할 수 도 있고 자동 스케쥴 방식으로, 주기적으로 스캐닝 하는 것도 가능하다.


보안 정책이 수시로 업데이트 되기 때문에, 정기적으로 보안 스캔을 하는 것을 권장한다.

텍스트 검색 (Search)

node.js에는 지원하지 않지만, Python,Java,PHP,Go (앱앤진 Standard environment)에서만 지원되는 기능중 하나는 구글 검색 엔진과 같은 검색 엔진을 지원한다. 텍스트 검색 HTML 그리고 GEO_POINT (위/경도 기반 검색)이 가능하다.

https://cloud.google.com/appengine/docs/java/search/?hl=en_US

결론

지금까지 간략하게나마 구글 클라우드에 대한 소개, 앱앤진에 대한 개념 및, 간단한 node.js express 애플리케이션을 작성해서 배포해봤다. 다음글은 앱앤진에 대한 조금 더 구체적인 환경에 대해서 알아보도록 하겠다.


Heroku에서 Metrics 메뉴를 이용하여 애플리케이션 모니터링 하기


조대협 (http://bcho.tistory.com)


heroku에서는 Metrics이라는 메뉴를 통해서 기본적인 시스템 모니터링을 지원한다. 기본 지원 항목으로는

응답시간 (Response time), 메모리 사용률 (Memory Usage), 분당 처리량 (Throughput-TPM), CPU 사용률 (Dyno Load)을 볼 수 있다. 이 항목들은 Heroku 대쉬보드에서 모니터링하고자 하는 애플리케이션을 선택한 후, 상단의 Metrics라는 탭을 선택하면 된다.  

 

아래는 Metrics 메뉴를 통해서 helloherokuterry 애플리케이션의 주요 지표를 모니터링 한 화면이다.



한가지 주의할점은 Metrics 모니터링 기능은 무료 dyno로는 사용이 불가능하며 최소 standard-1x dyno 부터 지원이 된다.

Heroku에서 newrelic을 이용한 node.js 애플리케이션 모니터링 (APM)


조대협 (http://bcho.tistory.com)


Heroku에서 node.js 애플리케이션에 대한 모니터링을 살펴보자. 애플리케이션의 모니터링은 모니터링 분야에서 APM (Application Performance Monitoring)이라는 분야로, 애플리케이션에서 어떤 API 들이 호출이 되었는지, 각 로직별 응답 시간등을 추적할 수 있다. 한국에서 유명한 APM으로는 제니퍼가 있다.

Heroku에서 사용할 수 있는 APM은 여러가지가 있지만 여기서는 newrelic이라는 제품을 소개한다.

Newrelicheroku 뿐 아니라, 모니터링 시장에서 매우 유명한 제품으로 APM 기능뿐만 아니라, 서버 인프라에 대한 모니터링등 상당히 많은 기능을 제공한다.

Heroku에는 그러한 기능을 제공하지는 않고 newrelicAPM 기능만을 제공한다.

 

newrelic add-on 설치


newrelic add-on부터 설치한다. 설치 명령어는 다음과 같다.


%heroku addons:create newrelic:{상품명}


상품명은 무료 상품을 사용할 예정이기 때문에, 상품명은 ‘wayne’를 선택한다. Heroku addons 명령어를 이용해서 다음과 같이 addons를 추가 한다.



Figure 7 newrelic addon 설치

 

상품 모델은 https://elements.heroku.com/addons/newrelic#plan_selector 를 참고하면 된다.

3 dyno 모니터링에 월 49$, 300 dyno에 월 4499% 까지 다양한 상품 모델이 있다. 가격은 다른 상품에 비해서 싼편은 아니지만, APM 쪽에서 그만큼 많은 기능을 제공한다.

 

newrelic 환경 변수 설정


다음으로 추가적인 환경 설정이 필요하다. 다음과 같이 heroku config 명령어를 이용해서 다음 환경변수들을 설정한다.

 

환경변수명

설정값

설명

NEW_RELIC_APP

‘helloherokuterry’

newrelic 을 적용한 heroku 애플리케이션 이름. 여기서는  helloherokuterry 앱을 사용하기 때문에, helloherokuterry 를 사용한다

NEW_RELIC_NO_CONFIG_FILE

‘true’

newrelicnode.js에서 사용하기 위해서 원래는 newrelic.js 에 환경변수를 설정하는데, herokunewrelic에서 이 옵션을 설정하면 newrelic.js 환경에서 환경변수를 읽는데, newrelic.js를 사용하지 않고, heroku config 를 이용하여 환경 변수를 설정할 경우, 이 옵션을 ‘true’로 세팅한다.

Figure 8 newrelic 환경 변수 목록

 

다음은 heroku config 명령을 이용해서 위의 두 환경 변수를 설정한 화면이다.



Figure 9 newrelic 환경 변수 설정 화면

 

node.js 애플리케이션에 에이전트 코드 삽입


환경 변수 설정이 끝났으면, newrelic 에서 node.js 애플리케이션의 실행 정보를 수집할 수 있도록 코드를 삽입해야 한다.

에이전트는 ‘newrelic’ node.js 모듈을 설치해서 app.js 에서 로딩 하면 된다.

package.json에서 다음과 같이 newrelic 모듈에 대한 의존성을 추가한다.


{

  "name": "helloheroku",

  "version": "0.0.0",

  "private": true,

  "scripts": {

    "start": "node ./bin/www"

  },

  "dependencies": {

    "body-parser": "~1.13.2",

    "cookie-parser": "~1.3.5",

    "debug": "~2.2.0",

    "ejs": "~2.3.3",

    "express": "~4.13.1",

    "morgan": "~1.6.1",

    "serve-favicon": "~2.3.0",

    "stylus": "0.42.3",

    "newrelic" : "~1.25.5"

  }

}

Figure 10 package.json  newrelic 의존성 추가

 

다음으로 이 모듈을 애플리케이션에서 로딩해야 하는데, app.js 맨 윗줄에 아래와 같이 require(‘newrelic’) 코드를 삽입한다.

 

require('newrelic');

 

var express = require('express');

var path = require('path');

var favicon = require('serve-favicon');

Figure 11 app.jsnewrelic 에이전트 로딩 코드를 삽입

 

코드가 수정되었으면 heroku에 배포한다.

 

Newrelic을 이용한 모니터링


이제 모든 준비가 끝났다. 애플리케이션을 기동하고 heroku 대쉬보드로 들어가 보자



Figure 12 애플리케이션 선택

 

그림과 같이 대쉬보드에서 애플리케이션을 선택하면, 다음과 같이 newrelic addon이 추가된것을 확인할 수 있다.



Figure 13 newrelic APM addon이 추가된 화면

 

newrelic을 클릭해보면, 설정이 제대로 되었다면 다음과 같은 화면이 나올것이다.



Figure 14 newrelic 첫번째 접속 화면

 

상단에서 APM화면을 눌러서 APM 화면으로 들어가면 아래와 같이 애플리케이션 리스트들이 나오고, 아까 등록한 helloherokuterry 애플리케이션이 나온다.



Figure 15 newrelic에서 애플리케이션 선택

 

해당 애플리케이션을 클릭하면 다음과 같이 애플리케이션에 대한 상세 정보가 나온다.



Figure 16 newrelic APM 모니터링 화면

 

전체 응답시간(Web transation time), 초당 처리량 (Throughput), 주로 호출되는 웹 트렌젝션 목록등을 볼 수 있다.

그이에도 각 인스턴스에 대한 디테일이나 개별 트렌젝션에 대한 추적, 에러등에 대해서도 추적이 가능하다.

Heroku에서 logentries를 이용하여 node.js 로그 모니터링 하기


조대협 (http://bcho.tistory.com)

 

Heroku에서 제공하는 로깅은 heroku logs –tail 명령을 이용해서 모니터링 할 수 있는데, 이 로그의 경우 최대 1500줄만 저장을 지원한다. 실제 운영 환경에서 1500줄의 로그란 부족해도 많이 부족한 양이다. 그래서 추가적인 서비스를 이용하는 것이 좋은데, 많은 로깅 서비스가 있지만, 간단하게 사용할 수 있는 로깅 서비스로 logentries 라는 서비스가 있다.

 



Figure 1 http://www.logentries.com

 

무료로 사용이 가능하고, 무료 사용시 최대 7일간의 로그를 저장해주고, 일 최대 33M 까지 로그를 저장할 수 있다.

가장 저렴한 Entry 플랜은 한달에 9$로 일 133M 로그를 최대 7일간 저장하고, 가장 비싼 Platium 플랜은 월 1399$로 일 최대 40GB의 로그를 최대 7일간 저장할 수 있게 해준다. (에러나 일반적인 시스템 로그라면, 왠만한 시스템이면 40GB정도면 충분하지 않나 싶다.)

 

그러면 앞서 작성하여 heroku에 배포한 node.js 애플리케이션에 이 logentires를 적용해 보자.

적용은 매우 간단하다. 명령창에서 간단하게 다음 명령을 실행하자

heroku addons:create logentries

 

명령을 실행하면 다음과 같이 logentries 가 설치되었다고 나온다.



Figure 2 logentries 설치

 

설치가 완료되었으면 이제 사용을 해보자. Heroku  대쉬 보드로 접속해서, 생성한 애플리케이션을 선택한다.



Figure 3 heroku dashboard에서 애플리케이션 선택

 

애플리케이션을 클릭해서 들어가면 하단 add-on 리스트에 logentries가 아래 그림과 같이 활성화가 되어 있는 것을 확인할 수 있다.



Figure 4 heroku 애플리케이션에서 add-onsLogentries가 설치된 화면

 

logentries를 클릭해서 들어가면, logentries를 이용한 로그 모니터링 화면이 나온다.

아래 그림과 같이 좌측에 “heroku”라는 Log set이 나오는데, 이를 클릭하고, 우측 상단에 “Live tail” 이라는 버튼을 누르면 현재 node.js의 로그를 실시간으로 보여준다. 실제로 해보면 heroku logs –tail 보다 약 1초 정도 지연이 발생한다.



Figure 5 logentries를 이용한 실시간 로그 모니터링

 

다음 화면은 node.js의 로그를 heroku logs –tail로 모니터링한 화면으로 위의 logentrieslive tail과 동일함을 확인할 수 있다.



Figure 6 heroku logs를 이용한 실시간 로그 모니터링

 

heroku 기본 로깅 시스템에 비해서 더 많은 로그를 볼 수 있는 것은 물론이고, 로그에 대한 검색이 가능하고, 특정 데이타를 기반으로 한 그래프등 다양한 기능을 지원한다.

Heroku 클라우드에 node.js 애플리이션을 배포하기


조대협 (http://bcho.tistory.com)



가장 빠르게 이해하는 방법은 직접 해보는 것이다. Heorku 클라우드에 대한 이해를 위해서 express를 이용해 구현된 node.js 애플리케이션을 직접 배포해서 실행해보자

이 예제는 node.js 4.3.1 버전과 express 4.13.4 버전을 기준으로 작성되었다.


Heroku 가입

Heroku사용을 위해서 Heroku계정을 만들자. http://www.heroku.com 에 접속해서 Sign up 메뉴로 들어가면, 간단하게 이름과 이메일 정도의 정보만 넣으면 간단하게 계정을 만들 수 있다.



Figure 1 Heroku 가입 화면


다른 클라우드의 경우 향후 유료 사용을 위해서 회원 가입시 처음부터 신용카드 정보를 요구 하는 경우가 있어서 신용카드가 없는 학생등은 가입이 안되는 경우가 있지만, Heroku의 경우 별다른 부담없이 무료로 계정을 생성해서 사용할 수 있다. 지금부터 진행할 예제는 무료 계정에서 한개의 웹 서버를 기동하여 node.js 애플리케이션을 기동하는 예제로 별도의 비용이 필요없다.


계정이 생성되었으면 Heroku 웹 콘솔에 로그인해보자




Figure 2 Heroku 대쉬 보드


첫 대쉬보드에서는 각 개발플랫폼에서 개발을 시작하는 방법에 대한 가이드를 제공한다.


node.js 애플리케이션 준비


Heroku 계정이 준비되었으면, Heroku에 배포할 node.js 애플리케이션을 준비해보자. 

“Hello Heroku”를 출력하는 간단한 node.js 애플리케이션을 작성하자.

다음과 같이 express generator를 이용해서 node.js 애플리케이션을 생성한다.


% express -–session --ejs --css stylus helloheroku

% cd helloheroku

% npm install


애플리케이션을 설치한 후에, 애플리케이션 디렉토리로 들어가서 npm install 명령을 이용하여, 애플리케이션에서 사용되는 의존성을 가지고 있는 모듈들을 설치한다.


다음으로 /routes/index.js를 다음과 같이 수정한다.


var express = require('express');

var router = express.Router();


/* GET home page. */

router.get('/', function(req, res, next) {

  res.render('index', { title: 'Heroku' });

  console.log(' hello heroku ');

});


module.exports = router;


Heroku에 배포하는 node.js 애플리케이션을 개발할때, 주의할점 중의 하나가 package.json이다.

보통 로컬 개발환경에 npm 패키지들이 이미 설치 되어 있는 경우 실행이 제대로 되고, 문제가 없기 때문에, package.json에 필요한 모듈에 대한 정의를 빼먹는 경우가 많다. Heroku에 애플리케이션을 배포할때는 의존 패키지들이 설치되어 있지 않기 때문에 이를 설치 해야 하는데,  Heroku는 자동으로 package.json에 정의된 npm 모듈들을 설치해 준다. 반드시 배포전에 package.json에 필요한 모듈들이 제대로 정의되었는지를 확인해보자


소스코드가 준비되었으면 Procfile 이라는 것을 준비해야 한다. 위에서 만든 애플리케이션의 루트”/” 디렉토리에 다음과 같은 내용으로 Procfile을 작성하자.


web: node ./bin/www


Procfile은 애플리케이션을 Heorku에 배포 해서 실행할때, Heroku 클라우드가 맨 처음 실행하는 명령어를 지정하는 파일이다. 보통 애플리케이션을 기동하기 위한 명령어를 기술한다.

앞서 작성한 Procfile을 보면, “web:” 이라고 기술하였는데, 배포하고자 하는 애플리케이션이 웹 애플리케이션임을 정의한다. web 타입의 애플리케이션만 Heroku의 내부 HTTP 로드밸런서에 연결이 되서 웹 요청을 받을 수 있다.

다음으로 “node ./bin/www” 라고 지정하였는데, node.js 애플리케이션을 기동하기 위한 명령어이다. 우리가 작성한 애플리케이션은 express애플리케이션으로 기동 로직이 ./bin/www 에 들어 있다.


추후에 추가로 설명하겠지만, node.js는 모니터링등을 위해서 forever나 pm2와 같은 추가적인 도구를 이용해서 기동을 하는 경우가 있다. 실행을 할때 forever ./bin/www 식으로 실행하는데, Heroku에서 실행하려면 다음과 같이 실행하면 된다.


web: ./node_modules/.bin/forever ./bin/www


이제 배포를 위한 node.js 애플리케이션 준비가 끝났다. Heorku에 배포해보자.


Heroku 툴벳 설치


계정이 준비되고 애플리케이션 개발이 끝났으면, Heroku에 접속해서 배포를 진행해야 한다. Heroku는 툴벳이라는 커멘트라인 인터페이스 (CLI : Command line interface)를 이용해서 사용한다. 

툴벳은 https://toolbelt.heroku.com/ 에서 다운로드 받을 수 있다.




Figure 3 Heroku 툴벳 다운로드 페이지


툴벳을 인스톨했으면 실행해보자. 프롬프트 상에서 

%heroku 

명령어를 수행하면 간단한 사용법이 나온다.

이 툴벳을 통해서 Heroku에 명령을 내리기 위해서는 자신의 계정으로 로그인을 해야 한다. 로그인은 “heroku login”이라는 명령을 사용해서, Heroku 가입시 생성한 계정으로 로그인을 하면 된다.




Figure 4 툴벳에서 Heroku 로그인


Heroku 배포 준비


로그인이 끝났으면, Heroku내에 앱을 생성한다. Heroku의 앱은 애플리케이션 단위로, 이 앱단위로 배포를 하고 운영을 하게 된다. 

앱 생성 방법은 다음과 같다.


%heroku app:create {앱이름}


이 예제에서는 helloherokuterry 라는 이름의 앱을 생성할것이다.

이 앱 이름은 Heroku 클라우드에 걸쳐서 유일한 이름으로 사용을 해야 하기 때문에, 위의 이름으로 앱을 생성하고자 하면 이미 저자가 해당 이름을 사용하고 있기 때문에, 아마도 에러가 날것이다. 다른 적절한 이름을 이용해서 앱을 생성하자


아래는 helloherokuterry 라는 이름의 앱을 생성하고, “heroku apps” 를 이용하여 현재 생성된 앱 리스트를 확인해서 helloherokuterry 라는 앱이 제대로 생성이 되었는지 확인 하는 화면이다.




Figure 5 Heroku에 애플리케이션을 생성하는 화면


만약에 잘못 앱을 생성하였으면 다음 명령어를 이용해서 앱을 삭제할 수 있다.


%heroku app:delete {앱이름}


앱이 생성되었으면, 작성한 애플리케이션을 배포해야 하는데, heroku의 코드 배포는 git 소스코드 관리 시스템을 사용한다.

앱 디렉토리에서 git 리포지토리를 생성한다.

%git init .

다음, 작성한 애플리케이션들을 git에 추가한다.

%git add *

추가된 애플리케이션 코드들을 commit 한다.

%git commit


이제 로컬 git 리파지토리에 애플리케이션 코드들이 저장되었다. 이 코드들을 Heroku에 전송하자.

git에 Heroku 클라우드 상의 git 저장소를 리모트 저장소로 지정해야 한다.

Heroku의 git 저장소를 리모트 저장소로 지정하는 방법은 다음과 같다. 


%heroku git:remote -a {앱이름}


여기서는 애플리케이션의 이름이 helloherokuterry이기 때문에 다음과 같이 리모트 저장소를 추가하겠다.

% heroku git:remote –a helloherokuterry


heroku의 git 리파지토리가 리모트 저장소로 지정되었다.

아래 명령어를 이용해서 로컬에 저장된 코드를 heroku로 올려보자


%git push heroku master


명령어를 실행하면 소스코드를 Heroku에 배포 하는 것을 확인할 수 있다.




Figure 6 git를 이용하여 Heroku에 앱을 배포하는 화면


배포는 단순하게 소스 코드만을 올리는 것이 아니라 올라간 소스코드를 확인해서, package.json에 지정된 의존성 있는 모듈들을 설치 한다. 아울러 환경변수를 세팅한다.

Heroku의 경우 node.js에 대해서 디폴트 환경 변수를 정의하는데

NPM과 node.js에 대한 환경 변수를 다음과 같이 설정한다. 모드를 운영 모드로 설정하는 부분이다.


remote:        NPM_CONFIG_LOGLEVEL=error

remote:        NPM_CONFIG_PRODUCTION=true

remote:        NODE_ENV=production

remote:        NODE_MODULES_CACHE=true


배포에서 git를 사용하였는데, 혹시나 git에 대해 생소한 분들을 위해서 간략하게 배포 흐름을 정리하고 넘어가자.  




Figure 7 git를 이용한 Heroku 배포 개념도


개발환경에서 작성된 소스코드는 git의 로컬 저장소 (Local repository)로 저장되기전에 git add명령어를 이용하여 스테이징 단계 (stage)로 이동된다. 소스를 저장소에 저장하기 전 단계로, 전체 코드 중에서 어떤 파일들을 저장할지를 선택하고 검토하는 일종의 중간단계이다.

스테이징이 끝나면, git commit 명령을 이용하여 로컬 저장소 즉 내 PC에 있는 git 저장소에 소스 코드를 저장한다.

다음 이 코드를 원격에 있는 Heroku의 git 저장소로 전송을 해야 하는데, 이를 푸쉬(push)라고 한다. git push 명령어를 이용해서 실행하며, 코드가 Heroku의 git 저장소에 저장이 되면, 기동을 하기 위한 환경 변수 설정이나 npm 모듈들을 설치 하는 작업을 수행한다.


이제 애플리케이션 실행을 위한 모든 준비가 끝났다. 배포한 애플리케이션을 기동해 보자


서비스 기동 및 모니터링


서버의 기동은 Heroku에서 web dyno수를 0에서 1로 늘려주면 된다.


%heroku ps:scale web=1


서버가 기동된것을 확인하였으면 웹으로 접속해서 애플리케이션이 제대로 동작하고 있음을 확인하자.

Heroku app의 URL은 http://{heroku app 이름}.herokuapp.com 이다.

우리가 만든 예제는 helloherokuterry라는 앱 이름을 사용했기 때문에, https://helloherokuterry.herokuapp.com/ 가 접속 URL이 된다

또는 간단하게 명령 프롬프트 창 내에서 heroku open 이라는 명령어를 사용하면 해당 URL을 브라우져를 열어서 자동으로 열어준다.


%heroku open




Figure 8 Heroku open 명령어를 이용하여 기동중인 웹사이트를 오픈




Figure 9 Hello Heroku 실행 화면


드디어 Heroku에 node.js 애플리케이션을 배포하고 기동시켰다.

애플리케이션의 구동 상태와 로그를 확인해보자

현재 몇개의 dyno 가 구동되고 있는지를 확인하려면 다음 명령어를 실행하면 된다.


%heroku ps




Figure 10 ps 명령어를 이용하여 동작중인 서버를 확인


현재 web 타입의 1개의 dyno 가 실행되고 있음을 확인할 수 있다.

다음은 애플리케이션 로그를 확인해보자


%heroku logs –tail


이 명령어는 node.js에서 나오는 로그를 모니터링 할 수 있게 해준다



Figure 11 node.js의 로그를 확인


위의 로그를 보면 03:11:32에 서버가 기동 되었음을 확인할 수 있고

03:11:34초에 http://helloherokuterry.herokuapp.com/  URL이 호출되었음을 확인할 수 있다.

그리고 그 아래 애플리케이션에서 console.log(‘hello heroku’)로 출력한 로그도 같이 출력됨을 확인할 수 있다.


테스트가 끝났으면 실행중인 서버를 내려보자.

서버를 내리는 방법은 ps:scale 명령어를 이용하여 web dyno수를 1에서 0으로 변경해주면 된다

%heroku ps:scale web=0

명령을 실행하고 ps 명령어를 이용해서 현재 기동중인 dyno 수를 확인해보면, 아무 서버도 기동되지 않음을 확인할 수 있다.



Figure 12 동작중인 dyno를 종료하는 화면


로그에서도 아래와 같이 dyno를 끄는 로그를 확인할 수 있다.



Figure 13 dyno 종료 로그를 확인



IBM Blumix #1-첫번째 node.js 애플리케이션 개발

bcho.tistory.com

조대협


지난번에 bluemix에 대한 간략한 소개를 (http://bcho.tistory.com/940) 하였다. 오늘은 첫번째 node.js 애플리케이션을 만들어보도록 하자

먼저 bluemix에 가입을 한후에, 대쉬보드에 들어가서 "Create App" 을 선택한후에, "SDK for Node.js"를 선택한다.


여기에, 애플레케이션 이름을 넣는다. 애플리케이션 이름을 넣으면, node.js 애플케이션의 디폴트 웹 URL명도 똑 같이 애플리케이션명.mybluemix.net으로 지정된다. 


위의 그림과 같이 node.js 애플리케이션이 생성된 것을 볼 수 있다. 소스코드를 수정하기 위해서, 코드를 git repository로 전환한다.

위의 메뉴에서 ADD GIT 버튼을 누르면 소스코드가 저장된 저장소를 git로 변경해준다. 그후에 아래와 같이 GIT URL이 생성된 것을 확인할 수 있다.



다음으로 IDE를 이용하여, git remote repository를 이 URL로 연결해준다. 여기서는 WebStorm 7.x를 사용하였다.

코드를 받아서 /package.json을 확인해보면 다음과 같다.

{

"name": "NodejsStarterApp",

"version": "0.0.1",

"description": "A sample nodejs app for Bluemix",

"dependencies": {

"express": "3.4.7",

"jade": "1.1.4"

},

"engines": {

"node": "0.10.26"

},

"repository": {}

}

기본적으로 express 3.4.7 버전과 jade 1.1.4 버전을 사용하고 있으며, node.js 버전은 0.10.26 버전을 이용한다.
그러면 코드를 수정해보자 /views/body.jade 파일에 아래와 같이 Learning node.js 문자열을 추가해주고, 코드를 commit/push 한다.

        p Thanks for creating <span class = "blue">Learnig node.js</span>. Get started by reading our <a href = "https://www.ng.bluemix.net/docs/#starters/nodejs/index.html#nodejs">documentation</a> or use the quick start guide under your app in your dashboard.



별도의 코드 배포나 작업없이 push가 된 코드는 node.js에 적용된다.

아래와 같이 수정한데로 "Learning node.js" 문자열이 출력되는 것을 확인할 수 있다.

대쉬 보드에서 프로젝트를 선택하면, "ADD GIT" 버튼이 있던 자리에 "CODE"라는 아이콘이 생긴것을 볼 수 있는데, 여기를 들어가면 git repository내에 저장된 코드를 볼 수 있고, 좌측의 git 아이콘을 눌러서 확인해보면, 코드 변경 이력을 아래와 같이 확인할 수 있다.




※ 참고 자료 : https://hub.jazz.net/tutorials/jazzeditor/ 에 설명이 잘 나와 있음. (추천)







IBM 블루믹스 소개

 

PaaS

IBM 블루믹스는 IBM에서 제공하는 PaaS(Platform As A Service) 클라우드 서비스이다. 아마존과 같은 서비스가 VM을 제공하는 IaaS(Infra as a service)라면, 블루믹스는 node.js, Java와 같은 런타임을 미리 깔아놓고, 거기에 소스코드를 넣어서 돌리는 구조이다. IaaS의 경우 Linux Windows Server와 같은 OS VM 기반으로 제공하기 때문에 직접 미들웨어를 설치해서 사용해야 하지만, PaaS의 경우 이미 설치된 미들웨어 위에 코드만 돌리면되기 때문에, 아무래도 관리가 편리하다. 

그러면 왜 PaaS인가?

얼마전까지만 해도, 개발 트렌드의 중심은 기업체에서 개발하는 B2C서비스였다. 페이스북이나 네이버와 같은 서비스들이 대표적인데, B2C 서비스들은 대용량의 사용자를 커버해야 하고, 세세한 튜닝이나 설정 변경이 필요하고 다소 복잡한 아키텍쳐 구조를 가지기 때문에, 직접 인프라를 세팅하고 미들웨어를 설치하는 것이 오히려 유리했다. 그래서 IaaS를 많이 사용했는데,

근래에 들어서 개발의 중심이 모바일 앱이 되고 스타트업이 중심이 되면서, 적은 인원으로 빠르게 개발하고 관리할 수 있는 플랫폼이 필요하게되었고, 그로 인해서, Google App Engine이나, Heroku와 같은 PaaS 서비스가 각광받게 되었다.

IBM의 블루 믹스는?

지원 플랫폼

블루믹스는 APPS라는 개념을 가지고 있는데 이는 하나의 서비스로 보면된다. 이 안에, 서비스를 기동하기 위한 node.js mongodb와 같은 미들웨어를 묶어서 배포 할 수 있다. 아래 그림은 실제로 Terry라는 App mongodb 서비스를 추가하는 화면이다.



<App 에 추가할 서비스를 선택하는 화면>

매우 편하다. 클릭 몇번만으로, 내가 원하는 플랫폼을 쉽게 설치할 수 있다.

아래 화면은 node.js mongodb,redis로 구성된 서비스 환경이다.



<node.js mongodb,redis로 구성된 App>

현재 지원되는 플랫폼은 Java, Node.JS, Ruby on rials, Ruby Sinatra등을 지원한다.

부가 서비스 들은, 앞에서 언급한 mongodb, redis이외에도, rabbitMQ, IBM MQ, memcached,Work flow engine, Cloudant (CouchDB 계열) 등의 미들웨어 서비스 이외에도 Single Sign On, IOT (사물인터넷)등의 서비스를 부가로 지원한다. (꽤 많음)


코드 저장 및 반영

런타임에 적용되는 코드들은, 블루믹스에서 제공되는 git 저장소를 사용하면 된다.



<블루믹스 git 저장소>

재미있는 것중의 하나는, 웹브라우져상에서 코드 개발 에디터 기능 자체도 제공한다. 아래는 node.js의 코드를 웹 개발환경에서 편집하는 화면이다.



<블루믹스내에서 코드 편집하는 화면>

그리고, Atlassian JIRA와 같은 이슈 트랙킹 시스템을 제공한다. 공동 프로젝트를 관리하기 위해서는 태스크를 관리할 수 있는 시스템이 필요한데, 블루믹스에서는 IBM Jazz를 기반으로한 태스크 관리 시스템을 제공하고 있다. 개인적으로 예전에 Jazz를 사용했을때 상당히 무겁고 복잡하다는 느낌을 받았는데.. 어떤지는 조금 더 써봐야 알 수 있겠다.



<Jazz를 이용한 Task 정의 화면>

블루믹스는 앞에서 본것과 같이 서비스를 제공하기 위한 플랫폼만을 제공하는 것이 아니라, 형상관리,태스크 관리 및 빌드/배포 까지 자동화한 ALM (Application Life cycle management) End2End 기능을 제공한다.


서비스 관리

아래 화면은 node.js의 인스턴스 수를 조정하는 화면인데, 정말 쉽다. 아래 인스턴스 개수 숫자를 올려주면, 그만큼의 인스턴스가 가동되고, 각 인스턴스별 메모리양을 설정할 수 있다.



<그림. Node.js의 인스턴스 수를 조정하는 화면>

좀 특이한 점이 아마존처럼 VM단위로 과금을 하는게 아니라, 나한테 정해진 메모리 용량에 따라서, 이 안에서 인스턴스를 마음대로 만들 수 있는 개념인데, 구체적인 과금에 개념에 대해서는 향후에 조금 더 테스트를 해보고 올리도록 하겠다.

 

지금까지 간략하게나마 IBM PaaS 클라우드 블루믹스에 대해서 알아보았다. 특징은 무엇보다 쉽다!! 이다. 블루믹스 클라우드는 가입하면 무료 평가기간 동안 사용할 수 있으며 다른 클라우드 처럼 신용카드 번호를 넣지 않아도 된다. (URL : https://ace.ng.bluemix.net)

서버 개발 환경이 필요한 사람이 있으면 꼭 한번 사용해보기를 추천한다.

알림 : 본글은 IBM 블루믹스로 부터, 스폰서를 받는 글이 아닙니다!!! 혹시나 오해하지 마시기를..

 

국내만 아니라, 해외에도 서비스 하는 플랫폼을 설계할때 고려해야 할 기술적인 사항을

인프라(하드웨어+데이타 센터) 관점과 소프트웨어 관점에서 간략하게 정리하였습니다

 



애플리케이션 기반의 플랫폼 레퍼런스

http://www.cloudbees.com/platform-overview.cb

단순하지만 쓸만한거 같고,
특징은 개발/빌드 환경을 체계화 해놨다는 건, 다른 클라우드에서는 이런 환경을 PaaS 수준으로 제공하는 것은 없는 걸로 아는데, 일단 CloudBees는 Jekins(Hudson)을 사용한다는 것

 아마존 EC2는 아마존 클라우드 서비스의 가장 대표적인 Iaas 서비스 컴포넌트이다. 아마존은 하드웨어 서버를 가상화해 그 하드웨어 자원을 사용자에게 제공하고, 사용자는 그 위에 운영체제와 소프트웨어를 설치해 클라우드 서비스를 이용한다는 개념이다.

 

아마존 EC2

아마존에서는 사전에 Pre configure 된 운영체제 이미지를 제공해, 사용자로 하여금 원하는 이미지와 소프트웨어를 직접 선택할 수 있게 하거나 또는 사용자가 직접 시스템에 대한 이미지를 AMI(Amazon Machine Image)라는 형태로 올려서 사용할 수 있도록 한다.

아마존에서 제공하는 Pre configure 된 이미지들은 < 1>과 같다.

 

Database

IBM DB2

IBM Informix Dynamic Server

Microsoft SQL Server Standard 2005/2008

MySQL Enterprise

Oracle Database 11g

Batch Processing

Hadoop

Condor

Open MPI

Web Hosting

Apache HTTP

IIS/Asp.NET

IBM Lotus Web Content Management

IBM WebSphere Portal Server

Application

Development

Environments

IBM sMash

JBoss Enterprise Application Platform

Ruby on Rails

Application Servers

IBM WebSphere Application Server

Java Application Server

Oracle WebLogic Server

Video

Encoding & Streaming

Wowza Media Server Pro

Windows Media Server

< 1> Pre configure 된 이미지

 

< 1>에서 보는 것과 같이 자바, 닷넷, Ruby on Rails와 같은 프로그래밍 플랫폼과 오라클, MySQL, DB2와 같은 데이터베이스는 물론이고, Media Server와 같은 스트리밍 서비스와 WebSphere Portal과 같은 애플리케이션 서비스도 제공한다.

기본적으로 아마존 EC2는 하드웨어를 가상화하기 때문에 원하는 운영체제와 원하는 소프트웨어를 대부분 인스톨 할 수 있다. 이런 이유로 플랫폼에 대한 수용력이 높다는 장점을 가지고 있다.

하지만 가상화된 하드웨어 자원에 대해서만 서비스를 제공하고 그 위에 설치되는 운영체제와 소프트웨어에 대한 서비스는 제공하지 않는다. 이것이 약점으로 작용할 수 있다. 왜냐하면 사용자 입장에서 해당 소프트웨어에 대한 라이선스 구매와 유지보수료 지불에 대한 추가적인 비용이 발생할 수 있으며, 각각의 소프트웨어에 대한 설치와 운영을 별도로 해야 하기 때문이다.

따라서 기존 온 프라미스 방식의 운영방식에 비해서 하드웨어 자원을 임대해 쓴다는 점 외에 소프트웨어 비용에 대한 문제와 운영관점 상의 문제가 그대로 남아있어 걸림돌로 작용할 수 있다.

 

아마존 SDB(Simple DB)

아마존 SDB 서비스는 Key-Value 타입의 데이터를 저장하기 위한 데이터 저장소 서비스다.

No-SQL인 카산드라(Cassandra)나 하둡(Hadoop) 기반의 HBase와 유사하게 Key-Value 타입의 데이터를 저장하고, 대용량 데이터의 저장 및 빠른 검색을 지원하며 Value에 들어가는 데이터 형에는 제약이 없다는 점이 특징이다. 이런 특성을 ‘Schemeless’라고 하는데, 관계형 데이터 저장이 필요 없는 데이터 구조에서 데이터 저장의 유연성을 부여해준다.

아마존 SimpleDB의 특징 중 하나는 Geo Replication이 가능하다는 것이다. Simple DB에 저장된 데이터는 물리적으로 떨어진 아마존의 데이터 센터에 복제되기 때문에 데이터의 접근성을 향상시키고 장애 시 데이터에 대한 안정성을 보장받을 수 있다.

* Column DB에 대한 구조와 설명은 지난 회에 연재한 Azure Table Storage를 참고 하기 바란다. (아주 유사한 데이터 구조와 기능을 가지고 있다.)

 

아마존 S3(Simple Storage Service)

SDB Key-Value 타입으로 된 간단한 형식과 작은 크기의 데이터 저장을 위해 디자인됐다면, S3은 대용량 Blob 데이터에 대한 저장을 위해 디자인됐다. 다시 말하면 파일, 이미지, 동영상과 같은 큰 사이즈의 데이터를 저장하기 위해 만들어졌다. 저장될 수 있는 데이터 수에 대한 제한은 없으며, 저장되는 데이터 크기는 레코드 당 1byte에서 최대 5GB를 지원한다.

 

아마존 SQS(Simple Queue Service)

SQS IBM MQ나 자바의 JMS와 같은 전통적인 Queue의 아마존 클라우드 버전이라고 생각하면 된다. Queue를 통해서 Reliable Messaging이나 Asynchronous 아키텍처 구성을 지원한다. Queue에 저장되는 메시지는 개당 최대 64Kb까지 지원되며, 최대 14일까지 Queue에 저장할 수 있다.

 

아마존 RDS(Relational Database Service)

RDB 서비스는 MySQL 기반의 관계형 데이터베이스 서비스를 제공하는 것이다. Geo Raplicaton을 포함한 대부분의 MySQL Feature를 지원하며, 흥미로운 특징 중 하나는 데이터베이스 아키텍처 중 하나인 Query-off loading 아키텍처를 지원한다는 것이다.

이 아키텍처는 읽기 트랜잭션(Read Transaction)이 많은 경우에는 하나의 마스터 데이터베이스(Master DB) Create / Update / Delete를 일으키고, 여러 개의 슬레이브 데이터베이스(Slave DB)에 데이터를 복사해 여러 개의 슬레이브 데이터베이스에서 읽기 관련 트랜잭션을 수행하게 한다. 이 과정을 통해 읽기 트랜잭션을 분산시켜 대규모 처리가 가능하게 된다.

 

아마존 EBS(Elastic Block Storage)

EBS EC2 인스턴스에 Attach 될 수 있는 가상의 하드디스크이다. 하나의 EC2 인스턴스에는 여러 개의 EBS 볼륨이 마운트 될 수 있으며, 하나의 볼륨 크기는 1GB부터 1TB까지이다.

실제로 저장될 때는 S3 서비스를 이용해서 저장되는데, 흥미로운 점은 분산파일구조를 채택하기 때문에 IO Performance가 상당히 높은 편이며, EBS Booting Partition으로도 마운트가 가능하다. 또한 특정 시점에 EBS의 이미지를 S3에 저장하여 백업용으로도 사용할 수 있다.

 

아마존 Elastic Map & Reduce

Map & Reduce는 대규모 분산처리를 위한 처리 알고리즘이다.

Map & Reduce는 하나의 큰 작업을 여러 단위의 작업으로 쪼갠(Map) 후 분산된 노드에서 각각 처리한다. 그리고 난 후 처리결과를 다시 하나로 모으는(Reduce) 작업을 통해 처리시간을 향상 시키는 기법이다. 주로 검색결과분석을 위해 많이 사용되는데, 대표적인 오픈소스 구현으로 하둡이 있다. 아마존에서 바로 이 하둡 기반의 Map & Reduce를 지원한다.

Map & Reduce를 실제로 구축하기 위해서는 많은 수의 CPU와 고성능 입출력을 지원하는 분산파일 시스템이 필요하기 때문에 클라우드 시나리오에 매우 적절한 모델이며, 주로 수학적인 계산이 필요한 과학 및 계산 애플리케이션에 많이 활용될 수 있다.

 

아마존 Elastic Load Balancing

클라우드 서비스에서 여러 개의 인스턴스를 운영한다면 당연히 각 인스턴스 간 부하를 분산시키는 메커니즘이 필요하다. 아마존에서는 Elastic Load Balancing이라는 이름으로 한 단계 향상된 형태의 부하분산 메커니즘을 제공한다.

 

- 하나의 데이터센터 내에서 배포된 인스턴스 간뿐만 아니라 여러 데이터센터에 걸쳐 배포된 인스턴스 간에도 부하분산을 지원한다.

- 각 사용자들에 대해 특정 인스턴스로 ConnectionPinning 해주는(L4에서 TCP Session이 한번 맺어지면 계속 유지되는 것과 유사한 방식) 기능을 지원한다. 이 기능은 서버 쪽에 사용자 상태를 저장하는 아키텍처(웹 세션 저장과 같은 시나리오)를 구현할 수 있게 해준다.

- 인스턴스의 상태를 파악해 장애가 났을 때, 장애가 난 인스턴스를 인지해 정상적인 인스턴스로만 요청을 전달하는 Fail Over 기능도 지원한다.

 

아마존 Auto Scaling

클라우드에 있어 가장 중요한 기능 중 하나는 바로 쓴 만큼 지불하되, 요구용량이 늘어나면 서비스 가용용량도 따라서 증가해야 한다는 것이다.

인스턴스는 독립된 VM(제약된 CPU와 메모리 용량)을 기본으로 서비스를 제공하기 때문에 인스턴스에 할당된 VM의 용량을 넘어서는 경우에는 추가로 VM을 할당해줘야 한다. 이런 일련의 작업을 자동으로 해주는 것이 바로 Auto Scaling기능이다.

아마존 EC2에서는 “CPU 사용량이 몇 % 이상 또는 저장용량이 얼마 이상”같은 조건을 사용자가 설정해놓으면 조건이 일치되는 시점에서 자동적으로 인스턴스가 늘어나는 서비스를 제공한다.

 

아마존 SNS(Simple Notification Service)

일반적인 서비스 모델은 클라이언트의 요청에 대해서 서버가 응답하는 형태인데 반해 Notification 서비스는 반대로 서버가 클라이언트에 요청을 보내는 모델이다. 대표적으로 핸드폰의 SMS나 이메일 푸쉬 서비스 등이 이에 해당하는데, 아마존에서는 이러한 형태의 Notification Service를 제공한다. 아마존의 Notification Service HTTP SMTP 프로토콜만을 지원한다.

기본적인 모델은 Subscription, Notification을 받고자 하는 클라이언트가 주제(Topic) Subscription을 신청하면 등록된 클라이언트들에서 이벤트가 있을 경우 Notification을 보내주는 형태이다.

 

아마존 VPC(Virtual Private Cloud)

VPC 서비스는 아마존 EC2 클라우드의 인스턴스와 고객사의 온 프라미스 시스템 사이에 VPN을 설정해 EC2 클라우드 인스턴스를 특정 고객사에서만 접근할 수 있게 해주는 서비스이다.

이 서비스는 일종의 Hosted Private Cloud 모델로 EC2 내의 특정 자원에 대한 접근을 특정 고객사로 Dedication 해줄 수 있는 기능을 가지고 있다. 바꿔 말하면 해당 시스템은 EC2 대외 고객은 접근이 불가능하다.

예를 들어 EC2에서는 쇼핑몰의 판매 정보를 온 프라미스 시스템으로 VPC를 통해서 전송하고, 고객에게는 쇼핑몰 판매 서비스를 제공하는 형태의 서비스가 불가능하다는 것이다(VPC 인스턴스는 온 프라미스 시스템과만 접속이 가능하다).

 

아마존 CloudFront

CloudFront 서비스는 아마존에서 제공하는 CDN(Contents Delivery Network) 서비스다. 아마존 S3에 저장된 Binary 데이터를 CDN 노드를 이용해 전세계에 걸쳐서 있는 다운로드 속도에 대한 성능을 올려주는 서비스이다. CDN은 전 세계에 여러 센터에 걸쳐서 배포돼 있는데 CDN 서버들이 일종의 캐시 서버 역할을 해서 거리로 인해서 발생하는 Latency를 줄여준다. <그림 1>에서 보듯 CloudFront는 미국, 유럽, 아시아에 걸쳐 총 16개의 CDN 센터를 운영하고 있다(< 2> 참조).

 

<그림 1> 아마존 CloedFront를 위한 CDN 센터

지역

위치

미국

애슈번(Ashburn), 댈러스/포트워스, 로스앤젤레스, 마이애미, 뉴욕, 뉴어크(Newark), 팰러앨토(Palo Alto), 시애틀, 세인트루이스(St. Louis)

유럽

암스테르담, 더블린, 프랑크푸르트, 런던

아시아

홍콩, 도쿄, 싱가포르

< 2> CDN 센터위치(http://www.michaelgaigg.com/blog/2008/11/19/fast-faster-cloudfront-speed-matters/ )

 

아마존 Cloud Watch

 

<그림 2> 아마존 Cloud Watch

 

Cloud Watch EC2 S3 등 아마존 클라우드 서비스에 대한 모니터링 기능을 수행한다. 모니터링을 통해 서버 부하와 장애상태를 체크하고, Elastic Load Balancer와 연동해 비 장애 노드로 요청을 전달한다. 부하상황에 따라 Auto Scaling 서비스와 연동해 서비스 인스턴스 수를 탄력적으로 조정할 수 있게 해준다.

 

지금까지 아마존 클라우드 서비스인 EC2의 기능에 대해서 살펴봤다. 여기서는 플랫폼적인 기능에 대해서만 주력해서 살펴봤다. 아마존은 Amazon MarketPlace Customization하기 위한 Fulfilment Service Billing/Payment Service 그리고 다양한 서포트 프로그램 등을 가지고 있다. 조금 더 자세히 알고 싶다면 홈페이지(http://aws.amazon.com/products/)를 참고하기 바란다.

 

아마존 BeansTalk

얼마 전에 발표된, Amazon PaaS 서비스로, Java/Tomcat을 기반으로 한 PaaS 서비스이다. 개발자가 개발한, 웹 애플리케이션을 WAR 타입으로 묶어서 UPLOAD만 하면 사용할 수 있으며, Tomcat이 구동되는 JVM에 대해서 다양한 성능 설정을 할 수 있다.

아울러, 문제가 생기거나 튜닝이 필요할 때, Tomcat이 구동되는 EC2 인스턴스에 직접 접근하여, OS수준에서 장애 분석이나 대응을 할 수 있다.

기존의 Amazon 서비스들이 IaaS 단계에서 머물러 있었다면, BeansTalk 서비스는 Amazon이 향후 PaaS 시장을 적극적으로 공략할 하나의 가능성을 보여주는 서비스 이다.

 

아마존 EC2 HPC (High Performance Computing)

BeansTalk과 함께, 아마존에서 발표한 서비스중의 하나가 EC2 HPC 서비스 인데, 근래의 HPC의 경향은 CPU를 사용하는 것도 있지만, 수치 연산에 최적화된 GPU를 사용하는 경우도 많다. 일반 수퍼 컴퓨터에 비해서 수치 연산에 최적화 되어 있고, GPU의 경우 수치 해석용 Core가 집적되어 있기 때문에, 가격대비해서 높은 성능을 낼 수 있다.

아래는 EC2 HPC에서 제공하는 인스턴스중의 하나인데,

l  22 GB of memory

l  33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture)

l  2 x NVIDIA Tesla “Fermi” M2050 GPUs

l  1690 GB of instance storage

l  64-bit platform

l  I/O Performance: Very High (10 Gigabit Ethernet)

l  API name: cg1.4xlarge

22G의 충분한 메모리와, 1.7 TB의 내부 저장 공간 그리고 2개의 NVIDIA Tesla GPU 를 가지고 있다.


<그림 3. Tesla M2050 GPU>

M2050의 경우 내부에 약 448개의 CUDA 기반의 Core, 3G또는 6G의 내부 메모리를 가지고 있다. HPC의 경우 고성능 계산이 필요한 경우만 한시적으로 사용하는 경우가 많기 때문에, 클라우드에 매우 적절한 시나리오라고 할 수 있다.

 

아마존에 대해서 몇 가지 주요 서비스를 소개했지만, 사실 이외에도 세부 서비스들이 많다.

 

클라우드는 근래에 가장 각광 받는 기술이면서도, 쓴 만큼 비용을 낸다는 개념으로 합리적인 모델이지만, 이번 연재를 통해서 설명한 것과 같이, 여러가지 모델 (IaaS,PaaS,SaaS)를 가지고 있으며, 각각의 특성도 매우 다르기 때문에, 업무의 특성을 이해하고, 기술의 특성을 이해해서 클라우드 지향형 아키텍쳐를 설계해서 시스템을 개발해야 한다. 이러한 이해가 없이 그냥 서비스를 클라우드에 배포한다면, 오히려 더 낮은 안정성과 성능 그리고 높은 비용을 지불해야 할 것이다.

 

 

클라우드 서비스중 Private 클라우드의 경우 대부분 Hypervisor 기반의 가상화를 이용하여 하드웨어 자원을 공유하는 아키텍쳐를 일반적으로 사용하지만, Public 클라우드의 경우 Iaas 형태의 서비스를 제공한다 하더라도, 몇가지 공통적인 특정 서비스를 제공한다.

Public 클라우드에서 제공하는 공통적인 서비스 형태들은 다음과 같다.

 

Storage Service

Storage Service는 말 그대로 데이터를 저장하는 서비스이다. 데이터의 성격에 따라 몇 가지 상세 서비스로 나뉘어 진다.

적은 크기의 많은 수의 데이터 (Table Storage)

데이터의 수가 수천만,테라 단위의 많은 수를 가지고 있으며, 데이터의 복잡도나 각각 레코드의 크기는 크지 않을 경우, 큰 저장 용량과 빠른 검색 속도를 요구 한다. 사용자 profile,게시물 레코드등이 해당하는데, 기업내에 이런 데이터를 저장하기에는 디스크등의 저장소에 소요되는 비용이 너무 크고, 폭발적인 용량 증설이 있을 경우에 비즈니스에 대한 대응성이 늦다. 그래서 대부분의 Public Cloud 서비스에는 이러한 데이터 형태를 저장하는 별도의 저장 메커니즘을 제공하는데, MS Windows Azure Table Storage Amazon SDS가 대표적인 서비스이다.

이러한 데이터 저장 구조는 근래에 서비스 업체를 중심으로 하는 NoSQL 아키텍쳐와 관련이 깊은데, 실제로 페이스북이나 트위터의 경우 많은 데이터에 대한 저장 요구사항과 빠른 검색 및 접근 성능을 요구로 하고 있기 때문에, Cassandra와 같은 Column데이타 베이스를 이용하여 이와 같은 요건을 구현하고 있으며, 이러한 배경이 반역된 것이 위에 언급한 형태의 클라우드 데이터 서비스이다.

크기가 큰 데이터 (Blob Storage)

일반 데이터 파일, 사진,이미지,동영상과 같은 크기가 큰 데이터의 경우 복잡한 쿼리와 같은 연산은 필요로 하지 않지만 저장용량에 대한 비용 문제가 발생하고 특히 여러 국가를 대상으로 서비스 하는 시스템의 경우 데이터의 다운로드 속도가 문제가 된다.

 이런 형태의 데이터를 Blob 데이터라고 하고, Public Cloud에서는 크기가 큰 데이터를 저장하기 위한 서비스를 제공한다. Amazon S3, MS Windows Azure Blob Storage 서비스가 대표적인 예이며, 여러 국가(지역)간의 다운로드 성능을 향상 시키기 위해서 CDN (Contents Delivery Network)을 연계한 서비스를 제공하는 모델이 많다.

복잡한 데이터 연산을 필요로 하는 데이터 (RDBS over Cloud)

다음으로 기업용 애플리케이션이나 복잡한 관계형 데이터를 가지고 있는 경우 쿼리와 관계 관리를 위한 RDBMS 기반의 데이터 서비스가 필요하다. 쉽게 생각하면 RDBMS를 클라우드에 올리고 서비스를 한다고 똑같이 생각하면 되고, 단 이 경우 여러 데이터베이스간의 트렌젝션을 연동하여 보장하는 분산 트렌젝션은 지원하지 않는 것이 보통이다. (클라우드 노드간의 Latency 문제 때문에 분산 트렌젝션 지원시 심각한 성능 저하를 유발한다.)

 Amazon에서 오픈소스인 MySQL을 기반으로한 RDS 서비스나, MS Windows Azure MS SQL을 기반으로한 MS SQL 서비스가 대표적인 사례이다.

가상 디스크 저장소 (Virtual Disk)

마지막으로 애플리케이션 차원에서 양이 많지 않고 애플리케이션 자체적으로 사용할 데이터 또는 Iaas OS에 마운트되는 디스크등을 지원하기 위해서 논리적으로 디스크를 생성하여 가상머신(OS VM)에 마운트하는 서비스를 제공한다.

대표적인 서비스로는 Amazon EBS Microsoft Azure Azure Drive 서비스 등이 있다.

Queue Service

Queue Service는 기존의 IBM MQ, Microsoft MSSQ, Java JMS와 같은 비동기 호출을 지원하는 메시지 큐이다.

클라우드는 특성상, 작업을 하는 Working Instance들이 존재하고, 이 여러 Working Instance간의 작업 배분 또는 작업 요청에 대한 Buffering등을 위해서 중간에 메시지큐가 필요한데 이러한 요구사항을 지원하기 위해서 Public Cloud에서는 Queue 서비스를 제공한다.

대표적인 서비스로는 Amazon SQS, Microsoft Azure Queue Storage 서비스등이 있다.

Data Grid Service

일반적인 엔터프라이즈 소프트웨어 아키텍쳐중에 근래에 발전된 아키텍쳐중 하나는 데이터 그리드라는 아키텍쳐이다. 일종의 거대한 메모리를 여러대의 물리적 서버에 걸쳐서 배포하여 이론적으로 무제한 사이즈의 메모리를 만들고 애플리케이션들이 이 메모리를 통해서 서로 데이터를 공유하거나 또는 데이터 베이스에 대한 2차 캐쉬로 사용하는 시나리오를 많이 사용한다.

실제로 FaceBook의 경우 MySQL 데이터 베이스 윗단에 memcached라는 데이터 그리드를 위치 시켜서 데이터 베이스의 쿼리 성능을 획기적으로 향상 시키는 아키텍쳐를 사용하고 있다.

특히 클라우드 서비스의 경우 각각의 서비스 컴포넌트가 분리되어 있고 그로 인해서 컴포넌트간의 네트워크 Latency가 존재하기 때문에 데이터 조회의 성능을 높이기 위한 캐쉬 서비스와, 여러 인스턴스간의 정보를 공유하기 위한 데이터 버스가 필요하다.

이를 지원하기 위해서 발전된 형태의 Public Cloud에서는 데이터 그리드 서비스를 제공한다.

o    캐쉬 서비스

캐쉬 서비스는 데이터를 저장소 (데이터베이스, 파일)등에 저장하기 전에 2차 캐쉬로 사용하는 형태로 특히 Private 클라우드에 데이터를 놓고 Public 클라우드를 통해서 서비스를 제공하는 경우 지역적 문제로 인한 네트워크 Latency가 심하기 때문에 성능 향상을 위해서 캐쉬 서비스가 필수적으로 요구 된다.

o    메모리 버스

또한 여러 업무 또는 동일 업무라도 여러 서비스 인스턴스 (여러 VM)간의 데이터를 모으고 서로 공유 하기 위한 데이터 버스가 필요한데, Table Storage를 통해서 이러한 정보를 공유하는 시나리오도 있지만, 이보다는 데이터 그리드를 이용할 경우 보다 나은 성능을 보장할 수 있다. (일반적으로 데이터 그리드의 접근방식,데이터 구조는 Table Storage의 접근 방식과 데이터 구조와 거의 동일하다.)

 

대표적인 데이터그리드 서비스로는 Google AppEngine memcache 서비스, Microsoft Azure AppFabric Cache 서비스 등이 있다.

Scalability Support Service

클라우드 서비스의 가장 큰 목적 중의 하나가 하드웨어 자원의 탄력적인 사용이다. 자원의 사용량에 따라서 비용을 지불하는 모델인데, 현재 클라우드 서비스들은 이러한 요건을 만족하기 위해서 라이선스 정책상의 헛점을 가지고 있다. 대부분의 라이선스 정책이 CPU X clock에 메모리 얼마인 인스턴스 단위로 계약을 하고, 이 인스턴스당의 사용량에 대해서 과금을 하는 방식이다. 문제는 초기 계약 당시에 하나의 인스턴스만 계약을 하기 때문에, 용량이 하나의 인스턴스 이상으이 필요할 때 대응이 애매하다는 것이다. 쉽게 말하면 자동으로 인스턴스를 늘려줘야 하고, 늘려진 인스턴스에 자동으로 부하를 분산해줘야 한다. 이것이 클라우드상의 Scalability 문제인데, 이런 문제를 해결하기 위해서 제공 되는 서비스가 Auto Scaling 서비스이다. 일정 수준(SLA 이상)의 용량이 넘어가면 이를 감지해서 자동으로 인스턴스를 추가해주는 서비스이다.

대표적인 서비스로는 Amazon Auto Scaling 기능과 Windows Azure에서는 Monitoring API를 통해서 Instance를 늘려주는 기능을 추가해서 사용한다. (http://code.msdn.com/azurescale)

Virtual Machine Service

Iaas를 위한 가장 기본적인 서비스로, Hypervisor 기반의 하드웨어 자원을 가상화 하여 OS 별로 자원을 할당해주는 서비스이다. Amazon EC2 서비스와 Windows Azure VM Role 서비스가 대표적인 사례이다.

IDM(IDentity Management) Service

클라우드 서비스에 있어서 계정 통합 관리 및 권한 관리는 매우 중요한 이슈이다. 클라우드에 배포되는 여러가지 서비스에 대해서 통합된 계정 관리가 필요하고, 각 서비스에서 요구하는 사용자의 프로필의 스키마(항목)가 다르고 서비스마다 각각 관리가 되어야 하기 때문에 서비스 가입 및 해지 또는 정보 변경에 따라 각각 서비스가 관리하고 있는 사용자 프로파일이 동일하게 변경되어야 한다 (ID Provisioning).

여기에 더해서 만약 on premise 시스템과 연동을 할 경우 기업 내에 이미 계정 및 권한 관리 시스템이 운영되고 있기 때문에 클라우드에 구축된 시스템과 on premise 시스템간의 계정 통합 역시 새로운 이슈로 제기된다.

이런 계정 통합과 통합 권한 관리의 이슈를 해결하기 위해서 클라우드 시스템내에는 통합된 또는 통합 가능한 형태의 계정 권한 관리 시스템이 요구된다.

대표적인 서비스로는 Windows Azure AppFabric ACS 서비스가 있다.

Platform Service (.NET,LAMP etc)

다음으로는 애플리케이션 플랫폼을 배포 및 운영할 수 있는 형태의 서비스를 제공하느냐인데, 쉽게 생각하면, 자바나 .NET 기반의 애플리케이션만 배포하면 되느냐? 아니면 DB,Web Application Server등의 미들웨어도 배포해야 하는냐로 판단하면 된다. 개발된 애플리케이션만 배포하여 운영할 수 있는 인프라가 다 되어 있는 경우에는 Paas (Platform As a Service)이고, 애플리케이션 운영을 위해서 별도의 미들웨어 인스톨이 필요할 경우 미들웨어를 인스톨할 수 있는 인프라만 제공하는 경우이기 때문에 이런 형태는 Iaas(Infra as a service)라고 한다.

Microsoft Azure의 경우 .NET,PHP 등의 애플리케이션 플랫폼을 제공하는 Paas 형태이고, Amazon의 경우에는 가상화된 OS를 기본적으로 제공하고, 그 위에 애플리케이션 운영플랫폼은 별도로 설치해야 하기 때문에 Iaas 형태이다.

Google의 경우 Python JVM기반의 언어 (JRuby)등을 제공하는 Paas 형태이고, 위에서 설명했듯이 MS Azure Paas, Amazon Iaas 형태의 서비스를 제공한다.

Integration Service

클라우드의 요구사항 중 하나는 각각 개별로 배포된 클라우드 기반의 서비스간의 통합 또는 클라우드에 배포된 서비스와 on premise에 배포된 서비스간의 연동이다. 위에서도 IDM등의 시나리오를 통해서 특화된 연동 통합 시나리오에 대해서 언급했지만, 여기서는 좀 더 보편화된 통합 서비스 기능에 대해서 설명한다.

     Internet Service Bus

SOA 서비스에서 메인 계층 중의 하나가 Enterprise Service Bus (ESB)이다. ESB는 여러 다른 비즈니스 서비스간의 통합과 데이터 버스의 개념으로 사용되는 솔루션이다. 클라우드 아키텍쳐에서도 이와 유사한 형태의 데이터 버스와 통합 계층이 필요한데, 기존 ESB의 특징에 더해서 클라우드 아키텍쳐의 특징을 반영할 수 있는 Service Bus가 필요하다.

클라우드는 첫번째로 지역적으로 분산된 위치에 비즈니스 서비스들이 배포 되며, 두번째로 방화벽이나 NAT(네트워크 주소를 변경 시키는 장치)등을 경계로 한 on premise 서비스와 클라우드 내의 서비스를 통합해야 하는 요건을 가지고 있다. 그렇기 때문에 지역간의 라우팅을 담당하고 복잡한 네트워크 토폴로지 (주소 변환,방화벽)를 지원할 수 있는 구조의 Service Bus가 필요하고 이런 특성을 가지고 있는 Service Bus Internet Service Bus라고 제공한다. 이러한 Internet Service Bus는 애플리케이션 플랫폼에 종속적이기 때문에 (Reverse Proxy등의 기능을 제공해야 하기 때문에 프로그래밍 언어의 라이브러리 형태로 일부 모듈이 제공되어야 한다.) Iaas 형태의 클라우드에서는 제공하기 어렵고 애플리케이션 플랫폼을 제공하는 Paas 형태에서 제공하기가 용이하기 때문에 대표적인 Iaas 형태인 Amazon 클라우드에서는 제공하지 않고 있으며 Paas 를 지원하는 Microsoft Windows Azure AppFabric Service Bus가 대표적인 사례이다.

     Legacy Integration Service

다음으로 기업내의 Legacy System을 통합하기 위한 솔루션이 필요한데, 클라우드 이전의 on premise 시스템에서는 EAI (Enterprise Application Integration)이라는 아키텍쳐를 이용했다. EAI Legacy Package Application에 대해서 특정한 Technology를 이용한 통합을 제공하는데, (SAP ERP, Oracle CRM에 대한 Technology 아답터등을 제공하는 방식으로) 이러한 EAI 특성이 클라우드에도 배포되어 on premise에 배포된 Legacy Application이나 클라우드에 배포된 Package Application에 대해서 통합을 지원한다. 대표적인 예로는 Microsoft Azure AppFabric BizTalk 서비스가 있다.

Monitoring Service

마지막으로 Monitoring Service인데, 서비스 현황, 사용량 등을 Dash Board 형태로 표현함은 물론이고, Application의 성능과 건강도를 모니터링할 수 있는 APM (Application Performance Monitoring)등의 기능이 제공되어야 한다.



클라우드 컴퓨팅의 최소 요구 조건

       Self Service : 클라우드에 배포된 리소스에 대한 사용과 설정 등을 서비스 제공자가 제공하는 인터페이스를 이용하여 사용자가 직접 조작

       Scalable /Elastic : 클라우드 내의 공유 자원 등을 이용하여 사용량(트렌젝션 증가)에 따라서 탄력적으로 리소스를 재 배분할 수 있어야 한다.

       Multi-tenant/Shared : 클라우드 내의 공유 리소스는 여러 조직이나 업무에 배분 되어 사용되며, 각각 배분된 리소스는 보안 적인 측면과 사용량 적인 측면등에 있어서 철저하게 분리된 형태로 제공되어야 한다.

       Usage based : 클라우드 서비스에 대한 사용 요금은, 사용량을 기준으로 제공되어야 한다.

클라우드 컴퓨팅의 배포 모델에 따른 분류

클라우드 컴퓨팅 플랫폼은 배포 장소와 서비스 사용 제공/사용 주체에 따라서 크게 아래와 같이 3가지 형태로 분리할 수 있다. 아래 Y 축은 배포 장소를 의미하고 아래 X축은 서비스 사용/제공 주체를 의미한다.


Private Cloud

서비스 사용자가 기업 내부의 비즈니스 시스템을 위해서 자체적으로 클라우드 플랫폼을 구축 하는 모델 (:on-premise)

§   클라우드 플랫폼이 회사 내부 또는 3’rd party 데이터 센터에 독립적으로 구축됨

§   Example

o    Rackspace Managed Private Cloud

o    데이터 센터에 Hosting Service + 가상화를 이용하는 경우

o    Hosting.com – Cloud Dedicated offering

o    Microsoft Data Center based implementation

Public Cloud

서비스 제공자가 클라우드 서비스를 제공하기 위한 플랫폼

§   전문 클라우드 사업자 (MS,Amazon)에 의해서 서비스가 제공되는 클라우드 플랫폼

§   클라우드 플랫폼은 서비스 사용자의 회사 외부에 (서비스 제공자)에 배포됨

§   모든 리소스는 다른 사용자와 공유됨

§   리소스 사용량에 따라 과금되는 형태

§   Example

o    Salesforce.com

o    Amazon EC2

o    Windows Azure, Microsoft Dynamics Online, Office365

o    Google App Engine

“Hosted Private Cloud”

서비스 사용자가 기업 내부의 비즈니스 시스템을 서비스 제공자의 Public 클라우드 플랫폼을 인프라로 사용하여 구축하는 모델

클라우드 컴퓨팅의 서비스 단계에 따른 분류

Infrastructure as a Service (Iaas)

IT 서비스를 제공하기 위한 주요 인프라 자원 (CPU 자원, 메모리, 디스크, 네트워크 환경)을 공유 자원 형태로 관리하고 이를 나눠서 제공하는 형태의 서비스로, 서비스 사용자는 이러한 인프라 위에 리소스를 할당 받아 OS와 미들웨어 (데이터 베이스, 웹서버)를 설치하여 서비스를 이용하는 형태이다.
주로 Microsoft Hyper-V, Citrix XenServer등과 같은 가상화를 이용하여 하드웨어 자원을 가상화하고, 이 가상화 기술을 통해서 자원을 배분한다
.
대표적인 Public Cloud 서비스로는 Amazon EC2,FastHosts,Rackspace,Go Daddy등이 있다.

Platform as a Service (Paas)

Iaas OS를 인스톨 하기 위한 하드웨어 가상화 환경을 제공하는 것이라면, Paas Iaas에 한 계층을 올려서 소프트웨어를 개발 할 수 있는 플랫폼을 제공하는 환경을 의미한다.

특정 컴퓨터 언어(Java,.NET,Rails,PHP etc) 가 구동할 수 있는 미들웨어 및 데이터 베이스는 물론이고, OPEN API 형태로 미리 구현된 서비스 라이브러리를 제공함으로써 애플리케이션을 개발할 수 있도록 지원한다.

대표적인 예로는 Java Python 언어 기반의 서비스를 제공할 수 있는 Google AppEngine 서비스,, .NET 기반의 웹 애플리케이션이나 서버 사이드 애플리케이션을 개발 및 서비스할 수 있는 Windows Azure등이 대표적인 Paas 서비스로 볼 수 있다.

또한 Amazon PayPal을 이용한 OPEN API기반의 빌링 서비스,Google Map 서비스와 같은 OPEN API  플랫폼 역시 Paas의 일부로 분류할 수 있다.

Software as a Service (Saas)

클라우드 서비스의 추상화중 가장 상위 계층을 차지하는 분류로 소프트웨어 서비스를 제공하는 형태의 클라우드 서비스이다. 예전의 ASP (Application Service Provider-KT의 비즈메카, Cafe24의 쇼핑몰 호스팅)과 유사한 서비스 모델로, 이메일,CRM 등의 완성된 형태의 애플리케이션을 서비스 받는 형식으로, 사용자는 애플리케이션의 사용량에 따라서만 비용을 지불하고 그외의 부분 (아래 인프라나 하드웨어 사양, 플랫폼 사양)에 대해서는 관리를 하지도 비용을 지불하지도 않는다.

구글의 GMAIL,Apps 서비스, SalesForce.com CRM서비스 MS Office365 서비스들이 대표적인 예이다.

기타

근래에 들어 위의 3개 주요 분류 이외에도 특화된 서비스 모델을 중심으로 새로운 클라우드 서비스 분류가 나타나고 있는데, 대표적인 분류 내용을 꼽아보자면 다음과 같다.

o    Test platform as a service

대규모 부하 테스트 등은, 소프트웨어 개발 프로젝트의 중후반에 발생하며 많은 수의 하드웨어 장비와 대규모의 트래픽을 지원하는 네트워크망이 필요하다. 이러한 인프라를 비 연속적인 개발 프로젝트를 위해서 사내에 구매 및 구축이 어렵기 때문에 근래에 들어서는 이러한 대규모 부하 테스트를 위한 서비스를 클라우드를 통해서 제공되는 서비스가 있으며, Selenium in Amazon EC2등이 대표적인 사례이다.

o    Develop platform as a service

테스트 플랫폼과 마찬가지로, 소프트웨어 개발 프로젝트 과정에서는 개발 계와 이행을 위한 Staging 계 등의 다양한 개발 환경이 필요하며, 이러한 개발 환경에 대한 관리 와 하드웨어 및 소프트웨어 구매는 기업에 있어서 또 다른 부담으로 다가온다. 이러한 문제를 해결하기 위해서 소프트웨어 개발환경을 클라우드 형태로 구성해놓고, 프로젝트 기간에만 임대해서 사용하는 형태의 서비스가 있다.

대표적인 예로는 Microsoft SDC (Solution Development Center)의 개발 환경 모델이 있다.

2009년 기술 전망

엔터프라이즈 솔루션 | 2009.01.06 09:42 | Posted by 조대협

1. Cloud and grid computing

클라우드 컴퓨팅과 이를 구현하기 위한 솔루션인 그리드 컴퓨팅은 금년에도 이슈가 될것같다.

구글이나 야후, 아마존들을 중심으로 한 글로벌 서비스 기업들이 그리드와 클라우드 컴퓨팅에 선두가 되고 있지만

정작, 기업에 있어서 클라우드 컴퓨팅이나 그리드 컴퓨팅의 도입은 소극적이다. 특히 클라우드 컴퓨팅의 경우

보안이나 성능상의 이슈로 기업에 도입이 될지 않될지는 지켜봐야 할것 같지만

그리드 컴퓨팅의 경우 Coherence와 같은 Data Grid제품이나, Hadoop과 같은 File grid, grid dbms등은 기업에도 충분히 사용이 가능한 솔루션이다. 얼마나 기업 고객들이 이 개념들을 이해하고 적응하느냐가 관건일테고, 다른 한축으로는 대부분의 그리드 솔루션이 오픈 소스로 구축 된 경우가 많기 때문에 기업의 오픈 소스에 대한 반감을 어떻게 풀어내느냐도 하나의 숙제가 될것이다.

 

2. Virtualization

여기서 언급하고자 하는 가상화는 특히 서버의 자원 가상화이다. 여러개의 CPU와 메모리가 있는 장비를 Partition해서 사용함으로써 자원의 효율성을 극대화 시키는 기술인데.

예를 들면 이전에 2 CPU 서버 3대로 3개의 업무를 하고 있다고 했을때, 1서버의 평균 CPU 사용률이 1.2 2서버 1.5, 3서버 1.5라고 했을때 이렇게 되면 총 6개의 CPU가 있지만, 사용되는 CPU수는 실제로는 4.2이다. 가상화를 사용하게 되면, 하나의 큰 서버에 CPU 사용률을 상황에 따라서 배정할 수 있기 때문에 초기에 5장의 CPU로도 충분히 운영이 가능하게 된다 또한, 갑자기 부하량이 늘어나는 경우에는 여분의 CPU를 해당 업무에 할당 할 수 있기 때문에 자원활용의 유연성을 더할 수 있다.

 

가상화의 다른 특징중의 하나는 가상화된 환경과 애플리케이션을 이미지로 관리하기 때문에, 쉽게 다른 하드웨어 환경으로 배포가 가능하다는 것이다. 이는 SM관점에서 많은 장점을 가질 수 있게 된다.

 

3. Saas,Pass,Iass

Saas (Software as a service)는 이미들 많이 사용되는 컨셉이고 내년에는 Iaas와 Pass가 화두가 되지 않을까?

Iaas(Infrastructure as a service)는 OS,CPU,메모리,디스크와 같은 자원을 서비스로 제공하는 형태이다. 이미 아마존이 Message Q, OS,Disk,DBMS등에 대해서 E3라는 형태의 서비스로 Iaas 서비스를 제공하고 있다. 단기적으로 컴퓨팅 파워가 필요한 캠페인이나, CPU가 많이 필요한 3D 렌더링 작업들에는 매우 유용하게 사용될 수 있고, IDC 센터가 세계에 나눠져 있기 때문에, 여러 위치에서 테스트가 필요한 경우 유용하게 사용할 수 있다.

이미 아마존 E3 서비스에서는 OS별로 이미지를 만들어서 업로드하면 수행할 수 있도록 되어 있다.

다음으로는 Pass (Platform as a service)가 있는데, 플랫폼을 서비스로 제공하는 것이다. Open API도 일종의 Pass가 될 수 있고, Google의 Android 플랫폼 (OS+Open API환경,애플리케이션 Store)나 Apple의 AppStore도 일종의 Pass가 될 수 있다. 이러한 Paas가 Iaas와 결합하면서, 무제한적인 자원(Iass)을 유연성있게 제공받을 수 있으며, 그위에 Pass를 구현함으로써 개발자들에게 Application을 개발할 수 있는 플랫폼을 제공한다. 이 Pass를 이용하여 소프트웨어가 개발되고 일반 사용자에게 서비스되는 형태가 Saas로 될 수 있다.

사실 한국에서는 이 3가지에 대해서 움직임이 매우 늦은게 사실이다. 이 3가지 기술들은 주로 Google,Amazon과 같은 서비스 업체들의 주도로 시장이 움직여가고 있는데, 우리나라의 N이나, D사의 경우 이 부분에 있어서 아주 초보적인 단계에 밖에 이르지 못했다.

 

국내에서도 Service Platform이라는 형태로 기업 내부의 유용한 자원을 Open API화하여 밖으로 서비스하려는 움직임이 있는데, 이런 움직임이 Pass와 같은 서비스 형태로 구현되었으면 한다.

 

4. REST

작년의 하나의 화두중에 하나가 REST였다. Roy Fielding의 논문에서 소개된 아키텍쳐 스타일로 웹의 장점과 인프라를 최대한 활용한다는 개념에서 출발하였다.

 

문제는 REST는 사실상의 표준이 없다. Google이나 Amazon이 주도하는 Defactor 표준 (암묵적인 표준)은 있지만 Spec과 같은 표준이 없기 때문에, 기업에서 사용할 경우 관리(Gorverning)이 어렵다. Google이나 Amazon의 경우 자체 개발 조직과 관리 조직을 가지고 있기 때문에, 잘 관리된 형태로 REST 서비스를 제공 및 사용하고 있지만, 기업내에서 REST가 얼마나 힘을 발휘할 수 있을지 미지수다. WebService를 사용해보고 REST도 모두 사용해봤지만 개발 관점에서 드는 Burden은 REST라고 결코 낮지는 않다. WebService의 경우 이미 Infra가 잘되어 있고 개발툴이나 자동화 스크립트가 많기 때문에 실제로 JAX-WS와 같은 개발 표준을 따를 경우 개발 공수가 사실 매우 낮은 것이 사실이다.

 

국내 상황을 보면 아쉽게도, Open API를 서비스 하는 포탈에도 REST를 지원하는 업체는 없는 것으로 안다. 또한 REST의 이해도 자체도 상당히 떨어지는데 HTTP + POX (Plain Old XML)은 REST가 아니다. 대부분 XML-RPC형태를 띄는데, REST는 Resource를 정의하고, Resource 지향적인 아키텍쳐로 설계되어야 하며, 사람이 직관적으로 이해하고 쉽고, Link등을 통해서 Resource간의 관계를 정의하고 Resource의 다음 상태 전이에 대한 정의 능력등이 있어야 한다.

국내 BLOG에 올라오는 글들을 보면 Jersey나 Apache CXF등을 이용하여 REST를 구현하는 샘플이나 예제는 종종 올라오지만, REST를 아키텍쳐 관점에서 접근하는 글은 매우 드문 것 같다. (아직까지는 못봤다.)

 

어쨌거나, REST가 JAX-RS로 JSR311 표준으로 등록되었고, WSDL 2.0에도 REST가 반영되었기 때문에, REST의 영향력이 커진 것은 기정사실이고, Amazon도 기존의 Open API를 서서히 REST형식으로 바꾸겠다니 Service World에서는 대세인 것은 분명하나 기업 아키텍쳐에서 얼마나 힘을 발휘할지는 지켜봐야할 사항이다.

 

5. SOA Governance

SOA는 어떻게 보면 양극화가 발생하는 듯한 인상인데, 이미 SOA에 적응한 기업은 SOA에 대한 성숙도를 높이기 위한 해가 될테이고 아직도 SOA를 시작하지 못한 기업은 이미 어느정도 성숙된 SOA 플랫폼과 개념을 바탕으로 SOA를 시작할것이다.

공통점은 이미 여러 SOA 프로젝트를 통해서 거버넌스의 중요성이 인식되었기 때문에 무엇보다 거버넌스에 많은 집중을 할 해가 될것이라고 생각되며 REST의 영향을 받아서 Restful webservice 기반의 SOA가 시험될 해라고 생각된다.

 

6. Mobile platform

모바일 플랫폼에 대해서는 더 이상 말할 필요가 없을 것 같다. Google의 Android, Apple의 AppStore, Nokia의 모바일 플랫폼에 이어서 MS나 기타 모바일 업체도 일반 개발자들에게 개발 환경을 오픈함으로써 User created contents(application)을 생산하게 하고 이 과정에서 수익을 창출하는 비즈니스 모델이 유행이 될것이다. 아마 금년은 이 모바일 플랫폼의 최고 격전의 해가 되지 않을까?

 

7. Collaboration

협업에 대해서는 ALM과 Agile 방법론이 금년에도 작년에 이어서 크게 유행할것이고 좀더 실용적이고 실질적인 개발 및 협업 프로세스의 발전과 이를 구현하는 도구들이 사용될 것이다. 작년에 비해서 크게 변화한 점이 있기 보다는 좀더 성숙된 형태로 발전하는 해가 되지 않을까 싶다.

 

'엔터프라이즈 솔루션' 카테고리의 다른 글

Apache Camel note  (0) 2013.02.12
아키텍쳐에 있어서 레퍼런스의 중요성  (2) 2009.10.20
2009년 기술 전망  (2) 2009.01.06