SOA Layers
이 서비스 기반 아키텍처, 즉 SOA는 소프트웨어 아키텍처 스타일입니다. 이 아키텍처 스타일은 서비스 공급자가 제공하는 서비스를 서비스 소비자가 메시지를 주고받으면서 활용하는 기본 구조를 가집니다.
SOMA 방법론에서와 같이 엔터프라이즈 SOA 구축을 위해서는 몇 개의 계층, 즉 Layer에 걸쳐서 분석과 모델링 과정이 필요합니다. 여기 보시는 그림은 SOA를 계층적인 아키텍처 스타일로 표현합니다.
이 아키텍처 스타일에서 맨 아래에 있는 Operational Systems Layer가 있습니다. 이 Layer에는 그 기업이 보유하고 있는 기존의 CRM이나 ERP 같은 레거시 시스템들이 표현되어 있습니다. 이 Operational Systems Layer 위에는 Enterprise Components Layer가 있습니다.
이 Layer에서는 레거시 시스템으로부터 도출될 수 있는 서비스 컴포넌트들, 핵심적인 서비스 컴포넌트들이 도출돼서 명시됩니다. 또한 이것의 상위에는 Service Layer가 있습니다. 이 서비스들은 아래의 Enterprise Components로부터 사용자를 위해서 제공할 수 있는 유용한 서비스들이 정의됩니다.
그리고 그 위에는 Business Process Choreography가 있습니다. 이 Layer에서는 아래 정의된 서비스들을 활용해서 제공할 수 있는 비즈니스 도메인에서의 프로세서들이 체계적으로 정의되어 있습니다. 맨 최상위의 Layer는 Presentation Layer라고 합니다. 이 Layer는 사용자가 서비스나 서비스의 조합을 Access할 수 있는 사용자 인터페이스를 제공하는 Layer입니다.
또한 여러 계층에 걸쳐서 필요한 요소들이 있습니다. 먼저 서비스 간에 통합을 이룰 수 있도록 하는 Enterprise Service Bus, 즉 ESB가 있습니다. 그리고 서비스의 상태를 모니터링하고 관리하고 서비스의 품질을 보장할 수 있도록 하는 요소도 필요하게 되겠습니다.
Data-Centric Architecture
이러한 기본적인 SOA의 계층구조를 바탕으로 필요에 따라 다양한 형태의 SOA 아키텍처를 구성할 수 있습니다. 몇 가지 대표적인 SOA 아키텍처 구성 옵션들에 대해서 살펴봅니다.
먼저 Data-Centric Architecture가 있습니다. 이것은 서비스 간의 데이터 이동에 초점을 둔 아키텍처로서 효율적인 Message Routing이 매우 중요한 요소가 됩니다. 이러한 Data-Centric Architecture을 표현합니다. 여기는 다양한 레거시 어플리케이션들이 서비스 버스를 통해서 서로 연결된 모습을 볼 수 있습니다.
그리고 이러한 레거시 시스템으로부터 제공될 수 있는 서비스는 하나의 일관된 채널을 통해서 Service Consumer에게 제공됩니다. 그리고 서비스 제공을 담당하는 빨간 점선으로 표시된 신규 시스템은 서비스 제공에 필요한 데이터를 레거시 시스템으로부터 복사해서 모아놓은 Master Database를 유지합니다.
그리고 이러한 Master Database와 기존 레거시 시스템의 데이터와의 일관성 유지를 위해서 파란 점선으로 표시된 것과 같은 Message Router라는 것이 서비스 버스에 연결됩니다. 이 Message Router는 레거시 데이터에 변화가 있을 경우에 이러한 수정 메시지를 Master Database 쪽으로 전송해서 Master Database도 일관된 Data 수정이 일어날 수 있도록 합니다.
또한 Mater Database에 대한 수정이 있을 경우는 반대로 이러한 경로를 통해서 수정 메시지가 해당 레거시 시스템으로 전달되게 됩니다. 이러한 Data-Centric Architecture는 주로 데이터 중심의 웹서비스를 단일 채널로 제공하는 경우에 적합합니다.
이러한 아키텍처의 장점은 서비스 제공의 핵심이 되는 데이터의 품질을 잘 제어할 수 있습니다. 기존의 레거시 시스템에 대한 영향을 최소화시킬 수 있습니다. 반면에 Master Database를 유지해야 되기 때문에 복사된 데이터와 레거시 시스템 간의 수정사항이 서로 반영돼서 일관성을 유지해야 됩니다. 이러한 과정에서 메시지를 주고받기 때문에 Delay가 발생할 수 있습니다.
Data WareHouse
Data-Centric Architecture가 적용된 대표적인 사례는 Data Warehouse입니다. Data Warehouse는 하나 이상의 데이터 소스로부터 데이터를 모아서 통합한 Central Repository입니다. 일반적으로 여러 레거시 시스템으로부터 애플리케이션에 필요한 데이터를 한곳에 모읍니다. 이것을 통해서 사용자가 필요로 하는 애플리케이션들이 개발되어 제공합니다.
Distributed Process Architecture
두 번째 SOA 아키텍처 옵션은 Distributed-Process Architecture입니다. Data-Centric Architecture와는 다르게 이 옵션에서는 Service 제공이 서비스의 종류에 따라 여러 채널을 통해서 이루어집니다. 서비스 요청에 대한 처리가 관련된 레거시 시스템에서 직접 이루어지는 구조를 갖습니다.
또한 서비스 제공에 필요한 데이터도 하나의 데이터베이스에 모아두는 것이 아니라 여러 시스템으로부터 직접 Access하는 방식을 사용합니다. 따라서 Service Consumer는 여러 서비스 경로를 통해 Access한 데이터 간의 중복성이나 비일관성 문제를 직접 해결합니다.
서비스를 그 종류에 따라 두개의 다른 채널을 통해 Consumer에게 제공합니다. 그리고 각각의 서비스 제공자는 관련된 레거시 시스템으로부터 직접 관련된 데이터를 획득해서 서비스를 제공합니다. 즉, 레거시 시스템들이 기존의 엔터프라이즈 내의 애플리케이션들뿐만 아니라 웹서비스 제공까지 함께 담당하는 구조입니다.
이러한 Distributed-Process 아키텍처의 장점은 Data-Centric 아키텍처와 같이 별도의 Master Database를 구축할 필요가 없습니다. 서비스 Consumer들을 가장 최신의 데이터를 통해서 직접 서비스를 제공할 수 있습니다.
그렇지만 이러한 아키텍처의 단점은 내부 시스템 각각이 직접 웹서비스를 제공해야 하기 때문에 해당 내부 시스템에 문제가 있을 경우에 서비스 제공 전체가 중단됩니다. 웹서비스에 부하가 많이 걸리는 경우에는 기존의 레거시 애플리케이션들의 성능 저하로 이어질 수 있습니다.
Sabre System Example
Distributed-Process 아키텍처를 적용한 사례로는 여러분께서 5주차에서 살펴보았던 Sabre의 Universal Service Gateway 아키텍처가 있습니다. 이 시스템에서는 여러분이 기억하시는 것처럼 서비스 클라이언트로부터 요청이 오면 그것을 직접 항공사, 호텔 등 해당되는 Service Provider에게 직접 연결시켜주는 방법을 사용합니다.
Busines Inteligence Example
Business Intelligence 아키텍처입니다. Business Intelligence란 비즈니스 트랜잭션을 수행하는 과정에서 나오는 데이터를 비즈니스 분석을 위해 유용하고 의미 있게 사용될 수 있는 정보로 변환하는 것입니다.
이를 위해서 그림에서 보시는 것과 같이 보통 다양한 데이터 소스로부터 추출된 대용량의 데이터가 저장되어 관리되고, 다양한 분석기법이 활용되어 데이터가 분석됩니다. 그리고 이러한 분석 결과는 가시화되어, 즉 Visualization이 돼서 사용자에게 제공됩니다. 사용자가 비즈니스 골을 달성하기 위한 의사결정을 효과적으로 내릴 수 있도록 도와주게 됩니다.
Business Intelligence 아키텍처는 그림에서 보시는 것과 같이 Business Intelligence 컴포넌트가 서비스를 제공하는 형태로 구성이 됩니다. 이때 Data-Centric 아키텍처에서 보신 것과 유사하게 분석에 필요한 데이터가 여러 레거시 시스템들로부터 모아져서 Master Database에 저장됩니다.
이런 Master Database는 그림에서 보시는 것과 같이 분산되고 이중화되어 구성됨으로써 Business Intelligence 컴포넌트가 다른 웹서비스 성능에 영향을 미치지 않도록 하면서 데이터 관리의 신뢰성을 높입니다.
Middle Tier Architecture
Middle-Tier 아키텍처입니다. 이 아키텍처는 가장 널리 사용되는 것 중에 하나입니다. 웹서비스의 제공을 담당하는 Application Server를 레거시 시스템과 분리된 Layer에 두는 것입니다. 이러한 Layer를 우리는 Middle Tier라고 부르고, 기존의 레거시 시스템이 있는 부분을 EIS Tier, 즉 Enterprise Information System Tier라고 합니다.
Middle Tier에는 Application Server 외에도 Web Server가 존재합니다. 웹 서버는 웹 인터페이스를 통해서 서비스 클라이언트의 요청을 받아 Application Server에게 전달하는 역할을 수행합니다. Application Server는 EIS Tier의 레거시 시스템에 접근하거나 파트너로부터 외부 서비스로 접근합니다. 이걸 통합해서 자신의 웹서비스를 클라이언트에 제공하는 역할을 수행합니다.
Application 서버는 서비스 제공을 위해 빈번하게 EIS Tier에 있는 데이터를 접근할 수 있습니다. 이때 데이터 접근 및 전송의 성능을 높이기 위해 Middle Tier의 애플리케이션 서버에 Cache 메모리를 둘 수 있습니다. 즉, 빈번히 사용되는 레거시 데이터는 Application 서버의 Cache에 caching 됨으로써 EIS Tier에 대한 빈번한 접근 없이도 서비스 제공이 가능합니다.
그런데 Cache 메모리는 일반적으로 용량에 한계가 있습니다. 또 시스템에 문제가 생겼을 경우에는 Caching 된 데이터가 소실될 우려도 있습니다. 그렇기 때문에 Middle Tier에 별도의 데이터베이스를 두어 Cache의 용량과 성능 그리고 안정성을 높이는 방법이 많이 사용이 됩니다.
즉, Cache에서 일정 기간 동안 사용되지 않는 데이터는 Middle Tier Database에 저장했다가 추후 그 데이터가 다시 필요할 때 Cache로 옮겨서 사용하는 방식입니다. Middle Tier 아키텍처를 사용하면 또한 시스템의 보안성도 증대시킬 수 있습니다.
Firewall을 EIS Tier와 Application Server 사이에 또는 Application Server와 웹 서버 사이에 이중으로 설치함으로써
웹 클라이언트들로부터의 잘못된 서비스 요청을 1차로 차단합니다. 또한 엔터프라이즈에서 가장 중요한 EIS Tier에 대한 잘못된 접근을 2차로 차단할 수 있습니다.
SOA Configuration Example
이러한 Middle Tier 아키텍처를 사용해서 구축된 SOA의 전체 모습입니다. EIS Tier에는 다양한 레거시 시스템들이 웹서비스 버스를 통해서 연결된 모습을 볼 수 있습니다.
Middle Tier에서는 애플리케이션 서버가 존재해서 이러한 내부의 레거시 시스템으로부터의 서비스 그리고 외부로부터의 서비스들이 접근돼서 통합된 이후에 클라이언트에게 서비스가 제공되는 모습을 볼 수 있습니다.
그리고 클라이언트는 이러한 애플리케이션 서버로부터의 서비스를 다양한 기기들을 통해서 접근해서 활용할 수가 있는 모습을 볼 수 있습니다.
'SW > 클라우드 서비스 아키텍처' 카테고리의 다른 글
| 클라우드 컴퓨팅 : 개념, 특징, 개요, 설명, 종류 (0) | 2020.06.04 |
|---|---|
| REST API 아키텍처 : 개념, 방법, 개요, 설명 (0) | 2020.06.03 |
| 서비스 지향 아키텍처 모델링 언어 : SoaML : 개요, 개념, 방법, 정의 (0) | 2020.06.01 |
| 서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요 (0) | 2020.05.31 |
| 서비스 기반 어플리케이션 기반 : 웹 서비스 코디네이션 모델 : 개요, 개념, 정의 (0) | 2020.05.21 |