Cloud Computing - Day 02

안녕하십니까?

이번 시간에는 Single Tenant 와 Multi tenant , 그리고 Azure 의 아키텍처 구조에 대해서

살펴 보겠습니다.

 

가. Single Tenant 와 Multi tenant

 

Single Tenant 와 Multi tenant 는 클라우드 기반의 솔루션을 설계하는 데, 한번쯤 짚고 넘어가야

하는 부분입니다. 원래는 좀 더 뒤에 Role 에 대한 이야기가 나오고 나서 설명 드려야 하는

부분입니다만, 어떤 면에서는 Role 과는 별개로 이해를 하고 있는 쪽이 후에 Role 을 이용해서,

아키텍처를 설계할 때, 왜 이런 구조로 해야 하는 지를 쉽게 이해 할 수 있으리라 생각이 듭니다.

 

Single Tenant

-       단일 인스턴스로 단일 클라이언트에게 서비스가 가능한 방식

-       클라이언트 마다 서로 다른 인스턴스를 사용한다.

 

Multi tenant

-       단일 인스턴스로 다수의 클라이언트에게 서비스 가능한 방식

-       다수의 클라이언트가 하나의 인스턴스를 사용한다.

 

멀티테넌트가 지원이 된다면 하나의 인스턴스로 다수의 클라이언트에 대해 동일한 서비스가

가능해지는 장점이 있다. 이는 또한 자원 활용도의 극대화를 추구할 수 있다.

다만, 멀티 테넌트 아키텍처 구조에서는 상대적으로 싱글 테넌트 아키턱체 비해서

취약한 점이 존재한다

 

싱글 테넌트의 경우 단일 인스턴스가 장애가 발생하면 단일 클라이언트에게만 영향을 주지만,

멀티 테넌트 방식에서는 모든 클라이언트가 영향을 받는다. 그러나, 윈도우 애저에서는

애플리케이션과 동일한 복사본을 다수의 윈도우 애저 역할 인스턴스에 배포해 인스턴스

장애 리스크를 줄일 수 있다.

 

*. Single Tenant 와 Multi tenant

 

왼쪽 그림이 Multi instance & Single Tenant 방식입니다. Service Provider 을 Web Server 라

가정하고, Instance 들을 웹 사이트라 가정하면 이해하기가 쉽습니다. 웹 서버 1대에 3개의

웹 사이트가 있고, 웹 사이트 별로 고객들이 붙어 있습니다.

 

오른쪽 그림은 Single instance & Multitenant 방식입니다. 하나의 웹 서버에 하나의 웹 사이트가

있고, 3명의 클라이언트가 붙어 있습니다.

 

이와 같은 구조를 가지고 있을 때, 만약에 인스턴스 1개가 죽었다고 가정한다면, 왼쪽의 경우는

1명의 클라이언트만 떨어져 나갈 것입니다. 반면에 오른쪽은 모든 클라이언트가 떨어져나가

버립니다.

 

Azure 에서는 이와 같은 문제가 발생할 것을 대비하기 위해서 최소 2개의 Role 을 사용하는

것을 권장합니다. ( Role 에 다음에 자세히 설명을 드리겠습니다. )

 

*. Windows Azure 의 일반적인 아키텍처

 

위의 그림은 Windows Azure 의 일반적인 아키텍처 그림으로, 이와 같은 형식으로 지원이

가능하다는 것일 뿐이지, 이런 형태로 설계해야 한다는 것은 아닙니다.

 

구조를 살펴보면 앞 단에서는 개별 인스턴스가 클라이언트들과 연결되어 있고, 중간에

멀티터넌트 형식의 인스턴스가 있고, 뒷 단에는 개별 인스턴스가 존재합니다.

 

이와 같은 경우라고 하더라도, 중간 계층의 멀티터넌트의 인스턴스가 죽을 경우를 대비해서,

인스턴스를 이중화 하는 것을 권장하고 있습니다.

 

나. Windows Azure Architecture

 

그러면 Windows Azure 의 기본적인 아키텍처를 살펴보도록 하겠습니다.

첫 회에 말씀 드렸던 바와 같이 Azure 도 많은 변화가 있을 예정입니다.

하지만, 지금 설명 드리는 아키텍처는 기본적인 부분이기 때문에, 아마 큰 변화는 없으리라

생각이 듭니다.

 

 

일반적인 아키텍처 구조입니다. Enterprise 환경은 기존의 기업 환경입니다.

기업 내 user 들 혹은 인터넷 상의 user 들이 접근이 가능한 구조를 보이고 있으며,

Cloud 내의 Service Bus 를 통해서 Cloud 상의 Application 이 On-Premises 상의

Database 에 접근이 가능하다는 것을 보여주고 있습니다.

 

 

조금 더 펼쳐 놓고 보면, Azure 에는 Windows Azure , SQL Azure AppFabric 이 있습니다.

AppFabric 은 OS 의 커널이라고 생각하시면 무난합니다. AppFabric 이 수행하는 역할은

LoadBalancing , Instance 들의 생성 , 재 시작 등등… 여러 가지 역할을 수행합니다.

 

 

Windows Azure 내에서는 Compute 와 Storage 가 존재합니다. Compute 에는 Role 이

존재하는 데, 이 부분은 후에 좀 더 자세히 설명하겠습니다.

Storage 는 공용 저장소 정도라고 우선은 이해하고 넘어가겠습니다.

Azure 에는 디스크의 개념이 존재하지 않기 때문에, 저장해야 할 데이터는 모두 Storage 에

저장해야 합니다.

 

 

http / https 요청을 받으면 AppFabric 이 L/B 를 수행해 Web Role 들 중에서 하나의 instance

에 요청을 던지게 됩니다.

 

Role 에는 다음과 같은 Role 들이 존재합니다.

 

Web Role

-       IIS 7 이 설치된 웹 서버 VM 이라고 이해하시면 무난합니다.

-       실지로 웹 어플리케이션이 구동되는 Role 입니다.

Worker Role

-       Windows 2008 R2 서버라고 이해하시면 무난합니다.

-       윈도우 서비스 형태로 무한 반복하면서 수행되는 서비스 입니다.

VM Role

-       Web Role 이나 Worker Role 로 패키징 되기 어려운 이미지를 묶어서 사용하는

역할입니다.

-       현재는 베타 서비스입니다.

 

Storage 는 공용 저장소이며, 다음과 같은 것들이 존재합니다.

보다 자세한 내역은 후에 다시 언급하겠습니다.

 

Blob

-       바이너리 파일을 저장하는 저장소입니다.

-       컨테이너 (폴더라고 이해하시면 됩니다.) 단위로 권한 설정을 하여 관리가 가능합니다.

-       CDN ( Content Delivery Network ) 에서 사용됩니다.

Tables

-       No-SQL 저장소입니다.

-       흔히, MongoDB , 카산드라와 비슷한 개념입니다.

-       LINQ 가 가능합니다.

Queues

-       말 그대로 큐입니다.

-       Web Role 과 Worker Role 같이 Role 간의 통신에 주로 사용됩니다.

 

 

SQL Azure 는 SQL Server 와 유사합니다만, SQL Server 를 그대로 Cloud 에 올려놓은 구조가

아니기 때문에, 구조적인 차이점이 존재합니다.

이 부분도 개념 정도만 후에 설명하겠습니다. MSDN 발췌 자료로 엄청난 양이 있더군요…

 

 

기존 SQL Server 처럼 TDS 를 이용해서 접근한다는 것을 보여줍니다.

TDS ( Tabular data stream )

 

 

여러 데이터 베이스 사용에 대한 부분도 나타내고 있습니다.

여기서 주의할 점은 Cloud 환경하에서는 기본적으로 분산 처리가 지원되지 않습니다.

따라서, 분산 처리를 해야 하는 구조의 Application 인 경우,

아키텍처 구조 상에서 처리 방식을 변경하거나 다른 방법으로 우회해야 할 수 있습니다.

( 우회하는 방법은 몇 가지가 있습니다. )

 

다. Role Over View

 

Role 에 대한 부분을 간단히 정리하고 넘어가겠습니다.

보다 자세한 내용들이 많습니다만, Over View 에서 보여드리는 정도만 이해하셔도 쓰시는 데는

큰 무리는 없으리라 생각이 됩니다.

 

1. 웹 응용 프로그램 ( Web Role )

Windows Azure의 웹 역할은 특수한 목적을 가진 역할로, 프런트 엔드 웹 응용 프로그램을

호스팅하는 데 사용되는 전용 IIS(인터넷 정보 서비스) 웹 서버를 제공합니다.

웹 응용 프로그램을 웹 역할에 빠르고 쉽게 배포한 다음 요구 사항에 맞게 계산 용량을

늘리거나 줄일 수 있습니다.

 

2. 백 엔드 응용 프로그램 ( Worker Role )

작업자 역할 내부에서 호스팅되는 응용 프로그램은 사용자 상호 작용 또는 입력과 무관하게

비동기적이거나, 오래 실행되거나, 영구적인 작업을 실행할 수 있습니다. 작업자 역할에

응용 프로그램의 백그라운드 프로세스를 분리하고 웹 역할에서 프런트 엔드를 호스팅하면

응용 프로그램 논리를 더 잘 분배하고 응용 프로그램의 확장을 더 세밀하게 제어할 수 있습니다.

 

3. 레거시 응용 프로그램 ( VM Role )

현재 베타 단계인 VM(가상 컴퓨터) 역할을 사용하여 사용자 지정 Windows Server 2008

R2(Enterprise 또는 Standard) 이미지를 Windows Azure에 배포할 수 있습니다.

응용 프로그램에 필요한 서버 OS 사용자 지정 항목이 많고 자동화할 수 없는 경우

VM 역할을 사용할 수 있습니다. VM 역할을 통해 응용 프로그램 환경을 완벽하게 제어하고

기존 응용 프로그램을 클라우드로 마이그레이션할 수 있습니다.

 

99. 부가적으로…

Worker Role 에서는 시작 스크립트와 같은 것을 이용해서 Tomcat , Apahce , JVM 을 비롯한

여러 유형의 응용 프로그램을 호스팅 할 수 있습니다.

 

Role 을 통해 배포되게 되면, 인스턴스하에서 구동이 되는 데, 사용하지 않는 인스턴스는

삭제를 하거나 스테이징으로 변경시켜두어야 비용이 발생하지 않습니다.