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


Archive»


 
 

쿠버네티스 #4

아키텍쳐


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


쿠버네티스에 대한 개념 이해가 끝났으면, 이제 쿠버네티스가 실제로 어떤 구조로 구현이 되어 있는지 아키텍쳐를 살펴보도록 하자. 아키텍쳐를 이용하면 동작 원리를 이해할 수 있기 때문에, 쿠버네티스의 사용법을 이해하는데 도움이 된다.




<그림. 쿠버네티스 아키텍쳐>

출처 https://kubernetes.io/docs/concepts/architecture/

마스터와 노드

쿠버네티스는 크게 마스터(Master)와 노드(Node) 두 개의 컴포넌트로 분리된다.

마스터는 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할을 맏고있고, 노드는 파드나 컨테이너 처럼 쿠버네티스 위에서 동작하는 워크로드를 호스팅하는 역할을 한다.

마스터

쿠버네티스 클러스터 전체를 컨트럴 하는 시스템으로, 크게 다음과 API 서버, 스케쥴러, 컨트롤러 매니져, etcd 로 구성되어 있다.


API 서버

쿠버네티스는 모든 명령과 통신을 API를 통해서 하는데, 그 중심이 되는 서버가 API서버이다.

쿠버네티스의 모든 기능들을 REST API로 제공하고 그에 대한 명령을 처리한다.

Etcd

API 서버가 명령을 주고 받는 서버라면, 쿠버네티스 클러스터의 데이타 베이스 역할이 되는 서버로 설정값이나 클러스터의 상태를 저장하는 서버이다.  etcd라는 분산형 키/밸류 스토어 오픈소스 ()https://github.com/coreos/etcd) 로 쿠버네티스 클러스터의 상태나 설정 정보를 저장한다.

스케쥴러

스케쥴러는 Pod,서비스등 각 리소스들을 적절한 노드에 할당하는 역할을 한다.

컨트롤러 매니져

컨트롤러 매니저는 컨트롤러(Replica controller, Service controller, Volume Controller, Node controller 등)를 생성하고 이를 각 노드에 배포하며 이를 관리하는 역할을 한다.


DNS

그림에는 빠져있는데, 쿠버네티스는 리소스의 엔드포인트(Endpoint)를 DNS로 맵핑하고 관리한다. Pod나 서비스등은 IP를 배정받는데, 동적으로 생성되는 리소스이기 때문에 그 IP 주소가 그때마다 변경이 되기 때문에, 그 리소스에 대한 위치 정보가 필요한데, 이러한 패턴을 Service discovery 패턴이라고 하는데, 쿠버네티스에서는 이를 내부 DNS서버를 두는 방식으로 해결하였다.

새로운 리소스가 생기면, 그 리소스에 대한 IP와 DNS 이름을 등록하여, DNS 이름을 기반으로 리소스에 접근할 수 있도록 한다.

노드

노드는 마스터에 의해 명령을 받고 실제 워크로드를 생성하여 서비스 하는 컴포넌트이다.

노드에는 Kubelet, Kube-proxy,cAdvisor 그리고 컨테이너 런타임이 배포된다.

Kubelet

노드에 배포되는 에이전트로, 마스터의 API서버와 통신을 하면서, 노드가 수행해야 할 명령을 받아서 수행하고, 반대로 노드의 상태등을 마스터로 전달하는 역할을 한다.

Kube-proxy

노드로 들어오거는 네트워크 트래픽을 적절한 컨테이너로 라우팅하고, 로드밸런싱등 노드로 들어오고 나가는 네트워크 트래픽을 프록시하고, 노드와 마스터간의 네트워크 통신을 관리한다.

Container runtime (컨테이너 런타임)

Pod를 통해서 배포된 컨테이너를 실행하는 컨테이너 런타임이다. 컨테이너 런타임은 보통 도커 컨테이너를 생각하기 쉬운데, 도커 이외에도 rkt (보안이 강화된 컨테이너), Hyper container 등 다양한 런타임이 있다.

cAdvisor

cAdvisor는 각 노드에서 기동되는 모니터링 에이전트로, 노드내에서 가동되는 컨테이너들의 상태와 성능등의 정보를 수집하여, 마스터 서버의 API 서버로 전달한다.

이 데이타들은 주로 모니터링을 위해서 사용된다.


전체적인 구조 자체는 복잡하지 않다. 모듈화가 되어 있고, 기능 확장을 위해서 플러그인을 설치할 수 있는 구조로 되어 있다. 예를 들어 나중에 설명하겠지만 모니터링 정보를 저장하는 데이타베이스로는 많이 사용되는 Influx 데이타 베이스 또는 Prometheus 와 같은 데이타 베이스를 선택해서 설치할 수 있고 또는 커스텀 인터페이스 개발을 통해서, 알맞은 저장소를 개발하여 연결이 가능하다.






Circuit breaker 패턴을 이용한 장애에 강한 MSA 서비스 구현하기 #1

Circuit breaker와 넷플릭스 Hystrix

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

MSA에서 서비스간 장애 전파

마이크로 서비스 아키텍쳐 패턴은 시스템을 여러개의 서비스 컴포넌트로 나눠서 서비스 컴포넌트간에 호출하는 개념을 가지고 있다. 이 아키텍쳐는 장점도 많지만 반대로 몇가지 단점을 가지고 있는데 그중에 하나는 하나의 컴포넌트가 느려지거나 장애가 나면 그 장애가난 컴포넌트를 호출하는 종속된 컴포넌트까지 장애가 전파되는 특성을 가지고 있다.


이해를 돕기 위해서 아래 그림을 보자


Service A가 Service B를 호출하는 상황에서 어떤 문제로 인하여 Service B가 응답을 못하거나 또는 응답 속도가 매우 느려진 상황이라고 가정하자. Service A가 Service B에 대한 호출 시도를 하면, Service A에서 Service B를 호출한 쓰레드는 응답을 받지 못하기 때문에, 계속 응답을 기다리는 상태로 잡혀있게 된다. 지속해서 Service A가 Service B를 호출을 하게 되면 앞과 같은 원리로 각 쓰레드들이 응답을 기다리는 상태로 변하게 되고 결과적으로는 남은 쓰레드가 없어서 다른 요청을 처리할 수 없는 상태가 된다.

이렇게 Service B의 장애가 Service A에 영향을 주는 경우를 장애가 전파 되었다고 한다. 이 상황에서 Service A를 호출하는 서비스가 또 있다면, 같은 원리로 인하여 그 서비스까지 장애가 전파되서 전체 시스템이 장애 상태로 빠질 수 있다.

Circuit breaker 패턴

이런 문제를 해결하는 디자인 패턴이 Circuit breaker 라는 패턴이 있다.

기본적인 원리는 다음과 같다. 서비스 호출 중간 즉 위의 예제에서는 Service A와 Service B에 Circuit Breaker를 설치한다. Service B로의 모든 호출은 이 Circuit Breaker를 통하게 되고 Service B가 정상적인 상황에서는 트래픽을 문제 없이 bypass 한다.

.


만약에 Service B가 문제가 생겼음을 Circuit breaker가 감지한 경우에는 Service B로의 호출을 강제적으로 끊어서 Service A에서 쓰레드들이 더 이상 요청을 기다리지 않도록 해서 장애가 전파하는 것을 방지 한다. 강제적으로 호출을 끊으면 에러 메세지가 Service A에서 발생하기 때문에 장애 전파는 막을 수 있지만, Service A에서 이에 대한 장애 처리 로직이 별도로 필요하다.

이를 조금 더 발전 시킨것이 Fall-back 메시징인데, Circuit breaker에서 Service B가 정상적인 응답을 할 수 없을 때, Circuit breaker가 룰에 따라서 다른 메세지를 리턴하게 하는 방법이다.



예를 들어 Service A가 상품 목록을 화면에 뿌려주는 서비스이고, Service B가 사용자에 대해서 머신러닝을 이용하여 상품을 추천해주는 서비스라고 했을때, Service B가 장애가 나면 상품 추천을 해줄 수 없다.

이때 상품 진열자 (MD)등이 미리 추천 상품 목록을 설정해놓고, Service B가 장애가 난 경우 Circuit breaker에서 이 목록을 리턴해주게 하면 머신러닝 알고리즘 기반의 상품 추천보다는 정확도는 낮아지지만 최소한 시스템이 장애가 나는 것을 방지 할 수 있고 다소 낮은 확률로라도 상품을 추천하여 꾸준하게 구매를 유도할 수 있다.


이 패턴은 넷플릭스에서 자바 라이브러리인 Hystrix로 구현이 되었으며, Spring 프레임웍을 통해서도 손쉽게 적용할 수 있다.

이렇게 소프트웨어 프레임웍 차원에서 적용할 수 있는 방법도 있지만 인프라 차원에서 Circuit breaker를 적용하는 방법도 있는데, envoy.io 라는 프록시 서버를 이용하면 된다.

소프트웨어를 사용하는 경우 관리 포인트가 줄어드는 장점은 있지만, 코드를 수정해야 하는 단점이 있고, 프로그래밍 언어에 따른 종속성이 있다.

반대로 인프라적인 접근의 경우에는 코드 변경은 필요 없으나, Circuit breaker용 프록시를 관리해야하는 추가적인 운영 부담이 늘어나게 된다.


이 글에서는 넷플릭스의 Hystrix, Spring circuit breaker를 이용한 소프트웨어적인 접근 방법과 envoy.io를 이용한 인프라적인 접근 방법 양쪽을 모두 살펴보기로 한다.


넷플릭스 Hystrix

넷플릭스는 MSA를 잘 적용하고 있는 기업이기도 하지만, 적용되어 있는 MSA 디자인 패턴 기술들을 오픈소스화하여 공유하는 것으로도 유명하다. Hystrix는 그중에서 Circuit breaker 패턴을 자바 기반으로 오픈소스화한 라이브러리이다.  


Circuit breaker 자체를 구현한것 뿐만 아니라, 각 서비스의 상태를 한눈에 알아볼 수 있도록 대쉬보드를 같이 제공한다.


Hystrix 라이브러리 사용방법

Hystrix를 사용하기 위해서는 pom.xml에 다음과 같이 라이브러리 의존성을 추가해야 한다.

<dependency>

<groupId>com.netflix.hystrix</groupId>

<artifactId>hystrix-core</artifactId>

<version>1.5.4</version>

</dependency>

<dependency>

<groupId>com.netflix.rxjava</groupId>

<artifactId>rxjava-core</artifactId>

<version>0.20.7</version>

</dependency>


Circuit breaker는 Hystrix 내에서 Command 디자인 패턴으로 구현된다. 먼저 아래 그림과 같이 HystrixCommand 클래스를 상속받은 Command 클래스를 정의한 후에, run() 메서드를 오버라이드하여, run 안에 실제 명령어를 넣으면 된다. HystrixCommand 클래스를 상속받을때 runI()메서드에서 리턴값으로 사용할 데이타 타입을 <>에 정의한다.


public class CommandHelloWorld extends HystrixCommand<String>{

private String name;

CommandHelloWorld(String name){

super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));

this.name = name;

}

@Override

protected String run() {

return "Hello" + name +"!";

}


이렇게 Command가 정의되었으면 호출 방법은 아래와 같다.


CommandHelloWorld helloWorldCommand = new CommandHelloWorld("World");

assertEquals("Hello World", helloWorldCommand.execute());


먼저 Command 클래스의 객체를 생성한 다음에, 객체.execute()를 이용해서 해당 command 를 실행하면 된다. 이렇게 하면, Command 클래스가 응답을 제대로 받지 못할때는 Circuit Breaker를 이용하여 연결을 강제적으로 끊고 에러 메세지등을 리턴하도록 된다.


전체 코드 샘플은 https://github.com/bwcho75/msa_pattern_sample/tree/master/hystrix 를 참고하기 바란다.

웹서비스에 적용하는 방법

대략적인 개념을 이해하였으면 실제로 이 패턴을 REST API로 구성된 MSA 기반의 서비스에 적용해보자.

두 개의 서비스 User와 Item이 있다고 가정하자 User 서비스가 REST API 호출을 이용하여 Item 서비스를 호출하는 구조라고 할때 이 User → Item 서비스로의 호출을 HystrixCommand를 이용하여 Circuit breaker로 구현해보도록 하자.


User 서비스의 전체 코드는 https://github.com/bwcho75/msa_pattern_sample/tree/master/UserService , Item 서비스의 전체코드는 https://github.com/bwcho75/msa_pattern_sample/tree/master/ItemService 에 있다.

각 코드는 Spring Web을 이용하여 구현되었으며 User → Item으로의 호출을 resttemplate을 이용하였다.


User → Item 서비스를 호출하여 해당 사용자에 속한 Item 목록을 읽어오는 Command를 GetCommand라고 하자, 코드는 대략 아래와 같다.


public class GetItemCommand extends HystrixCommand<List<User>>{

String name;

public GetItemCommand(String name) {

super(HystrixCommandGroupKey.Factory.asKey("ItemServiceGroup"));

this.name = name;

}


@Override

protected List<User> run() throws Exception {

List<User> usersList = new ArrayList<User>();

// call REST API

                                                (생략)

return usersList;

}

@Override

protected List<User> getFallback(){

List<User> usersList = new ArrayList<User>();

usersList.add(new User(name,"myemail@mygoogle.com"));

return usersList;

}

}


리턴 값이 List<User>이기 때문에, HystrixCommand <List<User>>를 상속하여 구현하였고, Item 서비스를 호출하는 부분은 run() 메서드에 구현한다. (restTemplate을 이용하여 호출하는 내용은 생략하였다.)


여기서 주목해야할 부분은 getFallBack() 함수인데, 호출되는 서비스 Item이 장애 일때는 이를 인지하고 getFallBack의 리턴값을 fallback 메세지로 호출한다.


Item과 User 서비스를 각각 실행한다.

%java -jar ./target/User-0.0.1-SNAPSHOT.jar

%java -jar ./target/Item-0.0.1-SNAPSHOT.jar


두 서비스를 실행 한후에 아래와 같이 User 서비스를 호출하면 다음과 같이 ItemList가 채워져서 정상적으로 리턴되는 것을 볼 수 있다.


terrycho-macbookpro:~ terrycho$ curl localhost:8081/users/terry

[{"name":"terry","email":"myemail@mygoogle.com","itemList":[{"name":"computer","qtetertertertertetttt


Item 서비스 서버를 인위적으로 죽인 상태에서 호출을 하면 다음과 같이 위에서 정의한 fall back 메세지와 같이 email이 “myemail@mygoogle.com”으로 호출되고 itemList는 비어 있는채로 리턴이 된다.


terrycho-macbookpro:~ terrycho$ curl localhost:8081/users/terry

[{"name":"terry","email":"myemail@mygoogle.com","itemList":[]}]


지금까지 간단하게나마 Circuit breaker 패턴과 넷플릭스의 Hystrix 오픈소스를 이용하여 Circuit breaker를 구현하는 방법에 대해서 알아보았다.

서비스 상태에 따라서 Circuit을 차단하는 방법등도 다양하고, Command 패턴을 처리하는 방법 (멀티 쓰레드, 세마포어 방식)등이 다양하기 때문에, 자세한 내부 동작 방법 및 구현 가이드는 https://github.com/Netflix/Hystrix/wiki/How-it-Works 를 참고하기 바란다.


Circuit breaker 패턴은 개인적인 생각에서는 MSA에서는 거의 필수적으로 적용해야 하는 패턴이라고 생각을 하지만 Hystrix를 이용하면 Command를 일일이 작성해야 하고, 이로 인해서 코드 복잡도가 올라갈 수 있다. 이를 간소화 하기 위해서 Spring 오픈소스에 이 Hystrix를 잘 추상화 해놓은 기능이 있는데, 그 부분 구현에 대해서는 다음글을 통해서 살펴보도록 한다.



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는 여러 클라우드 플랫폼에 명령을 내리기 위한 아답터 역할을 한다.



안드로이드 플랫폼 기본 아키텍쳐


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


안드로이드 플랫폼의 기반 아키텍쳐를 살펴보면 다음 그림과 같다.




리눅스 커널
일단 가장 아랫단에, Linux 커널 이 올라가 있다. 일반적인 Linux 커널과 크게 다르지는 않지만, 모바일 디바이스에 최적화된 전력 관리 기능이나 안드로이드에 최적화된 Binder IPC (프로세스간 커뮤니케이션) 부분등이 포함되어 있다.

시스템 라이브러리
리눅스 커널위에는 C로 구현된 몇가지 네이티브 라이이브러리들이 올라가 있다. 3차원 그래픽을 위한, OPEN GL, 로컬 데이타 베이스를 제공하는 SQLLite 데이타 베이스, 웹 브라우징을 위한 WebKit, 멀티미디어 재생을 위한 Media Framework들이 올라가 있다. 
이러한 시스템 라이브러리들은 내부적으로 JNI 인터페이스를 통해서 자바 코드로부터 호출되게 된다. 

안드로이드 런타임
이러한 시스템 라이브러리 위에, 안드로이드 런타임이 올라가 있는데, 안드로이드 런타임은 JVM (Java Virtual Machine)이다. 단, 모바일 애플리케이션을 위해서 최적화된 JVM으로 안드로이드는 달빅(Dalvik)이라는 이름의 VM이 올라간다. 이 달빅 JVM이 실제로 안드로이드 애플리케이션을 시작하게 되낟.   그리고, 그위에 코어 자바라이브러리들이 올라가게 된다. (java.*, javax.* ,org.* ...등)


애플리케이션 프레임웍
안드로이드 런타임 까지 기본 JVM과 자바 라이브러리가 올라갔다면 애플리케이션 개발 프레임웍은 라이브러리이다. 마치 서버 개발에서 자바 위에, JEE 나 스프링,Hibernate와 같은 프레임웍이 있는 것 같이 애플리케이션 개발용 프레임웍이 올라가 있다. 
  • Package manager : 어떤 애플리케이션들이 설치되어 있는지를 관리한다. 
  • Windows manager : 윈도우 화면을 관리 (윈도우란, 영역으로 맨 윗부분의 네비게이션바, 다이얼로그 형식으로 나오는 윈도우등등 모든 윈도우 시스템을 관리하는 부분이다.)
  • View manager : 기본적인 그래픽 컴포넌트를 관리 한다. 라디오 버튼이나, 탭, 버튼등. 
  • Resource manager  : 컴파일이 되지 않는 리소스를 관리한다. 예를 들어 폰 애플리케이션에 같이 패키징된 string, 이미지 파일등을 관리한다. (안드로이드 프로젝트상 main/res 내에 있는 것을 관리하는 듯)
  • Activity manager : 안드로이드의 액티버티를 관리한다. 이 액티버티는 안드로이드 애플리케이션내의 하나의 화면에 해당(?)하는 것으로, 이 액티버터의 생성 및 소멸까지의 라이프 싸이클을 관리한다.
  • Contents provider: 데이타 저장소에 대한 추상화된 계층으로, 이 Contents Provider 계층을 통하여, 데이타를 저장할 수 있고, 이 저장소를 다른 애플리케이션에게 공유하여 애플리케이션 간에 데이타를 공유할 수 도 있다.  
  • Location manager : 위치 관련 서비스 기능을 제공한다.  
  • Notification manager : notification bar에 중요한 이벤트를 보여주는 기능을 제공한다. (푸쉬 시스템도 여기서 관리 하나?)


기본 애플리케이션

그위에, 기본적으로 폰에 프리로드 되어 설치되는 애플리케이션들이 존재한다. 연락처, 메신져, 브라우져, 카메라등의 기본적인 애플리케이션 등이 이에 해당한다. 


아키텍쳐 문서화는 어떤 도구를 사용하는게 좋을까?

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


제 현재 본업은 아키텍트 입니다. 주로 시스템을 설계하는 역할을 하는데, 이 아키텍쳐 문서를 주로 PPT를 사용합니다. 문서는 워드로 만드는게 좋을 수 도 있고, EA나 StarUML등등 많은 툴이 있는데,  굳이 PPT를 사용하는 이유를 적어놓고자 합니다.

사실 예전에는 MS WORD로 설계문서를 만들었습니다. 만들어 놓으면 멋도 있고, 자세한 내용 표현이 가능해서 탐독하면서 이해하기도 좋습니다. 

그런데, 고객사의 요구 때문에, PPT로 바꾼후, 거의 습관처럼 PPT로 아키텍쳐 문서를 만들다 보니, 몇가지 장점이 있습니다.





1. PPT 는 표현에 제약이 없다.

아키텍쳐 디자인은 특성상 많은 다이어그램과 노트등을 달아야 하는데, WORD로 작성할 경우, 다른 툴에서 다이어그램을 그린 후 가져다 붙여야 합니다. 문서 만드는데 여간 노력이 많이 들어가고, 또한 UML 도구 같은 것을 사용하면 그 도구에서만 제공하는 다이어그래밍이 가능하지 다양하고 쉬운 다이어그래밍이 어렵습니다. 그냥 그리고 싶은 데로 표현하고 싶은데로 자유롭게 하면 되니 일단 문서 작성이 쉽습니다.


2. PPT는 발표용이지 문서용이 아니다

SI때나, 예전 전통적인 개발 방법론에서는 아키텍쳐 설계서 산출물이 나오면 이걸 받아서 개발자들이 잘 읽고 개발을 시작하는 프로세스였다면 근래의 개발 프로세스는 아키텍트가 설계를 하고,이 내용을 개발자들에게 설명을 합니다.

그냥 문서 하나 휙던지고 마는게 아니라는 겁니다. 예전 포스팅에서도 몇번 언급했지만, 문서화는 커뮤니케이션을 원할하게 하기 위한 하나의 도구이지, 산출물이 목적이 아닙니다.

그런점에서 PPT는 발표를 위한 도구인점에서 메리트가 많습니다. 보고용 자료가 아니라 발표/토론용 자료를 만드는 게 아키텍쳐 문서화의 목적이면 거기에 맞는 툴을 쓰는게 맞기 때문입니다.



람다 아키텍쳐의 소개와 해석

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


람다 아키텍쳐란

람다 아키텍쳐는 트위터에서 스트리밍 컴퓨팅에 있었던Nathan Marz에 의해서 소개된 아키텍쳐로, 실시간 분석을 지원하는 빅데이타 아키텍쳐이다.

아키텍쳐에 대한 자세한 내용은 http://lambda-architecture.net/ 에 소개되어 있다.


문제의 정의

아키텍쳐에 대한 이해를 돕기 위해서 예를 들어 설명해보자.

 페이스북과 SNS 애플리케이션 SNS가 있다고 가정하자. 이 애플리케이션은 모바일 애플리케이션이며, 글쓰기, 읽기, 댓글 달기, 스크롤 하기, 페이지 넘기기등 약 1000여개의 사용자 이벤트가 있다고 가정하자.

 사용자 수는 대략 1억명이며, 매일 이 각 사용자의 행동 패턴을 서버에 저장하여, 일별로, 사용자 이벤트의 개수를 통계로 추출한다고 하자.

클라이언트 디바이스로 부터 올라오는 데이타는 다음과 같다

  • 사용자 : 조대협

  • 날짜 : 2015년 1월 5일



<그림 1. 클라이언트에서 올라오는 데이타 포맷>

이런 환경에서, 기간별 특정 이벤트 추이, 가장 많이 활용되는 이벤트 TOP5 등의 통계 정보를 실시간으로 보고 싶다고 가정하자

가장 단순한 접근은 RDBMS에 저장하고 쿼리를 수행하는 방법이다.


<그림 2. 로그 데이타를 RDBMS에 저장한 포맷>

RDBM에 저장하고 SQL 쿼리문을 돌리면 되겠지만, 문제는 간단하지 않다. 1000개의 컬럼에, 1억명이 사용하는 시스템이다. 즉. 하루에 최대 1000개의 컬럼 짜리, 1억개의 레코드가 생성이 된다것이다.한달이면 30억개의 레코드이다.

이런 많은 데이타를 동적 SQL로 실행하였을때 그 수행시간이 많이 걸린다.


배치를 활용

그러면 이런 시간이 많이 걸리는 문제를 어떻게 해결하면 좋을까? 이를 위한 전통적인 접근 방식은 배치(BATCH)를 활용하는 것이다. 배치는, 어떤 특정 정해진 시간에, 계산을 미리 해놓는 것이다.

즉 데이타를 모아 놓았다가.밤마다.그날짜의 사용자들의 이벤트들의 합을 매일 계산해놓은 테이블을 만들어 놓으면 된다.



<그림 3. 일별 배치로 생성된 이벤트 데이타 테이블>

자아, 이렇게 배치로 테이블을 만들어 놓으면, 특정 기간에 각 이벤트별 통계를 내기가 쉬워 진다. 1년분의 데이타라하더라도 365 행 밖에 되지 않기 때문에, 속도 문제가 해결이 된다.

실시간 데이타의 반영

테이블 조인

이렇게 배치 테이블을 생성하면, 성능에 대한 문제는 해결이 되지만, 데이타가 배치 주기에 따라 최대 1일의 편차를 두게 된다. 즉 실시간 반영에 대한 문제가 발생한다.

그렇다면 어떻게 해결을 해야 할까? 해결은 배치 테이블과 그날의 데이타 테이블을 두개를 같이 사용하면 된다.

즉 어제까지의 데이타는 일별 배치로 생성된 테이블을 사용하고, 오늘 데이타 부분은 사용자별로 기록된 로그 테이블을 사용하여 두 테이블을 조인 하면, 오늘의 지금 순간의 통계값까지 볼 수 있다.

 


<그림 4. 테이블 조인을 이용한 실시간 데이타 통계 추출 >


실시간 집계 테이블의 활용

하루에 쌓이는 데이타량이 얼마 되지 않는다면 문제가 되지 않겠지만, 이 시나리오에서 하루에 쌓이는 데이타는 일 최대 1억건이 된다. 즉, 오늘 쌓이는 데이타 테이블을 조인 하면 1억개의 행에 대한 연산이 발생하여 적절한 성능을 기대하기 어렵다. 

그렇다면, 배치는 매일 돌리되, 오늘 데이타에 대한 통계 값을 실시간으로 업데이트 하는 방법을 생각해볼 수 있다. 

아래 그림과 같이 로그서버에서 클라이언트에서 받은 로그를 원본 데이타 테이블에 계속 저장을 하고, 오늘 통계에 대한 실시간 집계 테이블에, 글쓰기, 글 읽기 등 개별 이벤트의 값을 계산해서 더해 주면 된다.

 


<그림 5. 실시간 집계 테이블>

이렇게 하면, 실시간 집계 테이블과, 배치 테이블을 조인하여 빠르게 실시간 통계를 볼 수 있다.

즉 일별 실시간 통계는 다음 그림과 같이 당일전의 배치뷰와 당일의 실시간뷰를 합쳐서 통계를 낸 형태가 된다.

 


<그림 6. 실시간 통계를 뽑기 위한 테이블들의 관계>


람다 아키텍쳐를 활용

이 개념을 람다 아키텍쳐로 해석해보자. 데이타 흐름을 도식화 해보면 다음과 같다.

 


<그림 7. 람다 아키텍쳐의 개념>


먼저 배치 처리를 위해서, 로그 서버는 모든 로그 데이타를 저장소에 저장하고, 배치 처리 계층에서 일일 또는 일정한 시간을 주기로 배치 처리로 계산을 해서 배치 뷰(배치 테이블)을 만든다.

그리고 다른 흐름으로 실시간 처리쪽에 데이타를 전송해서 실시간 집계를 해서 실시간 집계 테이블을 만든다.

마지막으로, 이 두개의 뷰를 합쳐서 통계를 만든다.

배치뷰는 배치로 돌때만 쓰기가 가능하고 평상시에는 데이타를 읽기만 가능하게 한다. 이를 통해서 데이타가 변경되거나 오염(Corrupt)되는 것을 막을 수 있다.

실시간 뷰는 실시간으로 데이타를 쓰고, 읽을 수 있는 시스템을 사용한다.

위의 문제 정의 예제에서는 컬럼의 개수를 카운트 정도하는 간단한 예를 들었지만, 실제 빅데이타 분석에서는 단순 통계뿐 아니라 복잡한 수식이나 다단계를 거쳐야 하는 데이타 파일의 가공이 필요하기 때문에 복잡한 프로그래밍이 가능한 처리(배치/실시간)이 필요한데, 이 처리 계층에는 프로그램을 이용하려 알고리즘을 삽입할 수 있어야 한다.

이러한 특성에 맞춰서 각 데이타 처리 흐름에 솔루션을 맵핑 해보면 다음과 같다.



<그림 8. 람다 아키텍쳐에 대한 솔루션 맵핑> 


저장소는 대량의 데이타를 저비용으로, 안정성 있게 (유실이 없게) 저장할 수 있는 것이 필요하다. 그리고 이런 대량의 데이타를 배치로 처리할 때 되도록이면 빠른 시간내에 복잡한 알고리즘을 적용해서 계산할 수 있는 계층이 필요한데, 이러한 솔루션으로 제시되는 솔루션이 하둡의 HDFS(Hadoop File System)과 하둡의 MR (Map & Reduce)이다.

이렇게 계산된 배치 데이타를 저장할 장소가 필요한데, 하둡에서는 이런 데이타를 저장하고 고속으로 액세스할 수 있도록 HBase라는 NoSQL을 제공한다.

실시간 처리는 복잡한 알고지즘을 빠르게 데이타를 처리할 수 있는 솔루션이 필요한데, 대표적으로 Apache Storm등이 있으며, 빠른 읽기와 쓰기를 지원해야 하기 때문에, Redis와 같은 In-memory 기반의 NoSQL이 적절하게 추천되고 있다.

일반적으로 람다 아키텍쳐를 소개할때, 제안되는 솔루션의 형태이기는 하나, 람다 아키텍쳐는 특정 솔루션을 제안하는 아키텍쳐이기 보다는 데이타의 처리 기법을 소개하는 솔루션에 종속성이 없는 레퍼런스 아키텍쳐이다.

그래서 다른 솔루션 조합을 고려해볼 수 있는데, Dr.dobbs (http://www.drdobbs.com/database/applying-the-big-data-lambda-architectur/240162604)

에 소개된 솔루션 조합과 필자가 추천하는 조합을 추가해서 보면 다음과 같다.


<그림 9. 람다 아키텍쳐의 솔루션 조합>


여기서,필자가 Dr.Dobbs의 추천 솔루션 이외에, 배치 뷰와 실시간 뷰 쪽에, RDBMS를 추가하였는데, 배치뷰에 추가한 Amazon RedShift의 경우 아마존 클라우드 서비스에서 제공되는 Postgres 기반이 서비스로, 최대 16PB(페타바이트)까지의 용량을 지원한다. 이미 빅데이타라고 부를만큼의 충분한 데이타 사이즈를 지원할 뿐더라, RDBMS 기반의 SQL을 이용하여 유연한 데이타 조회가 가능하며, 리포트를 출력하기 위한 기존의 BI 툴과도 호환이 잘되서 많은 개발에 관련된 부분을 덜 수 있다. 실제로 통계 리포팅에서 가장 많은 시간이 소요되는 작업이, 비즈니스쪽 요구에 맞는 리포트를 만드는 작업이다.어떤 테이블과 그래프를 이용해서 데이터에 대한 의미를 보여줄 지는 단순한 리포팅 작업이라고 치부하기에는 매우 중요한 작업이며, 다양한 비즈니스 요건에 맞는 뷰를 보여 주기 위해서는 BI툴과의 연동은 많은 장점을 제공한다.

위에서 설명한 람다 아키텍쳐를 계층(Layer)로 나눠서 소개 하면 다음 그림과 같다.

실시간 데이터를 처리하는 부분을 스피드 레이어라고 부르며, 배치 처리는 배치 저장소와 배치 처리 부분을 배치 레이어라고 명명하고, 배치에 의해서 처리된 요약 데이터를 제공하는 부분을 서빙 레이어(Serving Layer)라고 한다.

 


<그림 10. 계층별로 추상화된 람다 아키텍쳐>

배치 레이어의 의미

배치 레이어의 저장소에는 가공전의 원본 데이터를 모두 저장한다. 데이터가 처리된 후에도 저장소에 데이터를 삭제 하지 않는다.

이렇게 원본 데이터를 저장함으로써, 배치 뷰의 데이터가 잘못 계산되었거나, 유실 되었을때, 복구가 가능하고, 현재 데이터 분석에서 없었던 새로운 뷰(통계)를 제공하고자 할 때 기존의 원본 데이터를 가지고 있음으로써, 기존 데이터에 대해서도 새로운 뷰의 통계 분석이 가능하다.


람다 아키텍쳐의 재구성

RDBMS를 활용한 유연성 증대 방안

이러한 람다 아키텍쳐는 대용량 데이터 처리와 실시간 정보 제공을 위한 장점을 가지고 있음에도 불구하고 대부분 하둡이나 NOSQL등의 솔루션을 조합해서 구현하는 경우가 대부분이기 때문에, 유연성 측면에서 문제점을 가지고 있다.

예를 들어 배치 뷰를 HBase를 사용하고, 실시간 뷰를 Redis를 사용할 경우, 상호 솔루션간 데이터 조인이 불가능할 뿐더러, 인덱스나 조인,그룹핑, 소팅 등이 어렵다. 이러한 기능이 필요하다면 각각 배치 처리와 실시간 처리 단계에 추가적으로 로직을 추가해서 새로운 뷰를 만들어야 한다.

쉽게 설명하면, 일반적인 NoSQL은 키-밸류 스토어의 개념을 가지고 있다.

그래서, 위의 그림3과 같은 테이블이 생성되었다 하더라도, 특정 컬럼 별로 데이터를 소팅해서 보여줄수 가 없다. 만약 소팅된 데이터를 표현하고자 한다면, 소팅이 된 테이블 뷰를 별도로 생성해야 한다.

참고 : NoSQL 데이터 모델링 패턴

http://bcho.tistory.com/665 , http://bcho.tistory.com/666

그래서 이런 문제점을 보강하기 위해서는 위에서도 잠깐 언급하였듯이 실시간 뷰와 배치 뷰 부분을 RDBMS를 사용하는 것을 고려해볼 수 있다. 쿼리에 특화된 OLAP 데이터 베이스를 활용하는 방법도 있고, 또는 HP Vertica 등을 활용할 수 있다. (HP Vertica는 SQL을 지원하지만, 전통적인RDBMS가 데이터를 행 단위로 처리하는데 반하여, Vertica는 데이터를 열 단위로 처리해서 통계나 쿼리에 성능이 매우 뛰어나다. 유료이지만 1테라까지는 무료로 사용할 수 있으니 뷰 테이블 용도 정도로 사용하는데는 크게 문제가 없다.)


데이터 분석 도구를 이용한 새로운 분석 모델 개발

분석 통계 데이터를 제공하다 보면, 저장소에 저장된 원본 데이터를 재 분석함으로써 추가적인 의미를 찾아낼 수 있는데, 이 영역은 데이터 과학자의 영역으로, 저장소에 있는 데이터를 통해서 새로운 데이터 모델을 추출해 내는 방식이다.

예를 들어, 글읽기 이벤트와 글쓰기 이벤트간의 상관 관계를 파악해내거나, 요일별 이벤트 변화량등을 분석해낼 수 있는데,

  1. 이 저장소에 R이나 MetLab과 같은 데이터 분석 도구를 이용하여, 샘플(표본) 데이터를 추출해서 데이터의 상관 관계를 파악해보고,

  2. 이러한 분석을 통해서 새로운 통계 모델을 설계하고 검증해볼 수 있다.

  3. 만약 이러한 모델이 적절하다면 알고리즘을 구현하고 이를 빅데이타 엔지니어에게 넘겨 준다.

  4. 빅데이타 엔지니어는 데이터 과학자에게서 받은 알고리즘을 람다 아키텍쳐의 각 레이어에 배치된 솔루션에 알맞은 형태로 구현한다.


 


<그림 11. 새로운 데이터 모델의 개발>

이러한 과정의 반복을 통해서, 분석 시스템은 지속적으로 발전되어가면서 데이터에 대한 더 많은 인사이트를 제공할 수 있게 된다.


결론

간단하게나마 람다 아키텍쳐에 대해서 알아보았다.

람다 아키텍쳐는 꼭 빅데이타에 적용하거나, 또는 하둡을 이용해야 하는 아키텍쳐가 아니다. RDBMS나 CSV 파일 등, 어떤 데이터 형태라도 기본은 배치를 이용한 집계 테이블과 실시간 뷰 테이블을 조인한다는 개념이기 때문에, 솔루션에 억메이지 말고, 적절한 시나리오를 찾아서 적용할 수 있도록 하면 좋겠다.


참고 : 

http://www.drdobbs.com/database/applying-the-big-data-lambda-architectur/240162604

http://www.infoq.com/articles/lambda-architecture-scalable-big-data-solutions



Microservice architecture note

아키텍쳐 /SOA | 2014.08.20 16:37 | Posted by 조대협

MSA (Microservice Architecture) 

자료 수집


참고 자료

Ebay 아키텍쳐 : http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Netflix 아키텍쳐 : http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

infoQ Microservice Architecture : http://www.infoq.com/articles/microservices-intro

MicroService 개념 http://microservices.io/patterns/microservices.html

Martin folwer : http://martinfowler.com/articles/microservices.html

Dzone microservice architecture : http://java.dzone.com/articles/microservice-architecture

Thought works의 PPT : http://www.infoq.com/presentations/Micro-Services

node.js로 apigateway 만들기 : 정리 잘되어 있음. http://plainoldobjects.com/presentations/nodejs-the-good-parts-a-skeptics-view/


Conway's 법칙에 연관됨

You build, You run - Devops, Amazon

De-Centralized governance - 기술 표준화 보다는 다양한 기술을 허가. Microserice들을 스크립트 언어로 빠르게 만들어 버림. 

Cross platform, Self organized team 모델 지향 - Align 되기전에 Self organized로 이동되면. 망함. 

운영이 HELL이다. 높은 운영 능력, 장애 처리, Devops 필요.



==> 공감 x 100배 (나만 겪는 문제가 아니구만..)

ESB (Enterprise Night Bus.. ) 


'아키텍쳐  > SOA' 카테고리의 다른 글

Microservice architecture note  (0) 2014.08.20
Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29

대용량 분산 시스템 아키텍쳐 디자인


대용량 분산 시스템에 대한 아키텍쳐 설계에 대한 내용을 공유합니다. 아직 많이 부족합니다. 많은 피드백 부탁드립니다.


1. 아키텍쳐 설계 프로세스


2. 대용량 분산 시스템 아키텍쳐


3. 대용량 분산 시스템 아키텍쳐 디자인 패턴


4. 레퍼런스 아키텍쳐 - SOA 


5. 레퍼런스 아키텍쳐 - REST


아키텍쳐 설계 프로세스

아키텍쳐 | 2012.09.04 17:55 | Posted by 조대협

아키텍쳐

아키텍쳐란 무엇일까? 소프트웨어 시스템에 대해서 이야기 하다보면, “아키텍쳐가 어떻다”. “최신 아키텍쳐를 적용했다.” 등 아키텍쳐에 대한 언급이 많다. 그렇다면, 소프트웨어 아키텍쳐에 대한 정의는 무엇일까?

http://www.sei.cmu.edu/architecture/start/glossary/community.cfm 를 보면, 수많은 아키텍쳐에 대한 정의가 있다. 지금부터 설명하고자 하는 아키텍쳐에 대한 정의는 다음과 같다.

아키텍쳐는 비지니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조를 정의한 문서로, 시스템을 구성하는 컴포넌트와, 그 컴포넌트간의 관계, 그리고, 컴포넌트가 다루는 정보(데이타)를 정의한다.”

또한 소프트웨어 아키텍쳐는 현재의 요구사항뿐 아니라 변화되는 비지니스 전략에 대응이 가능하도록 장기적인 로드맵을 수용하여 확장가능한 형태로 디자인 되어야 하며 가능하면, 구현 및 사용하고자 하는 조직의 기술 수준, 조직의 규모와 형태 그리고 비지니스의 형태에 맞춰서 설계 되어야 한다.

아키텍쳐 설계 프로세스



앞에서 아키텍쳐에 대한 정의는 끝냈다. 그렇다면 실제 아키텍쳐는 어떤 형태로 설계해야 할까?

비지니스 아키텍쳐 이해

아키텍쳐는 앞서 정의하였듯이, 비지니스를 성공적으로 이끌기 위해서, 만들어지는 시스템에 대한 설계다. 목적이 비지니스의 성공에 있기 때문에, 그 비지니스 자체가 어떤 목표,전략을 가지고 있는지를 이해해야, 목표에 부합하는 아키텍쳐를 설계할 수 있다.

아키텍쳐 설계 원칙 정의 (Architecture Principals)

비지니스 아키텍쳐가 정의되었으면, 시스템을 설계 하기 위한 테크니컬 아키텍쳐를 설계하기 위한 원칙을 정한다. 품질 속성이나, 기간, 조직 운용론, 기반 기술등 설계의 기본 사상이 되는 원칙을 정의한다.

시스템 아키텍쳐의 (System Architecture) 설계

설계 원칙이 정해졌으면, 비지니스의 요구 사항을 이 설계 원칙에 따라서 설계한다. 시스템 아키텍쳐는 크게 아래와 같이 3가지로 나뉘어 정의된다.

     애플리케이션 아키텍쳐 (Application Architecture) : 개발해야하는 애플리케이션 소프트웨어에 대한 아키텍쳐를 설계한다. 여기에는 컴포넌트의 정의, 컴포넌트 간의 관계, 특정 기능에 대한 컴포넌트간의 호출 흐름, 그리고 컴포넌트간의 통신을 위한 메세지에 대한 규격 정의를 포함한다.

     테크니컬 아키텍쳐 (Technical Architecture) : 애플리케이션의 배포 구조를 정의한다. 애플리케이션을 배포할 하드웨어의 구조와, 애플리케이션 개발에 사용하는 미들웨어 (DBMS, 웹서버등)등의 배포 구조를 함께 정의한다.

     데이타 아키텍쳐 (Data Architecture) : 마지막으로, 애플리케이션에서 다루는 정보(데이타)의 구조와 관계를 정의한다.

이 아키텍쳐의 설계는 기반 지식이 없는 상태에서는 설계가 어렵다. 물론 경험을 가지고 할 수 있겠지만, 참고할 수 있는 레퍼런스가 있다면 실수나 실패를 줄이고, 시간 또한 단축 시킬 수 있다. 참고자료는 CBD,SOA,EAI와 같은 일반적인 애플리케이션을 개발하기 위해서 패턴화된 아키텍쳐 스타일을 응용하거나, 유사한 도메인의 CASE STUDY (선행 사례) 기반의 아키텍쳐, 그리고 솔루션을 사용할 경우, 솔루션 제공사의 컨설팅 서비스를 이용하면, 매우 효율적으로 아키텍쳐 설계를 할 수 있다.


※ 많은 분들이 이 페이지를 방문하시고, 질문이 많으셔서, 상세한 아키텍쳐 설계 프로세스, 아키텍쳐의 정의, 아키텍트의 역할, 그리고, 대용량 시스템 아키텍쳐에 대한 글을 별도 문서로 정리하였습니다.   http://bcho.tistory.com/695


MongoDB Deployment 아키텍쳐를 간단하게 보면 다음과 같다.
mongos들을 앞단에 쭈욱 늘어놓고, 이는 라우터의 역할을 한다. mongos간의 load balancing은 앞단에 L4등의 로드 밸런서를 사용하고, Cache Hit율등을 높이기 위해서 L4는 Hash 방식등의 Sticky setting을 한다.
뒷단에 mongod를 배치하고, 최소한 3 copy replica 구조로 설정한다.



inter data center에 대한 replication을 설정하고, 이는 DR이나 Back up 용도로 사용한다
inter data center replication은 항상 여러가지 숙제를 주는데, 이 경우 backbone의 속도 차이로 인하여 data의 일관성이 깨질 수 있으니,
1. DR/Back up 용도로만 사용
2. data center간 초고속 백본만 설치
3. data center A에서는 read/write, B에서는 read만 (Query Off Loading 아키텍쳐) 수행하고, 이 경우에는 B 데이타 센터의 data 반영이 늦음을 예상해서 애플리케이션을 설계한다.

 
  • Scale out unit provisioning
    • Bare metal provisioning
  • Reporting
  • Life cycle management
  • Charge back model
  • IO Segregation
  • Self Service Portal
  • Multitenancy
  • Fabric Management
  • Live Migration
  • Automated Patch (Customer requirement is required. 보안 패치를 8시간 내에 모든 서버에 제공한다던지..)
  • Resource Pool Management
    • Asset (VLAN,IP,MAC,LUN) management
  • Scale out unit design

 
가상화만 고민하는데,
대충 이넘들은 고민해야 할듯..



아키텍쳐는 간단, 결국 Workflow 설계랑 PI를 어떻게 할것인가가.. 문제.
ITIL이랑 접속 시키는 것도 필요하고.~~

Cloud Architecture

클라우드 컴퓨팅 & NoSQL/IaaS 클라우드 | 2011.02.24 04:20 | Posted by 조대협


결국 이거지 머.. VM,Resource Pool, Fabric Management.

장애 대응 단계별 하드웨어 설계 방안

클라우드를 구축하는데 비용상의 문제점은 SAN을 구축하는데 소요되는 비용이다. SAN Controller Switch에 많은 비용이 소요되는데, 서버별 사용 시나리오별로 SAN 사용 여부를 판단함으로써 전체 하드웨어 구축 비용을 절약할 수 있다.


소프트웨어를 이용한 장애 대응

Tuxedo와 같은 TP Monitor Tomcat과 같은 Web Application Server 등은 소프트웨어 자체적으로 Cluster 구축을 통해서 Fail Over를 지원하거나 장애가 났을 때 일시적으로 Transaction이 중단되는 것을 허용하는 경우가 많다. 이런 경우에는 SAN을 구성하지 않고 Server에 직접 연결된 DAS를 이용해서 서비스를 제공한다.

권장 시나리오 : Application Server VM, Oracle RAC를 지원하는 DB 시나리오

Live Migration을 이용한 서버 장애 대응


하드웨어 장애가 났을 때에도 무 정지 상태로 Migration이 가능하다. VM 이미지를 저장하기 위해서 SAN이 필요하다. 이 경우에는 소프트웨어가 제공하는 Fail Over Mechanism을 사용하지 않는다. DISK에 대한 FailOver RAID 구성을 통해서 지원을 하지만, SAN Controller 장애시에는 전사 장애로 발전한다.

참고 : Linux VM의 경우 Hyper-V에서 Live Migration 지원이 불가능하다.

권장 시나리오 : MS SQL

SAN Cluster 구축을 통한 장애 대응


바로 위의 시나리오의 SAN Controller 장애에 대응하기 위한 아키텍쳐로 SAN Controller를 이중화 하고, 앞단에 SAN Switch를 넣어서 SAN Controller에 대해서 장애 대응을 한다. 모든 서버 하드웨어 장애 시나리오에 대해서 대응이 가능하다.

권장 시나리오 : 무정지 시스템, 무정지 MS SQL

IP TV 아키텍쳐의 이해

아키텍쳐 /모바일 | 2010.08.06 10:14 | Posted by 조대협

서비스 사업자의 IP TV 아키텍쳐 이해

아키텍쳐 모델

사용자 삽입 이미지

IP TV 아키텍쳐는 크게 서버와, 클라이언트 STB (Set Top Box)두 개로 이루어진다.

센터간 토폴로지 (중앙 방송 센터와 중계 센터)

서버 쪽은 중앙 방송 센터와 각 지역을 커버하기 위한 중계 센터(Sub Center)가 존재한다.
중앙 방송 센터는 전체 컨텐츠와 서비스 등을 통제하며, 중계 센터는 컨텐츠에 대한 중계를 주요 역할을 목적으로 하며, 중앙 방송 센터와 중계 센터 사이는 고속 Private 네트워크를 통해서 연결이 되어 있다. 중계 센터에서는 각 가정으로 Qos 망 또는 Private 망 기반의 IP망을 이용해서 서비스를 제공하며, VOD 서비스의 Latency를 낮추기 위해서 CDN 기반의 Storage 서비스 및 Streaming 서비스를 제공한다.

주요 서비스 컴포넌트

서비스 모델에 따라서는 VOD 서비스, 실시간 방송 서비스, 양방향 애플리케이션 및 공통 인프라 스트럭처로 나뉘어 지는데 각각의 구성 요소를 살펴보면 다음과 같다.

VOD 서비스 (Video on demand service)

·         Contents Acquisition

컨텐츠 제공자로부터 컨텐츠 (동영상) 그에 대한 메타 정보(타이틀, 시간, 배우 정보 ) 가지고 오는 역할을 수행한다. FTP 기타 파일 전송 프로토콜 등을 통해서 컨텐츠를 읽어오고 메타정보는 XML/HTTP 기반의 REST SOAP등을 통해서 읽어오는 구조를 취한다.  그러나 컨텐츠 확보에 있어서, 계약 등의 이슈가 있기 때문에 IP TV 서비스 제공자가 직접적으로 컨텐츠 확보를 하지 않고, 컨텐츠 Aggregator 통해서 컨텐츠를 확보하고, 컨텐츠 Aggregator각각 컨텐츠 제공자의 특성에 맞는 컨텐츠 획득 방안 (DVD 통한 획득, 실제 우편을 통한 획득 ) 따라서 컨텐츠를 모은 후에, IP TV 서비스 제공자에 맞는 형태 (MPEG2 ) 재가공하여 전달한다.

IP TV 서비스 제공자는 특정 포맷과 인터페이스 포맷을 제공함으로써 컨텐츠 획득에 들어가는 인터페이스 비용을 절약하고 기술적인 표준을 유지할 있다.

·         Encoding

확보된 VOD 컨텐츠는 서비스 형태에 맞는 파일 포맷으로 다시 인코딩이 된다.

다양한 디바이스 (모바일,HD TV,SD TV) 해상도에 맞춰서 인코딩이 수행되며, 인코딩 효율을 줄이기 위해서 하드웨어 인코더를 사용하기도 한다.

·         CA/DRM

인코딩 컨텐츠는 불법적인 복제를 막기 위해서 CA/DRM 처리를 한다. 이때 중요한 것은 컨텐츠 제공자 (월트디지니,픽사등) 따라서 특정 규격이상의 안정성(복제에 대한 대비) 요구로 하는 CA/DRM 요구한다.  그런 CA/DRM 통해서 VOD 배포하는 사업자에게만 컨텐츠를 판매하기 때문에, 계약하고자 하는 컨텐츠 제공자에 따라서 CA/DRM 솔루션을 구비하는 것이 필요하다.

·         Contents Storage

인코딩 되고 DRM 처리가 컨텐츠는 실제 서비스를 위해서 중앙 저장소 (Contents Storage) 저장된다.

·         Contents Provisioning

지역이 넓거나 가입자 수가 많은 경우에 지역  중계 센터를 설치 하는 경우가 있는데, 이런 경우, 저장된 컨텐츠는 지역 중계 센터로 배포 (Provisioning)된다.

지금까지 설명한 VOD 서비스의 시스템 프로세스를 정리해보면 다음과 같다.
컨텐츠 제공자(Program Provider)로부터 동영상과 메타 정보를 수집하여 전달 받고, 전달 받은 컨텐츠를 인코딩 DRM 거쳐서 중앙 저장소에 저장하여 서비스를 제공하고, 넓은 지역을 서비스 경우, 중계 센터로 VOD  컨텐츠를 배포 하여 지역 센터를 통해서 서비스를 제공한다.

VOD 서비스의 경우 실시간 성이 아니기 때문에, 미리 인코딩 컨텐츠를 제공하고, 또한 Buffering 가능하기 때문에 일반적인 인터넷 망을 통해서 서비스가 가능하다. 고화질의 컨텐츠를 제공하기 때문에, 일반 Public 망을 통해서 서비스 하는 경우 Buffering 시간이 길어져서 끊김현상등이 발생할 있고, Loading 시간이 많이 필요하기 때문에, 일반적으로 서비스 사업자의 경우 방송센터 또는 중계센터로부터 가정까지 폐쇄된 인터넷 (IP) 이용하여 서비스를 제공한다. (쉽게 말해서 Qos 보장되지 않지만, 빠른 속도의 초고속 인터넷을 사용한다.)

실시간 방송 서비스 (Live broad casting)

실시간 방송의 경우 공중파나 케이블 방송을 IP TV 다시 중계 해주는 서비스로, 실시간 방송은 TV 비즈니스에 있어서 빼놓을 없는 핵심 서비스이다. 실시간 방송의 경우 공중파나 케이블 방송의 컨텐츠를 실시간으로 인코딩 해서 BY PASS 해주는 방식으로, VOD와는 달리 컨텐츠를 저장하지 않기 때문에 아키텍쳐 적으로는 단순할 있으나, 버퍼링을 사용할 없고, 인코딩이 실시간으로 이루어져야 하기 때문에 컴포넌트의 성능적인 요구 사항이 VOD 서비스에 비해서 매우 높다.

·         Encoding

공중파나 케이블 방송으로부터 받은 실시간 컨텐츠를 인코딩 한다. 인코딩에 의해서 타임LACK 발생하면 안되기 때문에, 타임 LACK 최소화하기 위해서 고성능의 하드웨어 기반의 인코딩 장비를 사용한다.

·         Streaming

인코딩된 실시간 방송 Stream 가정까지 전송한다. 이때 VOD 차이점은 VOD 경우 순간 사용자가 보는 컨텐츠가 다르지만, 실시간 방송의 경우 같은 채널을 본다면 같은 사용자의 경우 같은 컨텐츠를 보기 때문에, IP Unicast 아니라 일반적으로 Multicast망을 사용한다.  이런 이유로 실시간 서비스를 제공 하기 위해서는 방송센터 à 가정까지 IP MultiCast 지원해야 한다.

·         EPG (Electronic Program Guide)

방송 프로그램 일정표이다. IP TV에서 실제 EPG 메뉴를 띄워주기도 하고,  EPG 메뉴에서 방송중인 프로그램을 선택해서 이동하거나 예약 시청, 녹화 예약 등을 한다. (녹화의 경우 현재 아키텍쳐 문서에서 배제하였다. 일반적으로 IP TV 서비스 사업자는 실시간 방송에 대한 녹화를 지원하지 않는다. 기술적 문제와 저작권 문제 )

EPG 실시간 방송사와 연계해서 IP TV 플랫폼에 읽어오게 되고, IP TV 플랫폼에서는 플랫폼 표준 규격으로 변경하여 STB 전송해서 EPG GUI 맞게 출력해준다.

·         Qos(Quality of Service) 네트워크

일반적으로 HDMI 화질의 5.1 CH 영상과 음성을 제공하기 위해서는 컨텐츠나 압축률에 따라 차이는 있지만 10~12Mbps 네트워크 대역폭이 안정적으로 필요하다.  이런 이유로, 방송센터 또는 중계 센터에서 가정까지의 Qos (Quality of Service : 12Mbps 대역폭을 항상 유지하는 인터넷 ) 필요하다.  국내 IP TV 사업자는 실시간 방송을 위한 회선의 Qos 보장하기 위해서 가정에 Home Network Gate Way 라는 것을 설치하여 일반 인터넷 망과 분리하여 QoS 보장하는 서비스를 제공한다.

향상된 실시간 방송 서비스

 

양방향 애플리케이션 (Interactive application)

양방향 애플리케이션은 IP TV에서 실행되는 게임이나 노래방 같은 간단한 애플리케이션에서부터 EPG Overlap 광고 (베너, 클릭 기반의 링크)등을 지원하는 애플리케이션을 정의한다.

좀더 나아가서 PIP (Picture in Picture) 같이 방송 중에 여러 화면을 동시에 보여주는 (예를 들어 골프 방송에서 여러 홀을 동시에 보여준다거나, 야구 방송에서 투수 쪽과 타자 화면을 동시에 보여주는 서비스) 인터페이스 역시 양방향 애플리케이션 인터페이스를 이용한다.

양방향 애플리케이션 인터페이스는 동영상 전송을 제외한 모든 IP TV 인터페이스를 포괄하는 기술적인 컴포넌트이다.

·         Application Storage

애플리케이션 컨텐츠 (게임,노래방 ) 애플리케이션 제공자가 업로드 해서 저장하는 공간이다. AppStore같이 개발자가 직접 애플리케이션을 업로드하는 개발 생태계를 가지고 있는 플랫폼의 경우 Application Storage 일종의 개발자 포탈과 같은 인터페이스를 가지면서 애플리케이션 업로드 판매에 대한 정산등까지고 포괄하여 지원한다.

·         Application Server

Application Server 실제 애플리케이션을 구동하거나 클라이언트에 다운로드되서 작동하는 애플리케이션에 대해서 OPEN API 제공하는 서비스를 한다.

Application Server 기능이 다양화 경우 플랫폼 형태로 구성되는 경우가 있는데, OPEN API 기능을 제공하는 여러 단위 컴포넌트와 컴포넌트를 플러그인 하는 통합형 버스(BUS) 통해 STB 서비스를 EXPOSE하는 기능으로 구성되며 이를 흔히SDP (Service Delivery Platform)이라고 이야기 한다.

·         STB VM

STB에는 다운로드 애플리케이션을 관리하고, 실행하는 VM(Virtual Machine:가상 머신) 존재한다. 모바일에서 이야기 하는 안드로이드나, 바다 플랫폼등이 이러한 VM 해당한다.

위에서 설명한 양방향 애플리케이션 실행 환경은 국내 IP TV 플랫폼에서 사용되는 클라이언트 지향형 아키텍쳐 이야기한다. 근래에 들어서 해외의 IP TV 플랫폼인MS MediaRoom이나 국을 TV 같은 경우에는 서버 지향형 아키텍쳐 사용하는데 차이점을 설명 하면 다음과 같다.

클라이언트 지향형 아키텍쳐 (Client Oriented Architecture)

아키텍쳐는 애플리케이션 수행 파일을 직접 STB 다운로드 받아서 VM위에서 구동하는 방식이다. 단말에서 직접 구동되기 때문에, 단말의 여러 기능을 이용할 있고, 중량의 애플리케이션 서비스 (다양한 형태의 서비스) 가능하다는 장점을 가지고 있다.

서버 지향형 아키텍쳐 (Server Oriented Architecture)

서버 지향형 아키텍쳐는 마치 WEB이나 모바일의 WAP처럼 애플리케이션은 실제 서버에 배포되고 TAG 기반의 프레젠테이션 계층(화면) 클라이언트로 전송되는 아키텍쳐 모델로, 애플리케이션의 비즈니스 로직이 서버에서 실행되기 때문에 사양 STB에서도 사용이 용이하다는 장점을 가지고 있으며, 애플리케이션의 변경과 배포가 매우 용이하다.

 MS 경우 PF(Presentation Framework)이라는 것을 사용해서 애니메이션 등을 포함한 다양한 태그 라이브러리를 통한 UI 제공하고, 프로그래밍 모델 역시 기존의 개발 방법과 유사하기 때문에 개발생산성과 개발자 확보가 쉬운 장점을 가지고 있으며, 애플리케이션의 업그레이드 등이 매우 용이하다.

얼마 TV  사업 진출을 선언한 구글의 경우에도 STB 다운로드 받는 형식이 아닌 HTML5 IP TV서비스에 적절한 표준을 추가 함으로써, 서버 지향형 아키텍쳐를 기반으로 IP TV 서비스 인프라를 제공하려는 움직임을 보이고 있다.

공통 서비스 (Common service)

공통 서비스 컴포넌트의 위의 모든 서비스를 제공하기 위해서 제공해야 하는 공통적인 기능들과 함께, 디바이스나 사용자관리와 같은 IP TV 서비스 플랫폼의 인프라를 제공하는 컴포넌트를 정의한다.

·         Billing/Charging

이벤트,패키지 상품과 같이 다양한 과금 정책에 따라서 컨텐츠의 가격을 매기는 것이 Charging,  실제 신용카드나 또는 요금 정산에 포함 시켜서 과금하는 Billing으로 구성된다.

·         Device Profile 관리

STB에 대한 이력과 사용자에 대한 정보를 관리한다. STB Firmware 버전, 다운로드 받은 소프트웨어 이력 등을 관리한다.

·         Device Management

Device에 대한 Firmware Upgrade등을 관리한다.

·         Authentication & Authorization

STB를 통해서 IP TV 서비스를 이용하고자 할 때, 인증 및 권한 관리를 담당한다.

 

IP TV에서의 킬러 컨텐츠

IP TV 비즈니스에 있어서 대부분의 수익은 VOD, 실시간 방송, 그리고 광고에서 창출된다.
광고 수익 기반으로 VOD를 무료로 배포하거나 고품질의 VOD를 유료로 서비스해서 수익을 창출하고, 실시간 방송의 경우 기존 공중파나 케이블을 대체하기 위해서 존재한다.

전통적인 IP TV 서비스 모델에 있어서의 문제점

국내 IP TV 비즈니스 모델에서의 주요 문제점을 살펴보면 다음과 같다.
실시간 방송의 경우 케이블 사업자의 실시간 재전송 비용에 대비해서 공중파 방송사들이 IP TV 사업자에게 상당히 큰 비용의 재전송비를 요구하기 때문에, 실시간 방송 쪽의 수익률이 좋지 않은 편이다.

또한 양방향 애플리케이션의 경우 국내의 IP TV 플랫폼이 대부분 Java 기반 또는 어도비의 플래시 형태를 사용하는데, Java 플랫폼 기반의 애플리케이션의 경우 STB에 탑재되는 JVM (Java Virtual Machine)의 표준이 잘못 구현된 경우가 많고 특성이 다양한 경우가 많아서 개발에 있어서 해당 플랫폼에 대한 경험이 많이 필요하고, 테스트에 많은 시간이 소요되기 때문에, 컨텐츠 제공자가 매우 적은 편이다.  또한 플래시 기반의 컨텐츠로 조금씩 이동 하고 있으나, 플래시 플랫폼의 한계로 인해서 아주 가벼운 형태의 애플리케이션 정도만 (간단한 게임) 서비스가 제공되고 있으며, 아직까지 애플리케이션 개발 생태계가 만들어지지 않은 상태이다.

이런 상황에서, 각 통신사들은 애플리케이션의 서버 플랫폼을 만들기 위해서 SDP (Service Delivery Platform)등을 구축하려고 노력하고 있으나, 애플리케이션 개발 생태계가 확립되지 않은 상태에서 효과를 내기 어렵고 더군다나 IP TV의 핵심 컨텐츠는 애플리케이션 보다는 효과적인 VOD 서비스 및 광고 수익 모델이기 때문에, 전략적이지 못한 투자가 이루어지고 있는 상황이다.

또한 독자적으로 IP TV 플랫폼을 가지기 위해서 STB 개발 비용 및 서버 플랫폼 개발 비용으로 막대한 비용을 투자하고 있으며, 서비스 품질의 경우 처음 개발하는 플랫폼이기 때문에 해외의 전문 IP TV 플랫폼 (Microsoft Mediaroom)등에 비해서 Quality가 떨어진다. 이상적인 방향은 서비스 사업자는 서비스 제공을 위해서 컨텐츠 등에 투자하고, 플랫폼은 선진 플랫폼을 들여와서 사업자의 특성에 맞게 Customization하여 플랫폼에 대한 투자 비용을 줄이는 방향이 바람직하다.

IIS의 Asynchronous 처리.

클라우드 컴퓨팅 & NoSQL/IIS | 2010.05.08 23:07 | Posted by 조대협
확인을 좀 해봐야알겠지 IIS의 Request 처리 메카니즘은 Java 기반의 WAS 보다 뛰어난것 같다.
일단 Asynchronous IO 처리라는 것이 되는데, 이는 WebLogic Server에서 최근에 추가된 Future Servlet과 유사한듯 하다.

보통 WAS는 Request를 받으면, 해당 Request를 처리하는 Thread가 Allocation이 되고, Response를 보낼때 까지 Thread를 잡고 있는데, DB나 외부 시스템을 호출하는 IO가 있을 경우 IO 처리 시간동안 Thread를 점유하는 비효율적인 메카니즘이 생겨나고, 이는 실제 처리할 수 있는 Request 수를 줄인다. 이를 보강하는 방법인 일단 Request를 받은 후에, 처리가 완료될때까지 Thread를 Release했다가, 처리가 끝나면 (DB IO등의) 다시 Thread가 Allocation되서 Response 처리를 하는 방법이다.

IIS에서는 Request가 오면 IIS Thread가 직접 이 요청을 받고 ASP.NET이 관리하는 Thread로 Request를 바로 넘긴다 (offload)그리고, IIS Thread는 바로 Release된다. ASP.NET이 관리하는 Thread가 요청 처리를 끝내면 Call back 메카니즘에 의해서, IIS Thread에 response를 보내는 Thread가 다시 재할당된다. 
이렇게 하면 ASP.NET쪽 AP Logic에 문제가 생겨도 IIS 가Thread 가 Stuck되는 일은 없을 것같고, 자원 처리 효율면에서도 상당히 뛰어나다.

제대로 이해했는지 모르겠는데, 예전에 적용된 아키텍쳐 치고는 상당히 앞서있는 듯..


시간 나면 디테일하게 다시한번 살펴봐야 쓰겄다.

참고 :

The ISAPI extension runs requests asynchronously. In this mode the ISAPI extension immediately returns on the calling worker process or IIS thread, but keeps the ECB for the current request alive. The ECB then includes a mechanism for letting ISAPI know when the request is complete (via ecb.ServerSupportFunction) which then releases the ECB. This asynchronous processing releases the ISAPI worker thread immediately, and offloads processing to a separate thread that is managed by ASP.NET.

ASP.NET receives this ecb reference and uses it internally to retrieve information about the current request such as server variables and POST data as well as returning output back to the server. The ecbstays alive until the request finishes or times out in IIS and ASP.NET continues to communicate with it until the request is done. Output is written into the ISAPI output stream (ecb.WriteClient()) and when the request is done, the ISAPI extension is notified of request completion to let it know that the ECB can be freed. This implementation is very efficient as the .NET classes essentially act as a fairly thin wrapper around the high performance, unmanaged ISAPI ECB.
.


'클라우드 컴퓨팅 & NoSQL > IIS' 카테고리의 다른 글

IIS의 새로운 동영상 Streaming 기술 Smooth Streaming  (2) 2010.06.09
IIS의 Asynchronous 처리.  (1) 2010.05.08
IIS Process 구조  (0) 2010.05.06

ALUI (WCI) Architecture

엔터프라이즈 솔루션/포탈 | 2009.08.25 23:17 | Posted by 조대협

From http://edocs.bea.com/alui/devdoc/docs60/Overview_of_the_Portal_Architecture/PlumtreeDevDoc_Overview_Intro.htm

Non Blocking Sync Call

엔터프라이즈 솔루션/BEA WebLogic | 2008.10.29 19:48 | Posted by 조대협
WebLogic에서 간만에 재미있는 기능을 찾아서 포스팅.
ESB나 EAI 제품과 같은 아키텍쳐에서 Sync Call의 구조를 보면 다음과 같다.
Request가 들어오면 특정 Thread가 그 request를 받아서 Backend의 Component에 보내고, 응답을 기다린다.
응답이 오면 Client에게 그 응답을 전달하는 구조이다.
그런데 이 경우 Client에서 요청을 받은 후 그 요청을 Component에 전달하고 나면 Component로 부터 응답이 오기까지는 Request Thread는 아무것도 하지 않고 단지 기다리기만 한다. 즉 하는 일없이 Thread만 점유하고 있는 것이다.
만약에 Component에서의 처리시간이 오래 걸리게 되면 Request Thread가 held 되는 시간이 늘어나게 되고 이런 요청이 많을 수록, 시스템 내의 Idle Thread는 기하급수적으로 줄어들게 되고, 이는 Thread 부족으로 인한 Slow down이나 hang현상을 유발하게 된다.

이를 해결하기 위한 아키텍쳐가 Non-blocking Sync Mode인데
개념은 다음과 같다. 
Client에서 요청이 들어오면 그 요청을 Request Thread가 처리하여 Backend의 Component로 전달을 하고 Request Thread는 Idle 상태로 전환된다.
그리고 나서 Component로 부터 응답이 들어오면 그 응답을 Idle Thread중에 한 Thread가 응답을 받아서 Client에게 전달을 한다. (Response Thread)
이런 구조에서는 Component로 일단 요청이 전달된후 Component에서 응답이 올때까지는 Thread가 release되어 있기 때문에 Working Thread의 수를 줄일 수 있다.
Server <--> Component 단을 Async/Callback처럼 구현해놓은것인데 EAI나 ESB와 같은 중계 시스템에서는 매우 유용한 아키텍쳐가 될거 같다.

이를 구현한 구현체가 WebLogic에 Future Response model for HTTP 라는 모델이다. (아래 참조)
이 모델은 Backend에서 수행 시간이 오래 걸릴 경우나 비지니스 로직이 JMS등을 이용하는 것과 같은 Async 구조에서는 매우 유용하지만 일반적인 WebApplication에서는 오히려 유용하지 않다. (하나의 Request를 수행하는데 Thread를 두개나 사용하게 되고 어짜피 Response를 만들기 위해서는 비지니스 로직을 처리해야할 쓰레드가 필요하기 때문에..)

이러한 구조는 ALSB 3.0 내부에서 사용하고 있다니 장애 예방이나, 리소스 효율 면에서 상당히 뛰어날듯하다.
간만에 재미있는 아키텍쳐를 봤더니.. 뿌듯하네..

==

A Future Response Model for HTTP Servlets

In general, WebLogic Server processes incoming HTTP requests and the response is returned immediately to the client. Such connections are handled synchronously by the same thread. However, some HTTP requests may require longer processing time. Database connection, for example, may create longer response times. Handling these requests synchronously causes the thread to be held, waiting until the request is processed and the response sent.

To avoid this hung-thread scenario, WebLogic Server provides two classes that handle HTTP requests asynchronously by de-coupling the response from the thread that handles the incoming request. The following sections describe these classes.

Abstract Asynchronous Servlet

The Abstract Asynchronous Servlet enables you to handle incoming requests and servlet responses with different threads. This class explicitly provides a better general framework for handling the response than the Future Response Servlet, including thread handling.

You implement the Abstract Asynchronous Servlet by extending theweblogic.servlet.http.AbstractAsyncServlet.java class. This class provides the following abstract methods that you must override in your extended class.

doRequest

This method processes the servlet request. The following code example demonstrates how to override this method.

Listing 9-3 Overriding doRequest in AbstractAsynchServlet.java
public boolean doRequest(RequestResponseKey rrk) 
      throws ServletException, IOException {
      HttpServletRequest req = rrk.getRequest();
      HttpServletResponse res = rrk.getResponse();

      if (req.getParameter("immediate") != null) {
            res.setContentType("text/html");
            PrintWriter out = res.getWriter();
            out.println("Hello World Immediately!");
            return false ;
      }
      else {
            TimerManagerFactory.getTimerManagerFactory()
            .getDefaultTimerManager().schedule
            (new TimerListener() {
                  public void timerExpired(Timer timer)
                        {try {
                              AbstractAsyncServlet.notify(rrk, null);
                        }
                        catch (Exception e) {
                              e.printStackTrace();
                        }
                  }
            }, 2000);
      return true;
      }
}

doResponse

This method processes the servlet response.

Note: The servlet instance that processed the doRequest() method used to handle the original incoming request method will not necessarily be the one to process the doResponse() method.

If an exception occurs during processing, the container returns an error to the client. The following code example demonstrates how to override this method.

Listing 9-4 Overriding doResponse() in AbstractAsyncServlet.java
public void doResponse (RequestResponseKey rrk, Object context)
   throws ServletException, IOException
      {
      HttpServletRequest req = rrk.getRequest();
      HttpServletResponse res = rrk.getResponse();

      res.setContentType("text/html");
      PrintWriter out = res.getWriter();
      out.println("Hello World!");
}

doTimeOut

This method sends a servlet response error when the notify() method is not called within the timeout period.

Note: The servlet instance that processed the doRequest() method used to handle the original incoming request method will not necessarily be the one to process the doTimeOut() method.
Listing 9-5 Overriding doTimeOut() in AbstractAsyncServlet.java
public void doTimeout (RequestResponseKey rrk)
      throws ServletException, IOException
{
      HttpServletRequest req = rrk.getRequest();
      HttpServletResponse res = rrk.getResponse();

      res.setContentType("text/html");
      PrintWriter out = res.getWriter();
      out.println("Timeout!");
}

Future Response Servlet

Although Oracle recommends using the Abstract Asynchronous Servlet, you can also use the Future Response Servlet to handle servlet responses with a different thread than the one that handles the incoming request. You enable this servlet by extending weblogic.servlet.FutureResponseServlet.java, which gives you full control over how the response is handled and allows more control over thread handling. However, using this class to avoid hung threads requires you to provide most of the code.

The exact implementation depends on your needs, but you must override the service() method of this class at a minimum. The following example shows how you can override the service method.

Listing 9-6 Overriding the service() method of FutureResponseServlet.java
  public void service(HttpServletRequest req, FutureServletResponse rsp)
throws IOException, ServletException {
if(req.getParameter("immediate") != null){
PrintWriter out = rsp.getWriter();
out.println("Immediate response!");
rsp.send();
} else {
Timer myTimer = new Timer();
MyTimerTask mt = new MyTimerTask(rsp, myTimer);
myTimer.schedule(mt, 100);
}
}

private static class MyTimerTask extends TimerTask{
private FutureServletResponse rsp;
Timer timer;
MyTimerTask(FutureServletResponse rsp, Timer timer){
this.rsp = rsp;
this.timer = timer;
}
public void run(){
try{
PrintWriter out = rsp.getWriter();
out.println("Delayed Response");
rsp.send();
timer.cancel();
}
catch(IOException e){
e.printStackTrace();
}
}
}