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


Archive»


 
 

쿠버네티스 #6

Replication Controller를 이용하여 서비스 배포하기

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


1. 도커 파일 만들기

node.js로 간단한 웹서버를 만들어서 도커로 패키징 해보자.

실습을 진행하기 위해서 로컬 환경에 도커와, node.js 가 설치되어 있어야 한다. 이 두 부분은 생략하도록 한다.

여기서 사용한 실습 환경은 node.js carbon 버전 (8.11.3), 도커 맥용 18.05.0-ce, build f150324 을 사용하였다.

node.js 애플리케이션 준비하기

node.js로 간단한 웹 애플리케이션을 제작해보자 server.js라는 이름으로 아래 코드를 작성한다.

var os = require('os');

 

var http = require('http');

var handleRequest = function(request, response) {

 response.writeHead(200);

 response.end("Hello World! I'm "+os.hostname());

 

 //log

 console.log("["+

               Date(Date.now()).toLocaleString()+

               "] "+os.hostname());

}

var www = http.createServer(handleRequest);

www.listen(8080);


이 코드는 8080 포트로 웹서버를 띄워서 접속하면 “Hello World!” 문자열과 함께, 서버의 호스트명을 출력해준다. 그리고 stdout에 로그로, 시간과 서버의 호스트명을 출력해준다.

코드 작성이 끝났으면, 서버를 실행해보자

%node server.js


다음 브라우저로 접속하면 다음과 같은 결과를 얻을 수 있다.


그리고 콘솔화면에는 아래와 같이 시간과 호스트명이 로그로 함께 출력된다.

도커로 패키징하기

그러면 이 node.js 애플리케이션을 도커 컨테이너로 패키징 해보자

Dockerfile 이라는 파일을 만들고 아래 코드를 작성한다.

FROM node:carbon

EXPOSE 8080

COPY server.js .

CMD node server.js > log.out


이 코드는 node.js carborn (8.11.3) 컨테이너 이미지를 베이스로 한후에,  앞서 작성한 server.js 코드를 복사한후에, node server.js > log.out 명령어를 실행하도록 하는 컨테이너를 만드는 설정파일이다.

설정 파일이 준비되었으면,  도커 컨테이너 파일을 만들어보자


% docker build -t gcr.io/terrycho-sandbox/hello-node:v1 .


docker build  명령은 컨테이너를 만드는 명령이고, -t는 빌드될 이미지에 대한 태그를 정하는 명령이다.

빌드된 컨테이너 이미지는 gcr.io/terrycho-sandbox/hello-node로  태깅되는데, 이는 향후에 구글 클라우드 컨테이너 레지스트리에 올리기 위해서 태그 명을 구글 클라우드 컨테이너 레지스트리의 포맷을 따른 것이다. (참고 https://cloud.google.com/container-registry/docs/pushing-and-pulling)

포맷은 [HOST_NAME]/[GOOGLE PROJECT-ID]/[IMAGE NAME]


gcr.io/terrycho-sandbox는 도커 이미지가 저장될 리파지토리의 경로를 위의 규칙에 따라 정의한 것인데,

  • gcr.io는 구글 클라우드 컨테이너 리파지토리 US 리전을 지칭하며,

  • terrycho-sandbox는 본인의 구글 프로젝트 ID를 나타낸다.

  • 이미지명을 hello-node 로 지정하였다.

  • 마지막으로 콜론(:) 으로 구별되어 정의한 부분은 태그 부분으로, 여기서는 “v1”으로 태깅을 하였다.


이미지는 위의 이름으로 지정하여 생성되어 로컬에 저장된다.




빌드를 실행하면 위와 같이 node:carbon 이미지를 읽어와서 필요한 server.js 파일을 복사하고 컨테이너 이미지를 생성한다.

컨테이너 이미지가 생성되었으면 로컬 환경에서 이미지를 기동 시켜보자


%docker run -d -p 8080:8080 gcr.io/terrycho-sandbox/hello-node:v1


명령어로 컨테이너를 실행할 수 있다.

  • -d 옵션은 컨테이너를 실행하되, 백그라운드 모드로 실행하도록 하였다.

  • -p는 포트 맵핑으로 뒤의 포트가 도커 컨테이너에서 돌고 있는 포트이고, 앞의 포트가 이를 밖으로 노출 시키는 포트이다 예를 들어 -p 9090:8080 이면 컨테이너의 8080포트를 9090으로 노출 시켜서 서비스 한다는 뜻이다. 여기서는 컨테이너 포트와 서비스로 노출 되는 포트를 동일하게 8080으로 사용하였다.


컨테이너를 실행한 후에, docker ps 명령어를 이용하여 확인해보면 아래와 같이 hello-node:v1 이미지로 컨테이너가 기동중인것을 확인할 수 있다.



다음 브라우져를 통해서 접속을 확인하기 위해서 localhost:8080으로 접속해보면 아래와 같이 Hello World 와 호스트명이 출력되는 것을 확인할 수 있다.


로그가 제대로 출력되는지 확인하기 위해서 컨테이너 이미지에 쉘로 접속해보자

접속하는 방법은


% docker exec -i -t [컨테이너 ID] /bin/bash

를 실행하면 된다. 컨테이너 ID 는 앞의 docker ps 명령을 이용하여 기동중인 컨테이너 명을 보면 처음 부분이 컨테이너 ID이다.

hostname 명령을 실행하여 호스트명을 확인해보면 위에 웹 브라우져에서 출력된 41a293ba79a7과 동일한것을 확인할 수 있다. 디렉토리에는 server.js 파일이 복사되어 있고, log.out 파일이 생성된것을 볼 수 있다.  

cat log.out을 이용해서 보면, 시간과 호스트명이 로그로 출력된것을 확인할 수 있다.



2. 쿠버네티스 클러스터 준비

구글 클라우드 계정 준비하기

구글 클라우드 계정 생성은 http://bcho.tistory.com/1107 문서를 참고하기 바란다.

쿠버네티스 클러스터 생성하기

쿠버네티스 클러스터를 생성해보자, 클러스터 생성은 구글 클라우드 콘솔의 Kubernetes Engine > Clusters 메뉴에서 Create 를 선택하면 클러스터 생성이 가능하다.



클러스터 이름을 넣어야 하는데, 여기서는 terry-gke-10 을 선택하였다. 구글 클라우드에서 쿠버네티스 클러스터는 싱글 존에만 사용가능한 Zonal 클러스터와 여러존에 노드를 분산 배포하는 Regional 클러스터 두 가지가 있는데, 여기서는 하나의 존만 사용하는 Zonal 클러스터를 설정한다. (Regional은 차후에 다루도록 하겠다.)

다음 클러스터를 배포한 존을 선택하는데, asia-northeast1-c (일본)을 선택하였다.

Cluster Version은 쿠버네티스 버전인데, 1.10.2 버전을 선택한다.

그리고 Machine type은 쿠버네티스 클러스터의 노드 머신 타입인데, 간단한 테스트 환경이기 때문에,  2 CPU에 7.5 메모리를 지정하였다.

다음으로 Node Image는 노드에 사용할 OS 이미지를 선택하는데, Container Optimized OS를 선택한다. 이 이미지는 컨테이너(도커)를 운영하기 위해 최적화된 이미지이다.

다음으로는 노드의 수를 Size에서 선택한다. 여기서는 3개의 노드를 운용하도록 설정하였다.


아래 부분에 보면  Automatic node upgrades 라는 기능이 있다.


구글 클라우드의 재미있는 기능중 하나인데, 쿠버네티스 버전이 올라가면 자동으로 버전을 업그레이드 해주는 기능으로, 이 업그레이드는 무정지로 진행 된다.


gcloud 와 kubectl 설치하기

클러스터 설정이 끝났으면 gloud (Google Cloud SDK 이하 gcloud)를 인스톨한다.

gcloud 명령어의 인스톨 방법은 OS마다 다른데, https://cloud.google.com/sdk/docs/quickstarts 문서를 참고하면 된다.

별다른 어려운 작업은 없고, 설치 파일을 다운 받아서 압축을 푼후에, 인스톨 스크립트를 실행하면 된다.


kubectl은 쿠버네티스의 CLI (Command Line Interface)로, gcloud를 인스톨한후에,

%gcloud components install kubectl

명령을 이용하면 인스톨할 수 있다.

쿠버네티스 클러스터 인증 정보 얻기

gcloud와 kubectl 명령을 설치하였으면, 이 명령어들을 사용할때 마다 쿠버네티스에 대한 인증이 필요한데, 인증에 필요한 인증 정보는 아래 명령어를 이용하면, 자동으로 사용이 된다.

gcloud container clusters get-credentials CLUSTER_NAME

여기서는 클러스터명이 terry-gke10이기 때문에,

%gcloud container clusters get-credentials terry-gke-10

을 실행한다.


명령어 설정이 끝났으면, gcloud 명령이 제대로 작동하는지를 확인하기 위해서, 현재 구글 클라우드내에 생성된 클러스터 목록을 읽어오는 gcloud container clusters list 명령어를 실행해보자



위와 같이 terry-gke-10 이름으로 asia-northeast1-c 존에 쿠버네티스 1.10.2-gke.3 버전으로 클러스터가 생성이 된것을 볼 수 있고, 노드는 총 3개의 실행중인것을 확인할 수 있다.

3. 쿠버네티스에 배포하기

이제 구글 클라우드에 쿠버네티스 클러스터를 생성하였고, 사용을 하기 위한 준비가 되었다.

앞에서 만든 도커 이미지를 패키징 하여, 이 쿠버네티스 클러스터에 배포해보도록 하자.

여기서는 도커 이미지를 구글 클라우드내의 도커 컨테이너 레지스트리에 등록한 후, 이 이미지를 이용하여 ReplicationController를 통해 총 3개의 Pod를 구성하고 서비스를 만들어서 이 Pod들을 외부 IP를 이용하여 서비스를 제공할 것이다.

도커 컨테이너 이미지 등록하기

먼저 앞에서 만든 도커 이미지를 구글 클라우드 컨테이너 레지스트리(Google Container Registry 이하 GCR) 에 등록해보자.

GCR은 구글 클라우드에서 제공하는 컨테이너 이미지 저장 서비스로, 저장 뿐만 아니라, CI/CD 도구와 연동하여, 자동으로 컨테이너 이미지를 빌드하는 기능, 그리고 등록되는 컨테이너 이미지에 대해서 보안적인 문제가 있는지 보안 결함을 스캔해주는 기능과 같은 다양한 기능을 제공한다.


컨테이너 이미지를 로컬환경에서 도커 컨테이너 저장소에 저장하려면 docker push라는 명령을 사용하는데, 여기서는 GCR을 컨테이너 이미지 저장소로 사용할 것이기 때문에, GCR에 대한 인증이 필요하다.

인증은 한번만 해놓으면 되는데

%gcloud auth configure-docker

명령을 이용하면, 인증 정보가 로컬 환경에 자동으로 저장된다.



인증이 완료되었으면, docker push 명령을 이용하여 이미지를 GCR에 저장한다.

%docker push gcr.io/terrycho-sandbox/hello-node:v1


명령어를 실행하면, GCR에 hello-node 이미지가 v1 태그로 저장된다.


이미지가 GCR에 잘 저장되었는지를 확인하기 위해서 구글 클라우드 콘솔에 Container Registry (GCR)메뉴에서 Images라는 메뉴를 들어가보자




아래와 같이 hello-node 폴더에 v1이라는 태그로 이미지가 등록된것을 확인할 수 있다.

ReplicationController 등록

컨테이너 이미지가 등록되었으면 이 이미지를 이용해서 Pod를 생성해보자,  Pod 생성은 Replication Controller (이하 rc)를 생성하여, rc가 Pod 생성 및 컨트롤을 하도록 한다.


다음은 rc 생성을 위한 hello-node-rc.yaml 파일이다.


apiVersion: v1

kind: ReplicationController

metadata:

 name: hello-node-rc

spec:

 replicas: 3

 selector:

   app: hello-node

 template:

   metadata:

     name: hello-node-pod

     labels:

       app: hello-node

   spec:

     containers:

     - name: hello-node

       image: gcr.io/terrycho-sandbox/hello-node:v1

       imagePullPolicy: Always

       ports:

       - containerPort: 8080


hello-node-rc 라는 이름으로 rc를 생성하는데, replica 를 3으로 하여, 총 3개의 pod를 생성하도록 한다.

템플릿 부분에 컨테이너 스팩에 컨테이너 이름은 hello-node로 하고 이미지는 앞서 업로드한 gcr.io/terrycho-sandbox/hello-node:v1 를 이용해서 컨테이너를 만들도록 한다. 컨테이너의 포트는 8080을 오픈한다. 템플릿 부분에서 app 이라는 이름의 라벨을 생성하고 그 값을 hello-node로 지정하였다. 이 라벨은 나중에 서비스 (service)에 의해 외부로 서비스될 pod들을 선택하는데 사용 된다.


여기서 imagePullPolicy:Always  라고 설정한 부분이 있는데, 이는 Pod를 만들때 마다 매번 컨테이너 이미지를 확인해서 새 이미지를 사용하도록 하는 설정이다.  컨테이너 이미지는 한번 다운로드가 되면 노드(Node) 에 저장이 되어 있게 되고, 사용이 되지 않는 이미지 중에 오래된 이미지는 Kublet이 가비지 컬렉션 (Garbage collection) 정책에 따라 이미지를 삭제하게 되는데, 문제는 노드에 이미 다운되어 있는 이미지가 있을 경우 컨테이너 생성시 노드에 이미 다운로드 되어 있는 이미지를 사용한다. 컨테이너 리파지토리에 같은 이름으로 이미지를 업데이트 하거나 심지어 그 이미지를 삭제하더라도 노드에 이미지가 이미 다운로드 되어 있으면 다운로드된 이미지를 사용하기 때문에, 업데이트 부분이 반영이 안된다.

이를 방지하기 위해서 imagePullPolicy:Always로 해주면 컨테이너 생성시마다 이미지 리파지토리를 검사해서 새 이미지를 가지고 오기 때문에, 업데이트된 내용을 제대로 반영할 수 있다.


%kubectl create -f hello-node-rc.yaml


명령어를 실행해서 rc와 pod를 생성한다.




위의 그림과 같이 3개의 Pod가 생성된것을 확인할 수 있는데, Pod가 제대로 생성되었는지 확인하기 위해서 hello-node-rc-rsdzl pod에서 hello-node-rc-2phgg pod의 node.js 웹서버에 접속을 해볼 것이다.

아직 서비스를 붙이지 않았기 때문에, 이 pod들은 외부 ip를 이용해서 서비스가 불가능하기 때문에, 쿠버네티스 클러스터 내부의 pod를 이용하여 내부 ip (private ip)간에 통신을 해보기 위해서 pod에서 pod를 호출 하는 것이다. kubectl describe pod  [pod 명] 명령을 이용하면, 해당 pod의 정보를 볼 수 있다. hello-node-rc-2hpgg pod의 cluster ip (내부 ip)를 확인해보면 10.20.1.27 인것을 확인할 수 있다.


kubectl exec 명령을 이용하면 쉘 명령어를 실행할 수 있는데, 다음과 같이 hello-node-rc-rsdzl pod에서 첫번째 pod인 hello-node-rc-2phgg의 ip인 10.20.1.27의 8080 포트로 curl 을 이용해 HTTP 요청을 보내보면 다음과 같이 정상적으로 응답이 오는 것을 볼 수 있다.


Service 등록

rc와 pod 생성이 끝났으면 이제 서비스를 생성해서 pod들을 외부 ip로 서비스 해보자

다음은 서비스를 정의한 hello-node-svc.yaml 파일이다.


hello-node-svc.yaml

apiVersion: v1

kind: Service

metadata:

 name: hello-node-svc

spec:

 selector:

   app: hello-node

 ports:

   - port: 80

     protocol: TCP

     targetPort: 8080

 type: LoadBalancer


Selector 부분에 app:hello-node 로 지정하여, pod들 중에 라벨의 키가 app이고 값이 hello-node인 pod 들만 서비스에 연결하도록 지정하였다. 다음 서비스의 포트는 80으로 지정하였고, pod의 port는 8080으로 지정하였다.


서비스가 배포되면 위와 같은 구조가 된다.

%kubectl create -f hello-node-svc.yaml

명령을 이용하면 서비스가 생성이 된다.


다음 생성된 서비스의 외부 ip를 얻기 위해서 kubectl get svc 명령을 실행해보자

아래 그림과 같이 35.200.40.161 IP가 할당된것을 확인할 수 있다.


이 IP로 접속을 해보면 아래와 같이 정상적으로 응답이 오는 것을 확인할 수 있다.


RC 테스트

rc는 pod의 상태를 체크하다가 문제가 있으면 다시, pod를 기동해주는 기능을 한다.

이를 테스트하기 위해서 강제적으로 모든 pod를 제거해보자. kubectl delete pod --all을 이용하면 모든 pod를 제거할 수 있는데, 아래 그림을 보면, 모든 pod를 제거했더니 3개의 pod가 제거되고 새롭게 3개의 pod가 기동되는 것을 확인할 수 있다.



운영중에 탄력적으로 pod의 개수를 조정할 수 있는데, kubectl scale 명령을 이용하면 된다.

kubectl scale --replicas=[pod의 수] rc/[rc 명] 식으로 사용하면 된다. 아래는 pod의 수를 4개로 재 조정한 내용이다.



자원 정리

테스트가 끝났으면 서비스, rc,pod를 삭제해보자.

  • 서비스 삭제는 kubectl delete svc --all 명령어를 이용한다.

  • rc 삭제는 kubectl delete rc --all

  • pod 삭제는 kubectl delete pod --all

을 사용한다.

삭제시 주의할점은 pod를 삭제하기 전에 먼저 rc를 삭제해야 한다. 아니면, pod가 삭제된 후 rc에 의해서 다시 새로운 pod가 생성될 수 있다.


Spinnaker #1 - 소개


Spinnaker

Spinnaker 는 넷플릭스에서 개발하여 오픈 소스화한 멀티 클라우드를 지원하는 Continuous Delivery Platform 이다. 구글 클라우드, 아마존, 마이크로소프트등 대부분의 메이져 클라우드를 지원하며, Kubernetes 나, OpenStack 과 같은 오픈소스 기반의 클라우드 또는 컨테이너 플랫폼을 동시에 지원한다.

시나리오

Spinnaker 의 특징은 멀티 클라우드 지원성뿐만 아니라, 오케스트레이션 파이프라인 구조를 지원한다 특징인데,  배포 단계는 여러개의 스텝이 복합적으로 수행되는 단계이기 때문에, 복잡한 워크 플로우에 대한


관리가 필요하다.

하나의 배포 시나리오를 통해서 오케스트레이션 파이프라인에 대해서 이해해보도록 하자

  • 코드를 받아서 빌드를 하고,

  • 빌드된 코드를 VM에 배포하여 이미지로 만든 후에, 해당 이미지를 테스트한다.

  • 테스트가 끝나면, Red/Black 배포를 위해서 새버전이 배포된 클러스터를 생성한 후에

  • 새 클러스터에 대한 테스트를 끝내고

  • 새 클러스터가 문제가 없으면 트래픽을 새 클러스터로 라우팅한다.

  • 다음으로는 구버전 클러스터를 없앤다.

각 단계에서 다음 단계로 넘어가기 위해서는 선행 조건이 필요하다. 예를 들어 이미지가 빌드가 제대로 되었는지 안되었는지, 새 클러스터가 제대로 배포가 되었는지 안되었는지에 대한 선/후행 조건의 확인 들이 필요하다.

Spinnaker에서는 이러한 오케스트레이션 파이프라인을 “파이프라인”이라는 개념으로 구현하였다. 파이프라인 흐름에 대한 예를 보면 다음과 같다.


위의 파이프라인은 이미지를 찾아서 Red/Black 배포를 위해서 Production에 새로운 이미지를 배포하고, Smoke 테스트를 진행한 후에, 구 버전을 Scale down 시키고, 소스를 태깅 한다. 이때 구 버전을 Destory 하기 전에, Manual Approval (사람이 메뉴얼로 승인) 을 받고 Destory 하는 흐름으로 되어 있다.


또한  각 단계별로 하위 테스크가 있는 경우가 있다. 예를 들어 새로운 클러스터를 배포하기 위해서는 클라우드 내에 클러스터 그룹을 만들고, 그 안에 VM들을 배포한 후에, VM 배포가 완료되면 앞에 로드 밸런서를 붙이고, Health check를 설정해야 한다. 그리고 설정이 제대로 되었는지 체크를 한다음에 다음 단계로 넘어간다.


이러한 개념을 Spinnaker에서는 Stage / Steps/ Tasks/ Operation 이라는 개념으로 하위 태스크를 구현하였다. 개념을 보면 다음과 같다.



파이프라인 컴포넌트

파이프라인은 워크 플로우 형태로 구성이 가능하다. 아래 그림은 파이프라인을 정의하는 화면의 예시이다.


<그림. 파이프라인 예제>

출처 http://www.tothenew.com/blog/introduction-to-spinnaker-global-continuous-delivery/


파이프라인에서 스테이지별로 수행할 수 있는 테스크를 선택할 수 있다.  샘플로 몇가지 스테이지를 보면 다음과 같다.

  • Bake : VM 이미지를 생성한다.

  • Deploy : VM 이미지 (또는 컨테이너)를 클러스터에 배포한다.

  • Check Preconditions : 다음 단계로 넘어가기전에 조건을 체크한다. 클러스터의 사이즈 (EX. 얼마나 많은 VM이 생성되서 준비가 되었는지)

  • Jenkins : Jenkins Job 을 실행한다.

  • Manual Judgement : 사용자로 부터 입력을 받아서 파이프라인 실행 여부를 결정한다

  • Enable/Disable Server Group : 이미 생성된 Server Group을 Enable 또는  Disable 시킨다

  • Pipeline : 다른 파이프라인을 수행한다.

  • WebHook : HTTP 로 다른 시스템을 호출한다. 통상적으로 HTTP REST API를 호출하는 형


개념 구조


Spinnaker는 리소스를 관리하기 위해서, 리소스에 대한 계층구조를 정의하고 있다.



<그림. Spinnaker의 자료 구조 >

출처 : ttp://www.tothenew.com/blog/introduction-to-spinnaker-global-continuous-delivery/



가장 최상위에는 Project, 다음은 Application 을 가지고 있고, Application 마다 Cluster Service를 가지고 있고, 각 Cluster Service는 Server Group으로 구성된다. 하나하나 개념을 보자면,


Server Group 은, 동일한 서버(같은 VM과 애플리케이션)로 이루어진 서버군이다. Apache 웹서버 그룹이나 이미지 업로드 서버 그룹식으로 그룹을 잡을 수 도 있고, 이미지 서버 그룹 Version 1, 이미지 서버 그룹 Version 2 등으로 버전별로 잡는등 유연하게 서버군집의 구조를 정의할 수 있다.

이러한 서버 그룹은 Cluster 라는 단위로 묶일 수 있다.


아래 예제 그림을 통해서 개념을 좀더 상세하게 살펴보자


위의 그림은 이미지 서비스(Image service)를 제공하는 서비스를 Cluster로 정의한것이다.

위의 구조는 Image Service를 Service Group으로 정의했는데, v1,v2,v3 버전을 가지고 있고 각 버전이 Service Group으로 정의된다 (이런 이유는 멀티 버전을 이용한 카날리 테스트나 Red/Black 배포를 이용하기 위해서 여러 버전을 함께 운용하는 경우가 생긴다.)

그리고, 리전별로 별도의 Image Service를 각각 배포하는 모델이다.

리전과 멀티 클라우드의 개념은 Spinnaker 문서에 나온 자료 구조 이외에, 중요한 자료 구조인데, 리소스를 정의할때 클라우드 계정을 선택함으로써 클라우드를 선택할 수 있고, 서비스의 종류에 따라 리전을 선택하는 경우가 있는데 이 경우 리전별로 리소스를 분류해서 보여준다.


Cluster는 Application 내에서 생성될때 , Service Group을 생성시 입력하는  {Account}-{stack}-{Detail} 을 식별자로하여 Cluster를 식별한다. 같은 식별자를 가진 Service Group을 하나의 Cluster로 묶는다.

아래는 Service Group을 생성하는 화면으로 Account, Stack, Detail을 입력하는 메뉴가 있는 것을 확인할 수 있다.



아래 그림은 myapplication 이라는 이름을 갖는 Application 내에, 각각 MY-GOOGLE-ACCOUNT라는 account를 이용하여, myapplication-nodestack-cluster1과, myapplication-nodestack-cluster2 두개의 클러스터를 생성한 예제이다.





또는 자주 쓰는 구성 방식중 하나는 Red/Black (또는 Blue/Green  이라고도 함) 형태를 위해서 하나의 클러스터에 구버전과 새버전 서버 그룹을 각각 정의해놓고 구성하는 방법이 있다.


Application은 Cluster의 집합이고, Project는 Application의 집합이다.

개발하고 배포하고자 하는 시스템의 구조에 따라서 Project, Application, Cluster를 어떻게 정의할지를 고민하는 것이 중요하다.


예를 들어 하나의 서비스가 여러개의 애플리케이션으로 구성되어 있는 경우, 예를 들어 페이스북 처럼, 페이스북 앱, 웹 그리고 앱 기반 페북 메신져가 있는 경우에는 페이스북이라는 프로젝트 아래, 페이스북 앱 백앤드, 웹 백앤드, 앱 백앤드로 Application을 정의할 수 있고,각각의 Application에는 마이크로 서비스 아키텍쳐 (MSA) 방식으로 각각서 서비스를 Cluster로 정의할 수 있다.

아키텍쳐

마지막으로 Spinnaker의 내부 아키텍쳐를 살펴보도록 하자.

Spinnaker는 MSA (마이크로 서비스 아키텍쳐) 구조로 구성이 되어 있으며, 아래 그림과 같이 약 9 개의 컴포넌트로 구성이 되어 있다.



각 컴포넌트에 대해서 알아보도록 하자


  • Deck : Deck 컴포넌트는 UI 컴포넌트로, Spinnaker의 UI 웹사이트 컴포넌트이다.

  • Gate : Spinnaker는 MSA 구조로, 모든 기능을 API 로 Expose 한다, Gate는 API Gateway로, Spinnaker의 기능을 API로 Expose 하는 역할을 한다.

  • Igor : Spinnaker는 Jenkins CI 툴과 연동이 되는데, Jenkins에서 작업이 끝나면, Spinnaker Pipeline을 Invoke 하는데, 이를 위해서 Jenkins의 작업 상태를 Polling을 통해서 체크한다. Jenkins의 작업을 Polling으로 체크 하는 컴포넌트가 Igor이다.

  • Echo : 외부 통신을 위한 Event Bus로, 장애가 발생하거나 특정 이벤트가 발생했을때, SMS, Email 등으로 notification을 보내기 위한 Connector라고 생각하면 된다

  • Rosco : Rosco는 Bakering 컴포넌트로, Spinnaker는 VM또는 Docker 이미지 형태로 배포하는 구조를 지원하는데, 이를 위해서 VM이나 도커 이미지를 베이커링(굽는) 단계가 필요하다. Spinnaker는 Packer를 기반으로 하여 VM이나 도커 이미지를 베이커링 할 수 있는 기능을 가지고 있으며, Rosco가 이 기능을 담당 한다.

  • Rush : Rush는 Spinnaker에서 사용되는 스크립트를 실행하는 스크립트 엔진이다.

  • Front50 : Front 50은 파이프라인이나 기타 메타 정보를 저장하는 스토리지 컴포넌트이다.

  • Orca : Oraca는 이 모든 컴포넌트를 오케스트레이션하여, 파이프라인을 관리해주는 역할을 한다.

  • CloudDriver : 마지막으로 Cloud Driver는 여러 클라우드 플랫폼에 명령을 내리기 위한 아답터 역할을 한다.



머신 러닝 프레임웍에 대한 간단 정리


머신 러닝을 다시 시작해서 보다 보니 어떤 언어로 개발을 해야 하는지 의문이 들어서 페이스북 Server Side architecture 그룹에 올렸더니, 좋은 정보가 많이 들어왔다.

Matalab이나 R과 같은 언어는 수학 라이브러리가 풍부해서, 주로 모델을 만들어서 시뮬레이션 하는데 많이 사용되고

Python이 수학 라이브러리가 풍부해서 그런지 ML 부분에서 많이 사용되는데, Production 까지 올라가는 경우는 잘 못본거 같고, 주로 Python으로 모델을 프로토타이핑 하는 수준으로 사용되는 것으로 보인다. 아직까지 자세히는 보지 못했지만, 자바의 Spark이나 Mahout과 같은 분산 환경 지원성이 약하고, 언어의 특성상 다른 언어보다 성능이 떨어져서, 실제 Production은 다른 언어, 주로 자바를 많이 사용하는 듯 하다.


Python으로 ML을 하려면, numpy,matplot등 다양한 패키지를 설치해야 하는데, 이 경우 방화벽과 프록시가 있는 환경에서는 설치가 쉽지 않다. (몇시간을 무지 삽질했던 경험이.. Proxy를 설정해도 패키지 인스톨이 잘안되서)

Python의 경우 이런 주요 수학 라이브러리를 패키징해놓은 인스톨 패키징이 있는데

대표적으로 Continum의 아나콘다 http://continuum.io/downloads

http://www.scipy.org/ 등이 있다.

그리고 Python에서 많이 사용되는 ML 프레임웍으로는 http://scikit-learn.org/ 등이 있다.


각 언어별로 ML 지원 라이브러리와 사용 용도를 정리해놓은 글이 있다. https://github.com/josephmisiti/awesome-machine-learning


알고리즘을 직접 작성하는 경우가 대부분이겠지만, 왠만해서는 기존 알고리즘 보다 잘 만들기가 어렵기 때문에 기존 알고리즘을 잘 활용하거나 데이타 샘플링을 잘하거나 또는 구현 인프라를 최적화 하는 방안을 고려해볼 수 있겠고, 여러 알고리즘을 중첩 적용하여 조합 함으로써 좋은 결과를 이끌어내는 방법을 고려해볼 수 있겠다.
아울러 근래에는 클라우드에 ML 라이브러리를 제공하고 있기 때문에, Azure ML이나 IBM Watson등을 고려해볼 수 있다.

SSAG에서 관련된 몇가지 중요한 댓글 메모

하용호 참고로 애초에 분산환경을 활용하도록 만들어진 MLLib등을 제외하면, 자바든 C든 R이든 속도는 대동소이 합니다. 대부분 매트릭스 연산에 그쪽으로 최적화된 LAPACK이나 BLAS, 돈 좀 쓰면 MKL등의 라이브러를 가져다가 쓰게 되어 있어서요. 뭐랄까 다들 같은 육수집에서 육수 받아서 쓴다랄까. 파이썬 쓰세요 파이썬 ㅎㅎㅎ 으하핫

민경국 mvn clean package -DskipTests 가 문제없이 돌아가는 방화벽 상황이라면 제플린으로 스프크와 스파크ML 을 보시는 건 어떨지요?
mvn 명령 한방으로 제플린 + 스파크가 설치되니 학습하기 좋은것 같습니다.
...더 보기

서민구 R이 싫으면 파이썬이 좋은데 설치가 잘 안된다니 안타깝네요. Pandas, numpy, scipy, scikitlearn, nltk 정도만 있어도 좋은데요. 언어가 파이썬이라 개발자들이 쉽게 배우구요. 통계분석 라이브러리는 문서화가 미비하지만 scikitlearn 의 문서는 대단히 훌륭합니다.

KwangHo Yoon 몇년전에는 직접 구현하는 걸 선호했는데.. 지금은 python이나 R이 라이브러리가 너무 좋아서 저도 파이썬을 사용하고 있습니다. PredictionIO나 h2o를 사용하시면 hbase나 spark등의관리를 편하게 해주어서..대용량의 데이터를 처리할 때에도 머신 러닝에 더 집중하여 개발할 수 있습니다.h2o에도 위에서 말씀하신 제플린과 비슷한 h2o flow가 있는데..인터렉티브한 화면으로 예측 결과까지 제공합니다 https://www.youtube.com/watch?v=wzeuFfbW7WE



한마디로 이야기 하자면

- "대단한 서비스이다."

- "멀티미디어 컨텐츠에 대해서 End2End 시나리오를 지원한다."

- "독보적인 서비스이다"

 

주관적인 생각이지만 그만큼 가치가 있는 서비스라고 생각한다.

2012년 6월8일 한국 시간 오전 5시에 Windows Azure의 새 버전이 발표되었다. 여기에 클라우드 서비스로 추가된 것이 'Windows Azure Media Services"이다.

 

이 서비스의 시나리오를 요약하자면

1) [업로드] 컨텐츠 사업자가 Azure에 멀티미디어 컨텐츠를 업로드 하면,

2) [워크플로우] 사용자가 정한 컨텐츠 처리 로직을 수행하게 되는데

3) [인코딩] 컨텐츠를 필요한 포맷으로 인코딩 하고

4) [Ingestion] 각종 후처리 (광고 삽입,메타데이타 추출등)를 거치고

5) [DRM] 필요에 따라 컨텐츠에 DRM을 삽입해준다.

6) [저장] 이렇게 후처리가 끝난 컨텐츠들은 Azure에 저장이 되고

7) [배포] 사용자가 원하는 시스템으로 컨텐츠를 전송하거나 또는 CDN으로 배포가 된다.

8) [서비스] 이렇게 배포된 서비스는 Azure에서 제공하는 CDN을 통해서 Streaming 서비스가 가능하게 된다.

9) [Adaptive Streaming] Streaming시에 단말 사용자가 접속한 인터넷 회선 사항에 따라서 컨텐츠의 인코딩 품질을 조정하면서 끊김없는 동영상 서비스를 가능하게 한다.

10) [클라이언트 지원] Streaming등의 컨텐츠 서비스를 위해서 윈도우즈 플랫폼 뿐만 아니라 애플 iOS 플랫폼용 SDK까지 제공하여, 단말 개발까지 지원한다.

 

위에서 시나리오를 설명하였지만, 한마디로 멀티미디어 컨텐츠 생성을 제외한 저장,후처리,스트리밍 서비스 및 개발 지원까지의 Full 시나리오를 지원하며, 워크 플로우를 통해서 컨텐츠 후처리 로직을 다양하게 설정할 수 있다.

 

이번 Azure 업그레이드에서 주목할만한점중 하나는 "개방성"인데, Media Services에도 이 개방성의 사상이 반영 되었다. 즉, DRM, CDN등에 대해서 Third Party Solution과 Integration이 가능하다. CDN은 Akamai를 Streaming 서비스는 Wowza를 DRM에는 BuyDRM,EZDRM들을 이미 지원하고 있다.

 

아직 정식 서비스가 아닌 시범 서비스 단계이기는 하지만 멀티미디어 컨텐츠 서비스를 위한 강력한 클라우드 서비스 플랫폼임에는 틀림이 없고, 비용이 많이 들고 복잡도가 높은 멀티미디어 서비스를 클라우드 환경에서 플랫폼 형태로 제공함으로써 많은 사용자 서비스를 만들어내는데 기여할것으로 기대된다.

 

 아마존 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)를 가지고 있으며, 각각의 특성도 매우 다르기 때문에, 업무의 특성을 이해하고, 기술의 특성을 이해해서 클라우드 지향형 아키텍쳐를 설계해서 시스템을 개발해야 한다. 이러한 이해가 없이 그냥 서비스를 클라우드에 배포한다면, 오히려 더 낮은 안정성과 성능 그리고 높은 비용을 지불해야 할 것이다.

 

 


Microsoft Cloud Platform은 전통적인 Iaas,Paas 뿐만 아니라 그위에 CRM ,Exchange ,Office ,SharePoint 등 다양한 형태의 소프트웨어를 서비스 형태로 제공하고, Xbox Live Windows Live와 같은 애플리케이션 서비스도 제공한다. 그러나 본 문서에서는 전체 Microsoft Cloud에 대한 설명을 하는 것이 아니라 엔터프라이즈 애플리케이션 개발과 배포를 위한 클라우드에 대한 부분에 초점을 맞추기 때문에, Paas Microsoft Windows Azure에 대해서 설명하도록 한다.


Azure Compute

Azure는 기본적으로 Paas 형의 클라우드다. Iaas 형태의 클라우드가 OS까지만 제공한다면, Paas형태의 클라우드는 아래 그림과 같이 애플리케이션을 수행 할 수 있는 Runtime과 각종 Middleware (Web Application Server, DBMS, Service Bus etc)등을 포함해서 서비스로 제공한다.

Iaas의 경우에는 이렇게 사전 제공되는 형태의 플랫폼이 없기 때문에 고객 마음대로 플랫폼을 설치 구성할 수 있기 때문에 요구사항에 대한 유연성이 매우 높지만, 반대로 플랫폼에 대한 구입,설치 및 설정과 유지보수에 대해서는 모두 고객이 책임져야 하기 때문에 그만큼 비용과 관리 인력,시간이 소요된다.

 Azure Paas형태의 클라우드 서비스로 .NET 기반의 플랫폼과 Microsoft 기반의 미들웨어는 물론이고, PHP,JAVA와 같은 다른 기술을 지원할 수 있는 플랫폼 서비스를 제공한다.


<그림. Iaas Paas의 차이 >

 

Web Role & Worker Role

이러한 애플리케이션 서비스 모델을 Azure Compute라고 하고, 각 구체적은 서비스 모델에 따라서 ‘Role’이라는 개념으로 정의되는데, 크게 “Web Role”“Worker Role” 로 분리된다.

Web Role ASP.NET 기반의 웹 애플리케이션 서비스를 하기 위한 프로세스 모델로 생각하면 된다. IIS(Internet Information Server)내에서 기동이 된다.
 Worker Role
은 백 그라운드 작업을 하기 위한 Role로 생각하면 된다. HTTP 인터페이스를 가지지 않고 TCP Q등을 통해서 Invoke가 되고, Windows Server의 서비스 프로세스로 기동된다
.
Web Role
자체는 추가적인 설명이 필요 없을 듯 하고, Worker Role은 일종의 Unix Process(?)와 유사한 개념으로 생각하면 되는데, 자바 진영의 MDB (Message Driven Bean)과 같은 개념으로도 사용될 수 있고, TP Monitor들의 서비스 프로세스와 같은 개념으로도 사용될 수 있다.

흥미로운 것 중의 하나는 Worker Role을 이용하여 요즘 유행하는 Map & Reduce (하나의 거대 작업을 작은 단위로 나눠서 패레럴 하게 처리한 후 합쳐서, 전체 성능을 끌어올리는 알고리즘) 을 구현할 수 있다. Map & Reduce를 수행하기 위해서는 앞단에서 작업을 분배해주는 작업 큐와, 작업 내용을 저장할 저장소가 필요한데, 이는 Windows Azure Storage Service Queue Service를 이용해서, Worker Role에 작업을 분산 지정할 수 있고, Storage Service Blob이나 Table Storage를 이용하여 작업 내용을 저장할 수 있다.

VM Role

이번에 PDC 2010에서 새로 발표된 Role로써는 VM Role이 있다. Amazon EC2 AMI와 같은 형태의 Iaas 서비스라고 생각하면 된다. VM Role 이전에 Windows Azure Paas 성격이 강했으나, 이번 VM Role의 추가로, Windows 기반의 Iaas 서비스가 가능하게 되었다. OS Virtual Machine Image를 통째로 VM Role에 올려서 독립적인 OS를 사용할 수 있다.

장점중의 하나는 Windows Server 2008로 운영하고 있는 on premise 시스템을 통째로 이미지로 떠서 그대로 Azure Compute VM Role에 옮겨서 운영할 수 있다는 것이다. Windows Server Base 라면 한번에 클라우드로 전환이 가능하게 된다.

Blob Storage Service

다음은 Blob Storage이다. 이미지,동영상 또는 큰 사이즈의 Binary 데이터등을 저장하는데 사용되는 서비스이다.


특징은 대용량의 저장성을 보장하고, 특히 CDN (Contents Distribution Network – 일종의 웹캐슁 서비스와 비슷하게 생각하면 된다. 각 지역 마다 캐쉬 서버를 두고 컨텐츠를 그 캐쉬 서버에 복제해서 지역적인 차이로 인한 다운로드 속도를 절감해준다.)과의 연동을 통해서 Blob Data를 원거리에서 접근하는데 성능을 보장한다.

SNS 서비스에서 이미지,동영상 저장 서비스나, 일반 기업에서 Archiving 서비스 (경비 지출서에 영수증등을 스캔해서 몇 년동안 저장해야 하는 기업 내부 규정)등에 유용하게 사용될 수 있다.

Table Storage Service

말 그대로 테이블 형태로 데이터를 저장한다. 사용자당 여러 개의 테이블을 소유할 수 있으며, 각 테이블은 다수의 컬럼으로 정의된 행을 포함한다. 그냥 편하게 RDBMS의 하나의 테이블이나, 엑셀 테이블 하나 생각하면 된다.

(데이터 구조에 대한 설명은 Apache Cassandra와 유사하기 때문에 http://bcho.tistory.com/440 문서를 참고하기 바란다.)

그런데 이미 RDBMS나 다른 곳에서도 제공하는 테이블 데이터 구조를 왜 따로 정의했을까? 쉽게 생각하면 요즘 유행하는 NoSQL과 비슷한 사상으로 생각하면 된다. 복잡한 관계형 구조나 Query가 필요 없지만 데이터의 양이 상당히 크고 고성능의 접근성이 요구될 때 사용된다. 트위터가 데이타를 Cassandra와 같은 NoSQL DB에 저장하고 사용하는 것과 같이 이유이다. Amazon SimpleDB와 유사한 서비스로 생각하면 된다.

Queue Storage Service

Queue Storage는 우리가 일반적으로 프로그래밍에서 사용하는 Queue를 생각하면 된다. IBM MQ Java JMS와 같은 개념이다.


이러한 Queuing 서비스는 비동기식 처리 방식의 아키텍쳐를 구현할 때 매우 편리한데, 예를 들어 월말 정산을 한다던지, 리포트 생성과 같은 배치 처리를 하고자 할 때, 화면에서 Request를 받고 백그라운드에서 처리를 할 때 유용하게 사용된다. 자바에서 JMS – Message Driven Bean(EJB)와 같은 아키텍쳐를 구축할 수 있다.

Azure Drive

Disk Storage 서비스는 Blob Storage 서비스를 Disk Mount 해놓은 서비스이다. Blob Storage API를 통해서 접근한다면, Disk Storage Application 입장에서는 하나의 물리적인 디스크로 인식하고 접근할 수 있다. 접근 성능을 높이기 위해서 Local VM (Windows Virtual Machine) Local Cache를 둬서 성능을 보장한다.

SQL Azure

MS SQL Azure는 쉽게 이해하면 MS SQL RDBMS를 통째로 클라우드에 올려놨다고 생각하면 된다. RDBMS를 클라우드에서 사용할 수 있는 것이다. Amazon의 경우 EC2 Oracle 이미지를 올려놓고 사용할 수 있지만 클라우드 플랫폼 자체에 녹여놨다고 보기는 약간 어렵지 않을까?

SQL Azure 서비스 중에 하나 중 재미있는 것은 MS SQL Azure 노드간의 데이터 동기화나 MS SQL Azure 노드와 기업내의 SQL 서버간의 데이터 동기화가 가능하다. MS SQL 제품 내부에는 CDC (Change Data Capture) 기능을 가지고 있는데, 아마 이 모듈을 사용해서 구축된 듯하다. 이서비스의 이름은 SQL Azure Data Sync Service, CDC 기능을 쉽게 Wrapping해놔서, Web UI상에서 복제할 MS SQL Instance를 선택하고, 테이블을 선택하면 자동으로 복제가 진행된다. 아무래도 센터간 복제이기 때문에 실시간 복제는 불가능하리라 생각하고, 아래 동영상을 보니 스케쥴 기반으로 복제를 진행한다.

아래 동영상의 시연을 보면 약 1132건의 트렌젝션 (테이블 생성에서부터, 복제등을 포함해서) 미국에서 유럽 센터간 동기화를 수행하는데 11.4초 정도가 소요된다.

기업 내부에서 CDC를 통해서 데이터 베이스를 동기화 하는 경우는 근 실시간으로 이루어 지는데, Azure Data Sync Service를 통한 지역간 복제는 아무래도 복제 아키텍쳐를 스케쥴 기반으로 설계해야 한다.

AppFabric Service Bus

AppFabric Service Bus는 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합이다.

SOA에서 사용되는 Enterprise Service Bus Legacy 시스템 통합을 위한 아답터 지원, Message Exchange Pattern의 변화,Cross Cutting Concern (보안 및 로깅 처리),SLA, Message Routing Transformation에 집중을 한다면, Internet Service Bus Network간의 메시지 릴레이와 Message Exchange Pattern에 집중 되어 있다. 보안과 Message Routing,Transformation AppFabric내의 다른 서비스 (ACS WF)에 의해서 제공되니 나중에 다시 살펴보기로 하고, Azure Service Bus의 주요 목적은 서로 다른 시스템에 배포되어 있는 서비스를 서로 연결해주는 역할을 한다. 같은 Azure 클라우드 내에 있건 아니면 다른 센터간이건, 아니면 기업과 클라우드간의 연결이건, 이를 위해서 릴레이라는 개념을 사용하는데 살펴보도록 한다.

Message Relay

앞에서도 설명했듯이 Azure Service Bus의 주요 기능은 메시지에 대한 릴레이다.엔터프라이즈 시스템과 다르게 클라우드와 특히 기업내 시스템과의 통합은 거리 문제와 NAT(네트워크 주소 변환),방화벽등의 네트워크단의 이슈를 가지고 있다. 외부 시스템과 연동을 하려면 방화벽 포트도 열어줘야 하고, 네트워크 주소도 고정을 시켜야 한다. 또는 개인이 직접 외부에서 기업 내부의 서비스를 사용하려면 일일이 방화벽 포트를 열어줄 수 없으니 이런 경우에는 VPN등을 써야 하지요. 한마디로 번거롭다 이겁니다. 그래서 클라우드에 Service Bus를 놓고 Service Bus를 통해서 접근하겠다는 사상이다.

여기에 더해서 방화벽이나 NAT와 같이 서버의 주소가 변할 때 도 대응하게 하려면 어떤 방식이 필요한가? 보통 J2EE WebLogic같은 Web Application Server (WAS)도 비슷한 문제를 가지고 있다. WAS 앞단에 로드밸런서를 두고 WAS 인스턴스에 로드를 밸런싱 해주는데, 로드밸런서가 밖에 있으면 마찬가지로 방화벽 포트를 열어줘야 하는 문제가 생깁니다. 그래서 이런 문제를 막기 위해서 사용하는 기법을 역방향 프록시라는 (Reverse Proxy)라는 기법을 사용한다.

아키텍쳐는 방화벽은 특성상 밖에서는 못 들어오지만, 나가는 것은 자유롭다. 그래서 서비스를 제공하는 서버가 Service Bus로 먼저 Connection을 맺어서 Session을 열어놓고 이를 통해서 메시지를 주고 받는 방식입이다. 방화벽을 열 필요도 없고, 서비스를 제공하는 서버의 IP가 바뀐다고 해도 상관 없다.

 

Direct Connection

다음으로는 Direct Connection이라는 기능을 제공하는데, 클라우드 밖에 있는 두 애플리케이션이 Azure Service Bus를 통해서 통신을 할 때, 당연히 Cloud를 거치면 성능이 저하된다. (Azure Data Center 옆에 두 회사가 있지 않는 이상) 서로 직접 통신을 하는 게 성능상으로 가장 좋다. 그런데 앞에서도 언급했듯이, 만약에 서비스 제공 서버의 IP가 동적으로 바뀐다면 클라이언트는 서버 IP와 포트를 알 수 가 없다. (NAT에 의해서 변경이 되기 때문에)

이를 해결하기 위해서 NAT에 의해서 어떤 포트가 다음 번에 열릴지를 예측을 해서 (mutual port prediction algorithm) Service Bus가 클라이언트와 서버에 서로 상대방 애플리케이션에 주소와 포트를 알려준다. 이 기법은 주로 인터넷 메신져에서 많이 사용되는 아키텍쳐로, 일반적인 텍스트 메시지를 서버를 경유해서 릴레이하고, 파일 전송을 할 때 이런 방법으로 서로 포트를 알려줘서 전송을 하도록 한다.

Message Buffer

위에서 설명한 것 처럼 AppFabric Service Bus는 상당히 다양한 네트워킹 Feature를 가지고 있는데, 이건 .NET 기술을 기반으로 합니다. WebService REST와 같은 플랫폼 독립적인 기술에서는 위에서 설명한 것과 같은 역방향 프록시(릴레이),Direct Connection이 불가능하다. 그래서 구현할때도 .NET에서도 코딩이 기존의 WCF를 사용하는 것이 아니라 *RelayBinding이라는 것을 사용한다.

이러한 언어에 대한 종속성을 없애기 위해서 자바나 Ruby,PHP에서도 서비스 연동을 할 수 있도록 중간에 일종의 Proxy 같은 개념을 넣었는데, 그것이 Message Buffer 이다. 서비스 앞에 Message Buffer라는 서비스를 넣고, 메시지를 이 Buffer를 통해서 다른 플랫폼과 주고 받는다. 다른 플랫폼들은 Message Buffer REST (XML/HTTP)를 이용해서 접근한다.

 

Message Exchange Pattern 변환

먼저 Message Exchange Pattern이란 (이하 MEP), API 또는 Procedure의 호출 형태를 이야기 한다. 우리가 흔히 이야기 하는 SYNC,ASYNC,PUB/SUB,1:1,1:N,MultiCast 등등이 MEP에 해당하고 Service Bus API에 대한 MEP를 변환할 수 있도록 한다. MEP에 대한 Full 변환 지원은 지원하지 않는 것 같고. (필요하다면 Workflow Foundation을 이용해서 구현할 수 있으나..) SYNC 방식의 서비스를 ASYNC방식의 Fire&Forget과 같은 패턴으로 구현하는 OneWay Relay 서비스 등이 있다.

조금 더 자세한 Relay 서비스 방식에 대해서는 아래 문서를 참고하기 바란다.

http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Security 지원

처음에 설명했듯이, Service Bus의 기본 목적은 클라우드 내의 시스템과 외부의 시스템간의 통합입니다. 그래서 보안 특히 인증,인가(Authentication & Authorization 이하 A&A)는 매우 중요한 일입니다. 실제 기업 프로젝트 할 때 도 이 계정 체계 통합이 정말 골치 아픈일입니다.

Azure에서는 ACS(Access Control Service)라는 권한 컨트롤 체계를 가지고 있고, 그 중에서 클라우드 내외부의 계정을 통합할 수 있는 메커니즘을 가지고 있다.

쉽게 정리해서 보자면 클라이언트가 서비스를 요청하면, 클라우드는 기업 내부에 있는 계정 시스템에 해당 사용자가 서비스를 사용 가능한지 물어보고 가능하면 서비스를 허가 한다”. 이런 시나리오 이다.
만약 웹 기반 서비스이면 클라우드 시스템이 기업내부의 계정 시스템의 인증/인가 페이지로 Redirect한다음에 로그인 되면 원래 서비스 페이지로 다시 Redirect하는 메커니즘이다.

AppFabric Cache

AppFabric Cache는 전통적인 애플리케이션의 Cache 기능과 함께, 데이터 교환을 위한 데이터 버스 사용 시나리오 두 가지를 지원한다.

전통적인 Cache 시나리오는 DB Query 결과에 대한 Cache나 웹페이지에 대한 Cache 등을 지원할 수 있는데, 특히 웹페이지에 대한 Caching의 경우 기존 페이지를 변경하지 않고 코드 변경 없이 손쉽게 적용할 수 있기 때문에 짧은 노력으로 성능 향상과 함께, Transaction 을 절약함으로써, 하드웨어 자원을 절약할 수 있다

또한 AppFabric Cache는 클러스터 구조를 통해서 수평적으로 무제한 확장이 가능하며, Cache의 크기도 운영중에 Dynamic하게 늘이거나 줄이는 것이 가능하다.

데이터 버스로는 Cache가 여러 Instance간에 접근이 가능하고, 그 접근 속도가 매우 빠르기 때문에, Web Session공유나 Instance간의 데이터 공유의 용도로 사용될 수 가 있다. 기존의 On-premise 시스템에서는 오픈소스인 memcached, Oracle Coherence, MS Windows Server AppFabric Cache등을 사용하여 이러한 아키텍쳐를 구현하였는데,클라우드에 이 개념을 도입함으로써 특히나 어려운 클라우드 상의 Instance간의 데이터 교환을 지원할 수 있게 되었다.

AppFabric Integration

On-premise 시스템과의 통합에 있어서 네트워크 회선상의 문제뿐만 아니라, ERP,CRM등과 같은 패키지 소프트웨어에 대한 통합이 또 다른 문제로 작용한다. 이러한 패키지 소프트웨어등은 고유의 기술 (SAP ABAP , Tuxedo ATMI etc)을 사용하기 때문에 이러한 시스템과 연동을 위해서는 별도의 테크놀로지 아답터가 필요하다. 또한 통합을 지원하기 위해서는 복잡한 Process,메시지에 대한 변환, 로깅 및 추적등의 기능이 필요한데, 이러한 영역은 전통적으로 On premise 시스템에서는 EAI(Enterprise Application Integration)을 통해서 해결되어 왔다.

 Windows Azure에서는 이러한 EAI의 요건을 충족하는 Microsoft BizTalk을 클라우드에 서비스화함으로써, Cloud 시스템과 On-premise의 패키지 소프트웨어에 대한 통합을 지원하게 되었고, BAM (Business Activity Monitoring) 기능을 지원함으로써, 통합 과정에서 수행되는 프로세스 각 단계에 대한 모니터링을 가능하게 해준다.

 또한 기업간 연동을 위한 B2B Connector를 제공하며, B2B 연동에 필요한 Trading Partner 관리등의 기능을 제공한다.

AppFabric ACS (Access Control Service)

ACS 서비스는 클라우드 내에서 사용되는 계정 체계와 권한 체계에 대한 관리를 담당하고, 타 시스템 (FaceBook과 같은 온라인 서비스나, on-premise 서비스내의 계정권한 시스템)과의 통합을 지원한다.

ACS Active Directory를 근간으로 되어 있으며, 사용자 또는 그룹에 따라서 시스템에 대한 접근 권한을 설정할 수 있다. On premise 시스템에 배포된 Active Directory나 또는 다른 계정 관리 시스템과 통합할 수 있는 인터페이스를 지원하며, X.509등의 여러 credential을 지원한다.

Composite Applications

이번 PDC 2010에 발표된 새로운 서비스로, Azure내의 각종 서비스들을 Composite하여 새로운 서비스를 제공할 수 있는 기능이다. 흔히 WEB 2.0에서 말하는 Mash up과 같은 개념의 서비스로 (Yahoo Pipe와 같은 개념). Azure Integration Service가 복잡하고 Stateful Orchestration Package Software에 대한 Native 프로토콜을 이용한 Integration  담당한다면, Composite 서비스는 표준 서비스 인터페이스 (REST,SOAP etc)를 기반으로 한 Mediation 기반의 Composition을 지원한다.

 또한 Azure Composite 서비스는 단순히 Composition만을 지원하는 것이 아니라 Composite 되는 Workflow구간에 대한 모니터링과 디버깅을 지원하며 Metering 지원을 통해서 사용량 측정(과금이 필요한 경우 과금 기반 자료로 사용 가능)등의 서비스를 제공한다.


Map & Reduce on Azure

다음으로 근래에 구글등의 업체가 검색 기술 향상을 위해서 분산 파일을 기본으로 한 분산 처리 기술인 Map & Reduce를 많이 언급하고 있는데, 이는 하나의 큰 작업을 여러 개의 작업으로 나눠서 작은 컴퓨터에서 처리한 후에 하나로 합해서 PC급의 컴퓨터 여러대를 이용해서 한대의 수퍼컴퓨터와 같은 성능을 내는 아키텍쳐이다.

이미 Amazon은 오픈 소스인 Hadoop을 기반으로 해서 이 Map & Reduce 를 서비스하고 있는데, Map & Reduce는 정확하게는 Hadoop이라는 솔루션이 아니라 아키텍쳐이자 알고리즘이다. 그래서 Azure에서도 Map & Reduce가 구현이 가능하고, 사례가 있는데, Map & Reduce를 구현하는 Reference Architecture를 설명하면 다음과 같다.


o    Map 단계

먼저 처리하고자 하는 데이터를 Blob Storage에 업로드한후 Worker Role을 통해서 작업을 지시한다.

Worker Role은 작업을 작은 조각으로 나누고, 작업 명령을 Queue에 저장한다. (Queue Storage Service 이용)

o    Compute 단계

작업을 수행하는 각각의 Worker Role들은 Queue에서 작업을 하나씩 꺼내고, 처리할 데이타를 Input Data가 저장된 Storage에서 꺼내서 작업 및 계산을 수행한다.

o    Reduce 단계

작업이 끝나면 작업이 끝났다는 내용을 Output Queue에 저장하고 OutPut을 담당하는 Worker Role Queue에서 작업이 끝났다는 내용을 하나씩 받아서, 위에서 계산이 저장된 각각의 Blob Storage로부터 작업 결과를 읽어서 합치는 계산을 수행한다.

이 구조에서 Compute (계산)을 담당하는 Worker Role의 수를 탄력적으로 조정하여 Computing Power를 조절할 수 있다.

 이러한 기법은 검색 결과에 대한 계산 (Indexing), 3D 그래픽 렌더링, 대규모 수학계산, 분석에 응용이 가능하다.

Azure CDN

Azure역시 CDN 서비스를 제공하는데, 전세계 22개의 CDN 센터를 두고 Blob Storage와 연계하여 대용량 데이터에 대한 지역 차이로 오는 Latency를 극복할 수 있도록 해준다.


Azure Connect (cf. Amazon VPC)

Amazon VPC와 유사한 개념의 서비스로, On premise 시스템과 Cloud 서비스간의 연동을 위해서 Secure VPN 네트워크를 제공하여 고객에게 Private Cloud 서비스를 제공한다.

VPN망은 Private Cloud 서비스를 사용하기 위해서도 사용될 수 있지만, 개발자나 관리자를 위한 관리 인터페이스 접근을 위한 VPN으로, 또는 SQL Azure와 같은 데이터 접근시 보안을 필요로하는 경우 등에 응용되어 사용될 수 있다.

Platform Compatibility

Azure Paas인 만큼 어떤 플랫폼을 지원하는지를 확인할 필요가 있는데, Microsoft의 클라우드 플랫폼임에도 불구하고 MS기술만 지원하지는 않는다.

기본적으로 Azure 클라우드에 배포된 각종 기능 (Storage,SQL,AppFabric)등은 Microsoft .NET, Java, PHP,그리고 Ruby Client SDK를 지원하고 있고, 서버쪽에서도 애플리케이션 플랫폼으로는 .NET 뿐만 아니라, PHP Apache Tomcat기반의 Java 개발환경을 지원한다. 데이터베이스 관점에서는 MS SQL이외에 MSQL을 함께 지원한다.

PDC 2010에서는 Microsoft에서 향후 Azure에 대해서 개방형 플랫폼 지원을 확장할것이며 특히 Tomcat 기반의 지원을 통해서 Java Azure First Citizen으로 만들겠다는 Vision을 발표하였다.


Azure Appliance

Microsoft Azure가 흥미로운 점 중의 하나는 Azure Platform 자체를 하드웨어를 포함하여 컨테이너 방식으로 직접 고객에게 판매한다는 것이다. Azure Appliance 라는 상품명인데, 아직 현재 테스트중이고 구체적인 판매 가격 등은 미정인 상태지만, eBay를 비롯하여 DELL,HP,Fujitsh 등을 대상으로 고객 테스트를 진행중이다.


Azure Appliance Azure를 운영하기 위한 서버,네트워크 장비,공조시설,전원등이 일체형으로 설계되어 있고, Azure Paas까지 모두 인스톨되어 있는 모델로, 컨테이너를 설치와 즉시 전원 공급만으로 운영이 가능하다.

Azure Appliance를 고객사에서 사용할 경우 Azure Platform Private Cloud형태로 사용하거나 Public Cloud 형태로 다른 고객에게 서비스할 수 있다. 또한 Azure Appliance에 배포된 Application Microsoft Azure와 동일 아키텍쳐를 가지고 있기 때문에 필요에 따라서 Microsoft Azure Platform으로 손쉽게 Migration이 될 수 있다. Azure Appliance에 대한 플랫폼 유지보수와 업그레이드 역시 Microsoft 본사를 통해서 직접 이루어지기 때문에 플랫폼 운영에 대한 비용과 시간 역시 절약할 수 있다는 장점을 가질 수 있다.

 

Azure Appliance는 위의 그림에서 보는 바와 같이 Public Azure가 가진 특징 이외에 기업 특성에 맞춰진 형태의 아키텍쳐 구성이 가능하다.


Amazon 클라우드 서비스는 상용화되고 성숙된 Iaas 방식의 Public 클라우드 서비스중의 하나이다. 여기서는 Amazon 클라우드 서비스의 각각의 기능에 대해서 간략하게 소개한다.

Amazon EC2

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

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

Amazon에서 제공하는 Pre configure된 이미지들은 다음과 같다.

 

Application Development Environments

Application Servers

Video Encoding & Streaming

IBM sMash

IBM WebSphere Application Server

Wowza Media Server Pro

JBoss Enterprise Application Platform

Java Application Server

Windows Media Server

Ruby on Rails

Oracle WebLogic Server

 

 

위의 표에서 보는 것과 같이 Java,.NET,Ruby on Rails와 같은 다양한 프로그래밍 플랫폼과 Oracle, MySQL,DB2 과 같은 다양한 데이터 베이스는 물론이고 Media Server와 같은 Streaming Service, WebSphere Portal과 같은 애플리케이션 서비스도 제공할 수 있는 구조가 된다.

기본적으로 EC2는 하드웨어를 가상화하기 때문에 원하는 OS와 원하는 소프트웨어를 대부분 Install할 수 있는 장점을 가지고 있기 때문에 플랫폼에 대한 수용력이 높다.

 반대로 가상화된 하드웨어 자원에 대해서만 서비스를 제공할 뿐 그위에 설치되는 OS와 소프트웨어에 대해서는 서비스를 제공하지 않기 때문에 사용하는 사용자 입장에서는 해당 소프트웨어에 대한 라이선스 구매와 유지 보수료 지불에 대한 비용 지불 그리고 각각 소프트웨어에 대한 설치와 운영을 별도로 해야 하기 때문에 기존 on premise 방식의 운영 방식에 비해서는 하드웨어 자원을 임대하여 쓰는 것 이외에는 소프트웨어 비용에 대한 문제와 운영관점의 문제는 그대로 남아 있는 문제점을 가지고 있다.

Amazon SDB (Simple DB)

Simple DB 서비스는 Key-Value 타입의 데이터를 저장하기 위한 데이터 저장소 서비스이다. No-SQL Cassandra Hadoop 기반의 HBase와 유사하게 Key-Value 타입의 데이터를 저장하고, 대용량의 데이터 저장 및 빠른 검색을 지원하며, Value에 들어가는 데이터의 형에는 제약이 없다. 이런 특성을 Schemeless라고 하는데, 관계형 데이터 저장이 필요 없는 데이터 구조에서 데이터 저장의 유연성을 부여해준다.

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

Amazon S3 (Simple Storage Service)

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

Amazon SQS (Simple Queue Service)

SQS IBM MQ JAVA JMS와 같은 전통적인 Queue Amazon 클라우드 버전으로 생각하면 된다. Queue를 통해서 Reliable Messaging이나 Asynchronous 아키텍쳐 구성을 지원한다.

Queue에 저장되는 메시지는 개당 최대 64Kb 까지 지원하며, 최대 14일까지 Queue에 저장될 수 있다.

Amazon RDS (Relational Database Service)

RDB 서비스는 MySQL 기반의 관계형 데이터 베이스 서비스를 제공한다. 대부분의 MySQL Feature를 지원하며 (geo replication 포함)

흥미로운 특징 중의 하나는 데이터베이스 아키텍쳐중의 하나인 Query-off loading 아키텍쳐를 지원한다는 것이다. 이 아키텍쳐는 Read Transaction이 많은 경우, 하나의 Master DB Create/Update/Delete를 일으키고 여러 개의 Slave DB에 데이터를 복사하여 여러 개의 Slave DB에서 Read 관련 Transaction을 수행함으로써 Read Transaction을 분산 시켜서 대규모 처리를 가능하게 한다.

Amazon EBS (Elastic Block Storage)

EBS EC2 인스턴스에 Attach될 수 있는 가상의 하드디스크이다. 하나의 EC2 인스턴스에는 여러개의 EBS 볼륨이 마운트 될 수 있으며, 하나의 볼륨 크기는 1GB~1TB이다. 실제로 저장될 때는 S3 서비스를 이용해서 저장되는데, 흥미로운 점은 분산 파일 구조를 채택하기 때문에 IO Performance가 상당히 높은 편이며, EBS Booting Partition으로도 마운트가 가능하다.

또한 특정 시점에 EBS의 이미지를 S3에 저장하여 백업용도로 사용가능하다.

Amazon Elastic Map & Reduce

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

Amazon에서는 이 Hadoop기반의 Map & Reduce를 지원한다.

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

Amazon Elastic Load Balancing

클라우드 서비스에서 여러 개의 인스턴스를 운영하면 당연히 필요한 것이 인스턴스간의 부하분산이다. Amazon에서는 Elastic Load Balancing이라는 이름으로 진보된 형태의 부하분산 메커니즘을 제공한다.

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

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

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

Amazon Auto Scaling

클라우드에 있어서 가장 중요한 기능중 하나가, 쓴만큼 지불하되, 요구 용량이 늘어나면 서비스 가용 용량도 따라서 증가해야 한다. 인스턴스는 독립된 VM(제약된 CPU와 메모리 용량)을 기본으로 서비스를 제공하기 때문에 인스턴스에 할당된 VM의 용량을 넘어서는 경우에는 추가로 VM을 할당해줘야 한다. 이러한 일련의 작업을 자동으로 해주는 것이 Auto Scaling기능인데, Amazon EC2에서는 “CPU 사용량이 몇 %이상 또는 저장 용량이 얼마 이상과 같은 조건을 정해놓으면 조건을 일치하는 시점에 자동으로 인스턴스를 늘리는 서비스를 제공한다.

Amazon SNS (Simple Notification Service)

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

Amazon Notification Service HTTP SMTP 프로토콜만을 지원한다.

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

 

Amazon VPC (Virtual Private Cloud)

VPC서비스는 Amazon EC2 클라우드의 인스턴스와 고객사의 on-premise 시스템 사이에 VPN 을 설정하여 EC2 클라우드 인스턴스를 특정 고객사에서만 접근할 수 있도록 해주는 서비스이다.

이 서비스는 일종의 Hosted Private Cloud 모델로 EC2내의 특정 자원에 대한 접근을 특정 고객사로 Dedication 해줄 수 있는 기능을 가지고 있으나, 반대로 해당 시스템은 EC2 대외 고객은 접근이 불가능 하다. 예를 들어 쇼핑몰의 판매 정보를 EC2에서 on-premise 시스템으로 VPC를 통해서 전송하고, 고객에게는 쇼핑몰 판매 서비스를 제공하는 형태의 서비스가 불가능 하다는 것이다. (VPC 인스턴스는 on-premise 시스템과만 접속이 가능하다.)

Amazon CloudFront

CloudFront 서비스는 Amazon에서 제공하는 CDN (Contents Delivery Network) 서비스이다. Amazon S3에 저장된 Binary 데이터를 CDN 노드를 이용하여 전세계에 걸쳐서 다운로드 속도에 대한 성능을 올려주는 서비스이다. (CDN은 전세계에 여러 센터에 걸쳐서 배포되고, CDN 서버들이 일종의 캐쉬 서버 역할을 해서 거리로 인해서 발생하는 Latency를 줄여준다.)

아래 그림과 같이 CloudFront는 미국,유럽,아시아에 걸쳐 총 16개의 CDN 센터를 운영하고 있다.


United States (Ashburn, VA) (Dallas/Fort Worth, TX) (Los Angeles, CA) (Miami, FL) (New York, NY) (Newark, NJ) (Palo Alto, CA) (Seattle, WA) (St. Louis, MO)

Europe Amsterdam,Dublin,Frankfurt,London

Asia Hong Kong,Tokyo,Singapore   16개 센터

(원본 http://www.michaelgaigg.com/blog/2008/11/19/fast-faster-cloudfront-speed-matters/ )

 

Amazon Cloud Watch

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

 

지금까지 Amazon Cloud의 기능에 대해서 살펴보았다. 여기서는 플랫폼적인 기능에대해서만 주력해서 살펴보았는데, Amazon Amazon MarketPlace Customization하기 위한 Fulfilment Service, Billing/Payment Service, 그리고 다양한 Support 프로그램등을 가지고 있다. 조금 더 자세한 사항은 http://aws.amazon.com/products/ 를 참고하기 바란다.

클라우드 서비스중 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)의 개발 환경 모델이 있다.


서비스를 고객에게 제공하다 보면 바이너리 파일이 다운되는 시나리오가 많습니다.
웹사이트에서 이미지,CSS를 다운로드 하는 것은 가장 기본 적인 시나리오이고
사진 저장 및 다운로드, 영화 파일, 또는 일반 파일 다운로드 등이 그 대표적인 시나리오인데, 이런 것들을 사용자 응답시간에 아주 결정적인 영향을 미칩니다.
이런 것을 해결하기 위한것이 CDN (Contents Delivery Network)입니다. 개념은 간단하게 각 지역에 일종의 캐쉬서버를 놓고, 지역이 멀어서 발생하는 네트워크 지연을 해결하겠다는 개념입니다. 전세계적으로 Akamai가 대표적인 CDN 서비스 벤더이지요.
클라우드를 통한 서비스의 경우 아무래도 시스템이 전세계의 어딘가에 배포되어 있기 때문에 서비스 대상이 되는 지역에 서버가 없을 경우 응답속도가 느려질 수 밖에 없고, CDN의 필요성이 높게 대두 됩니다.

Windows Azure에서는 CDN 서비스를 제공하는데, Windows Azure Storage Service의 Blob Storage와 연동하여 서비스를 제공합니다.
또한 아래 그림과 같이 총 22개 지역의 데이타 센터를 통해서 CDN 서비스를 제공하기 때문에 상당히 넓은 커버리지를 자랑합니다.

Windows Azure Compute

AzureAmazon EC2와 같은 OS를 통째로 올리는 Iaas와 같은 클라우드 서비스가 아니라, 애플리케이션을 개발 및 배포할 수 있는 Paas(Platform As A Service)와 같은 개념을 가지고 있다. 쉽게 생각하면 Windows Azure는 일종의 Web Application Server (WAS) 개념으로 생각하면 된다.

Web Role & Worker Role

이러한 애플리케이션 서비스 모델을 Azure Compute라고 하고, 각 구체적은 서비스 모델에 따라서 ‘Role’이라는 개념으로 정의되는데, 크게 “Web Role”“Worker Role” 로 분리된다.

Web RoleASP.NET 기반의 웹 애플리케이션 서비스를 하기 위한 프로세스 모델로 생각하면 된다. IIS(Internet Information Server)내에서 기동이 된다.
 Worker Role
은 백 그라운드 작업을 하기 위한 Role로 생각하면 된다. HTTP 인터페이스를 가지지 않고 TCP Q등을 통해서 Invoke가 되고, Windows Server의 서비스 프로세스로 기동된다
.
Web Role
자체는 추가적인 설명이 필요 없을 듯 하고, Worker Role은 일종의 Unix Process(?)와 유사한 개념으로 생각하면 되는데, 자바 진영의 MDB (Message Driven Bean)과 같은 개념으로도 사용될 수 있고, TP Monitor들의 서비스 프로세스와 같은 개념으로도 사용될 수 있다.

흥미로운 것 중의 하나는 Worker Role을 이용하여 요즘 유행하는 Map & Reduce (하나의 거대 작업을 작은 단위로 나눠서 패레럴 하게 처리한 후 합쳐서, 전체 성능을 끌어올리는 알고리즘) 을 구현할 수 있다. Map & Reduce를 수행하기 위해서는 앞단에서 작업을 분배해주는 작업 큐와, 작업 내용을 저장할 저장소가 필요한데, 이는 Windows Azure Storage ServiceQueue Service를 이용해서, Worker Role에 작업을 분산 지정할 수 있고, Storage ServiceBlob이나 Table Storage를 이용하여 작업 내용을 저장할 수 있다.

VM Role

이번에 새로 발표된 Role로써는 VM Role이 있다. Amazon EC2 AMI와 같은 형태의 Iaas 서비스라고 생각하면 된다. VM Role 이전에 Windows Azure Paas 성격이 강했으나, 이번 VM Role의 추가로, Windows 기반의 Iaas 서비스가 가능하게 되었다. OSVirtual Machine Image를 통째로 VM Role에 올려서 독립적인 OS를 사용할 수 있다.

아무래도 전직이 자바 개발자인지라, Azure를 봐도 자바 지원 여부를 보게 되는데, 재미있는 자료를 몇가지 찾아서 첨부한다.


위의 동영상은 Windows Azure Platform 위에서 Tomcat을 구동 시킬 수 있는 방법에 대한 글이다. 이클립스 연동도 되고 대충 쓸만해 보인다. 일반적인 웹 애플리케이션은 그럭저럭 기동 시킬 수 있을 텐데.. 앞뒤에 붙는 Apache Http 서버라던가, Jennifer와 같은 APM은 아마 적용하기 힘들것 같고, Thread Dump를 이용한 Trace라던가 JVM 튜닝 같은 내용의 적용이 쉽지 않아 보인다. 그냥 일반 서비스성 웹애플리케이션이나 이벤트성 서비스에는 그럭저럭 쓸 수 있을 듯 한데, 상용 서비스에서는 글쎄....??

이건 Azure Storage Service들을 Java에서 사용할 수 있는 API SET
http://www.interoperabilitybridges.com/projects/windows-azure-sdk-for-java.aspx
어짜피 Azure는 REST를 지원하니 Java나 PHP,Ruby등에서 당연 사용할 수 있는 것이지만, Library Set을 지원하니 훨씬 개발하기 편한듯 하다. 샘플 코드를 보니 정말 편한데..
아무래도 대용량 데이타를 유지 관리해야 하는 서비스나, BLOB과 같은 데이타를 유지해야 하는 서비스들에 대해서는 충분히 승산이 있을듯.

Amazon EC2에는 AMI로 해서 WebLogic까지 싸악 올릴 수 있군요.
http://www.theserverlabs.com/blog/2009/05/29/setting-up-a-load-balanced-oracle-weblogic-cluster-in-amazon-ec2/
멋집니다. 라이센스를 얼마나 받을 련지 몰겠습니다마나.


Windows Azure AppFabric Service Bus

Azure 클라우드에는 AppFabric이라는 또 하나의 서비스가 있습니다. 간략하게 설명하자면 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합입니다. 그 중에서 이번에는 Service Bus에 대해서 설명해보겠습니다.
사실 이 Service Bus를 이해하는데 다소 시간이 걸렸습니다. 왜냐하면 제 기술적인 백그라운드가 SOA이고, 그 중 가장 중요한 컴포넌트 중 하나가 Enterprise Service Bus (ESB)니까요. 그런데 Azure의 Service Bus 개념은 약간 다릅니다. Internet Service Bus (ISB)라는 개념으로 설명을 하더군요.
Enterprise Service Bus가 Legacy 시스템 통합을 위한 아답터 지원, Message Exchange Pattern의 변화,Cross Cutting Concern (보안 및 로깅 처리),SLA, Message Routing 및 Transformation에 집중을 한다면,
Internet Service Bus는 Network간의 메시지 릴레이와 Message Exchange Pattern에 집중 되어 있습니다. 보안과 Message Routing,Transformation은 AppFabric내의 다른 서비스 (ACS와 WF)에 의해서 제공되니 나중에 다시 살펴보기로 하고, Azure Service Bus의 주요 목적은 서로 다른 시스템에 배포되어 있는 서비스를 서로 연결해주는 역할을 합니다. 같은 Azure 클라우드 내에 있건 아니면 다른 센터간이건, 아니면 기업과 클라우드간의 연결이건, 이를 위해서 릴레이라는 개념을 사용하는데 살펴보도록 하지요.

Message Relay
앞에서도 설명했듯이 Azure Service Bus의 주요 기능은 메시지에 대한 릴레이 입니다.엔터프라이즈 시스템과 다르게 클라우드와 특히 기업내 시스템과의 통합은 거리 문제와 NAT(네트워크 주소 변환),방화벽등의 네트워크단의 이슈를 가지고 있습니다. 외부 시스템과 연동을 하려면 방화벽 포트도 열어줘야 하고, 네트워크 주소도 고정을 시켜야 합니다. 또는 개인이 직접 외부에서 기업 내부의 서비스를 사용하려면 일일이 방화벽 포트를 열어줄 수 없으니 이런 경우에는 VPN등을 써야 하지요. 한마디로 번거롭다 이겁니다. 그래서 클라우드에 Service Bus를 놓고 Service Bus를 통해서 접근하겠다는 거지요.
여기에 더해서 방화벽이나 NAT와 같이 서버의 주소가 변할 때 도 대응하게 하려면 어떤 방식이 있을까요? 보통 J2EE의 WebLogic같은 Web Application Server (WAS)도 비슷한 문제를 가지고 있는데요. WAS 앞단에 로드밸런서를 두고 WAS 인스턴스에 로드를 밸런싱 해주는데, 로드밸런서가 밖에 있으면 마찬가지로 방화벽 포트를 열어줘야 하는 문제가 생깁니다. 그래서 이런 문제를 막기 위해서 사용하는 기법을 역방향 프록시라는 (Reverse Proxy)라는 기법을 사용합니다.
원리인 즉, 방화벽은 특성상 밖에서는 못 들어오지만, 나가는 것은 자유롭습니다. 그래서 서비스를 제공하는 서버가 Service Bus로 먼저 Connection을 맺어서 Session을 열어놓고 이를 통해서 메시지를 주고 받는 방식입니다. 방화벽을 열 필요도 없고, 서비스를 제공하는 서버의 IP가 바뀐다고 해도 상관 없습니다. 예전 웹로직 할 때 봤던 아키텍쳐인데 여기서 보니 또 새롭네요..
 

Direct Connection
다음으로는 Direct Connection이라는 기능을 제공하는데, 클라우드 밖에 있는 두 애플리케이션이 Azure Service Bus를 통해서 통신을 할 때, 당연히 Cloud를 거치면 느립니다. (Azure Data Center 옆에 두 회사가 있지 않는 이상) 서로 직접 통신을 하는 게 성능상으로 가장 좋습니다. 그런데 앞에서도 언급했듯이, 만약에 서비스 제공 서버의 IP가 동적으로 바뀐다면 클라이언트는 서버 IP와 포트를 알 수 가 없습니다. (NAT에 의해서 변경이 되기 때문에)
이를 해결하기 위해서 NAT에 의해서 어떤 포트가 다음번에 열릴지를 예측을 해서 (mutual port prediction algorithm) Service Bus가 클라이언트와 서버에 서로 상대방 애플리케이션에 주소와 포트를 알려줍니다. 이 기법은 주로 인터넷 메신져에서 많이 사용하는데요. 일반적인 텍스트 메시지를 서버를 경유해서 릴레이하고, 파일 전송을 할 때 이런 방법으로 서로 포트를 알려줘서 전송을 합니다.

Message Buffer
위에서 설명한 것 처럼 AppFabric Service Bus는 상당히 다양한 네트워킹 Feature를 가지고 있는데, 이건 .NET 기술을 기반으로 합니다. WebService나 REST와 같은 플랫폼 독립적인 기술에서는 위에서 설명한 것과 같은 역방향 프록시(릴레이),Direct Connection이 불가능하지요. 그래서 구현할때도 .NET에서도 코딩이 기존의 WCF를 사용하는 것이 아니라 *RelayBinding이라는 것을 사용하네요. 
 


어쨌든 간에, 언어에 대한 종속성을 없애기 위해서 자바나 Ruby,PHP에서도 서비스 연동을 할 수 있도록 중간에 일종의 Proxy 같은 개념을 넣었습니다. 그게 Message Buffer라는 것인데, 서비스 앞에 Message Buffer라는 서비스를 넣고, 메시지를 이 Buffer를 통해서 다른 플랫폼과 주고 받습니다. 다른 플랫폼들은 Message Buffer에 REST (XML/HTTP)를 이용해서 접근합니다.
 
일단 이렇게 해서 타 플랫폼과의 상호 운용성을 확보해주는 방법인데, Native WCF를 써서 SOAP이나 REST를 쓰는 것에 비해서 어떤 장점이 있는지는 좀 봐야 알 수 있을 것 같습니다.

Message Exchange Pattern 변환
먼저 Message Exchange Pattern이란 (이하 MEP), API 또는 Procedure의 호출 형태를 이야기 한다. 우리가 흔히 이야기 하는 SYNC,ASYNC,PUB/SUB,1:1,1:N,MultiCast 등등이 MEP에 해당하고 Service Bus는 API에 대한 MEP를 변환할 수 있도록 한다. MEP에 대한 Full 변환 지원은 지원하지 않는 것 같고. (필요하다면 Workflow Foundation을 이용해서 구현할 수 있으나..) SYNC 방식의 서비스를 ASYNC방식의 Fire&Forget과 같은 패턴으로 구현하는 OneWay Relay 서비스 등이 있다.
조금 더 자세한 Relay 서비스 방식에 대해서는 아래 문서를 참고하기 바란다.
http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Security 지원
처음에 설명했듯이, Service Bus의 기본 목적은 클라우드 내의 시스템과 외부의 시스템간의 통합입니다. 그래서 보안 특히 인증,인가(Authentication & Authorization 이하 A&A)는 매우 중요한 일입니다. 실제 기업 프로젝트 할 때 도 이 계정 체계 통합이 정말 골치 아픈일입니다.
Azure에서는 ACS(Access Control Service)라는 권한 컨트롤 체계를 가지고 있고, 그 중에서 클라우드 내외부의 계정을 통합할 수 있는 메커니즘을 가지고 있습니다.
쉽게 정리해서 보자면 “클라이언트가 서비스를 요청하면, 클라우드는 기업 내부에 있는 계정 시스템에 해당 사용자가 서비스를 사용 가능한지 물어보고 가능하면 서비스를 허가 한다”. 이런 시나리오 입니다.
만약 웹 기반 서비스이면 클라우드 시스템이 기업내부의 계정 시스템의 인증/인가 페이지로 Redirect한다음에 로그인 되면 원래 서비스 페이지로 다시 Redirect하는 메커니즘입니다.
대략 AppFabric의 모듈 중 하나인 Azure Service Bus에 대해서 살펴봤고, 다음 글에서는 AppFabric의 Work Flow 모듈과 보안 모듈(ACS)에 대해서 살펴보겠다.
 


대충 위와 같은 개념인데, ACS가 계정에 대한 통합 역할을 하는 셈입니다.
ACS는 SAML등과 같은 표준을 지원하기는 하지만 Active Directory를 잘 지원합니다. 기업의 계정 시스템이 Active Directory 기반이라면 아주 쉽게 통합이 된다는 겁니다.
그 외에도 Facebook, Open ID와 같은 SNS 기반의 ID 체계와도 통합 로그인을 할 수 있는 Feature를 제공하고 있습니다.
ACS에 대한 내용은 나중에 좀 더 알아보도록 하겠습니다.

 

Azure Data Storage Service

요즘 어찌어찌 해서, 클라우드쪽과 특히 마이크로소프트의 클라우드 플랫폼인 Azure 쪽을 보고 있는데, 상당히 흥미롭다. 국내 기업을 대상으로 서비스를 제공하고 있지 않고 국내에 .NET 개발자층이 자바쪽에 비해서 두텁지 않은 관계로, 크게 이슈화는 못 되어가고 있는 것 같지만 기술적인 관점에서는 상당히 흥미롭다. Azure를 한마디로 이야기 하자면 넣을 수 있는 건 정말 다 넣었다. CRM,Exchange 등등과 같은 소프트웨어 서비스 기반의 Saas에서부터 Windows 기반의 Iaas 까지, 거기에 SNS 통합 인증, Windows Live Service등에서 제공되는 OPEN API Integration까지 참 많기는 많다.

하여간 자세한 이야기는 나중에 올리도록 하고, 오늘은 Azure Platform의 데이터 저장 서비스에 대해서 알아보고자 한다.

기업이 클라우드를 사용하려는 근본적인 이유와, 모든 클라우드 업체들이 내세우는 클라우드의 장점은 결국 비용이다. 쓴 만큼 지불하는 비용 구조를 제공하겠다는 것인데, 컴퓨팅에서 비용은 결국 컴퓨팅 파워 (CPU)와 저장소(Storage)비용이다. 그래서 클라우드 서비스들은 강력한 Storage 서비스등을 제공한다. Amazon도 SimpleDB,S3,EBS,RDS,SQS(엄밀하게는 Queue 서비스) 등의 다양한 서비스를 제공하고 있고, Microsoft의 Azure역시 다양한 형태의 Storage 서비스를 제공한다. 일반적으로 클라우드 상의 Storage 서비스는 RDBMS 처럼 OLTP를 지원하기 위한 고급 Feature들 보다는 대용량의 데이터를 저장할 수 있는 Scalability와 대용량 데이터를 Handling할 수 있는 Performance 에 초점이 맞춰져 있다.

일단 Microsoft의 Azure의 Storage 서비스를 보면 크게 아래와 같이 5가지 형태의 서비스를 제공한다.


Table Storage
말 그대로 테이블 형태로 데이터를 저장한다. 사용자당 여러 개의 테이블을 소유할 수 있으며, 각 테이블은 다수의 컬럼으로 정의된 행을 포함한다. 그냥 편하게 RDBMS의 하나의 테이블이나, 엑셀 테이블 하나 생각하면 된다.


그런데 이미 RDBMS나 다른 곳에서도 제공하는 테이블 데이터 구조를 왜 따로 정의했을까? 쉽게 생각하면 요즘 유행하는 NoSQL과 비슷한 사상으로 생각하면 된다. 복잡한 관계형 구조나 Query가 필요 없지만 데이터의 양이 상당히 크고 고성능의 접근성이 요구될 때 사용된다. 트위터가 데이타를 Cassandra와 같은 NoSQL DB에 저장하고 사용하는 것과 같이 이유이다. Amazon의 SimpleDB와 유사한 서비스로 생각하면 된다.

Blob Storage
다음은 Blob Storage이다. 이미지,동영상 또는 큰 사이즈의 Binary 데이터등을 저장하는데 사용되는 서비스이다.


특징은 대용량의 저장성을 보장하고, 특히 CDN (Contents Distribution Network – 일종의 웹캐슁 서비스와 비슷하게 생각하면 된다. 각 지역 마다 캐쉬 서버를 두고 컨텐츠를 그 캐쉬 서버에 복제해서 지역적인 차이로 인한 다운로드 속도를 절감해준다.)과의 연동을 통해서 Blob Data를 원거리에서 접근하는데 성능을 보장한다.

SNS 서비스에서 이미지,동영상 저장 서비스나, 일반 기업에서 Archiving 서비스 (경비 지출서에 영수증등을 스캔해서 몇 년동안 저장해야 하는 기업 내부 규정)등에 유용하게 사용될 수 있다.

Disk Storage
Disk Storage 서비스는 Blob Storage 서비스를 Disk로 Mount 해놓은 서비스이다. Blob Storage가 API를 통해서 접근한다면, Disk Storage는 Application 입장에서는 하나의 물리적인 디스크로 인식하고 접근할 수 있다. 접근 성능을 높이기 위해서 Local VM에 (Windows Virtual Machine) Local Cache를 둬서 성능을 보장한다.

Queue Storage Service
 Queue Storage는 우리가 일반적으로 프로그래밍에서 사용하는 Queue를 생각하면 된다. IBM의 MQ나 Java의 JMS와 같은 개념이다.


이러한 Queuing 서비스는 비동기식 처리 방식의 아키텍쳐를 구현할 때 매우 편리한데, 예를 들어 월말 정산을 한다던지, 리포트 생성과 같은 배치 처리를 하고자 할 때, 화면에서 Request를 받고 백그라운드에서 처리를 할 때 유용하게 사용된다. 자바에서 JMS – Message Driven Bean(EJB)와 같은 아키텍쳐를 구축할 수 있다.

SQL Azure
마지막으로 SQL Azure이다. MS SQL Azure는 쉽게 이해하면 MS SQL RDBMS를 통째로 클라우드에 올려놨다고 생각하면 된다. RDBMS를 클라우드에서 사용할 수 있는 것이다. Amazon의 경우 EC2에 Oracle 이미지를 올려놓고 사용할 수 있지만 클라우드 플랫폼 자체에 녹여놨다고 보기는 약간 어렵지 않을까?

SQL Azure 서비스 중에 하나 중 재미있는 것은 MS SQL Azure 노드간의 데이터 동기화나 MS SQL Azure 노드와 기업내의 SQL 서버간의 데이터 동기화가 가능하다. MS SQL 제품 내부에는 CDC (Change Data Capture) 기능을 가지고 있는데, 아마 이 모듈을 사용해서 구축된 듯하다. 이서비스의 이름은 SQL Azure Data Sync Service로, 이 CDC 기능을 쉽게 Wrapping해놔서, Web UI상에서 복제할 MS SQL Instance를 선택하고, 테이블을 선택하면 자동으로 복제가 진행된다. 아무래도 센터간 복제이기 때문에 실시간 복제는 불가능하리라 생각하고, 아래 동영상을 보니 스케쥴 기반으로 복제를 진행한다.

아래 동영상의 시연을 보면 약 1132건의 트렌젝션 (테이블 생성에서부터, 복제등을 포함해서) 미국에서 유럽 센터간 동기화를 수행하는데 11.4초 정도가 소요된다.

기업 내부에서 CDC를 통해서 데이터 베이스를 동기화 하는 경우는 근 실시간으로 이루어 지는데, Azure Data Sync Service를 통한 지역간 복제는 아무래도 복제 아키텍쳐를 스케쥴 기반으로 설계해야 한다.

 

오늘 MS 개발자 행사인 RemixK에 다녀왔습니다.
10년 이상 자바개발자 행사만 다닌 저한테는 다소 낮선 자리였습니다.

오늘 컨퍼런스 내용중에 흥미로웠던것중에 하나가 WinMobile7이었습니다.
년말에나 나올 '내일폰'이긴 합니다만.
Feature들이 흥미로워서 이야기 해봅니다.

크게 개발환경이 SilverLight와 XNA로 나뉘어 지는데, 일반적인 애플리케이션 개발은 SilverLight기반으로 하게 되어 있습니다. 그런데 개발툴이 일반 개발자 개발툴이라기 보다는 동영상 저작도구 같은 느낌이더군요. 아이폰의 Object C 개발환경, 이클립스 기반의 안드로이드 개발환경을 맛본 저로써는 다소 신선했습니다. 저작도구 답게 UI프로그래밍이나 이펙트가 매우매우 쉽습니다.
아마 아이디어만 있다면 웹디자이너라도 쉽게 기본적인 어플은 만들 수 있겠더군요.

그리고 다음이 XNA인데, 게임 개발 플랫폼입니다. 상당히 흥미로운 점은 XNA로 개발된 윈모7게임은 XBOX와, WIN7에서도 똑같이 동작합니다. 물론 화면 사이즈에 맞춰서 다시 렌더링 되서 말이지요. 이게 소위 MS에서 이야기하는 3Screen입니다. 한번 개발해서 모바일,데스크탑,TV에서까지 모두 사용할 수 있다는 겁니다.
게임 개발 프레임웍도 상당히 쉽습니다. 10년전(?)에 Direct X로 게임 개발을 하고 OPEN GL로 3D 프로그래밍 경험을 했을때 이것저것 만드느냐고 상당히 시간이 오래걸렸는데, 허허~~ 오늘 보니 이건 거의 거져 만들더군요. 충돌 로직이나 조이스틱,화면 IO,애니메이션 처리.. 한마디로 거져라고 말할 수 밖에 없을만큼 쉬워졌습니다.

그럼 이런것들이 무엇을 뜻 하느냐?

1. 개발자들의 진입이 쉬워집니다.
누구나 아이디어만 있다면 기술의 장벽을 넘어서 컨텐츠를 제공할 수 있다는 겁니다.
2. 시장이 넓다.
XNA기반의 게임 컨텐츠는 한번 개발하면 PC,X-BOX,모바일 환경에 모두 판매가 가능합니다. 한마디로 개발자의 투자 대비 수익이 늘어나는 거지요..

이 두가지 특징만 해도 모바일 플랫폼으로 무시 못할듯 싶습니다.
여기에 더불어서, 윈모7 탑재 디바이스들은 철저하게 스펙 규약이 있기 때문에 (화면 사이즈, CPU 제약,메모리 제약). 안드로이드가 겪고 있는 여러 스펙의 디바이스로 부터 오는 문제를 피해갈 수 있습니다.

또한 MS의 Azure 클라우드는 모바일 서비스에 새로운 가능을 제시해줍니다. 3G망 기반의 모바일 애플리케이션들은 인터넷을 통해서 통신을 하거나 OPEN API들을 호출합니다. 애플이나 안드로이드에서 작동하는 앱들은 대부분 공개된 오픈 API를 사용합니다.
그렇다면 특화된 서비스를 개발하고 싶다면? 서버 사이드를 구축해야할 필요가 있다면?
사야져... 서버도 사고.. 세팅과 운영도 하고... 개인이 하기는 비용이 만만하지 않습니다. 그래서 일부 전문 업체만 서버를 두고 OPEN API를 통해서 자사의 앱과 통합하는 형태를 가집니다.
그런데....
MS는 Azure를 들고 나왔습니다. 클라우드 플랫폼이져.. 개발이 다른 클라우드 플랫폼에 비해서 매우 쉬운 (비주얼 스튜디오에 개발환경이 통합되어 있어서, 기존 웹 개발 환경만 이해한다면 별도의 Learning Curve가 필요없습니다. ) 장점을 가지고 있고, 사용량에 대해서 과금을 하기 때문에, 손쉽게 서버를 갖출 수 있습니ㅏㄷ.

XNA지원,3Screen,모바일용 클라우드 보유

이 3가지 장점만 해도 모바일 2라운드를 한번 해볼만 하지 않을까 싶네요.
애플이 4세대 아이폰을 내고, 안드로이드 2.2가 경이로운 성능을 보여주기는 하지만 근본적으로 접근 방법이 틀리다는데에서 기대를 걸어봅니다.
올해 초 부터 클라우드 컴퓨팅에 대한 말들이 많다. 차세대 성장 동력이 어쩌고 이야기는 많지만 사실 실체는 거의 없다. 유일하게, Google,Amazon,MS만이 Public 클라우드 플랫폼을 서비스하고 있다. 그나마 Google이나 MS는 잘 만들어진 웹호스팅 시스템과 같은 느낌이다. 진정한 클라우드는 Amazon 정도라고나 할까? (사견입니다.)


아마존 클라우드는 Virtual Image를 로드해서 기동할 수 가 있다. 그래서 어느 미들웨어나 DBMS를 사용할 수 도 있고 Language의 제약도 받지 않는다.Prebuilt Image들의 경우 상용인 오라클이나 웹로직까지 이미 들어있어서 쉽게 시스템을 구축할 수 있다. 기본적으로 아마존 클라우드는 하드웨어 인프라를 제공할 수 있는 Iaas (Infrastructure as a service)의 개념을 가지고 있다. 거기에 더해서 인터넷 상에서 사용할 수 있는 Message Queue (SQS)나 Storage (S3) 서비스들도 제공한다 
 재미있는 개념은 Instance on demand라는 개념을 제공하는데, Instance가 계속 떠 있는 것이 아니라 request가 있을때 동적으로 구동되며 request양에 따라서 Instance 수를 가변적으로 조정할 수 있다.

그에 비해 구글은 Iaas보다는 Paas(Platform as a service)에 가깝다. 정해진 Google Application Engine 만 사용해야 하며, Python과 Django라는 언어만 지원한다.거기에 여러 Backend service와 UI용 Front end 서비스를 제공한다. 리소스를 분산해서 돈을 주고 사용한다는 순수한 클라우드 개념에는 아마존 보다는 떨어진듯.

MS Azure도 이제 나왔는데, .NET 뿐만 아니라, Ruby on rails와 같은 다른언어도 지원한다. 아직 사실 동영상밖에 보지 못해서 실체는 잘 모르겠지만 아직까지 과금 시스템은 없어보인다.거기에 MS의 CRM도 지원하던데 ASP서비스 처럼, 이 형태는 오라클 CRM on Demand와 비슷한 Saas(Software as a service)의 형태와 유사해 보인다.

사실 Public Cloud에서 가장 중요한것은 과금이다. Network traffic단위의 과금의 경우 이미 기존 Telco 시스템에 많았지만 CPU 사용량등의 과금은 시스템의 개발뿐 아니라 과금 모델 자체를 개발하는 것이 매우 어려운 일인데.. 그에 비해 아마존은 꽤나 성공을 거두고 있지 않나 싶다. (구글의 세계 정복을 방해하는 세력중의 하나이지 않을까?)

국내에도 SKT가 클라우드를 오픈했다고 하는데, 사실 실체가 궁금하다 진정한 클라우드 형태일지, 아니면 클라우드의 탈을 쓴 웹호스팅일지... 오픈된 기사를 하나 보면 "원문:http://www.bloter.net/archives/18586"

SK텔레콤은 현재 시험 운용중인 30여대의 인큐베이션 시스템을 추가 증설함으로써 80여대의 물리적인 서버를 투입했다. 가상화 솔루션으로는 시트릭스의 젠서버를 사용했고 일부 레드햇의 제품도 사용됐다. VM웨어의 가상화 솔루션을 도입할 경우 하드웨어 인프라 투자비용보다 더 비싸 오픈소스 가상화 제품을 도입해 비용을 줄인 것. SK텔레콤이 마련한 물리적인 x86 서버는 80대지만 가상화할 경우 600여 대의 서버 구성이 가능한 것으로 알려졌다.
가상화 솔루션을 쓴것을 봐서는 아마존 클라우드에 비슷한것 같은데

클라우드가 워낙 중요한 키워드가 되다보니 여기저기 만들어만 놓고 클라우드라는 태그만 붙이는 것 같은데 마케팅 메시지에 휘말리지 말아야 하지 않을까?