소프트웨어 아키텍처 101 - CHAPTER 16 오케스트레이션 기반 서비스 지향 아키텍처 스타일

16.1 역사와 철학

서비스 지향 아키텍처는 1990년대 후반에 등장했습니다.

이 시대의 아키텍트들은 다양한 외부 여건 탓에 어쩔 수 없이 제약이 많은 분산 아키텍처를 구축했습니다. 아키텍트는 최대한 재사용하는 것을 목표로 삼게 되었고, 실제로 모든 형태의 재사용은 이 아키텍처의 중심 철학이 되었습니다.

이 아키텍처 스타일은 아키텍트가 기술 분할에 집착하면 어떻게 되는지 잘 보여주는 사례입니다.

16.2 토폴로지

서비스 지향 아키텍처의 토폴로지는 [그림 16-1]과 같습니다.

아키텍처 내부에 서비스 택소노미(taxonomy, 분류체계)를 정립하여 레이어별로 책임을 지운다는 아이디어입니다.

16.3 택소노미

이 아키텍처의 중심 철학은 엔터프라이즈 레벨의 재사용입니다.

16.3.1 비즈니스 서비스

이 아키텍처 최상단에 위치한 비즈니스 서비스(business service)는 진입점 역할을 합니다.

16.3.2 엔터프라이즈 서비스

엔터프라이즈 서비스(enterprise service)는 세분화된 공유 구현체를 포함합니다.일반적으로 개발팀은 특정 비즈니스 도메인에 관한 원자적 행위(atomic behavior)를 구현한는 업무를 담당합니다. 이런 서비스는 오케스트레이션 엔진을 통해 묶인, 단위가 큰 비즈니스 서비스를 구성하는 요소들입니다.

이 아키텍처의 재사용 목표 때문에 이렇게 책임을 분리한 것입니다.

16.3.3 애플리케이션 서비스

애플리케이션 서비스(application service)는 한 번만 사용 가능한 단일 구현체 서비스입니다.

16.3.4 인프라 서비스

인프라 서비스는 모니터링, 로깅, 인증/인가 등의 운영 관심사를 지원합니다.

16.3.5 오케스트레이션 엔진

오케스트레이션 엔진(orchestration engine)은 이 분산 아키텍처의 요체입니다. 이 엔진은 비즈니스 서비스 구현체로 서로 엮어주며 트랜잭션 조정과 메시지 변환 등의 기능을 수행합니다. 트랜잭셔널 로직은 데이터베이스가 아닌 오케스트레이션 엔진에서 선언적(declaratively) 처리됩니다.

오케스트레이션 엔진은 비즈니스와 엔터프라이즈 서비스의 관계, 이 둘을 매핑하는 방법, 트랜잭션 경계는 어디까지인지 등을 정의합니다.

16.3.6 메시지 흐름

이 아키텍처는 모든 로직이 오케스트레이션 엔진에 있으므로 심지어 내부 호출을 할 때에도 메시지는 엔진을 경유합니다.

서비스 버스는 아키텍처 내부의 모든 호출을 중계하면서 통합 허브와 오케스트레이션 엔진, 두 가지 역할을 합니다.

16.4 재사용… 그리고 커플링

이 아키텍처의 주된 목표는 서비스 레벨의 재사용, 즉 시간이 지남에 따라 재사용 가능한 비즈니스 행위를 점진적으로 구축하는 능력입니다.

[그림 16-4]처럼 고객의 모든 행위를 하나의 Customer 서비스로 분리함으로써 재사용 목표를 확실하게 달성했습니다.

그러나 이 설계의 어두운 그림자가 서서히 드러나기 시작합니다. 첫째, 재사용 위주로 시스템을 구축 하다보니 컴포넌트 간의 커플링이 심하게 발생합니다.

또 로직을 한 곳에 통합하는 것은 또 다른 부작용을 일으킵니다. 재사용을 위해 만든 컴포넌트는 일부 컴포넌트에서 필요한 세부 정보까지 가지고 있어야 합니다. 즉, 해당 세부 정보가 필요 없는 컴포넌트까지 부가적인 세부 정보 정의의 복잡성까지 떠안을 수밖에 없는 구조입니다. 예를 들어 자동차 보험에 가입하려면 운전 면허증이 필요한데 면허증은 사람이 소유한 것이지 차의 소유물이 아닙니다. 따라서 Customer 서비스는 가령 장애 보험팀에게는 전혀 관심사가 아닌 운전 면허증의 세부 정보까지 갖고 있어야 합니다. 즉, 장애 문제를 관리하는 팀이 부가적인 고객 정의의 복잡성까지 떠안을 수밖에 없는 구조입니다.

16.5 아키텍처 특성 등급

서비스 지향 아키텍처는 어쩌면 지금까지 시도된 아키텍처 중에서 가장 기술적으로 분할된 범용 아키텍처일 것입니다! 실제로 이 구조의 단점에 대한 반발로 인해 마이크로서비스 같은 보다 현대적인 아키텍처가 탄생하게 되었습니다. 이 아키텍처는 분산 아키텍처지만 퀀텀 수는 1개입니다. 아키텍처 어느 부분도 모든 동작을 조정하는 중재자와 상이한 아키텍처 특성을 가질 수가 없기 때문에 이 아키텍처는 모놀리식과 분산 아키텍처 모두의 단점을 갖고 있습니다.

이 아키텍처는 탄력성, 확장성 같은 특성을 일부 지원하지만 구현하기는 상당히 까다롭습니다.

이 아키텍처는 분산 트랜잭션이 실세계에서 얼마나 구현하기 어려운지, 기술 분할의 실제 한계가 무엇인지 생생하게 가르쳐준 아주 중요한 이정표였습니다.

요약

16.1 역사와 철학

• 서비스 지향 아키텍처는 1990년대 후반에 등장함.
• 재사용을 중심 철학으로 삼아 제약이 많은 분산 아키텍처를 구축함.
• 기술 분할에 집착하면 발생할 수 있는 문제를 보여주는 사례임.

16.2 토폴로지

• 서비스 지향 아키텍처의 토폴로지를 그림으로 제시함.
• 아키텍처 내부에 서비스 택소노미를 정립하여 레이어별로 책임을 분담함.

16.3 택소노미

• 엔터프라이즈 레벨의 재사용이 중심 철학임.

16.3.1 비즈니스 서비스

• 아키텍처 최상단에 위치하며 진입점 역할을 함.

16.3.2 엔터프라이즈 서비스

• 세분화된 공유 구현체를 포함함.
• 특정 비즈니스 도메인의 원자적 행위를 구현함.
• 오케스트레이션 엔진을 통해 큰 단위의 비즈니스 서비스를 구성함.
• 재사용 목표로 인해 책임을 분리함.

16.3.3 애플리케이션 서비스

• 한 번만 사용 가능한 단일 구현체 서비스임.

16.3.4 인프라 서비스

• 모니터링, 로깅, 인증/인가 등의 운영 관심사를 지원함.

16.3.5 오케스트레이션 엔진

• 분산 아키텍처의 핵심 요소임.
• 비즈니스 서비스를 엮어주고 트랜잭션 조정 및 메시지 변환 기능을 수행함.
• 트랜잭셔널 로직을 선언적으로 처리함.
• 비즈니스와 엔터프라이즈 서비스의 관계 및 트랜잭션 경계를 정의함.

16.3.6 메시지 흐름

• 모든 로직이 오케스트레이션 엔진에 있으므로 내부 호출도 엔진을 경유함.
• 서비스 버스는 통합 허브와 오케스트레이션 엔진의 두 가지 역할을 수행함.

16.4 재사용… 그리고 커플링

• 서비스 레벨의 재사용을 목표로 함.
• 고객의 모든 행위를 하나의 Customer 서비스로 분리하여 재사용 목표를 달성함.
• 그러나 재사용 위주의 설계로 인해 컴포넌트 간 커플링이 심화됨.
• 로직의 통합으로 불필요한 세부 정보까지 관리해야 하는 부작용 발생함.
  • 예: 운전 면허증 정보가 필요 없는 팀도 해당 정보를 다뤄야 함.

16.5 아키텍처 특성 등급

• 기술적으로 가장 분할된 범용 아키텍처 중 하나임.
• 이 구조의 단점으로 인해 마이크로서비스 같은 현대적 아키텍처가 탄생함.
• 분산 아키텍처지만 퀀텀 수는 1개로, 모놀리식과 분산 아키텍처의 단점을 모두 가짐.
• 탄력성, 확장성 같은 특성을 일부 지원하지만 구현이 까다로움.
• 참고:
  • SOA는 이론적으로 확장성과 유연성을 제공하도록 설계되었지만, 실제 구현에서는 중앙 집중식 구성 요소(예: ESB, 오케스트레이션 엔진)로 인해 병목 현상이 발생할 수 있음.
  • 이러한 중앙 구성 요소가 단일 장애 지점이 되어 확장성에 제한을 줄 수 있음.
  • 올바른 구현을 위해 이러한 문제를 해결할 수 있는 아키텍처적 고려가 필요함.
• 분산 트랜잭션의 구현 어려움과 기술 분할의 한계를 보여주는 중요한 이정표임.