Microsoft 클라우드 Azure의 기업 시스템 통합을 위한 Service Bus

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에 대한 내용은 나중에 좀 더 알아보도록 하겠습니다.